« 2016年9月 | メイン | 2016年11月 »

2016年10月

2016/10/27

ランサム[身代金ウィルス]ウェアの対策してますか?

身近な言葉になってきた”ランサム[身代金ウィルス]ウェアですが、企業でもアンチ・ウィルスソフト(セキュリティ対策ソフト、振る舞い検知、隔離用のサンドボックスなど)の導入で防御し対策を行っており、セキュリティの面で語られることが多いと思います。

ただ、セキュリティ対策ソフトからすると、常にパターンファイルの更新を行い、おかしな振る舞いを監視する事象を追いかける形になっています。 つまり、新種が出ると、対策についてはイタチごっこ、盾と鋒で新たな攻撃を受けた後の対策となり、即席では直らず時間が掛かることになります。 また進入の経路も多岐(メール、Webアクセス、ファイル転送)に渡り、その対策についての労力も馬鹿にならないものになります。

初期のウィルス・ソフトは悪戯が主目的で、悪意があってもウィルス・ソフト製作者の技量を見せつけるタイプのソフトが多くありましたが、2000年以降のウィルス・ソフトは企業内で問題となる事象(サイト攻撃やスパムメールの踏み台)が増えて来ました。また、サーバやPCに影響を及ぼし、業務に支障がでるようなウィルスも多くありました。昨今のウィルス:特にランサムウェアと呼ばれるものは、ファイルを暗号化することやPCを起動させなくすることで身代金を要求するウィルスであり、1回に要求される金額が小額(平均300米ドル)であっても、デジタルの環境(ビット・コインによる金銭授受)が整っていることもあり、不特定多数に対して金銭要求することでビジネス(ウィルス開発者が儲ける)になっている事が大きな違いであり、1件あたりの被害額は少なくても多数の被害の積み上げで被害額が拡大している事や特定が難しいのが特徴です。 

また、暗号化されたファイルやシステムが立ち上がらないような状態から、自力で元通りに復旧させるには時間も能力も必要です、その費用や労力の割には、要求される金額が小額であることから、一番の解決策が身代金を払う事と言われています。

セキュリティ対策としてアンチ・ウィルスソフトを導入するのは、個人でも、企業でも一般的だと思います。 ただ、アンチ・ウィルス対策は、最後の砦、突破されたらおしまいです。

それ以前の対策として、バックアップ有用性を考えてみてください。 以外と端末のバックアップは個人に任せていることが多くないでしょうか? やはり、怪我や病気、車の事故に対応した保険と同じく、データの保険は、やはり転ばぬ先の杖であるバックアップ(データ・コピー)が対策として有効な手段だと考えます。

ランサムに関しては個人の端末(スマフォ、タブレット)に波及するケースが多く、被害の範囲は狭いものの個人には打撃の大きいものとなります。 攻撃されても補える力(データの2次コピー)を持っていれば、余計なお金(身代金)を払わずに済み、被害の拡散防止にも役立ちます。

データのバックアップは、利益を生み出すことが無いですが、皆さんの心に安心を与えてくれます。 無くなって困らないデータであればコピーは必要ないですが、大事な個人のデータや企業のデータの消失対策としてのバックアップと、アンチ・ウィルスソフトとの2段階で防御/対策するのが望ましいでしょう。

バックアップもサーバ向けのバックアップ・ソフトだけではなく、PCや個人端末に対応したバックアップ・ソフトもあります。

是非、弊社のランサムウェア対策をご覧ください。

ランサムウェア対策: http://www.networld.co.jp/solution/ransomware/

Edit by :バックアップ製品担当 松村・安田

2016/10/26

Salle Designより: Nutanixの事例 ~Nutanix Prismが生まれるまで~(Part 1)

本記事の原文はNutanix社のProduct Design DirectorのJeremy Sallee氏によるものです。

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

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

Nutanix製品の優れた部分はインフラストラクチャの高度な自動化や優れたソフトウェアアーキテクチャによってもたらされていることはもちろんですが、Nutanixのもう一つの魅力はその優れたユーザーインターフェイスであるNutanix Prismです。

