*VMware Feed

2016/10/12

VMwareさん、ご冗談でしょう?(FUDだ!) : Nutanix CVM/AHV と vSphere/VSANのオーバーヘッド

本記事の原文はもともとNutanix社のStaff Solution Architectで、Nutanix Platform Expert (NPX) #001 そしてVMware Certified Design Expert (VCDX) #90(2桁)として活動しているJosh Odger氏によるものです。

原文を参照したい方はVMware you’re full of it (FUD) : Nutanix CVM/AHV & vSphere/VSAN overheadsをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら

訳注: 少々刺激的な表現が多用されますが、原文はもっと酷いです(笑) 真実は人と立場によって異なります。決して何かを煽るつもりもありませんし、そうならないように(特にインカーネルストレージIOパスPVSCSI)技術的な裏取りの記事をいくつも翻訳してきました。ぜひ、合わせてこの壮絶な宗教(?)争いの結果に生まれたとんでもない記事をお楽しみください。

長きに渡って、VMwareとEMCは他のベンダーとともにNutanixのコントローラーVM(CVM)についてのFUD(訳注:ネガティブキャンペーン、Fear-恐れ、Uncertainty-不安、Doubt-疑念を煽るような競合に対するマーケティング戦略のこと)を流し続けてきました。すなわち、CVMはI/Oを行うために多くのリソースを利用する、ですから仮想マシン(つまり、仮想化ストレージアプライアンス/VSA)はインカーネルで動作するのよりも効率が悪く、遅いと。

最近のFUDの例を挙げると、VCEの社長、Chad Sakac氏自らが書いた記事があるので引用します。

それ(VxRail)は完全に統合されたSDSスタックをカーネルに埋め込んだ唯一のHCIA(ハイパーコンバージドインフラストラクチャアプライアンス)です。VSANを利用するためにVxRailはvSphereを利用します。8vCPU、16GB以上のメモリをストレージスタックに利用するようなおかしなことはしません(これは他のHCIAを選んだ場合の「ストレージコントローラ」毎の値、もしくはノードあたりの値ですよ!)。

ですから、私は過去に書き連ねてきたNutanix CVMの提供する機能と、Chad氏のいう完全にSDSが統合されたスタックを並べて比較の記事を書いてみました。

さぁ、Acropolis分散ストレージファブリック(ADFS)とAcropolisハイパーバイザ(AHV)からなるNutanix Suiteに必要とされるリソースと、VMware社のvCenter、ESXi、VSANそして関連コンポーネントからなるVMwareのSuiteに必要とされるリソースの比較をしていきましょう。

こうすることで、Nutanixのプラットフォームをあまりご存知でない方がその機能とCVMが提供する価値を理解する事もできますし、様々な競合他社によって流されているFUDは正しくはどういうものかという事を理解することも出来ます。

初める前に、Nutanix CVMの標準のサイズを確認しておきましょう。

本日の時点ではCVMは標準で8vCPU、16GBのメモリを利用します。

CPUリソースについては当たり前のことですが、お客様のユースケースによって異なります。もしもI/O要件が低い場合には、CVMは8vCPUどころか、4vCPUも利用することはありません、ですが8vCPUが割り当てられています。

何年もの間に渡ってESXiのCPUスケジューリングは改善され、必要以上のvCPUを環境内の限られた数の仮想マシン(例えばCVM)に割り当てるという影響は無視できるほどになっています。でうが、CVMはしっかりとサイジングされているべきだということも常識です。

メモリの割当は重複排除を利用する場合には24GBが推奨です、そしてワークロードが大きくReadに偏っているような場合、メモリを増やすことで更に大きなReadキャッシュとして利用できます。

しかし、CVMのメモリをReadキャッシュ(拡張キャッシュ)として増やすのは今では昔の推奨事項とされています。これはAcropolisオペレーティングシステム(AOS)4.6のリリースでReadキャッシュを有効にしなくても優れたパフォーマンスが出るような改善がなされたからです。

実際のところ、AOS 4.6において4KのランダムのReadで 150K(15万)IOPS以上を記録したNX-9040-G4のノードはインメモリReadキャッシュを利用せずに開発チームがSSDの性能がどのぐらいのものなのかを示すために行ったテストでのものです。結果として、極端なほどのパフォーマンスであってもCVMのメモリをReadキャッシュとして増やすということはもはや必要ありません。ですから殆どのワークロードでは24GBのメモリで充分であり、メモリの要件を減らすということも可能なのです。

考察 : インカーネルのソリューションが優れたストレージパフォーマンスを提供できるということが事実であったとしても(今回はそういう話はしませんが)、これは全体からするととても小さな部分にしか過ぎません。管理についてはどうですか? VSANの管理はvSphere Web Client経由で行われますが、その仮想マシンはユーザースペース(空間)で動作しています(つまり、「インカーネル」ではない)し、更に同じくユーザー空間で動作している仮想マシンで動作しているvCenterに接続を行います、さらにvCenterはSQLやOracleデータベースを利用しており、これもユーザー空間で動作しています。

さて、続いてレプリケーションについて見ていきましょう。VSANはvSphere Replicationを利用します、これもご承知のとおり、ユーザー空間で動作している仮想マシンで動作します。キャパシティ/パフォーマンス管理において、VSANはvRealize Operations Manager(vROM)を利用しており、これもユーザースペースで動作しています。バックアップは? vSphere Data Protectionアプライアンスはこれもまた、ユーザー空間で動作している仮想マシン上のサービスです。

これらの全ての製品はデータをカーネル空間からユーザー空間へと取り出す必要があります。現時点では仮想マシンの基本的なI/Oを除くとすべての機能でVSANはユーザー空間で動作しているコンポーネントに依存していることになります(つまり、インカーネルではない)。

さぁ、VSAN自身の要件を見ていきましょう。

VSAN design and sizing guide(ページ56)によるとVSANはVSANのすべての機能を利用する場合には最大でホストのCPUの10%までと32GBのメモリを必要とすると有ります。もちろん、VSANが32GB全てを利用するということではなく、必要でなければNutanixのCVMが割り当てられたメモリを全て利用するということはないということと同じです。ですが、Nutanixでは最低推奨サイズの12GBまで減らすことができますし、16GBが今日では小さい方だと言わざるをえない192GBのメモリを搭載したノードにおいても標準的です。16GBというのはVSANであってもNutanixのCVMであっても10%未満で最小限のオーバーヘッドと言えるでしょう。

私が検証した結果によるとVSANのCPU利用率のオーバーヘッドは10%に制限されているようではないようです。これはVMware社自身が行ったSQLでの検証「VMware Virtual SAN™ Performance with Microsoft SQL Server」で確認が可能です。

かいつまんで説明をすると、検証は4vCPUで構成された3つの仮想マシンで実施され、デュアルソケットのIntel Xeon プロセッサE5-2650 v2(16コア、32スレッド@2.6GHz)を搭載したホストで動作しています。

仮想マシンが100%の利用率だと仮定しても、コア全体の75%(16のうちの12)しか利用しないはずです。ですから、以下のグラフを見ると仮想マシン以外の何者かがCPUを利用しているということがわかります。最低でもハイパーバイザが5%を利用するとして、VSANは20%ほどのCPUを利用していることになります。実際には仮想マシンは100%の利用率になることはありませんので、VSANは20%よりも多くオーバーヘッドがある事になります。

Fig032さて、I/OのためのCPU要件はわかりました。VSANが20%かそれよりも多くCPUを利用するとしても別段問題はありません。問題だと思うのはVMwareがお客様に10%しか利用しないというご案内をして、更にNutanixのような仮想アプライアンスを利用する他の仮想アプライアンスベンダーはリソースの大食漢だというFUDを撒き散らしていることです。

私の言葉をそのまま信じるのではなく、ご自身で検証したり、上で挙げられているようなドキュメントを読んでみてください。簡単な算数だけで、最大10%と言うのは神話であるということがわかると思います。

ここから、大体4vCPU(大抵のデュアルソケットの8コアのシステム上で)と最大で32GBのメモリがVSANに必要になるということがわかります。ですが、今回は平均的に16GBということにしておきましょう。殆どのシステムはディスクグループが5以上になることはありません。

上での検証は最新のVSAN 6.2でのものではありません。ですから、これは今では変わっている可能性があります。こうしたVSANの変更の中にソフトウェアのチェックサムがあります。これは実際にパフォーマンスを劣化させます(皆さんのご想像の通り)、というのもこの機能は全てのI/Oについてのデータの一貫性を提供するものであるため、上で述べてきたパフォーマンスの比較をNutanixと行うという意味ではこれを加えるほうがフェアになります。というのも、本稼働系のストレージソリューションとしてこの機能は必須の機能なため、Nutanixは常にソフトウェアでチェックサムを取得しているからです。

そして、思い出してください、VSANはストレージスタックの部分しか提供していないのです。ですから20%までのCPUの高負荷は単なるストレージスタックだけからのものです。NutanixのCVMではそれに加えて高可用性をもつ管理レイヤーも提供しており、比較をするのであれば(殆どの場合、それ以上の機能、可用性、拡張性を提供していますが)vCenter、VUM、vROM、vSphere Replication、vSphere Data Protection、vSphere Web Client、Platform Services Controller(PSC)そしてそれを支えるデータベースプラットフォーム(SQL/Oracle/Postgres)までをも提供しています。

ですから、VSANのCPU利用率とNutanixのCVMを正味で比較というのとは程遠いわけです。正味の比較を行うために、全てのvSphereの管理コンポーネントのリソース要件を見て、平等な比較を行いましょう。

vCenter Server

リソース要件:

Small | Medium | Large

4vCPUs | 8vCPUs | 16vCPUs
16GB | 24GB | 32GB RAM

参照:http://pubs.vmware.com/vsphere-60/index.jsp#com.vmware.vsphere.install.doc/GUID-D2121DC5-1FC8-48DC-A4BA-C3FD72D0BE77.html

Platform Services Controller

リソース要件:

2vCPUs
2GB RAM
参照:http://pubs.vmware.com/vsphere-60/index.jsp#com.vmware.vsphere.install.doc/GUID-D2121DC5-1FC8-48DC-A4BA-C3FD72D0BE77.html

vCenter Heartbeat (今では非推奨)

もしも正味で比較しようとするとvCenterに完全な分散と高可用性が必要になりますが、これは出来ません。vCenter Heatbeatは今では非推奨ですが、何かしらを加えなければなりません。vCenterやVUMなどのリソースを2倍することになるでしょう。非推奨ということですし、今回はVMwareさんの仰るとおり、管理コンポーネントの高可用性のためのリソースを勘定に入れないことにします。

vCenterのリンクモードについては?

これに関するドキュメントを見つけることは出来ませんでした。ですからVMwareさんのおっしゃるとおり、オーバーヘッドは一切ないということで行きたいと思います。ですが、オーバーヘッドはさておき、別製品としてインストール、検証、維持管理しなくてはなりません。

vSphere Web Client

完全なVSANの管理、昨日を利用するためにはWeb Clientが必要になりますが、これはそれ自身のリソース要件があります:

4vCPUs

2GB RAM (最低要件)
参照:https://pubs.vmware.com/vsphere-50/index.jsp#com.vmware.vsphere.install.doc_50/GUID-67C4D2A0-10F7-4158-A249-D1B7D7B3BC99.html

vSphere Update Manager (VUM)

VUMはvCenterサーバ上にインストールすることも出来ます(これはWindowsへのインストールを行っている場合)、これは管理仮想マシンやOSの管理の削減になりますが、もしも仮想アプライアンス版を利用している場合には別のWindowsインスタンスが必要となります。

リソース要件:

2vCPUs
2GB

NutanixのCVMはメジャー、マイナーのAHVはもちろんのことESXiのパッチアップデートの機能を有しています。

vRealize Operations Manager (vROM)

