*Nutanix Feed

2017/12/24

どうしてNutanix AHV(旧称 : Acropolis Hypervisor)は次世代のハイパーバイザーなのか? パート10 - コスト

本記事は[2枚目]Nutanix Advent Calendar 2017への寄稿も兼ねております。是非アドベントカレンダーの他の記事もお楽しみください。1枚目のNutanix Advent Calendar 2017もどうぞ。

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

原文を参照したい方はWhy Nutanix Acropolis hypervisor (AHV) is the next generation hypervisor – Part 10 – Costをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら

ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。

コストがリストの一番下にあって、驚かれている方もいらっしゃるかもしれません。ですが、これまでの記事を読んできていただいた方はおそらく、業界の他の製品と比べてAHVが様々な面で優れた仮想化プラットフォームであるということにお気づきでしょう。私の意見では、Starterエディションに含まれているから、AHVを「低価格なオプション」もしくは「機能に制限のある廉価なハイパーバイザー」と考えるのは誤りです。(これは全てのNutanixのお客様に無償で提供することにしているという意味でしかありません)

ハイパーバイザーやその管理コンポーネントのライセンス/ELAが明らかに削減されるという点を考慮しないとしても、AHVを利用して頂く実際のコスト上のメリットは劇的な設計、実装、運用の様々なフェーズともちろん、日々の管理の労力の劇的な削減です。

この原因は多くの要素からなります:

設計フェーズのシンプル化

すべてのAHVの管理コンポーネントは組込されており、高可用性構成で、自動的にスケールします。目的に特化した専門家(SME ー Subject Matter Expert)を管理ソリューションの設計に巻き込む必要もありません。何年にも渡って数え切れないほどの高可用性仮想化ソリューションを設計してきた人間の一人として、AHVは最初から私が過去にお客様のために他の製品を利用しながら夢に描いて来たもの、そのものです。

実装フェーズのシンプル化

すべての管理コンポーネント(Prism Centralという例外はありますが)は自動的に展開され、エンジニアがこれらのコンポーネントをインストール/パッチ/要塞化するという要件は存在しません。

Acropolisとすべての管理コンポーネントはすべてCVM内に組み込まれています。これは間違いの起こる可変の部品が少ないということを意味し、それらの検証を行う必要もありません。

経験的に、運用の検証は大抵の場合見落とされがちで、インフラストラクチャはその設計要件とその導入効果が実証される前に本稼働環境へと投入されてしまいます。AHVでは管理コンポーネントは自動的に展開され、コンポーネントが提供されないというリスクはまったくもってありません。更に運用上の検証を行うにしても、従来型の製品とは異なり、可変できる部分が非常に少ないため、検証は非常に早く終えることができます。

日々の運用のシンプル化

AcroplisはAcroplisベースソフトウェア(以前はNOSと呼んでいました)、AHV、ファームウェア、そしてNutanixクラスタチェック(NCC)に対して完全に自動化されたローリングアップグレードの機能を提供しています。それだけではありません、アップグレードのダウンロードの前に互換性のないヴァージョンインストールしてしまうリスクを排除してやハードウェア互換性リスト(HCL)や互換性マトリックスをチェックしてからダウンロードされます。

AHVはキャパシティ管理を劇的にシンプルにします。これは必要とされるキャパシティ管理がストレージプールレイヤだけであるということに由来します。管理者がLUN/NFSマウントするもしくはコンテナにおいてキャパシティを管理するという必要はありません。この能力はよく知られているハイバーバイザーが持っている、例えばvSphere ストレージ DRSの必要性も排除します。

サードパーティのライセンスコストの削減

AHVにはすべての管理コンポーネントが含まれています。もしくはPrism Centralを利用する場合においても事前にパッケージされたアプライアンスを使うだけです。すべてのOSのライセンスは発生しません。すべてのNutanixノード上で動作している高い信頼性を持つ管理コンポーネントはMicrosoft SQLやOracleというようなサードパーティのデータベース製品、もしくはベストなケースで仮想アプライアンスを展開すればよいという場合であったとしてもこれらは高可用性を欠くもので、バックアップや維持が必要になります。AHVではこれらの必要性を排除しています。

管理用インフラストラクチャのコストの削減

仮想化ソリューションに10もしくはそれ以上の管理コンポーネント(それぞれが専用の仮想マシンになっている場合がほとんど)が必要になるということはよくある話です。小さな環境においても一元管理、パッチ、パフォーマンスやキャパシティの管理の機能を利用しようとすればこれらが必要になってしまいます。環境が成長するについれて、もしくは高い可用性の要件が必要になるに連れて、管理仮想マシンの数とそのためのコンピューティングの要件は増えていく傾向にあります。

すべての管理コンポーネントはNutanixコントローラー仮想マシン(CVM)の中で動作しており、CVMはそれぞれのNutanixのノードで起動しています。専用の管理クラスタは必要ありません。コンピューティング/ストレージのリソースの総量も減らすことができます。

管理用インフラストラクチャの削減からの間接的なコスト削減は以下を含みます:

  1. ラックスペースの削減 (RU)
  2. 電源/空調の削減
  3. ネットワークポートの削減
  4. コンピューティングノードの削減
  5. ストレージキャパシティとパフォーマンス要件の低減

大事なことを言い忘れていました、メンテナンスウィンドウやシステム停止時にかかるコストはどうでしょうか?

Acropolisは完全に非破壊的なワンクリックのアップグレードを提供しており、多くの障害ポイントを削減しています(例 : サードパーティのデータベース)、その一方で、非常に信頼性の高いプラットフォームを提供しています。AHVはお客様のメンテナンス時やシステム停止時のコストも削減してくれます。

まとめ:

  1. Acropolisの管理コンポーネントの設計は必要ありません
  2. 管理コンポーネントの日々の維持運用も必要ありません
  3. 複雑性を削減し、ダウンタイムやヒューマンエラーによるダウンタイムの可能性を削減します

インデックスへ戻る

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

Ntc2017_2

全10回(実質9回)の本シリーズはこちらでおしまいです。残念ながら原文のパート9の内容はパスワードで保護されているため、日本語にしたとしてもこちらで公開することはできません。

ですが、パート9がなかったとしてもAHVが如何に優れたハイパーバイザーであるかということはお伝えできたのではないかと思っています。しかも、本記事を翻訳している間にAOS 5.5がリリースされ、AHV Turboを含む様々な最新の機能が現在進行形で取り込まれています。次世代である上に更に歩みを止めずに進化し続けている唯一のハイパーバイザーと呼んでよいのではないでしょうか。

最後に今回、9にもなるシリーズ、つまり9日間分のブログの翻訳を決意させてくださった、NutanixのAdvent Calender周辺の管理者の皆様、誠にありがとうございます。まさかの2枚目のカレンダー、今年何をやり忘れているか・・・。AHVでした。来年はAOS 5.5と一緒に登場した新機能で更に武装を強化し、Year of AHVにしましょう!

また、毎日のように更新されるブログを呼んでくださった皆様、ありがとうございます。

2017/12/23

どうしてNutanix AHV(旧称 : Acropolis Hypervisor)は次世代のハイパーバイザーなのか? パート8 - 分析(性能 & キャパシティ管理)

本記事は[2枚目]Nutanix Advent Calendar 2017への寄稿も兼ねております。是非アドベントカレンダーの他の記事もお楽しみください。1枚目のNutanix Advent Calendar 2017もどうぞ。

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

原文を参照したい方はWhy Nutanix Acropolis hypervisor (AHV) is the next generation hypervisor – Part 8 – Analytics (Performance / Capacity Management)をご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら

ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。

AcropolisはAcropolisプラットフォーム、コンピューティング(AHV/仮想マシン)、そしてストレージ(分散ストレージファブリック)をカバーする強力かつシンプルに使える分析ソリューションを提供しています。

他の分析ソリューションとは異なり、Acropolisは追加で設計/展開もしくは構成が必要となるソフトウェアライセンスや管理インフラストラクチャ、もしくは仮想マシンやアプライアンスを必要としません。Nutanixのコントローラー仮想マシンは組み込みで分析機能を提供し、一切外部へ依存関係を持っていません。別の製品や仮想アプライアンスにデータを展開/取込が必要にならないということは、オーバーヘッドが小さいということにもなります。つまり、保存するデータが小さくなるということで、ストレージへの影響も小さくなります。