Prismにどんな思いが込められているのかを表したビデオに字幕を入れさせていただきましたので、合わせて御覧ください。

今回は、そのPrismがどのようにして生まれたのかを解説した記事をお届けします。原文が非常に長いので分割しての投稿になりますが、ご容赦ください。

まずは今回はほんのイントロダクションです。

NutanixはGoogle、FacebookそしてAmazonのITテクノロジーをエンタープライズの本流へともたらしました。2009年に創業し、凄まじい勢いで過去数年成長していました。

2013年のはじめ、Nutanixはとても上手く行っていました。製品の新しい機能によって会社は多くの注目を集めていました。しかし、この新しい製品を管理、監視するユーザーインターフェイスはとても複雑で、寄せ集めのFlexベースのアプリケーションでした。

より優れたエクスペリエンスをユーザーに提供するため、会社としてこのアプリケーションを完全に作り直そうという動きを始めます。HTML5ベースのフラットデザインが目的でした。デザイナーがいなかったので、開発チーム(7名のエンジニア)はユーザエクスペリエンスのフリーランサーを雇い、初期段階のアプリケーションに取り掛かり始めました。このタイミングで私はこのプロジェクトに参加することになりました。

Flexベースのアプリケーションの見た目は以下の様なものでした

Fig039

そして、以下が私が到着したその日の初期段階のアプリケーションの見た目です

Fig040

Fig041

Fig042

私が加入する以前のNutanixのデザインやワイヤフレームのアーカイブはここからダウンロード出来ます。見ていただくだけで製品がいかに複雑であるか、そして、どうして単一デザインソリューションへと会社を駆り立てたのかがよくわかります。

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

まだ本当にイントロダクションなのですが、FlexベースのUIとJeremyさんが到着した時点でのユーザーインターフェイスをご紹介致しました。ある意味で、既にNutanix Prismのように見えますが、ここからJeremyさんはどのように手を入れていくのでしょうか? 次回パート2は超大作になりそうですが、頑張って翻訳していきます。コンシューマーグレードのデザイン、インターフェイスが生まれていくそのプロセス、なかなか学ぶ機会も無いと思いますし、実際ものすごく面白い内容になっています。ご期待ください。

IBM FlashSystem 900の実力

IBM FlashSystem 900!それはまさに異次元の低遅延を誇る超高速マシン!!

Fs900

★ 実はこっそりこんな検証もやってたんですぜっ!! 

(遅延の原因になる機能を可能な限り取っ払って辿りついた「速さ!」の最終形態っ!)
速い!って謳ってる「FlashSystem900」は本当に速いのっ?

 
その真相を確かめるべく、「一般的なSSD」を使用したオールフラッシュストレージと呼ばれるものと何が違うのか比べてみましたっ♪
 
あのね、言っておくけど、HDDハイブリッド・ストレージとの比較じゃなくて、オールフラッシュストレージとの比較だからねっ!!
相手も相当の高速マシンだからねっ!!
そこんとこよろしくねっ♪



超高速・低遅延  Flash Module の実力とその傾向
IBM Flash System 900編

 

速い!と謳われる超低遅延の高速フラッシュストレージ!

では、いったいどのくらい速いのか?
一般的なSSDタイプのオールフラッシュストレージと比較することでその違いと傾向を視てみましょう。
今回はフラッシュストレージということで「ランダムアクセス」に焦点を絞り検証を行いました。

1:特定のワークロード(ランダム読み込み、ランダム書き込み、OLTP)実行時の性能比較
2:データベースのワークロード(TPC-C)実行時の比較

本検証は、超高速、低遅延のフラッシュストレージの特徴を確認し
使用方法、及びその用途のベスト・プラクティスを確立することを目的として、
一般的なベンチマークアプリケーションにて負荷を発生させ、これを計測したものです。

3

 

4

 

5

 

6

1:特定のワークロード(読み込み、書き込み、OLTP/4KB)実行時の性能比較

 

8_2

9_2

 

11

 