NutanixはPRISM Element内にvROMが提供しているような分析の機能を組み込みで提供しており、キャパシティ計画/管理を一元的に行うことが出来、「what if」シナリオによってノードのクラスタへの追加の機能を提供しています。ですから、正味で比較するためにはvROMを加えて比較するのが正しいと思います。

リソース要件:

Small | Medium | Large

4vCPUs | 8vCPUs | 16vCPUs
16GB | 32GB | 48GB
14GB ストレージ

リモートコレクタ Standard | Large

2vCPUs | 4vCPUs

4GB | 16GB
参照:https://pubs.vmware.com/vrealizeoperationsmanager-62/index.jsp#com.vmware.vcom.core.doc/GUID-071E3259-625A-437B-AB34-E6A58B87C65B.html

vSphere Data protection

Nutanixは組み込みのバックアップ/リカバリ/スナップショットの機能をVSSによるアプリケーションとの整合性をもって提供しています。vROMと同様にNutanixのCVMとの比較にはvSphere Dta Protectionを加えるべきです。

vSphere Data Protectionは以下の様に0.5TBから8TBにて展開されます:

Fig033

参照: http://pubs.vmware.com/vsphere-60/topic/com.vmware.ICbase/PDF/vmware-data-protection-administration-guide-61.pdf

最小で4vCPUと4GBのメモリを利用しますが、それでは0.5TBしかサポートされません。平均的な4TBを利用しようとすると4vCPUと8GBのメモリが必要になります。

VDPアプライアンス1台あたりではもっとも良くても8TBであり、これはNutanixの(もしくはVSAN Ready)ノードの幾つかよりも小さい値です(例 : NX6035/NX8035/NX8150)。ですからVSANを利用している場合にはVDPアプライアンスを各ノードに一つずつ展開するという可能性も出てきます。これはNutanixのようにVSANにはバックアップの機能が組み込まれていないからです。

さて仮想マシンのレプリケーションをしたい場合や、Site Recovery Manager(SRM)を利用したいという場合はどうなるでしょうか?

vSphere Replication

vROMとvSphere Data Protectionと同じようにvSphere RepliactionはVSANにNutanixではCVMに組み込まれている機能を提供します。正味の比較のためにはvSphere Replicationも含める必要があります。

vSphere Replicationのリソース要件はかなり軽いものでは有りますが、もしも全てのレプリケーションがこのアプライアンス経由になるとするとそのVSANノードはストレージとネットワークのトラフィックのホットスポットになり、ネットワークとノードを逼迫させたり、ノード上のすべての仮想マシンにとってのノイジーネイバー(やかましいご近所さん)になってしまう可能性もあります。

リソース要件:

2vCPUs
4GB RAM
14GB Storage
制限:

vCenterあたり1つのvSphere replicationアプライアンス
2000仮想マシンが上限
参照: http://pubs.vmware.com/vsphere-replication-61/index.jsp?topic=%2Fcom.vmware.vsphere.replication-admin.doc%2FGUID-E114BAB8-F423-45D4-B029-91A5D551AC47.html

ですから2000仮想マシンを超えて拡張しようとした場合、別のvCenterが必要になり、それはまた、別のVUM、Heatbeat(もしもまだあったとしたら)、そして更にSQLかOracle上の別のデータベースが必要ということになります。

Nutanixはこうした制限はありませんが、VMwareがおっしゃる通りでの比較にしたいと思います。

サポートするデータベース

小さなSQLサーバであったとしても大抵は最低2vCPUと8GB以上のメモリになり、完全な正味の比較をしようとするとバックエンドのデータベースサーバもNutanix AHV/CVMがそうであるように高可用性のサポートを加味しなくてはなりません。

ですから、小さな環境であったとしても2vCPUと8GB以上のメモリの仮想マシンが2つ必要で、それは単にvCenter、VUM、SRMなどのバックエンドのデータベースの要件だけです。

環境が大きくなるにつれ、vCPU/vRAMとしてストレージ(キャパシティやIOPS)要件も大きくなることを覚えておいてください。

さて、VSANの小さな4ノードのクラスタのオーバーヘッドとして何が適切か?

以下のテーブルは上で述べてきたそれぞれのコンポーネントの最低要件を元にVSAN(完全に等価ではありませんが)とNutanix CVMの提供している機能を比較したものです。

Fig034

上は小さな、例えば4ノードの環境での最低要件しか採用していません。vSphere Data Protectionは複数インスタンス必要になるでしょうし、SQLは高可用性を実現するために常時稼働可用性グループ(AAG-always on availability Group)を利用しすべきで、2つ目のSQLサーバが必要になります。そして環境が大きくなればvCenter、vRealize Operations Manager、SQLのvCPU/vRAM要件も高くなります。

一方でNutanix AHV環境は以下のようになります:

Fig035

結果として4ノードクラスタのための32vCPUと64GBのメモリという値はvSphere/VSANの4ノードのソリューションに比べて8vCPUそして54GBも少ないということになります。

もしNutanixのスケールアウトファイルサーバ機能(オプションで有効にできます)を加えたとしても値は48vCPUと100GBのメモリで、vSphere/VSANと比べてvCPUが8つ多くなりますが、メモリは18GB少ないことになり、それでもNutanixはそれ以上の機能(例えばスケールアウトファイルサービス)を提供していますし、箱から取り出してたままで完全に分散された、高可用性のある、完全に統合された管理スタックを備えています。

NutanixのvCPUの数はすべてのvCPUを利用することを前提で数えており、これは殆どの場合起こりえません。ですからこの比較はNutanixと比べVSANを利用している際にvSphere/VSANに高いオーバーヘッドがあるということと、Nutanixは組み込まれた機能、例えばスケールアウトファイルサーバ(これもまた分散された高可用性のあるソリューションです)などの追加機能を提供しており、vSphere/VSANよりもちょっと多くのリソースを利用するだけで、vSphere/VSANの提供していないファイルサービス機能が利用できるということを上手く顕しています。

もし、こうしたvSphere/VSANのすべての機能を利用せず、つまりこれらの管理仮想マシンを展開しないとしたら、VSANのオーバーヘッドは低いというのは正しいのか?

すべてのvSphere/VSANの機能を利用しないので、展開する必要がないという議論もあると思います。それではそれによってvSphere/VSANの要件(やオーバーヘッド)は小さくなるのでしょうか?

同じ仮定はNutanixのコントローラVMについても同様のことが言えます。

お客様がすべての機能を利用する必要がなく、I/O要件も軽いという場合にはCVMを6vCPUにダウンサイズするということも少なくありません。私自身、今週とあるSQL/Exchangeを動作させているお客様でこれを実施しました。インライン圧縮を行いながら、ビジネスクリティカルアプリケーションを動作させている際にCVMは75%あたりで動作しており、これは大体4vCPUでした。

結局のところ、オーバーヘッドはワークロード次第で、標準のサイズはvSphere/VSANコンポーネントでもNutanix CVMでも変動するのです。

さて、インカーネルのくだらない話へと戻りましょう。

VMwareは自分自身のハイパーバイザーが非常に大きなオーバーヘッドがあるので、ストレージをそれを通して動作させるのは難しいというFUDを広めるのが好きなようです。これを見るたびにVMwareはこれまで市場に対してハイパーバイザのオーバーヘッドは小さい(実際に小さい)と言い続けていたので、変だなと感じます。けれどもVMwareは自身の商品のためにお天気のように言葉を翻しました。

こうしたFUDの例はVMwareのチーフテクノロジストDuncan Eppingのツイートです:

Fig036

訳注: どうしてインカーネルがいいのか?と聞く前に 幾つかのステップを省略できる!

ツイートにはハイパーバイザを経由して別の仮想マシン(この場合、Nutanix CVM)へアクセスするのは効率的ではないという意図で書かれています。これはいくつかの理由で非常に興味深いものです:

  1. もしもそんなにもハイパーバイザを経由して仮想マシンから別の仮想マシンへと通信するオーバーヘッドが高いというのであれば、どうしてVMwareはビジネスクリティカルな、高いI/Oを要求するようなアプリケーションで、仮想マシン同士(そしてESXi同士)がデータアクセスを相互に行うようなアプリケーションをカーネル上で動作させることを推奨しているのでしょうか? 例: Webサーバ仮想マシンはアプリケーションサーバ仮想マシンへアクセスし、さらにそこからデータベースへとアクセスするような構成、それぞれが各々仮想マシンでカーネルを通じて別の仮想マシンへとアクセスする。
  2. VSANは以下に上げるような機能でそれを利用している:
  • レプリケーション(vSphere Replication)
  • vRealize Operations Manager (vROM)
  • vSphere Data Protection (vDP)
  • vCenter と それをサポートするコンポーネント

VMwareのもう一つのFUDの例として今回はプリンシパルエンジニアである Jad Elzeinのもので、VSANはNutanix(BlockはNutanixの「Block」のことです)に比べてオーバーヘッドが小さいという事を意図したものです。

訳注: 10ブロック=40ノード = 40管理仮想マシン = 80vCPUと1TB以上のメモリが管理のためだけに! オーマイゴッド!

思うに、VSANの機能やvSphereの基本管理機能に必要な仮想マシンの数(とリソース)について忘れてしまったのだと思います。インカーネル(もしもまだ何らかの優位点があるということを信じているのであれば)の優位点の全てはハイパーバイザーとインカーネルではない管理仮想マシン間の恒常的なトラフィックによって以下の図のように殆ど消えてしまいます:

Fig038むしろ、#AHVisTheOnlyWay(AHVこそが進むべき道だ)そして#GoNutanix(Nutanixを使おう!)というのが正解です。AHVのオーバーヘッドはvSphere/VSANよりも小さいのですから!

まとめ:

  1. Nutanix CVMは完全に統合された、事前構成済みの、高可用性を備えた、自己修復管理スタックを提供します。vSphere/VSANは多くのアプライアンスやソフトウェアを追加でインストールする必要があります。
  2. Nutanix AHVの管理スタック(CVMによって提供される)は8vCPUと大抵は16GBのメモリのみで、その中で多くの場合vSphere/VSANを超える能力を提供します。vSphere/VSANは同等機能を提供しようとすると(実際には同等にならないことも多いですが)非常に多くのリソースを利用します。
  3. Nutanix CVMはこれらの機能を様々な多くの仮想アプライアンス、仮想マシン、またはサードパーティのデータベース製品に頼るのではなく組み込みで提供します(PRISM Centralだけは別の仮想アプライアンスで例外ですが)。
  4. Nutanixの管理スタックは競合製品に比べより優れた堅牢性/高可用性を備え、しかもすぐにそれが利用できます。クラスタが拡張されるにつれAcropolis管理スタックが自動的に管理機能を拡張し続け、リニアな拡張性と一貫したパフォーマンスを保証します。
  5. 次にVMware/EMCがNutanix コントローラVMについて、リソースの大食漢であるとか、そのたぐいのFUDを広げようとしていたら、それはどの機能についての話なのか聞いてください。おそらくここで述べたようなポイントは考慮していませんでしょうから、お勉強として上の記事を読むようにさせてください。
  6. Nutanix AHV管理は完全に分散されており、高可用性を備えています。VMwareにvSphere/VSANの管理コンポーネントを完全に高可用性を備えた状態にする方法を聞いてみてください。ついでに、設計、インストール、検証、維持管理のためのプロフェッショナルサービスにいくらかかるかも。
  7. 次の会話は「Nutanixと比べてVSANはどれだけのコストがかかるの?」です。今回全てのリソースのオーバーヘッドとvSphere/VSAN環境の設計、実装、検証が複雑であるということを知りましたが、vSphere HA以外にほとんど管理コンポーネントを守るすべがないということまではお話しませんでした。しかし、コストの話はELAやライセンシングコストの話をしなくてはなりません。あまり興味わかないですよね。

VMware/EMCにいるお友達へ、Nutanix CVMはこう言っていますよ。