この機能は組み込みで初日から使えるというだけでなく、環境が時を経て成長するに連れて、Acropolisは自動的に分析機能を拡張していきます。どこかでしきい値を超えて追加のインスタンスを展開する必要性や、分析のための仮想アプライアンスのコンピューティング/ストレージのリソースの割当を増やすまたは、バックエンドにデータベースを追加するというようなことには永遠にならないのです。

分析UIのデモについては以下のYoutubeのビデオを4:50から御覧ください : 


YouTube: Nutanix Prism UI - 28 nodes

まとめ:

  1. 組み込みの分析ソリューション
  2. 追加でのライセンスを必要としない
  3. 設計/実装もしくは仮想マシン/アプライアンスの展開の必要はありません
  4. XCPのクラスタが成長するのとともに自動的に分析機能もスケールします

Acropolisに組み込まれているためオーバーヘッドは小さく、分散ストレージファブリックを活用できます。

インデックスへ戻る

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

Ntc2017_2

今回はデモビデオを見て頂く・・・という記事なのですが、分析ソリューションが組み込まれていて、小さなオーバーヘッドで利用できるということは非常に重要です。

また、Prismの使いやすさは見ていただいて理解頂くのが一番です!ぜひビデオをじっくり御覧ください!

2017/12/22

どうしてNutanix AHV(旧称 : Acropolis Hypervisor)は次世代のハイパーバイザーなのか? パート7 - 俊敏性 (価値創出までの時間)

本記事は[2枚目]Nutanix Advent Calendar 2017への寄稿も兼ねております。是非アドベントカレンダーの他の記事もお楽しみください。1枚目のNutanix Advent Calendar 2017もどうぞ。

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

原文を参照したい方はWhy Nutanix Acropolis hypervisor (AHV) is the next generation hypervisor – Part 7 – Agility (Time to value)をご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら

ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。

他のハイパーバイザーと管理蘇シューションを展開する時には、一貫したパフォーマンスを保証したり、ダウンタイムのリスクを最小限に留めるためにある一定のデザインのための労力とそれの作業への専門性が必要です。一方で出来る限りの俊敏性も実現しなくてはならないのです。Acropolisの管理には全くと言っていいほど殆ど設計は必要ありません。組み込みの管理ソリューションは最初から最適化されており、高可用性を備えているからです。これによって他のハイパーバイザーとそれに紐づく管理コンポーネントの展開よりもAHVはより早い展開を実現することが可能です。

AHVをベースとした環境の最初のサイズを気にすること無く、すべての管理、分析、データ保護、そしてBC/DRコンポーネントは自動的に展開され、適切にサイジングされます。AHVのクラスタに限った話ではありませんが、管理の設計の労力は必要ありません。これによって非常に早く(大抵の場合、1時間以内で単一ブロックの展開)その価値を発揮し始めます。

AHVは数え切れないほどの機能も提供し、お客様が迅速にソリューションを展開できるようにしています :

  • 組み込みの管理&分析

クラスタの管理に必要なすべてのツールが自動的にクラスタ内に展開されているという事実は、価値提供開始までの時間はこうしたツールの設計/展開/検証のいずれにも依存していないということを意味しています。AHVを管理するためのクライアントをインストールするという必要性もありません。単にウェブブラウザでアクセスすれば良くなっています。

  • 組み込みのセキュリティ/コンプライアンス監査による、出荷時からの要塞化構成

最初から要塞化されていることで、実装フェーズでセキュリティが崩壊してしまうというリスクを排除することができます。それと同時に、自動化された監査によって、普段の運用の中でセキュリティの設定を変更してしまうというようなことがあったとしてもそうして変更されてしまった設定はセキュリティプロファイルで決められているものに戻されます。

  • インテリジェントなクローン作成

分散ストレージファブリックとの統合により、AHVはほとんど一瞬で仮想マシンのクローンを行うことができます。この機能は仮想マシンの電源の状態には関係ありません。ですから、他のハイパーバイザーのように仮想マシンの電源がオフでないといけないというような制限はないのです。

この機能のデモについてはこちら: Nutanix Acropolis hypervisor acli cloning operations

注意: クローンについてはPrismもしくはacli(Acropolis CLI)で行えます

まとめ:

  1. 最小限の設計/実装の労力でAHVは管理することができます
  2. マルチクラスタの一元管理が必要な場合、単一の仮想マシン(Prism Central)のみが必要となり、これは仮想アプライアンスとして展開できます
  3. 分析、データ保護、レプリケーション、管理の高可用性化のための追加アプライアンス/コンポーネントは必要ありません
  4. 適切なAcropolisプラットフォームの展開に何かに特化した専門家が必要になることはありません

インデックスへ戻る

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

Ntc2017_2

さて、パート7は少し短めです。ですが、ビジネスにおいて最も効果を発揮する部分もここでしょう。数週間から数ヶ月掛けてインフラを展開するということも以前は非常に多かったのですが、Nutanixに関して言えば当社のSEがご支援に入って、一週間以上に渡って作業するということは(ハードウェアの設置やNutanix以外の部分を除くと)まずありません。

つまり購入して、すぐにその価値を発揮し始めるNutanixを採用することは投資回収期間を大幅に縮めることにつながります。(もちろん、更にソフトウェアアップグレードでその価値が継続的に上がっていくということも!)

長かったシリーズもあと2つになりましたが、後2日おつきあいお願い致します。

2017/12/21

どうしてNutanix AHV(旧称 : Acropolis Hypervisor)は次世代のハイパーバイザーなのか? パート6 - 性能

本記事は[2枚目]Nutanix Advent Calendar 2017への寄稿も兼ねております。是非アドベントカレンダーの他の記事もお楽しみください。1枚目のNutanix Advent Calendar 2017もどうぞ。

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

原文を参照したい方はWhy Nutanix Acropolis hypervisor (AHV) is the next generation hypervisor – Part 6 – Performanceをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら

ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。

性能についてお話をする際に、4KのI/Oベンチマークを使うなど、非現実的なスピードを比較対象として並べていくのは非常に容易いことです。ですが、すべての本当のデータセンタの技術のエキスパートが知っているとおり、IOPSはパズルの本の小さなピースでしかないのです。私の意見では、IOPSはこれほどまでに注目をあびるべきではないほどの注目を浴びています。これについてはこちらの記事でお話をしています。ピークパフォーマンス vs 実際の世界のパフォーマンス

性能についてお話をする際に、私は管理コンポーネント、アプリケーション/仮想マシン、分析、データの信頼性などのすべてとその間のものも含めてお話をしていきます。

さて、AHV(旧称: Acropolis Hypervisor)を動作させているNutanix XCPが全てのコンポーネントにおいて一貫した高いパフォーマンスを保証している幾つかの例を見ていきましょう:

管理の性能:

Acropolisの管理レイヤにはAcropolis Operating System(以前のNOS)、Prism (HTML5のGUI)、そしてAHVの管理スタックが含まれており、「マスタ」と「スレーブ」のインスタンスからなっています。

このアーキテクチャは全てのCVMが動作し、各々平等にプラットフォームの全てのエリアで継続的にスムースに動作することができるように、保証しています。つまり、中心となるアプリケーションやデータベースやコンポーネントは存在せず、それがボトルネックになることもないのです。完全に分散させることこそがウェブスケールプラットフォームを提供する鍵です。

Fig336

おのののコントローラー仮想マシン(CVM)はローカルノードの管理に必要なコンポーネントと分散ストレージファブリックと管理タスクに貢献するためのコンポーネントを動作させています。

例 : 1つのAcropolis「マスタ」が居ますが、これは単一障害点でもパフォーマンスのボトルネックでもありません。

Acropolis マスタ は以下のタスクを担当します:

  1. HAのスケジューラー
  2. ネットワークコントローラー
  3. タスクの実行者
  4. ハイパーバイザーからのローカルの統計を収集/提出
  5. 仮想マシンのコンソール接続のVNCプロキシ
  6. IPアドレスの管理