12

 

13

 

14

 

15

 

16

 

17

 

18

 

19

 

20

 

21

 

22

 

2:データベースのワークロード実行時の性能比較

24

 

25

 

26

27

 

28

 

29

 

30

31a

 

ここでちょっと言い訳タイム!!

 
All Flash(SSD) Storageって遅いじゃん・・・って思ったそこのあなたっ!
次の検証結果を視て、よ~く考えてみてくださいっ。
ここで比較されているALL HDD(SAS-HDD)Storageも64GB(1コントローラーあたり) のWrite Cacheを搭載した
ミッドレンジに相当するの高速ストレージですっ。
次のグラフを見てのとおりAll Flash(SSD) Storageは、間違いなく爆速ですっ!!

Flash System 900が速すぎるだけなのですっ。


*参考データ*

32

 

2016/10/19

VMware Cloud on AWS - Elastic DRSプレビュー

本ブログエントリーは以前はPernixData社のテクノロジーエバンジェリストとして勤務し、現在はVMware社のR&DでSenior Staff Architectを務めているFrank Denneman氏のブログの翻訳版です。 Frank氏について、詳しくはこちらもご参照ください。

本記事の原文はVMware Cloud on AWS - Elastic DRS previewで閲覧可能です。

ネットワールドのVMwareに関する情報はこちら

VMworld Europeのキーノートでは将来提供開始されるVMware Cloud on AWSが紹介されました。このサービスは手短に言うとVMwareの顧客に即座のスケールとAWSのグローバルな提供性を提供しながら、これまでに培ってきたスキルセットでのVMwareのオンプレミスとクラウドのSDDC環境を動作させ運用するを可能にするというものです。プラットフォームを再構成、再設計するというリスクを避け、現在利用しているアプリケーションをそのままに別のプラットフォームで動作させ、同じサービスを提供することが出来るのです。そうすることでIT組織は現在のアプリケーションをRDSやRed Shift、Glacierやもっと多くのサービスのようなAWSの広範なサービスカタログに接続して利用することが出来るのです。

興味深い機能の一つとして現在テックプレビューのElastic DRS(イラスティック DRS)が挙げられます。イラスティックDRSはIT設計者が直面するもっとも難しい課題の1つであるキャパシティプランニングの解決に役立ちます。キャパシティプランニングの主なキーポイントは現在と将来のリソース要求、障害復旧のためのキャパシティそして、メンテナンスのためのキャパシティです。ワークロードのパフォーマンスを維持することと、障害復旧のためのキャパシティのためのCAPEXとOPEXを削減していくことの適切なバランスを見つけるのは難しい問題です。AWSの拡張可能なIT運用を活用することで、イラスティックDRSはvSphereクラスタを俊敏性を備えた発電所へと変革します。

俊敏な拡張性の機能によって追加ホストがクラスタへと追加されます。ハードウェア、ラッキング、スタッキングを注文するということはなく、単にマウスを右クリックして新しいホストを追加するだけです。従来からの計算を行い、DRSはクラスタのホストリソースが限界に来ていることを検知し、新たにホストを追加すべきであるという推薦事項を表示します。通常のDRSと同じく、イラスティックDRSを自動モードにすることが出来、クラスタ上での負荷に応じてホストを追加、削除することが出来るようになります。

Fig003

時々ITをスーパースケールで動かしていくということがめちゃくちゃ複雑であるということを忘れてしまうことも有ります。単一のホストをインストール、構成、そして運用していくのは面白いことです、しかしこれを大量にやるとすると多くのIT組織にとっての限界が迫ってきます。さらに、それが世界中の多くのデータセンタで同時に行われなくてはならず、しかもお客さんがそれを直ぐに望んでいるとしたら?途方も無いことになります。チームにジョインし、イラスティックDRS。について学んだことは、まさに感激でした。これがAWSの世界中のすべてのデータセンタの全てのお客様にとってどのように動くのかを理解しすることは本当にぶったまげるようなことです!拡張されるIT(IT-at-Scale)がもっとも良いのです。