「あっちへ行って、見くびっていてください。」

記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw) 今後は (@Networld_NTNX)

どうでしょう(笑)!? そもそもかなり偏った角度からの記事です。どうしてもFUDを払拭したかったのでしょう(ありがたいことに、全部引用元を明らかにしてリンクがついている・・・)。今後はCalm.ioを買収したのでvRealize Automationも加えないといけないとか、NutanixがPernixDataを買収したのでやっぱりインカーネルが必要・・・と思ったりしている人もいるかもしれません。

今回、この記事を取り上げたのは最近の翻訳記事で繰り返しお伝えしているとおり、変な色眼鏡で技術を誤解してほしくないということをお伝えしたかったからです。Guidoさんや今回のJoshさんのようにしっかりと技術的に確認して、何が正しいのか見極めてください。

2016/10/05

VMwareのSCSIコントローラのオプション

本記事の原文はもともとPernixData社のTechnical Support Engineer (TSE)で、現在はPernixData社のNutanix社による買収でNutanix社のSr. Systems Reliability Engineerとして活動を継続しているGuido Hagemann氏によるものです。

VMworld EMEAに参加した際に初めてお会いしましたが、Guidoさんはサポート担当ですので、時間によってはサポートコールを取ってくれて話やメールをした間柄です。

原文を参照したい方はVMware SCSI Controller Optionsをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら

今回の記事ではVMware ESXi内の様々なSCSIコントローラについてと、なぜ最終的に他のものよりこのオプションが優れるのか、ということを解き明かして行きたいと思います。私は現職で様々なお客様と、どういう状況においてはLSI Logis SASやParallelがParavirtualized(準仮想化) SCSIアダプタ(PVSCSI)に対して優れるのかという様々な議論を交わしてきました。そしてその結果、私の考える本当の理解とその違いについて上手く説明しているブログの記事やKBが無いということに気が付きました。殆どの環境ではOS標準のアダプタが選択されており、多くの場合、それで良く、上手く動いています。問題が起きるのはどこかに制限があったときであって、どのようにそれを見つけるかではありません。でははじめていきましょう。現在のESXi 6.0のヴァージョンでは5つのSCSIコントローラを選ぶことが出来ます。それをまとめたのが以下のテーブルです。

SCSIコントローラの比較

アダプタタイプ
OSタイプ
最低要件
最大SCSIアダプタ数
ユースケース
BusLogic Parallel
サーバ
-
4
コントローラあたり15デバイス、64ビットOSと2TBのVMDKの問題、VMwareはこのアダプタからの移行を推奨している
LSI Logic Parallel (以前のLSI Logic)
サーバ/デスクトップ
-
4
コントローラあたり15デバイス、Microsoft Clusteringサービスに必要(Windows 2008より古い場合)
LSI Logic SAS
サーバ/デスクトップ
HWv7
4
コントローラあたり15デバイス、ほとんどのOSの標準のSCSIコントローラ、MSCS(Windows 2008以降で必要)
PVSCSI
サーバ
HWv7
4
コントローラあたり15デバイス、I/Oの多い殆どのユースケースにおいてはCPU利用率が低い、ESXi 5.5u2以前ではMSCSをサポートしない
AHCI SATA
サーバ/デスクトップ
HWv10
4 (既存のSCSIコントローラ上で)
コントローラあたり30デバイス、I/Oの多い環境では推奨されない、LSI Logic SASまたはPVSCSI程効率的ではない

アダプタタイプ

見るとおり、AHCI SATAコントローラはさほど大きなメリットを産んでいません。このコントローラは追加ディスクを大量に必要とするような場合を想定しており、パフォーマンスについては問題としていないのです。AHCI SATAコントローラは既に利用しているSCSIコントローラ上に追加することが可能です。

それぞれのアダプタがいつからサポートされているのか、ということを知るのも重要ですので、以下のテープルにまとめました。

機能
ESXi 6.0
ESXi 5.5
ESXi 5.1
ESXi 5.0
ESXi 4.x
ESXi 3.5
ハードウェアヴァージョン
11
10
9
8
7
4
サポートされるSCSIアダプタ
BusLogic
LSI Parallel
LSI SAS
PVSCSI
AHCI
BusLogic
LSI Parallel
LSI SAS
PVSCSI
AHCI
BusLogic
LSI Parallel
LSI SAS
PVSCSI
BusLogic
LSI Parallel
LSI SAS
PVSCSI
BusLogic
LSI Parallel
LSI SAS
PVSCSI
BusLogic
LSI Logic
ESXiのサポート

x86アーキテクチャ

さて、もっとも面白そうなアダプタはLSI Logic SASとPVSCSIであるということに疑問はなくなりましたか? この「Paravirtual(準仮想化)」という言葉は一体どういうことを意味するのでしょうか?これについてお話する前に、ドライバがスタックのどこに位置しているのかを見ていきましょう。x86アーキテクチャでは常に4つのレベルもしくは特権を目にします。それらはリングまたは、CPUモードと呼ばれており、リング 0~3に分けられます。従来からのWindowsのようなOSはリングを2つだけ利用してきました。これはその時に利用できるプロセッサが2つ以上のモードをサポートしていなかったからです。あらゆるアプリケーションが利用する最低限の特権しか有しないリング3とすべての権限を利用できるリング0です。ですから、ユーザーアプリケーションがハードウェアを利用しようとする度にCPUはユーザーモードへと切り替わる必要があります。もし、もっと詳しく知りたいということであればカーネル vs ユーザーモードという記事を読んでみてください。次の図はx86アーキテクチャでの従来型のモードを顕しています。

Fig029従来型x86アーキテクチャ

VMMを利用したバイナリトランスレーション

仮想化された環境ではハイパーバイザ自身が物理ハードウェア上で動作します。ゲスト仮想マシンOSがリング 0で動作することは非常に難しくなります。これはリング 0をハイパーバイザー自身が利用しているからです。更に複雑なことに、特定の操作はリング 0で実行しなければ完了できないというものが有ります。では、どうやっているのでしょうか? VMwareはバイナリトランスレーションと呼ばれる手法を利用して、仮想マシンモニタ(VMM)をリング 0で動作させています。これによって仮想マシンがこうした操作を行う際にリング 0で動作しているVMMの力を借りて実行することが出来るようになります。アプリケーション自身にとっては何も変わってはいません。次の図にこれを顕します。

Fig030OSのリクエストでバイナリ変換

ESXi内のParavirtual(準仮想化)実装

Paravirtual SCSIアダプタという名前は意味合いで言うとちょっと間違っています、これは全てのゲスト仮想マシン内のすべての仮想化ハードウェアはparavirtual(準仮想化)だからです。全く同じことがVMXNET3ドライバという固有のVMwareのドライバについても当てはまります。いずれの場合もゲストOS内にドライバをインストールして、このアダプタを利用できるようにしなくてはなりません。VMXNET3ドライバについてはこれはVMwareツールがインストールされた際に既に完了しています。

paravirtualドライバを利用するとESXiカーネルへアクセスすることが出来るようになり、システムハードウェアと通信する際にVMMを経由しなくても良くなります。ESXiに対して「ハイパーコール」を実行し、スケジューリング、割り込み、メモリ管理などの重要な操作を実現します。ですから、これはドライバの観点からはカーネルとのダイレクトチャンネルのようなものです。PVSCSIアダプタは他のSCSIコントローラのオプションに比べ一般的には優れたパフォーマンスを低いCPU利用率で提供することが出来ます。ですが、全ては時と場合次第です。次のセクションではLSI Logic SASとPVSCSIをもっと比較します。以下の図は一般的な「ハイパーコール」を利用するparavirtualアダプタの実装を顕しています。

Fig031 ESXi内のParavirtual(準仮想化)実装

合成

合成(Coalescing)は融合(merge)、結合(join)、assemble(組み上げ)の類義語ですが、ゲスト仮想マシン内のSCSIコントローラではどういう意味を持つのか?とても簡単で、I/Oを非常にうまいやり方で最適化します。少しだけ合成がどういう意味を持つのかを挙げてみます。

  • ストレージドライバを効率化する手法
  • 合成はある種のバッファで、複数のイベントが同時実行の待ち行列していると考えると良い
  • 効率と割り込みを改善しますが、そのためにはI/Oは大きなバッチリクエストとして生成出来るようにある程度高速な流れでなくてはならない
  • もしも流入するI/Oがおそすぎて、タイムアウト期間まで待たなければいけない場合、I/Oは不必要に遅延が起きることになる
  • LSI Logic SASとPVSCSIの両方は合成に割り込みをかけるために2つの異なる方法を用いています:
    • 行われるI/O数(outstanding I/O) : 仮想マシンのI/O要求数
    • IOPS : ストレージシステムが提供できるI/O

では、この2つが双方のアダプタでどのように動作するのかを比較してみましょう。

  1. LSI SAS : ドライバは行われるI/O数(Outstanding I/O:OIO)とIOPSが増加するに連れて合成を増やし、OIOが殆ど無い場合やスループットが低い場合には合成を行いません。ですから、OIOとI/Oスループットが小さい際には非常に効率的です。
  2. PVSCSI : ドライバはOIOベースでのみ合成を行い、スループットは考慮しません。仮想マシンが多くのI/Oを行っているときでも、ストレージにそれがすぐに伝わるということはなく、PVSCSIドライバが合成の割り込みを行います。ストレージに一定の流量のI/Oが無い場合、もちろん合成のための割り込みは必要ありません。結果として、わずかばかりですが、レイテンシが上がることになり、PVSCSIコントローラではスループットの低い環境では得るものは無いということになります。
  3. CPUコスト : LSI Logic SASとPVSCSIコントローラの違いはIOPSが低い場合にはその差は図ることが出来ない程度ですが、多くの数のIOPSであればPVSCSIではCPUサイクルを劇的に削減することが出来ます。

VMwareによると、2,000IOPSのピークパフォーマンス、または4OIOあたりでの切り替えがよいということがKB107652に記載されています。さらに新しいヴァージョンのESXiに於いてはもっと低いIOPSやOIO要件においてもPVSCSIを利用することを推奨しています。

キューデプス(Queue Depth)

パフォーマンスを最大化するためには仮想化ディスクが出来る限り多くのvSCSIアダプタに分散しているのが良いということになります。最大で4つのvSCSIアダプタが仮想マシンに対して構成でき、一つのvSCSIアダプタ毎に最大で15の仮想化ディスクが利用できます。複数のvSCSIアダプタを利用することでより多くのI/Oキューを利用することが出来るということです。以下のテーブルはPVSCSIアダプタを利用したときと、LSI Logic SASアダプタを利用したときのキューデプスを比較したものです。

キュー
PVSCSI
LSI Logic SAS
アダプタのキューデプスの標準値
256
128
アダプタのキューデプスの最大値
1024
128
仮想ディスクのキューデプスの標準値
64
32
仮想ディスクのキューデプスの最大値
254
32
キューデプス

PVSCSIのチューニング

とてもよいKBがあります : VMware KB 2053145 理解すると仮想マシンだけでなく、ESXi自身の様々なパラメータを変更しながらチューニングを行えるようになります。2つの設定項目がチューニングできます:

  • ESXiホスト上のHBAのキューデプスの調整
  • WindowsもしくはLinuxゲスト内部からPVSCSIのキューを増やす

注意 : 標準のリングのページは8つで、それぞれが4KBのサイズとなっています。一回のI/Oのキューに関しては128バイトが必要とされます。つまり、32回で単一ページの4096バイトを利用することになり、結果として256回のIOができることなります(8x32)。WindowsのPVSCSIドライバアダプタのキューは以前のリリースではハードコーディングされていましたが、VMwareツールで提供されるヴァージョン以降では最大で32ページまで調整して増やすことが可能です。

ここにKBから抜き出した注意書きを書きましたが、これはどういう意味なのでしょうか?リングページとキューデプスが本当はどういう意味で、どのように誤解されているかを説明していきます。