各々のAcropolis スレーブ は以下のタスクを担当します:

  1. ハイパーバイザーからのローカルの統計を収集/提出
  2. 仮想マシンのコンソール接続のVNCプロキシ

マスタであるか、スレーブであるかにかかわらず、各々のCVMは2つの最も重たいタスクを実行しています。ハイパーバイザーからのローカルの統計を収集/提出と利用している場合は仮想マシンのコンソールの接続です。

初めから分散して設計されているため、XCPのプラットフォームは一貫した高いパフォーマンスを達成できています。中央の、例えば中心となる管理仮想マシンとそれに紐付いたデータベースサーバへ統計情報を送信することはボトルネックになりえますが、何らかの形でのアプリケーションレベルのHA(例 : SQL Aways on Availability Group)が導入されていない場合、これは単一障害点にもなりうるため、殆どのお客様でこれは受け入れがたい状態です。

Acropolisマスタが行っている役割はHAのスケジューラーやネットワークコントローラー、IPアドレス管理、タスク実行者など、全て軽量なタスクです。

HAスケジューラータスクはノード障害時にしかアクティブにならないタスクで、マスタにとってのオーバーヘッドは非常に小さいものです。ネットワークコントローラーのタスクは新たなVLANを構成する際などにしか利用されません。タスクの実行は全てのCVMで実行されている分散されたすべてのタスクを継続的に監視するシンプルなものです。IPアドレスの管理は基本的にはDHCPのサービスで、これも非常に小さなオーバーヘッドです。

パート8で、Acropolis Analyticsについて更に詳しくお話します。

データローカリティ

データローカリティはXCPの他にはない機能で、新しいI/Oは仮想マシンが動作しているローカルノードとクラスタ内の他のノードにレプリケーションされて書き込まれるというものです。データローカリティは次回以降のReadのI/Oがネットワークを経由して転送され、リモートのコントローラーを利用するという必要性を排除します。

仮想マシンがクラスタ内を移動する場合には、WriteのI/Oは常にローカルに書き込まれるため、リモートからのリードはリモートデータのReadが必要な場合にのみ発生します。もしもデータがリモートに有り、その先アクセスされないのであればリモートのI/Oは発生しません。結果として大抵の場合、90%以上のI/Oがローカルから提供されることになります。

現在、うまく設計された10Gbのネットワークでは帯域とレイテンシの問題はさほど問題にならないかもしれませんが、フラッシュのパフォーマンスが幾何級数的に向上していくにつれ、ネットワークは非常に高価な40Gb(もしくはそれ以上の)のネットワークへの移行なくしては簡単に大きなボトルネックとなります。データローカリティは大部分のRead I/Oをローカルから提供し、Writeのコピーのうちの一つをローカルでさばくことによってWrite I/Oからのネットワークのオーバーヘッドを減らすことでネットワークへの依存関係を最小化することに役立ちます。ですから、ローカリティはお客様がパフォーマンスに妥協すること無くより低コストなネットワークを利用することを可能にするのです。

データローカリティはサポートされている全てのハイパーバイザーで動作しますが、AHVは他にはないデータアウェアな仮想マシンの配置をサポートしています : 仮想マシンは障害時やメンテナンス時に仮想マシンのデータのローカルデータの割合が最も高いノードで、つまりリモートのI/Oの可能性が最も低くなるノードで電源が入りそれぞれの仮想マシンのI/Oのオーバーヘッドが低くなります。

さらに、データローカリティはハイパーバイザーや仮想マシンの統計データなどの分析のためのデータの収集についても適用されます。結果として統計データはローカルに書き込まれ2つ目(もしくはRF3が設定されている場合には3番目も)はリモートに書き込まれます。これはつまり、統計データ、非常に膨大にもなりうるデータが分散ファイルシステムとクラスタに有りうる限りの最小限の影響しか与えないということも意味しています。

まとめ:

  1. クラスタとともに管理コンポーネントも拡張され、一貫したパフォーマンスを保証する
  2. データローカリティがデータがコンピューティング(仮想マシン)とデータを可能な限り近くにあることを保証する
  3. データの場所をベースとしたインテリジェントな仮想マシンの配置
  4. 全てのNutanixコントローラー仮想マシンはチーム(ペアではない)で動作し、クラスタ内のすべてのコンポーネントとワークロード(仮想マシン)に適切なパフォーマンスを保障

インデックスへ戻る

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

Ntc2017_2

さて、皆様の大好きなパフォーマンスに関連する記事になりました。XCPという名前が多用されているとおり、記事が古いので現在のAHVはこれはさらに先を行っています。

仮想マシンの配置はよりインテリジェントなものとなり、vSphereでいうDRSに相当する動的なものになっていますし、AHV Turboモードによって、ハイパーバイザーを通過する際に発生するオーバーヘッドもNutanixにとっては過去のものになりつつ有ります。

常に進化を続け、購入したノードの性能もソフトウェアで向上していく・・・そうしたNutanixの魅力の一つで外せないのが、この性能で、その中心にあるのがAHVなのです。

2017/12/20

Nutanix Marketplaceはどのように開発者とIT部門を一緒にするのか?

本記事はNutanix社のオフィシャルブログの翻訳版です。原文を参照したい方はHow Nutanix Marketplace Brings Developers and IT Togetherをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら

ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。

ニースにおいて、我々は新しいエンタープライズのための先進的なパブリッククラウドのような消費モデルの開発者中心のサービスを発表しました。この記事では開発者とITをより緊密にするという我々の見通しを共有させていただきます。そこではよりよいコラボレーションが育まれ、アプリケーションの俊敏性が増すことになります。これによって組織に劇的な効果が上がることになるでしょう。

開発者とITに共通して必要とされる一般的な目的には市場への迅速な投入の加速、対応時間の短縮、インフラストラクチャの問題の解決に費やす時間の最小化などがあります。しかしながら、開発者は最新の技術の取り込みとオンデマンドなリソースの提供に目を向けがちで、IT側はアプリケーション開発者を手助けする適切なツールの必要性についてはしばし目を伏せがちです。Nutanixは既に管理、アップグレード、ITリソースの拡張のシンプル化などの優れたプラットフォームを提供することで市場への投入時間を短くするという部分については提供をしてきています。しかし開発者は本当にサービスの提供についてNutanixプラットフォームを利用していることの価値を感じているのでしょうか?例えば、コンテナの世界に置ける最先端のイノベーションを活用できているでしょうか?開発の業務に集中できるようにするために自動的にコンテナプラットフォームが展開される様になっているでしょうか?ここにNutanix Marketplaceが登場してきた意味があります。

セルフサービスのちからを与える ー ワンクリック、エニークラウド

Nutanix Marketplaceは我々の2017年Q4でのリリースを予定しています。開発者に一箇所からただのワンクリックで必要なアプリケーションリソースを瞬時に利用開始できるようにします。チームにとっては自身のための特別オーダーメイドとなる様々な展開オプションをユーザーの役割とグループに応じて手に入れることができるようになります。Nutanix Marketplaceからアプリケーションの1つを起動するということは、MarketplaceやまたはカスタムのITが事前に作成した、事前に定義された全体が自動化された手順のフローをインスタンス化するということです。これには仮想マシン、バイナリ、必要なアプリケーション構成が含まれています。これを利用することで開発者は自分自身の必要とするスピードで完全にセルフサービスの状態でサービスを利用することができます。

ITの観点からは、単により良く、迅速なサービスを提供できるということだけに留まりません。アプリケーションはマーケットプレイスからいつも実行可能ですし、再現性があり、数日もしくは数ヶ月のアプリケーションの展開や管理の提携作業を取り除くことになります。すべてのユーザーのアクティビティはエンドツーエンドで追跡可能で、トラブルシューティングや互換性のニーズを解決することにも役立ちます。

マーケットプレイスは我々のオープンなアプローチということを前提に設計されています。開発者はアプリケーションをオンプレミスに、もしくはパブリッククラウドにもしくはその両方にまたがっても展開するということを選択することができます。結果としてITはマルチクラウド戦略を実現しながら、その利用状況やクラウドをまたいだリソースのコストについても可視性を手に入れることができるのです。

Fig319

事前統合のBlueprint