もし、すぐに利用できるESXiホストが幾つかあるのであれば、沢山のクールなことが出来るようになります。例えばDRSを有効にしてvSphere HAを補助したりです。ESXi 3.0からvSphere HAはワークロードがクラスタ内の残ったホスト上で再起動することを保証してきました。しかし、ホストが足りない状態が一時的ではなく、永続的なものであった場合、利用可能なホストリソースが長期に渡って足りないことの影響を受け、アプリケーションのパフォーマンスは影響を受けてしまいます。自動回復はこの課題の解決に寄与します。

イラスティックDRSの上で実現される自動回復はESXiホストが不足している間も利用可能なホストリソースを保証します。ホスト障害が検知されると自動回復によって別のホストがクラスタに追加され、長期にわたるホスト障害からワークロードのパフォーマンスが影響を受けないようにします。もし、(ハードウェアの)一部の障害が発生したら、自動回復はデグレードされたホストを解除する前にVSANの運用が行われることを保証します。

このフレームワークのもう一つのメリットはメンテナンス時にも同等のリソースを維持することが可能になります。大抵メンテナンス機関の間、ホストにパッチを当てるなどでホストは一時的にサービスアプリケーションを動作させることができなくなります。多くのIT組織はこの問題に対して「オーバーサイジング」で対処するか、メンテナンス期間中はサービスが劣化するというSLAを引くかで対処します。イラスティック DRSがあれば、クラスタサイズはメンテナンス運用時も減ることはありません。こうすることでリソースの不足からワークロードが影響を受けることはなくなり、通常運用の時間と同じようなパフォーマンスで動作継続することが可能です。

この機能はまだテクニカルプレビューで、まだ利用できないということを協調しておきます。

VMware Cloudについてもっと詳しく知りたいという方は詳細をご確認ください。

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

さて、VMware Cloud on AWSのFrank氏のブログが追加になりました。前回はイラスティックスケーリングと言う言い方をしていましたが、このスケーリングが既存のDRSの技術を活用するもので、ホストの追加と削除までが全自動で行われる様になるということも記載されています。

AWSで同様なことを行おうとするとこれまでは一工夫必要でしたし、もちろんオンプレミスのvSphereでは物理的にホストリソースをすぐに増やすということが出来ませんでしたので、まさに夢のとりわせで実現した、夢のインフラ(クラウドというべきか?)だと思います。

また、他の記事では初めてAWSが「ハイブリッドクラウド」という言葉を使った!と話題にもなっていますが、AWSとしても既存のワークロードへと足を伸ばすことが可能でまさに相思相愛のパートナーシップだと思います。

もちろん、vSphereですからコンピューティングやストレージリソースがきっちり仮想マシン分だけということではないので、VMware Cloud on AWSでどの程度のスペックのホストが利用できるのか?どういう単位なのか?は語られていない情報です。

他の部分はどうなっているのでしょう? まだまだ謎に包まれたVMware Cloud On AWS、Frankさんの続報を待ちましょう。

エンドユーザーにフォーカスを : Citrix XenserverとNutanixのエンタープライズクラウドプラットフォーム

本記事はNutanix社のオフィシャルブログの記事Putting the Focus on End-users: Citrix XenServer and Nutanix Enterprise Cloud Platformをネットワールドが翻訳したものです。著作者はNutanix社のDirector of Solutions MarketingのSachin Chheda氏です。

NutanixのCEO、Dheeraj Pandeyは最近companies with staying power(勢いを保ち続ける会社)という記事を投稿しています。もともとは造反者として始まった彼らは、業界に優れた変革をもたらし、業界における地位を確立しながらも、自分自身への再発明も行っています。この顧客中心の見方はエンジニアから、サポート、ソリューション開発までにおけるNutanixのガイドラインとなる基本思想の一つでもあります。これは他でもないアプリケーションやデスクトップ仮想化の分野において、顕著に現れています。