リングページ :

128バイトと言う単位はI/Oのことを指しますが、これはI/Oが直接入出力される実際のメモリのことではありません。ページは実際のI/O操作を行うためのリングバッファによって利用されるメモリのことを指しています。実際のI/O自身にはこれは利用されません。これはDMA操作で利用されるポインターを格納しているページだと考えてください。ページのうちの一部分(非リングページ)があるI/Oに使われる場合がありますし、残りの部分(もちろん、かぶる場合もあります)が別のI/Oで利用される可能性があります。ですから、これ以降の操作が可能になるのです。

キューデプス :

キューデプスの数はPVSCSIの場合にはアダプタの制限を反映したものになります。アダプタは8つのリングページを利用するので、256のキューデプスをサポートします。PVSCSIは実際のデバイスではなく、VMwareの準仮想化SCSIデバイスですから、これは自然にはありえない値になっています。しかしながら、他のデバイス(実際のアダプタ)では、実際のハードウェア上の制限です。リングはハードウェア内にあり、制限を受けますので、そこでキューデプスです!キューデプスはアダプタ毎に存在します。ですから、もしもPVSCSIや他のLSIアダプタであれ、4倍の数のキューデプスを利用することが出来ます。つまり、それぞれ4つのリングページが有るのです。

LSI Logic :

構造は良く似ています。唯一の違いはハードウェアコントローラに実際のHBAのキューリソースによって上限が設定されていることです。ですが、ドライバーは恣意的にハードウェアが利用できる値よりも低い値で動作するようにします。もし、HBAが言う以上の高い値を設定したとすると、ESXi SCSI mid-layerのキューに行列するのではなく、ドライバ内に行列することになります。この場合、キューの遅延を考慮しなくてはなりません。

結論

さて、ここまででの結論はどうなるでしょうか? 人生における他のすべてと同じように、何を望んでいるかによってマチマチだ、ということになります。私が考えるには出来る限りはPVSCSIコントローラを利用するのが良いということになります。以前の会社では1500台以上の仮想マシンを動作させていました。あるとき、確か2010年だったと思いますが、既に80~90%の仮想化を終え、どこでLSIを利用すべきで、どこでPVSCSIを利用すべきなのかを環境の中で行っていくことは地獄のような作業になるということに気が付きました。加えて、当時のモニタリングツールは今日のものに比べとてもひどいものだったということもお伝えしておきます。結果として私はインフラストラクチャのアーキテクトとして3VMしか起動しないような小さな単独のESXiサーバであれ、集中管理されたデータセンタ内の巨大なERPシステムであれ例外なく全てのテンプレートで同じ構成のPVSCSIを利用するということにしました。既存で稼働していた仮想マシンについてもメンテナンス時間のタイミングで既存のSCSIコントローラからPVSCSIアダプタへの置き換えを行いました。おそらくはI/Oをほとんどしないような小さな仮想マシンにとっては全くメリットはなかったはずですが、I/O要件の高い仮想マシンにとってはもちろん、助けになったはずです。もちろんこれは私の過去の決断です。仮想マシン内のSCSIコントローラを変えるということは大きな労力となりますので、ダウンタイム時に変更するというのは正しい選択だったと思っています。

チューニングを行う一方で、注意しておきたいのは、利用しているストレージシステムのパフォーマンスがどんな様子なのかということです。もしもそうでないのであればこうしたパラメータを変更しても全く変化はありません。数年前まで、私はコントローラもしくはSCSIコントローラのキューデプスを調整することで常にパフォーマンスが改善できると考えていましたが、実際にはストレージシステムとサーバとストレージの間のスタックに依存することがわかりました。もしもキューから溢れてしまったI/Oを処理するものがなければ、多くのI/Oでキューを埋めるということは全く意味をなしませんが、もしもストレージがそれでも高速に動くのであればボトルネックとなっている仮想マシン側の問題にはこれで対処が可能です。ストレージシステムのパフォーマンスが良いとはどういうことか? これは検証や調整の末に見つけ出さなければなりません。もっとも簡単な方法はWindowsのパフォーマンスモニタなどのローカルOSのツールを利用して、平均ディスクキューの長さがアダプタの制限に張り付いていないかを確認することです。さらに、PVSCSIアダプタの数を増やすことで効果があるのはストレージがその取り回しに苦労しているときだけです。以前出来る限り多くのディスクとコントローラにまたがって構成を行い、負荷を可能な限り分散しようとする同僚がいたのを思い出します。ですが、結局はストレージがボトルネックになり、単に構成が複雑になっただけでした。ですから、出来る限り増やすのが良いということではなく、98%のシステムにおいては出来る限りシンプルにしておくのが良いと思います。残った2%はその必要があれば集中して調整を掛けていくのが良いと思います。

もし、ご質問があればどうぞ。

情報ソース、インスピレーション:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1017652
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1010398
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2053145
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1037959
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1267


ブログ:
https://blogs.vmware.com/vsphere/2014/02/vscsi-controller-choose-performance.html
https://pelicanohintsandtips.wordpress.com/2015/09/23/vmware-paravirtual-scsi-adapter-pvscsi/
https://clearwaterthoughts.wordpress.com/2011/05/06/virtual-scsi-adapters-vs-para-virtual-scsi-pvscsi-adapters-vs-vm-direct-path-io/

記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw) 今後は (@Networld_NTNX)

さて、前回はカーネルの中のお話でしたが、今回はVMwareが提供している準仮想化ドライバを利用して仮想マシンのI/Oをチューニングしていくと言う話です。結果としてはPVSCSIに落ち着くということなのですが、SCSIドライバの中の話(リングページやキューデプス、またはIOの合成)などは特に理解せずに利用していた方が多いのではないかと思います。

この話を翻訳しようとしたのは「カーネル vs ユーザーモード」の話を宗教戦争ではなく掘り下げて理解していただきたかったことと、例えば、途中のPVSCSI(準仮想化ドライバ)の図のように、PVSCSIを利用すればVMMを経由せずにダイレクトにI/Oを実行できることなどを知った上で、議論に参加してほしいからです。VSANやPernixData(今はNutanix) FVPはVMMからコンテキストチェンジを発生させずにI/Oをフラッシュ(FVPの場合はメモリにも)に届けることでデータパスを短くしていますし、NutanixのCVMは今回ご紹介したようなテクニックを利用してデータパスを短くしています。どっちがいいのか? Guidoさんが言うように人生における他の全てと同じく、目指しているもの次第なわけです。

3回に渡ってGuidoさんの記事を翻訳し、カーネル vs ユーザーモードの話、特にI/O周りのアーキテクチャの話をしてきましたが、次回はI/O周りだけではなく、ソリューション全体での比較を取り上げたいと思います。

Stay Tuned!

2016/09/28

VMware ESXi ストレージ IO パス

本記事の原文はもともとPernixData社のTechnical Support Engineer (TSE)で、現在はPernixData社のNutanix社による買収でNutanix社のSr. Systems Reliability Engineerとして活動を継続しているGuido Hagemann氏によるものです。

VMworld EMEAに参加した際に初めてお会いしましたが、Guidoさんはサポート担当ですので、時間によってはサポートコールを取ってくれて話やメールをした間柄です。

原文を参照したい方はVMware ESXi Storage I/O Pathをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら

私にとってESXiの中をIOがどのように流れていくのは長い間謎に包まれたものでした。もちろん、私はパス選択ポリシー(PSP)がどういうもであるのかや、ストレージアレイタイププラグイン(SATP)がどういうものかということは知っていましたし、vSCSI statsについても聞いたことが有りましたが、それでもI/Oのフローについて深く説明するということは出来ませんでした。仮想マシンから出たI/Oがどうにかしてカーネルに入っていく、というぐらいしか知らないようなものだったのです。それでもESXTOPのようなstatsコマンドで特定のパフォーマンスの値を監視したり、PSPのレベルでベンダーが推奨する通りの設定を行い、パフォーマンスを監視するということは出来ます。そして、そう、RAWデバイスです。これはまた別のストレージプロトコルやキューが登場します。ですが、これは全体でどのようになっているのでしょうか?

このブログの記事はストレージ IO パスについて一定のレベルでの詳細をご説明します。エンジニアリング(製品開発部門)と緊密に動くことの良い点は日々非常に多くの事を知ることが出来ますが、それを自分のものにしていくことが難しくなるのです。ですから、この多くの情報をより深く調べ、最終的にはブログの記事にまとめることにしました。もちろん、ESXi 6 U1にはVAIO(vSphere API for IO Filtering)フレームワークが追加されていますが、これについては別の記事に後でまとめたいと思います。VAIOを利用すればベンダーはユーザーワールドのコンテキストで動作するフィルタドライバーを経由してしっかりとVMwareのコントロール下に置かれたやり方でI/Oに割り込む方法で開発を行うことが出来ます。今日の時点ではVAIOはまだ新しすぎて、殆どのベンダーはVAIOを利用する製品をリリースすることが出来ていません。どうしてこんなことを書くのかって? それはPernixDataの(そして、今はNutanixの)フラグシッププロダクトであるFVPとストレージ分析ソフトウェアであるArchitectはESXiのプラガブルストレージアーキテクチャ(PSA)で統合されています。更にVVOLによってストレージの管理は著しく簡単になろうとしています。ですが、私はテクニカルサポートエンジニアとして日々過ごす中で、VVOLについて考えはじめ、もしくはさらに次のインフラストラクチャが登場するのではないかと考え始めています。VMwareは既にVVOL以前にポリシードリブンストレージマイグレーションで素晴らしい結果を上げており、私の対峙している顧客は十分満足しています。結果として、VVOLについて考えるのが後回しになっているのです。

仮想マシンからの全てのIOはユーザーワールドのコンテキストでvCPU、VMX、MKS、SVGAなどのそれぞれから、異なるスレッド(ワールド)で開始します。ユーザーとカーネルモードのち我について理解するためには私の最初の記事カーネル vs. ユーザーモードをご参照ください。仮想マシン自身のマネージャーはVMM(仮想マシンモニタ)です。

それからIOは基本的にはVMkernelを通じてどんなアクションが行われるか、そのストレージ実装が利用されているかによって様々なジャンクションを通っていきます。

  • Block Storage(ブロックストレージ):
    • Fibre Channel (FC)
    • Internet Small Computer Systems Interface (iSCSI)
    • Fibre Channel over Ethernet (FCoE)
  • File Storage(ファイルストレージ):
    • Network File System (NFS)

すべてのI/OはVMMレベルで開始されるため、ここまではスキップしてvSCSIフロントエンドからのI/Oフローをご説明していきます。I/OがユーザーワールドからvSCSIフロントエンドへ流れていく部分は非常に面白いです。そして、VMXNETやPVSCSI実装などの準仮想化実装とどう違うのかがわかります。