開発者は常に新たな開発、検証、コード投入の新しい考え方やツールを取り込むことで開発のプロセスを改善しようと考えています。これを最終目標として、Nutanixは事前に統合され、検証の済んだblueprintを提供し、ITチームが新しいテクノロジーを自身の環境に迅速に導入できるようにします。これらの事前統合されたblueprintを用いることでIT部門は開発者とともに新しいツールを迅速に試験導入し、共同でそれを利用するかどうかの決断をすることができます。この能力は新しいツールの実権を育むということだけではなく、チーム間のコラボレーションを生み出すことにもなります。

上のスクリーンショットではJenkins、Puppet、Hadoop、そしてMySQLなどの事前統合されたblueprintを確認することができます。NutanixはGoogleとのパートナーシップの中でコンテナのオーケストレーションプラットフォームであるKubenetesのblueprintも提供します。このblueprintではNutanixのオンプレミスとパブリッククラウドの両方へKubernetesクラスタを展開することができます。以下のスクリーンショットでは35ページにも及ぶガイドが必要なほど複雑で、多くのコンポーネントと様々なスクリプトが必要になる厄介な手順がシンプルなblueprintへと翻訳され、マーケットプレイスからワンクリックで利用可能になるということを確認できます。

Fig320

まとめると、Nutanix MarketplaceはIT部門に対し、開発者のための優れたセルフサービス環境を実現するための素晴らしい方法をご提供しながら、より良い統制とマルチクラウド戦略への簡単な道筋を提供します。Nutanixでの自動化についてもっとよく知りたいですか? Nutanix CalmのページまたはCalmの技術メモをダウンロードして下さい。

Forward-Looking Statements Disclaimer

This blog includes forward-looking statements, including but not limited to statements concerning our plans and expectations relating to product features and technology that are under development or in process and capabilities of such product features and technology, our plans to introduce product features in future releases, product performance, competitive position and potential market opportunities. These forward-looking statements are not historical facts, and instead are based on our current expectations, estimates, opinions and beliefs. The accuracy of such forward-looking statements depends upon future events, and involves risks, uncertainties and other factors beyond our control that may cause these statements to be inaccurate and cause our actual results, performance or achievements to differ materially and adversely from those anticipated or implied by such statements, including, among others: failure to develop, or unexpected difficulties or delays in developing, new product features or technology on a timely or cost-effective basis; delays in or lack of customer or market acceptance of our new product features or technology; the introduction, or acceleration of adoption of, competing solutions, including public cloud infrastructure; a shift in industry or competitive dynamics or customer demand; and other risks detailed in our Form 10-K for the fiscal year ended July 31, 2017, filed with the Securities and Exchange Commission. These forward-looking statements speak only as of the date of this presentation and, except as required by law, we assume no obligation to update forward-looking statements to reflect actual results or subsequent events or circumstances.

© 2017 Nutanix, Inc. All rights reserved. Nutanix, AHV, Acropolis Compute Cloud, and the Nutanix logo are registered trademarks or trademarks of Nutanix, Inc. in the United States and other countries. All other brand names mentioned herein are for identification purposes only and may be the trademarks of their respective holder(s).

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

Ntc2017_2

今回もニースで発表になった内容の記事となります。Nutanix Calmはマルチクラウド環境に置けるオーケストレーションを実現するのみならず、スケールアウト、アップグレードなどのアプリケーションライフサイクル全体をコントロールする意欲的なプラットフォームです。

このCalmを最も簡単に利用できるようにするのがこのNutanix Marketplaceです。ワンクリックとある通り、Nutanixの上にこのマーケットプレイスのアプリケーションを展開するのは本当に簡単で、新しい技術を少し試してみようというところから、その先に本格的に導入しようという場合、そしてその環境をパブリッククラウドへと移行させようという場合、様々なライフサイクルの局面で利用することができます。

自動化って・・・開発者のものだよねもしくはDev/Opsだよね、というちょっと大変そうな道ではなく、ワンクリックで簡単な道を用意してくれています。閉ざされた自動化が少しでも開ければと思い、私も期待しています。登場が待ちきれません。(翻訳時には登場が待ちきれませんでしたが、なんとリリースされています!)

2017/12/19

どうしてNutanix AHV(旧称 : Acropolis Hypervisor)は次世代のハイパーバイザーなのか? パート5 - 信頼性

本記事は[2枚目]Nutanix Advent Calendar 2017への寄稿も兼ねております。是非アドベントカレンダーの他の記事もお楽しみください。1枚目のNutanix Advent Calendar 2017もどうぞ。

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

原文を参照したい方はWhy Nutanix Acropolis hypervisor (AHV) is the next generation hypervisor – Part 5 – Resiliencyをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら

ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。

信頼性についての話をする場合、データの信頼性のみを見てしまい、ビジネスアプリケーションを稼働させるために必要なストレージコントローラーや管理コンポーネントの信頼性については見落とされてしまうという過ちが多くあります。

RAIDやホットスペアのドライブといった従来からのテクノロジーは場合によってはデータの信頼性を提供しますが、スケールアウトも自己修復もできないデュアルコントローラータイプのストレージに接続されていた場合、単一のコンポーネントの障害であったとしても、データが利用できなかったり、パフォーマンスや機能がいくばくか低下するというようなことに見舞われます。信頼性の回復について、ハードウェア交換に依存したインフラストラクチャは私がハードウェアサポート契約と24x7 4時間オンサイトはもはや必要のないものになった(和訳予定なし)という記事で以前議論したとおり、根本的に崩壊しているのです。

加えて、もしも管理アプリケーションのレイヤに信頼性がなくなった場合、データレイヤの高可用性や信頼性が阻害されることになり、ビジネスアプリケーションは(例えば普通のスピードでは)うまく動作しなくなったり、まったくもって動かなくなることもあるでしょう。

Acropolisプラットフォームはデータと管理レイヤの双方に高い信頼性を提供しており、N+1またはN+2(Resiliency Factor 2 または 3)に設定することができます。これによって最大2つのノード障害が同時に発生しても管理そしてデータを失わずに対応することができます。更に、「ブロックアウェアネス」があればブロック全体(最大4ノード)の障害においてもクラスタは完全な機能を維持し続けます。こう考えるとXCPのデータと管理コンポーネントの信頼性は最大でN+4であるということもできます。

更に、より大きなXCPクラスタではノード/コントローラー/コンポーネントの障害の影響はより小さくなっていきます。4ノードの環境でN-1は25%のインパクトですが、8ノードのクラスタでは12.5%です。クラスタが大きければ大きいほどコントローラー/ノードの障害のインパクトは低減されるのです。対象的にデュアルコントローラーのSANにおいては単一コントローラーの障害は50%もの品質低下影響があり、その後に障害が起きれば完全な停止に追い込まれます。Nutanix XCP環境は自己治癒機能を持っているため、障害イベントでもN-1になるだけです。その後に機能する自己治癒がその後に発生する障害からも保護を行ってくれるため、大きな影響や停止を起こすことはないのです。

Acropolisのマスターインスタンスが障害を起こした場合でも、30秒以内で完了する新たなマスター選出によって完全な機能が環境に復元されます。これは管理の可用性が「シックスナイン」(99.999%)以上であることと等価です。重要なのはAHVはこの管理の信頼性が組み込まれているということです。さらに設定をする必要もありません!

更に詳しい情報についてはこちら: Acropolis: の拡張性(和訳予定なし)

データの高可用性についてはハイパーバイザーに関係なくNutanix分散ストレージファブリック(DSF ー Distributed Storage Fabric)は2つまたは3つのデータ/パリティを保持しており、SSD/HDDもしくはノードの紹介時に設定されたRFをクラスタ内のすべてのノードで復元します。

データの信頼性

データの信頼性だけが重要な要素ではないとはお話しましたが、やはりこれはキーとなります。結局のところ、データを失う可能性のある共有ストレージソリューションではあらゆるデータセンタの目的に見合ったソリューションにはなりえないのです。

データの信頼性についてはNutanixの分散ストレージファブリックの根幹ですから、データ信頼性のステータスはPrismのホームスクリーンに表示されます。以下のスクリーンショットで我々は信頼性が定常状態にいるのか、または障害(キャパシティのリビルド)時のイベントの両方を確認する事ができます。