NutanixとCitrixはVDIとアプリケーション仮想化を定期的に革新し、情報システム部門のエンドユーザーのニーズへのフォーカスするための場を提供してきました。例えば、2016年にシドニーでNutanixはフルスタックのターンキー(鍵を回すだけ)のInstantON VDI for Citrixと呼ばれるCitrix XenDesktopとMicrosoft WindowsベースのVDIソリューションを発表しました。これによって適切な価格帯でのエンタープライズレベルのエクスペリエンスの提供がなされたのです。2つの会社は設計者や管理者に業界を代表するVDIとアプリケーション仮想化ソリューションを様々な異なる仮想化スタック上で動作させるという選択という力を提示したのです。この中には業界初となるXenAppとXenDesktop-Microsoft Hyper-V上で動作-するソフトウェアで定義されたCitrix Validated Solution(Citrix検証済みソリューション)、ESXiとの検証済みソリューション、それからNutanix AHV仮想化スタックを活用したCitrix MCSとの統合ソリューションが含まれています。今日のニュースはこの我々の情報システム部門の方々へのコミットメントを更に後押しするものとなります。

NutanixはCitrixと共同で将来、将来業界をリードするXenServer上で動作するXenApp、XenDesktop、NetScaler VPSそしてNetScalerをNutanix エンタープライズクラウドプラットフォーム上でサポートすることをアナウンス致します。NutanixのAsterixリリースと共に、XenServerを利用しているお客様はXenServer 7をNutanixソリューションのTech previewとして動作させることが可能になります。

Citrixを利用しているお客様の間での一般的な選択では、XenServerはもっとも大きなXenApp、XenDesktopの環境においても十分適応できるというものです。Nutanix AHVと同様に、Citrix XenServerでは特別なライセンスが必要になるわけではありません。Citrix XenAppとXenDesktopに含まれており-別の仮想化スタックへの投資を削減することが出来ます。最新ヴァージョンであるXenServer 7では拡張グラフィックスサポート(Linux用のvGPUと拡張性の向上)、確実なWindowsとの統合(Windows 仮想マシンドライバの更新、SCOM統合、他)、優れたセキュリティ(Direct Inspect API)などの既存の顧客に対しての先進的な機能が盛り込まれています。

機能がリリースされた暁には、Citrix XenServerのユーザはNutanixエンタープライズクラウドプラットフォームへの移行で既にNutanixの顧客が経験しているのと同じ以下のメリットを受けられることに気がつくことでしょう :

  1. 最初の展開の高速さと1クリックでの追加拡張 - XenServerの顧客はハードウェアを箱から出してから、仮想デスクトップを提供し始めるまでにものの2,3時間で、既存の環境を拡張する際にも数分でそれが出来るようになります。これはHero GroupRush大学でのNutanixでの体験と同じで、Nutanixソリューションの展開は1日かかりません。
  2. パフォーマンスのボトルネックなくリニアにユーザーを拡張 - XenServerのユーザは10,000のユーザーへも素晴らしいユーザーエクスペリエンスを提供できる環境へと拡張することが出来ます。これは多くのサイトをまたがった数千のユーザーをカバーするSt. Lukeが進んだのと同じような道のりです。お客様はサイジングや拡張性のリスクに対して、Nutanix VDI Assureanceサービス(訳注:国内での提供時期は未定)で備えることも出来ます。
  3. 低いコストと運用のオーバーヘッド - XenServerのユーザーはインフラストラクチャの管理、特にストレージの管理のための労力を最小化し、展開やトラブルシューティングのタスクをシンプルにすることで、TCOや運用のオーバーヘッドを大きく削減することが出来ます。これはYahoo! JapanがCitrixとNutanixを利用した後に、エンドユーザーのデスクトップやアプリケーションについて情報システム部門の個々人の生産性を高くして対応できたのと同じ体験になります。