ESXi I/O フロー

  • vSCSI フロントエンド:
    • フラットバックエンド(VMDK)またはRDMバックエンドのIOの両方が流れてきます。
    • それからI/OはFSS(ファイルシステムスイッチ)へと流れ、その後、DevFS(スナップショット関連のI/O)、VMFSレイヤ、NFSレイヤのいずれかへと導かれます。
    • NFSの場合、その後、ESXiのSUNRPC実装とTCP/IPスタックを経由してVMカーネルインターフェイス(vmk)へとI/Oが進んでいきます。
    • VMFSの場合、道はFDS(ファイルデバイススイッチ)へと続き、そこで、ディスク(通常のスナップショットのないI/O)、スナップショットドライバ、またはLVM(ロジカルヴォリュームマネージャー)へと分岐します。
      • ディスク : 通常のVMDKのI/O。
      • スナップショットドライバ : 仮想マシンがスナップショットを発行するか、スナップショット上で動作している場合、すべてのI/Oは再度FSSへと送られ、スナップショットの連鎖はDevFSの実装を通してマウントされます。
      • LVM : ディスクが作成、拡張、結合された場合。
    • I/OはPSA(プラガブルストレージアーキテクチャ)へと進んできます
      • デバイスキューは2つのエリアに別れます:
        • SCSIデバイス
        • SCSI Sched キュー
      • ここへ至ったIOは殆どの場合、NMP(ネイティブマルチパシングプラグイン)かEMCがPowerPathと呼んで提供している完全なプラグイン実装へと流れていきます。今回はNMPのみにフォーカスします。
        • SATP(ストレージアレイタイププラグイン) ストレージシステムとの連携を実現するコントロールプレーン
        • PSP (パス選択ポリシー) ストレージ自身へのI/Oを制御するデータプレーン
      • 最後にI/Oは物理的なHBA、キューイング、SCSIエラーを管理するSCSI Midlayerへと到達します。ESXiのSCSI Midlayerについてもっと詳しく知りたい場合にはこのリンク先のVMware SAN System Design and Deployment Guideの58ページもご参照ください。

以下の図はI/Oフローの詳細をそれぞれのパーツを結合して顕したものです。

Fig028

ESXiのストレージ実装

VMM:

仮想マシンモニタ(x86 CPU、SCSIコントローラをエミュレーション、等)

共有リング:

共有リングはVMMとVMカーネルの間の共有キューで、VMMもしくはVMカーネルの両者はパフォーマンスのペナルティなくこの共有リングへアクセスが可能です。共有リングのサイズは発生させられるI/Oの数を決めてしまいます。VMカーネルが共有リング内のI/Oを見つけるとすぐに、このI/Oをキューから取り出し、vSCSIフロントエンドへと送ります。もっと詳しく知りたい方は以下のKBを参考にしてください。

ソース : VMware KB: 2053145

vSCSI:

VMカーネルのSCSIフロントエンドで、SCSIリクエストと仮想化されたファイルへのI/Oリクエストを送信します。

Flat Backend(フラットバックエンド):

ファイルをエミュレーションします。

RDM Backend(RDMバックエンド):

RAWのLUNへのポインタ/シンボリックリンクです。リンク内に識別子が埋め込まれます。

FSS (ファイルシステムスイッチ):

ファイルシステムのドライバを実装する際に利用できます。APIは公開されていません。

DevFS:

殆どのUNIXベースのファイルシステムと非常によく似ており、実デバイス、非実デバイスをエミュレーションします。

VMFS:

VMFSの3と5の両方を実装した単独モジュール。

NFS:

NFSプロトコルを実装しています。

FDS (ファイルデバイススイッチ - ブロックストレージ):

ディスク、スナップショット、そしてLVMの切り替えに利用されます。

ディスク:

すべてのディスクベースのブロックデバイスをエミュレーションします。ストレージスタックと直接やり取りします。

スナップショットドライバ:

フィルタドライバとして実装されています。フィルタドライバによって、FSSへとIOが戻るため、ディスクが再帰的にDevFSへとマウントされます。

LVM (ロジカルヴォリュームマネージャ):

削除、結合、作成などが発生した場合にはLVMへと司令が送られます。LVMはヴォリュームの結合を行い、論理領域としてヴォリュームを上のレイヤへ見せます。VMFSとしてデータストアをフォーマットすると以下のように動作します:

  • はじめにLVMに論理ボリュームが作成される
  • それから、そのヴォリュームがVMFSでフォーマットされる

このようになる理由はディスクが異なるLUNをまたがって拡張、結合される可能性があるからです。もちろん、再署名 例えば、スナップショットされたLUNでは同一のUUIDが利用されているので、LVMによって再署名される可能性があります。

PSA (プラガブルストレージアーキテクチャ):

SCSI デバイス:

すべてのローカル、そしてリモートのデバイスはSCSIデバイス構造になっています。(ターゲットあたり256以上のLUNは存在し得ない)


SCSI スケジュールキュー:

ストレージスタックは比例型の共有スケジューラ(シェア)を実装しています。SIOC(ストレージ I/Oコントロール)はこれをクラスタベースで行うものですが、SCSIスケジューラーキューを利用しています。シェアの値には全てのSCSIディスクの数が利用されます。

SATP (ストレージアレイタイププラグイン - コントロールプレーン):

ベンダー固有の機能を有しています。例: Trespass : LUNで利用可能なSP(サービスプロセッサ - ストレージシステムのコントローラ)のアクティブ-パッシブを制御します。また、I/Oが異なるSPから流れ込み、そのためにその異なるSPへと接続してI/Oを受けたなどを状態を理解することも可能です。SATPは障害時にもストレージとのコミニュケーションを行います。

PSP (パス選択ポリシー - データプレーン):

PSPはバックエンドのストレージにどのようにReadとWriteを提供するかを司ります。PSPには3つのフレーバがあります : MRU(もっとも直近で利用したパス)、Fixed(固定)、そしてRR(ラウンドロビン)。

  • Most Recently Used (MRU): VMW_PSP_MRUポリシーは利用可能な最初のパスを選択します。このパスはシステムのブート時に検知されます。パスが利用できなくなった場合、ESXi/ESXホストは別のパスへとスイッチし、新しいパスが利用できる限りはそのパスを利用し続けます。これはアクティブ/パッシブのストレージ装置において論理ユニット数(LUNs)の標準ポリシーです。ESXi/ESXは万一、パスが復帰したとしても以前のパスへと復帰しようとはしません。利用している障害が起きないかぎりは、です。
  • Fixed (Fixed): VMW_PSP_FIXEDポリシーは指定された場合にはそのフラグが立っているパスを固定的に利用します。もし指定がない場合、システムのブート時に検知したパスの最初の利用可能なものを利用します。ESXi/ESXがその選択したパスを利用できない、もしくは出来なくなった場合、ESXi/ESXホストは別のパスを選択します。ホストは自動的に事前に定義されたパスが復帰するとすぐさまそのパスへと復帰します。このポリシーはアクティブ/アクティブのストレージ装置を接続したときのLUNsの標準ポリシーです。
  • Round Robin (RR): VMW_PSP_RRポリシーは自動的にパスを選択し、利用可能な全てのパスの中で負荷を分散しながら設定されたパスを利用します。
    • アクティブ/パッシブストレージ装置では、アクティブなコントローラのパスのみがこのラウンドロビンポリシー時には利用されます。
    • アクティブ/アクティブストレージ装置では、全てのパスがこのラウンドロビンポリシーで利用されます。

ソース: VMware KB 1011340

このブログの記事が少しでもあなたのお役に立てば。もちろん質問があれば、いつもどおり気軽にコンタクトください。

記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw) 今後は (@Networld_NTNX)

さて、前回に引き続き、Guidoさんの記事です。VMwareのカーネルの中(といっても、ストレージ部分だけですが・・・)をこんなに解説してくださっている記事はなかなか無いと思いましたので、前回のものと合わせて翻訳させていただきました。前回とは異なって、I/OがESXiの中をどう流れていく?ということを順を追って解説してくれています。さすが、カーネルの中でI/Oを捕まえてぶん回している会社(PernixData/今はNutanix)のサポートチーム・・・詳しい!もちろん、VSANについてはまた上の図の中に別の枝が出て実装されていますし、今後はVAIOでもっと面白い実装も出てくるのではないかと思いますが、あくまでベーシックということで。技術的に深すぎてNutanixもPernixDataもVSANも違いがなくなってきています・・・そんな技術を組み合わせてソリューションを生み出していく各社・・・。そして、我々はそれを理解した上で、お客様に最適なソリューションをご紹介するソリューションディストリビュータです。

次回もGuidoさんのふかーい記事を翻訳予定です。まだまだ続きます。

2016/09/21

カーネル vs ユーザーモード

本記事の原文はもともとPernixData社のTechnical Support Engineer (TSE)で、現在はPernixData社のNutanix社による買収でNutanix社のSr. Systems Reliability Engineerとして活動を継続しているGuido Hagemann氏によるものです。

VMworld EMEAに参加した際に初めてお会いしましたが、Guidoさんはサポート担当ですので、時間によってはサポートコールを取ってくれて話やメールをした間柄です。

原文を参照したい方はKernel vs. Usermodeをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら

私の生まれて初めてのブロク記事へようこそ! この記事はとても前に、ブロクを始めようと思った際に書いたものですが、その時にはいろいろな事情で公開しませんでした。 :) でも、ほら、ようやく公開することが出来ました。記事の内容についてはとても昔の内容から初まります。「ITインフラストラクチャ」という名前の大学の講義で、私がOSのカーネルの深みに初めて踏み入り、CPU内のキャッシュやCPUが実際にどのように計算を行っているとか、もちろんもっと多くの事を知った際の話からです。その時私はOSカーネルの中が非常なめらかで、その一方で非常に複雑であり、時には危険だということに驚きました。例えばメモリの上書き、C言語でのプログラミングで手続き上のオブジェクトが存在しないなどです。もちろん、あらゆるOSのハードウェアを利用するためのドライバーはRing 0で動作しています。ですから、複雑さは実際にはカーネル内で動作しているソフトウェアの機能によって大きく異なります。もちろん、品質についても同じです。さぁ、前置きはこれぐらいにして、記事の中身に入っていきましょう。

オペレーティングシステムは通常は非常に大きなプログラムで、コアコンポーネントはカーネルと呼ばれます。カーネルは全てのハードウェアリソースを司るオーナーでもっとも深いソフトウェアレイヤで動作しており、ハードウェアに直接アクセスを行うことが出来ます。カーネルが行っていることは:

  • アプリケーションへのインターフェイス(API)
  • CPU(中央演算装置)、ハードウェアデバイス、メモリ(スケジューラ、ドライバ、メモリ管理)のコントロール
  • リソースのスケジューリング 例 :アプリケーションの処理時間
  • リソースの構成 例 : ディスクのようなブロック指向のデバイスのファイルシステムへのマッピング
  • リソース競合の解消 例: リソースのキューイング、CPUリソースのロック
  • リソース~プロセッサ(をプロセスへ)、ディスク(をファイルへ)、メモリ(を仮想化メモリへ)~の仮想化
  • ファイルやデバイスのアクセスコントロールの監視

Exokernel、モノリシックカーネル、レイヤードカーネルなどのように、異なる目的に対して非常に多くの種類の異なるカーネルがありますが、それらの詳細の違いについて踏み入ることはしません。今日もっとも利用されている種類のカーネルはマイクロカーネルと呼ばれるものです。マイクロカーネルはすべてのWindowsワークステーション・サーバそして、LinuxをベースとしたOSやVMware ESXiでも利用されています。OSを様々なプロセスに分割、分けていく理由はクライアントが他のOSやアプリケーションでも良くしようというためです。ですからクライアントがリクエストを適切なサーバにメッセージを送信することで実行し、サーバは処理を実行します。マイクロカーネルは結果をクライアントに返します。以下の図にそれを示しました:

Fig026マイクロカーネル

マイクロカーネル固有の特性の幾つかは:

  • OSの一部を容易に置き換え可能
  • ドライバはユーザモードでもカーネルモードでも動作する
  • 物理I/Oアクセスの実装が難しい
  • コンテクストスイッチ(時にはタスクスイッチやプロセススイッチとも呼ばれる。単一のプロセスやプロセスのスレッドが別のCPUへと切り替わること)

ユーザーモード (ユーザープログラムで言う非特権モード) :

全てのユーザープログラムはこのモードで実行されます。ユーザーモードはメモリやハードウェアへの直接のアクセスを行いません。この理由はすべてのプログラムがそれぞれでメモリを書き換えると他のプログラム用のメモリを上書きしてしまい、衝突が起きてしまうからです。ユーザーモードのプログラムは通常はカーネルの観点からは信頼性のないソフトウェアとして取り扱われます。もし、ハードウェアリソースへのリソースが必要な場合にはその下のAPI(システムコール)を経由して手続きが行われます。