この例ではクラスタ内のすべてのデータは設定されたResiliency Factor(RF2 または 3)コンプライアンスに従っている状態です。そして、クラスタは最低限のN+1のノード障害時のリビルドのためのキャパシティも確保しています。

Fig341

信頼性のステータスのさらに詳細に分け入るためにはシンプルに上のボックスをクリックするだけです。そうすれば更に細かな障害からの保護についての詳細が表示されます。

以下のスクリーンショットはメタデータなどを示していまっす。OpLog(永続的Writeキャッシュ)とZookeeperなどのバックエンドの機能が監視されており、必要なときにはアラートが発行されます。

Fig342

これらのどれか一つでも通常もしくは「グリーン」状態でない場合、Prismは管理者へアラートを発報します。アラートの原因がノード障害の場合、Prismは自動的に(Pulse経由で)Nutanixのサポートへと通知を行い、必要なパーツを出荷を初めます。大抵の場合、ハードウェアのメンテナンスのSLAが4時間オンサイトなどであったとしても、Nutanix XCPクラスタはハードウェアの到着よりも随分前に自己治癒を終えています。

これはNutanixがハードウェア(の交換)に依存しない信頼性をもっていることのまたとない例です。

データの完全性

ゲストOSとしてへのWrite I/Oの完了通知はデータが永続メディアに書き込まれた後のみであるべきです。これはこの時まではストレージがバッテリーバックアップのキャッシュや無低電源装置(UPS)で保護されていたとしても、データを失う可能性が伴います。

唯一のWriteの事前完了通知を行うメリットはパフォーマンスですが、良いパフォーマンスのためにデータの完全性やがデータそのものが失われてしまうリスクを犯しますか?

もう一つの一般的に見逃されがちなエンタープライズグレードのストレージソリューションについての要件はサイレントなデータの欠落を検出し、復元する能力です。Acropolisはソフトウェアで全てのWriteとRead両方にチェックサムをつけています。重要なことはNutanixはその下のハードウェアやサードパーティのソフトウェアにデータの完全性を維持するための機構で依存していないということです。全てのチェックサム発行と(必要な場合の)復元はネイティブで行われます。

プロのコメント : もしストレージソリューションがチェックサムをWriteとReadの両方で行っていない場合にはそのソリューションは本稼働環境では使わないで下さい。

サイレントなデータの欠落(あらゆるベンダーのあらゆるストレージデバイスがこの影響を受けます)が起きた場合、チェックサムが合わず、I/Oは別のノード(もちろん、物理的に別のSSD/HDD)上にある別のレプリカから取得されます。もしイレイジャーコーディング環境でチェックサムが合わなかった場合、EC-XがデータをHDD/SSD障害時と同様の方法で再計算し、I/Oを提供します。

バックグラウンドでNutanix Distributed Storage Fabricはデータの欠落を無効化し、設定されているResiliency Factorを壊れていないレプリカか、EC-Xが利用されている場合にはストライプから復元するのです。

このプロセスは完全に仮想マシンやエンドユーザーからは透過的に行われますが、XCPの信頼性に置ける重要なコンポーネントです。下にある分散ストレージファブリック(DSF)は自動的にAcropolis管理コンポーネントも保護します。これは全てのコンポーネントが一緒に作られていて、後からボルトドメされているわけではないAcropolisアーキテクチャの多くの先進性の1つの例です。

RF3(Replication Factor 3)に設定されているストレージコンテナのAcropolis環境ではN+2の管理の可用性が提供されます。結果として、ほとんど起きそうにもない、同時に3ノードの障害が起きない限りは管理が停止していまうということもありません。幸いなことにXCPはこの起こりそうにもないシナリオに対しても回答を持っています。ブロックアウェアネスを利用すれば3もしくはそれ以上のブロックでもクラスタを保護し、ブロック全体(最大4ノード)の障害においてもデータと管理をオフラインにせずに済みます。

Acropolisの信頼性周りの話の一部として、複雑性がないという話に戻りましょう。Acropolisは1クリックのローリングアップグレードをすべての機能において実現しています。単一障害点は一切ありません。最悪のシナリオとしてAcropolisマスターを載せているノードが障害を起こしたとしても、30秒以内に別の生き残ったノード上で次のマスターロールが再起動され、仮想マシンの電源を開始します。繰り返しになりますが、これは組み込まれた機能で、設計/インストール/維持が必要な追加もしくはサードパーティのソリューションを必要とはしません。

上で述べてきた点はAHV自身というよりは大部分がXCPの機能です、ですからAHVのロードバランシング機能と障害対応機能を取り上げたいと思います。

従来型の3階層のインフラストラクチャ(例 SAN/NAS)とは異なり、Nutanixのソリューションはマルチパスを必要としません。これは全てのI/Oがローカルのコントローラーから提供されるからです。結果としてマルチパスのポリシーの選択などの別のレイヤーの複雑性や潜在的な障害点になりうるものを排除できているのです。

しかしながら、ローカルのCVMが何らかの理由で利用できなくなった時には最も効率的な方法でI/Oをノード上のすべての仮想マシンに提供しなくてはなりません。AHVはこれを以下に示すようにvDiskレベルでランダムにリモートのStargateへI/Oをリダイレクトすることで実現しています。

Fig343

AHVがこれをできる理由は全てのvDiskがiSCSI経由で提示されており、自身のターゲット/LUNを所有しているからです。つまりvDisk自体がTCP接続を保持しています。これは例えばMS SQL/ExchangeもしくはOracleのような複数のvDiskが必要となるようなビジネスクリティカルなアプリケーションを同時に複数のコントローラーで利用できるということを意味します。

結果として全ての仮想マシンのI/OはAcropolisクラスタ全体に負荷分散され、これによって単一のCVMがボトルネックにならないということを保証します。仮想マシンは障害時やメンテナンス時も素晴らしいパフォーマンスを得ることができるのです。

更に詳しくはこちら: Acropolis Hypervisor (AHV) I/O Failover & Load Balancing(和訳予定なし)

まとめ:

  1. 以下に対応する最初から有効になっている自己治癒の機能:
    1. SSD/HDD/ノード障害
    2. Acropolis と PRISM (管理レイヤー)
  2. 組み込みのデータの完全性とソフトウェアベースのチェックサム
  3. 最大で4台同時のノード障害を無害化
  4. 管理の高可用性は99.9999%以上 (シックス“ナイン”)
  5. データと管理の信頼性についてはハードウェアに依存していない

更に詳しくはこちら: Ensuring Data Integrity with Nutanix – Part 2 – Forced Unit Access (FUA) & Write Through(和訳予定なし)

インデックスへ戻る

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

Ntc2017_2

今回はもっとも重要な・・・そして長い記事です。データの信頼性はもちろん、管理コンポーネントの信頼性についても記載されていますが、AHVの優れている(そしてユニークな)ポイントはvDisk一つ一つを仮想マシンがiSCSIでTCP接続しているという点でしょう。iSCSIの接続が切れる(CVMの障害などで)場合でも瞬時に別のCVM経由で再接続され、I/Oの停止は発生しません。これはNFSやCIFSで接続されている他のハイパーバイザーでは実現できない・・・つまりNutanixなりの思い切った実装が元になっています。

こうした複雑なことをしていても、Prismがそれをキレイに覆い隠してくれる・・・それがNutanixのいいところですね。さて、次は第6弾ですが、明日はちょっと別の内容をはさみます。

2017/12/18

Nutanix Xtract for VMs Deep Dive ~データ転送の裏側~

本記事は全三回の連載になっています。本記事は全三回の連載になっています。興味のある方は他の回のコンテンツもご覧ください。

第1回: Nutanix Xtract for VMsは使えるのか? 

https://blogs.networld.co.jp/main/2017/12/nutanix-xtract--61ff.html

第2回: Nutanix Xtract for VMs Deep Dive ~データ転送の裏側~

https://blogs.networld.co.jp/main/2017/12/nutanix-xtract--342e.html


第3回: Nutanix Xtract for VMs Deep Dive ~ハイパーバイザー変更を吸収する仕組みとは~