終わりに : 求めているものが、ホステッドシェアードデスクトップであれ、グラフィックス辺獣の仮想化デスクトップであれ、リモートユーザーへの高速でセキュアなアプリケーションとデータへのアクセスであれ、NutanixとCitrixはともに、情報システム部門を支え、それを実現してきました。今日のNutanixがXenServerをサポートする計画であるというアナウンスはこの両社がエンドユーザーのニーズの提供にフォーカスしようという原点への立ち戻りのまたとない例で、仮想化を別のアドオンとして入れるという部分を排除し、インフラストラクチャをインビジブルにしているのです。

もっと詳しく知りたいですか? VDIとアプリケーション仮想化におけるXenServerのサポートについてのNutanixのソリューションブリーフはこちらからダウンロードできます。更にcitrix@nutanix.comに個別のブリーフィングやライブでのデモを依頼することも可能です(訳注:英語のみ)。さらに以下のリソースを参照して、もっと情報を得ることも可能です。

リソース:

Calvin Hsu氏のブログ: CitrixとNutanixは情報システム部門がアプリケーションとデスクトップ環境のコストと複雑性の管理をどのように手助けできるか (XenAppとXenDesktop、ShareFile、NetScaler VPX、その他がAHVで検証済みとなった際に投稿されたもの、訳注:翻訳予定なし、リンク先は原文)

XenServer 7の新機能についてはCitrixブログ内のXenServer 7 Launch - 知っておくべきこと(訳注: ネットワールド、Nutaixチームとしての翻訳予定はなし)

PVSとMCSの違いを知りたいですか? Kees Baggerman(CTP、Nutanixソリューションアーキテクト)とMartijn Bosschaart(テクニカルパートナーアーキテクト)のCitrix Synergyセッションはこちら

免責事項 : このブログはNutanix.com外のウェブサイトへのリンクを含んでいます。このため、外部のサイトの内容についての正確さについては全て免責とさせていただきます。外部ページへのリンクはすべてそのサイト内のコンテンツへの推薦としてお考えください。

記事担当者: マーケティング本部 三好哲生 (@Networld_NTNX) ← 今回の記事からこちらのアカウントへ移行を始めております。

Nutanixエンタープライズクラウド、クラウドの名前にふさわしく、素晴らしいスピードでの機能追加です。今回はvSphere、Hyper-V、AHVに続く第4のハイパーバイザーであるXenServerのサポートについてのアナウンスからです。VDIでGPUを利用する際の選択肢としても広がりますし、PVSでなくてはならないというニーズにも答えた素晴らしい選択だと思います。

まずはAsterixでTechプレビューとしてリリースのようですね、正式版が待ち遠しい!最近のリリースでハイパーバイザーの混在がアナウンスされましたので、まずはAHV、その後XSというようなお客様内でのロードマップも選択できるかもしれません。

そう、重要なのは「エンドユーザーのニーズに答える」ということです。

Citrix + AHVのビデオへ字幕を入れましたのでご紹介致します。

Citrix Runs on Nutanix Enterprise Cloud(ネットワールド字幕入れ) from miyo4i on Vimeo.

また、次回のネットワールドのNutanixのウェブセミナーは「AHV+XenDesktopやってみた!」です。是非お申し込みください。ネットワールドでは毎月(原則)第2,4水曜日に定例Webセミナーを実施しています。色々と試してみますので、ぜひ毎回ご参加ください!とくに「やってみた!」シリーズでは毎回ネタを募集しています! Twitterでも、Facebookでも、コチラからでもどしどしリクエスト受け付けます!

2016/10/14

VMware Cloud™ on AWS – 詳細

本ブログエントリーは以前はPernixData社のテクノロジーエバンジェリストとして勤務し、現在はVMware社のSenior Staff Architectを務めているFrank Denneman氏のブログの翻訳版です。 Frank氏について、詳しくはこちらもご参照ください。

本記事の原文はVMware Cloud™ on AWS – A Closer Lookで閲覧可能です。

ネットワールドのVMwareに関する情報はこちら

長きに渡る沈黙を経て、ようやく少しだけ、私がVMwareで何にフォーカスをしてきたかということをお話できるタイミングになりました。(この記事の内容はblogs.vmware.comに掲載した内容の再掲です。)