カーネルモード (システムモードとも呼ばれる):

このモードは全てのカーネルプログラムで利用されています。カーネルモードではプロセスがその下のすべてのハードウェアに直接アクセスを行います。CPUだけがカーネルとユーザーモードを同時に実行することが出来ます。ユーザーからカーネルモードへのスイッチは自動的に行われ、その際には割り込みが発生します。

マイクロカーネルの詳細への踏み込みはおこなわず、ここでは少々コンテクストスイッチにフォーカスしたいと思います。すべてのプロセスは単一、又は複数のスレッドで実行されます。プログラムはスレッドを利用して事実上の並立実行時間を設け、1つ以上のCPUで実行されます。上で述べたように、マイクロカーネルは全てのリソースを司ります。ですから、もしもプロセスがCPUで動作しようとするととても大きなオーバーヘッドが生じます。既存でCPU上で動作していた環境は以下によって抑制がかかります :

  • プロセスのステータス
  • プログラムカウンタ
  • スタックポインタ
  • ファイルのオープン状態
  • メモリ管理 : 実際の実行環境へのポインタ

メインメモリへの一回のアクセスの全てのステップで、CPU内のこのプロセスのキャッシュは全てが廃棄されます。これはもはや正しいキャッシュではなく、将来的にキャッシュのミスを引き起こすからです。すべてのプロセスがCPUを利用しようとする度にOSのスケジューラーはいつそのプロセスがCPUを利用するかを決め、実際にCPUを利用させるのです。

Fig027プロセスの状態

コンテクストスイッチはカーネル内でしか発生しません。ですから、もしアプリケーションがCPUのプロセスを利用したい場合には、ユーザーモードからカーネルモードへシステムコール経由で移行しなければなりません。ですから、ユーザーからカーネルモードへ恒久的にスイッチするということは非常にコストが高く、多くのCPUサイクルを利用します。カーネル内で直接動作するソフトウェアはオーバーヘッドを著しく減らし、パフォーマンスが向上します。仮想化の世界でのカーネル実装の2つの例は:

  • VMware VSAN
  • PernixData FVP

さぁ、まとめに入りましょう。アプローチの方法はその目的によって様々ですが、一般的には以下が言えるでしょう:

  • カーネルモードのドライバ/ソフトウェアは実際にOSのコアで動作する点や、加えてプログラムの方法も限定されているため非常に複雑ですが、実現できればパフォーマンス面からは非常に大きなメリットが有ります。セキュリティの面から考えても、カーネル内からは外からそれを行うよりはるかに簡単です。
  • ユーザーモードのソフトウェアは非常に強力で、それは安定性の実装が簡単であり、プログラミングフレームワークを数多く選べることからのメリットもあります。ユーザーモードとカーネルモードのソフトウェアを組み合わせた実装も目にすることが有ります。これはカーネルモジュールとのやり取りを必要とするようなケースがあるからです。これはユーザーモードで動作しているコアOS自身のデーモンプロセスなどで見られます。

記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)

いかがでしたでしょうか? OSの中身まで奥深く分け入らない、と言いながらもCPUの中で何が起きているか、などまで解説していますのでなかなかわかりにくいかもしれませんが、一昔前にある種の「宗教戦争」として勃発したインカーネル対仮想化ストレージアプライアンスをこれ以上ないぐらい低いレイヤからみた話としてご紹介しました。まとめのところにあるように、カーネル実装は強力ですが、複雑で、実装も難しい、けれどもパフォーマンスの観点からは大きくベネフィットが有ります。ユーザーモード実装はフレームワークを様々に選択できるため実装が簡単です。裏返しとしてコンテクストスイッチの発生の際にはCPUのキャッシュを廃棄したり、スケジューラーのサイクルを待たなくてはならないこともあります。また、私がとても気になったのは「ハイブリッド」の実装もあるよ、という一文です。

買収直後の記事ですし、深読みしてしまうところもありますが、宗教戦争のような絶対的な決着があるわけではなく、目的によってカーネル、ユーザーモードを使い分けるのが正しいということを覚えておいてください。そして、カーネルモードの実装例として上げられているPernixData FVPは現在はユーザーモードの実装例の代表格であるNutanix社の手の中にあるのです。さぁ、将来が楽しみですね。Guidoさんの記事は非常に深いレイヤからの知識を教えてくれ、いろいろな意味で面白いので今後も翻訳の対象にしていきます。お楽しみに!

2016/09/02

Platform9 OpenStackでの仮想マシンの高可用性

本記事の原文:Virtual Machine High Availability with Platform9 OpenStackの公開は2016年の8月24日です。現時点では機能が拡張されたり、改善されている場合がございますのでご注意ください。

Platform9製品詳細についてはこちら

Platform9について詳しく知りたい方は是非以下のWebセミナーへもアクセスください。

【Webセミナー】Platform9 Managed OpenStack Web&デモセミナー
話題!日本上陸直後のPlatform9 Managed OpenStackを徹底解説 & デモを実施

昨年、OpenStack Summit 東京での開催、先日開催OpenStack Summit Days Tokyo 2016の大成功、大規模な導入事例発表など、OpenStackの熱気はいよいよ日本国内へも押し寄せてきています。
しかし、OpenStackはオープンソースプロジェクトでそのものはフリーで提供されていますが、そもそもインストールが難しい、運用管理していく手間とコストが膨大になる、アップグレードがうまくいかないなど、一般的な企業のお客さまにとっては多くのハードルを抱えています。

本セミナーではOpenStackの5つの展開方法とそのメリット・デメリットを上げた上で、
Platform9社が提供するユニークなOpenStack-as-a-serviceについてご紹介致します。
これまでになかったアプローチでのOpenStackの利用開始、運用、そしてその効果についてあますところなくお伝え致します。
本セミナーへご参加方にのみ、Platform9 Managed OpenStackのフリートライアルアカウントをお渡し致します。是非奮ってご参加ください。

https://networld.smartseminar.jp/public/seminar/view/666

エンタープライズのためのあらゆるクラウド商品において、仮想マシンの高可用性(HA)はアプリケーションの可用性をインフラストラクチャの障害時にも維持するためになくてはならない機能です。高可用性を高所してクラウドを設計すればクラウドネイティブなアプリケーションだけでなく、従来型のアプリケーションの障害からの保護にも役立ちます。これまで、HAの機能はVMwareやHyper-Vなどといった、仮想化インフラストラクチャだけのものでした。Platform9 Managed OpenStackを利用することで同じ機能をKVM環境においても利用できるようになりました。

モダンアプリケーションは複数階層のアーキテクチャとデータ共有で障害時にも一貫したパフォーマンスの提供を保証します。アプリケーションはスケールアウト、もしくは負荷状況に応じて拡張することが可能になっています。各々のインスタンスの障害は大抵はモダンワークロードに影響をあたえることはありません。しかし、大規模なデータセンタの障害ともなると、こうしたアプリケーションの可用性にもまだ影響をおよぼすことが有ります。クラウドスケールのデータセンタはこうしたハードウェアの障害も考慮して設計されているべきなのです。OpenStackでは管理者が障害ドメインを指定して、可用性ゾーン(AZ)を構築することが出来るようになっています。Platform9 manged OpenStackはこうした障害から、クラウドネイティブアプリケーションを複数のAZにわたってワークロードを配置することで保護することが出来るようになっています。

従来型のアプリケーションはインフラストラクチャが常に利用できることを前提としています。アプリケーションのアーキテクチャはハードウェアの障害に耐性をもちません。仮想マシンやハイパーバイザーの障害はこうしたアプリケーションの可用性に影響を及ぼします。Platform9 managed OpenStackを利用すれば、こうしたアプリケーションをもほぼすることが可能です。もしアプリケーションの仮想マシンがクラッシュしたり、その下のハイパーバイザーノードがダウンした場合、こうした仮想マシンはPlatform9のHA機能によって新しいホストを再割当てすることが出来るのです。

クラウドネイティブアプリケーションを保護する

Platform9 Managed OpenStackでインフラストラクチャ管理者とアプリケーション開発者は大規模なハードウェア障害に備えることができます。データセンタの設計によって、AZはサーバのシャーシであったり、ラックであったり、データセンタ環境全体であったりします。アプリケーション開発社はクラウドネイティブアプリケーションをAZの障害に耐性を持つように設計することが出来ます。

OpenStackはクラウド対応アプリケ-ションをリソースの利用状況に応じて自動的に拡張させるためのオートスケーリンググループを構築することが出来るようになっています。Platform9のHA機能を用いれば、オートスケーリンググループに可用性ゾーンの要件を追加することも可能です。例えば、以下のテンプレートは可用性とともにオートスケーリンググループはを記述したものです。

Fig009可用性ゾーンを組み込んだHeatテンプレート

heatテンプレートはアプリケーションのスケールアウトの青写真を記載したものです。複数のインスタンスにまたがるワークロードが増加すれば、それに応じて追加でアプリケーションのインスタンスを展開します。Platform9では、開発者は可用性ゾーン(AZ)を指定してアプリケーションのインスタンスを展開することが出来ます。AZは"availability_zones"というプロパティにコンマで区切られたリストとして指定することが出来ます。Platform9 Managed OpenStackはアプリケーションのインスタンスがテンプレートで指定されたAZに最低1つずつ展開されることを保証します。以下の様な障害イベントに対応がなされます。

  • AZ内のホスト障害 : 同じAZの内の別のホストで新しいアプリケーションのインスタンスが開始される
  • AZ全域に及ぶ障害 : 他のAZ内のアプリケーションのインスタンスがユーザーリクエストに継続対応、クラウドネイティブアプリケーションとしては動作に影響が出ない

従来型アプリケーションを保護する

Platform9 Managed OpenStackはHAを従来型アプリケーションに拡張します。AZは古くからのアプリケーションの保護を構成するためにも利用ができるのです。クラウド管理者は以下のようにして可用性ゾーン上にHAを有効にすることが出来ます。

Fig010Platform9で仮想マシンのHAを管理

仮想マシンを障害ホストから復旧するためには共有ストレージが必要です。HAクラスタに参加する全てのホストは同一の共有ストレージに仮想マシンに固有のストレージパスを利用して接続することで、ノード障害時に適切に仮想マシンを復旧することが出来ます。OpenStackの可用性ゾーンにHAを有効にするため、Platform9は可用性ゾーン内のすべてのKVMホストに分散クラスタリングサービスを展開します。クラスタリングサービスはGossipプロトコルを利用してクラスタ内のすべてのノードの死活を監視します。従来からのハートビートを利用したノードの健全性の監視を行うアプローチと比べ、分散クラスタは以下の様な利点があります。

  • Gossipプロトコルはハートビートベースの手法に比べ、確実にそして素早く障害を検知、仮想マシンのダウンタイムもより短くなる
  • ネットワークパーティション(分断)のようなわかりにくく、ハートビートでは検知できない障害も検知

ホスト障害発生時にはそのホストは隔離され、クラスタから切り離されます。以下に示したように、そのノードで動作している全ての仮想マシンは同じAZ内の他のノードで再起動されます。

Fig011障害時の仮想マシンの避難

AZのサイズと起こりうる仮想マシンの障害の数によって、障害ホストの仮想マシンを復旧するための予備のキャパシティを展開しておく必要があります。

Platform9は分散クラスタを自動的に管理することが出来ます。障害時に手動で構成を行う必要はありません。クラスタはAZにハイパーバイザーのホストが追加されたり、削除されたりする毎に自動的にメンテナンスされます。まとめです。Platform9 Managed OpenStackは現在企業に必要とされるHAの機能を一元的に提供することが出来ます。クラウド対応のみならず、古くからのアプリケーションのための固有のHAの要件に応えることが出来るようにし、ワークロードの可用性について不安を抱えることなくクラウドへ簡単に移行できるようにしてあります。このHAの機能についてのデモは以下のビデオを御覧ください。