https://blogs.networld.co.jp/main/2017/12/nutanix-xtract--ae65.html

AHV移行時の課題

 既存のHypervisorからAHVへ移行する場合、前回お話したように「ダウンタイムをいかに最小限にするか?」「何かあったときに容易に切り戻り(ロールバック)できるか?」という点が重要になってきます。この2点をどのようにXtract for VMsで解決しているのが、データの転送の観点からみていきたいと思います。

 

Xtract for VMsの移行の流れ

  Xtract for VMsの移行はシンプルな移行ジョブとして作成されますが、当然裏側では様々なタスクが実行されています。スムーズな移行を実現するためにタスクを分類すると、「ダウンタイムを最小限にするためのデータ転送のタスク」「移行元、移行先のギャップを埋めるための仮想マシン設定のタスク」にわけることができます。

 今回はこのうち「ダウンタイムを最小限にするためのデータ転送のタスク」について掘り下げていきたいと思います。来週執筆予定の「Xtract for VMs Deep Dive第2回」では「移行元、移行先のギャップを埋めるための仮想マシン設定のタスク」について掘り下げる予定です。

 

ソースとなるvSphere環境から仮想マシン1台(Xt-02-w2k12r2)をAHV環境へ移行する流れは以下になります。今回はデータ転送が行われるフェーズの①~③について出力されるログをベースにどんな処理が実行されているのか見ていきましょう。

 

Migration Planの作成

Migration Planの実行

↓①

CutOverの待機

↓②

CutOverの実行

↓③

Migration Planの完了

 

Xtract for VMsのデータ転送の仕組み(Migration Planの実行編)

 Xtract for VMsでは「Migration Plan」の実行時に「Data Seeding」と呼ばれる移行元仮想マシンの全データの転送が行われます。このとき、仮想マシンはもちろんゲストOSの中で動作するアプリケーションは動作していて問題ありません

 

この「Data Seeding」時は、以下のようなデータ転送処理が行われます。他にもゲストOS内で様々な処理が実行されますが、データ転送に関わる部分だけを取り上げています。仮想マシンがもつすべてのスナップショットが削除される点だけ注意が必要です

  • 仮想マシンがもつすべてのスナップショットの削除
  • 仮想マシンのスナップショットの取得(ロールバック時にはこのスナップショットに戻る)
  • 全データの転送

Xtract1_2

 

これらのスナップショットの取得は、ソースとなる仮想マシンのvmware.logファイルにログが出力されます。「XTRACT-VMSnap-0」というスナップショットを取得していることがわかります。

 

2017-12-18T02:35:05.900Z| vmx| I125: SnapshotVMX_TakeSnapshot start: 'XTRACT-VMSnap-0', deviceState=0, lazy=0, logging=0, quiesced=0, force

Native=0, tryNative=1, saveAllocMaps=0 cb=466AA50, cbData=32400020

2017-12-18T02:35:05.912Z| vmx| I125: DISKLIB-LIB_CREATE   : DiskLibCreateCreateParam: vmfsSparse grain size is set to 1 for '/vmfs/volumes/

32fae0e3-f1ee21fa/Xt-02-w2k12r2/Xt-02-w2k12r2-000001.vmdk'

2017-12-18T02:35:05.915Z| vmx| I125: DISKLIB-LIB_CREATE   : DiskLibCreateCreateParam: vmfsSparse grain size is set to 1 for '/vmfs/volumes/

32fae0e3-f1ee21fa/Xt-02-w2k12r2/Xt-02-w2k12r2_1-000001.vmdk'

2017-12-18T02:35:05.915Z| vmx| I125: SNAPSHOT: SnapshotPrepareTakeDoneCB: Prepare phase complete (The operation completed successfully).

 

では次に気になるデータ転送の経路についてみていきましょう。

 Xtract for VMsでは通常移行先のAHVクラスタ上にXtract for VMsの仮想アプライアンスを展開します。この仮想アプライアンスを中心にどういったデータ転送が発生するのでしょうか。

 まずソースVMのデータのやりとりは、通常のvSphere環境でバックアップするときに用いられるVADP(vStorage API for Data Protection)と呼ばれるAPIを利用しています。ソースの仮想マシンに対してスナップショットを実行して、仮想ハードディスクに対して読み取り専用でアクセスすることができます。

 そしてターゲットVMのデータのやりとりは、AHVクラスタ上の「Storage Container(データストア)」をXtract for VMsのゲストOSがNFSマウントすることで、直接AHVクラスタへデータを書き込みます。一度Xtract for VMsにデータを保存して、それをもう一度AHVクラスタへ書き込むようなことはしていません。そのため、データ転送自体最短で完了することができますし、移行元のデータサイズによってXtract for VMsにローカルディスクを追加する必要もありません

図としてあらわすと以下のようになります。

Xtract

 これらの一連のタスクのログは、Xtract for VMsのサポートログの中に、xtract-vm-diskreader.log,xtract-vm-diskwriter.logのログとして保存されています。

2

 

Data Seedingフェーズではこのような動作で、Xtract for VMsを介して移行元仮想マシンのデータを移行先のAHVクラスタへデータを転送しているようです。

 

Xtract for VMsのデータ転送の仕組み(Cutoverの待機編)

 先ほどのData Seedingフェーズで全データを転送しましたが、アプリケーションは起動状態だったため最後にデータ整合性を担保したデータで上書きする必要があります。

 しかし、仮想マシンの移行時にData Seeding後にすぐに移行(Cutover)をするとは限りません。動作確認等を入念に行ったり、短時間とはいえシステム停止が必要なためメンテナンス時間の調整で、一ヵ月先になったりすることも当然考えられます。

 例えばData Seedingを行ってから一ヵ月後に移行する場合、一ヵ月の差分データを移行直前にすべて転送完了する必要があります。アプリケーションやデータ構造によっては大部分のデータを再転送することも考えられます。その場合、データサイズによってはシステム停止の時間が長時間になってしまいます。

システム停止時間を最小に抑えるためにXtract for VMsではData Seeding完了後からCutoverが実行されるまでの間は10分間隔で移行元仮想マシンのデータを移行先AHVクラスタへ差分転送が実行されるアーキテクチャになっています。

 

Xtract2

 こうすることで、アプリケーションやデータ構造によるデータ変更量の多少、Data SeedingからCutoverの期間に長さに関わらず、Cutover時には最長でも10分前のデータが担保された状態を維持することができるのです。

 10分間隔と非常に短い間隔で実行されていますが、差分データの取得にはData Seeding時と同じVADPのCBT(Change Block Tracking)の機能を利用しているため、すべてのデータの差分チェックを行う必要はありません。既に変更があったブロックを認識しているため、変更ブロックだけを速やかに差分転送することが可能なアーキテクチャを採用しています。

 Data Seeding時と同様に移行元仮想マシンのvmware.logファイルにCBTを利用した差分データの取得のログが出力されます。

2017-12-18T06:29:22.324Z| vcpu-0| I125: DISKLIB-LIB_BLOCKTRACK   : Resuming change tracking.

2017-12-18T06:29:22.326Z| vcpu-0| I125: DISKLIB-CBT   : Initializing ESX kernel change tracking for fid 1327949945.

2017-12-18T06:29:22.326Z| vcpu-0| I125: DISKLIB-CBT   : Successfuly created cbt node 4f26e879-cbt.

2017-12-18T06:29:22.326Z| vcpu-0| I125: DISKLIB-CBT   : Opening cbt node /vmfs/devices/cbt/4f26e879-cbt

2017-12-18T06:29:22.326Z| vcpu-0| I125: DISKLIB-LIB   : Opened "/vmfs/volumes/32fae0e3-f1ee21fa/Xt-02-w2k12r2/Xt-02-w2k12r2-000001.vmdk" (flags 0x8, type vmfsSparse).

2017-12-18T06:29:22.327Z| vcpu-0| I125: DISKLIB-CBT   : Shutting down change tracking for untracked fid 1257695343.

2017-12-18T06:29:22.327Z| vcpu-0| I125: DISKLIB-CBT   : Successfully disconnected CBT node.

2017-12-18T06:29:22.328Z| vcpu-0| I125: DISKLIB-CBT   : Shutting down change tracking for untracked fid 1327949945.