本日、VMwareとAmazon Web Services(AWS)は完全なVMwareのSoftware Defined Data Center(SDDC)を動作させることが可能なクラウドサービスをAWS上で提供開始するという戦略的なパートナーシップを発表しました。このサービスはvSphere、ESXi、VSAN、そしてNSXを含む皆様がよく親しんだ全てのエンタープライズツールが含まれています。この記事では新しいVMware Cloud on AWS(VMC)サービスの技術的なプレビューを行います、もうすぐリリースされるめちゃくちゃクールなこいつを覗き見していきましょう。

Fig001このアーキテクチャは言わずもがな、夢の取り合わせです。vSphereをこれまでに利用してきた管理者や設計者はアプリケーションを再設計することや、運用手順を再構成することなくAWSの俊敏性を活用することができようになるのです。vCenterが運用の中心となるプラットフォームになりますから、現在オンプレミスのvSphere環境で利用しているvCenterと連携して動作する全てのツールがクラウドのSDDC環境で動作するというのが一つの大きな目玉です。こうした何年もの月日を経て開発されてきたツールや機能が、今後はクラウドの間をワークロードが移動出来る環境で利用することが出来るようになり、その上、新しいレベルでのデータセンタの俊敏性までもが利用可能なのです。

つまり、サインアップを終えて、クラスタのサイズを選択すればご自身のSDDC環境が短時間で作成されるということです。VMware cloudはネイティブなESXが、次世代のAWSのベアメタルインフラストラクチャ上で動作しているということを強調(そして誤解を避けるためにも)しておきます。VMware cloudはAWSインフラストラクチャ上のvSphere ESXiホスト、VSAN、NSXを含むプライベートクラウドとして展開されます。これによって、エンタープライズワークロードがオンプレミスの環境と同じレベルのパフォーマンス、信頼性、そして可用性で今度はAWSアーキテクチャ上で動作するということになります。オンプレミスとクラウド環境の大きな違いはVMwareがVMware Cloud on AWSのインフラストラクチャを管理運用するということです。

Fig002

重要なので、これは完全なマネージドサービスであるということをしっかりとお伝えしておきます。つまり、VMwareがこれを支えるESXi、VSAN、vCenter、そしてNSXのインフラストラクチャをインストール、管理、維持するということです。パッチ適用やハードウェア障害の復旧というような一般的な運用はVMwareがサービス内で実施します。お客様はvCenterのパーミッションなどの権限を受け、管理的なタスクを行うことになりますが、パッチ適用などの特定のアクションについてはVMwareがサービスの一環として提供を行います。これはつまり、VMwareがAWSとのパートナーシップ内でインフラストラクチャのコア部分の面倒を見るということです。

VMware Cloud on AWSはスタンドアローン、ハイブリッドクラウド、そしてクラウド to クラウドの3つの環境で利用が可能です。ハイブリッドとクラウド to クラウドの環境ではvCenterはリンクモードを有効にして構成され、IT運用チームがSDDC環境を集中管理されたコンソールから一元管理できる状態で提供されます。NSXは様々な環境間のネットワークとセキュリティを一貫して俯瞰できるように拡張します。ただし、NSXは要件には含まれません! もしも現在NSXをオンプレミス側で利用していなかったとしてもVMware Cloud on AWSを利用することが出来、その場合にはNSXを利用するハイブリッドクラウドの機能を利用できないというだけです。ネットワークとクラウドにまで渡る機能によって、vMotionでワークロードを様々なクラウドに自在に出入りさせることが出来るようになっています。そう、読み間違えではありませんよ、現在のオンプレミスのvSphere環境からAWSへvMotionすることが出来るのです!

面白いコンセプトとしてイラスティックスケーリング(自在な拡張)があります。イラスティックスケーリングはIT設計者の直面するもっとも難しい課題であるキャパシティプランニングの解決に役立ちます。キャパシティプランニングの重要なポイントは現在と将来のリソース要件、障害復旧キャパシティ、そしてメンテナンスのためのキャパシティです。ワークロードのパフォーマンスと障害復旧のための予約キャパシティのCAPEXとOPEXの低減の適切なバランスを見つけ出すことは難しい問題です。イラスティックスケーリングがvSphereクラスタを俊敏性を備えた発電所へと変えると考えてください。時間のかかる調達を行い、プロセスを自身でインストールする代わりに、拡張性のあるITという考え方とAWSによって提供されるサービスのメリットを受けることが出来るのです。