記事責任者 マーケティング本部 三好哲生 (@Networld_pf9)

2016/08/30

VMworld 2016 Day1 General Session 国内最速レポート

皆さん こんにちは
5年連続5回目のVMworldに参加中の工藤です。
今年は私から現在開催中のVMworld 2016の初日のGeneral Sessionの速報をお送りします。

Image_2

このままクラウドの普及が続くと2021年に漸くトラディショナルなインフラが50%になる予測を披露しました。

Image

そんなクラウドとオンプレミスが共存するIT基盤においてFreedom とControlの両立を実現するHybrid Cloudを提供するのがVMwareのミッションであると発表されました。

そんなHybrid Cloudを実現するCross Cloud Archtectureとして以下のような発表がありました。

  • 統合基盤ソフトウェア「Cloud Foundation」の発表
  • マルチクラウド管理のSaaS「Cross-Cloud Services」の発表

今回は統合基盤ソフトウェア「Cloud Foundation」について紹介してみたいと思います。

■「Cloud Foundation」の発表
ITmediaの三木さんが既にこちらで紹介されていますが、最近のトレンドであるHyper Coverged Infrastructureの新しいモデルとして「Cloud Foundation」が発表されました。既にこちらに製品ページから発表された内容を確認することができます。

■「Cloud Foundation」って何?

「Cloud Foundation」は一言でいうと、vSphere + Virtual SAN + NSX + SDDC Managerで構成されたソフトウェア群の名称です。従来「EVO SDDC」として提供されていたものを置き換えるものとなります。以前のEVO:RAIL、現在のVSAN Ready NodeやEMC VxRAILのようなアプライアンスはvSphere + VSANだけの統合でしたが、NSXまで統合されることによってネットワークまで含めた提供のなっている点が異なります。Hyper Converged Infrastructure業界のリーダーであるNutanix社の掲げる「Enterprise Cloud」のビジョンとも似ていて、パブリッククラウドのようにシンプルにするにはオンプレミスのインフラもシンプルにする必要があり、それをソフトウェアで実現するVMware社のソリューションともいえるのはないでしょうか。

■「Cloud Foundation」ってソフトウェア単体で構築するのと何が違うの?

「Cloud Foundation」で追加された「SDDC Manager」は現在のところ物理リソースを管理して、サーバ仮想化の基盤(VI)と仮想デスクトップの基盤(VDI)を裏で展開を自動化し用途に応じて払いだすことができるそうです。そして展開されたソフトウェアコンポーネントを含むソフトウェア群のアップデートのライフサイクル管理が提供されます。

Sddcmanager_2

また今後Cloud FoundationがvRealize AutomationやvRealize Business、Integrated OpenStackに対応してDevOPSの基盤やvCloud Foundationのコスト管理などの機能追加がされる予定です。

Sddc

■「Cloud Foundation」はどうやって提供されるの?

今までのHyper Converged Infrastructureに対するVMware社のアプローチ同様VMware社からはソフトウェアだけを提供し、エコパートナーからHyper Converged Infrastructureとして提供される形をとっています。現在3つの提供形態が予定されています。

  1. 統合アプライアンスとしての提供
  2. Ready Nodeの提供
  3. パブリッククラウドとの連携

統合アプライアンスとしてはEMC社よりVCE VxRack1000 SDDCとして提供がされる予定です。Ready NodeとしてDELL社、HPE社、Quanta社より提供がされる予定です。そして最後のパブリッククラウドとの連携ではIBM Softlayer上で提供された後、vCloud Air、vCloud Air Networkが追加されていく予定です。

■まとめ

Cloud Foundationを実現することで、オンプレミスとパブリッククラウドをまたいだハイブリッドクラウドを実現することができるようになります。今回のGeneral Sessionで発表されたCross Cloud Serviceもこうした基盤がある前提になるような気がしています。オンプレミスのインフラをシンプルにするCloud Foundationに皆様ご注目ください。

また9/14,18にVMworldの内容をまとめてわかりやすく解説するフィードバックセミナーを予定しております。興味のある方は是非こちらにいらっしゃってください。

VMworld 2016 フィードバックセミナーhttps://networld.smartseminar.jp/public/seminar/view/668

次回はこのCross Cloud Serviceについて紹介していきたいと思います。

2016/08/10

HyperFlexのバックアップはVeeamにお任せ!

先月、弊社ではCisco HyperFlexとVeeamの共同セミナーを全国4拠点で開催し、ニュースサイトでも紹介されました!
http://biz.bcnranking.jp/article/news/1607/160711_142672.html

そこで、セミナーにご参加いただいた方には重複する内容になりますが、今回はVeeam Backup & Replicationを使用したHyperFlex環境のバックアップについてご紹介させていただきます。


①  HyperFlexとは?

こちらでご存じの方もいるかもしれませんが、今年3月に発表されたCiscoのハイパーコンバージドインフラ製品で、Fabric Interconnect + UCSサーバのハードウェアで構成され、SDS(Software Defined Storage)+管理ツールが含まれます。SDSはSpringpathのものを使用しており、重複排除と圧縮が標準機能になっています。

Hxveeam1

②  何故、HyperFlex+Veeam?

HyperFlexはVMwareの仮想環境に特化したハイパーコンバージドインフラ製品であり、Veeamも仮想環境に特化したバックアップ製品で相性ピッタリの組み合わせです。また、HyperFlexはUCSのノードを追加することでスケールアウトに対応できますが、Veeamもバックアップ処理を行うプロキシサーバやバックアップ保存先となるリポジトリを追加することでHyperFlexにあわせてスケールアウトに対応できます。

Hxveeam2_2これは弊社の勝手な思いつきの組み合わせではなく、Cisco社とVeeam社はアライアンスが組まれており、既に海外ではHyperFlexとVeeamがセットになったアプライアンス製品も販売されています。

https://www.cisco.com/c/dam/en/us/products/collateral/servers-unified-computing/ucs-c-series-rack-servers/whitepaper-CiscoVeeam.pdf

Hxveeam3_2

③  VeeamでHyperFlexをバックアップしてみよう!

物理のVeeamサーバを用意して、NBDモード(10Gネットワーク経由)で、1つのバックアップジョブで仮想マシン(Windows 2012 R2/100GBのVMDK)を1台/2台/3台/6台/9台/12台と台数を変えて、HyperFlex上の仮想マシンをバックアップしてみました。

【検証構成】

Hxveeam4_6

Hxveeam4a_5 

その結果が下の表です。

Hxveeam5

注:

※バックアップ時間は3回実行しての平均値になります。

※仮想マシンはHyperFlexのクローン機能を使用して用意しました。

※仮想マシンは起動した状態であるため、バックアップ容量はログなどにより差異があります。

※仮想マシンは各ESXiホストに均等に配置しております。(例)12VMの場合は、1ESXiホストに4VM配置

※プロキシサーバの同時タスク数(デフォルト:2)、リポジトリの同時タスク数(デフォルト:4)、データストア毎のスナップショット数(デフォルト:4)の制限は解除しております。

※弊社の検証環境での値であり、全ての環境で同等の数値が出ることを保証するものではありません。

 

1台だけでバックアップした時間(4分弱)も十分早いですが、台数を増やしていくことで、1VMあたりの時間が一層短くなっていきました。6台以上の場合は、なんと!1VMあたり、1分を切る高速バックアップです!!Thin DiskとThick Diskも数秒程度の違いしかありません。

SpringpathのSDSが重複排除・圧縮が標準機能ということで、バックアップ(読み取り)に時間がかかるのでは?と心配した方もいるかもしれませんが、安心してください。こんなに高速にバックアップすることができます!! 

あまりのバックアップの速さに信じられない方は、下記の無償の製品評価版で試して、第3者の厳しい目で判断してください。

Veeam Backup & Replication製品

Veeam製品評価版入手手順

評価ガイド(日本語版)

HyperFlex+Veeamは安心・確実な組み合わせです。日本でHyperFlexとVeeamの両方を販売できるのはネットワールドだけですので、HyperFlexのバックアップを検討している方は、お気軽に弊社までご相談ください。HyperFlexに限らず、ハイパーコンバージドインフラ環境のバックアップにお悩みの方からのご相談もお待ちしております。

担当:臼井

2016/05/02

VMware VDPの実測値。。。

Q:VMware VDPの重複排除率はいかほどのものか?

A:環境によって異なるので試してみてください。

このようなやりとりは頻繁にありますよね。

まあ、そうなんですがバックアップ対象がOSをインストールしただけの状態であれば"環境によっ

て異なる"ということも最小限の誤差の範囲に収まると思いますので試してみました。

VDPのバージョンはvSphereDataProtection-6.1.1です。

バックアップ対象は以下の通りです。

下記のプロビジョニングポリシーで作成したWindows2012R2 と CentOS6

Thick Lazy Zeroed

Thick Eager Zeroed

Thin Provision

各OSのディスクサイズと使用容量は下記のとおりです。

各プロビジョニングポリシー共にOSが認識する使用領域は同じです。

Win2012r2

Centos6

バックアップ前のVDPの使用容量は下記のとおりです。536GBですね。 

Vdp_2

バックアップ後に536GBから減った容量がバックアップに使用された容量ということになります。

各種2回ずつバックアップを実施しますが、1回目と2回目の間にデータ更新は一切行いません。

1)Windows2012R2 Thick Lazy Zeroed を2回バックアップしてみました。

Photo_9

1回目のバックアップ後の容量

1a

2回目のバックアップ後の容量

2b_4

OSの使用容量が8.96GBに対して1回目のバックアップに使用されたストレージの容量は

4.9GBでした。2回目のバックアップに必要な容量はゼロでした。

VDPの容量は2回目のバックアップのあと1バイトも変化しませんでした。

2)Windows2012R2 Thick Eager Zeroed を2回バックアップしてみました。

Photo_6

1回目のバックアップ後の容量

2b_52回目のバックアップ後の容量

2b_6Thick Lasy Zeroedと同じ結果でした。

3)Windows2012R2 Thin Provisionを2回バックアップしてみました。

Photo_11

1回目のバックアップ後の容量

W3_22回目のバックアップ後の容量

W32

Thick Lazy Zeroed,Thick Eager Zeroedと同じ結果でした。

4)CentOS6  Thick Lazy Zeroed を2回バックアップしてみました。

Photo_121回目のバックアップ後の容量

1_2

2回目のバックアップ後の容量

2b_7

OSの使用容量が4.2GBに対してバックアップに使用されたストレージの容量は2.4GBでした。

1回目と2回目では1バイトも変化しませんでした。

5)CentOS6  Thick Eager Zeroed を2回バックアップしてみました。

1回目のバックアップ後の容量

Photo_14

2回目のバックアップ後の容量

2b_8

Thick Lasy Zeroedと同じ結果でした。

6)CentOS6  Thin Provision を2回バックアップしてみました。

Photo_16

1回目のバックアップ後の容量

B

2回目のバックアップ後の容量

2Thick Lazy Zeroed,Thick Eager Zeroedと同じ結果でした。

最後に3種のWindowsとCentOSを同時にバックアップしてみます。

Window 8.96GB×3台

CentOS 4.2GB×3台

合計39.48GB です。

All_3

E

1回目のバックアップ後の容量

C_2

2回目のバックアップ後の容量

F

合計39.48GBのバックアップに要したVDPの容量は1回目は14GB、2回目はゼロでした。

VDPに必要なバックアップ容量の算出にお役に立てれば幸いです。

唐突に話は変わりますが、現行のVDPはVDPAの機能が統合されましたので、従来のVDPAの機能(DataDomainとの連携等)を利用可能です。

担当:磯前

実況中継!? VSAN 6.2 中の人によるふかーい話 (パフォーマンス編・後編)