2017-12-18T06:29:22.328Z| vcpu-0| I125: DISKLIB-CBT   : Successfully disconnected CBT node.

 

Xtract for VMsのデータ転送の仕組み(Cutoverの実行編)

さて最後になりました。実際にvSphere上で動いている仮想マシンを停止して、AHVクラスタ上で仮想マシンを起動する「Cutover」フェーズの動作をみていきましょう。

まずソースとなるvSphere上の仮想マシンでは以下のようなタスクが実行されます。

 

  • Guest OSの停止
  • スナップショットの取得
  • (データ整合性が担保される、差分データ転送)
  • スナップショットの削除
  • 仮想マシンのNICの接続を解除
  • Migrate Plan実行時に取得したスナップショットの削除

 

Xtract3

 

 先ほどCutoverの待機編で説明したように、直近10分前のデータ同期が完了しているためこの3の最後の差分データ転送が短時間で完了するため、まるでOSのパッチ適用をするぐらいのメンテナンス時間で容易に移行できるのがXtract for VMsの最大の特徴ということができます。

 

そして移行先となるAHVクラスタ上ではPrismを確認すると以下のようなタスクが実行されます。今回の移行元仮想マシンが仮想HDDを2つ持っているためImageが2つ作成されています。

Prism

 

  • Xtract for VMが書き込んだHDDをもとにテンプレート(Image)を作成
  • 1で作成されたテンプレートを元に仮想マシンを作成
  • 仮想マシンの電源をオン
  • テンプレートを削除

 

今回はXtract for VMsを使ったvSphereからAHVへの仮想マシンの移行の際のデータの転送の仕組みについて掘り下げて紹介してみました。次回はどうやってハイパーバイザーの違いを吸収しているのか、ゲストOSで実行されているXtract for VMの移行タスクについて掘り下げて紹介してみたいと思います。

 

ではまた来週。

どうしてNutanix AHV(旧称 : Acropolis Hypervisor)は次世代のハイパーバイザーなのか? パート4 - セキュリティ

本記事は[2枚目]Nutanix Advent Calendar 2017への寄稿も兼ねております。是非アドベントカレンダーの他の記事もお楽しみください。1枚目のNutanix Advent Calendar 2017もどうぞ。

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

原文を参照したい方はWhy Nutanix Acropolis hypervisor (AHV) is the next generation hypervisor – Part 4 – Securityをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら

ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。

セキュリティはXCPの設計において、一つ肝となる部分です。革新的な自動化を利用した結果、おそらく業界で最も堅牢でシンプルで包括的な仮想化インフラストラクチャが出来上がりました。

AHVはハードウェアベンダーのHCLを包括的にサポートするようには設計されていません、更にはボルトオンスタイルで数え切れないほどの手間のかかる製品群を積み上げたものでもありません。AHVはそうしない代わりに、Nutanixの分散ストレージファブリックとうまく動くように最適化されており、認証の下りたNutanixもしくはOEMパートナーのアプライアンス上で全てのサービスと機能を完全にウェブスケール式に提供できるようにしてあります。

これによって、他のハイパーバイザーと比べ、より緻密で目的にフォーカスした品質管理と被攻撃面を劇的に削減することができているのです。

セキュリティ開発ライフサイクル(SecDL)が全てのAcropolis プラットフォームで活用されており、全てのコードの一行一行までが本稼働環境での動作を保証されています。この設計はdefense-in-depthモデルに従っており、すべての必要のないlibvirt/QEMU(SPICE、利用しないドライバー)のサービスは削除されています。さらにlibvirtの非-rootグループでソケットは最小限の権限しか付与されないようになっており、SELinuxがゲストのvmescapeからの保護を保証し、その上侵入検知システムが組み込まれています。

Fig339

AHVは文書化されたセキュリティベースライン(XCCDF STIG)をサポートしており、自己修復機能を搭載しています。お客様の定義した間隔でハイバーバイザーはセキュリティベースラインに対するあらゆる変更をスキャンし、あらゆる不都合が検出さればた場合にユーザーを介さずにバックグラウンドでその変更をリセットします。

Acropolisプラットフォームも更に包括的なセキュリティの認証/検証のリストを保持しています:

Fig340

まとめ

Acropolisは以下のような多くのセキュリティの先進性を提供している:

  1. 組み込みの自己監査を行うセキュリティ技術実装ガイド(STIGs - Security Technical Implementation Guides)
  2. 管理者が要塞化の推奨事項を適応する必要のない、そもそもから既に要塞化されたハイパーバイザー
  3. 他のサポートされているハイパーバイザーに比べて削減された被攻撃面

Nutanixのセキュリティに関しては以下もご参照下さい:

インデックスへ戻る

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

Ntc2017_2

第4弾はセキュリティです。ハイパーバイザーはOSの一種ですが、そのうえでさらに多くのOSを起動することを考えると最もセキュリティが必要とされるOSであるということになるのではないでしょうか。AHVは変更検知と自動修復の機能を持ったハイパーバイザーです。また、不要なドライバーなどは入っていないため、巨大なHCLを抱えるOSに比べて被攻撃面も小さくなります。

私自身はセキュリティについて詳しいわけではありませんが、セキュリティ面で見てもシンプルであるが故に、非常に堅牢なハイパーバイザーということは理解できます。

ようやく折り返しですが、次回の第5段にもご期待ください。

2017/12/17

NutanixのBOMアレコレ

こんにちは、ネットワールドの海野です。

今日もNutanix Advent Calendar 2017の記事ということで投稿します。

現在、当社ではマーケティング部門の依頼に基づき、NutanixのBOM (Bill of Material : 部品表)を

SEが作成することが基本となっています。

SEが作成したBOMをマーケティング部門がNutanix社へ送付し、製品の見積が送られてきます。

そして、その見積が弊社営業からリセラー様へ提示されるというフローです。

今回はそのなかのやり取りをFAQとしてまとめてみました。


① Nutanixの型番(モデルナンバー)の意味

Nutanixを扱っていると、NX-1465-G5とかNX-3175-G5とかそういうのを見かけると思いますが、

この型番を確認するだけでどのようなNutanixであるかが判別できます。

Photo_3

例えば、NX-3175G-G5であれば、

「NXシリーズ」の

「3000シリーズ」で

「1ノード構成」の

「3.5インチディスク」で構成されて

「GPU」も搭載された

「Broadwell世代」CPUの

Nutanixであるということが一目でわかります。

② Nutanixのリソース(実効容量)

「Nutanixの実効容量を教えてください」という質問をよく受けます。

我々SEは、ヒアリングに基づき必要とされるリソースをSizerで入力していますから、

お客様からご指定いただいたリソース分は確実に確保されているのですが、

あとどれくらい使えるのかというのを知りたいのもまた現実です。

というわけで、カンタンにですがその把握の仕方をご紹介します。

それを知るためにはBOM (Bill of Material : 部品表) を参照します。

だいたいBOMの4ページあたりに[ Sizing Details ] という項目がありますが、

そこに記載されている [ BOM Details ] にご注目ください。

Bomd3_2

上記の図のとおりですが、BOM Detailsは以下のものが含まれます。

(1) Raw Capacity : Nutanix全体のリソース総合計

(2) RF Overhead : 冗長化(データ多重化)のために使用したディスクリソースの割り当て分

(3) CVM Overhead : 管理VM(Controller VM)に割り当てているリソース

(4) Workload Total : Sizerに入力したユーザーが実際に使うであろうリソース

(5) Usable Remaining Capacity : 利用可能な残りのリソース
  (データ多重化の度合いによって残りのディスク容量が異なります)

(6) % Utilized : リソースの使用率

これを踏まえて、ユーザーが利用可能なディスクの実効容量を算出するためには

BOMに記載されている (4) Workload Total と (5) Usable Remaining Capacity を足し合わせればよいということになります。


当初、実はCitrixとの組み合わせのことを書こうと思ったんですが、

本当によく聞かれるので自分のFAQ的に使いたいと思います。

現場からは以上です。

2017/12/16

どうしてNutanix AHV(旧称 : Acropolis Hypervisor)は次世代のハイパーバイザーなのか? パート3 - 拡張性