ESXi4.0以降、vSphere HAはワークロードがクラスタ内の稼働中のホスト上で再起動する事を実現しています。しかし、ホストの不足が一時的なものではない場合、ホストのリソースは利用可能なホスト数の減少によって抑制を受けることになります。ESXiホストが不足している間にもホストのリソースが確保されるような自動修復機構をDRソリューション上に構築することも可能です。ホスト障害が検知された際に、自動修復はクラスタに自動的に別のホストを追加し、ワークロードのパフォーマンスが長期継続するホスト障害からの影響を受けないことを保証します。もしも(ハードウェアの)部分的な障害の場合、自動修復によってその機能不全のホストがクラスタから外れる前にVSANの必要な操作が行われることを保証します。

このフレームワークのもう一つのメリットはメンテナンス時にも同様にリソースを利用するということが出来るということです。メンテナンス運用の最中、クラスタのサイズが減ることはなく、ワークロードはリソースが減ることによる影響を受けずに、通常運用時と同じように動作継続することが出来るのです。

VMware Cloud on AWSサービスの一つの強みは管理者、運用チーム、そして設計者が既存のスキルセットとルールを利用してAWSインフラストラクチャを利用することが出来ることだと考えています。クラウドへワークロード動かす際に、そのクラウド流にプラットフォームを変更する必要も、仮想マシンの変換も、パッケージングの変換も、そして重要なポイントとして、過剰なまでの検証を行うこともなく、単に仮想マシンを移行させればよいのです。もう一つの強みは、AWSが取り揃えている優れた機能セットと現在のワークロードを組み合わせられるという点です。その結果、ITチームは自身のスキルセットを広大なAWSが提供しているサービスのカタログへと拡張していくことが出来るようになります。これによって、オンプレミスのプライベートクラウドと優れたAWSのパブリッククラウドサービスの両方でシームレス動作する環境を作り上げることが出来ます。

もっとご紹介したい素晴らしい機能がたくさんあるのですが、これについてはまた別の記事のために取っておきましょう。

VMworld

もし、今後リリースされるVMware Cloud on AWSサービスをもっと学びたいと思うのであれば、VMworld Europeで、ブレイクアウトセッションINF7849:VMware Cloud on AWS - a closer lookに参加してください。このセッションでAlex Jauchと私はもう少し深くこのサービスの詳細まで潜っていきます。もっと一般的な観点であればINF 7711 VMware Cloud Foundation on Public Cloudsのブレイクアウトセッションへご登録ください。

VMworld Europeでの私のMeet the Expertのスロットも少ないながら有りますので、もしもっとサービスにフォーカスした議論がしたいということであればご登録ください。

もし、ベータへ登録をしたいという場合にはこちらをクリックしてください:http://learn.vmware.com/37941_REG

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

ちょっと本日バタバタしており、タイムリーに翻訳記事を公開できませんでしたが、なんと、Frankのアニキこんなことになっていたのですね! VMwareに戻って活発に活動しているようなのでとても嬉しいです。VMwareがAWS上で動く、まさにFrankさんが言うように「夢の取り合わせ」です。私個人的にはこのところ活動が多角化していたVMwareが本来のソフトウェアカンパニーとしてのイノベーションという原点に回帰したようにも思え、今回の発表はなんだか、心が熱くなります。まだまだ語るべきことがたくさんある!と言う雰囲気ですのでFrankさんの記事はタイムリーに翻訳をかけていきたいと思います。

また、上で紹介されているVMworld Europeですが、今年もネットワールドのメンバーが参加予定になっていますので、また現地からのレポートが届くかも!? 乞うご期待です!

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!