みなさん、こんにちわ。本記事は「実況中継!? VSAN 6.2 中の人によるふかーい話」の続編にあたります。

以前の記事はこちらです。

本記事はTech Field Day主催のイベントStorage Field Day 9内で2016年3月18日に実施されたVMware社のStorage & AvailabilityのCTOであるCristos Karamanolis氏のプレゼンテーションの録画から様々な情報を抜き出したものです。妙にマニアックな質問もありますし、実装手法をどう選んだかについてもCTO自ら意見しているケースも有りますので興味のある方は是非ビデオもご覧になってください。

実況中継というか、なんというか、ビデオから文字を起こしていますのでなんとなくゆる~い感じになってしまっていますが、内容はかなり濃いです。濃すぎてあえて文字にしなかった部分もありますので、そこは生のビデオを御覧ください。こちらの記事は雰囲気も含めてお楽しみいただければ幸いです。ベンチマークソフトを利用しての検証結果が中心ですので、重複排除や圧縮が特に聞きやすいテストになっていたり、ということもありますので、あくまでご参考としてご理解いただければ幸いです。

障害発生時のパフォーマンス

上手く動いている時の話はすべてお話してきました。ここからは壊れた時の話です。

Fig397

非常にシビアな状況を作り出しました。Writeキャッシュが埋まってしまうような負荷をかけ続けました。これには一定の時間(今回の場合60分)がかかります。Writeキャッシュが埋まってしまうと、デステージ(キャパシティディスクへのデータの書き出し)が始まります。これを表しているのは青のラインです。一貫したパフォーマンスが出ていますが、デステージが並行して走ることで少しガタガタしています。これがベースラインです。さて、障害を起こします。デステージが始まった瞬間、ホストを落とします。

念のためですが、今回はDVD Storeを利用していますですのでこの縦軸はユーザーが実際に体感するアプリケーションのOPM(毎分の処理数=多いほどパフォーマンスが高い)です。また、Y軸の一番下は0ではなく100で、通常状態では160の数字が出ています。

障害が発生した直後、一時的に158から112ほどまで低下しますが、130~140ぐらいに安定します。この間隔が落ちたホスト上にあったデータを生き残ったホスト内のデータから復元している期間です。この時に発生した再同期のためのトラフィックがグレーで表示されています。

ここで言えるのは一時的にパフォーマンスが劣化しますが、上手く保てています。最大でも25%しか劣化しませんし、殆どの期間は10%程度の劣化で済んでいます。

そして再同期が終わればオレンジのラインは標準のガタガタに戻っています。これはDVD Storeのワークロードでデータベースがどんどん膨らんでいるため、デステージが常に行われている状態だからです。

VSANはシステム内に分散スケジューラーを持っており、再同期のための帯域が25%未満になるように調整するようになっています。うまいことにちょうどこの例でも25%でしたね。とにかく、通常のIOのためのトラフィックを出来る限り邪魔しないようにしています。つまり出来る限り早く再同期を終わらせるということと、アプリケーションへの影響を最小にしようという2つのトレードオフを行っているのです。

会場より : どっちを優先したいというユーザーが居るのではないですか?

そのための詳細設定を提供しています。標準は20か25ですが、変更できます。

ビジネスクリティカルアプリケーションでのパフォーマンス

驚くべきことに、今日VSANで最も広く利用されているアプリケーションはビジネスクリティカルアプリケーションなのです。SAPやMicrosoftやOracleですね。様々なホワイトペーパーを提供しており、多くのお客様環境で利用されています。SAPとは緊密に活動しており、SAP HANAの認定検証を行いましたが、VSANはそれをすべてクリアしました。公に書くことは出来ませんが、レイテンシは600~650マイクロ秒程度でした。

Fig398

これはOracle RACの実際のワークロードで、4ノードのハイブリッド構成での結果です。私だったらオールフラッシュで構成しますが・・・まぁ、見てみましょう。 Oracle RACでそれぞれのノードで1台ずつ仮想マシンが動作しています。パフォーマンスは素晴らしいです。平均で287,000TPM(毎分処理されるトランザクション数)で、最大で331,000TPMを記録しています。これは非常に嬉しいことです。ハイブリッド構成であっても一貫したパフォーマンスが得られていることの証ですから。また1ノードだけでは155,000TPMだったトランザクション数も4ノードで287,000TPMまでスケールしています。

ストレッチクラスタでのパフォーマンス

多くの顧客はこうしたアプリケーションをストレッチクラスタで動作させています。理由は高い可用性を得たいがためです。ストレッチクラスタはどのようにパフォーマンスに影響するのでしょうか?

Fig399

今回も前のスライド(Oracle RAC)とお同じベンチマークを利用しています。Oracle RACによるSwingベンチです。正確なノード数を忘れてしまいましたが、ベースラインとしては同じデータセンタ内での値、1msのレイテンシのストレッチクラスタ、2.2msのストレッチクラスタ、4.2msのストレッチクラスタを比較しています。TPS(毎秒のトランザクション数)はそのレイテンシに対して、妥当なレベルでの劣化が見えています。つまり、データセンタの距離に応じてパフォーマンスにペナルティが生まれているということです。いわゆるメトロクラスタの距離であればラウンドトリップタイムは1ms程度でしょう。その環境ならもともとの環境の80%のパフォーマンスで利用が可能です。そして、RPOはゼロです。障害時にデータを失うことはありません。

いかがでしたでしょうか?キャパシティ・パフォーマンス、ストレッチクラスタと優れた技術がふんだんに盛り込まれたVSANはなんとただのx86サーバで動作するのです。まさにストレージの革命ですね。また面白い内容があればご紹介していきます。

記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)

2016/04/27

ネットワールド、Veeam 始めるってよ

 弊社では色々なメーカーのバックアップソフトを扱っておりますが、この度、新たなメーカーのバックアップソフトが加わることになりました。そのメーカーとは Veeam Software です!下記のプレスリリースで発表されています。

https://www.veeam.com/news/veeam-expands-into-japan-to-deliver-availability-for-the-always-on-enterprise.html

そこで、今回はVeeam Softwareとバックアップソフトをご紹介しましょう。

 

①  Veeam Softwareとは

Veeam社の本社はスイスのバールにあり、仮想環境向けデータ保護と監視ツールを提供するソフトウェアベンダーです。2006年の設立から約10年が経ちますが、売り上げと顧客数を急速に伸ばしています。

Veeam01

②  主力製品について

主力製品はデータ保護製品のVeeam Backup & Replicationと監視ツールのVeeam ONEです。また、この2つがセットになったVeeam Availability Suite もあります。

Veeam03

Veeam Backup & Replicationはバージョンアップを重ね、ユーザーが望む多くの機能を実装してきました。そして、今年1月には新バージョンとなる v9 をリリースしています。

Veeam04_3

 

③  特徴的な機能

この製品が他のバックアップソフトと何が違うのかが気になると思います。細かな違いは多々ありますが、特徴的な機能をいくつかご紹介します。

 (1)ストレージ・スナップショットとの統合
vSphereの仮想マシンのバックアップでは、vStorage API for Dada Protection(以下、VADP)を使用しますが、VADPによるスナップショットではバックアップ中の変更量に応じてログファイルのサイズが大きくなっていくため、バックアップ時間が長くなった場合や変更量が多い場合はスナッショット領域が肥大化してしまいます。

また、スナップショットを削除する際にはマージ(結合)処理が伴いますが、ログファイルが大きくなると、マージ処理に時間がかかったり、不安定になることもあります。

Veeam Backup & Replicationでは、この問題を解決するためにストレージ(NetApp,HP StoreVirtual/StoreServ,EMC VNX/VNXe)とのスナップショット連携機能を提供しています。vSphere上でスナップショットを作成した後、ストレージのスナップショットを作成し、すぐにvSphere上のスナップショットを削除することでスナップショットを保持する時間を短くすることができます。

Veeam05

更に、NetAppのストレージの場合、SnapMirror/SnapVaultと連携することが可能で、SnapMirrorのレプリケーション先・SnapVaultのバックアップ先からバックアップすることでプライマリストレージに影響を与えることなくバックアップできます。vSphere のデータストアとしてNetAppを利用している方には最適です。

Veeam06

ちなみに、次期バージョン(9.5)では、Nimble Storageとのストレージ連携ができるようになる予定ですので、ご期待ください。
https://www.veeam.com/blog/integration-nimble-storage-veeam-availability-suite.html

 (2)アプリケーション対応
VADPでのバックアップはエージェントレスでのバックアップになりますが、VeeamBackup & Replicationはアプリケーション(Active Directory,MSSQL,SharePoint,Exchange,Oracle)を意識したバックアップが可能です。他社のバックアップ製品でも同様の機能を提供しているものはありますが、VMware ToolsのVSSに依存していたり、仮想マシンへエージェントのインストールが必要になります。

それに対して、VeeamBackup & Replication VMware ToolsのVSSインテグレーションコンポーネントは使用せず、Veeamが独自実装したMicrosoftのVSSインテグレーションを使用し、エージェントレスでのアプリケーションを意識したバックアップが可能です。 

Veeam07 

また、VADPのバックアップからのアプリケーションのオブジェクト単位のリストアに対応しているバックアップソフトはいくつかありますが、MS SQL Serverについては、テーブル単位のリストアのリストアも可能で、更に他社ではまだ実現できていない?Oracleのリストアにも対応しています。

 (3)重複排除ストレージとの連携
Veeam Backup & Replicationのバックアップデータ先(リポジトリ)としては、Windows・Linux・NAS(CIFS)・テープなど多くの種類に対応していますが、その中でもバックアップのパフォーマンスが良いのが、EMC DataDomainやHP StoreOnceの重複排除ストレージと組み合わせた場合です。

EMC DataDomainやHP StoreOnceをCIFSとして利用しても良いのですが、Data DomainのDD BoostやStoreOnceのCatalystといったソースサイド重複排除機能を利用すれば、プロキシサーバ上で重複排除を行い、重複排除された(最適化された)データのみをバックアップストレージに送信することで、低速リンク経由でもバックアップデバイスへ高速にデータを送信できます。

Veeam09

通常、DD BoostやStoreOnce Catalystを使う場合は専用のPluginを各メーカーのサイトからダウンロードしてインスト-ルする必要がありますが、Veeam Backup & ReplicationはPluginが予めインストールされていますので、すぐに利用することができます。

尚、Data DomainはDDOS 5.4~5.7まで、StoreOnceはOS 3.13.1以降が対応しております。
https://helpcenter.veeam.com/backup/vsphere/system_requirements.html#target

 (4)セルフサービス機能

日々のバックアップは管理者がスケジュールでバックアップしていても、仮想マシンやその中のファイルをリストアすることになった場合、ユーザーが管理者に連絡してリストアしてもらうのは、管理者・ユーザーのどちらにとっても手間のかかる作業です。

Veeam Backup & ReplicationはEnterprise Managerでのセルフサービスによるリストア機能を提供しています。セルフサービスによりユーザーは専用のリストアポータルサイトにアクセスすることで、仮想マシン単位・ファイル単位・アプリケーション単位のリストアが可能になり、管理者・ユーザー両者の負荷を軽減させることができます。

Veeam10

 

④  価格体系

ライセンスはCPUソケット単位の課金でStandard/Enterprise/Enterprise Plusの3つのエディションと小規模環境向け(6ソケットまで)のEssentialsがあります。エディションによって使える機能が異なり、例えば、前述のストレージ連携をする場合は、Enterprise Plusが必要になります。

※エディション比較表

https://www.veeam.com/jp/backup-version-standard-enterprise-editions-comparison.html


以上、今回は簡単にご紹介させていただきましたが、他にも色々な魅力的な機能がありますので、仮想環境のバックアップにお悩みの方やVeeam製品が気になって夜も眠れない方は、下記までお気軽にお問合せください。

Email :veeam-info@networld.co.jpPropartner_logo_distr_img

担当:臼井