本記事は[2枚目]Nutanix Advent Calendar 2017への寄稿も兼ねております。是非アドベントカレンダーの他の記事もお楽しみください。1枚目のNutanix Advent Calendar 2017もどうぞ。

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

原文を参照したい方はWhy Nutanix Acropolis hypervisor (AHV) is the next generation hypervisor – Part 3 – Scalabilityをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら

ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。

拡張性は単にクラスタもしくはストレージの最大キャパシティを形成するノードの数ということではありません。拡張性のもっと重要な面は管理、パフォーマンス、キャパシティ、堅牢性という多くの観点から環境を拡張できるということで、そして運用の観点から拡張がどのような影響をおよぼすのかということになります。

AHVの管理/管理者に必要とされるコンポーネントの拡張性について見ていきましょう :

管理の拡張性

AHVは自動的に管理コンポーネントのサイズを最初のクラスタの展開中、およびクラスタにノードが追加された際に決定します。これは最初のサイジングまたはXCPの管理コンポーネントの拡張を最初から最後まで考える必要が無いということになります。

Resiliency Factorが3(N+2)で構成されているのであれば、Acropolisの管理コンポーネントは自動的にN+2の要件を満たすところまで自動的に拡張されます。よく考えてみましょう。N+2を単一レイヤーで実現するのでは意味がありません。可用性は鎖のように連なっており、最も弱い部分と同じだけの可用性しかもたらさないのです。

ストレージキャパシティの拡張

Nutanixの分散ストレージファブリック(DSF - Distributed Storage Fabric)にはストレージキャパシティの上限はありません。それだけではなく、ストレージキャパシティはNX-6035Cのような"Storage-only"ノードを利用することでコンピューティングとは別に拡張することさえできます。NutanixのStorage onlyノードは従来型のストレージと比べてキャパシティを拡張しようとする際の問題を排除してくれるのです。

AHV(サポートされているハイパーバイザーとの相互互換もあります)を動作させているStorage-onlyノードを拡張することはお客様のキャパシティの拡張をハイパーバイザーを気にせずに行えるということです。Storage-onlyノードはハイパーバイザーのライセンシングや別の管理コンポーネントを必要としません。Storage onlyノードはAcropolis BaseソフトウェアとAHVをコンピューティング+ストレージノードと同様にワンクリックアップグレードを完全にサポートしています。結果として、Storage onlyノードはインビジブルで、どのノードにキャパシティとパフォーマンスを追加したいのかということは完全に分離されているのです。

NutanixのStorage onlyノードは従来型のストレージにおけるキャパシティの拡張の際の問題を排除してくれます。詳しい情報については従来型の共有ストレージの拡張の際の問題点(和訳予定なし)をご参照下さい。

従来型のストレージに置ける拡張時の問題の一部はドライブのシェルフの追加とデータサービス/管理が拡張できないということです。これはIOPS/GBの低下とストレージコントローラーなどのコンポーネント障害時にワークロードに大きな影響が出るということに結びつきます。

Storage onlyノードの拡張は非常にシンプルです。例えば、あるお客様は8台のNX6035CをvSphereクラスタに追加するということを今年の10月のvForumオーストラリアのショールームフロアからノートパソコンで実施しています。 

https://twitter.com/josh_odgers/status/656999546673741824

それぞれのstorage-onlyノードがクラスタに追加されると軽量のNutanix CVMがクラスタに追加され、データサービスを提供しはじめ、リニアな管理とパフォーマンスの性能拡張が保証されます。ですから、従来型ストレージにあった拡張性の問題は存在しないのです。

Storage onlyノードについて詳しくはこちら :  http://t.co/LCrheT1YB1

コンピューティングの拡張性

クラスタ内で高可用性を実現するということはHAのために1台もしくはそれ以上のノードを予約するということを意味します。これはハイパーバイザーのクラスタサイズの最大値が制限されている場合には不必要な非効率性を生み出してしまいます。AHVには単一クラスタに於いてさえ、ノード数の上限値はありません。結果として、AHVはHAのためにクラスタ毎に1台もしくはそれ以上のノードを予約しなければならず、それによってインフラが非効率化してしまう不必要なサイロを避けることができます。AHVのノードは自動的に既存のクラスタに追加される際に必要な設定が施されます。管理者がしなくてはならないのは基本的なIPアドレスの情報とExpand Clusterというボタンを押すだけで、残りはAcroplisがすべてやってくれます。

Nutanixクラスタの拡張をどのように行うかのデモは以下を御覧ください :


YouTube: Expanding a Nutanix cluster

分析の拡張性

AHVは組み込みで他のAcropolis管理コンポーネントと一緒に分析機能も含んでいます。分析コンポーネントは初期展開時とノード追加での拡張時に自動的にサイジングされます。

これは管理者が新たに分析インスタンスもしくはコンポーネントを拡張・展開しなくてはならない閾値はないということを意味しています。分析機能とそのパフォーマンスは規模に関係なくリニアな状態を維持します。

これはAHVでは分析機能の提供のために他のソフトウェアインスタンスやデータベースが必要になることはないということを意味しています。

堅牢性の拡張性

AcropolisはNutanix 分散ストレージファブリックを利用していますので、ドライブやノードの障害時に、クラスタ内のすべてのノードが影響を受けたデータの構成されているresiliency factor(RF)の復旧に参加します。これはハイパーバイザーに関係なく実施されますが、AHVは完全に管理コンポーネントが分散されているため、クラスタが大きければ大きいほど管理レイヤーの堅牢性も向上します。

例えば、4ノードクラスタ内で1つのノードが失われたとすると、パフォーマンスと管理コンポーネントの25%が影響を受けることになります。32ノードクラスタであれば単一ノードの障害の影響はもっと小さくなり、3.125%だけになります。AHV環境が拡張していくにつれ、障害時の劣化や自己修復の能力が復旧時間面でも、その後の続発障害に対する許容度も高まります。

大規模クラスタに置ける堅牢性の向上について更に詳しくはこちら: EC-Xを利用して大規模クラスタに置ける堅牢性を改善する(和訳予定なし)

パフォーマンスの拡張性

ハイパーバイザーにかかわらず、XCPのクラスタが成長していけばパフォーマンスは改善されます。新しいノードがクラスタに追加されるやいなや、追加されたCVMは仮想マシンがノードで動作していない場合であっても管理とデータの堅牢性のタスクに参加する事になります。新しいノードが追加されると、ストレージファブリックはRFのトラフィックをより多くのコントローラーに分散することができるため、Write I/Oと堅牢性が向上し、更にレイテンシの低下にも役立ちます。

他にサポートしているハイパーバイザーに対して、AHVの持つ先進性は管理コンポーネントのパフォーマンス(その多くは既にお話してきました)が、クラスタとともに劇的に拡張されることです。分析機能と同様にAHVの管理コンポーネントもスケールアウトします。管理コンポーネントやその依存関係を新たに手動で追加しなくては管理が拡張できないという閾値は存在しません。

重要なことには、全てのコンポーネントについて、XCPはデータと管理の機能をクラスタ内の全てのノードに分散しているということです。Acropolisは「ミラーされた」コンポーネント/ハードウェア、そしてオブジェクトを利用しておらず、これによって、どれか一つのノードやコンポーネントやハードウェアがボトルネックになったり単一障害点にならないということを保証しています。

インデックスへ戻る

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

Ntc2017_2

さて、第3段は拡張性です。拡張できますよ、ということではなく、上で述べられているとおりで、拡張に際して発生する面倒事は全て自動化されていますし、そもそもこれまでの従来型ストレージの拡張に関して発生していた問題もアーキテクチャ上おこらないようになっています。

単純にハイパーバイザーを比較するとAHVにつく星の数は少ないかもしれませんが、Nutanixにとってそもそも必要のない機能だったりということも多くあります。

AHV以外のハイパーバイザーではクラスタの拡張に応じて管理コンポーネントを手動でスケールアップする必要があるかもしれませんが、それすら無い・・・データが膨れ上がりより大規模なクラスタが必要になる今後のデータセンタ環境では、この全てのレイヤでのスケールアウトは非常に重要になってきます。