Copyright (c) 2022: The Nutanix Bible and NutanixBible.com, 2022. 本ブログの著者または所有者から書面による許可を受けることなしに、本著作物を無断で使用すること、またはコピーすることを固く禁じます。 本著作物を引用、または本著作物に対するリンクを設定することは許可されますが、 NutanixおよびNutanixBible.comの著作であることを明記し、かつ原著の内容を適切かつ明確に示すよう、該当箇所を提示することを前提とします。
日本語版に関して、誤植や不自然な翻訳など、お気づきの点がございましたら こちらのフォームよりお知らせください。
- 他言語版はこちらからご覧ください。
- For other languages, click the flag icon.
- 다른 언어는 국기 아이콘을 클릭하십시오.
- Для других языков щелкните значок флага.
- 对于其他语言,请单击标记图标。
翻訳版について: Nutanixバイブルの原著(英語版)は頻繁に更新されるため、日本語版を含む各言語の翻訳版では最新の更新を反映しているとは限りません。 あらかじめご了承ください。 また、同じ理由によりPDFバージョンを提供していません。 ハードコピーを印刷したい場合には、「PDFに変換」などの手段をご利用ください。
一般的に「Webスケール」の説明に用いられる原則を、Nutanixはスタック全体で活用しています。このセクションでは、これらの基本と、核となるアーキテクチャーの概念について説明します。
Webスケール – ウェブスケール – 名詞 – コンピューターアーキテクチャー
インフラストラクチャーおよびコンピューティングのための
新しいアーキテクチャー
Nutanix は、ソフトウェアスタックを通して「Webスケール」の原則を活用しています。 Webスケールだからといって、GoogleやFacebook、Microsoftのような「超大規模なスケール」になる必要はないということを明言しておきます。 Webスケールな構成はどんな規模でも(3ノードでも、数千ノードでも)適用可能であり、その恩恵を受けることができます。
Webスケールなインフラストラクチャーについて説明するために、いくつか重要な要素があります:
その他の要素:
本書では、これらの基礎とアーキテクチャーコンセプト説明します。
Nutanixは、ある一つの目標に焦点を当てて考案されました:
あらゆる場所のインフラストラクチャーコンピューティングを、存在を意識しなくていいくらい簡単(インビジブル)にする。
このシンプルさは、次の3つのコア領域に焦点を当てることで達成されました。
私達は、単一のハイパーバイザー(ESXi)をサポートする単一のハードウェア プラットフォーム(NX)からスタートしましたが、常に単一のハイパーバイザー/プラットフォーム/クラウド企業以上の存在であることを認識していました。 これが、vCenter でプラグインではなく独自の UI をゼロから構築したり、カーネル内のネイティブなものではなくVM として実行したり、といった選択をした理由の1つです(他にも多くの理由があります)。 なぜでしょうか? と聞かれるかもしれません。
1つのハイパーバイザー、プラットフォーム、またはクラウドがすべてのお客様のニーズに適合するわけではありません。 同じプラットフォームで複数のハイパーバイザーをサポートすることによって、お客様に選択と活用の自由を与えます。 また、それらの間で移動できるようにすることで、お客様に柔軟性を与えます。 すべてがNutanixプラットフォームの一部であるため、同じ操作体験が提供されます。
現在、12種類以上のハードウェアプラットフォーム(Direct/OEM/サードパーティ)、複数のハイパーバイザー(AHV、ESXi、Hyper-Vなど)をサポートし、主要なクラウドベンダーすべて(AWS、Azure、GCP)とのインテグレーションを拡充しています。 これによりお客様は自分にとって最適なものを選択でき、ベンダーとの交渉目的としても利用できます。
注:プラットフォームとは、このセクション全体、そして一般的に使われている一つのキーワードです。 私たちはワンオフの製品を作ろうとしているのではなく、プラットフォームを構築しているのです。
以下に、Nutanixプラットフォームのアーキテクチャー概要を示します。
私たちは、分散ストレージ ファブリック(DSF。当時はNutanix Distributed Filesystem、別名NDFSとして知られていました)と呼ばれる機能でストレージをシンプル化することからこの旅をはじめて、 それは、ローカルストレージリソースとインテリジェントソフトウェアを組み合わせて「集中型ストレージ」のような機能を提供するものでした。
長年にわたり、私たちは多くの機能を追加してきました。 物事をシンプル化するために、これらは 2 つのコア領域に分割されています:
コア サービスは、ワークロード(VM/コンテナ)や他のよりハイレベルのNutanixサービスの実行を容易にする、基礎的なサービスとコンポーネントを提供します。 当初は単なるDSF製品でしたが、スタックのシンプル化と抽象化を支援するために、プラットフォームの機能を拡張し続けています。
以下に、AOSコア プラットフォームの概観を示します:
何年にもわたって、これは独自のハイパーバイザー(AHV)の導入による仮想化の抽象化(私達は、これは透過的なもので、システムの一部であるべきだと信じています)、アップグレードのシンプル化、セキュリティや暗号化のような他の重要なサービスの提供などにまで拡張してきました。
これらの機能により、私達は多くのインフラストラクチャーレベルの問題を解決しましたが、そこで止まりませんでした。 人々はまだ、ファイル共有、オブジェクトストレージ、コンテナのような追加サービスを必要としました。
いくつかのサービスについて、他ベンダーの製品を使用するようにお客様に要求するのではなく、どのサービスでパートナーと提携し、どのサービスを自社で構築するかを考えました。 バックアップについてはVeeamやHYCUなどのベンダーと提携し、ファイルやオブジェクトサービスのような他のサービスについてはプラットフォームサービスとして構築しました。
以下に、Nutanixプラットフォームサービスの概観を示します:
端的にいうと、Appleのような企業が培ってきた、シンプルさ、一貫性、直観性にフォーカスを当てたデザイン原則を適用することです。 当初から、私達はNutanix製品の「フロントエンド」に多大な時間と労力を費やしてきました。 後回しにせず、UI/UXとデザインのチームは、常に限界に挑戦してきました。 例えば、私達は(SaaSプレイヤーを除けば)企業向けソフトウェア企業の中では、管理用UIをHTML5で作成した最初の企業の1つでした。
ここでのもう一つの核となる項目は、プラットフォームに単一のインターフェイスを提供し、その中で一貫した操作体験を維持することに重点を置いていることです。 私達の目標は、インフラストラクチャーを統合したようにUIを統合することです。 私達はPrismを、データセンターでの仮想化の管理、クラウドでのDesktop-as-a-Serviceの管理、または支出の可視性の提供など、 Nutanixプラットフォームの管理と利用ができる単一のインターフェイスとして提供したいと考えています。
これは、機能やサービスの創造と買収を通してプラットフォームを拡張し続ける上で重要なことです。 新しい機能をただ追加するのではなく、それらをプラットフォームにネイティブに統合するために時間を費やしたいと考えています。 その方が時間はかかりますが、長期的には一貫した操作体験を維持し、リスクを軽減することができます。
要約すると、私達のビジョンはシンプルです。 「どのようなアプリでも、どのような場所でも、1つのプラットフォーム」です。 注:このイメージ図を提供してくれたマーケティング チームに感謝します。これは完璧にフィットしており、私たちの目的を簡潔に述べています。
これは当初から私達の目標でした。 その証明として、以下にあるものが2014年頃に作成されたNutanixプラットフォーム アーキテクチャについて説明するためのイメージ図です。 ご覧のように多くは変わっていませんが、私たちはただ拡大を続け、この目標に向かって努力を続けています。
長年にわたり、Nutanixプラットフォームの機能セットとサービスは大幅に成長してきました。 これは、仮想化技術のシンプル化と抽象化、アップグレードと運用の自動化、その他多くのことを実現するために進化してきました。 このセクションでは、現在のポートフォリオとパートナーシップについて説明します。 注: 最新のポートフォリオと製品については、Nutanix のウェブサイトを参照してください。
長年にわたって製品ポートフォリオが成長してきたので、製品について話すよりも、むしろ私は結果とそれらを達成するための旅に焦点を当てたいと思っています。 以下のステップは、お客様の「旅」と、Nutanix が彼らの達成を支援できる結果をカバーしています。
コア(Core)には、複雑な3層(3-Tier)のインフラストラクチャーからシンプルなHCIプラットフォームへの移行を容易にする、基礎となるNutanix製品が含まれています。 AOSはすべてのコアサービス(ストレージ、アップグレード、レプリケーションなど)を提供し、 Prismはコントロールプレーンと管理コンソールを提供し、AHVは無償の仮想化プラットフォームを提供します(注:ESXi と Hyper-V を使用することもできます)。
コア機能に含まれるもの:
エッセンシャル(Essentials)は、コア インフラストラクチャーをプライベートクラウドのように消費できるようにする機能を提供することに重点を置いています。 Flowはネットワークセグメンテーションとセキュリティを提供し、Filesはファイルサービスを提供し、Calmはセルフサービス、クォータ、そしてオーケストレーション機能を提供します。
エッセンシャル機能に含まれるもの:
エンタープライズ(Enterprise)は、クラウドとクラウドサービス間でワークロードを移行する機能を提供することに焦点を当てている。 これには、クラウドとオンプレミスを横断するコストガバナンスとコンプライアンスに焦点を当てたBeamのような機能や、Frame(DaaS)やXi Leap(DRaaS)といったクラウドサービスが含まれます。
エンタープライズ機能に含まれるもの:
現在、Nutanixは以下のプラットフォームをサポートしています:
ビデオによる解説は、こちらからご覧いただけます: LINK
ハイパーコンバージドシステムには、いくつかの核となる構造があります:
以下の図は、典型的な3層スタック対ハイパーコンバージドの例を示しています:
ご覧のように、ハイパーコンバージドシステムは以下のことを行います:
Nutanixソリューションは、ローカルコンポーネントを活用してワークロードを実行するための分散プラットフォームを作成する、統合ストレージ+コンピューティングのソリューションです。
それぞれのノードで、業界の標準的なハイパーバイザー(現在はESXi、AHV、Hyper-V)およびNutanixコントローラーVM(CVM)を稼動させることができます。 Nutanix CVMは、Nutanixソフトウェアを稼動させ、ハイパーバイザーおよびその上で稼動する全てのVMに対するI/O処理の全てを受け持ちます。
以下は、典型的なノードの論理構成例を図示したものです:
Nutanix CVMは、コアとなるNutanixプラットフォームロジックを担当し、以下のようなサービスを処理します:
注: 一部のサービスや機能は、追加のヘルパーVMを作成したり、マイクロサービスプラットフォーム(MSP)を使用したりします。 例えば、Nutanix Filesは追加のVMをデプロイしますが、Nutanix ObjectsはMSPのためのVMをデプロイし、それらを活用します。
VMware vSphereが動作するNutanixユニットの場合、SSDやHDDデバイスを管理するSCSIコントローラーが、VM-Direct Path(Intel VT-d)を利用して直接CVMに接続されます。 Hyper-Vの場合は、ストレージデバイスがCVMにパススルー接続されます。
Nutanixコントローラーをユーザー空間でのVMとして実行する主な理由は、以下の4領域に分類されます:
はじめから、私達は単一のプラットフォーム企業ではないことを知っていました。 それ故に、ハードウェア、クラウド、ハイパーバイザーベンダーのいずれであっても、選択肢を持つことは常に私たちにとって重要でした。
ユーザー空間でVMとして実行することで、Nutanixソフトウェアをアンダーレイとなるハイパーバイザーおよびハードウェアプラットフォームから切り離します。 これにより、コアのコードベースをすべての運用環境(オンプレミスおよびクラウド)で同じに保ちながら、他のハイパーバイザーのサポートを迅速に追加できました。 そのうえ、ベンダー固有のリリースサイクルに縛られない柔軟性を提供しました。
ユーザー空間でVMとして実行する性質上、ハイパーバイザーの外部にあるため、アップグレードやCVMの「障害」といったものをエレガントに処理できます。 例えば、CVMがダウンするという破滅的な問題が発生した場合でも、ノード全体が、クラスタ内の他のCVMからのストレージI/Oとサービスで引き続き稼働します。 AOS(NutanixのCoreソフトウェア)のアップグレード中でも、そのホストで実行されているワークロードに影響を与えることなくCVMを再起動できます。
しかし、カーネル内にあるほうがより高速ではないでしょうか? 簡潔に答えると、NOです。
よく議論に上がるのは、カーネル内とユーザー空間のどちらにあるかについてです。 これについては、実際の内容とそれぞれの長所と短所を説明する「ユーザー空間とカーネル空間」のセクションを一読することをお勧めします。
要約すると、オペレーティングシステム(OS)には2つの実行空間があり、それは カーネル(特権のあるOSのコアでドライバーが常駐するような場所)とユーザー空間(アプリケーションやプロセスが常駐する場所)です。 慣例上、ユーザー空間とカーネルの間を移動すること(コンテキストスイッチとして知られる)は、CPUと時間(コンテキストスイッチあたり~1,000ns)の面でコストがかかる可能性があります。
その議論では、カーネルにいることは常にベターで速いということですが、これは誤りです。 何があっても、ゲストVMのOSには常にコンテキストスイッチがあります。
分散システムとして不可欠な要素が3つあります:
Nutanixの複数のノードから成るグループが、分散システム(Nutanixクラスタ)を形成し、PrismやAOSの機能を提供します。全てのサービスやコンポーネントは、クラスタ内の全てのCVMに分散され、高い可用性やリニアなパフォーマンスの拡張性能を提供します。
以下の図は、NutanixノードがどのようにNutanixクラスタを形成するのかを例示したものです:
これらのテクニックは、メタデータやデータにも同様に適用されています。全てのノードやディスクデバイスにメタデータやデータを分散することで、通常のデータ投入や再保護を行う際、最大のパフォーマンスが発揮されるようになっています。
これによって、クラスタの能力を最大限に引き出しながら、Nutanixが使用するMapReduceフレームワーク(Curator)が並列処理を行えるようになります。例えば、データの再保護や圧縮、消失訂正号、重複排除といった処理がこれに該当します。
以下の図は、それぞれのノードがどの程度の割合で処理を分担しているのかを示したもので、クラスタの規模が拡大するにつれ、分担割合が劇的に低下していることが分かります:
重要な点: クラスタのノード数が増加(クラスタが拡大)すると、各ノードが負担すべき処理の割合が低下し、処理全体としての効率も向上します。
ソフトウェア デファインド システムには、4つの不可欠な要素があります:
既に何度か説明した通り、Nutanixプラットフォームは、ソフトウェアベースのソリューションであり、ソフトウェアとハードウェアをバンドルしたアプライアンスとして出荷されます。 コントローラーVMには、Nutanixソフトウェアとロジックの大半が組み込まれており、当初から拡張性を持つプラガブルなアーキテクチャーとして設計されたものです。ソフトウェア デファインドとしてハードウェアの構成に依存しないメリットは、その拡張性にあります。製品を既に使用中の場合でも、拡張機能や新機能をいつでも取り入れることができます。
Nutanixは、カスタム仕様のASICやFPGA、またはハードウェア機能に依存しないことで、単にソフトウェア アップデートのみで新しい機能を開発・展開することができます。 これは、データ重複排除などの新機能をNutanixソフトウェアのバージョンをアップグレードすることにより展開できることを意味します。 また、レガシーなハードウェア モデルに対しても、新しい機能の導入を可能にします。 例えば、Nutanixソフトウェアの古いバージョンと、前世代のハードウェア プラットフォーム(例えば2400)でワークロードを稼動させていたと仮定します。 稼動中のソフトウェアバージョンでは、データ重複排除機能を提供しないため、ワークロードはその恩恵にあずかることができません。 このデータ重複排除機能は、ワークロードが稼動中であっても、Nutanixソフトウェアのバージョンをローリング アップグレードすることで利用可能です。 これは非常に簡単な作業です。
このような機能と同様に、新しい「アダプター」あるいはインターフェイスをDSFに向け作成できることも、非常に重要な性能です。 製品が出荷された当初、サポートはハイパーバイザーからのI/Oに対するiSCSIに限定されていましたが、現在では、NFSとSMBもその対象になっています。 将来的には、新しいアダプターを様々なワークロードやハイパーバイザー(HDFSなど)に向けて作成できるようになるでしょう。 繰り返しますが、これらの対応は全てソフトウェアのアップデートで完了します。 「最新の機能」を入手するために、ハードウェアを更改したりソフトウェアを購入したりする必要がある多くのレガシーなインフラストラクチャーとは対照的に、Nutanixではその必要がありません。 全ての機能がソフトウェアで実装されているため、ハードウェア プラットフォームやハイパーバイザーを問わずに稼動させることが可能で、ソフトウェア アップグレードによって新たな機能を実装することができます。
以下は、ソフトウェア デファインド コントローラー フレームワークの論理的な構成を図示したものです:
常にユーザーを主眼に置くNutanix製品は、その導入や使用が極めて容易です。 これは基本的に、抽象化や様々な自動化、さらにソフトウェアの連携機能によって実現されています。
以下にNutanix Clusterの主要コンポーネントを示します。(心配は無用です。全部記憶したり、個々の役割を全て理解したりする必要はありません)
Book of Prismの「Nutanixソフトウェアのアップグレード」および「ハイパーバイザーのアップグレード」セクションで、AOSおよびハイパーバイザーバージョンのアップグレードを実行するために使用される手順を説明しました。 このセクションでは、さまざまなタイプのアップグレードを無停止で実行できるようにする方法について説明します。
AOSのアップグレードでは、いくつかの核となる手順が実行されます:
アップグレード前のチェックでは、以下の項目が確認されます。 注: アップグレードを続行するには、これが正常に完了する必要があります。
アップグレード前のチェックが完了すると、システムはアップグレードソフトウェアバイナリをクラスタ内の2ノードにアップロードします。 これは、耐障害性のためであり、1つのCVMが再起動している場合に、他方のCVMからソフトウェアを取得できるようにします。
ソフトウェアが2つのCVMにアップロードされると、すべてのCVMが並行してアップグレードソフトウェアをステージングします。
CVMには、AOSバージョンのための2つのパーティションがあります:
AOSアップグレードは、非アクティブパーティションでアップグレードが実行されます。 アップグレードトークンを受信すると、アップグレードされたパーティションをアクティブパーティションとしてマークし、CVMを再起動してアップグレードされたバージョンにします。 これは、bootbankとaltbootbankに似ています。
注: アップグレードトークンはノード間で反復的に渡されます。 これにより、一度に1つのCVMのみが再起動します。 CVMが再起動して安定すると(サービスの状態と通信を確認して)、すべてのCVMがアップグレードされるまでトークンが次のCVMに渡されます。
よくある質問として、アップグレードが失敗した場合や、プロセスの途中で問題が発生した場合はどうなるか、というものがあります。
アップグレードの問題が発生した場合は、アップグレードを停止して進行しません。 注: アップグレードが実際に開始される前に、アップグレード前のチェックでほとんどの問題が検出されるため、これは非常にまれです。 ただし、アップグレード前のチェックが成功して実際のアップグレード中に問題が発生した場合、クラスタで実行されているワークロードとユーザーのI/Oへの影響はありません。
Nutanixソフトウェアは、サポートされているアップグレードバージョン間の混在モードで無期限に動作するように設計されています。 例えば、クラスタがx.y.fooを実行していて、それをx.y.barにアップグレードしている場合、システムは両方のバージョンのCVMで無期限に実行できます。 これは、実際にアップグレードプロセス中に発生します。
例えば、x.y.fooの4ノードクラスタがあり、x.y.barにアップグレードを開始した場合、最初のノードをアップグレード開始すると、他のノードがx.y.fooである間にx.y.barが実行されます。 このプロセスは続行され、アップグレードトークンを受け取るとCVMはx.y.barで再起動します。
Foundation(ファンデーション)は、Nutanixクラスタのブートストラップ、イメージング及び導入のためにNutanixが提供しているツールです。 イメージングプロセスにより、目的とするバージョンに対応するAOSソフトウェアやハイパーバイザーをインストールされます。
Nutanixノードには、デフォルトでAHVがプリインストールされており、異なるハイパーバイザーをインストールするためには、Foundationを使用して、該当ノード上に必要とされるハイパーバイザーを再イメージングする必要があります。 注意: 一部のOEMでは、事前に希望するハイパーバイザーがインストールされた形で出荷を行っています。
以下に、Foundationのアーキテクチャー概要を示します:
Foundationは、設定を容易にする目的でAOS 4.5からCVMに組み込まれました。 インストーラーの保存領域は、アップロードイメージを格納するためのディレクトリであり、初期のイメージングに加え、イメージングが必要になるクラスタ拡張でも使用されます。
Foundationディスカバリ アプレット(こちらからダウンロードできます)は、ノードをディスカバリしてユーザーが接続するノードを選択できるようにします。 ユーザーが接続ノードを選択すると、アプレットは localhost:9442のIPv4アクセスを、CVMのIPv6リンクローカルアドレスのポート8000にプロキシします。
以下にアプレットアーキテクチャーの概要を示します:
注意: ディスカバリアプレットは、ディスカバリやノード上で稼動するFoundationサービスにプロキシする1つの手段に過ぎません。 実際のイメージングやコンフィグレーションは、Foundationサービスが行うもので、アプレットではありません。
ターゲットとなるNutanixノードとは異なる(L2)ネットワークを使用している(WAN経由など)場合はディスカバリアプレットが使用できません。 しかしCVMにIPv4アドレスが割り当てられていれば、(ディスカバリアプレットを使わずに)直接Foundationサービスに接続することができます。
直接接続する際には、 <CVM_IP>:8000/gui/index.htmlをブラウズします
Foundationには、以下の入力設定があります。 典型的な導入例では、1ノードあたり3つのIP(ハイパーバイザー、CVM、リモート管理(IPMI、iDRACなど))が必要となります。 さらに、各ノードに対し、クラスタとデータサービスIPアドレスを設定することを推奨します。
注意: (*) が付いた項目はオプションですが、設定することを強く推奨します
最初に、ディスカバリアプレット経由で、FoundationUIに接続します。(同じL2にあればノードIPの入力などは不要です)
目的とするノードが見つからない場合は、同じL2ネットワーク上に存在するかどうかを確認してください。
選択したノードのFoundationインスタンスに接続すると、FoundationUIが表示されます:
ここでは、検出した全てのノードとシャーシが表示されます。 必要なノードをクラスタから選択し「Next(次へ)」をクリックします。
次のページで、クラスタとネットワーク情報を入力します:
詳細の入力が完了したら「Next(次へ)」をクリックします。
次のページで、ノードの詳細とIPアドレスを入力します:
必要に応じてホスト名とIPアドレスを上書きします:
「Validate Network(ネットワークの検証)」をクリックし、ネットワーク設定を確認して次に進みます。 ここでは、IPアドレスに重複がないかを検証し、接続性を確認します。
ネットワークの検証が正常に終了したら、次に必要なインストーラーイメージを選択します。
CVM上の現状のAOSを新しいバージョンにアップグレードするためには、ポータルからダウンロードし、tarball(.tar.gz ファイル)をアップロードします。 必要なAOSイメージを入手したらハイパーバイザーを選択します。
AHVの場合、そのイメージはAOSイメージに含まれています。 その他のハイパーバイザーの場合には、必要なハイパーバイザーのインストーラーイメージをアップロードする必要があります。 注意: AOSとハイパーバイザーのバージョンの組み合わせが、互換表 (リンク) に掲載されたものであることを確認してください。
必要なイメージが揃ったら、「Create(作成)」をクリックします:
イメージングが不要な場合、「Skip(スキップ)」をクリックすれば、イメージング工程を省略することができます。これによってハイパーバイザーあるいはNutanixクラスタが再イメージされることはありませんが、クラスタの設定(IPアドレスなど)は必要です。
次にFoundationは(必要に応じて)イメージングを行い、クラスタ作成プロセスに進みます。
作成が成功すると、完了スクリーンが表示されます:
これでCVMまたはクラスタIPにログインし、Nutanixプラットフォームを利用できるようになりました!
本セクションでは、様々なストレージデバイス(パフォーマンス - NVMe/SSD、キャパシティ - SSD/HDD)がどのように分割および、パーティショニングされ、Nutanixプラットフォームで利用されるかを説明します。 注意: 説明で使用されているキャパシティは、10進法のギガバイト (GB) ではなく、すべて2進法のギガバイト (GiB) を使って表現されています。 また、ファイルシステムのためのドライブのフォーマッティングや、関連するオーバーヘッドも考慮に入れた値になっています。
パフォーマンス デバイスは、ノードで最もパフォーマンスの高いデバイスです。 これらは、NVMe、またはNVMeとSSDデバイスの混合で構成できます。 前述したいくつかの重要な情報が保存されます:
以下に示す図は、Nutanixノードのパフォーマンスデバイスの分割例です:
図の大きさは、実際の値の大きさと一致しているわけではありません。 残りの(Remaining)GiBキャパシティは、上から下方向に数値を計算していった残りで見積ります。 例えば、OpLogで使用可能な残りのGiBを計算する場合は、フォーマット済みSSDのキャパシティから、Nutanix HomeとCassandraのキャパシティを差し引いた値になります。
Nutanix Homeは可用性確保のため最初の2つのSSDにミラーされ、そして2つのデバイスに60GiBを予約します。
AOS 5.0の場合、Cassandraは、各ノードのSSD間(現在、最大4つまで)で、1つのSSDあたり15GiBの初期予約領域(メタデータの容量が増加した場合、一部のStargate SSDを使用可能)と一緒に共有されます。 デュアルSSDシステムの場合、メタデータはSSD間でミラーされます。 SSDあたりのメタデータ予約領域は15GiBとなります(デュアルSSDは30GiB、4つ以上のSSDの場合は60GiB)。
AOS 5.0より前は、Cassandraはデフォルトで最初のSSDにあり、そのSSDに障害発生した場合はCVMが再起動されてCassandraストレージは2番目にあるものになります。 この場合のSSDあたりのメタデータ予約は、最初の2つのデバイスでは30 GiBです。
OpLogはすべてのSSDデバイスに分散され、1ノードあたり最大12までとなります (Gflag: max_ssds_for_oplog)。 NVMe デバイスが使用可能な場合、OpLogはSATA SSDではなくそちら(NVMe デバイス)に配置されます。
ディスクあたりのOpLog予約は、次の式を使用して計算できます: MIN(((Max cluster RF/2)*400 GiB)/ numDevForOplog), ((Max cluster RF/2)*25%) x Remaining GiB)。 注意: リリース 4.0.1から、OpLogのサイズが動的に決定されるようになり、エクステントストアも動的に拡張されるようになりました。 ここで示す値は、OpLogが完全に使用されている状況を前提としています。
例えば、1TBのSSDデバイスが8つあるRF2(FT1)クラスタの結果は次のようになります:
RF3(FT2)クラスタでは下記のようになります:
1TBの4つのNVMeデバイスと8つのSSDデバイスによるRF2(FT1)クラスタの場合、結果は下記のようになります:
エクステントストアの容量は、他のすべての予約が計算された後の残り容量になります。
HDDデバイスは、基本的に大容量ストレージとして利用されるため、その分割はよりシンプルになります:
Prism – プリズム – 名詞 - コントロールプレーン
データセンター運用をワンクリックで可能にするインターフェイス
洗練され、愛着を感じることができる直観的な製品を構築することは、Nutanixプラットフォームの核心であり、私達はそれに真剣に取り組んでいます。 本セクションでは、Nutanixのデザインメソドロジーとその適用について説明します。
また、NutanixのVisioのステンシルはこちらからダウンロードいただけます: http://www.visiocafe.com/nutanix.htm
Prismは分散リソース管理プラットフォームであり、ローカルとクラウドのどちらでホストされているかにかかわらず、 ユーザーがNutanix環境全体のオブジェクトやサービスを管理およびモニターすることができます。
これらの機能は、以下2つの主要なカテゴリに分けられます:
以下は、Nutanixプラットフォームの一部としてのPrismを概念的に図示したものです:
Prismは、2つの主要コンポーネントに分けられます:
以下は、Prism CentralとPrism Elementの関係を概念的に図示したものです:
大規模な環境、あるいは分散環境(例えば1クラスタ以上あるいは複数のサイト)に導入する場合、運用のシンプル化を図るため、Prism Centralを使用し、 全てクラスタやサイトへの対応を1つの管理UIから実施できるようにすることを推奨します。
Prismのサービスは、HTTPリクエストに対応する特定のPrismリーダーと連携しながら、全てのCVM上で動作します。 「リーダー」を持っている他のコンポーネントと同様、Prismリーダーに障害が発生した場合、新しいリーダーが選定されます。 PrismリーダーではないCVMがHTTPリクエストを受け取ると、当該リクエストはPrismリーダーに、HTTPレスポンスステータスコード301を使用して、恒久的にリダイレクトされます。
以下は、PrismのサービスとHTTPリクエストの処理を概念的に図示したものです:
Prismは、ポート80と9440を使用します。HTTPトラフィックがポート80に到達した場合、ポート9440のHTTPS側にリダイレクトされます。
クラスタの外部IPを使用する場合(推奨)、同IPは常に現在のPrismリーダーによってホストされます。 Prismリーダーに障害が発生した場合、クラスタIPは新たに選択されたPrismリーダーが引継ぎ、gratuitous ARP(gARP)は、古くなったARP(stale ARP)のキャッシュ エントリーをクリアするために使用されます。 本シナリオの場合、常にクラスタIPがPrismのアクセスに使用され、既にPrismリーダー内に存在するため、リダイレクトする必要がありません。
最新のPrismリーダーを特定するためには、いずれかのCVMで ’curl localhost:2019/prism/leader’を実行します。
Prismは現在、以下の認証プロバイダーとのインテグレーションをサポートしています:
SAML認証により、PrismはSAML準拠の外部IDプロバイダー(IDP、例えばOkta、ADFSなど)と統合できます。
これにより、プロバイダーサポートするPrismへのログインユーザーで、多要素認証(MFA)や2要素認証(2FA)機能を活用できます。
近日公開
次のセクションでは、典型的なPrismの使用方法と、一般的なトラブルシューティング方法について説明します。
IT運用の世界には、多くのノイズがあります。 従来のシステムでは、大量のアラート、イベント、通知が生成されており、多くの場合にオペレーターは、 a) ノイズに紛れて重要なアラートが表示されないか、 b)アラートやイベントを無視していました。
Nutanixの異常検出により、システムは時系列データ(例えば、CPU使用率、メモリ使用率、レイテンシーなど)の季節的傾向を監視し、期待値の「バンド」を確立します。 「バンド」の外にあたる値のみがイベントやアラートをトリガーします。 エンティティまたはイベントのページから異常によるイベントやアラートを確認できます。
以下のグラフは、システムで大規模なバッチロードを実行した際の、多くのI/Oおよびディスク使用率の異常を示します:
以下は、サンプルメトリックと確立された「バンド」の時系列値を示します:
「通常」状態のアラートは望んでおらず、これにより不要なアラートが削減されます。 例えば、データベースシステムは、通常でもキャッシュなどにより95%を超えるメモリ使用率で実行されます。 万が一、これが低下して10%になると、それは何かよくない(データベースサービスのダウンなど)異常かもしれません。
別の例としては、週末のバッチ処理ワークロードがどのように実行されるかです。 例えば、平日にはI/O帯域幅が低く、しかしながらバッチ処理(例えば、バックアップ、レポートなど)が実行される週末には、I/Oに大きなスパイクが発生する場合があります。 システムはこれの季節性を検出して、週末でのバンドを上げます。
ここでは、値が予想される範囲外であるため、異常イベントが発生したことがわかります:
異常のもう1つの興味深いトピックは、季節性です。 例えば小売業者では、年間の他期間より、ホリデー期間中、または月末の終わりに高い需要が見られます。
異常検出ではこのような季節性を考慮し、以下の期間もとにミクロ(毎日)とマクロ(四半期)の傾向を比較します:
独自のカスタムアラートまたは静的しきい値を設定することもできます:
Nutanixは「Generalized Extreme Studentized Deviate検定」と呼ばれるバンドを決定する手法を利用しています。 これについて簡単に考えると、アルゴリズムによって確立された下限と上限の間にある、値の信頼区間に似ています。
アルゴリズムでは、季節性と期待されるバンドを計算するために、3倍の粒度(毎日、毎週、毎月など)が必要です。 例えばそれぞれの季節性に適応するには、以下の量のデータが必要になります:
Twitterには、彼らがこれをどう活用しているかについての良いリソースがあり、ロジックをさらに詳しく説明しています: LINK
Nutanixソフトウェアのアップグレードは非常に簡単で、システムを停止させる必要もありません。
最初に、Prismにログインし画面の右上にある歯車アイコン(設定)をクリックするか、「S」を押し「ソフトウェアのアップグレード (Upgrade Software)」を選択します:
「ソフトウェアアップグレード (Upgrade Software)」ダイアログが表示され、現在のソフトウェアバージョンと、使用可能なアップグレードバージョンが示されます。また、マニュアルでAOSバイナリファイルをアップロードすることも可能です。
これにより、クラウドからアップグレードバージョンをダウンロード、またはマニュアルでアップロードすることができます:
場合によっては、ソフトウェアをダウンロードしたうえで、CVM自身からアップロードすることができます。 たとえば、ビルドをCVMのローカルにダウンロードするために使用できます。
最初にCVMにSSH接続し、Prismリーダーを見つけます:
curl localhost:2019/prism/leader && echo
PrismリーダーにSSH接続して、ソフトウェアバンドルとメタデータのJSONファイルをダウンロードします。
以下のコマンドを実行して、ソフトウェアをPrismに「アップロード」します:
ncli software upload file-path=<PATH_TO_SOFTWARE> meta-file-path=<PATH_TO_METADATA_JSON> software-type=<SOFTWARE_TYPE>
以下は、Prism Central の例を示します:
ncli software upload file-path=/home/nutanix/tmp/leader-prism_central.tar meta-file-path=/home/nutanix/tmp/leader-prism_central-metadata.json software-type=prism_central_deploy
次に、Nutanix CVMにアップグレードソフトウェアをアップロードします:
ソフトウェアのロードが完了したら、「アップグレード (Upgrade)」をクリックし、アップグレード処理を開始します:
確認のためのボックスが表示されます:
アップグレードの事前チェックが行われ、続いてアップグレードが順次進行します。
アップグレードが完了すると、結果が表示され、全ての新しい機能が利用できるようになります:
現状のPrismリーダーでは、アップグレードの最中、Prismのセッションが一瞬切断されます。 但し、これによってVMやサービスが影響を受けることはありません。
Nutanixソフトウェアのアップグレードと同様に、ハイパーバイザーのアップグレードもPrism経由で順次自動的に進行します。
前述と同様に、「ソフトウェアのアップグレード (Upgrade Software)」ダイアログボックスを表示して、「ハイパーバイザー (Hypervisor)」を選択します。
これで、クラウドからハイパーバイザーのアップグレードバージョンをダウンロード、またはマニュアルでアップロードすることができます:
ハイパーバイザーにアップグレードソフトウェアがロードされます。ソフトウェアがロードされたら、「アップグレード (Upgrade)」をクリックしてアップグレード処理を開始します:
確認のためのボックスが表示されます:
システムがホストのプリアップグレードチェック を行い、ハイパーバイザーをアップロードし、クラスタをアップグレードします:
プリアップグレードチェックが完了すると、ハイパーバイザーアップグレードが順次進行します:
Nutanixソフトウェアのアップグレード同様、各ホストのアップグレードも稼動中のVMに影響を与えることなく、順次進行します。 VMは、現在のホストとは別にライブマイグレーションされ、ホストがアップグレードされる通りブートが行われます。 この処理は、クラスタ内の全てのホストのアップグレードが完了するまで、それぞれのホストに対して繰り返し実行されます。
クラスタ全体のアップグレードステータスは、いずれかのNutanix CVMで、'host_upgrade --status' を実行することで確認できます。各ホストの詳細なステータスは、各CVMの ~/data/logs/host_upgrade.out にログされています。
アップグレードが完了すると結果が表示され、全ての新しい機能が利用できるようになります:
Nutanixクラスタを動的に拡張できることは重要な機能です。Nutanixクラスタを拡張する際には、ノードをラックに格納、スタック後、ケーブルを接続して電源を供給します。ノードに電源が投入された後は、現在のクラスタからmDNSを使用してそれらを検知できるようになります。
図は、既存7ノードのクラスタにおいて新規の1ノードが検知された状態を示しています。
複数のノードについても検知が可能であり、クラスタに対して同時に追加することもできます。
ノードが検知された後、「ハードウェア (Hardware)」ページの右上にある「クラスタの拡張 (Expand Cluster)」をクリックすることで、拡張が開始されます:
クラスタの拡張処理は、歯車アイコンをクリックすることで、どのページからでも実行できます:
これをクリックすると、クラスタ拡張メニューが起動され、追加する(複数の)ノードを選択し、コンポーネントに対するIPアドレスを指定することができます:
ホストを選択すると、追加するノードで使用するハイパーバイザーイメージをアップロードするよう促されます。ハイパーバイザーがAHVの場合、またはイメージが既にFoundation インストーラーストア上に存在する場合、アップロードは必要ありません。
アップロードが完了し、「クラスタの拡張 (Expand Cluster)」をクリックするとイメージングと拡張処理が開始されます:
ジョブがサブミットされ、対応するタスクが表示されます:
タスクを開くと、詳細な進行状況を確認できます:
イメージングとノード追加処理が完了すると、更新されたクラスタサイズ通りソースを確認できます:
パフォーマンスに関するトラブルシューティングを実施する上では、まずボトルネックの特定が重要となります。この対応を支援するためにNutanixでは、新たな「I/Oメトリクス」セクションをVMページに追加しました。
レイテンシーは、様々な変数(キューの深さ、I/Oサイズ、システムの状態、ネットワーク速度など)の積として表現されます。このページでは、I/Oサイズ、レイテンシー、ソースおよびパターンに関するインサイトを提供します。
この新しいセクションを利用するためには、「VM」ページに入り、一覧から必要なVMを選択します。これで、ハイレベルな使用状況のメトリクスが表示されます:
一覧の下にあるセクションに、I/Oメトリクス (I/O Metrics) タブが表示されます:
「I/Oメトリクス」タブを選択すると、詳細ビューが表示されます。ここでは、同ページの詳細と使用方法について説明します。
最初のビューは「平均I/Oレイテンシー(Avg I/O Latency)」で、過去3時間の平均R/Wレイテンシーを表しています。デフォルトでは、対応する詳細メトリクスと共に、その時点での最新の値が表示されます。
また、グラフにポインタを合わせると、過去のレイテンシー値が表示され、グラフ上の時間をクリックすると、以下のようにメトリクスの詳細が表示されます。
これはスパイク、つまり突然数値が跳ね上がっている状態の確認に有効となります。このような状況が見られた場合には、そのスパイク表示をクリックして以下のような詳細情報を評価し、さらに調査を進めることができます。
レイテンシーに全て問題がなければ、それ以上の調査は必要ありません。
次のセクションは、READおよびWRITE I/Oサイズのヒストグラムを表示したものです:
ここでは、READ I/Oが、4Kから32Kのサイズ範囲にあることが分かります:
ここでは、WRITE I/Oについては、ほぼ16Kから64Kに収まっているものの、一部は512Kまでのサイズになっていることが分かります:
数値にスパイクが見られる場合には、まずI/Oサイズを確認します。大きなI/O(64Kから1MB)は、一般的に小さなI/O(4Kから32K)よりも大きなレイテンシーを示します。
次のセクションは、READおよび WRITE I/OのI/Oレイテンシーヒストグラムを示したものです:
READレイテンシーヒストグラムを見ると、ほとんどのREAD I/Oがミリ秒未満 (<1ms) に収まっていますが、一部は2~5msに達していることが分かります。
「Readのソース (Read Source)」を見ると、ほとんどのI/OがSSD層で発生していることが分かります:
データが読み込まれると、ユニファイド キャッシュ(Unified Cache)内にリアルタイムで配置されます(詳しくは、「I/Oパスとキャッシュ」のセクションを参照)。 ここでは、データがキャッシュに配置され、DRAMから提供されている様子が理解できます:
基本的に、全てのREAD I/Oがミリ秒 (1ms) 未満のレイテンシーで行われていることが分かります:
ここでは、ほとんどのWRITE I/Oが、1~2ms未満のレイテンシーで行われていることが分かります:
READレイテンシーにスパイクが見られ、かつI/Oサイズが大きくない場合は、READ I/Oリクエストに対する結果がどこから返されているかを確認します。最初にHDDから読み込む場合は、DRAMキャッシュよりも大きなレイテンシーを示しますが、一度キャッシュに入れば、以降のREADはDRAMに対してヒットするようになり、レイテンシーが改善されます。
以下の最後のセクションでは、I/Oのパターンとランダムとシーケンシャルの比較内容を示しています:
通常、I/Oのパターンはアプリケーションやワークロードによって、様々に異なるものとなっています(例えば、VDIはほとんどがランダムでHadoopは基本的にシーケンシャルなど)。さらに、2つをミックスしたワークロードも存在します。例えばデータベースは、インサートや一部のクエリではランダムですが、ETL処理中はシーケンシャルとなります。
キャパシティプラニングの詳細情報を取得する際には、Prism Centralにある「クラスタランウェイ (Cluster Runway)」セクションで、特定のクラスタをクリックしてください。
この画面は、クラスタランウェイに関する詳細情報や、最も切迫したリソース(制約的なリソース)に関する情報を表示しています。 また、リソースを大きく消費している対象に関する詳細情報や、キャパシティをクリーンアップできる可能性やクラスタ拡張のための適切なノードタイプに関する情報を得ることができます。
日常的な活動を考えると、より多くのことを自動化できます。 私達は日常生活の中でこれを常にルーチンで行っており、テクノロジーによって他の分野と同様のことができます。 Prism ProのX-Playでは、Prismによって一般的なアクティビティのセットを自動化できます。 製品に飛び込む前に、まずは、何をしようとしているのかを説明します。
イベント駆動型の自動化は、以下のように動作します:
イベント → ロジック → アクション
このシナリオでは、一連のアクションまたは一連のアクションをトリガーする、ある種のイベント(または連なっているイベント)が発生します。 これの良い例は、IFTTT(「if this then that」の略語から)であり、イベントを受け取り、いくつかのロジックを適用し、その後いくつかのアクションを実行します。
例えば、家を出るときには家の明かりを消します。 イベント(例えば、家を出る、デバイスが存在しない)をプログラムして、システムがすべてのライトを自動的にオフにするようにトリガーできれば、私たちの生活がはるかに簡単になります。
これをIT運用のアクティビティと比較すると、同様のパターンが見られます。 イベントが発生(例えば、VMがより多くのディスク領域を必要とする)した際、次に一連のアクション(例えば、チケットの作成、ストレージの追加、チケットのクローズなど)を実行します。 これらの反復的なアクティビティは、自動化によって付加価値を付け、より有益なアクティビティに集中できるようにする完璧な例です。
X-Playを使用すると、一連のイベントやアラートを取得し、システムがそれらを捉えて一連のアクションを実行できるようになります。
開始するには、Prism Centralの「Operations」の下にある「Plays」セクションに移動します:
これにより、メインのX-Playページが開きます:
「Get Started」をクリックして現在のプレイを表示するか、新しいものを作成します:
ここから、最初にトリガーを定義して、新しいプレイブックを作成できます:
以下に、カスタムアラートをもとにしたトリガーの例を示します:
トリガーを定義したら、一連のアクションを指定します。以下に、いくつかのサンプルアクションを示します:
アクションの詳細を入力します。これは、REST APIコールのサンプルを示します:
X-Playは、Eメールの送信、Slackメッセージの送信など多くのデフォルトアクションを提供します。REST APIコールの実行なども同様です。
これは、CMDBやチケット管理、自動化ツールのような外部システムとのインターフェイスを考えるときに重要です。 REST APIアクションを使用することは、チケットの作成や解決、ワークフロー開始などのインターフェイスになります。 これは、すべてのシステムを同期させることができるため非常に強力なオプションです。
エンティティやイベント固有の詳細については、「parameters」変数を使用して取得できます:
完了するとプレイを保存でき、定義どおりに実行開始されます。
以下は、複数のアクションが実行されるプレイのサンプルを示します:
Playsタブには、プレイの実行時間とステータスが表示されます:
すべてを自動化することを、忘れずに!
Prismが、シンプルで使いやすい管理インターフェイスを提供するためには、HTML5 UIが不可欠です。 しかし、自動化のためのAPIの提供もまた重要となります。 Nutanixプラットフォームにプログラムインターフェイス機能を提供するため、Prism UIで可能な操作は、REST APIを使っても実装が可能になっています。 お客様やパートナーは、APIを使って自動化を行なったり、サードパーティツールと連携させたり、あるいは独自のUIを作成することも可能です。 以下のセクションでは、インターフェイスと使用例について説明します。
動的な、あるいは「ソフトウェア デファインド」な環境に不可欠なものとして、Nutanixでは、様々なインターフェイスを提供することで、シンプルなプログラミングとインターフェイス機能を実現します。主なインターフェイスには、次のようなものがあります:
API やサンプルコードの詳細については、developer.nutanix.comをご覧ください!
インターフェイスで中心となるのがREST APIであり、オーケストレーションや自動化ツールから、Prism UIとまったく同様な形で該当機能やデータを扱ってNutanixを制御することができます。 REST APIを使用することで、SaltStack、PuppetやvRealize Operations、System Center Orchestrator、Ansibleなどのツールで、容易にNutanixのカスタムワークフローを構築できます。 どんなサードパーティでも、REST APIを使うことで独自のUIを開発し、REST経由でNutanixデータを投入することができます。
以下は、Nutanix REST APIエクスプローラで、開発者がAPIで利用できるスニペットと必要なデータフォーマットを図示したものです:
演算子は、詳細とRESTコールの例を表示するよう展開できます。
4.5.xの時点で、クライアントおよびHTTPコールの認証には、HTTPS経由の基本認証が使用されています。
AOS CLI (ACLI) は、Nutanix製品のAOS部分を管理するためのCLIです。本機能は、AOS 4.1.2以降のリリースで利用できます。
注意: 全ての操作は、HTML5 GUIおよびREST APIから実施可能です。以下のコマンドは、タスク自動化のための追加的な方法として示されています。
説明: ACLIシェルの起動(どのCVMでも可)
acli
または
説明: LinuxシェルからACLIコマンドを実行
acli <Command>
説明: クラスタ内のAOSノード一覧を出力
acli -o json
説明: クラスタ内のAOSノード一覧を出力
host.list
説明: VLANベースのネットワークを作成
net.create <TYPE>.<ID>[.<VSWITCH>] ip_config=<A.B.C.D>/<NN>
例:
net.create vlan.133 ip_config=10.1.1.1/24
説明: ネットワーク一覧出力
net.list
説明: DHCPスコープの作成
net.add_dhcp_pool <NET NAME> start=<START IP A.B.C.D> end=<END IP W.X.Y.Z>
注意: .254は予約されており、AOS DHCPサーバーのアドレスが、ネットワーク作成中に設定されなかった場合に、AOS DHCPによって使用されます。
例:
net.add_dhcp_pool vlan.100 start=10.1.1.100 end=10.1.1.200
説明: ネットワークのVMとVM名、UUID、MACアドレスおよびIPを含む詳細を取得
net.list_vms <NET NAME>
例:
net.list_vms vlan.133
説明: DHCP DNSの設定
net.update_dhcp_dns <NET NAME> servers=<COMMA SEPARATED DNS IPs> domains=<COMMA SEPARATED DOMAINS>
例:
net.set_dhcp_dns vlan.100 servers=10.1.1.1,10.1.1.2 domains=splab.com
説明: VMの作成
vm.create <COMMA SEPARATED VM NAMES> memory=<NUM MEM MB> num_vcpus=<NUM VCPU> num_cores_per_vcpu=<NUM CORES> ha_priority=<PRIORITY INT>
例:
vm.create testVM memory=2G num_vcpus=2
説明: 複数VMの作成
vm.create <CLONE PREFIX>[<STARTING INT>..<END INT>] memory=<NUM MEM MB> num_vcpus=<NUM VCPU> num_cores_per_vcpu=<NUM CORES> ha_priority=<PRIORITY INT>
例:
vm.create testVM[000..999] memory=2G num_vcpus=2
説明: 既存のVMからクローンを作成
vm.clone <CLONE NAME(S)> clone_from_vm=<SOURCE VM NAME>
例:
vm.clone testClone clone_from_vm=MYBASEVM
説明: 既存のVMから複数のクローンを作成
vm.clone <CLONE PREFIX>[<STARTING INT>..<END INT>] clone_from_vm=<SOURCE VM NAME>
例:
vm.clone testClone[001..999] clone_from_vm=MYBASEVM
説明: OS のためのディスクを作成
vm.disk_create <VM NAME> create_size=<Size and qualifier, e.g. 500G> container=<CONTAINER NAME>
例:
vm.disk_create testVM create_size=500G container=default
説明: NICを作成して追加
vm.nic_create <VM NAME> network=<NETWORK NAME> model=<MODEL>
例:
vm.nic_create testVM network=vlan.100
説明: VMのブートデバイスを設定
特定のディスクIDからブートするように設定
vm.update_boot_device <VM NAME> disk_addr=<DISK BUS>
例:
vm.update_boot_device testVM disk_addr=scsi.0
CD-ROMからブートするよう設定
vm.update_boot_device <VM NAME> disk_addr=<CD-ROM BUS>
例:
vm.update_boot_device testVM disk_addr=ide.0
説明: VM CD-ROMにISOをマウント
手順:
ISOでCD-ROMを作成
vm.disk_create <VM NAME> clone_nfs_file=<PATH TO ISO> cdrom=true
例:
vm.disk_create testVM clone_nfs_file=/default/ISOs/myfile.iso cdrom=true
CD-ROMを作成済みの場合はマウントのみを実行
vm.disk_update <VM NAME> <CD-ROM BUS> clone_nfs_file<PATH TO ISO>
例:
vm.disk_update atestVM1 ide.0 clone_nfs_file=/default/ISOs/myfile.iso
説明: CD-ROMからISOを削除
vm.disk_update <VM NAME> <CD-ROM BUS> empty=true
説明: VMを起動する
vm.on <VM NAME(S)>
例:
vm.on testVM
全てのVMを起動
例:
vm.on *
プリフィックスの一致するVMを起動
例:
vm.on testVM*
特定範囲のVMを起動
例:
vm.on testVM[0-9][0-9]
注意: 全ての操作は、HTML5 GUIおよびREST APIから実施可能です。以下のコマンドは、タスク自動化のための追加的な方法として示されています。
説明: NFSホワイトリストに特定のサブネットを追加
ncli cluster add-to-nfs-whitelist ip-subnet-masks=10.2.0.0/255.255.0.0
説明: Nutanixソフトウェアの現在のバージョンを表示
ncli cluster version
説明: 隠れたNCLIコマンド/オプションを表示
ncli helpsys listall hidden=true [detailed=false|true]
説明: 既存のストレージ プール一覧を表示
ncli sp ls
説明: 既存のコンテナ一覧を表示
ncli ctr ls
説明: 新しいコンテナを作成
ncli ctr create name=<NAME> sp-name=<SP NAME>
説明: 既存のVM一覧を表示
ncli vm ls
説明: 既存のパブリックキー一覧を表示
ncli cluster list-public-keys
説明: クラスタアクセスのためのパブリックキーを追加
ncli cluster add-public-key name=myPK file-path=~/mykey.pub
説明: クラスタアクセスのためのパブリックキーを削除
ncli cluster remove-public-keys name=myPK
説明: プロテクションドメインの作成
ncli pd create name=<NAME>
説明: レプリケーションのためのリモートサイトを作成
ncli remote-site create name=<NAME> address-list=<Remote Cluster IP>
説明: 指定したコンテナ内の全てのVMを保護
ncli pd protect name=<PD NAME> ctr-id=<Container ID> cg-name=<NAME>
説明: 指定したVMを保護
ncli pd protect name=<PD NAME> vm-names=<VM Name(s)> cg-name=<NAME>
説明: 指定したDSFファイルを保護
ncli pd protect name=<PD NAME> files=<File Name(s)> cg-name=<NAME>
説明: プロテクションドメインのワンタイムスナップショットを作成
ncli pd add-one-time-snapshot name=<PD NAME> retention-time=<seconds>
説明: n個のリモートサイトに対するスナップショットとレプリケーションの反復スケジュール作成
ncli pd set-schedule name=<PD NAME> interval=<seconds> retention-policy=<POLICY> remote-sites=<REMOTE SITE NAME>
レプリケーションステータスのモニター
ncli pd list-replication-status
説明: プロテクションドメインをリモートサイトにフェイルオーバー
ncli pd migrate name=<PD NAME> remote-site=<REMOTE SITE NAME>
説明: リモートサイトでプロテクションドメインを有効にする
ncli pd activate name=<PD NAME>
説明: DSFシャドウ クローン機能を有効化
ncli cluster edit-params enable-shadow-clones=true
説明: 特定のvDiskに対するフィンガープリンティングと重複排除機能の両方、若しくはフィンガープリンティングのみを有効化
ncli vdisk edit name=<VDISK NAME> fingerprint-on-write=<true/false> on-disk-dedup=<true/false>
ノードのステータス
ncli cluster get-domain-fault-tolerance-status type=node
ブロックのステータス
ncli cluster get-domain-fault-tolerance-status type=rackable_unit
以下では、Nutanix PowerShell コマンドレットの使用方法、および前提となるWindows PowerShellについて説明します。
Windows PowerShellは、.NETフレームワークに実装された(その名の通りの)強力なスクリプト言語です。 使い方は非常にシンプルかつ直観的でインタラクティブな操作が可能です。PowerShellには、いくつかの構成要素があります:
コマンドレットは、特定の処理を行うためのコマンドまたは .NETのクラスです。 ほとんどの場合、Getter/Setterメッソドに従い、また通常 <Verb>-<Noun> という構文を使用します。 例えば、Get-ProcessやSet-Partitionなどが該当します。
パイプラインはPowerShellの重要な機能(同様な機能がLinuxにもあります)であり、正しく使えば様々なことがシンプルになります。 パイプラインを使用することで、一方の出力をもう一方の入力にすることができます。 パイプラインは必要に応じていくらでも連結することができます(パイプラインの出力が次のパイプラインの入力になる等)。 簡単な例として、現在のプロセス一覧を取得し、その特性でマッチングまたはフィルタリングし、最後にソートするという処理を以下に示します:
Get-Service | where {$_.Status -eq "Running"} | Sort-Object Name
パイプラインは、for-each文でも使用できます。例えば次のようになります:
# For each item in my array
$myArray | %{
# Do something
}
以下にPowerShellの主要なオブジェクトタイプを示します。 オブジェクトタイプは、.getType() メッソドで確認できます。 例えば、$someVariable.getType() はオブジェクトタイプを返します。
$myVariable = "foo"
注意: 変数には、一連のコマンドまたはパイプラインのアウトプットも設定できます。
$myVar2 = (Get-Process | where {$_.Status -eq "Running})
この例では、カッコの中のコマンドの結果がまず求められ、そのアウトプットが変数となります。
$myArray = @("Value","Value")
注意: 配列、ハッシュテーブルまたはカスタムオブジェクトの配列も使用できます。
$myHash = @{"Key" = "Value";"Key" = "Value"}
特定のコマンドレットのヘルプ内容を取得します(Linuxの manページと同様)。
Get-Help <コマンドレット Name>
例:
Get-Help Get-Process
コマンドまたはオブジェクトのプロパティとメソッド一覧を表示
<Some expression or object> | Get-Member
例:
$someObject | Get-Member
Nutanix コマンドレットをダウンロードします。Nutanix コマンドレットは、Prism UI (4.0.1以降)の右上のドロップダウンリストから、直接ダウンロードすることが可能です。
スナップインがダウンロードされているかどうかを確認し、実施されていなければダウンロードを行います。
if ( (Get-PSSnapin -Name NutanixCmdletsPSSnapin -ErrorAction SilentlyContinue) -eq $null
)
{
Add-PsSnapin NutanixCmdletsPSSnapin
}
Get-Command | Where-Object{$_.PSSnapin.Name -eq "NutanixCmdletsPSSnapin"}
Connect-NutanixCluster -Server $server -UserName "myuser" -Password (Read-Host "Password: " -AsSecureString) -AcceptInvalidSSLCerts
変数に対して出力
$searchString = "myVM"
$vms = Get-NTNXVM | where {$_.vmName -match $searchString}
インタラクティブ
Get-NTNXVM | where {$_.vmName -match "myString"}
インタラクティブおよびフォーマット設定
Get-NTNXVM | where {$_.vmName -match "myString"} | ft
変数に対して出力
$vdisks = Get-NTNXVDisk
インタラクティブ
Get-NTNXVDisk
インタラクティブおよびフォーマット設定
Get-NTNXVDisk | ft
変数に対して出力
$containers = Get-NTNXContainer
インタラクティブ
Get-NTNXContainer
インタラクティブおよび書式設定
Get-NTNXContainer | ft
変数に対して出力
$pds = Get-NTNXProtectionDomain
インタラクティブ
Get-NTNXProtectionDomain
インタラクティブおよび書式設定
Get-NTNXProtectionDomain | ft
変数に対して出力
$cgs = Get-NTNXProtectionDomainConsistencyGroup
インタラクティブ
Get-NTNXProtectionDomainConsistencyGroup
インタラクティブおよび書式設定
Get-NTNXProtectionDomainConsistencyGroup | ft
免責事項: すべてのコード サンプルは © Nutanix, Inc. であり、MITライセンス(https://opensource.org/licenses/MIT)のもとで現状のまま提供されます。
Acropolis – アクロポリス – 名詞 – データプレーン
ストレージ、サーバー、仮想化プラットフォーム
Acropolis Operating System(AOS)は、プラットフォーム上で実行されているワークロードやサービスによって利用される中核的な機能を提供します。 これには、ストレージサービス、アップグレードといったものが含まれますが、これらに限定されません。
この図は、様々なレイヤーにおけるAOSの概念的性質のイメージを示しています:
Nutanixでは、全てを分散するという設計方針に基づき、この考え方を仮想化とリソース管理の分野にまで拡張しました。 AOSは、ワークロードやリソースを管理、プロビジョニング、運用するためのバックエンド サービスです。 目的は、稼動しているワークロードをNutanixがサポートするリソース(ハイパーバイザー、オンプレミスやクラウドなど)から分離して抽象化し、運用する1つの「プラットフォーム」を提供しようというものです。
これによって、ワークロードをハイパーバイザー、クラウド プロバイダーやプラットフォーム間でシームレスに移動させることが可能となります。
AOS 4.7現在、VM管理機能がサポートするハイパーバイザーは、AHVとESXiに限定されていますが、将来的には拡大される予定です。 但し、Volumes APIとREADオンリーの操作は、現在でも全てがサポートされています。
Acropolisワーカーは、全てのCVM上で、タスクのスケジューリング、実行、IPAMなどを行う選出されたAcropolisリーダーと共に稼動します。 他のリーダーを持つコンポーネントと同様、Acropolisリーダーに障害が発生した場合は、新しいリーダーが選出されます。
各機能の役割を以下に示します:
以下は、Acropolisリーダーとワーカーの関係を概念的に図示したものです:
リソースを効果的に使うためには、リソースの効率的なスケジューリングが重要となります。 AOS Dynamic Schedulerでは、サーバー使用状態(CPU/メモリ)を根拠にした従来のスケジューリング方法を拡張し、より正確な決定ができるようになっています。 ここでは、サーバーのみでなくストレージやその他の状態を見て、VMやボリューム(ABS)のプレースメント判断を行います。 これにより、リソースを効果的に使用し、エンドユーザーのパフォーマンスを最適化することができます。
リソースのスケジューリングは、2つの主要な部分に分かれます:
オリジナルのAOS Schedulerが最初にリリースされた際には、初期プレースメントのみを考慮していました。 AOS 5.0でのリリースにより、AOS Dynamic Schedulerは、実行時にもリソースの最適化が図られるよう拡張されました。
以下にスケジューラーのアーキテクチャーの概要を示します:
ダイナミックスケジューラー (Dynamic Scheduler) は、終日稼動し続けてプレースメントの最適化を行います (現在は15分毎 | Gflag: lazan_anomaly_detection_period_secs)。 推定要求値は、平滑化アルゴリズムを使って使用状況の遷移を計算します。 ワークロードの移動判断に推定要求値を使用することで、使用率のスパイク(一瞬の数値の跳ね上がり)に引きずられないようにします。
既存のスケジューリングや最適化のためのプラットフォーム(VMware DRS、Microsoft PRO)を見ると、 全てワークロードのバランシングや、クラスタリソースに対するVMの配置平滑化に焦点を当てています。 注意: バランスの悪さをいかに積極的に解消するかは、バランシングの設定によります(例えば、manual -> none, conservative -> some, aggressive -> more)。
例えば、クラスタ内に3つのホストがあり、それぞれの使用率が50%、5%、5%だと想定します。典型的なソリューションは、ワークロードをリバランスして、それぞれが ~20%となるように調整します。なぜでしょうか?
私達が行おうとしているのは、リソースの競合が発生しないようにすることであり、非対称性を解消することではありません。リソースの競合がなければ、ワークロードを「バランシング」する積極的な理由は存在しません。実際に、ワークロードの不必要な移動を行おうとすると、必要な追加処理(メモリの転送、キャッシュの再ローカライズ等)が発生し、リソースを消費することになります。
AOS Dynamic Schedulerでは、この問題に対応すべく、非対称性の発生ではなく想定したリソース競合が発生した場合に限りワークロードを移動させています。 注意: DSFは、ホットスポットの発生を回避したり、リビルドの速度を上げたりするために、データをクラスタ全体に均一に分散させるという異なる方法を取っています。 DSFに関するより詳細な内容については、「ディスクバランシング」セクションをご覧ください。
ADSは起動時に、クラスタ全体でVM初期プレースメントのバランシングを行います。
以下の要因によってプレースメントの決定が行われます:
スケジューラーは、前述のルールに従ってワークロードが最適なプレースメントとなるよう最善を尽くします。システムには、移行が過度に発生しないよう制限が設けられています。これによって、移行がワークロードに悪影響を及ぼさないようにしています。
移行完了後、その「効果」をシステムが判定して実際のメリットを確認します。この学習モデルによって自己最適化が可能となり、移行判定のための妥当性をより向上させることができます。
セキュリティは、Nutanixプラットフォームのコアとなる部分であり、常に注意が払われています。 Nutanix Security Development Lifecycle(SecDL)は、開発プロセスの全てのステップで採用されています。 システムは、工場から出荷された時点でセキュリティが確保された状態にあり、 プラットフォームのNutanixによって制御されている部分は、箱から出したときに安全な状態で、エンドユーザーが後からセキュリティを「強化する」必要はありません。
セキュリティについて考えるとき、私たちは本当に達成しようとしているものは3つの核となること(CIAトライアドと呼ばれる)です:
これは単純な説明に簡略化でき、つまりは、ユーザーが悪意のある人を排除しながら仕事をできるようにします。 セキュリティを設計するときは、以下の図で強調されているいくつかの重要な領域を考慮する必要があります:
以降のセクションでは、前掲の図の各セクションを分類します。
従来、人々は「ハードニング(hardening)」と呼ばれる手法でシステム(OS +アプリ)のセキュリティを参照しています。 これは、ベースラインと呼ばれる特定の標準に構成することで、システムを安全にするプロセスです。
DoD(アメリカ国防総省)のIT組織(DISA)には、STIGと呼ばれるサンプルのハードニングガイドがあります(詳細は以降にあるSCMAセクションを参照してください)。 これには、ディレクトリのアクセス許可、ユーザーアカウント管理、パスワードの複雑さ、ファイアウォール、その他の多くの構成設定などが含まれます。
システムがその標準に設定されると「安全」と見なされますが、それはプロセスの始まりにすぎません。 システムのセキュリティは、その寿命を通して維持する必要があるものです。 例えば、標準のハードニングベースラインが確実に満たされるようにするには、構成自動化ツールを使用する必要があります。 これにより、システムは常にベースラインの「望ましい状態」を満たします。
Nutanixは、このセクションの後半で説明する、自身で開発したSCMAと呼ばれるツールを使用してCVMとAHVハイパーバイザーに対してこれを保証しています。
データはあらゆるビジネスの中核であり、間違いなく会社の最も貴重な資産です。 セキュリティについて考えるとき、データのアクセシビリティ、品質、および盗難回避を確保することに焦点をあてる必要があります。
アクセシビリティの概念においては、意思決定を行うためにシステムとデータへのアクセスが常に必要です。 「ランサムウェア」と呼ばれる最近の攻撃手法は、データ暗号化によってデータにアクセスする能力を脅かし、ユーザーがアクセスを取り戻すための身代金を要求します。 これはさまざまな方法で回避できますが、バックアップの重要性を強調することにもなります。
データの品質についても、多くの決定またはアクションが依存するため重要な項目です。 例えば、攻撃者がシステムにアクセスすることで、悪意のある注文をしたり、配送先住所を自身の場所に変更して商品を流用したりします。 これは、データをクリーンな状態に保つために、ロギングとチェックサム確認が非常に重要となりうるところです。
最後に重要なことは、データをどのように安全または強固なものにするかです。 これは一般的に、暗号化によって行われ、データ復号化キーがない場合にはデータが役に立たなくなります。 この場合、誰かが暗号化されたファイルまたはディスクデバイスを盗むと、元となるデータにはアクセスできなくなります。
ネットワークは、攻撃者がシステムにアクセスするために使用する典型的な通信経路です。 これには、境界セキュリティ(例えば、外部ファイアウォール)や、内部への侵入防止および検出が含まれます。
他の優れた設計と同様に常にセキュリティの層があるべきで、 同じことがネットワークにも当てはまります。 高セキュリティのネットワークを信頼できるネットワークからセグメント化する必要があり、それらを信頼できないネットワーク(例えば、業務やWi-Fiネットワーク)から保護します。 オフィスのローカルネットワークがセキュアであると想定することは決して安全ではありません。
複数層のネットワークを持つことにより、最も信頼されていないネットワークにアクセスする誰かが、安全なネットワークに向けて作業することをより困難にすることができます。 このプロセスにおいて、優れたIDPSシステムは、異常なアクセスや、nmapのようなスキャンツールを検出できます。
認証とは、Active Directoryやその他のIDP(IDプロバイダー)などの信頼できるソースによって、ユーザーの身元を認証することです。 MFA(多要素認証)や2FAのようなツールは、認証しようとしているユーザーがその人自身であることについて、さらに保証を追加します。
身元が確認されたら、次は、ユーザーが行うことが許可されているかどうか、ユーザーが何にアクセスできるかを決定します。これは認可の部分です。 ユーザーfooは、barでのxとy、basでのyとzを行うことを認可されているといったものです。
コンプライアンスとは、一般的にPCIやHIPAAのような特定の認定をするときに参照されるものです。 しかし、これはハードニングガイドや基準へのコンプライアンスを満たすことにまで拡張されます。 例えば、STIGはハードニングのベースラインとなるサンプルですが、各企業では追加のポリシーやルールを設けている場合があります。 安全なシステムを確保するためには、システムがこれらのポリシーを満たし、コンプライアンスを遵守した状態にしておかなければなりません。
伝統的に、コンプライアンスは遡及的に確認され、かなり手動によるプロセスです。 これは絶対に間違ったアプローチだと思います。 コンプライアンスは、潜在的な脅威ベクタ確実に制限したり、開いている可能性のあるものを閉じたりする唯一の方法であり、常に確保しなければならないものです。
ここでは、構成管理の自動化(別名は、desired state configuration - DSC)を処理するツールが重要なピースです。 これらにより、構成や設定が常にベースラインまたは目的の状態に設定されます。
監視と侵入のテストは、このコンプライアンスを検証および保証するために重要です。 Nessus、Nmap、metasploitのようなツールを使用して、システムのセキュリティをテストできます。 これらのテスト中、監視および検出システムは、これらを検出してアラート通知をする必要があります。
どのシステムにおいても、人間は伝統的に最も弱いリンクです。 ユーザーがフィッシング攻撃やソーシャルエンジニアリングに陥らないようにするには、トレーニングと教育が重要です。 ユーザーが何を探すべきかを確実に把握して、不明な場合は既知のリソースを案内する必要があります。
教育の1つの方法は、実際にフィッシング攻撃をシミュレートすることであり、彼らに質問を投げかけることで何を探すべきかを学習できます。 また、ロック解除した状態やパスワードを書き留めたままでコンピューターを離れない、といった他のポリシーも強制する必要があります。
Nutanixでは、スタック(オンプレミスおよびオフプレミス)の部分にわたり次のようなセキュリティ認証や認定を有しています:
Nutanixのセキュリティ エンジニアリング チームは、特定時点でしか対応できなかったセキュリティベースラインのチェックを刷新し、導入ライフサイクルのあらゆる局面を通じて、クラスタ内の全てのCVM/AHVホストが継続的なモニタリングを行い、ベースラインに対する自己修復をできるようにしました。 これによって、セキュリティ基準(STIG)に記載された全てのセキュリティベースラインのコンポーネントチェックが可能となり、未準拠となっている部分を検知して、ユーザーに影響を及ぼすことなく、サポートされたセキュリティ設定に戻すことができます。 SCMAはデフォルトで有効化されるので、有効化のための作業は不要です。
SCMAは、設定済みスケジュール(デフォルト:一時間毎)に従って実行されますが、オンデマンドで実行することも可能です。SCMAツールは、以下のコマンドを使ってCVMから実行することができます。
1台のCVMでの実行
sudo salt-call state.highstate
すべてのCVMでの実行
allssh "sudo salt-call state.highstate"
Nutanix Command Line Interface (NCLI) を使用することで、様々な設定が可能となり、厳しいセキュリティ要件にも対応することができます。
以下のコマンドは、クラスタ全体にSCMAポリシーを設定するためにNCLIに追加されたコマンドです。該当コマンドとその機能を以下に示します:
CVMセキュリティ設定の表示
ncli cluster get-cvm-security-config
このコマンドは、現状のクラスタ設定内容を出力します。デフォルトの出力内容は以下の通りです:
Enable Aide : false Enable Core : false Enable High Strength P... : false Enable Banner : false Enable SNMPv3 Only : false Schedule : DAILY
それぞれは以下のように定義されています:
CVMログインバナーの設定
このコマンドを使うことで、Nutanix CVMにログインする際に、DoD(米国防総省)の同意内容 (DoD knowledge of consent) に関するログインバナーを表示するかどうかを設定できます。
ncli cluster edit-cvm-security-params enable-banner=[yes|no]
デフォルトでは、DoD同意内容バナーが使用されます。カスタムのバナーを使用したい場合は、以下の手順に従います(いずれのCVMについてもNutanixユーザーとして実行)。
sudo cp -a /srv/salt/security/KVM/sshd/DODbanner /srv/salt/security/KVM/sshd/DODbannerbak
sudo vi /srv/salt/security/KVM/sshd/DODbanner
CVMパスワードの強度設定
このコマンドで、高強度パスワードポリシー (minlen=15,difok=8,remember=24) の適用を有効化または無効化できます。
ncli cluster edit-cvm-security-params enable-high-strength-password=[yes|no]
Advanced Instruction Detection Environment (AIDE) の設定
このコマンドで、週次に実行するAIDEサービスを有効化または無効化できます。
ncli cluster edit-cvm-security-params enable-aide=true=[yes|no]
SNMPv3限定の設定
このコマンドで、SNMPv3限定トラップを有効化または無効化できます。
ncli cluster edit-cvm-security-params enable-snmpv3-only=[true|false]
SCMAスケジュールの設定
このコマンドでSCMAの実行頻度を設定できます。
ncli cluster edit-cvm-security-params schedule=[HOURLY|DAILY|WEEKLY|MONTHLY]
以下のコマンドは、SCMAポリシーをクラスタ全体に設定するためにNCLIに追加されたコマンドです。該当コマンドと機能を以下に示します:
ハイパーバイザーのセキュリティ設定を表示
ncli cluster get-hypervisor-security-config
このコマンドは、現状のクラスタの設定内容を出力します。デフォルトの出力内容は以下の通りです:
Enable Aide : false Enable Core : false Enable High Strength P... : false Enable Banner : false Schedule : DAILY
ハイパーバイザー ログインバナーの設定
このコマンドを使うことで、Nutanixハイパーバイザーにログインする際に、DoD(米国防総省)の同意内容 (DoD knowledge of consent) に関するログインバナーを表示するかどうかを設定できます。
ncli cluster edit-hypervisor-security-params enable-banner=[yes|no]
ハイパーバイザー パスワード強度設定
このコマンドで、高強度パスワードポリシー (minlen=15,difok=8,remember=24) の適用を有効化または無効化できます。
ncli cluster edit-hypervisor-security-params enable-high-strength-password=[yes|no]
Advanced Instruction Detection Environment (AIDE) の設定
このコマンドで、週次に実行されるAIDEサービスを有効化または無効化できます。
ncli cluster edit-hypervisor-security-params enable-aide=true=[yes|no]
SCMAスケジュールの設定
このコマンドで、SCMAの実行頻度を設定できます。
ncli cluster edit-hypervisor-security-params schedule=[HOURLY|DAILY|WEEKLY|MONTHLY]
クラスタ ロックダウン (Cluster lockdown) は、パスワードベースのCVMアクセスを無効化、またはキーベースのアクセスのみを有効化する機能です。
クラスタ ロックダウンの設定内容については、歯車アイコンのメニューにあるPrismから確認することができます:
現在の設定内容が表示され、アクセスに必要なSSHキーを追加、削除することができます:
キーを追加するためには「New Public Key(新規パブリックキー)」ボタンをクリックし、キーの詳細内容を入力します:
SSHキーを生成するためには、次のコマンドを実行します:
ssh-keygen -t rsa -b 2048
これで2つのキーペアが作成され、2つのファイルが生成されます:
キーを作成し、これを使ってアクセスできることが確認されれば、「Enable Remote Login with Password(パスワードを使ったリモートログインを有効化する)」のチェックを外し、 パスワードベースのログインを無効化することが可能となります。確認のポップアップが表示されたら、「OK」をクリックしてロックダウンを有効化します。
データの暗号化とは、許可を受けた人のみがデータを理解でき、許可を受けていない人には意味不明なものにするためのデータのエンコード方法です。
例えば、メッセージを1人だけに送信する必要がある場合には、メッセージ(平文)を暗号(キー)で暗号化して、暗号化されたメッセージ(暗号文)を送信できます。 仮に、このメッセージが攻撃側に盗まれたり盗聴されたりしても、暗号化されたメッセージを、キーを使って復号化できなければ、暗号文を目にするだけとなります。 正しい相手がメッセージを受け取ると、送り手が提供したキーを使ってメッセージを復号化することができます。
データの暗号化には、いくつかの方法が存在します:
注意: PGP(またはGPG)は、パブリリックキーとプライベートキーの両方を使用します。
データの暗号化は、主に次のような状況で使用されます:
Nutanixは、ネイティブなソフトウェアベースの暗号化によって、(SEDの有無にかかわらず)転送中*、および保存時における暗号化の両方を解決します。 SEDのみをベースとした暗号化では、Nutanixは保管時のデータ暗号化を解決します。 *注:転送中の暗号化は、現在、Nutanixクラスタ内のデータRFに適用できます。
以下のセクションでは、Nutanixのデータ暗号化の方法と、キー管理オプションについて説明します。
Nutanixは、主に3つの方法でデータの暗号化をサポートしています:
暗号化は、ハイパーバイザーのタイプに応じて、クラスタまたはコンテナ単位で設定することが可能です:
注意: SEDを使用する場合、物理デバイスが自ら暗号化を行うため、暗号化の設定はクラスタ単位となります。
クラスタの暗号化の状況は、設定メニュー(歯車アイコン)から「Data-at-Rest Encription(保存データの暗号化)」を選択して確認できます。 ここで現在の状況確認と、暗号化の設定(現在有効化されていない場合)を行うことができます。
こちらは、クラスタ単位で暗号化が有効になっている例です:
この例では、一覧にある特定のコンテナで暗号化が有効になっています:
「edit configuration(設定の編集)」ボタンをクリックすれば、設定を有効化または変更することができます。 暗号化に使用されているKMSの設定、または現在使用中のKMSのタイプを設定するメニューが表示されます。
外部のKMSを使用している場合は、このメニューのCSRリクエスト処理を使って、証明書を承認のためCA(認証局)に渡すことができます。
Nutanixのソフトウェア暗号化機能によって、保存データをAES-256でネイティブに暗号化することができます。 また、KMIPまたはTCG準拠の外部KMSサーバー(VormetricやSafeNetなど)や、AOS 5.8で発表されたNutanixネイティブのKMSともやり取りが可能です(以下に詳細)。 また、ソフトウェアによる処理の影響を最小限に抑えるため、システムはIntel AES-NIアクセラレータを使用して暗号化と復号化を行っています。
データが(OpLogやエクステントストアに)書き込まれると、チェックサムの境界でディスクに書き込まれる前に暗号化されます。 これは、データがローカルで暗号化され、そして暗号化されたデータがRFによってリモートのCVMに複製されることも意味します。
暗号化は、ディスクにデータが書き込まれる直前に実施されます。
重複排除と圧縮を行った後に暗号化を行うため、これらの手段によるスペースの節約状態はそのまま維持されます。 簡単に言えば、重複排除と圧縮の比率は、データを暗号化してもしなくてもまったく同じだということです。
チェックサムの境界でディスクから読み込まれた暗号化データは、復号化されてゲストに返されます。 復合化/暗号化をチェックサムの境界ごとに実施することで、読み込み増幅 (Read Amplification、余分な追加読み込み処理) が発生することはありません。 また、Intel AES-NIによって処理がオフロードされるため、パフォーマンスやレイテンシーにほとんど影響を与えることがありません。
アーキテクチャーの概要を以下に図示します:
SED暗号化は、ストレージデバイスを安全な状態 (secured) または非安全な状態 (un-secured) のいずれかの状態にある、「データバンド (data bands)」に分解することで機能します。 Nutanixの場合には、ブートとNutanix Homeのパーティションを明示的に暗号化します。 全てのデータデバイスとバンドについては、Level-2に適合するよう、bit数の長いキー(big keys)を使った高度な暗号化が行われます。
クラスタが起動すると、KMSサーバーとのやり取りを行い、ドライブのロックを解除するためのキーを入手します。 安全性を確保するため、クラスタでキーをキャッシュすることはありません。コールドブートやIPMIリセットの場合、ノードはKMSサーバーをコールバックし、ドライブのロックを解除する必要があります。 CVMのソフトブートでは、この状況は発生しません。
Nutanixは、他の専用KMSソリューションが提供する場合と同等の、キー管理機能(ローカルキー管理 - LKM)とストレージ機能(AOS 5.8から)をネイティブに提供しています。 これにより、専用のKMSソリューションが不要となり、システム環境をシンプル化できますが、外部のKMSのサポートも継続しています。
前のセクションで説明したように、キー管理はあらゆるデータ暗号化ソリューションにとって極めて重要な部分です。 非常にセキュアなキー管理ソリューションは、スタック全体で複数のキーを使用しています。
ソリューションで使用されるキーには、3つの種類があります:
以下の図で、それぞれのキーの関係とKMSオプションを説明します。
ローカルキーマネージャー (LKM) サービスは、すべてのNutanixノードに分散され、各CVMでネイティブに稼動します。 このサービスでは、FIPS 140-2暗号モジュールを(承認のもと)使用し、あらゆるキーの管理(キーの更新、キーのバックアップなど)をエンドユーザーに透過的に行うことができます。
データ暗号化の設定を行う場合、「Cluster’s local KMS(クラスタのローカルKMS)」を選択すれば、ネイティブのKMSを使用することができます:
マスターキー (MEK) は、シャミアの秘密分散法を使って分割され、クラスタのノード全体に保存されることで、耐障害性とセキュリティが確保されます。 キーを再構成する際には、Nをクラスタのノード数とした場合、最低でも ROUNDUP(N/2) (ノード数を2で割って小数点以下を切り上げた数)のノードが必要になります。
暗号化を有効にした場合、データ暗号化キー (DEK) のバックアップを取っておくことをお勧めします。 バックアップを取った場合、強力なパスワードを設定し、安全な場所に保管するようにしてください。
KEKとMEKのローテーション(キー更新)をシステムで行うことが可能です。 マスターキー (MEK) を毎年自動的にローテーションするほか、必要に応じていつでもローテーションすることができます。 ノードを追加または削除した場合も、マスターキーのローテーションが行われます。
分散ストレージ ファブリック(DSF)は、ハイパーバイザーから集中ストレージアレイのように見えますが、全てのI/Oをローカルで処理することで最大のパフォーマンスを発揮します。 ノードがどのように分散システムを形成するかについての詳細は、次のセクションで説明します。
Nutanix分散ストレージ ファブリック(DSF)は、以下の要素で構成されています:
DSF/Stargate側でvDiskのサイズに理論的な制限を加えることはありません。 AOS 4.6では、vDiskサイズは64ビット符号付整数を使ったバイト単位で表現されていました。 つまり、論理的なvDiskの最大サイズは、2^63-1 または 9E18 (9 Exabytes) となります。 この値を下回る制限があるとすれば、それはESXiの最大vmdkサイズなど、クライアント側の問題になります。
以下は、DSFとハイパーバイザーの関係を図示したものです:
以下は、前述の構成要素と各ファイルシスムの対応関係を図示したものです:
これらのユニットの関係は、以下のように図示することもできます:
ビデオによる解説はこちらからご覧いただけます: LINK
一般的なハイパーコンバージドなストレージI/Oパスは、以下の層に分類できます:
NutanixのI/Oパスは、以下のコンポーネントで構成されています:
CVM内では、StargateプロセスがすべてのストレージI/Oリクエストと、他のCVMや物理デバイスとの相互作用の処理を担当します。 ストレージデバイスコントローラーは直接CVMにパススルー接続されるため、すべてのストレージI/Oはハイパーバイザーをバイパスします。
以下の図は、これまでのI/Oパスの概要を示します:
Nutanix BlockStore(AOS 5.18で出荷)はAOSの機能で、すべてがユーザー空間で処理される拡張可能なファイルシステムとブロック管理レイヤーを作成します。 これにより、デバイスからファイルシステムが排除され、ファイルシステムカーネルドライバーの呼び出しが削除されます。 新しいストレージメディア(例えば、NVMe)の導入により、 デバイスにはユーザー空間のライブラリが付属し、デバイスI/Oを直接処理(例えばSPDKで)することで、システムコール(コンテキストスイッチ)を行う必要がなくなりました。 BlockStoreとSPDKの組み合わせにより、すべてのStargateによるデバイスの相互作用がユーザー空間に移動し、コンテキストスイッチやカーネルドライバーの呼び出しが排除されました。
以下の図は、BlockStoreとSPDKを使用してアップデートされたI/Oパスの概要を示します:
データ複製を実行するために、CVMはネットワークを介して通信します。 デフォルトのスタックでは、これはカーネルレベルのドライバーが呼び出されます。
しかし、RDMAを使用するとNICはハイパーバイザーのすべてをバイパスしてCVMにパススルー接続されます。 また、CVM内では、RDMAを使用するすべてのネットワークトラフィックは制御パスにカーネルレベルのドライバーのみを使用するため、実際のすべてのデータI/Oは、コンテキストスイッチなしでユーザー空間にて行われます。
以下の図は、RDMAを使用したI/Oパスの概要を示します:
要約すると、拡張機能は以下のように最適化されます:
CVM内のStargateプロセスは、ユーザーVM(UVM)からの全てのI/O処理と永続化(RFなどによる)をハンドリングする責任を持ちます。 書き込みリクエストがStargateに届くと、そこには書き込み特性化の機能があり、突発的なランダム書き込みであればOpLog、持続的なランダム書き込みまたはシーケンシャルな書き込みであればエクステントストアに永続化します。 読み取りリクエストは、リクエストされた際にデータが存在する場所によって、OpLogまたはエクステントストアから読み取られます。
NutanixのI/Oパスは、以下の大まかなコンポーネントで構成されます:
*AOS 5.10以降は、Autonomous Extent Store(AES)を使用して、必要条件が満たされたときにサステイン状態のランダムなワークロードを処理できます。
Oplogは共有リソースですが、それぞれのvDiskが平等に利用できるように、vDisk単位での割り当てが行われます。 AOS 5.19より前は、OpLogのサイズはvDiskごとに6GBに制限されていました。 AOS 5.19以降は、個々のvDiskのOpLogは、IOパターンの要求に従ってノードごとに使用されるOpLogインデックスメモリの上限まで、6GBを超えて拡張し続けることができます。 この設計上の決定により、I/Oの観点でアクティブなvDiskが少ない仮想マシンがある場合、アクティブでない他のvDiskを費やして、必要に応じてOpLogを拡張できるという柔軟性が得られます。
vDiskに対する1.5MB以上の未処理I/Oが残っている場合、WRITE I/Oはシーケンシャル処理であると見なされます(AOS 4.6の時点)。 この条件に該当する場合、データは既に整列済みの大きなかたまりとなっており、データを融合させることで生じるメリットがないため、OpLogを経由することなく、エクステントストアに対して直接I/Oが行われます。
これは次の Gflagによって制御されます:: vdisk_distributed_oplog_skip_min_outstanding_write_bytes.
大きなサイズ(例えば > 64K)を含む、その他すべてのI/OはOpLogによって処理されます。
((CVM Memory - 12 GB) * 0.45)
例えば、32GBのCVMのキャッシュサイズは次のようになります:((32 - 12) * 0.45) == 9GB
以下は、ユニファイド キャッシュ の概要を図示したものです:
データは、4Kの粒度でキャッシュに格納され、全てのキャッシングはリアルタイムで行われます(例えば、データをディレイ処理したり、バッチ処理でデータをキャッシュに格納したりするようなことはありません)。
それぞれのCVMには、CVMがホストする(例えば同じノードで稼動するVMのような)独自に管理されたvDiskのためのローカルキャッシュがあります。vDiskがクローン(新しいクローンやスナップショットなど)されると、それぞれの新しいvDiskに個別にブロックマップが生成され、元のvDiskは変更不可とマークされます。これによって各CVMは、キャッシュコヒーレンシを保ちながら、元となるvDiskのキャッシュコピーをそれぞれに持つことが可能になります。
上書きが発生した場合、それは、VM自身のブロックマップにある新しいエクステントにリダイレクトされます。
AOSは、大規模なアプリケーションのパフォーマンスを提供できるように設計および構築されています。 Stargateの内部では、I/Oは、vDiskコントローラーと呼ばれるものによって、作成されたvDiskごとに処理されています。 全てのvDiskは、Stargate内部でvDiskのI/Oを受け持つ、それ自身のvDiskコントローラーを取得します。 期待されていたのは、ワークロードやアプリケーションが複数のvDiskを持ち、それぞれがシステムとして高いパフォーマンスを駆動できる自身のvDiskコントローラースレッドを持つことでした。
このアーキテクチャーは、単一の大きなvDiskを持つ仮想マシンによる、従来のアプリケーションやワークロードの場合を除いて、よく機能していました。 これらの仮想マシンでは、AOSの機能を最大限に活用できていませんでした。 AOS 6.1以降では、vDiskコントローラーが機能拡張され、それぞれが自身のスレッドを持つコントローラーのシャードを作成することで、単一のvDiskへの要求が、現在では複数のvDiskコントローラーに分散されるようになりました。 複数のコントローラーへのI/O分散は、プライマリコントローラーによって行われ、外部とのやりとりでは単一のvDiskのように見えます。 その結果、単一のvDiskを効果的にシャーディングしてマルチスレッドにします。 この機能拡張と前述にあるBlockStoreやAESのような他のテクノロジーによって、AOSは、単一のvDiskを使用する従来型のアプリケーションに対しても、一貫した高いパフォーマンスを大規模に提供できます。
YouTubeビデオによる解説はこちらからご覧いただけます:Tech TopX by Nutanix University: Scalable Metadata
メタデータは、インテリジェントなシステムの中心となるものですが、ファイルシステムやストレージアレイにとって非常に重要な存在となります。 「メタデータ」という用語についてわからないのであれば、本質的にメタデータは「データに関するデータ」です。 DSFという観点から、メタデータにはいくつかの重要な要素があります:
AOS 5.10 以降のメタデータは、グローバルメタデータとローカルメタデータの2つの領域に分かれています(以前はすべてのメタデータがグローバルでした)。 これの動機は、「メタデータのローカリティ」を最適化し、メタデータ検索のためのシステムネットワークトラフィックを制限することです。
この変更の根拠は、すべてのデータがグローバルである必要はないということです。 例えば、すべてのCVMが、どの物理ディスク上に特定のエクステントが配置されているかを把握している必要はありません。 ただ、どのノードがそのデータを保持しているかのみ把握し、そしてそのノードが、データをどのディスクに保持しているのかを把握している必要があります。
これにより、システムに保存されるメタデータの量を制限(ローカルのみのデータのメタデータRFを排除)し、「メタデータのローカリティ」を最適化できます。
以下に、4ノードクラスタにおけるメタデータの追加/更新の例を図示します:
以下のセクションでは、グローバルメタデータによる管理方法について説明します:
前述のアーキテクチャーのセクションでも説明した通り、DSFはリング状のキーバリューストアを使用して他のプラットフォームデータ(例えばステータスデータなど)と同様に、不可欠なグローバルメタデータをストアしています。 グローバルメタデータの可用性と冗長性を確保するため、レプリケーション ファクタ(RF)が奇数になるように(例えば、3や5に)設定します。 メタデータに書き込みや更新が発生した場合、ロー(Row)データが該当するキーを持つリング上の特定ノードに書き込まれ、n個(nはクラスタサイズに依存)のノードにレプリケートされます。 データをコミットする前に、Paxosアルゴリズムを使って、過半数のノードでのデータ一致を確認します。 このようにして、プラットフォームにストアするデータやグローバルメタデータの完全一致性を確保します。
以下の図は、4ノードクラスタでのグローバルメタデータの挿入/更新処理について示します:
DSFのグローバルメタデータにとって、大規模な構成におけるパフォーマンスも重要な要素です。 従来のデュアルコントローラーや「リーダー/ワーカー」方式のモデルとは異なり、プラットフォーム全体のメタデータの管理をNutanixの各ノードが分担して実施します。 クラスタの全てのノードにメタデータを配置して操作できるようにすることで、従来のボトルネックを排除することができます。 クラスタサイズに変更を加える(つまりノードを追加あるいは撤去する)場合、キーの再配布を最小限に抑えるためのキーのパーティショニングに、コンシステントハッシュ法を使用します。 クラスタを拡張(例えば4ノードから8ノードに)する場合、新しいノードは、「ブロック アウェアネス」と信頼性を確保するため、リングを構成しているノードの間に追加されます。
以下に、グローバルメタデータの「リング」とその拡張方法を図示します:
ビデオによる解説はこちらからご覧いただけます:LINK
現在、Nutanixプラットフォームは、回復ファクタ (Resiliency Factor) あるいはレプリケーション ファクタ (RF – Replication Factor) と呼ばれる係数に加え、チェックサムを使用してノードまたはディスクの障害や破損時にデータの冗長性と可用性を確保するようになっています。 前述のように、OpLogは、取り込んだWRITEリクエストを低レイテンシーのSSD層で吸収するためのステージング領域として機能します。 データはローカルのOpLogに書き込まれると、ホストに書き込み完了のAckを返す前に、データを異なる1つまたは2つの Nutanix CVMのOpLog(その数はRFに依存)に同期的にレプリケートします。 これにより、データは少なくとも2つまたは3つの独立した場所に存在することになり、フォールトトレランシーが確保されます。 注意:RF3の場合、メタデータがRF5となるため、最低でも5つのノードが必要となります。
OpLogのピアが一定単位毎(1GBのvDiskデータ)に選択され、全てのノードがこれに積極的に関与します。 どのピアが選択されるかという点については、複数の要因があります(例えばレスポンスタイム、業務、キャパシティの使用状況など)。 これによってフラグメンテーションの発生を防ぎ、全てのCVM/OpLogを同時に使用できるようになります。
データRFについては、Prismからコンテナレベルで設定を行います。 「ホットノード」の発生を防ぎ、リニアな拡張性能を維持するため、全てのノードをOpLogのレプリケーションに参加させます。 データが書き込まれている間にチェックサムが計算され、メタデータの一部としてストアされます。 その後データは、非同期的にエクステントストアに移され、RFが維持されていきます。 ノードやディスクに障害が発生した場合、データはクラスタ内の全ノードで再度レプリケートされ、RFを維持します。 データにREADが発生すると常に、データの正当性を確認するためチェックサムが計算されます。 チェックサムとデータが一致しない場合、当該データのレプリカが読み込まれ、不正なデータを置き換えます。
アクティブI/Oが発生しない場合でも一貫性を保つよう、データは継続的に監視されます。 ストレージのスクラブ処理は、エクステントグループを継続的にスキャンし、ディスクの使用率が低い時にチェックサムの検証を実施します。 これによって、ビットやセクターの毀損の発生からデータを保護します。
以下は、上記の解説を論理的に図示したものです:
ビデオによる解説はこちらからご覧いただけます:LINK
可用性ドメイン(またはノード/ブロック/ラック アウェアネス)は、コンポーネントやデータの配置を決定づける、分散システムにおける重要な要素です。 Nutanixは「ブロック」を、1、2または4つのサーバー「ノード」を含むシャーシ(筐体)として、「ラック」を1つ以上の「ブロック」を含む物理ユニットとして定義しています。 注意:ブロック アウェアネスな状態にするためには、最低3つのブロックが使用されている必要があります。 それ以外の場合はノード アウェアネスとなります。
Nutanixは現在、次のレベルまたはアウェアネスをサポートしています:
ブロック アウェアネスを確実に有効にするためには、ブロックを均一に配置することを推奨します。 一般的なシナリオと適用されるアウェアネスのレベルについては、本セクションの最後で説明します。 3ブロック必要となるのは、クォーラムを確保するためです。例えば3450は、4ノードで構成されるブロックです。 ブロック横断的にロールやデータを分散するのは、ブロックに障害が発生した場合やメンテナンスが必要な場合でも、システムを停止することなく稼動を継続できるようにするためです。 注意:ブロック内で唯一共有されているコンポーネントは、冗長構成のPSUとファンのみになります。
注: ラック アウェアネスでは、管理者がブロックを配置する「ラック」を定義する必要があります。
以下は、これがPrismでどのように構成されるかを示します:
アウェアネスは、いくつかの重要な分野に分類されます:
DSFによって、データのレプリカがクラスタ内の他の「ブロック/ラック」に書き込まれ、「ブロック/ラック」障害時や計画停止時でも、データは利用可能なままです。 これは、RF2とRF3の両方のシナリオで当てはまり、「ブロック/ラック」障害の場合も同様です。 考え方は、ノードに障害が発生した場合に備え、レプリカを異なるノードにレプリケーションしてデータを保護する「ノード アウェアネス」と同じです。 ブロックおよびラック アウェアネスは、「ブロック/ラック」停止した場合のデータの可用性を保証することにより、これをさらに拡張したものと言えます。
以下に、3ブロックの場合のレプリカの配置方法を図示します:
ブロック/ラックに障害が発生した場合でも、ブロック/ラック アウェアネスは維持され(可能であれば)、データブロックは、クラスタ内の異なるブロック/ラックにレプリケートされます。
よくある質問として、クラスタを2つの場所(部屋、建物など)をまたぐように構成して、 ブロック/ラック アウェアネスを使用して、場所の障害に対する回復力を提供できるかどうかというものがあります。
理論的には可能ですが、これは推奨されるアプローチではありません。 まず、これで達成したいことについて考えてみましょう:
最初のケースとして、0に近いRPOを達成しようとしている場合は、同期または同期に近い(near-synchronous)レプリケーションを利用することをお勧めします。 これにより、リスクの少ない同様のRPOを提供できます。
RTOを最小にするには、同期レプリケーション上でメトロクラスタを利用し、障害に対してDR復旧を実行する代わりにHAイベントとして処理します。
要約すると以下の理由により、同期レプリケーションやメトロクラスタリングを利用することが推奨されます:
一般的なシナリオとトレランスのレベルについて以下に説明します:
要求されるアウェアネスの種類 | FTレベル | EC有効か? | 最小ユニット | 同時故障への 耐性 |
---|---|---|---|---|
ノード | 1 | No | 3 ノード | 1 ノード |
ノード | 1 | Yes | 4 ノード | 1 ノード |
ノード | 2 | No | 5 ノード | 2 ノード |
ノード | 2 | Yes | 6 ノード | 2 ノード |
ブロック | 1 | No | 3 ブロック | 1 ブロック |
ブロック | 1 | Yes | 4 ブロック | 1 ブロック |
ブロック | 2 | No | 5 ブロック | 2 ブロック |
ブロック | 2 | Yes | 6 ブロック | 2 ブロック |
ラック | 1 | No | 3 ラック | 1 ラック |
ラック | 1 | Yes | 4 ラック | 1 ラック |
ラック | 2 | No | 5 ラック | 2 ラック |
ラック | 2 | Yes | 6 ラック | 2 ラック |
AOS 4.5以降、ブロック アウェアネスはベストエフォートで実行され、厳しい実施条件などはありません。 これは、ストレージリソースが偏在(skew)している(ストレージが極端に大きいノードがある等)クラスタが、機能を無効にしないための措置です。 しかし、ストレージの偏在を最小に抑え、均一なブロックを用意する形が依然ベストプラクティスと言えます。
AOS 4.5より前のバージョンの場合、ブロック アウェアネスには以下の条件を満たすことが必要となります:
(層の)最大相違数は、100 / (RF+1) として計算します
前述の「拡張可能メタデータ」のセクションで説明したように、Nutanixでは、メタデータや他の主要な情報をストアするために、Cassandraプラットフォームに大幅に手をいれています。 Cassandraは、リング状の構造を持ち、データの整合性と可用性を保つよう、リング内にn個のピア(peer)をレプリケーションしています。
以下は、12ノードクラスタのCassandraリングを図示したものです:
Cassandraのピアのレプリケーションは、リングを時計回りに移動しながら実施されます。 ブロック/ラック アウェアネスの場合、同じブロック/ラックにピアが2つ存在しないよう、ブロック/ラック間に分散されます。
以下は、上記のリングをブロック/ラックベースの表現に置き替えた内容を図示しています:
ブロック/ラック アウェアの特性により、ブロック/ラックに障害が発生しても、最低2つのデータコピー(メタデータRF3、さらに大規模なクラスタではRF5も可能)が存在することになります。
以下は、リングを形成する全ノードのレプリケーショントポロジーを図示したものです(やや複雑ですが):
以下に、一般的なシナリオと適用されるアウェアネスのレベルを示します:
Nutanixは、Zookeeperを使用してクラスタの基本的な設定データをストアしています。 この機能ついてもまた、ブロック/ラックに障害が発生した場合の可用性を維持するため、ブロック/ラック アウェアな方法で分散が行われています。
以下は、ブロック/ラック アウェアな方法で3つのZookeeperノードに分散された場合を例示したものです:
ブロック/ラックに障害発生した場合、つまりZookeeperの1ノードが停止した場合、Zookeeperの役割は、以下に示すようにクラスタ内の他のノードに引き継がれます:
ブロック/ラックがオンラインに復帰した場合、ブロック/ラック アウェアネスを維持するためZookeeperの役割は元に戻されます。
注意: AOS 4.5より前のバージョンでは、この移行は自動的に実行されずマニュアルでの対応となります。
DSFや従来のストレージプラットフォームの最も重要なコンセプトではないにしても、その信頼性と回復性能は最も重要な要素です。
Nutanixでは、ハードウェアの信頼性に重点を置いた従来のアーキテクチャーとは異なるアプローチを採用しています。 Nutanixは、ハードウェアがいずれは障害を起こすことを前提にしています。 従ってシステムは、このような障害に対して的確に、そして稼動を維持したままで対処できるようデザインされています。
注意: これはハードウェアの品質の問題ではなくコンセプトの変化です。 NutanixのハードウェアおよびQAチームは、徹底的な品質チェックと審査プロセスを実施しています。
前のセクションで説明した通り、メタデータおよびデータは、クラスタのFTレベルに基づくRFを使って保護されています。5.0では、FTレベルとしてFT1とFT2がサポートされ、それぞれがメタデータRF3とデータRF2に、またはメタデータRF5とデータRF3に対応しています。
メタデータの共有方法に関する詳細については、前述の「拡張可能メタデータ」セクションをご覧ください。また、データがどのように保護されるかに関する詳細は、前述の「データ保護」セクションをご覧ください。
通常状態におけるクラスタのデータレイアウトは、以下に示すようになります:
図に示す通り、VM/vDiskのデータがノード間に分散したディスクおよび関連するストレージデバイス上に、2つまたは3つコピーされています。
メタデータおよびデータを全てのノードとディスクデバイスに分散させることで、通常のデータ投入や再保護処理の際に最大のパフォーマンスを発揮できるようになります。
データがシステムに投入されると、プライマリとセカンダリのコピーがローカルおよび他の全てのリモートノードにコピーされます。これによってホットスポットの発生(ノードやディスクのスローダウン)を回避し、一定のWRITEパフォーマンスを得ることができます。
ノードを再度保護する必要があるディスクやノード自体に障害が発生した場合、クラスタの全能力を使ってリビルドを実施します。(障害発生ディスクのデータ検索およびレプリカの存在場所を特定するための)メタデータのスキャンは、CVM全体で均等に分散する形で実施されます。データのレプリカが特定できると、正常なCVMとディスクデバイス(SSDとHDD)、さらにホストネットワークのアップリンクを同時に使用してデータをリビルドします。
例えば、4ノードのクラスタでディスク障害が発生した場合、それぞれのCVMは、25%のメタデータのスキャンとリビルドを実施します。10ノードのクラスタの場合であれば、それぞれのCVMが10%、さらに50ノードのクラスタの場合であれば、それぞれのCVMは、2%分を担当することになります。
重要点: Nutanixは、データを均一に分散することによって一定のパフォーマンスを維持し、遙かに優れた再保護処理を実施できるようになっています。そして、これはクラスタ全体の処理(例えば、消失訂正符号や圧縮、重複排除など)にも適用されます。
HAのペアを使用したり、データの全てのコピーを単一のディスクに保存したりしている他のソリューションの場合には、ミラーノードやディスクが切迫した状態となった際(重いI/Oやリソース競合の発生などの際)に、フロントエンドでパフォーマンス問題が発生する可能性があります。
また、データを再保護する必要のある場所で障害が発生すると、単一のコントローラーやノードの単一のディスクリソース、そして単一のノードのアップリンクによって制約を受けることになります。 テラバイト級のデータを再度レプリケートしなければならない場合には、ローカルノードのディスクやネットワークのバンド幅について大きな制約を受けることになり、その間に別の障害が発生すると、データを喪失してしまう危険性が高まることになります。
DSFは分散システムとして、コンポーネント、サービス、そしてCVMの障害に対処するよう設計されていますが、障害は幾つかのレベルに分類できます:
予期しない障害が発生した場合(正常に機能していない場合はプロアクティブにオフラインにして)、即座にリビルドプロセスを開始します。
60分待機しててリビルド開始し、その期間中に1つのコピーのみ維持する一部の他ベンダーとは異なり (非常に危険であり、何らかの障害が発生するとデータロスにつながる可能性があります)、 潜在的に高いストレージ使用率を犠牲にして、そのリスクを取るつもりはありません。
これができる理由は次の仕組みによります。 a)メタデータの粒度で、 b)書き込みRFのピアを動的に選択し(障害が発生している間、すべての新しいデータ(例えば、新しい書き込み/上書き)は構成された冗長性を維持します)、 c)リビルド中にオンラインに戻ってくるデータは検証されたら再収容できます。 このシナリオでは、データが「過剰複製」される可能性がありますが、Curatorスキャンが開始されると、過剰複製されたコピーが削除されます。
ディスクが削除された場合、障害が発生した場合、応答がない場合、またはI/Oエラーが発生した場合には、ディスク障害と位置付けられます。 StargateのI/Oエラーやデバイス障害頻度が一定のしきい値を超えると、ディスクがオフライン状態にあると判断します。 この状態になると、HadesがS.M.A.R.Tを実行してデバイスの状態をチェックします。テストにパスすれば、ディスクはオンライン状態にあると認識し、そうでなければオフラインのままの状態とします。 Stargateが複数回(現在は1時間に3回)ディスクのオフラインを認識すると、S.M.A.R.Tのテストにパスしていても、ディスクはオンライン状態から外されます。
VMの影響:
ディスク障害が発生した場合、Curatorスキャン(MapReduceフレームワーク)が直ちに実施されます。 そして、メタデータ(Cassandra)をスキャンし、障害が発生したディスクがホストしていたデータおよび、レプリカをホストしているノード / ディスクを検索します。
「再レプリケーション」が必要なデータを発見した場合、クラスタ内のノードに対してレプリケーションの指示を行います。
この処理の間に、Drive Self Test (DST) が不良ディスクに対して実行され、SMARTのログでエラーを監視します。
以下は、ディスク障害と再保護の例になります:
ここで重要となるのは、Nutanixの場合、データは全てのノード、CVM、ディスクにまたがって分散およびレプリケートされることと、全てのノード、CVM、ディスクが再レプリケーションに関わるということです。
このように、クラスタ全体の処理能力をフル活用することで、データ保護機能の再生に向け必要となる時間を大幅に削減することが可能となり、また、クラスタの規模が大きくなるほど再生が高速になります。
VMの影響:
ノードに障害が発生した場合、VMのHAイベントにより、仮想化クラスタ全体の他のノードでVMの再起動が行われます。VMが再起動されると、I/Oは通常通りの形でローカルCVMによって処理され、VMはI/O処理を継続します。
前述のディスク障害と同様に、Curatorスキャンは、該当するノードでそれまでホストされていたデータに対応するレプリカを検索します。レプリカが見つかると、全てのノードが再保護に参加します。
ノードが長時間(AOS 4.6の場合30分間)停止した状態のままである場合、停止したCVMはメタデータリングから削除されます。ノードが復旧し一定時間経過して安定した後、停止していたCVMはリングに戻されます。
データの回復機能状態(resiliency state)については、ダッシュボードページのPrismから確認することができます。
回復機能状態は、cliでも確認できます:
ノードのステータス
ncli cluster get-domain-fault-tolerance-status type=node
ブロックのステータス
ncli cluster get-domain-fault-tolerance-status type=rackable_unit
これで最新の状態が表示されますが、データを更新するためにCuratorパーシャルスキャンを実行することもできます。
CVMの「障害」は、CVMが一時的に使用できなくなるようなCVMの動作と見なすことができます。該当システムは、こうした障害を透過的に処理するよう設計されています。障害が発生した場合、I/Oはクラスタ内の別のCVMにリダイレクトされます。但し、実際の仕組みはハイパーバイザーによって異なります。
ローリングアップグレードは、実際にこの機能を利用して、CVMを一度に一つアップグレードし、クラスタ全体で繰り返します。
VMの影響:
CVMに「障害」が発生した場合、該当するCVMが提供していたI/Oはクラスタ内の他のCVMに転送されます。 ESXiやHyper-Vは、HA.py(「Happy」に似ている)を使用したCVM Autopathing(CVM自動パス設定)と呼ばれるプロセス経由でこれを処理します。 CVM Autopathingは、内部アドレス(192.168.5.2)に向けられたトラフィックの転送パスを、クラスタの他のCVMの外部IPアドレスに向け変更します。 これにより、データストアは完全な状態を保つことができ、ただI/Oサービスを提供するCVMがリモートになるという違いのみになります。
ローカルのCVMが復旧して安定すると、転送パスは撤回され、ローカルCVMが全ての新しいI/Oを引き継いで処理します。
AHVは、プライマリなパスをローカルCVMとして、他の2つのパスをリモートに設定するというiSCSIマルチパスを使用しています。プライマリパスに障害が発生すると、残りのパスの1つがアクティブになります。
ESXiやHyper-VのAutopathingと同様、ローカルCVMが復旧すると、プライマリパスが役割を引き継ぎます。
使用されている用語の復習です:
レジリエントキャパシティは、可用性/障害ドメイン内でのFT障害の発生後に、自己修復能力で要求されたレプリケーションファクター(RF)に回復する最中の、最小状態の可用性/障害ドメインで利用可能なストレージ容量です。 簡単に言うと、「レジリエントキャパシティ = クラスタ全体の容量 - FT障害からリビルドするために必要な容量」です。
同一構成のノードで構成されたクラスタの容量
レジリエントキャパシティ = (40-10)*0.95 = 28.5TB
95%は、Stargateが読み取り専用モードになりユーザーの書き込みを実行できなくなるしきい値です。同一構成ではないノードで構成されたクラスタの容量
レジリエントキャパシティ = 40 * 0.95 = 38TB
95%は、Stargateが読み取り専用モードになりユーザーの書き込みを実行できなくなるしきい値です。この場合のレジリエントキャパシティは60TBではなく40TBであり、理由としては、40TBのブロックを失うと、クラスタにはノード可用性ドメイン(障害ドメイン)があるためです。 このレベル(ノード障害ドメイン)で2つのデータコピーを維持するには、使用可能容量は40TBであり、この場合のレジリエントキャパシティは全体で40TBになります。
容量と障害ドメインの観点から、クラスタは同一かつ均一の構成に保つことをお勧めします。
AOS 5.18以降は、レジリエントキャパシティがPrism ElementのStorage Summaryウィジェットに灰色の線で表示されます。 しきい値は、クラスタの使用容量がレジリエントキャパシティに到達したときに、エンドユーザーに警告するように設定できます。 デフォルトでそれは75%に設定されています。
Prismでは、管理者がノードごとでの復元力を理解しやすくするように、ノードごとに詳細なストレージ使用率を表示することもできます。 これは、ストレージ分散が偏っているクラスタで役立ちます。
クラスタの使用量がクラスタのレジリエントキャパシティを超えると、そのクラスタは障害に耐えられず、障害から回復できなくなる可能性があります。 レジリエントキャパシティは構成された障害ドメインによるものであるため、クラスタは下位の障害ドメインでも回復して障害に耐えられる可能性があります。 例えば、ノード障害ドメインを持つクラスタは、ディスク障害からの自己修復と回復ができる場合がありますが、ノード障害からの自己修復と回復はできません。
クラスタが適切に機能し、障害から自己修復で回復する能力を維持するために、どのような状況でもクラスタのレジリエントキャパシティを超えないようにすることを強くお勧めします。
Nutanixプラットフォームは、広範なストレージ最適化テクノロジーを組み合わせる形で採用し、全てのワークロードが使用可能なキャパシティを効率的に使用できるようにしています。このようなテクノロジーは、ワークロードの特性に合わせてインテリジェントに適応されるため、マニュアルによる設定やチューニングが不要となります。
使用されている最適化テクノロジーは以下の通りです:
それぞれの機能詳細については、次のセクションで説明します。
以下の表で、どのような最適化テクノロジーがどんなワークロードに適用可能かを説明します:
データ変換 | 最も適したアプリケーション | 補足 |
---|---|---|
消失訂正符号 | Nutanix Files/Objects に最適 | 従来のRFより少ないオーバーヘッドで高い可用性を提供。 通常のREAD/WRITE I/Oパフォーマンスに対し影響を与えない。 ディスク/ノード/ブロックに障害が発生しデータをデコードする必要がある場合には、READに若干のオーバーヘッドが発生。 |
インライン 圧縮 |
全て | ランダムI/Oに影響を与えずストレージ層の使用効率を向上。レプリケーションやディスクから読み込むデータ量を減らすことで、大規模なI/OやシーケンシャルI/Oのパフォーマンスを向上。 |
オフライン 圧縮 |
なし | インライン圧縮は、大規模またはシーケンシャルなWRITEに限りインラインで圧縮。ランダムI/Oや小規模なI/Oに対しては、オフライン圧縮を使用すべき。 |
パフォーマンス層 重複排除 |
P2V/V2V、Hyper-V (ODX)、クロスコンテナクローン | クローンされなかったデータまたは効率的なAOSクローンを使用せずに作成されたデータに対して大幅なキャッシュ効率を提供。 |
キャパシティ層 重複排除 |
パフォーマンス層重複排除に同じ | 上記の効果により、ディスクのオーバーヘッドを低減。 |
Nutanixプラットフォームでは、データ保護と可用性のためにレプリケーションファクター (RF) を利用しています。この方法では、1ヶ所を超えるストレージからデータ読み込んだり、障害時にデータの再計算を行なったりする必要がないため、極めて高い可用性を提供できます。 しかし、データの完全なコピーが必要となるため、ストレージリソースを消費することになります。
DSFでは、必要なストレージ容量を削減しつつ可用性とのバランスがとれるよう、消失訂正符号 (EC) を使用したデータのエンコードが可能になっています。
パリティを計算するRAID(レベル4、5、6など)の概念と同様、ECは、異なるノードに存在するデータブロックのストライプをエンコードしてパリティを計算します。 ホストまたはディスクに障害が発生すると、パリティを使用して消失したデータブロックの計算(デコーディング)を行います。 DSFの場合、データブロックはエクステントグループであり、また各データブロックはそれぞれ異なるノードに配置され、異なるvDiskに格納されている必要があります。
コールドで読み取られるデータの場合は、同じvDiskから、データブロックがノードを横断するよう分散してストライプ(同じvDiskのストライプ)を形成するようにします。 これにより、vDiskが削除された場合に完全なストライプを削除できるため、ガベージコレクション(GC)が簡素化されます。 ホットデータの読み取りでは、vDiskのデータブロックをノードに対してローカルに保ち、異なるvDiskのデータからストライプ(vDiskをまたぐストライプ)を形成します。 ローカルvDiskのデータブロックをローカルに配置できるため、別のVM/vDiskがストライプ内で別のデータブロックを構成でき、リモート読み取りが最小化します。 読み取るコールドストライプがホットになると、システムはストライプを再計算し、データブロックをローカル配置しようとします。
ストライプのデータやパリティのブロック数は、希望する障害耐性によって決定されます。 通常設定は、<データブロック>/<パリティブロック数> で計算します。
例えば、「RF2ライクな」可用性(つまりN+1)を求める場合は、3または4つのデータブロックとストライプに1つのパリティブロック(つまり3/1または4/1)とします。 「RF3ライクな」可用性(つまりN+2)を求める場合は、3ないしは4つのデータブロックとストライプに2つのパリティブロック(つまり3/2または4/2)とします。
AOS 5.8以降、ECはデータとパリティブロックをブロック認識する方法で配置できます(AOS 5.8より前はノードレベルで行われていました)。
既存のECコンテナは、AOS 5.8へのアップグレード後、すぐにはブロック認識の配置に変更されません。 クラスタ内で利用可能な十分なブロック(ストライプサイズ (k + n) + 1)がある場合、以前のノード認識ストライプはブロック認識になるよう移動します。 新しいECコンテナは、ブロック認識したECストライプを作成します。
想定されるオーバーヘッドは、<パリティブロック数> / <データブロック数> で計算できます。 例えば、4/1ストライプの場合、25%のオーバーヘッドまたはRF2の2Xに比べ1.25Xとなります。4/2ストライプの場合には、50%のオーバーヘッドまたはRF3の3Xに比べ1.5Xとなります。
以下の表に、エンコードされたストライプのサイズとオーバーヘッドの例を示します:
|
|
|||
---|---|---|---|---|
クラスタサイズ(ノード数) | ECストライプサイズ(データ/パリティブロック) | ECオーバーヘッド(対 RF2の2X) | ECストライプサイズ(データ/パリティ) | ECオーバーヘッド(対 RF3の3X) |
4 | 2/1 | 1.5X | N/A | N/A |
5 | 3/1 | 1.33X | N/A | N/A |
6 | 4/1 | 1.25X | 2/2 | 2X |
7 | 4/1 | 1.25X | 3/2 | 1.6X |
8+ | 4/1 | 1.25X | 4/2 | 1.5X |
クラスタサイズは、常にストライプサイズ(データ+パリティ)より最低でも1ノード大きくなるように設定し、ノードに障害が発生した場合でも、ストライプの再構築が可能なようにしておくことが推奨されます。 こうすることで、(Curatorにより自動的に)ストライプが再構築されている場合でも、READにかかるオーバーヘッドを避けることができます。 例えば、4/1ストライプの場合は、クラスタに6ノードを確保すべきです。 前述の表は、このベストプラクティスを踏襲したものになっています。
エンコーディングは、ポストプロセスで実施され、Curator MapReduceフレームワークを使用してタスクの配布を行います。 ポストプロセスのフレームワークであるため、従来のWRITE I/Oパスが影響を受けることはありません。
RFを使用する通常の環境は以下に図示するような内容となります:
このシナリオの場合、RF2とRF3データが混在し、元のデータはローカルに存在し、レプリカはクラスタ全体の他のノードに分散されています。
Curatorスキャンが実行され、エンコードが可能な適切なエクステントグループを検索します。適切なエクステントグループとは、「write-cold」なもの、つまり一定の間書き込みが行われていないものを指します。この間隔はCurator Gflag、curator_erasure_code_threshold_secondsによってコントロールされます。適切な候補が見つかると、Chronosによってエンコーディングタスクが配布され実行されます。
以下に4/1および3/2ストライプの例を図示します:
データのエンコード(ストライプおよびパリティ計算)が成功すると、レプリカエクステントグループは削除されます。
以下は、ストレージセービングのためにECが実行された後の環境を図示したものです:
消失訂正符号はインライン圧縮機能と相性がよく、さらにストレージの節約ができます。
ビデオによる解説はこちらからご覧いただけます:LINK
Nutanix Capacity Optimization Engine(COE – キャパシティ最適化エンジン)は、ディスクのデータ効率を上げるために、データ変換を行います。 現在、圧縮機能は、データの最適化を行うための重要な機能の1つとなっています。 DSFは、お客様のニーズやデータタイプに応じた対応ができるよう、インライン圧縮とポストプロセス圧縮の両方を提供しています。 AOS 5.1では、オフライン圧縮がデフォルトで有効化されています。
インライン圧縮では、エクステントストア (SSD + HDD) の書き込み時に、シーケンシャルなデータや大きなサイズのI/O(>64K)を圧縮します。 これには、OpLogからのデータドレイニングやOplogをスキップするシーケンシャルデータなどが含まれます。
AOS 5.0では、OpLogが4Kを超える全てのインカミングの書き込みについて圧縮を行うことで(Gflag:vdisk_distributed_oplog_enable_compression)、優れた圧縮効果が得られるようになりました。 これによって、さらに効率的にOpLogのキャパシティを活用し、安定したパフォーマンスが得られるようになります。
OpLogからエクステントストアに溢れたデータについては、一度解凍し、アラインメントした後に、32Kのユニットサイズに合わせて再圧縮が行われます(AOS 5.1の場合)。
この機能はデフォルトで有効となっており、ユーザーが設定する必要はありません。
オフライン圧縮の場合、最初は通常の状態(非圧縮状態)で書き込みが行なわれ、Curatorフレームワークを使用してクラスタ全体のデータを圧縮します。 インライン圧縮が有効化された場合、I/Oがランダムな特性を持っていても、データは圧縮されない状態でOpLogに書き込まれて合成され、エクステントストアに書き込まれる前にインメモリで圧縮されます。
Nutanixは、AOS 5.0以降、データ圧縮にLZ4とLZ4HCを使用しています。 AOS 5.0より前は、Google Snappy圧縮ライブラリを使用することで、処理オーバーヘッドが少なく高速な圧縮/解凍速度で、非常に優れた圧縮率を得ていました。
通常のデータに対しては、圧縮率とパフォーマンスのバランスが取れたLZ4を使用しています。 コールドデータに対しては、より圧縮率に優れたLZ4HCを使用しています。
コールドデータは、次のような2つのカテゴリに分類されます:
以下に、インライン圧縮とDSF WRITE I/Oパスとの関連を図示します:
大規模またはシーケンシャルなWRITE処理のみが圧縮対象で、ランダムWRITEのパフォーマンスに影響を与えないため、ほとんどの場合インライン圧縮(圧縮遅延 = 0)が使用されます。
これによってSSD層の実効容量を増やし、パフォーマンスを効果的に向上させ、より多くのデータをSSD層に格納しておくことができます。 書き込みやインライン圧縮された、より大容量またはシーケンシャルデータに対しては、RFによるレプリケーションの際に圧縮データが送られることで回線を通過するデータ量が低減され、さらなるパフォーマンスの向上につながります。
またインライン圧縮は、消失訂正符号との相性という面でも優れています。
オフライン圧縮の場合、全ての新しいWRITE I/Oが非圧縮状態で行われ、通常のDSF I/Oパスが適用されます。 圧縮遅延時間(設定可能)に達するとデータの圧縮が可能となります。 オフライン圧縮は、Curator MapReduceフレームワークを使用し、全ノードで圧縮タスクを実行します。 圧縮タスクはChronosによって起動されます。
下記に、オフライン圧縮とDSF WRITE I/Oの関係を示します。
READ I/Oの場合、最初にメモリ内で解凍を行ってからI/Oが実施されます。
現在の圧縮率は、PrismのStorage > Dashboardページで確認できます。
ビデオによる解説はこちらからご覧いただけます:LINK
Elastic Dedupe Engineは、DSFにおけるソフトウェアベースの機能で、キャパシティ層(エクステントストア)とパフォーマンス層(ユニファイド キャッシュ)でデータの重複排除を行います。 データストリームは、16K粒度のSHA-1ハッシュを使用して取り込まれる間にフィンガープリントを残します。 フィンガープリントは、データの取り込み時にのみ収集され、書き込みブロックのメタデータの一部として永続的にストアされます。 注意:当初、フィンガープリントの収集に4Kの粒度が使用されていましたが、テストの結果、16Kの方がメタデータのオーバーヘッドを減らし、最大の重複排除効果が得られることが判明しました。 重複排除後のデータは、4Kの粒度でコンテンツキャッシュに取り込まれます。
データの再読み込みが必要となるバックグラウンドのスキャンを使用する従来の手法とは異なり、Nutanixはデータ取り込み時にインラインでフィンガープリントを取得します。キャパシティ層で重複排除が可能な重複データは、スキャンしたり再読み込みしたりする必要がないため、重複したデータは基本的に削除することが可能です。
メタデータのオーバーヘッドを効率化するため、フィンガープリントの参照カウントをモニターし、重複排除の可能性をトラッキングします。メタデータのオーバーヘッドを最小限にするため、参照数の低いフィンガープリントは廃棄されます。また、フラグメントを最小限にするためには、キャパシティ層の重複排除を最大限に使用することが望まれます。
ベースイメージ(vdisk_manipulatorを使用してマニュアルでフィンガープリント可能)に対しては、パフォーマンス層の重複排除を使用し、コンテンツキャッシュの優位性を活かすようにします。
Hyper-Vを使用してODXがデータの完全コピーを取得する場合、またはコンテナをまたがったクローンを実施(単一のコンテナが好ましいため通常は推奨しません)する場合、 P2V / V2Vに対してはキャパシティ層の重複排除を使用します。
ほとんどの場合、圧縮機能の方がより多くの容量削減が可能なため、重複排除の代わり使用されるべきでしょう。
以下に、Elastic Dedupe Engineの拡張と、ローカルVMのI/Oリクエストの処理の関連を図示します:
I/Oサイズが64K以上(初期のI/OまたはOpLogからのドレイニングの際)のデータを取り込む間にフィンガープリントが収集されます。 Intel accelerationが使用された、CPUのオーバーヘッドが極めて少ないSHA-1処理を行われます。 データ取り込み中にフィンガープリントが収集できない(例えばI/Oサイズが小さいなど)場合、フィンガープリントの収集は、バックグラウンドプロセスとして実行されます。 Elastic Dedupe Engineは、キャパシティ層(エクステントストア)とパフォーマンス層(ユニファイド キャッシュ)の両方に対応しています。 重複データが特定されると、同じフィンガープリントの複数のコピーに基づき、バックグラウンドプロセスが、DSF MapReduceフレームワーク (Curator)を使用して重複データを削除します。 読み込みデータは、複数階層を持つプールキャッシュであるDSFユニファイド キャッシュに取り込まれます。これ以降、同じフィンガープリントを持つデータリクエストは、キャッシュから直接データを取り込みます。 ユニファイド キャッシュとプールの階層構造の詳細については、I/Oパス概要セクション内の「ユニファイド キャッシュ」に関するサブセクションをご覧ください。
AOS 4.6.1 では、vDisk全体で無制限にフィンガープリントと重複排除ができるようになりました。
AOS 4.6.1 以前では、メタデータの効率性を高めるため、この制限が24GBまで拡張されました。 AOS 4.5 以前では、vDiskの最初の12GBのみがフィンガープリント採取の対象でした。 これは、通常OSが最も共通的なデータであったため、維持するメタデータのフットプリントが比較的小さいためです。
以下に、Elastic Dedupe EngineとDSF I/Oパスの関係を図示します:
現在の重複排除率は、Prismの Storage > Dashoboard ページ で確認することができます。
4.5では、重複排除と圧縮を同じコンテナに適用することができます。しかし、データが重複排除可能な場合(セクションの最初に述べた条件)を除き圧縮にこだわるべきでしょう。
ディスクバランシングのセクションでは、どのようにしてNutanixクラスタの全てのノードにまたがるストレージ キャパシティをプールし、また、どのようにしてILMがホットデータをローカルに維持するかについて解説しました。 同様の概念が、クラスタ全体のSSDやHDD層といったディスクの階層化にも適用されており、DSF ILMは、階層間でデータを移動させる役目を担います。 ローカルノードのSSD層は、そのノードで稼動するVMが生成する全てのI/Oに対して常に最高優先度となる階層であり、また、クラスタの全てのSSDリソースは、クラスタ内の全てのノードに対して提供されることになります。 SSD層は、常に最高のパフォーマンスを提供すると同時に、その管理はハイブリットアレイにとって非常に重要なものとなります。
階層の優先度は次のような分類が可能です:
同じタイプのリソース(例えばSSD、HDDなど)が、クラスタ全体のストレージ層から集められてプールされます。 つまり、ローカルにあるかどうかを問わず、クラスタ内の全てのノードが、その層のキャパシティ構築に利用されるということです。
以下は、このプールされた階層がどのように見えるかを図示したものです:
ローカルノードのSSDが一杯になるとどうなるのか?というのは一般によく聞かれる質問です。 ディスクバランシングのセクションで説明した通り、重要となるのは、ディスク層のデバイス間の使用率の平準化を図ることです。 ローカルノードのSSD使用率が高い場合、ディスクバランシングは、ローカルSSDに存在する最もコールドなデータをクラスタの他のSSDに移動するように機能します。 これにより、ローカルSSDに空きスペースを確保し、ローカルノードがネットワーク越しにではなく、ローカルのSSDに直接書き込めるようにします。 ここで重要な点は、全てのCVMとSSDがリモートI/Oに使用されることで、ボトルネックの発生を防ぎ、また、万が一発生した場合でも、ネットワーク経由でI/Oを実施してそれを修復できる点です。
別のケースとして、階層全体の使用率が、一定のしきい値 [curator_tier_usage_ilm_threshold_percent (デフォルト=75)] を超えた場合、 Curatorジョブの一部としてDSF ILMが起動され、データをSSD層からHDD層に下層移動させます。 これにより、使用率が上記のしきい値内になるか、または最小解放値 [curator_tier_free_up_percent_by_ilm (デフォルト=15)] の2者から、大きい方の値でスペースが解放されます。 下層移動の対象となるデータは、最後にアクセスのあった時間によって決定されます。 SSD層の使用率が95%の場合、SSD層にある20%のデータをHDD層に移動(95% -> 75%)されます。
しかし、使用率が80%の場合は、階層の最小解放値に基づき、15%のデータのみがHDD層に移動することになります。
DSF ILMは、I/Oのパターンを定常的にモニターし、必要に応じてデータを上層または下層に移動すると共に、その階層に関係なく、ホットなデータをローカルに移動させます。 上層への移動(もしくは水平移動)のロジックは、egroupローカリティで定義されたものと同様です: 10分間に3回のランダムアクセス、または10回のシーケンシャルアクセスが発生した場合。ただし10秒間のサンプリング間隔内で発生した複数回のReadは1回としてカウントされます。
ビデオによる解説はこちらからご覧いただけます:LINK
DSFは非常にダイナミックなプラットフォームとして、様々なワークロードに対応することが可能であると同時に、1つのクラスタをCPUに重点を置いた構成(3050など)や、ストレージに重点を置いた構成(60x0など)など、様々なノードタイプを組み合わせた構成が可能です。 大規模なストレージ容量を持ったノードを組み合わせた場合、データを均一に分散することが重要になります。 DSFには、クラスタ全体でデータを均一に分散するためのディスクバランシングと呼ばれるネイティブな機能が含まれています。 ディスクバランシングは、DSF ILMと連携しながらローカルにあるノードのストレージ キャパシティの使用率を調整します。 もし、使用率が一定のしきい値を超えた場合は、使用率の均一化を図ります。
注: ディスクバランシングのジョブは、プライマリI/O(UVMのI/O)とバックグラウンドI/O(例えばディスクバランシング)に異なる優先度キューを持つCuratorによって処理されます。 これは、ディスクバランシングやその他のバックグラウンド処理が、フロントエンドのレイテンシーやパフォーマンスに影響しないように行われます。 このときジョブのタスクは、タスク実行の抑制や制御をするChronosに渡されます。 また、ディスクバランシングのための移動は同じ層内で行われます。 例えば、HDD層に不均等なデータがある場合、ノード間の同じ層で移動します。
以下は、異なるタイプ(3050 + 6050)で構成された「バランスが悪い」状態にあるクラスを図示しています:
ディスクバランシングは、DSF Curatorフレームワークを使用し、スケジュールプロセスとして、 または、しきい値を超えた場合(例えば、ローカルノードのキャパシティの使用率 > n%)に機能します。 データのバランスが悪い場合、Curatorはどのデータを移動すべきかを判断し、クラスタのノードにタスクを配分します。 ノードタイプが均一(例えば、3050のみ)の場合、データの分散もほとんどが均一な状態になります。 しかし、ノード上に他に比べ大量のデータ書き込みを行うVMが存在した場合には、該当ノードのキャパシティ使用率のみが突出したものになります。 このような場合、ディスクバランシングが機能し、そのノードの最もコールドな状態にあるデータをクラスタ内の他のノードに移動させます。 さらに、ノードタイプが不均一(例えば、3050 + 6020/50/70など)な場合や、ストレージの利用のみに限定して使用されている(VMが動いていない状態)ノードが存在する場合にも、データを移動する必要があると考えられます。
以下に、ノードタイプが混在したクラスタで、ディスクバランシングが機能し、「バランスが取れた」状態を図示しました:
大量のストレージ キャパシティを確保するため、一部のノードを「Storage Only(ストレージとしてのみ利用する)」という状態で稼動させるお客様も存在します。 この場合、CVMのみがノード上で稼動することになります。 ノードの全てのメモリをCVMに割り当て、より大きなREADキャッシュを確保することができます。
以下は、ノードタイプ混在クラスタにStorage Onlyノードが存在する場合、ディスクバランシングがどのようにVMを稼動するノードからデータを移動させるかを図示したものです:
ビデオによる解説はこちらからご覧いただけます:LINK
DSFはオフロードされたスナップショットとクローンをネイティブにサポートし、VAAI、ODX、ncli、REST、Prismなどから使用することができます。 スナップショットもクローンも、最も効果的かつ効率的なリダイレクト オン ライト(redirect-on-write)アルゴリズムを採用しています。 データストラクチャのセクションで説明した通り、仮想マシンはNutanixプラットフォーム上のvDiskであるファイル(vmdk/vhdx)から構成されています。
vDiskは、論理的に連続したデータのかたまりであり、エクステントグループにストアされているエクステントで構成されています。エクステントグループは、ストレージデバイス上のファイルとしてストアされている物理的に連続したデータです。スナップショットやクローンが取得されると、元になるvDiskは変更不可とマークされ、一方のvDiskはREAD/WRITE可能な形で作成されます。この時点で、両方のvDiskは同じブロックマップ、すなわちvDiskに対応するエクステントをマップしたメタデータを持っています。スナップショットチェーンのトラバーサル(READに必要なレイテンシーの増加)が発生する従来のアプローチとは異なり、各vDiskがそれぞれのブロックマップを持っています。これによって、大きく深いスナップショットチェーンで一般的にみられるオーバーヘッドを排除し、パフォーマンスに影響を与えることなく、連続的にスナップショットを取得することができるようになります。
以下は、スナップショットを取得した際の動きを図示したものです(ソース: NTAP):
日本語版 補足: この図はNTAP(NetApp)の図をもとに作成されたものです。NTAPの説明が最も明解なものだったからです。
既にスナップショットあるいはクローンが取得されたvDiskでスナップショットまたはクローンを取得する場合も、同じ方法が適用されます:
VMやvDiskに対するスナップショットやクローンも、同様の方法で取得します。 VMまたはvDiskがクローンされる場合、その時点のブロックマップをロックして、クローンが作成されます。 更新はメタデータのみに対して行われるため、実際にI/Oが発生することはありません。 さらにクローンのクローンについても同様です。 以前にクローン化されたVMは、「ベースvDisk(BasevDisk)」として機能し、クローニングが行われる場合ブロックマップがロックされ、2つの「クローン」が作成されます。 1つはクローン元のVMで、もう一方は新しいクローンです。 クローンの最大数に制限はありません。
いずれも以前のブロックマップを引き継ぎ、新規の書き込みや更新はそれぞれのブロックマップに対して行われます。
既にご説明した通り、各VM/vDiskはそれぞれブロックマップを持っています。上記の例では、ベースVMの全てのクローンがそれぞれのブロックマップを持つようになり、書き込みや更新はそこで発生します。
上書きが発生した場合、データを新しいエクステント/エクステントグループに移動します。 例えば、既存のデータが「エクステントe1のオフセットo1」にありそれが上書きされるとき、Stargateは新しいエクステントe2を作成し、新しいデータが「エクステントe2のオフセットo2」に書き込まれたことを追跡します。 vBlockマップは、これをバイトのレベルで追跡します。
以下にそのような状態を図示します:
VM/vDiskに引き続き、クローンやスナップショットを取得しようとすると、元のブロックマップがロックされ、R/Wアクセスできる新しい対象が作成されます。
Nutanixプラットフォームでは、ノード間通信においてバックプレーンを一切使用せず、標準的な10GbEネットワークのみを使用しています。 Nutanixノード上で稼動するVMの全てのストレージI/Oは、ハイパーバイザーによって専用のプライベート ネットワーク上で処理されます。 I/Oリクエストは、ハイパーバイザーによって処理され、ローカルCVM上のプライベートIPに転送されます。 CVMは、外部IPを使いパブリック10GbEネットワーク経由で、他のNutanixノードに対してリモートレプリケーションを行います。 つまり、パブリック10GbEを利用するトラフィックは、DSFリモートレプリケーションとVMネットワークI/Oのみということです。 但し、CVMが停止していたり、データがリモートに存在したりする場合、CVMはリクエストをクラスタ内の他のCVMに転送します。 さらに、ディスクバランシングなどクラスタ横断的なタスクは、10GbEネットワーク上で一時的にI/Oを発生させます。
以下は、VMのI/Oパスとプライベートおよびパブリック10GbEネットワークの関係を図示したものです:
コンバージド(サーバー+ストレージ)プラットフォームであるNutanixでは、I/Oとデータのローカリティが、クラスタおよびVMのパフォーマンスにおいて重要な要素となります。 前述のI/Oパスの通り、全てのRead/Write I/Oは、一般のVMに隣接した各ハイパーバイザー上に存在するローカルのコントローラーVM(CVM)によって処理されます。 VMのデータは、ローカルでCVMから提供され、CVMコントロール下のローカルディスクにストアされます。 VMが特定のハイパーバイザー ノードから他に移動する場合(あるいはHAイベント発生中)には、新たなローカルCVMによって移行されたVMのデータが処理されます。 古いデータ(リモート ノード/CVMに格納)を読み込む際、I/OはローカルCVMからリモートCVMに転送されます。 全てのWrite I/Oは、直ちにローカルで処理されます。 DSFは、異なるノードで発生したI/Oを検知し、バックグラウンドで該当データをローカルに移動し、全てのRead I/Oがローカルで処理されるようにします。 ネットワークに負荷を与えないようにするため、データの移動はRead処理が発生した場合にのみ実施されます。
データ ローカリティは、主に以下2つの状況で発生します:
以下は、VMがハイパーバイザー ノード間を移動した場合、データがどのようにVMを「追いかけるか」を図示したものです:
キャッシュローカリティはリアルタイムに発生し、vDiskの所有権に応じて決定されます。 vDiskやVMがあるノードから別のノードに移ると、vDiskの「所有権」もローカルCVMに移動します。 所有権が移動すると、データはユニファイド キャッシュ内でローカルにキャッシュされます。 その間、キャッシュは所有権がある場所(この場合はリモート ホスト)に格納されます。 それまでデータをホストしていたStargateは、リモートI/Oが300秒を超えた際にvDiskトークンを放棄し、それをローカルのStargateが引き継ぎます。 vDiskデータをキャッシュするには所有権が必要なため、キャッシュの統合処理が行われます。
egroupのローカリティは、サンプリングに基づく処理であり、エクステント グループの移行は以下の状況により発生します: 「10秒毎のサンプリング計測で、複数のRead処理が発生している10分間に、ランダム アクセスが3回、またはシーケンシャル アクセスが10回発生した場合」
分散ストレージ ファブリックには「シャドウ クローン」と呼ばれる機能があり、「複数の読み手」のある特定のvDiskやVMデータの分散キャッシングを行うことができます。 VDI導入中に、多くの「リンク クローン」がReadリクエストをセントラルマスター、つまり「ベースVM」に対して送信する場合などがこの典型例と言えます。 VMware Viewの場合、この仕組みはレプリカ ディスクと呼ばれ、全てのリンク クローンから読み込まれます。 XenDesktopの場合には、MCSマスターVMと呼ばれています。 これは複数の読み手が存在する場合(例えば展開サーバーやリポジトリ)などあらゆるシナリオで機能します。 データやI/Oのローカリティは、VMが最大パフォーマンスを発揮するために不可欠であり、またDSFの重要な構成要素となります。
DSFは、シャドウ クローンを使って、データ ローカリティと同様にvDiskのアクセス傾向をモニターします。 しかし、2つ以上のリモートCVM(ローカルCVMも同様)からリクエストがあり、かつ全てがRead I/Oリクエストであった場合、vDiskは変更不可とマークされます。 一旦ディスクが変更不可とマークされると、vDiskはCVM毎にローカルにキャッシングされ、Readリクエストに対応できるようになります(ベースvDiskのシャドウクローンとも言います)。 これによって、各ノードのVMがベースVMのvDiskをローカルに読み込めるようになります。VDIの場合、レプリカディスクがノード毎にキャッシュされ、ベースに対する全てのReadリクエストがローカルで処理されるようになります。 注意: データの移動は、ネットワークに負荷を与えずに効率的なキャッシュ利用を可能にするため、Read処理が発生した場合にのみ実施されます。 ベースVMに変更があった場合、シャドウクローンは削除され、プロセスは最初からやり直しとなります。 シャドウ クローンは、デフォルトで有効化されており (4.0.2の場合)、以下のNCLIコマンドを使って有効化/無効化できます: ncli cluster edit-params enable-shadow-clones=<true/false>
以下に、シャドウ クローンの動作と分散キャッシングの方法を図示します:
Nutanixプラットフォームは、VM/ゲストOSから物理ディスク デバイスに至るまで、スタック全体にわたる複数の層でストレージを監視しています。 様々な階層とそれらの関係を十分理解することが、ソリューションの監視においては非常に重要となり、処理との関連性をより可視化することができます。 以下は、処理を監視している各層とその粒度について図示したものです:
メトリクスと時系列データは、Prism Elementにローカルで90日間保存されます。Prism CentralやInsightsでは、データを (キャパシティが許す限り) 無期限に保存します。
Nutanix Guest Tools (NGT) は、ソフトウェア ベースのゲストにインストールするエージェント フレームワークであり、Nutanixプラットフォームを介して高度なVM管理機能を提供します。
本ソリューションは、VMにインストールされたNGTインストーラーおよび、エージェントとNutanixプラットフォーム間の調整に使用されるGuest Tools Frameworkで構成されています。
NGTインストーラーには以下のコンポーネントが含まれています:
このフレームワークは少数のハイレベル コンポーネントで構成されています:
以下に各コンポーネントの関係概要を示します:
Guest Tools Serviceは、以下2つの主要機能で構成されています:
NGTリーダーをホストしているCVMのIPは、以下のコマンドにより確認することができます(どのCVM上でも実行可能)。
nutanix_guest_tools_cli get_leader_location
以下に各ロールの概要を示します:
前述の通り、Guest Agentは主に以下のようなコンポーネントで構成されています:
Guest Agent Serviceは、SSLを使用してNutanixクラスタIP経由でGuest Tools Serviceと通信します。 Nutanixクラスタ コンポーネントとUVMを異なるネットワーク上に導入している場合(全てそうであることが推奨)、以下が可能であることを確認してください:
Guest Tools Serviceは、認証局(CA – Certificate Authority)として機能し、NGTが有効なUVMのための証明書ペアを生成します。 この証明書は、UVMのために構成されたISOに埋め込まれ、NGT導入プロセスの一部として使用されます。 これらの証明書はインストール プロセスの一部としてUVM内部にインストールされます。
NGTエージェントのインストールは、PrismまたはCLI / スクリプト(ncli/REST/PowerShell)で実行できます。
PrismからNGTをインストールする場合は、「VM」ページでNGTをインストールするVMを選択し「Enable NGT(NGTを有効化)」をクリックします。
確認表示が出たら、「Yes」をクリックしてNGTのインストールを進めます:
ソフトウェアや独自の証明書を含むインストーラーがCD-ROM内にあるため、以下のようにVMからCD-ROMが利用可能になっている必要があります:
OSからNGTインストーラーCD-ROMが確認できます:
CDをダブルクリックし、インストール プロセスを開始します。
以下のコマンドを実行して、CD-ROMからNutanix Guest Toolsをサイレントインストレーションすることができます:
NutanixGuestTools.exe /quiet /l log.txt ACCEPTEULA=yes
プロンプトに従い、ライセンスを承諾してインストールを完了させます:
インストール プロセスの過程で、Python、PyWinおよびNutanix Mobility(ハイパーバイザー間互換性)ドライバーがインストールされます。
インストール完了後には、リブートが必要となります。
インストールおよびリブートが完了すると、「Programs and Features (プログラムと機能)」に以下の項目が表示されます:
NGTエージェントおよびVSS ハードウェア プロバイダー用サービスもまた稼動しています:
以上でNGTのインストールが完了し、利用可能となりました。
個々のVMにNGTをインストールするのではなく、ベースイメージにNGTを埋め込んで導入することも可能です。
ベースイメージでNGTを使用できるようにするためには、次の手順に従います:
クローンVMがブートされると、新しいNGT ISOを検知し、関連設定ファイルと新しい証明書をコピーして、Guest Tools Serviceとの通信を開始します。
Nutanixでは、CloudInitおよびSysprepを使用してネイティブにOSをカスタマイズすることが可能です。 CloudInitは、Linuxクラウドサーバーのブートストラップを処理するパッケージです。 これにより短時間でLinuxインスタンスの初期化とカスタマイズを行うことができます。 Sysprepは、WindowsのOSカスタマイズ機能です。
例えば、次のようなケースで使用します:
本ソリューションは、以下のバージョンを含むAHV上で稼動するLinuxゲストで有効となります。 (以下のリストは一部です。全てを確認する際には、ドキュメントをご覧ください)
CloudInitを利用するためには以下が必要となります:
Sysprepはデフォルトで有効となっており、Windowsにインストールされています。
CloudInitは(もし未済の場合には)以下のコマンドでインストールすることができます:
Red Hatベースのシステム (CentOS、RHEL)
yum -y install CloudInit
Debianベースのシステム (Ubuntu)
apt-get -y update; apt-get -y install CloudInit
Sysprepは、Windowsインストレーションの一部となっています。
カスタムスクリプトを使用してOSのカスタマイズを行うためには、PrismのチェックボックスまたはREST APIに内容を記述します。このオプションは、VMの作成またはクローニング処理の途中で指定します:
Nutanixには、カスタムスクリプトパスを指定するいくつかの方法があります:
Nutanixは、スクリプトを含むCD-ROM作成によって、初回ブート中にCloudInitまたはSysprepプロセスにユーザーデータスクリプトを引き渡します。 処理が完了した時点でCD-ROMを取り外します。
このプラットフォームは、様々なデータ入力フォーマットをサポートしています。以下に主なフォーマットの一部を示します:
ユーザーデータスクリプトは、簡単なシェルスクリプトでブートスクリプトの最後で処理されます(例えば「rc.local-like」)。
本スクリプトは、bashスクリプトのように「#!」で開始します。
以下にユーザーデータスクリプトの例を示します:
#!/bin/bash touch /tmp/fooTest mkdir /tmp/barFolder
インクルードファイルには、URLのリスト(一行に1つ)が含まれています。各URLが読み込まれ、他のスクリプト同様に処理されます。
本スクリプトは「#include」で開始します。
以下はインクルードスクリプトの例です:
#include http://s3.amazonaws.com/path/to/script/1 http://s3.amazonaws.com/path/to/script/2
cloud-config入力タイプは、CloudInitで最もよく使用されています。
本スクリプトは「#cloud-config」で開始します。
以下にクラウド構成データスクリプトの例を示します:
#cloud-config # Set hostname hostname: foobar # Add user(s) users: - name: nutanix sudo: ['ALL=(ALL) NOPASSWD:ALL'] ssh-authorized-keys: - ssh-rsa: <PUB KEY> lock-passwd: false passwd: <PASSWORD> # Automatically update all of the packages package_upgrade: true package_reboot_if_required: true # Install the LAMP stack packages: - httpd - mariadb-server - php - php-pear - php-mysql # Run Commands after execution runcmd: - systemctl enable httpd
CloudInitのログファイルは、/var/log/cloud-init.log および cloud-init-output.logにあります。
unattend.xmlファイルは、ブート時のイメージカスタマイズに使用するSysprepの入力ファイルであり、詳細はこちらで確認できます: LINK
本スクリプトは、「<?xml version="1.0" ?>」で開始します。
以下はunattend.xmlファイルの例です:
<?xml version="1.0" ?> <unattend xmlns="urn:schemas-microsoft-com:unattend"> <settings pass="windowsPE"> <component name="Microsoft-Windows-Setup" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" processorArchitecture="x86"> <WindowsDeploymentServices> <Login> <WillShowUI>OnError</WillShowUI> <Credentials> <Username>username</Username> <Domain>Fabrikam.com</Domain> <Password>my_password</Password> </Credentials> </Login> <ImageSelection> <WillShowUI>OnError</WillShowUI> <InstallImage> <ImageName>Windows Vista with Office</ImageName> <ImageGroup>ImageGroup1</ImageGroup> <Filename>Install.wim</Filename> </InstallImage> <InstallTo> <DiskID>0</DiskID> <PartitionID>1</PartitionID> </InstallTo> </ImageSelection> </WindowsDeploymentServices> <DiskConfiguration> <WillShowUI>OnError</WillShowUI> <Disk> <DiskID>0</DiskID> <WillWipeDisk>false</WillWipeDisk> <ModifyPartitions> <ModifyPartition> <Order>1</Order> <PartitionID>1</PartitionID> <Letter>C</Letter> <Label>TestOS</Label> <Format>NTFS</Format> <Active>true</Active> <Extend>false</Extend> </ModifyPartition> </ModifyPartitions> </Disk> </DiskConfiguration> </component> <component name="Microsoft-Windows-International-Core-WinPE" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" processorArchitecture="x86"> <SetupUILanguage> <WillShowUI>OnError</WillShowUI> <UILanguage>en-US</UILanguage> </SetupUILanguage> <UILanguage>en-US</UILanguage> </component> </settings> </unattend>
Nutanixは、(現状では)Kubernetesを使用することで、永続的 (persistent) コンテナを利用することができます。以前もNutanixプラットフォームでDockerを動かすことは可能でしたが、短命なコンテナの特性によってデータの永続性確保が困難でした。
Dockerのようなコンテナテクノロジーは、ハードウェアの仮想化とは異なるアプローチと言えます。従来の仮想化では、それぞれのVM自体がオペレーティングシステム (OS) を持っていましたが、基盤となるハードウェアは共有されていました。アプリケーションやそれに必要な全てを含むコンテナは、オペレーティングシステム (OS) のカーネルを共有しながら、独立したプロセスとして実行されます。
以下の表では、VMとコンテナの簡単な比較を行っています:
比較基準 | 仮想マシン (VM) | コンテナ |
---|---|---|
仮想化タイプ | ハードウェアレベルの仮想化 | OSカーネルの仮想化 |
オーバーヘッド | 重い | 軽い |
プロビジョニングの速さ | 遅い(数秒から数分) | リアルタイム / 高速 (usからms) |
パフォーマンス オーバーヘッド |
限定的なパフォーマンス | ネイティブなパフォーマンス |
セキュリティ | 完全に独立(相対的に高い) | プロセスレベルで独立 (相対的に低い) |
本ソリューションでは、以下の構成をサポートします。(一部のみを掲載しています。完全なリストについてはドキュメントをご覧ください)
*AOS 4.7の時点で本ソリューションがサポートする対象は、Dockerベースのコンテナとの連携に限定されていますが、他のコンテナシステムについても、Nutanixプラットフォーム上のVMとして稼動させることが可能です。
Karbonコンテナサービスは、以下の要素で構成されています:
Dockerは以下の要素から構成されています(注意:全てが必要となる訳ではありません)
現在のところNutanixでは、Docker Machineを使用して生成されたVM内で稼動するDocker Engineを使用しています。これらのマシンは、通常のVMと一緒にプラットフォーム上で稼動させることができます。
Nutanixが開発したDocker Volume Pluginは、AOS Volumesの機能を利用して、コンテナ用にボリュームを作成、フォーマット、そしてアタッチします。 これによって、電源のオン・オフの繰り返しや移動において、データはコンテナとして永続性を保つことができます。
データの永続性は、AOS Volumesを活用してボリュームをホストやコンテナにアタッチするNutanix Volume Pluginを使用することで確保されます。
コンテナサービスを使用するためには、以下の前提条件を満たす必要があります:
上記前提条件が全て満たされた前提で、Docker Machine を使用してNutanix Dockerホストをプロビジョニングする最初の手順は:
docker-machine -D create -d nutanix \ --nutanix-username <PRISM_USER> --nutanix-password <PRISM_PASSWORD> \ --nutanix-endpoint <CLUSTER_IP>:9440 --nutanix-vm-image <DOCKER_IMAGE_NAME> \ --nutanix-vm-network <NETWORK_NAME> \ --nutanix-vm-cores <NUM_CPU> --nutanix-vm-mem <MEM_MB> \ <DOCKER_HOST_NAME>
下図にバックエンドのワークフロー概要を示します:
次に、docker-machine ssh経由で、新たに用意されたDockerホストに対してSSHを実行します:
docker-machine ssh <DOCKER_HOST_NAME>
以下を実行して、Nutanix Docker Volume Pluginをインストールします:
docker plugin install ntnx/nutanix_volume_plugin PRISM_IP=<PRISM-IP> DATASERVICES_IP=<DATASERVICES-IP> PRISM_PASSWORD=<PRISM-PASSWORD> PRISM_USERNAME=<PRISM-USERNAME> DEFAULT_CONTAINER=<Nutanix-STORAGE-CONTAINER> --alias nutanix
起動が完了したら、プラグインの有効化を確認します:
[root@DOCKER-NTNX-00 ~]# docker plugin ls ID Name Description Enabled 37fba568078d nutanix:latest Nutanix volume plugin for docker true
Nutanix Dockerホストが導入され、ボリュームプラグインが有効化されると、永続的ストレージにコンテナをプロビジョニングすることができます。
通常のdocker volumeコマンド構造を使ってNutanix Volume Driverを指定することで、AOS Volumesを使用するボリュームを作成することができます。 以下に例を示します:
docker volume create \ <VOLUME_NAME> --driver nutanix
例:
docker volume create PGDataVol --driver nutanix
以下のコマンド構造を使って、作成したボリュームを使用するコンテナを作成できます。
docker run -d --name <CONTAINER_NAME> \ -p <START_PORT:END_PORT> --volume-driver nutanix \ -v <VOL_NAME:VOL_MOUNT_POINT> <DOCKER_IMAGE_NAME>
例:
docker run -d --name postgresexample -p 5433:5433 --volume-driver nutanix -v PGDataVol:/var/lib/postgresql/data postgres:latest
下図にバックエンド処理のワークフローを示します:
以上のように、永続的ストレージ上でコンテナを動かすことができました!
Nutanixでは、ネイティブにバックアップとディザスタリカバリ (DR) 機能を提供しており、オンプレミスとクラウド環境(Xi)の両方で、ユーザーがDSF上で稼動する仮想マシンやオブジェクトをバックアップ、リストア、DRできるようにしています。 AOS 5.11 で、Nutanixはこれらの多くのコンセプトを抽象化するLeapとよばれる機能をリリースしました。 Leapについての追加情報は、Book of Backup / DR ServicesのLeapチャプターを参照してください。
次のセクションでは、以下の点について説明を行います:
注意: NutanixはネイティブにバックアップとDR機能を提供していますが、従来のソリューション(CommvaultやRubrikなど)についても、プラットフォームが提供するネイティブな機能(VSS、スナップショットなど)のいくつかを活用することで提供が可能です。
NutanixバックアップとDRには、幾つかの主要な構成要素があります:
希望するRPO/RTOに従って個々のサービス階層向けに複数のPDを作成します。 ファイル配布(ゴールデンイメージやISOなど)に対しては、レプリケーションするファイルを対象にPDを作成することができます。
整合性グループ内で依存関係にあるアプリケーションやサービスVMをグループ化することで、これらを整合性のある状態でリカバーすることができます(例えばアプリとDBなど)
スナップショットのスケジュールは、希望するRPOと一致している必要があります
リテンションポリシーは、VMまたはファイル毎に必要となるリストアポイントの数と一致している必要があります
ターゲットとなるサイトには、完全なサイト障害に備えた十分なキャパシティ(サーバー、ストレージ)が必要です。 このような場合には、単一サイト内のラック間でのレプリケーションも有効となります。
以下に、単一サイトのPD、CGおよびVMまたはファイルの関係を示します:
ポリシーベースのDRとランブックは、VMベースのDRで定義されていた機能(PD、CGなど)を拡張し、ポリシー駆動モデルとして抽象化します。 重要な項目(例えばRPOや保持期限など)に焦点をあて、VMに直接ではなくカテゴリ割り当てにすることで、設定を簡素化します。 また、すべてのVMに適用できる「デフォルトポリシー」を設定することもできます。
注: これらのポリシーは、Prism Central(PC)で構成します。
以下の手順に従って、エンティティ(VM、VG、ファイル)を保護することができます:
Data Protection(データ保護)ページで、+ Protection Domain -> Async DR とします:
PD名を設定し、「Create(作成する)」をクリックします。
保護するエンティティの選択:
「Protect Selected Entities(選択済みエンティティを保護)」をクリックします。
保護されたエンティティは、「Protected Entities(保護されているエンティティ)」に表示されます。
「Next(次へ)」をクリックし、次に「Next Schedule(次回のスケジュール)」をクリックしてスナップショットとレプリケーションをスケジュールします。
スナップショットの頻度、保存方針、レプリケーションするリモートサイトを設定します。
「Create Schedule(スケジュールを作成)」をクリックし、スケジュールを完成させます。
スナップショットやレプリケーションスケジュールは、複数作成することができます。例えば、1時間おきにローカルバックアップを取得し、日次でリモートサイトに対してレプリケーションを行うといった対応が可能です。
単純化するために、コンテナ全体を保護対象にできる点に留意してください。ただし、プラットフォーム自体は、VMやファイルといった粒度での保護が可能です。
Nutanixのバックアップ機能は、Cerebroによって起動されるネイティブなDSFスナップショット機能を使用してStargateが実行します。スナップショット機能は、ゼロコピー (zero copy) であり、ストレージを効率的に使用してオーバーヘッドを低減しています。スナップショットの詳細については、「スナップショットとクローン」のセクションをご覧ください。
通常のバックアップとリストア操作には、次のようなものがあります:
「エンティティの保護」セクションで作成した保護ドメイン (PD) は、Data Protection(データ保護)ページで確認することができます。
一旦、対象となるPDを選択すると、いくつかのオプションを選択することができます:
「Take Snapshot(スナップショットの取得)」をクリックすると、選択済みPDのスナップショットをアドホックに取得し、必要に応じてリモートサイトにレプリケートすることができます。
また、PDを「Migrate(移行)」して、リモートサイトにフェイルオーバーさせることも可能です:
移行(コントロール下にあるフェイルオーバー)が発生すると、システムは新しいスナップショットを作成してレプリケートし、新しいナップショットが作成されたことを他のサイトに通知します。
AOS 5.0以降は、単一ノードのレプリケーションターゲットを使用して、データを保護することができます。
PDのスナップショットについても以下の一覧で確認することができます:
ここからPDスナップショットをリストアまたはクローンすることもできます:
「Create new entities(新しくエンティティを作成)」を選択すると、指定したプリフィックスを持つ新しいエンティティにPDのスナップショットをクローンします。あるいは「Overwrite existing entities(既存エンティティに上書き)」を選択すると、現在のエンティティをスナップショット時にリプレースします。
バックアップやアーカイブのみが目的であれば、バックアップ先として、ストレージ機能のみのNutanixクラスタをリモートサイトに構成することが可能です。 データは、ストレージ機能のみのクラスタへ(から)レプリケートすることができるようになります。
NutanixのVmQuesced Snapshot Service (VSS) 機能によって、OSやアプリケーションの静止 (queiscing)操作を行い、アプリケーション整合性を保ったスナップショットを取得することができます。
VSSと言えば、通常WindowsのVolume Shadow Copy Serviceを指します。 しかしこの機能は、WindowsとLinux双方に適用できるため、NutanixではVmQueisced Snapshot Serviceと呼んでいます。
本ソリューションは、WindowsとLinuxゲスト双方に対応します。 完全なサポート対象ゲストOSの一覧については、"Compatibility and Interoperability Matrix" にある "NGT Compatibility" をご覧ください: LINK
Nutanix VSSスナップショットを使用するためには、以下が必要です:
AOS 4.6では、Nutanix Guest Toolsパッケージの一部としてインストールされる、ネイティブなNutanixハードウェアVSSプロバイダーを使用しています。
以下にVSSアーキテクチャー概要を示します:
通常のデータ保護ワークフローを踏襲し、VMの保護において「Use application consistent snapshots(アプリケーション整合性スナップショットを使用)」を選択することで、 アプリケーション整合性のあるスナップショットを取得することができます。
UVMのNGTが有効されていれば、Nutanix VSSスナップショット機能もデフォルトで有効化されています。しかし、本機能は、以下のコマンドで無効化することができます。
ncli ngt disable-applications application-names=vss_snapshot vm_id=<VM_ID>
Nutanix VSSソリューションは、Windows VSSフレームワークと連携しています。下図にそのアーキテクチャー概要を示します:
一旦、NGTがインストールされると、NGTエージェントとVSS Hardware Providerサービスを確認することができます:
LinuxソリューションもWindowsソリューションに似ていますが、Linuxディストリビューションの場合には、Microsoft VSSフレームワークに該当するような機能が存在しないため、スクリプトを使用します。
以下にアーキテクチャー概要を示します:
pre-freezeとpost-thawスクリプトは、以下のディレクトリにあります:
ESXiでは、VMware Toolsを使用した、ネイティブなアプリケーション整合性スナップショットをサポートしています。 しかし、この処理の途中で差分ディスクが生成されるため、ESXiは、仮想ディスクを新規のWRITE I/Oを処理する新しい差分ファイルにマップするためにVMをスタン(stun:一時停止)させます。 このスタン状態は、VMwareスナップショットを削除した場合にも発生します。
VMがスタン状態の間、OSは一切の処理を行うことができず、基本的には「スタック」した状態(pingが通らない、I/O処理ができないなど)になります。 このスタンの長さは、vmdksの数とデータストア メタデータ処理(新規差分ディスクの作成など)の速さに依存します。
Nutanix VSSを使用することで、VMwareスナップショット / スタン処理を完全にバイパスし、VMやOSのパフォーマンスや可用性にほとんど影響を与えないようにすることができます。
ビデオによる解説はこちらからご覧いただけます:LINK
Nutanixでは、スナップショットおよびクローンのセクションで説明した機能をベースにしたネイティブなDRとレプリケーション機能を提供しています。 Cerebroは、DSFのDRとレプリケーション管理を担当するコンポーネントです。Cerebroは、全てのノードで稼動しますが、(NFSリーダー同様に)Cereboroリーダーが選択され、レプリケーション管理を担当します。 Cerebroリーダーに障害が発生し、CVMが代理で稼動している場合には、他のCerebroが選定され役割を引き継ぎます。 Cerebroのページは<CVM IP>:2020 にあります。 DRの機能は、以下に示すいくつかの主要な領域に分解することができます:
以前から、サイト・ツー・サイト、ハブ・アンド・スポーク、フルまたは部分メッシュなど、レプリケーションのトポロジーはいくつか存在していました。 Nutanixでは、従来のサイト・ツー・サイトやハブ・アンド・スポークのみが可能なソリューションとは異なり、フルメッシュあるいは多対多モデルも提供しています。
基本的に、企業のニーズに合わせたレプリケーション機能をシステム管理者が選択できるのです。
前述の通り、Nutanixのレプリケーション機能はCerebroサービスを利用しています。Cerebroサービスは、動的に選定されるCVMである「Cerebroリーダー」と、各CVMで稼動するCerebroワーカーに分けられます。 「Celerbroリーダー」となったCVMに障害が発生した場合は、新しい「リーダー」が選定されます。
Cerebroリーダーは、ローカルにあるCerebroワーカーに対するタスク委譲管理を行い、リモートレプリケーションが発生した場合、リモートにある(複数の)Cerebroリーダーとのコーディネーションを行います。
レプリケーションが発生すると、Cerebroリーダーはレプリケーションの対象となるデータを特定し、レプリケーションタスクをCerebroワーカーに移譲し、Stargateにレプリケーションすべきデータとその場所を指示します。
レプリケーションされたデータは、プロセス全体の複数のレイヤー上で保護されます。 エクステントが読み込んだソースは、ソースデータの整合性を確保するよう(DSFの読み込み同様に)チェックサムが取られ、新しいエクステントについてもレプリケーション先で(DSFの書き込み同様)チェックサムが取られます。 ネットワークレイヤーの整合性はTCPで確認します。
以下に、このアーキテクチャーを図示します:
リモートサイトはプロキシを使って設定し、全てのコーディネーションやクラスタから到来するレプリケーショントラフィックの拠点として使用することもできます。
プロキシを利用してリモートサイトの設定を行う場合には、常にPrism Leaerにホストされ、CVMが停止した場合でも使用可能な状態にするため、必ずクラスタIPを使用するようにします。
以下に、プロキシを使用したレプリケーションアーキテクチャーを図示します:
SSHトンネルを使用してリモートサイトを設定することも可能ですが、この場合トラフィックは、2つのCVM間を流れることになります。
以下に、SSHトンネルを使用したレプリケーションアーキテクチャーを図示します:
Elastic Deduplication Engine(弾力的重複排除エンジン)のセクションで説明した通り、DSFではメタデータのポインタを更新するのみで重複排除ができるようになっています。 同じ考え方がDRとレプリケーション機能にも適用されます。DSFは回線越しにデータを送出する前にリモートサイトにクエリをかけ、ターゲットに既にフィンガープリントが存在しているかどうか(つまりデータが存在しているかどうか)を確認します。 存在している場合には、回線越しにデータを送出することなく、メタデータ更新のみが行われます。 ターゲットサイトにデータが存在しない場合には、該当データが圧縮されに送出されます。 この時点でデータは両方のサイトに存在することになり、重複排除の対象となり得ます。
以下は、1つ以上のプロテクションドメイン(PD)を有する3つのサイトからなる構成例を示しています:
レプリケーションの重複排除を可能にするためには、ソースおよびターゲットとなるコンテナおよびvstoreで、フィンガープリントが有効化されている必要があります。
Nutanixでは、先に説明した従来の非同期(async)レプリケーション機能をベースにした、同期に近いレプリケーション(NearSync: Near Syncronous Replication)の提供をはじめました。
NearSyncは、プライマリI/Oのレイテンシーに(非同期レプリケーションのような)影響を与えないことに加え、(同期レプリケーション(Metro)のような)非常に短いRPOを実現することが可能です。 これによってユーザーは、通常、同期レプリケーションの書き込みに必要となるオーバーヘッドなしに、非常に短いRPOを実現することが可能になります。
この機能には、「ライトウェイトスナップショット (LWS: Light-Weight Snapshot)」と呼ばれるテクノロジーが使用されています。 非同期で使用する従来のvDiskベースのスナップショットとは異なり、NearSyncは、マーカーを使用した完全にOpLogベースの機能となっています(一方、vDiskのスナップショットはエクステントストアで行われます)。
Mesosは、スナップショット層の管理と、フル / 増分スナップショットにおける複雑性の排除を目的に追加された新しいサービスです。 ハイレベルな構造とポリシー(整合性グループなど)については引き続きCerebroが管理する一方で、MesosはStargateとのやり取りや、LWSのライフサイクルコントロール機能を受け持ちます。
NearSyncのコンポーネント間のやり取りの例を以下に示します:
ユーザーがスナップショットの取得頻度を15分以下に設定すると、自動的にNearSyncが使用されます。この場合、初期のシードスナップショットが取得され、リモートサイトにレプリケーションされます。これが60分未満で完了すると、すぐに別のシードスナップショットが取得されてレプリケートされ、LWSスナップショットのレプリケーションが開始されます。2番目のシードスナップショットのレプリケーションが完了すると、既に存在する全てのLWSスナップショットが有効となり、システムは安定したNearSync状態となります。
以下に示す図は、NearSyncの有効化から実行までを時間の流れで追った例となります:
安定した状態にある間、vDiskのスナップショットは、1時間おきに取得されます。LSWとスナップショットを一緒にリモートサイトに送る代わりに、リモートサイトでは、以前のvDiskのスナップショットと、その時点以降のLWSを組み合わせてvDiskのスナップショットを生成します。
NearSyncの同期状態が崩れる(例えばネットワークの停止やWANの遅延など)と、LWSのレプリケーションに60分以上を要する状態となり、システムはvDiskベースのスナップショットに自動的に切り替えを行います。これらの内の1つが60分未満で完成すると、LWSのレプリケーションを開始する場合と同様に、システムは瞬時に他のスナップショットを取得します。一旦完全なスナップショットが完成すると、LWSスナップショットは有効となり、システムは安定したNearSyncの同期状態となります。このプロセスは、初期のNearSyncの有効化と同様の内容になります。
LWSベースのスナップショットがリストア(またはクローン)されると、システムは最新のvDiskのクローンを取得し、目的のスナップショットに達するまで、順次LWSを適用していきます。
以下の図は、LWSベースのスナップショットをリストアする方法を示しています:
Nutanixは、ネイティブでサーバーやストレージクラスタを複数の物理サイトに拡張する「ストレッチクラスタ」機能を提供しています。これらの導入では、サーバークラスタは2つのロケーションにまたがる形でストレージの共有プールにアクセスします。
VM HAドメインは、単独のサイトから2つのサイトに拡張され、ニアゼロのRTOやゼロRPOを実現することができます。
この場合、各サイトにはそれぞれNutanixクラスタが存在することになりますが、コンテナはWRITE処理を認識する前に同期される形でレプリケートされ、リモートサイトに「ストレッチ」されます。
以下に、本アーキテクチャーのデザイン概要を図示します:
サイトに障害が発生した場合、HAイベントを発行し、別のサイトでVMを再起動することが可能です。 通常、フェイルオーバー処理は手動での対応となります。 しかしAOS 5.0でリリースされたMetro Witnessの場合には、フェイルオーバーの自動化設定が可能です。 WitnessはポータルからダウンロードしてPrismを使って設定することができます。
以下に、サイト障害発生時の例を図示します:
2つのサイト間のリンクに障害が発生した場合、各クラスタはそれぞれ独立して運用されます。リンクが回復した時点で、両サイトで再同期が図られ(差分のみ)、同期レプリケーションが再開されます。
以下に、リンク障害発生時の例を図示します:
一般的なユーザーインターフェイスに加え、高度なNutanixページを参照して、詳細なステータスや指標をモニターすることができます。 URLは、http://<Nutanix CVM IP/DNS>:<Port/path(以下に説明)> という形式になります。 例: http://MyCVM-A:2009 注意: 異なるサブネットを使用している場合、ページにアクセスするためにはiptablesをCVMで無効化する必要があります。
バックエンド ストレージ システムをモニターするためのページであり、上級ユーザー向けとなります。 2009ページの説明や内容について別途投稿があります。
バックエンドのレイテンシーをモニターするためのStargateのページです。
I/Oサイズやレイテンシー、WRITEヒット(OpLog、eStoreなど)、READヒット(キャッシュ、SSD、HDDなど)その他のヒストグラムを含む、様々なvDiskステータスを提示する、Stargateのページです。
オペレーション状況をトレースしモニターするための、Stargateのページです。
各種カウンターをモニターするためのStargateのページです。
Curatorの稼動状況をモニターするためのCuratorのページです。
Curatorジョブをマニュアルで起動するための、Curatorコントロールのページです。
Curatorによってスケジューリングされたジョブやタスクをモニターするための、Chronosのページです。
プロテクションドメイン、レプリケーションのステータス、DRをモニターするための、Cerebroのページです。
PD処理やレプリケーション状況をトレースしモニターするための、Cerebroのページです。
Acropolisのメインとなるページで、環境内のホスト、稼動中のタスク、ネットワークなどの詳細を提示します。
VMやリソース配分の計画に必要な情報を提示するAcropolisのページです。このページには、利用可能なホストのリソースと各ホストで稼動するVMが表示されます。
Acropolisのタスクとステータスに関する情報を提示するAcropolisのページです。タスクのUUIDをクリックすると、タスクに関するJSONの詳細情報が表示されます。
AcropolisのVMとその詳細情報を提示するAcropolisのページです。VM名 (VM Name) をクリックすると、コンソールに接続されます。
説明: CLIからクラスタのステータスを確認
cluster status
説明: CLIから特定のCVMサービスのステータスを確認
genesis status
アップグレードのステータスを確認
upgrade_status
手動のCLIアップグレードを実行
cd ~/tmp
tar xzf <NUTANIX INSTALLER PACKAGE>.tar.gz
./install/bin/cluster -i ./install upgrade
説明: CVMのCLIから、ハイパーバイザーのアップグレードステータスを確認
host_upgrade_status
詳細ログ(各CVM上)
~/data/logs/host_upgrade.out
説明: CLIから特定のクラスタサービスを再起動
サービスを停止
cluster stop <Service Name>
停止したサービスを起動
cluster start #NOTE: This will start all stopped services
説明: CLIから停止したクラスタサービスを起動
停止したサービスを起動(注意: 全ての停止サービスが起動されます)
cluster start #NOTE: This will start all stopped services
または
特定のサービスを起動
cluster start <Service Name>
説明: CLIから特定のクラスタサービスを再起動
サービスを停止
genesis stop <Service Name>
サービスを起動
cluster start
説明: CLIから停止したクラスタサービスを起動
cluster start #NOTE: This will start all stopped services
説明: CLIからクラスタにノードを追加
ncli cluster discover-nodes | egrep "Uuid" | awk '{print $4}' | xargs -I UUID ncli cluster add-node node-uuid=UUID
説明: 現在のクラスタの、クラスタIDを調査
zeus_config_printer | grep cluster_id
説明: iptablesでポートを有効化
sudo vi /etc/sysconfig/iptables
-A INPUT -m state --state NEW -m tcp -p tcp --dport <PORT> -j ACCEPT
sudo service iptables restart
説明: シャドウ クローンを次の形式で表示: name#id@svm_id
vdisk_config_printer | grep '#'
説明: レイテンシーページ (
allssh "wget $i:2009/latency/reset"
説明: vDiskの情報や名前、ID、サイズ、IQNとして他を含む詳細を調査
vdisk_config_printer
説明: DSF上のvDisk(ファイル)の数を調査
vdisk_config_printer | grep vdisk_id | wc -l
説明: 指定したvDiskのegroup ID、サイズ、変換とセービング、ガベージ、レプリカ配置を表示
vdisk_usage_printer -vdisk_id=<VDISK_ID>
説明: CLIからCuratorフルスキャンを起動
フルスキャン
allssh "wget -O - "http://localhost:2010/master/api/client/StartCuratorTasks?task_type=2";"
部分的なスキャン
allssh "wget -O - "http://localhost:2010/master/api/client/StartCuratorTasks?task_type=3";"
使用量の更新
allssh "wget -O - "http://localhost:2010/master/api/client/RefreshStats";"
説明: curator_idでレプリケーション中のデータを確認
curator_cli get_under_replication_info summary=true
説明:メタデータリングを圧縮
allssh "nodetool -h localhost compact"
説明: AOSのバージョンを調査(注意: NCLIを使うことも可能)
allssh "cat /etc/nutanix/release_version"
説明: CVMのイメージのバージョンを調査
allssh "cat /etc/nutanix/svm-version"
説明: (重複解除向けに) 特定のvDiskのフィンガープリントを作成。注意:コンテナの重複排除が有効になっている必要があります。
vdisk_manipulator -vdisk_id=<vDisk ID> --operation=add_fingerprints
説明:(重複排除向けに)全てのvDiskのフィンガープリントを作成。注意:コンテナの重複排除が有効になっている必要があります。
for vdisk in `vdisk_config_printer | grep vdisk_id | awk {'print $2'}`; do vdisk_manipulator -vdisk_id=$vdisk --operation=add_fingerprints; done
説明: 全てのクラスタノードに対しFactory_Config.json をエコー
allssh "cat /etc/nutanix/factory_config.json"
説明: 特定のノードのAOSバージョンとクラスタに整合ようにアップグレード
~/cluster/bin/cluster -u <NEW_NODE_IP> upgrade_node
説明: ファイルとDSFにストアされているvDiskに関する情報一覧を表示
nfs_ls
ヘルプテキストの出力
nfs_ls --help
説明: 潜在的問題やクラスタのヘルスをテストするためのヘルススクリプト、Nutanix Cluster Check (NCC) をインストール
tar xzmf <ncc .tar.gz file name> --recursive-unlink
インストールスクリプトの実行
./ncc/bin/install.sh -f <ncc .tar.gz file name>
リンクを作成
source ~/ncc/ncc_completion.bash
echo "source ~/ncc/ncc_completion.bash" >> ~/.bashrc
説明:潜在的問題やクラスタのヘルスをテストするためのヘルススクリプト、Nutanix Cluster Check (NCC) を実行。 クラスタに問題が発見された場合のトラブルシューティングとして、最初に実行すべきことです。
NCCヘルスチェックを実行
ncc health_checks run_all
progress_monitor_cli -fetchall
progress_monitor_cli --entity_id=<ENTITY_ID> --operation=<OPERATION> --entity_type=<ENTITY_TYPE> --delete
注意: operationとentity_typeは、先頭にある小文字のkをすべて削除する必要があります。
以下のセクションでは、Nutanixバックエンドに対する特定の指標や、しきい値について説明します。この内容は今後も適時更新します!
近日公開!
説明: クラスタのAcropolisのログを調査
allssh "cat ~/data/logs/Acropolis.log"
説明: クラスタのERRORログを調査
allssh "cat ~/data/logs/<COMPONENT NAME or *>.ERROR"
Stargateの例
allssh "cat ~/data/logs/Stargate.ERROR"
説明: クラスタのFATALログを調査
allssh "cat ~/data/logs/<COMPONENT NAME or *>.FATAL"
Stargateの例
allssh "cat ~/data/logs/Stargate.FATAL"
ほとんどの場合、必要な情報やデータはPrismを使って得ることができます。 しかし、より詳細な情報を入手したいような場合は、Stargate(または2009ページと呼ばれる)を使用することができます。 2009ページは、<CVM IP>:2009 で見ることができます。
異なるネットワークセグメント(L2サブネット)にいる場合、バックエンドページにアクセスするためには、IPテーブルにルールを追加する必要があります。
ページの最上部には、クラスタに関する様々な細部に関する概要が表示されます。
このセクションには、2つの重要な部分が含まれています。1つ目はI/Oキューで、これは処理待ちまたは未処理のI/O数を表します。
以下は、概要セクションのQueueに関する部分です:
2つめは、コンテンツキャッシュのキャッシュサイズとヒット率に関する情報を表示する部分です。
以下は、概要セクションのコンテンツキャッシュに関する部分です:
理想的には、ワークロードがREAD中心型で、最大のREADパフォーマンスを発揮した場合、ヒット率は80~90%を超えるものになります。
注意: 以上は、Stargate / CVM あたりの数値です。
次は「クラスタステータス」に関するセクションで、クラスタ内のStargateとそのディスク使用状況に関する詳細を表示しています。
以下は、Stargateとディスク使用状況(利用可能/合計)を図示したものです:
次のは「NFSワーカー」に関するセクションで、vDisk単位で様々な詳細やステータスを表示しています。
以下は、vDiskとI/Oの詳細を図示したものです:
潜在的なパフォーマンスに関する問題を調査する場合、以下のメトリックを確認する必要があります:
より詳細な情報が、vdisk_stats ページに多数含まれています。
2009 vdisk_statsページは、vDiskに関するより詳細なデータを提供するためのページです。このページにはランダムネス、レイテンシーヒストグラム、I/Oサイズ、ワーキングセットの詳細などが含まれています。
左の列にある「vDisk Id」をクリックするとvDisk_statsページに移ります。
以下は、セクションとvDisk IDのハイパーリンクを示しています:
vdisk_statsページに移ると、vDiskのステータス詳細が表示されます。注意: 表示されている値はリアルタイムなもので、ページをリフレッシュすることで更新することができます。
まず重要なセクションは、「オペレーションとランダムネス (Ops and Randomness)」で、I/Oパターンをランダムなものとシーケンシャルなものに分解しています。
以下は、「オペレーションとランダムネス (Ops and Randomness)」セクションを図示したものです:
次の部分には、フロントエンドのREADおよびWRITE I/Oのレイテンシー(あるいはVM/OSから見たレイテンシー)のヒストグラムが表示されています。
以下が、「フロントエンドREADレイテンシー」のヒストグラムになります:
以下が、「フロントエンドWRITEレイテンシー」のヒストグラムになります:
次の重要な領域は、I/Oサイズの分散で、READとWRITEのI/Oサイズのヒストグラムを表示しています。
以下が、「READサイズの分散」のヒストグラムになります:
以下が、「WRITEサイズの分散」のヒストグラムになります:
次の重要な領域は、「ワーキングセットサイズ」で、直近2分間と1時間におけるワーキングセットサイズに関する情報を提供しています。内容は、READとWRITE I/Oに分けられています。
以下が、「ワーキングセットサイズ」テーブルになります:
「READソース (Read Source)」は、READ I/Oに対する処理が行われた階層またはロケーションの詳細を示します。
以下が、「READソース (Read Source)」詳細になります:
READに高いレイテンシーが見られる場合、vDiskのREADソースを見て、I/O処理がどこで行われているかを確認します。 ほとんどの場合、READがHDD(Estore HDD)で処理されることでレイテンシーが高くなります。
「WRITE先 (Write Destination)」は、新規WRITE I/Oがどこに対して行われるかを示します。
以下が、「WRITE先 (Write Destination)」一覧になります:
ランダムまたは小規模なI/O (<64K) は、OpLogに書き込まれます。大規模あるいはシーケンシャルなI/OはOpLogをバイパスし、エクステントストア (Estore)に直接書き込まれます。
データの、HDDからSSDへの上層移動がILMによって行われます。 「エクステントグループ上層移動(Extent Group Up-Migration)」一覧は、直近300、3,600、86,400秒に上層移動したデータを示しています。
以下が、エクステントグループ上層移動(Extent Group Up-Migration)」一覧になります:
2010ページは、Curator MapReduceフレームワークの詳細をモニターするためのページです。このページは、ジョブ、スキャンおよび関連するタスクの詳細情報を提供します。
Curatorページには、http://<CVM IP>:2010 から入ることができます。 注意: Curatorリーダーにいない場合は、「Curator Leader:」の後のIPアドレスをクリックしてください。
ページの上部には、稼動時間、ビルドバージョンなど、Curatorリーダーに関する詳細な情報が表示されます。
次のセクションには、「Curatorノード」一覧があり、クラスタ内のノード、ロール、ヘルス状態といった詳細が表示されています。 これらは、Curatorが分散処理とタスクの移譲のために使用しているノードです。
以下が「Curatorノード」一覧になります:
次のセクションは「Curatorジョブ」一覧で、完了したジョブと現在実行中のジョブを表示しています。
ジョブには主に、60分に1回程度の実行が望ましいパーシャルスキャンと、6時間に1回程度の実行が望ましいフルスキャンという2つのタイプがあります。注意:実行タイミングは、使用率や他の処理状況により異なります。
スキャンはスケジュールに基づいて定期的に実行されますが、特定のクラスタイベントによっても起動されます。
ジョブが実行されるいくつかの理由を、以下に示します:
以下が「Curatorジョブ」一覧になります:
一覧には、各ジョブが実行したアクティビティの概要の一部が記載されています:
処理 | フルスキャン | パーシャルスキャン |
---|---|---|
ILM | X | X |
ディスクバランシング | X | X |
圧縮 | X | X |
重複排除 | X | |
消失訂正符号 (EC) | X | |
ガベージクリーンアップ | X |
「実行ID (Execution ID)」をクリックすると、ジョブの詳細ページに移り、生成されたタスクと同時にジョブの詳細情報が表示されます。
ページの上部に表示される一覧には、ジョブのタイプ、理由、タスク、デュレーションといった詳細が表示されます。
次のセクションには「バックグラウンドタスクステータス (Background Task Stats)」一覧があり、タスクのタイプ、生成された数量やプライオリティといった詳細が表示されます。
以下がジョブ詳細一覧になります:
以下が「バックグラウンドタスクステータス」一覧になります:
次のセクションには「MapReduceジョブ」一覧があり、各Curatorジョブにより起動された、実際のMapReduceジョブが表示されます。パーシャルスキャンには単独のMapReduceジョブとなり、フルスキャンは4つのMapReduceジョブとなります。
以下が「MapReduceジョブ」一覧になります:
「ジョブID (Job ID)」をクリックすると、MapReduceジョブの詳細ページに移り、タスクステータス、各種カウンター、MapReduceジョブの詳細が表示されます。
以下に、ジョブのカウンターの例を図示します:
メインページの次のセクションには、「QueueされたCuratorジョブ」および「最後に完了したCuratorスキャン」一覧があります。これらの一覧には、定期的なスキャンを実施すべき適切な時間と、最後に実行されたたスキャン詳細が表示されています。
以下が「QueueされたCuratorジョブ」および「最後に完了したCuratorスキャン」セクションになります:
通常のトラブルシューティングやパフォーマンスの監視にあたっては、Prismがあれば全ての対応が可能です。しかし、これまで説明したバックエンドページやCLIで得た情報に関して、さらに詳細に把握したい場合もあるでしょう。
vdisk_config_printerは、クラスタの全てのvDiskに関する情報の一覧を表示するコマンドです。
以下に、主要なフィールドを列挙します:
以下に、コマンドの出力例を示します:
nutanix@NTNX-13SM35210012-A-CVM:~$ vdisk_config_printer | more ... vdisk_id: 1014400 vdisk_name: "NFS:1314152" parent_vdisk_id: 16445 vdisk_size: 40000000000 container_id: 988 to_remove: true creation_time_usecs: 1414104961926709 mutability_state: kImmutableSnapshot closest_named_ancestor: "NFS:852488" vdisk_creator_loc: 7 vdisk_creator_loc: 67426 vdisk_creator_loc: 4420541 nfs_file_name: "d12f5058-f4ef-4471-a196-c1ce8b722877" may_be_parent: true parent_nfs_file_name_hint: "d12f5058-f4ef-4471-a196-c1ce8b722877" last_modification_time_usecs: 1414241875647629 ...
vdisk_usage_printerは、vDiskの詳細、エクステント、egroupに関する情報の取得に使用します。
以下に、主要なフィールドを列挙します:
以下に、コマンドの出力例を示します:
nutanix@NTNX-13SM35210012-A-CVM:~$ vdisk_usage_printer -vdisk_id=99999 Egid # eids UT Size T Size ... T Type Replicas(disk/svm/rack) 1256878 64 1.03 MB 1.03 MB ... D,[73 /14/60][184108644 /184108632/60] 1256881 64 1.03 MB 1.03 MB ... D,[73 /14/60][152 /7/25] 1256883 64 1.00 MB 1.00 MB ... D,[73 /14/60][184108642 /184108632/60] 1055651 4 4.00 MB 4.00 MB ... none[76 /14/60][184108643 /184108632/60] 1056604 4 4.00 MB 4.00 MB ... none[74 /14/60][184108642 /184108632/60] 1056605 4 4.00 MB 4.00 MB ... none[73 /14/60][152 /7/25] ...
注意: 重複排除済みと非重複排除でのegroupのサイズの違い(1MB対4MB)にご注意下さい。 「データ構造」セクションで説明したように、重複排除の結果、重複排除後のデータにフラグメンテーションが発生しないようにするためには、egroupサイズが1MBの方を優先すべきです。
curator_cli display_data_reduction_reportを使って、コンテナ別のストレージ削減量に関する詳細情報を、適用したトレージの変換テクニック(クローン、スナップショット、重複排除、圧縮、消失訂正符号など)別にレポートすることができます。
以下に、主要なフィールドを列挙します:
以下に、コマンドの出力例を示します:
CVM:~$ curator_cli display_data_reduction_report Using curator leader: 99.99.99.99:2010 Using execution id 68188 of the last successful full scan +---------------------------------------------------------------------------+ | Container| Technique | Pre | Post | Saved | Ratio | | Id | | Reduction | Reduction | | | +---------------------------------------------------------------------------+ | 988 | Clone | 4.88 TB | 2.86 TB | 2.02 TB | 1.70753 | | 988 | Snapshot | 2.86 TB | 2.22 TB | 656.92 GB | 1.28931 | | 988 | Dedup | 2.22 TB | 1.21 TB | 1.00 TB | 1.82518 | | 988 | Compression | 1.23 TB | 1.23 TB | 0.00 KB | 1 | | 988 | Erasure Coding | 1.23 TB | 1.23 TB | 0.00 KB | 1 | | 26768753 | Clone | 764.26 GB | 626.25 GB | 138.01 GB | 1.22038 | | 26768753 | Snapshot | 380.87 GB | 380.87 GB | 0.00 KB | 1 | | 84040 | Snappy | 810.35 GB | 102.38 GB | 707.97 GB | 7.91496 | | 6853230 | Snappy | 3.15 TB | 1.09 TB | 2.06 TB | 2.88713 | | 12199346 | Snappy | 872.42 GB | 109.89 GB | 762.53 GB | 7.93892 | | 12736558 | Snappy | 9.00 TB | 1.13 TB | 7.87 TB | 7.94087 | | 15430780 | Snappy | 1.23 TB | 89.37 GB | 1.14 TB | 14.1043 | | 26768751 | Snappy | 339.00 MB | 45.02 MB | 293.98 MB | 7.53072 | | 27352219 | Snappy | 1013.8 MB | 90.32 MB | 923.55 MB | 11.2253 | +---------------------------------------------------------------------------+
curator_cli get_vdisk_usage lookup_vdisk_idsコマンドは、指定された各vDiskで使用されているスペースについてのさまざまな統計を取得するために使用されます。
以下、主要なフィールドを列挙します:
以下に、コマンドの出力例を示します:
Using curator leader: 99.99.99.99:2010 VDisk usage stats: +------------------------------------------------------------------------+ | VDisk Id | Exclusive | Logical | Logical | Logical | Logical | | | usage | Uninherited | Dedup | Snapshot | Clone | +------------------------------------------------------------------------+ | 254244142 | 596.06 MB | 529.75 MB | 6.70 GB | 11.55 MB | 214 MB | | 15995052 | 599.05 MB | 90.70 MB | 7.14 GB | 0.00 KB | 4.81 MB | | 203739387 | 31.97 GB | 31.86 GB | 24.3 MB | 0.00 KB | 4.72 GB | | 22841153 | 147.51 GB | 147.18 GB | 0.00 KB | 0.00 KB | 0.00 KB | ...
curator_cli get_egroup_access_infoを使って、最新のアクセス(読み込み、変更(書き込みまたは上書き))を基に、各バケットのegroupの数に関する詳細な情報をレポートすることができます。この情報を使えば、消失訂正符号に適したegroupの数を推定することができます。
以下に、主要なフィールドを列挙します:
以下に、コマンドの出力例を示します:
Using curator leader: 99.99.99.99:2010 Container Id: 988 +----------------------------------------------------------------------------.. | Access \ Modify (secs) | [0,300) | [300,3600) | [3600,86400) | [86400,60480.. +----------------------------------------------------------------------------.. | [0,300) | 345 | 1 | 0 | 0 .. | [300,3600) | 164 | 817 | 0 | 0 .. | [3600,86400) | 4 | 7 | 3479 | 7 .. | [86400,604800) | 0 | 0 | 81 | 7063 .. | [604800,2592000) | 0 | 0 | 15 | 22 .. | [2592000,15552000) | 1 | 0 | 0 | 10 .. | [15552000,inf) | 0 | 0 | 0 | 1 .. +----------------------------------------------------------------------------.. ...
AHVを導入した場合、コントローラーVM(CVM)はひとつのVMとして稼動し、ディスクはPCIパススルーを使用するようになります。 これにより、PCIコントローラー(および付属デバイス)のパススルーが完全に実現され、ハイパーバイザーを迂回してCVMに直接繋がるようになります。 AHVは、CentOS KVMをベースに構築されています。 ゲストVM (HVM) に対しては、完全なハードウェアの仮想化を使用します。
AHVは、CentOS KVMをベースに基本機能を拡張し、HAやライブ マイグレーションなどの機能を組み込んだものです。
AHVは、Microsoft Server Virtualization Validation Programの認定を受け、またMicrosoft OS やアプリケーションの稼動検証を受けています。
KVMの主要なコンポーネントは、以下に示す通りです:
以下に各コンポーネントの関連を示します:
AOSとKVM/QEMUは、libvirtdを経由して通信します。
異なるプロセッサ世代間でVMを移動できるVMwareのEnhanced vMotion Capability (EVC) と同様に、AHVでは、クラスタ内の最も古いプロセッサの世代を特定し、全てのQEMUドメインをそのレベルで取扱います。これによって、AHVクラスタ内に異なる世代のプロセッサが混在している場合でも、ホスト間のライブマイグレーションが可能となります。
以下の最大構成と拡張制限が適用されます:
*AHVには、ESXiやHyper-Vのような従来型のストレージ スタックはありません。 全てのディスクがロー(Raw)SCSIブロックデバイスとしてVMに提供されます。 このため、最大仮想ディスクサイズについては、最大DSF vDiskサイズ(9 エクサバイト)の制約を受けることになります。
AHVは、全てのVMネットワークに対してOpen vSwitch (OVS) を活用しています。VMネットワークは、PrismやACLIから設定することが可能で、各VM NICは、Tapインターフェイスに接続されます。
以下に、OVSアーキテクチャーの概念構成を示します:
上記の画像には、いくつかの種類のコンポーネントが表示されています。
OVSとは、Linuxカーネルに実装され、複数台のサーバー仮想化環境で動作するように設計されたオープンソースのソフトウェアスイッチです。 デフォルトでは、OVSはMACアドレステーブルを維持するレイヤー2ラーニングスイッチのように動作します。 ハイパーバイザーホストとVMはスイッチの仮想ポートに接続します。
OVSは、VLANタグ、Link Aggregation Control Protocol(LACP)、ポートミラーリング、Quality of Service(QoS)など、多くの一般的なスイッチの機能をサポートしています。 各AHVサーバーはOVSインスタンスを持ち、すべてのOVSインスタンスが結合して単一の論理スイッチを形成します。 ブリッジと呼ばれる構造は、AHVホストにあるスイッチのインスタンスを管理します。
ブリッジとは、物理と仮想ネットワークインターフェイス間のネットワークトラフィックを管理する仮想スイッチとして機能します。 デフォルトのAHV構成には、br0と呼ばれるOVSブリッジとvirbr0と呼ばれるネイティブLinuxブリッジが含まれています。 virbr0 Linuxブリッジは、CVMとAHVホスト間の管理およびストレージ通信を運送します。 他のすべてのストレージ、ホスト、およびVMネットワークのトラフィックはbr0 OVSブリッジを通過します。 AHVホスト、VM、および物理インターフェイスは、ブリッジへの接続に「ポート」を使用します。
ポートとは、仮想スイッチへの接続を表す、ブリッジに作成された論理構造です。 Nutanixでは、internal、tap、VXLAN、ボンドを含む、いくつかのポートタイプを使用します。
ボンドポートは、AHVホスト上の物理インターフェイスを束ねます。 デフォルトでは、br0-upという名前のボンドがbr0ブリッジに作成されます。 ノードをイメージングすると、すべてのインターフェイスは単一のボンド内に配置されます。これは、Foundationでのイメージング処理の要件によるものです。 デフォルトのボンド(AHVホストではbr0-up)に対して、(一般的なLinuxでは)bond0という名前がしばしば用いられますが、 Nutanixは、インターフェイスをブリッジbr0のアップリンクとして迅速に識別できるように、名前はbr0-upのまま使用することを推奨します。
OVSのボンドでは、active-backup、balance-slb、balance-tcpといった、いくつかの負荷分散モードが設定できます。 ボンドに対してLACPも有効化できます。 「bond_mode」の設定はインストール中に指定されないためデフォルトはactive-backupであり、これは推奨構成です。
前のセクションで簡単に説明したように、ボンドアップリンク間でトラフィックを分散できます。
以下のボンドモードが使用できます:
ボンドの詳細については、AHV Networkingのベストプラクティスガイド(LINK)を参照してください。
AHVは、以下のVMネットワークインターフェイスの種類をサポートします:
デフォルトで、VMのNICはAccessインターフェイスとして生成されますが、(ポートグループ上のVMのNIC同様に)VMのOSにTrunkインターフェイスとして提示することも可能です。 Trunk設定されたNICはプライマリVLANをタグなしで送信し、追加のすべてのVLANをタグ付けしてVM上の同じvNICで送信します。 これは、VMにvNICを追加せずに複数のネットワークを接続する場合に役立ちます。
Trunkインターフェイスは、以下のコマンドで追加することができます:
vm.nic_create <VM_NAME> vlan_mode=kTrunked trunked_networks=<ALLOWED_VLANS> network=<NATIVE_VLAN>
例:
vm.nic_create fooVM vlan_mode=kTrunked trunked_networks=10,20,30 network=vlan.10
AHVサービスチェーン(service chaining)によって、全てのトラフィックをインターセプトし、パケット処理機能(NFV、アプライアンス、仮想アプライアンスなど)に対してネットワークパスの延長として透過的に渡すことができます。
サービスチェーンの一般的な使用例:
サービスチェーンには、2つの方式があります:
全てのサービスチェーン処理は、Flowのマイクロセグメンテーション ルールが適用された後、かつパケットがローカルOVSから出る前に完了します:
説明: 複数のパケットプロセッサを、1つのチェーンに繋ぎ合わせることも可能です。
AHVには、簡単にクローンできるように単一vDiskのデータキャプチャにフォーカスしたイメージライブラリが常に持っていましたが、CPU、メモリ、そしてネットワークの詳細を設定するプロセスを完了するには、管理者からの入力が必要でした。 仮想マシンテンプレートは、この概念を次のレベルのシンプルなものにして、他のハイパーバイザーでテンプレートを利用したことがある管理者に馴染みのある仕組みを提供します。
AHVの仮想マシンテンプレートは既存の仮想マシンから作成され、CPU、メモリ、vDisk、そしてネットワークの詳細など、定義する仮想マシンの属性を受け継ぎます。 テンプレートは、展開時にゲストOSをカスタマイズするように構成でき、オプションとしてWindowsライセンスキーを提供できます。 テンプレートでは複数のバージョンを維持できるため、新しいテンプレートを作成する必要なく、オペレーティングシステムやアプリケーションパッチなどの更新を簡単に適用できます。 管理者はどのテンプレートのバージョンがアクティブか選択できるため、更新を事前にステージングしたり、必要に応じて以前のバージョンに戻すことができます。
仮想化の主な利点の1つは、コンピューティングリソースをオーバーコミットできることであり、これにより、サーバーホスト上に物理的に存在するよりも多くのCPUを仮想マシンにプロビジョニングできます。 ほとんどのワークロードは、割り当てられたすべてのCPUを100%必要とはしないため、ハイパーバイザーは、CPUサイクルを必要とするワークロードに各時点で動的に割り当てることができます。
CPUまたはネットワークリソースと同様に、メモリもオーバーコミットできます。 どの時点でも、ホスト上の仮想マシンでは、割り当てられたすべてのメモリを使用している場合も使用していない場合もあり、ハイパーバイザーは未使用のメモリを他のワークロードと共有できます。 メモリのオーバーコミットによって、未使用のメモリを組み合わせて必要とする仮想マシンに割り当てることで、管理者は各ホストにより多くの仮想マシンをプロビジョニングできるようになります。
AOS 6.1では、追加のメモリと仮想マシン密度が必要なテストや開発のような環境で、管理者が利用できるようにするオプションとしてメモリオーバーコミットをAHVにもたらします。 オーバーコミットはデフォルトで無効になっており、仮想マシン単位で定義できるため、クラスタ上の仮想マシンのすべてまたはサブセットのみで共有できます。
異なる種類のアプリケーションには、仮想マシンを同じホストで実行する必要があるか、または別のホストで実行する必要があるかを指示する要件があります。 これは通常、パフォーマンスもしくは可用性の利点のために行われます。 アフィニティ制御により、仮想マシンがどこで実行されるかを管理できるようになります。 AHVには、2種類のアフィニティ制御があります:
AHVは、ESXiやHyper-Vのような従来のストレージ スタックを使用してはいません。 全てのディスクは、ロー(raw)SCSIブロックデバイスとしてVMに渡されます。 これによってI/Oパスを軽量化および最適化することができます。
AOSは、エンドユーザーに対してkvm、virsh、qemu、libvirtおよびiSCSIを抽象化する形で、全てのバックエンド構成を処理します。 これによってユーザーは、PrismやACLIを使って、そのスタックより上のみを意識すればよくなります。 なお以下は、情報提供を目的とした説明であるため、マニュアル操作でvirshやlibvirtに触らないことを推奨します。
各AHVホストには、iSCSIリダイレクター デーモンが常駐し、NOP OUTコマンドを使用してクラスタのStargateに関するステータスチェックを行います。
iscsi_redirectorログ(AHVホストの/var/log/に存在)によって、各Stargateの稼動状態を確認することができます:
2017-08-18 19:25:21,733 - INFO - Portal 192.168.5.254:3261 is up
...
2017-08-18 19:25:25,735 - INFO - Portal 10.3.140.158:3261 is up
2017-08-18 19:25:26,737 - INFO - Portal 10.3.140.153:3261 is up
注意: ローカルのStargateは、内部アドレス192.168.5.254で確認できます。
以下の内容を見ると、iscsi_redirectorが127.0.0.1:3261でリスニングしていることが分かります:
[root@NTNX-BEAST-1 ~]# netstat -tnlp | egrep tcp.*3261 Proto ... Local Address Foreign Address State PID/Program name ... tcp ... 127.0.0.1:3261 0.0.0.0:* LISTEN 8044/python ...
QEMUは、iSCSIリダイレクターがiSCSIターゲットポータルとなるよう設定されます。ログインリクエストがあるとリダイレクターが起動され、iSCSIログインは、正常なStargate(通常はローカルにある)にリダイレクトされます。
XMLのドメインを確認すると、その構成が分かります:
<devices> ... <disk type='network' device='lun'> <driver name='qemu' type='raw' cache='none' error_policy='report' io='native'/> <source protocol='iscsi' name='iqn.2010-06.com.nutanix:vmdisk-16a5../0'> <host name='127.0.0.1' port='3261'/> </source> <backingStore/> <target dev='sda' bus='scsi'/> <boot order='1'/> <alias name='scsi0-0-0-0'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> ... </devices>
推奨するコントローラータイプは、virtio-scsi(SCSIデバイスのデフォルト)です。 IDEも使用できますが、ほとんどの場合、お薦めできません。Windowsでvirtioを使用する場合には、virtioドライバー、Nutanixモビリティドライバー、またはNutanix Guest Toolsがインストールされている必要があります。 最新のLinuxディストリビューターは、virtioをプリインストールして出荷しています。
... <controller type='scsi' index='0' model='virtio-scsi'> <driver max_sectors='2048'/> <alias name='scsi0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </controller> ...
稼動中のStargateが停止した(NOP OUTコマンドにレスポンスできない)場合、iSCSIリダイレクターは、ローカルのStargateを障害として判断します。そして、QEMUがiSCSIログインを再試行した時に、リダイレクターは、ログインオペレーションを他の正常なStargateにリダイレクトします。
ローカルのStargateが復旧(かつNOP OUTコマンドにレスポンスを開始)した場合、iSCSIリダイレクターは、リモートStargateへのiSCSIセッションを終了します。 QEMUは、iSCSIログインを再度試み、同ログインはローカルのStargateにリダイレクトされます。
全てのハイパーバイザーやOSと同様、ユーザー空間とカーネル空間のコンポーネントが相互にやり取りを行って、1つの処理を実行しています。 以下を読む前に「ユーザー空間とカーネル空間」のセクションを参照し、お互いがどういった関係でやり取りをしているかを理解することをお勧めします。
VMがI/Oを実行する場合、以下の処理が行われます(理解しやすくするため、一部の手順は省略してあります):
以下に、このフローの例を示します:
ドメインのXMLに着目すると、qemu-kvmエミュレータが使用されていることが分かります。
... <devices> <emulator>/usr/libexec/qemu-kvm</emulator> ...
またAHVホストを見ると、ローカルブリッジとIPを使用している正常なStargateを使って、qemu-kvmがセッションを確立しています。 外部との通信のため、外部ホストとStargate IPが使用されています。 注意: 1ディスクあたりのセッション数は、1つとなります(PID 24845をご覧ください)。
[root@NTNX-BEAST-1 log]# netstat -np | egrep tcp.*qemu Proto ... Local Address Foreign Address State PID/Program name tcp ... 192.168.5.1:50410 192.168.5.254:3261 ESTABLISHED 25293/qemu-kvm tcp ... 192.168.5.1:50434 192.168.5.254:3261 ESTABLISHED 23198/qemu-kvm tcp ... 192.168.5.1:50464 192.168.5.254:3261 ESTABLISHED 24845/qemu-kvm tcp ... 192.168.5.1:50465 192.168.5.254:3261 ESTABLISHED 24845/qemu-kvm ...
メインループがシングルスレッドになっていたり、libiscsiがすべてのSCSIコマンドを検査したりするなど、このパスには幾つか非効率な部分が存在します。
ストレージテクノロジーは、Nutanixと同様に進化を続け、その効率性をさらに高めています。 Nutanix自身の手でAHVやスタックを完全にコントロールできるようになった今こそ、絶好の機会です。
手短に言えば、Frodoはより優れたスループットや低レイテンシーの実現、さらにCPUのオーバーヘッドを減らすため、AHV向けに特別に最適化されたI/Oパスなのです。
FrodoはAOS 5.5.X以降でパワーオンされたVMにおいてデフォルトで有効になります。
VMがI/Oを実行する場合、以下の処理が行われます(理解し易くするため、一部の手順は省略してあります):
以下に、このフローの例を示します:
以下のパスは、いくつかの重要な点を除いて、従来のI/Oと変わりが無いように見えます:
パフォーマンスが向上するのみでなく、ゲストからはディスクデバイスに複数のキューが存在しているように見えます。 I/O処理のCPUオーバーヘッドが25%も低下したり、Qemuに比べパフォーマンスが3倍になったりした例もあります! 他のハイパーバイザーに比べても、I/O処理のCPUオーバーヘッドを最大3倍減らすことができます。
AHVホストを見ると、それぞれのVMに対してfrodoプロセス(qemu-kvmプロセス)が存在することが判ります。
[root@drt-itppc03-1 ~]# ps aux | egrep frodo ... /usr/libexec/qemu-kvm ... -chardev socket,id=frodo0,fd=3 \ -device vhost-user-scsi-pci,chardev=frodo0,num_queues=16... ... /usr/libexec/frodo ... 127.0.0.1:3261 -t iqn.2010-06.com.nutanix:vmdisk... ...
またドメインのXMLがfrodoを使用していることも判ります:
... <devices> <emulator>/usr/libexec/frodo</emulator> ...
Frodoのマルチスレッド / マルチコネクションの利点を活かすためには、VMが立ち上がった際に、1つのVMにつき2つ以上のvCPUを割り当てることが必要となります。
これは、以下のように特徴付けられます:
以下では、ローカルブリッジとIPを使用している正常なStargateを使って、Frodoがセッションを確立しています。外部との通信のため、外部ホストとStargate IPが使用されています。
[root@NTNX-BEAST-1 log]# netstat -np | egrep tcp.*frodo Proto ... Local Address Foreign Address State PID/Program name tcp ... 192.168.5.1:39568 192.168.5.254:3261 ESTABLISHED 42957/frodo tcp ... 192.168.5.1:39538 192.168.5.254:3261 ESTABLISHED 42957/frodo tcp ... 192.168.5.1:39580 192.168.5.254:3261 ESTABLISHED 42957/frodo tcp ... 192.168.5.1:39592 192.168.5.254:3261 ESTABLISHED 42957/frodo ...
Acropolis IPアドレス管理 (IPAM) により、DHCPスコープを構成し、VMに自動的にIPアドレスを割り当てることができます。この機能は、VXLANとOpenFlowルールを使用してDHCPリクエストに割り込みを行い、DHCPレスポンスによりレスポンスを返します。
以下は、Acropolisリーダーがローカルで稼動している場合の、Nutanix IPAMを使用したDHCPリクエストのオペレーション例です:
Acropolisリーダーがリモートで稼動している場合には、ネットワークを超えたリクエストを処理するために、同じVXLANトンネルが使用されます。
既存のDHCP / IPAM ソリューションも使用することが可能です。
AHV VM HAは、ホストやブロックに障害が発生した場合に、VMの可用性を確保するための機能です。 ホストに障害が発生した場合、そのホストで稼動していたVMは、クラスタ内の他の正常なノードに移動し再起動されます。 Acropolisリーダーがこの役割を担っています。
Acropolisリーダーは、クラスタ内全てのホスト上のlibvirtへの接続状況をモニターし、ホストのヘルスチェックを行っています:
libvirtの接続がダウンすると、HAによる再起動へのカウントダウンが開始されます。 libvirtの接続がタイムアウト期間内での再確立に失敗すると、Acropolisは切断されたホストで起動されていたVMを再起動します。 この場合、VMは120秒以内に再起動されるはずです。
Acropolisリーダーが分割された場合、またはネットワーク隔離された場合、さらに、障害が発生した場合には、クラスタ内の正常のノードが新しいAcropolisリーダーとして選定されます。 クラスタが分割された場合(例えば、Xノードが他のYノードに通信不能)には、クォーラムを持った方が動作を継続し、VMはそのノードで再起動されます。
VM HAには主に2つのモードがあります:
VM HAを保証 (Guarantee) モードにすると、システムはVMのためにホストのリソースを予約します。 予約されるリソースの量は、以下のように要約することができます:
ホストのメモリ容量に差がある場合、システムは最大のメモリ容量をもつホストを基準に、ホストあたりの予約量を決定します。
リリース5.0より前には、ホストとセグメントベース両方の予約をサポートしていました。 リリース5.0以降は、セグメントベースの予約のみとなり、これは保証HAモードが選択されると自動的に設定されます。
予約セグメントは、クラスタの全てのホスト全体にリソースを分散させます。 この場合それぞれのホストは、HAのために予約されたメモリを共有することになります。 これによって、ホストに障害が発生した場合でも、VMを再起動するための十分なフェイルオーバー容量をクラスタ全体で確保することができます。
以下の図は、予約セグメントの状態を示したものです:
ホストに障害が発生すると、VMはクラスタに残った正常なホストを使って再起動されます。
予約セグメントの総数と1ホストあたりの予約量は、システムが自動的に計算します。
必要な予約量の算出は、良く知られた「ナップサック問題」の解法に集約します。 最適な解は、NP困難 (NP-hard、指数関数的)ですが、実用的には発見的解法でも最適解に近いものを得ることができます。 Nutanixは、こうしたアルゴリズムの1つであるMTHMを採用しています。 Nutanixは、今後も配置アルゴリズムの改善に努めて参ります。
説明: ローカルホストのbond0に対してのみ10gを有効化する
manage_ovs --interfaces 10g update_uplinks
説明: クラスタ全体のovsアップリンクを表示
allssh "manage_ovs --interfaces 10g update_uplinks"
説明: ローカルホストのOVSアップリンクを表示
manage_ovs show_uplinks
説明: クラスタ全体のOVSアップリンクを表示
allssh "manage_ovs show_uplinks"
説明: ローカルホストのOVSインターフェイスを表示
manage_ovs show_interfaces
説明: クラスタ全体のインターフェイスを表示
allssh "manage_ovs show_interfaces"
説明: スイッチ情報を表示
ovs-vsctl show
説明: ブリッジ一覧を表示
ovs-vsctl list br
説明: OVSポート情報を表示
ovs-vsctl list port br0
ovs-vsctl list port <bond>
説明: インターフェイス情報を表示
ovs-vsctl list interface br0
説明: ブリッジのポートを表示
ovs-vsctl list-ports br0
説明: ブリッジのインターフェイスを表示
ovs-vsctl list-ifaces br0
説明: ブリッジの作成
ovs-vsctl add-br <bridge>
説明: ブリッジにポートを追加
ovs-vsctl add-port <bridge> <port>
説明: ブリッジにボンドポートを追加
ovs-vsctl add-bond <bridge> <port> <iface>
説明: ボンド詳細を表示
ovs-appctl bond/show <bond>
例:
ovs-appctl bond/show bond0
説明: ポートのLACPを有効化
ovs-vsctl set port <bond> lacp=<active/passive>
説明: 全ホストのbond0を有効化
for i in `hostips`;do echo $i; ssh $i source /etc/profile > /dev/null 2>&1; ovs-vsctl set port bond0 lacp=active;done
説明: LACPの詳細を表示
ovs-appctl lacp/show <bond>
説明: ポートにボンドモードを設定
ovs-vsctl set port <bond> bond_mode=<active-backup, balance-slb, balance-tcp>
説明: OVS openflowの詳細を表示
ovs-ofctl show br0
説明: OpenFlowのルールを表示
ovs-ofctl dump-flows br0
説明: QEMU PIDを取得
ps aux | grep qemu | awk '{print $2}'
説明: 指定したPIDの上位指標値を取得
top -p <PID>
説明: 各QEMUプロセスのストレージI/Oに対するアクティブなStargateを獲得
netstat -np | egrep tcp.*qemu
近日公開!
説明: 全ホストのiSCSIリダイレクターログを確認
for i in `hostips`; do echo $i; ssh root@$i cat /var/log/iscsi_redirector;done
単独ホストの例
ssh root@<HOST IP>
cat /var/log/iscsi_redirector
説明: CPUのSteal時間(Stolen CPU)をモニター
topを起動して %st(以下ではボールド表示)を探す
Cpu(s): 0.0%us, 0.0%sy, 0.0%ni, 96.4%id, 0.0%wa, 0.0%hi, 0.1%si, 0.0%st
説明: VMリソースのステータスをモニター
virt-topを起動
virt-top
ESXiを導入した場合、コントローラーVM (CVM) はVMとして稼動し、ディスクはVMダイレクトパスI/Oを使用するようになります。これによって、PCIコントローラー(および付属デバイス)のパススルーが完全に可能となり、ハイパーバイザーを迂回してCVMに直接繋がるようになります。
以下の最大構成と拡張制限が適用されます:
注意: vSphere 6.0 時点の情報です。
ESXiホストでベンチマークを行う場合、常にESXiホストのパワーポリシーを「ハイパフォーマンス(High performance)」に設定してテストを行います。 これで P-States および C-States を無効化し、テスト結果を人為的に制限しないようにします。
各ESXiホストにはローカルvSwitchがあり、Nutanix CVMとホストの、ホスト内部通信に使用されます。 外部やVMとの通信には、標準のvSwitch(デフォルト)またはdvSwitchが使用されます。
ローカルvSwtich(vSWitchNutanix)は、Nutanix CVMとESXiホスト間の通信のためのものです。 ホスト上のこのvSwitchにはVMkernelインターフェイス(vmk1-192.168.5.1)があり、CVMにはこの内部スイッチのポートグループにバインドされるインターフェイス(svm-iscsi-pg - 192.168.5.2)があります。 これが基本的なストレージの通信パスになります。
外部接続するvSwitchは、標準のvSwitch(標準仮想スイッチ)またはdvSwitch(分散仮想スイッチ)です。 これはESXiホストとCVMの外部インターフェイスをホストすると同時に、ホスト上のVMに使用されるポートグループもホストします。 外部のvmkernelインターフェイスは、ホスト管理やvMotionなどに使用されます。 外部CVMインターフェイスは、他のNutanix CVMとの通信に利用されます。 トランク上でVLANが有効になっていれば、必要に応じてポートグループが作成できます。
以下は、vSwitchアーキテクチャーの概念的な構造を図示したものです:
デュアルToRスイッチを使用して、スイッチHAのために、両スイッチをクロスしたアップリンク構成をとることを推奨します。システムは、デフォルトでアップリックインターフェイスをアクティブ/パッシブモードで使用します。アップストリームのスイッチアーキテクチャーが、アクティブ/アクティブなアップリンクインターフェイス(例えば、vPCやMLAGなど)に対応していれば、より高いネットワークスループットを得るためにこれを使用することができます。
Nutanixプラットフォームは、VMware API for Array Integration(VAAI)をサポートし、ハイパーバイザーのタスクをアレイにオフロードすることができます。 ハイパーバイザーが「仲介役」を果たす必要がなくなるため、より効率的になります。 現在Nutanixでは、「フルファイルクローン(full file clone)」、「ファストファイルクローン(fast file clone)」および「リザーブスペース(reserve space)」プリミティブを含む、NAS向けVAAIプリミティブをサポートしています。 各種プリミティブの優れた説明がこちらにあります: http://cormachogan.com/2012/11/08/vaai-comparison-block-versus-nas/
フルクローンとファストファイルクローンの場合、DSFの「ファストクローン」が完了すると、 (re-direct on writeを使って)各クローンに対する書き込み可能なスナップショットが生成されます。 各クローンは自身のブロックマップを持っているので、チェーンの深さを気にする必要はありません。 VAAIを使用するか否かは、以下の要素で決まります。
VMware Viewの場合、次の方針になります:
VAAIの動作は、Activity Traceページの「NFS Adapter」を使って確認できます。
本セクションでは、CVMの「障害」がどのように処理されるかについて説明します(コンポーネントの障害対応については、後日説明を追加します)。 ここではCVMの「障害」とは、ユーザーによるCVMの停止、CVMのローリングアップグレードなど、CVMを停止させる全てのイベントを含みます。 DSFには自動パス切りかえ(autopathing)と呼ばれる機能があり、ローカルCVMが利用不可になった場合、I/Oはクラスタ上の異なるCVMによって透過的に処理されます。 ハイパーバイザーとCVMは、専用のvSwitch(詳細は前述参照)上のプライベートの192.168.5.0ネットワークを使って通信します。 つまり、全てのストレージI/Oは、CVMの内部IPアドレス(192.168.5.2)を使って行われるということです。 CVMの外部IPアドレスは、リモートレプリケーションやCVMの通信に使用されます。
以下にこの状態を図示しました:
ローカルCVMで障害が発生した場合、それまでローカルCVMにホストされていたローカルの192.168.5.2アドレスは使用不可能になります。DSFは自動的にこの障害を検知し、10GbE経由でI/Oをクラスタ内の異なるCVMにリダイレクトします。この経路変更は、そのホストで稼動するハイパーバイザーやVMに対して透過的に行われます。つまり、CVMが停止しても、VMは引き続きDSFにI/Oが可能だということです。ローカルCVMが復旧して利用可能になると、経路は透過的に元にもどされ、トラフィックはローカルCVMから提供されるようになります。
以下は、CVM障害時にどういった動きをするか図示したものです:
基本的な仮想マシン管理操作は、ハイパーバイザーの管理インターフェイスを使用せずに、Prismから直接実行できます。 NutanixノードをvCenterインスタンスに追加し、vCenterをNutanixクラスタに登録(Settings → vCenter Registration)すると、Prismからダイレクトに次の操作が実行できるようになります:
説明: CLIとカスタム オフライン バンドルを使用した、ESXiホストの自動アップグレードを実行
cluster --md5sum=bundle_checksum --bundle=/path/to/<offline_bundle> host_upgrade
例:
cluster --md5sum=bff0b5558ad226ad395f6a4dc2b28597 --bundle=/tmp/VMware-ESXi-5.5.0-1331820-depot.zip host_upgrade
説明: 各ESXiホストサービスを順次再起動
for i in `hostips`;do ssh root@$i "services.sh restart";done
説明: ESXiホストの「Up」状態にあるNICを表示
for i in `hostips`;do echo $i && ssh root@$i esxcfg-nics -l | grep Up;done
説明: ESXiホストの10GbE NICとそのステータスを表示
for i in `hostips`;do echo $i && ssh root@$i esxcfg-nics -l | grep ixgbe;done
説明: ESXiホストのアクティブ、スタンドバイ、未使用状態にあるアダプターを表示
for i in `hostips`;do echo $i && ssh root@$i "esxcli network vswitch standard policy failover get --vswitch-name vSwitch0";done
説明: ESXiホストのルーティングテーブルを表示
for i in `hostips`;do ssh root@$i 'esxcfg-route -l';done
説明: データストアでVAAIが有効化されているか、サポートされているかを確認
vmkfstools -Ph /vmfs/volumes/<Datastore Name>
説明: VIBのアクセプタンスレベルをCommunitySupportedに設定し、サードパーティのVIBをインストール可能にする
esxcli software acceptance set --level CommunitySupported
説明: 署名確認なしでVIBをインストール
esxcli software vib install --viburl=/<VIB directory>/<VIB name> --no-sig-check
# または
esxcli software vib install --depoturl=/<VIB directory>/<VIB name> --no-sig-check
説明: ESXi ramdiskの空きスペースを確認
for i in `hostips`;do echo $i; ssh root@$i 'vdf -h';done
説明: 各ESXiホストのpynfsログをクリア
for i in `hostips`;do echo $i; ssh root@$i '> /pynfs/pynfs.log';done
Nutanix Hyper-Vクラスタが生成されると、Hyper-Vホストは、指定されたWindows Active Directoryドメインに自動的に参加する形になります。 これらのホストは、VM HAのためフェイルオーバークラスタに組み入れられます。 以上が完了すると、それぞれのHyper-VホストとフェイルオーバークラスタにADオブジェクトが作られます。
Hyper-Vを導入した場合、コントローラーVM (CVM) は、VMとして稼動しディスクはディスクパススルーを使用して提供されます。
以下の最大構成と拡張制限が適用されます:
注意: Hyper-V 2012 R2現在
各Hyper-Vホストには、内部限定の仮想スイッチがあり、Nutanix CVMとホスト間の通信に使用されます。外部やVMとの通信には、外部仮想スイッチ(デフォルト)または論理スイッチが使用されます。
内部スイッチ (InternalSwitch) は、CVMとHyper-Vホスト間のローカル通信のためのものです。ホストは、内部スイッチ (192.168.5.1) 上に仮想イーサネットインターフェイス (vEth) を持ち、CVMは内部スイッチ (192.168.5.2) 上にvEthを持っています。これが基本的な通信パスとなります。
外部vSwitchは、標準的な仮想スイッチまたは論理スイッチでかまいません。外部vSwitchは、Hyper-VホストとCVMに加え、ホスト上のVMに使用される論理およびVMネットワークのためのインターフェイスをホストします。外部vEthインターフェイスはホスト管理、ライブマイグレーションなどに用いられます。外部CVMインターフェイスは、他のNutanix CVMとの通信に使用されます。トランク上でVLANが有効になっていれば、論理およびVMネットワークはいくつでも作成することができます。
以下は、仮想スイッチアーキテクチャーの概念的な構造を図示したものです:
デュアルToRスイッチを使用し、スイッチHAのために両スイッチをクロスしたアップリンク構成をとることを推奨します。システムは、デフォルトで特別な構成を必要としないスイッチ非依存モードでLBFOチームを形成します。
Nutanixプラットフォームは、Microsoft Offloaded Data Transfers(ODX)をサポートし、ハイパーバイザーのタスクをアレイにオフロードすることができます。 ハイパーバイザーが「仲介役」を果たす必要がなくなるため、より効率的になります。 現在Nutanixは、フルコピー(full copy)やゼロイング(zeroing)とSMBのためのプリミティブをサポートしています。 しかし、「ファストファイル (fast file)」クローン処理(書き込み可能なスナップショットを使用)が可能なVAAIとは異なり、ODXにはフルコピーを行うための同等なプリミティブが存在しません。 このため、現在nCLI、RESTまたはPowerShellコマンドレットから起動できるDSFクローン機能を利用する方がより効果的です。 現在のところ、ODXは以下の処理に使用されます。:
SCVMMライブラリ(DSF SMBシェア)からテンプレート導入 - 注意: シェアは、ショートネーム(つまりFQDNではない)を使用して、SCVMMクラスタに追加する必要があります。 これを簡単に行うには、クラスタのhostsファイル(つまり10.10.10.10 nutanix-130)にエントリーを追加します。
ODXは以下の処理には使用できません:
ODXの稼動状態は、Activity Traceページの「NFS Adapter」を使って確認できます(SMB経由で実行されますが、NFSです)。 vDiskのコピー状態は「NfsWorkerVaaiCopyDataOp」、ディスクのゼロイング(zeroing)状態は「NfsWorkerVaaiWriteZerosOp」で表示されます。
近日公開!
説明: 特定のまたは複数のリモートホストで PowerShellを実行
$targetServers = "Host1","Host2","Etc"
Invoke-Command -ComputerName $targetServers {
<COMMAND or SCRIPT BLOCK>
}
説明: 指定したホストで使用可能なVMQオフロードの数を表示
gwmi -Namespace "root\virtualization\v2" -Class Msvm_VirtualEthernetSwitch | select elementname, MaxVMQOffloads
説明: 特定のVMに対するVMQを無効化
$vmPrefix = "myVMs"
Get-VM | Where {$_.Name -match $vmPrefix} | Get-VMNetworkAdapter | Set-VMNetworkAdapter -VmqWeight 0
説明: 特定のVMに対するVMQを有効化
$vmPrefix = "myVMs"
Get-VM | Where {$_.Name -match $vmPrefix} | Get-VMNetworkAdapter | Set-VMNetworkAdapter -VmqWeight 1
説明: 特定のプリフィックスに一致するVMを起動
$vmPrefix = "myVMs"
Get-VM | Where {$_.Name -match $vmPrefix -and $_.StatusString -eq "Stopped"} | Start-VM
特定のプリフィックスに一致するVMをシャットダウン
$vmPrefix = "myVMs"
Get-VM | Where {$_.Name -match $vmPrefix -and $_.StatusString -eq "Running"}} | Shutdown-VM -RunAsynchronously
特定のプリフィックスに一致するVMを停止
$vmPrefix = "myVMs"
Get-VM | Where {$_.Name -match $vmPrefix} | Stop-VM
説明: Hyper-VホストRSS (Receive Side Scaling) の設定の確認
Get-NetAdapterRss
説明: WinshとWinRMのコネクティビティおよびステータスを、サンプルクエリを発行して確認。コンピューターシステムオブジェクトを返さない場合はエラーと判断。
allssh 'winsh "get-wmiobject win32_computersystem"'
近日公開!
近日公開!
パブリッククラウドを活用するということは、アプリケーションとデータをオンデマンドで数分以内に拡張できるということを意味します。 Nutanix Cloud Clusters(NC2)では、単一の管理プレーンを使用してNutanixによるプライベートクラウドとパブリッククラウドのリソースの両方が同じPrismインターフェイスで管理できるようになり、シームレスな体験になります。
本書では、アーキテクチャー、ネットワーキング、ストレージ、そしてNC2の稼働についてのその他の側面について、技術的な詳細について解説します。
NC2は、現在はAWS上でサポートされています。
NC2は、現在Azureでのカスタマーとのプライベートプレビューを実施しています。
Nutanix Cloud Clusters (NC2) on AWSは、ターゲットクラウド環境のベアメタル リソースで実行される、オンデマンドのクラスタを提供します。 これにより、ご存知のNutanixプラットフォームのシンプルさで、真のオンデマンドな収容能力を実現できます。 プロビジョニングされたクラスタは従来のAHVクラスタのように見えますが、クラウド プロバイダーのデータセンターで実行されています。
このソリューションは以下の構成に適用できます(このリストはおそらく不完全であり、完全なサポートされている構成のリストについては、ドキュメントを参照してください):
このセクションでの用語は、以下のように定義されています。
Nutanix Cloud Clusters Portalは、概観的にいうとNC2 on AWSをプロビジョニングし、AWSと対話するためのメイン インターフェイスです。
プロビジョニング手順は、おおまかに下記のステップとして要約できます。
以下は、NC2 on AWSの相互作用における概要を示します:
以下は、NC2 Portalによる入力と、作成されるリソースの概要を示します:
以下は、AWSでのノードの概要を示します:
ホストがベアメタルであるため、通常のオンプレミス展開と同様に、ストレージとネットワークのリソースを完全に制御できます。 CVMおよびAHVホストのブート領域では、EBSボリュームが使用されます。
注: EBSなどの特定のリソースとのやりとりは、AHVホストでNVMeコントローラーとして認識されるAWS Nitroカードを介して実行されます。
Nutanixは、AWSのアベイラビリティ ゾーン内にノードをデプロイする際に、パーティション配置戦略をとります。 1つのNutanixクラスタが同じリージョン内の異なるアベイラビリティ ゾーンにまたがることはできませんが、異なるゾーンまたはリージョン内にある複数のNutanixクラスタで相互にレプリケーションを行うことはできます。 Nutanixは、最大で7つのパーティションを使用して、AWSベアメタル ノードを異なるAWSラックに配置し、新規ホストをパーティション全体にストライプ化します。
NC2 on AWSは、クラスタ内での異種ノード タイプの組み合わせをサポートしています。 1つのノード タイプのクラスタを展開し、そこに異種ノードを追加してクラスタの容量を拡張できます。 この機能は、元のノードタイプがリージョンで不足した場合に、オンデマンドでクラスタを拡張する柔軟性を提供できるようにします。 ストレージ ソリューションの適切なサイズを検討している場合にも、異種ノードのサポートにより、より多くのインスタンス オプションから選択できます。
クラスタでインスタンス タイプを組み合わせる場合は、常に少なくとも3ノードをベース クラスタをデプロイした元のタイプで維持しておく必要があります。 元のタイプが3ノード以上残っていて、クラスタ サイズが28ノードの制限内であれば、ベース クラスタは任意の数の異種ノードで拡張または縮小できます。
次の表と図はどちらも、クラスタの元のインスタンス タイプを「Type A」、互換性のある異種タイプを「Type B」としています。
表:サポートされているインスタンス タイプの組み合わせ
Type A | Type B |
---|---|
i3.metal | i3en.metal |
i3en.metal | i3.metal |
z1d.metal | m5d.metal |
m5d.metal | z1d.metal |
Nutanixクラスタを構成すると、パーティション グループはNutanixのラック アウェアネス機能にマップされます。 AOSストレージは、クラスタ内の異なるラックにデータ レプリカを書き込み、ラックの障害または計画的なダウンタイムの際に、レプリケーション ファクタ2とレプリケーション ファクタ3の両方のシナリオにおいてデータが利用可能のままであることを保障します。
Nutanix Cloud Clusters on AWSのストレージは、次の2つの領域に分類できます:
コア ストレージは、Nutanixクラスタで期待するものとまったく同じであり、「ローカル」ストレージデバイスをCVMに接続して、Stargateで活用します。
「ローカル」ストレージではAWSインスタンス ストアが使われており、 停電やノード障害が発生した場合の完全な復元力がなく、追加の考慮が必要になります。
たとえば、停電またはノード障害が発生した場合、ローカルのNutanixクラスタでは、ストレージはローカル デバイスに永続化されており、ノードや電源がオンラインに戻ると復旧します。 AWSインスタンス ストアの場合、このケースには当てはまりません。
ほとんどの場合、AZ全体が電源を失うまたはダウンするという可能性は低いですが、 センシティブなワークロードの場合は、次のことをお勧めします:
NC2 on AWSのユニークな機能の1つは、クラスタを「ハイバネート」状態にして、EC2コンピューティング インスタンスを停止している間もデータを永続化できることです。 これは、コンピューティング リソースが不要で、支払いを継続したくないが、データを永続化して後で復元できるようにしたいという場合に役立ちます。
クラスタがハイバネート状態になると、データはクラスタからS3にバックアップされます。 データがバックアップされると、EC2インスタンスが終了されます。 再開または復元の際には、新しいEC2インスタンスがプロビジョニングされ、データがS3からクラスタに読み込まれます。
ネットワークは、いくつかの中核的な領域に分類できます:
独自のオーバーレイ ネットワークを運用する代わりに、AWSサブネットでネイティブに運用することを決定しました。 これにより、プラットフォームで起動されているVMがパフォーマンス低下なくAWSサービスとネイティブに通信できるようになります。
NC2 on AWSは、AWS VPCにプロビジョニングされます。以下に、AWS VPCの概要を示します:
AWSはデフォルトのVPCやサブネットなどを作成します。各リージョンには172.31.0.0/16のIPスキームを使用します。
企業のIPスキームに適合するサブネット、NATやインターネット ゲートウェイなどが関連付けられた、新規VPCを作成することを推奨します。 このことは、VPC(VPCピアリング)や既存のWANにネットワークを拡張する計画がある場合に重要です。 これはWAN上の他のサイトと同じように扱う必要があります。
AWSのベアメタルで実行されているホストは従来どおりのAHVホストであるため、同様にOVSベースのネットワーク スタックを利用します。
以下は、AWSでのAHVホストにおけるOVSスタックの概要を示しています:
OVSスタックは、L3アップリンクブリッジが追加されていることを除いて、従来のAHVホストと同様です。
UVM(ゲストVM)のネットワークでは、VPCサブネットが使用されます。 UVMのネットワークは、クラスタの作成プロセス中、または下記の手順で作成できます:
AWSのVPCダッシュボードで、「subnets」をクリックし、「Create Subnet」をクリックして、ネットワークの詳細を入力します:
注:CIDRブロックは、VPCのCIDR範囲のサブセットである必要があります。
サブネットはVPCからルート テーブルを継承します:
この場合、ピアVPC内部のトラフィックはVPCピアリング接続を経由し、外部トラフィックはインターネット ゲートウェイを経由します。
完了すると、ネットワークがPrismで使用できるようになります。
ほとんどの場合の展開では、AWS内部のみでなく、外部の世界(他のVPC、インターネットまたはWAN)と通信する必要があります。
VPCを接続する場合(同じ、または異なるリージョン)、VPC間でトンネリングできるVPCピアリングを使用できます。 注:WAN IPスキームのベスト プラクティスに従っており、VPCとサブネットのCIDR範囲重複がないことを確認する必要があります。
以下は、eu-west-1およびeu-west-2リージョンの、VPC間のVPCピアリング接続を示します:
各VPCのルートテーブルは、ピアリング接続を経由して他のVPCに向かうトラフィックをルーティングします(通信が双方向の場合、これは両側に存在する必要があります)。
オンプレミスまたはWANへのネットワーク拡張では、VPNゲートウェイ(トンネル)またはAWS Direct Connectが利用できます。
リソースがフル コントロール セキュリティ外であるクラウドで実行されている場合、データ暗号化とコンプライアンスは非常に重要な考慮事項です。
推奨事項は以下のように特徴付けられます:
このセクションでは、NC2 on AWSを構成して活用する方法について説明します。
おおまかなプロセスは、以下の手順となります:
まだ続く!
Nutanix Cloud Clusters (NC2) on Azureは、ターゲットクラウド環境のベアメタル リソースで実行される、オンデマンドのクラスタを提供します。 これにより、ご存知のNutanixプラットフォームのシンプルさで、真のオンデマンドな収容能力を実現できます。 プロビジョニングされたクラスタは従来のAHVクラスタのように見えますが、クラウドプロバイダーのデータセンターで実行されています。
このソリューションは以下の構成に適用できます(このリストはおそらく不完全であり、完全なサポートされている構成のリストについては、ドキュメントを参照してください):
このセクションでの用語は、以下のように定義されています:
Nutanix Cloud Clusters(NC2)Portalは、概観的にいうとNC2 on Azureをプロビジョニングし、Azureと対話するためのメイン インターフェイスです。
プロビジョニング手順は、おおまかに下記のステップとして要約できます:
以下に、NC2 on Azureの相互作用の概要を示します:
以下は、NC2 Portalによる入力と作成されるリソースの概要を示します:
ホストがベアメタルであるため、通常のオンプレミス展開と同様に、ストレージとネットワークのリソースを完全に制御できます。 ビルディング ブロックとして、Azure Nutanix Ready Nodeを使用しています。 AWSとは異なり、Azureベースのノードは、CVMまたはAHVのための追加サービスを消費しません。
Nutanix Clusters on Azureは、デフォルトで7つのパーティションを持つ、パーティション配置ポリシーを使用します。 ホストは、Nutanixのラックに対応するパーティションに、ストライプ状に配置されています。 これにより、1~2箇所の「ラック」全体障害が発生しても、可用性を維持できます。
以下に、パーティションによる配置戦略および、ホストのストライピングの概要を示します:
コア ストレージは、Nutanixクラスタで期待するものとまったく同じであり、「ローカル」ストレージデバイスをCVMに接続して、Stargateで活用します。
「ローカル」ストレージとしてローカルフラッシュデバイスがバッキングされているため、停電が発生した場合でも完全に回復力があります。
NC2は、AzureのFlow Virtual Networkingを利用してオーバーレイネットワークを作成することで、Nutanix管理者による管理作業を容易にし、クラウドベンダー間のネットワークの制約を軽減します。 Flow Virtual Networkingは、オーバーレイ仮想ネットワークを作成することにより、Azureのネイティブネットワークを抽象化するために使用されます。 これによりAzureの基盤となるネットワークが抽象化され、それと同時に、ネットワークの下地(およびそれに関連する機能や操作性)をカスタマーの持つオンプレミスのNutanix展開と整合させることができます。 使い慣れたPrism Centralのインターフェースで、Nutanix内に新しい仮想ネットワーク(仮想プライベートクラウドまたはVPCと呼ばれる)を作成し、RFC 1918の(プライベート)アドレス空間に含まれる任意のアドレス範囲からのサブネットによってDHCPを定義し、NAT、ルーティング、およびセキュリティポリシーを設定します。
Flow Virtual Networkingは、抽象化レイヤーを提供することによりクラウドの制約をマスキングまたは軽減できます。 例として、AzureではVNetごとに1つの委任されたサブネットのみが許可されます。 サブネットの委任により、仮想ネットワークに導入する必要があるAzure PaaSサービスに、特定のサブネットを指定できます。 NC2には、Microsoft.BareMetal/AzureHostedServiceに委任された管理サブネットが必要です。 サブネットがBareMetalサービスに委任されると、NC2 Portalではそのサブネットを使用してNutanixクラスタをデプロイできるようになります。 AzureHostedServiceは、NC2 Portalがベアメタルノードにデプロイとネットワーク構成をするために使用するものです。
ネイティブのユーザー仮想マシンのネットワーキングに使用される各サブネットも、同じサービスに委任する必要があります。 VNetが持てるのは1つの委任されたサブネットのみなので、通信を可能にするためにはVNetを相互にピアリングする必要があり、ネットワーク構成は手に負えなくなります。 Flow Virtual Networkingを使用することで、NC2とAzureで実行されているワークロードが通信できるようにするために必要なVNetの量を大幅に減らすことができます。 Flow Virtual Networkingでは、Azure VNetを1つ消費するだけで500を超えるサブネットを作成できます。
企業のIPスキームに適合するサブネット、NATやインターネット ゲートウェイなどが関連付けられた、新規VNetを作成することを推奨します。 このことは、VNet(VNetピアリング)や既存のWANにネットワークを拡張する計画がある場合に重要です。 これはWAN上の他のサイトと同じように扱います。
Prism Central(PC)は、展開後のNutanixクラスタにデプロイされます。 Prism Centralには、Flow Virtual Networkingのコントロールプレーンが含まれています。 PCのサブネットはMicrosoft.BareMetal/AzureHostedServiceに委任されるため、ネイティブのAzureネットワークを使用してPCのIPを配布できます。 PCがデプロイされると、Flow GatewayがPCと同じサブネットにデプロイされます。 Flow Gatewayを使用すると、Flow VPCを使用するユーザー仮想マシンがネイティブAzureサービスと通信できるようになり、仮想マシンが次のようにネイティブAzure仮想マシンと同等になります:
Flow Gateway VMは、クラスタからNorth-Southに向かう、すべての仮想マシンのトラフィックを担当します。 展開中に、必要な帯域幅に基づいてFlow Gateway VMのサイズを選択できます。 他のCVMやオンプレミスとの間でのCVMレプリケーションはFlow Gateway VMを介して流れないため、それらのトラフィックはサイジングする必要がないと理解することが重要です。
ネットワークアドレス変換(NAT): AHV/CVM/PC/Azureリソースと通信するユーザー仮想マシンは、Flow Gateway VMの外部ネットワークカードを経由します。 提供されるNATは、ネイティブのAzureアドレスを使用して、すべてのリソースへのルーティングを保証します。 NATの使用が望ましくない場合は、Azureのユーザー定義のルートを使用してAzureリソースと直接通信できます。 これにより、新規インストールでAzureとすぐに通信できるようになりますが、カスタマーにはより高度な構成のオプションも提供されます。
Azureのベアメタルで実行されているホストは従来どおりのAHVホストであるため、同様にOVSベースのネットワーク スタックを利用します。
以下は、AzureでのAHVホストにおけるOVSスタックの概要を示しています:
NutanixのOpenv Switchの実装は、オンプレミスでの実装と非常によく似ています。 上の図は、ベアメタルに展開されるAHVの内部アーキテクチャを示しています。 br0ブリッジは、トラフィックをbr0.cluster(AHV/CVMのIP)とbr0.uvms(ユーザー仮想マシンのIP)の間で分割します。
br0.clusterを介したAHV/CVMトラフィックの場合、データパケットを変更せずに、br0.azureブリッジへの単純なパススルーになります。 トップオブラックのスイッチングは、br0.clusterトラフィックへのセキュリティを提供します。 ユーザー仮想マシンのIPトラフィックがbr0.uvmsを介して流れる場合、VLAN-ID変換およびbr0.azureへのパススルートラフィック用にOVSルールがインストールされます。
br0.azureは、OVSボンド(bond)のbr0.azure-upを持ち、ベアメタルに接続された物理NICとのボンドインターフェイスを形成します。 したがってbr0.azureは、ボンドインターフェイスをbr0.uvmsおよびbr0.clusterから隠します。
作成するサブネットはビルトインのIPAMを持ち、ネットワークをオンプレミスからAzureに拡張するオプションがあります。 外部アプリケーションがサブネット内のユーザー仮想マシンと直接通信する必要がある場合には、AzureのIPプールからフローティングIPを割り当てるオプションもあり、Flow Gatewayの外部ネットワークからのものです。
展開を成功させるには、NC2は、NATゲートウェイまたはアウトバウンドアクセスのオンプレミスVPNを使用して、NC2 Portalへのアウトバウンドアクセスを必要とします。 Nutanixクラスタは、VPNからのみアクセスできるプライベートサブネットに配置できるため、環境への露出は制限されます。
ほとんどの場合の展開では、Azure内部のみでなく、外部の世界(他のVNet、インターネットまたはWAN)と通信する必要があります。
VNetを接続する場合(同じ、または異なるリージョン)、VNet間でトンネリングできるVNetピアリングを使用できます。 注:WAN IPスキームのベスト プラクティスに従っており、VNetとサブネットのCIDR範囲重複がないことを確認する必要があります。
オンプレミスまたはWANへのネットワーク拡張では、VNetゲートウェイ(トンネル)またはExpress Routeが利用できます。
このセクションでは、NC2 on Azureを構成して活用する方法について説明します。
おおまかなプロセスは、以下の手順となります:
More to come!
Nutanix Volumesは、バックエンドにあるDSFストレージを、iSCSI経由で外部ユーザー(ゲストOS、物理ホスト、コンテナなど)に提供する機能です。
本機能によって、オペレーティングシステムは、DSFにアクセスしてストレージ機能を利用できるようになります。この導入シナリオにおいて該当OSは、ハイパーバイザーを経由することなく、Nutanixに直接アクセスすることになります。
Volumesの主要なユースケース:
本ソリューションは、iSCSI仕様に準拠しており、QAによって以下のオペレーティングシステムが検証済みとなっています。
Volumesは、以下のエンティティで構成されています:
注意: バックエンドでは、VGのディスクは単にDSF上のvDiskとなります。
設定を行う前に、セントラルディスカバリ / ログインポータルとして機能するデータサービスIPを設定する必要があります。
設定は「Cluster Details(クラスタ詳細)」ページから行います。(歯車アイコン -> Cluster Details)
NCLI / API経由でも設定が可能です:
ncli cluster edit-params external-data-services-ip-address=<DATA SERVICES IP ADDRESS>
Volumesを使用するためには、まずiSCSIのターゲットとなる「Volume Group(ボリュームグループ)」を作成する必要があります
「Storage(ストレージ)」ページの右側にある「+ Volume Group(ボリュームグループの追加)」をクリックします:
VG詳細を設定するメニューが表示されます:
次に「+ Add new disk(ディスクの追加)」をクリックして、ターゲット(LUNとして見える)にディスクを追加します。
メニューが表示されたら、ターゲットとなるコンテナとディスクサイズを選択します:
「Add(追加)」をクリックし、必要に応じて繰り返しディスクを追加します。
詳細を設定し、ディスクを追加したら、ボリュームグループをVMまたはイニシエータIQNにアタッチします。これによって、VMがiSCSIターゲットにアクセスできるようになります(未知のイニシエータからのリクエストは拒否されます):
「Save(保存)」をクリックします。これでボリュームグループの設定は完了です!
ACLI / API経由でも、同様の対応が可能です:
VGの作成
vg.create <VG Name>
VGにディスクを追加
vg.disk_create <VG Name> container=<CTR Name> create_size=<Disk size, e.g. 500G>
イニシエータIQNをVGにアタッチ
vg.attach_external <VG Name> <Initiator IQN>
前述の通り、データサービスIPはディスカバリに使用されます。 これによって、個々のCVM IPアドレスを知る必要なく、1つのアドレスのみを使用できます。
データサービスIPは、現状のiSCSIリーダーに割り当てられます。 障害が発生すると、新しいiSCSIリーダーが選択され、データサービスIPが割り当てられます。 これにより、ディスカバリポータルは常時使用可能な状態になります。
iSCSIイニシエータは、データサービスIPによりiSCSIターゲットポータルとして設定されます。ログインリクエストが発生すると、プラットフォームはiSCSIログインを正常なStargateにリダイレクトします。
アクティブの(アフィニティがある) Stargateに障害が発生すると、イニシエータはデータサービスIPデータサービスIPへのiSCSIログインをリトライし、別の健全なStargateにリダイレクトされます。
アフィニティがあるStargateが復旧して安定すると、現状アクティブとなっているStargateはI/Oを休止し、アクティブなiSCSIセッションを切断します。イニシエータが再度iSCSIログインを試みると、データサービスIPはそれをアフィニティがあるStargateにリダイレクトします。
DSFに対するメカニズムと同様に、VolumesにZookeeperを使用して、Stargateのヘルス状態を監視します。
フェイルバックのデフォルト間隔は120秒となっています。つまり、元々接続していたStargateが2分間以上健全な状態を保てば、セッションを休止して切断するということです。他のログインも、接続中のStargateに戻されます。
この仕組みによって、パスのHAのためのクライアント側マルチパス(MPIO)設定はもはや必要ありません。 ターゲットに接続する場合、MPIOを有効化するために「Enable multi-path(マルチパスを有効化)」にチェックを入れる必要はありません。
iSCSIプロトコルに準拠するためには、イニシエータとターゲット間で1つターゲットに1つのiSCSIセッション(TCP接続)となる必要があります。つまり、Stargateとターゲットが、1:1の関係になるということです。
4.7では、1つのアタッチイニシエータに対して32(デフォルト)の仮想ターゲットが自動生成され、ボリュームグループ (VG) に追加された各ディスクデバイスに割り当てられます。これにより、1つのディスクデバイスに対して、1つのiSCSIターゲットが提供されます。以前は、複数のVGをそれぞれのディスクに対して作成することで実装を行っていました。
ACLIやAPIでVGの詳細を見てみると、各アタッチメントに対して、32の仮想ターゲットが作成されていることが分かります:
attachment_list { external_initiator_name: "iqn.1991-05.com.microsoft:desktop-foo" target_params { num_virtual_targets: 32 } }
例として、3つのディスクデバイスを追加したVGを作成しました。クライアントでディスカバリを実行すると、それぞれのディスクデバイスに対する個々のターゲットが確認できます。(サフィックスは -tgt[int])
これでディスクデバイスは、自身のiSCSIセッションを持つことになり、これらのセッションは複数のStargateでホストすることが可能であるため、拡張性やパフォーマンスの向上につながります:
iSCSIセッションが確立されている間(iSCSIログイン)、各ターゲットに対するロードバランシングが発生します。
以下のコマンドを使って、仮想ターゲットをホストしている、有効なStargateを確認することができます(ホストしているStargateのCVM IPを表示):
Windows
Get-NetTCPConnection -State Established -RemotePort 3205
Linux
iscsiadm -m session -P 1
AOS 4.7では、簡単なハッシュ関数を使用してクラスタノード全体にターゲットを分散しています。 AOS 5.0では、これがDynamic Schedulerに統合され、必要に応じて再バランスを取るようになっています。 また、どのノードを使用するかについては、該当ノードが正常である限り自由に設定を行うことができます。
Volumesでは、SCSI T10仕様にあるSCSI UNMAP (TRIM) コマンドをサポートしています。 このコマンドを使用することで、削除済みブロックのスペース再利用が可能となります。
Nutanix Filesによって、Nutanixプラットフォームを高可用性ファイルサーバーとして利用することができます。 ユーザーは、単一のネームスペースにホームディレクトリやファイルをストアできます。
本ソリューションでは、以下の構成をサポートしています(一部のみを掲載しています。完全なリストについてはドキュメントをご覧ください):
本機能は、いくつかのハイレベルな要素から構成されています:
下図は、構成要素の連関についての概要を示したものです:
Nutanix Filesでは、Nutanixプラットフォームと同じ分散メソドロジーを踏襲することで、可用性と拡張性を保証しています。ファイルサーバーには、少なくても3つのFSVMが設定されます。
以下にコンポーネントの詳細を示します:
FSVMは、論理的なファイルサーバー インスタンスとして統合され、Filesクラスタと呼ばれることもあります。 ひとつのNutanixクラスタには、複数のFilesクラスタを作成できます。 FSVMは、設定プロセスの途中で透過的にデプロイされます。
下図は、AOSプラットフォームにおけるFSVMの詳細を示したものです:
Nutanix Files機能は、Microsoft Active Directory(AD)およびDNSと完全に連携を取ることができます。 このため、ADに関する全てのセキュアな認証と権限管理機能の活用が可能となります。 共有許可、ユーザーやグループの管理については、従来のWindows MMCを使用して実施されます。
インストレーションプロセスの途中で、以下のAD / DNSオブジェクトが生成されます:
ファイルサービスを導入し、ADおよびDNSオブジェクトを生成するためには、ドメイン管理者または同等の権限を持ったユーザーアカウントを使用する必要があります。
各FSVMは、Volumes APIを使って、ゲスト内からのiSCSI経由でデータ ストレージにアクセスします。 これにより、FSVMに障害が発生した場合でも、iSCSIターゲットへの接続が可能となります。
以下にFSVMストレージの概要を示します:
CVM が使用できなくなった場合 (アクティブ パスのダウンなど)、iSCSIリダイレクションを使用してターゲットを別のCVMにフェイルオーバーしてI/O処理を引き継ぎます。
ローカルCVMが復旧して正常稼動すると、こちらがアクティブパスであると認識され、ローカルI/Oを提供するようになります。
通常の運用環境では、各FSVMのパッシブ接続されたデータスストレージとの通信は、それぞれのVGとの通信によって実現されます。 それぞれのFSVMは、クライアントがDFS Referral(分散ファイルシステム紹介)プロセスの一部としてFSVMと通信するためのIPを持ちます。 DFS Referralプロセスが共有フォルダーをホストしている正しいIPに接続するため、クライアントが個別のFSVMのIPを認識する必要がありません。
FSVMに「障害」(メンテナンスや電源断など)が発生すると、該当FSVMのVGとIPは、他のFSVMに引き継がれて高可用性を維持します。
以下に、障害FSVMのIPとVMに関する引継ぎの流れを示します:
障害のあったFSVMが復旧し安定すると、再度IPとVGを取得してクライアントI/Oの処理を継続します。
Nutanix Objectsは、S3準拠のAPIを介して非常にスケーラブルで耐久性のあるオブジェクトサービスを提供します(S3の補足情報: LINK)。 Nutanix ObjectsがNutanixプラットフォーム上にデプロイされると、圧縮、消失訂正符号 (Erasure Coding)、レプリケーションなどのAOS機能を利用できます。 ObjectsはAOS 5.11で導入されました。
ソリューションは以下の構成に適用できます(以下のリストは一部です。全てを確認する際には、ドキュメントをご覧ください):
Nutanix Objectsは、Nutanix Microservices Platform(MSP)を活用して実行される最初のコア サービスの1つです。
Nutanix MSPは、Identity and Access Management(IAM)やロードバランシング(LB)といった、Objectsのコンポーネントに関連付けられたコンテナとプラットフォームサービスをデプロイするための共通フレームワークとサービスを提供します。
次のこのセクション全体で使用される主要な用語は、以下のように定義されています:
この図は、概念構造のマッピングを示します:
この機能は、いくつかの大まかな構成要素で構成されています:
この図は、Objectsのサービス アーキテクチャーの詳細を示します:
Objects固有のコンポーネントは、Nutanix Greenで強調されています。 オブジェクトには「上書き」の概念がないため、CRUD(Create/Replace/Update/Delete)ではなくCxxD(Create/x/x/Delete)です。 一般的なオブジェクトの「上書き」の方法は、新しいリビジョンを作成するか、新しいオブジェクトを作成してそのオブジェクトをポイントすることです。
Nutanix Objectsは、オープンソースコンポーネントを活用しつつ、有機的なイノベーションの連携により構築されています。 これにより当社の製品がより堅牢で効率的になり、お客様のビジネスに最適なソリューションを提供できると確信しています。
オープンソースライセンスの開示に関する詳細についてはこちらをご覧ください: LINK
オブジェクトは、リージョンと呼ばれる論理構造に格納されます。 リージョンは、vDisk上の固定長セグメントの領域です。
この図は、vDiskとリージョンの関係についての例を示します:
小さいオブジェクトは単一のリージョンのチャンク(リージョンID、オフセット、長さ)に収まる場合がありますが、大きいオブジェクトはリージョンをまたいでストライプ化されることがあります。 ラージオブジェクトが複数のリージョンにストライプ化されている場合、それらのリージョンを複数のvDiskでホストして、複数のStargateにて同時に利用できます。
この図は、オブジェクト、チャンク、リージョンの関係についての例を示します:
オブジェクトサービス機能は、Nutanixプラットフォームと同じ分散方式によって、可用性と拡張性を保証します。 Objectsのデプロイでは、最低3台のオブジェクトVMがデプロイされます。
本書では、Nutanix によって提供されるネットワークとネットワークセキュリティのサービスについて説明します
これらの製品を別の名前で聞いたことがあるかたのために、ここで少し各製品の歴史と概要を示します。
我々は、カテゴリとポリシーベースマイクロセグメンテーションのソリューションとしてNutanix Flowをリリースしました。 以前はFlowとして知られていた、ステートフル、分散、そしてマイクロセグメンテーションのファイアウォールは、現在はFlow Network Securityと呼ばれています。
オンプレミスとクラウド環境の両方に対して、セキュリティプランニング、脅威検出、コンプライアンス監査を提供するために、NutanixはSaaSベースで提供されるBeamをリリースしました。 Beamのセキュリティコンポーネントは、現在はSecurity Centralとして知られています。
重複するIPアドレスに対応する本当のマルチテナントネットワーキングや、セルフサービスによるネットワークプロビジョニングのためにNutanixFlow Networkingをリリースしましたが、現在ではFlow Virtual Networkingと呼ばれています。
Flow Network Securityは、分散かつステートフルなファイアウォールとして、AHVプラットフォームで稼動する仮想マシン間や外部のエンティティとのきめ細かなネットワーク監視とエンフォースメントを可能にします。
このソリューションは以下の構成に適用できます:
Flow Network Securityの設定については、Prism Centralでポリシーを定義し、仮想マシンにカテゴリを割り当てる形で行います。 Prism Centralは、接続されている多くのAHVクラスタのセキュリティーポリシーとカテゴリをひとつの場所で定義できます。 それぞれのAHVホストについては、分散適用するための要件によりOVSとOpenFlowを使用してルールを実装します。
Flow Network Securityには、いくつかの重要な構成要素があります:
カテゴリとは、ポリシーの適用対象となる仮想マシングループを定義するために使用される、シンプルなキー/バリューのペアです。 一般的なカテゴリは、環境、アプリケーションの種類、そしてアプリケーションの層です。 仮想マシンの識別に役立つように任意のキー/バリュータグをカテゴリとして使用できますが、アプリケーションセキュリティポリシーのためにはAppTypeやAppTierといったカテゴリが必要です。
例えば、商用環境のデータベースサービスを提供する仮想マシンには、以下のようにカテゴリが割り当てられる場合があります:
これらのカテゴリは、適用するルールやアクションを決定するためのセキュリティポリシーに利用できます。 カテゴリはFlow Network Securityだけでなく、保護ポリシー(Protection Policy)でも同じカテゴリが使用できます。
セキュリティポリシーは、定義済みのカテゴリ間で許可の内容を決定するためのルール定義です。
セキュリティポリシーには、以下に示すような幾つかのタイプが存在します:
以下は、Flow Network Securityを使った、サンプルアプリケーションにおけるトラフィックコントロールの例です:
ポリシーの状態(Policy State)は、ルールが一致した場合にどんなアクションを取るかを決定します。Flow Network Securityには、2種類のステートがあります:
Flow Network Securityのポリシーは、パケットがUVMを出て、他の仮想マシンに到達する前に適用されます。 これは、AHVホストのマイクロセグメンテーションブリッジ(br.microseg)で発生します。
ポリシーはカテゴリを基に構築されますが、ルールの適用は検出された仮想マシンのIPアドレスをもとに行われます。 Flow Network Securityの役割は、全ての仮想マシンに割り当てられているカテゴリとポリシーを評価し、保護された仮想マシンの稼働しているホスト(またはホスト群)のbr.microsegブリッジに正しいルールをプログラムすることです。 Nutanix AHV IPAMを使用している仮想マシンは、仮想マシンがパワーオンされた際に、NICがプロビジョニングされるとすぐにIPアドレスが分かりルールがプログラムされます。 Nutanix Acropolisのプロセスは、スタティックIPまたは外部のDHCPを利用する仮想マシンのIPアドレスを検出するために、DHCPとARPのメッセージをインターセプトします。 それらの仮想マシンは、仮想マシンのIPアドレスが分かるとすぐにルールが適用されます。
検疫、アプリケーション、そしてVDIポリシーのルール評価は、検出したIPv4のアドレスをベースにしています。
隔離ポリシーのルール評価は、検出したIPv4のアドレスと、仮想マシンのMACアドレスの両方をベースにしています。
評価の順序は、次の順序での最初のマッチに基づきます。
最初にマッチしたポリシでアクションが実行され、それ以降の処理はすべて停止します。 たとえば、トラフィックがMonitorモードになっている隔離ポリシーに出会った場合は、転送するアクションが行われ、許可および監視されたことがログ出力されます。 たとえ、このトラフィックをブロックするアプリケーションやVDIのポリシーが以降にあったとしても、それ以上のルールは評価されません。
さらに、仮想マシンは1つのAppTypeカテゴリのみに所属することができ、 AppTypeカテゴリは、単一のAppTypeのみが設定できるポリシーのターゲットグループに入れることができます。 つまり、仮想マシンは1つのAppTypeポリシーのターゲットグループにのみに所属することができます。 仮想マシンで受信/送信する全てのトラフィックは、この単一のAppTypeポリシーで定義する必要があります。 現在、仮想マシンが複数のアプリケーションポリシーの中心にあるというコンセプトではなく、したがって、アプリケーションポリシー間で競合や評価順序が発生することはありません。
Nutanix Security Centralは、マイクロセグメンテーションのセキュリティプランニング、脅威検出アラート、そして継続的なコンプライアンス監視を提供する、Software as a Service(SaaS)製品です。 複数の機械学習(ML)モデルと、Louvain法、ARIMA、ツリーベース、クラスタリングのようなアルゴリズムを使用し、Security Centralは500を超える監査チェックとセキュリティのベストプラクティスに基づいて、オンプレミスの展開へのセキュリティに関する洞察を提供します。
Security Central Portal(https://flow.nutanix.com/securitycentral)は、クラウドとオンプレミスインフラストラクチャーで一般的そしてリスクの高い構成間違いを調査するために、インベントリ(棚卸し)と構成アセスメントを提供します。 このインベントリとコンプライアンス追跡ツールを組み合わせることで、セキュリティポスチャ監視も提供されます。 Security Centralのユーザーは、システム定義されたSQLのようなカスタムクエリを使用することで、セキュリティの状態についてその瞬間の洞察を得ることもできます。
最後になりますが、オンプレミスのAHVクラスタから取り込んだネットワークフローの情報により、機械学習によるトラフィックパターン分析に基づくほぼリアルタイムでの脅威検出を提供します。
Security Centralは、セキュリティ監視と管理フレームワークを提供するために、いくつかの新しい構成を導入しています。
導入された2つの要素は次のとおりです:
Security CentralはFSC VMという新しいサービス仮想マシンを導入しており、これはオンプレミスのNutanixのためのセキュリティ監視を有効化するために必要です。 FSC VMはプロキシとして動作し、オンプレミスのクラスタからの情報を集約します。 それから、その情報を安全なネットワーク接続を介してSecurity Centralに送信します。
FSC VMは、環境と仮想マシン(メタデータ)についてのインベントリ情報を収集します。 Security Centralは、インストールされているソフトウェアパッケージやバージョンといった、仮想マシンが所有するデータの収集はしませんが、Qualysのようなパートナーのエージェントとのインテグレーションにより、利用可能なアラートを充実させられます。
インストールしたら、管理者はFSC VM UIに接続してネットワークログの収集を有効化します。 その後、FSC VMはPrism Centralに、そのPrism Centralインスタンスによって管理されるすべてのAHVクラスタでIPFIXエクスポーターを有効化するように指示します。
FSC VMはPrism Centralから、すべての登録されているクラスタと仮想マシンについてのクラスタインベントリ情報も収集します。 収集されるインベントリ情報には、仮想マシン名、接続されたネットワークの情報、構成情報、そしてPrism Centralが仮想マシンに割り当てられるカテゴリなどの項目が含まれます。 インベントリのポーリングは3時間ごとに繰り返され、SaaSポータルは変更の記録と分析を行えます。
インベントリとIPFIXログは、HTTPS/TLS接続を使用して安全にSecurity CentralのSaaS環境に送信されます。 IPFIXログを15分間隔で送信することで、FSC VMはバッチ単位の増分でデータを送信できるため、FSC VMに必要なストレージ容量が削減され、クラウドへのネットワークの制約が軽減されます。
管理者は必要に応じて、FSC VMを使用して、要求されたインベントリ更新を手動でクラウドにプッシュできます。
FSC VMは、Prism Central(PC)によって管理されるクラスタ数に関係なく、展開されたPCごとに必要です。 FSC VMは、Prism Centralへの内部通信と、FSC-SaaSポータルへのアウトバウンド通信を容易にします。 Security Centralは、コンポーネント間の通信で以下のTCPポートを使用します。
ファイアウォールで、次のポートが開放されていることを確認してください:
FSCのプラットフォームは、厳格なセキュリティ管理を受けています。 Flow Security Centralのコンプライアンス認定を参照してより詳細を知るためにNutanix Trustを訪れてください。
Flow Security Central VMを構成するための要件:
Flow Security Central VMの構成要件を確実に満たすためには、Security Central Guideを調べてください。
Security Centralへの正常なログインの後に表示される最初の画面は、メインダッシュボードです。 そのダッシュボードは、Security Centralによって監視および警告された多くの領域の概観を提供します。 より詳細な表示は、個々のウィジェットから起動できます。
セキュリティ監査を利用することで、オンプレミス展開のセキュリティに関する深い洞察が提供されます。 Security Centralは、環境に500を超えるすぐに利用可能な(out-of-the-boxの)自動化されたセキュリティ監査を実行し、監査の失敗については修正手順とともに報告します。
Security Centralの監査チェックは、次のカテゴリとNutanixのセキュリティベストプラクティスに準拠しています:
常に更新される組み込みの監査に加えて、Security Centralは、Common Query Language(CQL)を使用して監査とレポートをカスタマイズする機能を提供しています。 これにより、さまざまな属性についてクラウドインベントリでCQLクエリを実行し、特定のユースケースのための監査チェックを作成できます。
Nutanixの多くのカスタマーにとって、コンプライアンスは非常に重要です。 コンプライアンスを維持することで、会社の運用環境が従うべき管理基準が満たされていることを検証できます。
コンプライアンスのために環境を監視することは、困難で時間がかかる場合があります。 絶えず変化する要件、規制、環境を常に把握するには、継続的なコンプライアンス監視機能が必要です。 カスタマーには、これらのチェックを自動化することで、コンプライアンス違反への対処において、簡潔なビューと解決時間の短縮という利益があります。
Security Centralは、PCI-DSS、HIPAA、NISTなどの一般的な規制フレームワークと、Nutanix STIGポリシーを使用したNutanixセキュリティベストプラクティスの監査チェックを提供します。
コンプライアンスダッシュボードは、監視されている各フレームワークのコンプライアンススコアを提供します。 スコアの要素をさらに調査して、監視および監査されているフレームワークの要素、合格したチェックの数、および失敗したチェックの数を表示できます。 コンプライアンスビューには、失敗したチェック、チェックが関連付けられているフレームワークのセクション、検出された問題などの、チェックの詳細が表示されます。 コンプライアンスレポートとその詳細は、オフラインでの使用および共有するためにエクスポートすることもできます。
Security Centralは、ビジネス要件に基づいたカスタム監査とカスタムコンプライアンスポリシーを作成する拡張機能も提供します。
「問題をきちんと述べられれば、半分は解決したようなものだ」
- チャールズケタリング
脅威の状況は絶えず変化しているため、今日の環境ではセキュリティの監視とアラート発報が重要です。 ネットワーク、セキュリティコントロール、サーバー、エンドポイント、そしてユーザーアプリケーションで見つかった脅威と脆弱性を継続的に監視してアラート発報することで、全体的なセキュリティポスチャを強化し、問題が検出された際に解決時間を短縮するアラートへのプロアクティブなアプローチを可能にしています。
Security CentralにあるFindings and Alertsビューは、現在のセキュリティポスチャのビューを提供します。 このビューには、Security Centralによって監視されているNutanixクラスタで検出された構成の問題と観測された異常な動作が表示されます。 これらの調査結果は、選択した監査ポリシーに基づいています。 ユーザーにはこれらの問題の表示方法についてのカスタマイズ可能なオプションがあり、監査カテゴリ、リソース、役割、そしてビジネス要件ごとに調査結果を調整するための優れた柔軟性を提供します。
脅威検出のアラートは、Findings and Alertsビューに含まれています。 Security Centralは、NutanixのIPFIXネットワークログを分析して、監視対象のNutanixクラスタ内で発生する潜在的な脅威と異常な動作を検出してレポートします。 これらのアラートは、機械学習と観測されたデータポイントを使用してモデル化されます。
以下は、検出される潜在的な脅威と動作の一部と、異常の登録またはアラートをトリガーするために監視する必要のある最小日数またはデータポイントです:
アプリケーションのセキュリティ保護を計画する場合、効果的なセキュリティポリシーの作成に必要とされる、検出および情報収集する多くのコンポーネントがあります。 この情報を収集することは、非常に困難な場合があります。 多くの場合、アプリケーションの通信プロファイルを得るために、ファイアウォール、ネットワーク機器、アプリケーション、そしてオペレーティングシステムからログを収集する必要があります。 それらデータが収集および分析されたら、アプリケーションの所有者と相談して、観察された結果を、期待される動作と比較します。
Security CentralのMLベースのセキュリティプランニングは、アプリケーションのセキュリティポリシーの検出と計画に役立つ詳細な視覚化を提供します。 オンプレミスのNutanixクラスタ内のネットワークトラフィックフローを視覚化し、Security Centralがアプリケーションを分類して保護する方法についての推奨事項を作成します。
Security Planningセクションでは、アプリケーションと環境として、最大2レベルのグループ化を柔軟に利用できます。 この機能では、分析を特定のクラスタ、VLAN、仮想マシン、そしてカテゴリにドリルダウンできるため、アプリケーションの保護に集中することにおいて非常に役立ちます。 このグループ化により、観測またはフィルタリングされたすべてのネットワークトラフィックをダウンロードして、オフラインでの共有、検出、そして計画をさらに進めることができます。
備えられている機械学習機能を使用することで、Security Centralは観察されたネットワークフローに基づいて、カテゴリの推奨と仮想マシンへの割り当てを行うこともできます。 これは、新規のマイクロセグメンテーションまたはアプリケーションの展開で特に役立ちます。 アプリケーションの仮想マシンを分類することは、アプリケーションを保護するための重要なステップです。 さらに一歩進んで、Security Centralは、インバウンドおよびアウトバウンドのルール推奨を生成し、Nutanix AHVクラスタでのアプリケーションセキュリティポリシーをMonitorモードで作成することもできます。
Monitorモードのセキュリティポリシーを使用すると、ポリシーアクションを適用しなくても、セキュリティで保護されているアプリケーションの動作を監視できます。 Prism Centralを使用して、必要に応じてポリシーを適用する前にポリシーを編集できます。
セキュリティアーキテクチャーは、多くの場合で、多層防御の姿勢を構築するために複数ベンダーのソリューションで構成されています。 エンドポイントの脅威と脆弱性、チケットシステム、ログ管理、脅威とイベントの分析を監視するソリューションは、すべてセキュリティアーキテクチャーの重要なコンポーネントになる可能性があります。 これらの製品は非常に重要ですが、多くの場合にスタンドアロンであり、セキュリティインフラストラクチャの他のコンポーネントとの統合に制限があります。 統合は、セキュリティアーキテクチャーの構築でセキュリティソリューションをまとめるための鍵となります。 これは、脅威の認識、分析、脅威の修復についての効率化および時間短縮となります。
Security Centralは、Nutanix以外のアプリケーションをSecurity Centralと直接統合する機能を提供します。 これらの統合は、OSレベルの監視と保護から、エンタープライズのチケットシステムや分析エンジンまで、複数のソリューションをカバーしています。
いくつかのサポートされている統合を以下に示します:
Flow Virtual Networkingを使用すると、物理ネットワークから切り離され、完全に隔離された仮想ネットワークを作成できます。 重複するIPアドレスを持つマルチテナントネットワークプロビジョニング、セルフサービスでのネットワークプロビジョニング、IPアドレスの保持といったことが実行できます。
主なユースケース:
管理インターフェイス:
サポートされる環境:
アップグレード:
Flow Virtual Networkingは、完全なネットワーキングソリューションを提供するため、いくつかの新しい構造を導入しています。
VPC(Virtual Private Cloud)は、Flow Virtual Networkingの基本単位です。 それぞれのVPCは、VPC内の全サブネットと接続するための仮想ルータインスタンスを持つ、隔離されたネットワーク名前空間です。 これにより、ひとつのVPC内にあるIPアドレスを、他のVPCや物理ネットワークと重複させることができます。 VPCは同一のPrism Centralで管理されているクラスタに拡張することができます。 しかし、通常はVPCが単一のAHVクラスタ内、もしくは同一のアベイラビリティ ゾーン内のクラスタに存在するべきです。 詳細については、外部ネットワークにて説明します。
それぞれのVPCは1つ以上のサブネットを持つことができ、それらは全て同じVPC仮想ルータに接続されます。 内部では、VPCは、必要に応じてAHVホスト間のトラフィックをトンネリングするためにGeneveによるカプセル化を利用しています。 つまり、異なるホスト上の仮想マシンが通信するために、VPC内のサブネットは、作成したりトップオブラックスイッチに存在させたりする必要はありません。 VPCにある2つの異なるホスト上の2つの仮想マシンで相互通信する場合、パケットは最初のホストでGeneveでカプセル化され、別のホストに送信されるとカプセル化が解除されて宛先の仮想マシンに送信されます。
仮想マシンのNICを選択したときに、そのNICをオーバーレイサブネットまたは従来のVLANサブネットのどちらかに配置できます。 オーバーレイサブネットを選択した場合には、VPCも選択します。
それぞれの仮想マシンは、単一のVPCのみに配置できます。 仮想マシンは、VPCとVLANの両方に同時接続したり、異なる2つのVPCに同時接続したりすることはできません。
全てのVPCには1つの仮想ルータが含まれており、いくつかの種類のルートが存在します:
外部ネットワークは、VPC全体に対しての、0.0.0.0/0ネットワークプリフィックスのデフォルトの宛先である必要があります。 使用する外部ネットワークごとに、代替のネットワークプリフィックスルートを選択できます。 完全に隔離されたVPCにするために、デフォルトルートを選択しないことも選択できます。
直接接続されたルートは、VPC内のサブネットごとに作成されます。 Flow Virtual Networkingは、それぞれのサブネットの最初のIPアドレスを、そのサブネットのデフォルトゲートウェイとして割り当てます。 デフォルトゲートウェイとネットワークプリフィックスはサブネット構成によって決定され、直接変更することはできません。 同一VPCの同一ホスト上にあって、異なるサブネットにある2つの仮想マシン間のトラフィックは、ホスト内でローカルにルーティングされます。
VPN接続のようなリモート接続や外部ネットワークは、ネットワークプリフィックスのネクストホップの宛先として設定できます。
VPCルーティングテーブル内のそれぞれのネットワークプリフィックスは、一意である必要があります。 同じ宛先プリフィックスを持つ2つの異なるネクストホップ宛先は設定しないでください。
仮想ルータは、VPC内のトラフィックの制御ポイントとして動作します。 ここでは、シンプルなステートレスポリシーを適用でき、ルータを通過する全てのトラフィックはそのポリシーで評価されます。 同じサブネット内では、ある仮想マシンから別の仮想マシンへのトラフィックは、ポリシーを通過しません。
VPC内では、ポリシーは最高(1,000)から最低(10)の優先順位で評価されます。
次の値を基にトラフィックをマッチングします:
トラフィックがマッチすると、ポリシーは次のアクションを実行できます:
reroute(Re-route)ポリシーは、全てのインバウンドトラフィックをロードバランサーや、VPCの別のサブネットで稼働しているファイアウォール仮想マシンを経由するルーティングを実行するようなことに非常に役立ちます。 これは、ネットワーク機能を提供する仮想マシン(NFVM: Network Function VM)がAHVホストごとに必要になる従来のサービスチェインと比較して、VPC内の全てのトラフィックに対してNFVMが1つのみ必要だという付加価値があります。
ステートレスポリシーでは、許可(Permit)ルールがドロップルールを上書きする場合、往復の両方向で個別のルールが必要です。 この場合、復路のトラフィックはドロップルールによって定義されます。 これらの対応する往路と復路のエントリーは、同じ優先度を使用してグループ化します。
外部ネットワークは、VPCにトラフィックが出入りするための主な方法です。 外部ネットワークは、Prism Centralで作成され、そして単一のPrism Elementクラスタのみに存在します。 このネットワークはVLAN、デフォルトゲートウェイ、IPアドレスプール、そして全てのVPCが使用するNATの種類を定義します。 1つの外部ネットワークは、複数のVPCが利用できます。
外部ネットワークは2種類あります:
PC.2022.1とAOS 6.1から、VPCでは最大2つの外部ネットワークが選択できるようになりました。 VPCは、最大で1つのNAT外部ネットワークと、最大で1つのRouted(NATなし)外部ネットワークを持つことができます。
NAT(Network Address Translation)外部ネットワークは、フローティングIPもしくはVPC SNAT(Source NAT)アドレスの背後にある、VPC内にある仮想マシンのIPアドレスを隠蔽します。 それぞれのVPCは外部ネットワークのIPプールからランダムに採番されたSNAT IPアドレスを持ち、VPCから出るトラフィックは、この送信元アドレスに書き換えられます。
フローティングIPアドレスも、外部ネットワークのIPプールから採番され、入力トラフィックを許可するために、VPC内の仮想マシンに割り当てられます。 フローティングIPが割り当てられた仮想マシンは、出力トラフィックが、VPC SNAT IPの代わりにフローティングIPで書き換えられます。 これは、仮想マシンのプライベートIPアドレスを露出させることなく、VPCの外側にパブリックサービスを公開する際に役立ちます。
ルーティングされた(Routed)、もしくはNATなしの外部ネットワークにより、ルーティングを介してVPC内で物理ネットワークのIPアドレス空間を共有できます。 VPC SNAT IPアドレスの代わりに、VPCルータIPが外部ネットワークのプールからランダムに採番されます。 このVPCルータIPを物理ネットワークのチームと共有することで、VPC内でプロビジョニングされた全てのサブネットに、仮想ルータIPをネクストホップとして設定できます。
例えば、外部ネットワークが10.5.0.0/24のVPCには、仮想ルータIPとして10.5.0.200を割り当てることができます。 VPC内のサブネットが10.10.0.0/16のネットワークで作成されている場合には、物理ネットワークチームは、10.5.0.200経由で10.10.0.0/16へのルートを作成します。 10.10.0.0/16のネットワークは、VPCの外部へルーティング可能なプリフィックスになります。
ネットワークゲートウェイは、サブネット間のコネクタとして動作します。 これらのサブネットは、さまざまな種類と場所に配置できます。
ネットワークゲートウェイのサブネット接続には、いくつかの方法があります。
Layer 3 VPNによる接続タイプでは、別の2つのネットワークプリフィックスを持っている2つのサブネットが接続されます。 例えば、ローカルサブネットである10.10.1.0/24を、リモートサブネットである10.10.2.0/24に接続できます。
2つのネットワークゲートウェイを使用する場合、それぞれのネットワークゲートウェイにはDHCPプールから外部IPアドレスが割り当てられ、それらのアドレスを介して通信できる必要があります。
ネットワークゲートウェイ仮想マシンを、リモートの物理ファイアウォール、またはVPNアプライアンスまたは仮想マシンに接続することもできます。 ローカルのネットワークゲートウェイは、リモートの物理アプライアンスまたは仮想アプライアンスと常に通信できる必要があります。
それぞれのサブネットからリモートサブネットへのトラフィックは、VPC内のIPルーティングを使用して作成されたVPN接続を介して転送されます。 ルートは静的に設定することも、BGPを使用してネットワークゲートウェイ間で共有することもできます。 このVPNトンネル内のトラフィックは、IPsecで暗号化されます。
サブネット間のトラフィックがインターネットのようなパブリックリンクを経由する場合は、IPsec暗号化でのVPNを使用します。
Layer 2 VXLAN VTEPの場合は、同じネットワークプリフィックスを共有する2つのサブネットが接続されます。 たとえば、ローカルサブネットの10.10.1.0/24が、同じく10.10.1.0/24を使用するリモートサブネットに接続されます。
2つのネットワークゲートウェイ仮想マシンを使用する場合、それぞれのネットワークゲートウェイには外部IPアドレスが割り当てられ、2つのネットワークゲートウェイ仮想マシンはこれらのアドレスを介して通信できる必要があります。
ローカルのネットワークゲートウェイは、物理スイッチなどのリモートにある物理VXLAN VTEP終端デバイスに接続することもできます。 物理デバイスは、Cisco、Arista、Juniperなどの一般的なベンダーの標準的なVXLANデバイスが利用できますが、これらに限定されません。 VXLAN VTEP接続には、リモート物理デバイスのIPアドレスを入力するだけです。
ローカルサブネットからリモートサブネットへのトラフィックは、レイヤー2スイッチ経由で交換され、暗号化されていないVXLANにカプセル化されます。 それぞれのネットワークゲートウェイはソースMACアドレステーブルを維持し、ユニキャストまたはフラッディングされたパケットをリモートサブネットに転送します。
トラフィックが暗号化されないため、VXLAN TEPはトラフィックがプライベートもしくはセキュアなリンクを通過する場合のみ使用します。
セキュリティを強化するために、VXLAN接続は、既存のVPN接続でトンネリングすることで暗号化できます。 このケースでは、ネットワークゲートウェイ仮想マシンがVXLANとVPN接続を提供するので、ネットワークゲートウェイ仮想マシンがローカルとリモートの両方のサブネットに必要です。
確実なバックアップ戦略を持つことは、インフラストラクチャ設計において不可欠です。 本書では、ポリシー駆動型のバックアップ、DR、およびランブックによる自動化を提供するNutanix Leapの詳細について説明します。
Note: Nutanix Mine section coming soon!
Nutanix Leapの機能は、Prism Central(PC)に構成された、ポリシー駆動型のバックアップとDR、およびランブックによる自動化サービスを提供します。 この機能は、AOSで利用可能であり、PEで何年にもわたって構成されてきた、ネイティブなDRおよびレプリケーション機能に構築および拡張されています。 レプリケーションなどに活用されている実際のバックエンドメカニズムの詳細については、「Book of AOS」の「バックアップとディザスタリカバリ」セクションを参照してください。 LeapはAOS 5.10で導入されました。
ソリューションは以下の構成に適用できます(リストは不完全な場合があります。サポートされているものの完全なリストについては、ドキュメントを参照してください):
このセクション全体で使用される主な用語、以下のように定義されています:
Nutanix Leapには、いくつかの重要な構成要素があります:
下記の図は、Nutanix Leapの保護ポリシーの構造を示します:
以下の図は、Nutanix Leapにおけるリカバリープランの構造を示します:
保持期間が短い小さなRPOウィンドウや、常に特定のRPOウィンドウに復旧できるようにする必要がある場合には、リニア保持ポリシーを使用します。
保持期間が長いものにはロールアップ保持ポリシーを使用します。 柔軟性が高く、スナップショットのエージングやプルーニングを自動処理すると同時に、運用開始時むけの期間の細かいRPOを提供します。
以下に、Leapの構成の概要を示します:
以下は、LeapがオンプレミスとXiとの間でどのように複製できるかを示します:
このセクションでは、Leapを構成して利用する方法について説明します。
おおまかなプロセスは、以下の手順となります:
最初の手順はAZに接続することで、これはXiのAZ、または別のPCです。 注: PC 5.11以降、少なくとも2つのPCが必要になります(各サイトに1台)。
PCで「Availability Zones」を検索するか、「管理」→「アベイラビリティ ゾーン」に移動します:
「アベイラビリティ ゾーンに接続」をクリックして、AZの種類(「Xi」またはPCインスタンスである「Physical Location」)を選択します:
PCまたはXiの資格情報を入力し、「接続」をクリックします:
接続されたAZが表示され、使用できるようになります。
PCで「保護ポリシー」を検索するか、「ポリシー」→「保護ポリシー」に移動します:
「保護ポリシーを作成」をクリックします:
名前、リカバリロケーション、RPO、保存ポリシーの詳細を入力します(前述):
注:Xiの場合は、「ターゲットクラスタ」を選択する必要はありません:
次に、ポリシーを適用するカテゴリを選択します:
「保存」をクリックすると、新しく作成された保護ポリシーが表示されます:
PCで「Recovery Plans」を検索するか、「ポリシー」→「リカバリープラン」に移動します:
最初の起動時に、最初のリカバリープランを作成するための画面が表示されます:
ドロップダウンを使用して「Recovery Location」を選択します:
注:これは、XiのAZまたはPhysical AZ(対応する管理対象クラスタを持つPC)のいずれかです。
リカバリープランの名前と説明を入力し、「Next」をクリックします:
次に「Add Entities」をクリックして、パワーオンのシーケンスを指定します:
VMまたはカテゴリを検索して、各ステージに追加します:
ステージのPower On Sequenceが適切になったら、「次へ」をクリックします:
Power On Sequenceを決定するときは、次のようにステージ設定する必要があります:
次に、ソースとターゲットの環境の間でネットワークをマッピングします:
ほとんどの場合で、テストネットワークには、ルーティング不可能な、または分離されたネットワークを使用します。 これにより、SIDの重複、ARPエントリーなどの問題が発生しなくなります。
CNCFでは、クラウドネイティブを「組織が、パブリック、プライベート、ハイブリッドクラウドといったモダンで動的な環境において、拡張可能なアプリケーションを構築および実行できるようにするテクノロジーのセット」と定義しています。 アプリケーションモダナイゼーションへの移行を推進する主要なテクノロジーには、コンテナ、マイクロサービス、そしてKubernetesが含まれます。
我々は、Nutanixのハイパーコンバージドインフラストラクチャー(HCI)は、大規模なKubernetesで実行されるクラウドネイティブワークロードの理想的なインフラストラクチャ基盤であると確信しています。 Nutanixはプラットフォームのモビリティを提供し、Nutanixプライベートクラウドと、パブリッククラウドとの両方でワークロードを実行するための選択肢を提供します。 Nutanixアーキテクチャーはハードウェア障害を念頭に置いて設計されており、それはKubernetesプラットフォームコンポーネントとアプリケーションデータの両方に、より良い回復力を提供します。 HCIノードを追加することで、Kubernetesコンピュートノードに拡張性と回復力が提供される恩恵を受けられます。 同様に重要なこととして、各HCIノードとともにデプロイされる追加のストレージコントローラーがあることで、ステートフルなコンテナ化されたアプリケーションのストレージパフォーマンスが向上することが挙げられます。
Nutanix Cloud Platformは、Nutanix Kubernetes Engine(NKE)によって組み込みのターンキーKubernetes体験を提供します。 NKEはエンタープライズグレードの製品であり、複数のクラスタにおけるプロビジョニングとライフサイクル管理を簡素化します。 Nutanixは顧客の選択に関するものであり、優れたフルスタックのリソース管理により、顧客はOpenShift、Rancher、Anthosなどの好みのディストリビューションを実行できます。 詳細については、以降のチャプターをご覧ください。
Nutanix Unified Storageは、永続的で拡張性のあるソフトウェアデファインドストレージをKubernetesクラスタに提供します。 これらには、Nutanix CSIドライバーを介したブロックおよびファイルストレージと、S3互換のオブジェクトストレージが含まれます。 さらに、Nutanix Database Serviceによって、大規模なデータベースのプロビジョンと操作が可能です。
以降のチャプターで、これらについて詳しく説明します。
Note: Nutanix Unified Data Services chapter coming soon!
Nutanix Kubernetes Engine(NKE)は、Kubernetesのターンキープロビジョニング、運用、そしてライフサイクル管理を可能にするNutanix認定エンタープライズKubernetes管理ソリューションです。
このソリューションは、以下の構成に適用できます:
主なユースケース:
管理インターフェース:
サポートされる環境:
サポートされるノードOSイメージ:
アップグレード:
互換性のある機能:
Nutanix Kubernetes Engineは、Prism Centralで有効化できます。 NKEを有効化したPCに登録されているNutanix AOSクラスタは、Kubernetesクラスタをプロビジョニングするためのターゲットとして使用できます。
NKEで有効化されているKubernetesクラスタは、複数のNutanixクラスタをまたぐことができません。
NKEはPrism Centralでコンテナ化されたサービスとして実行されます。 PCでNKEが有効化されると、次の2つのコンテナがプロビジョンされます: karbon-coreコンテナとkarbon-uiコンテナ
karbon-coreは、Kubernetesクラスタのライフサイクル管理を担当します。 プロビジョニング、ノードOSのアップグレード、クラスタ拡張などのタスクは、このコンテナによって実行されます。
karbon-uiは、Prism Centralを介して直感的なコンソールの提供を担当します。 この統合されたUIから、IT管理者はNKEインスタンスによって管理されるKubernetesランドスケープ全体を完全に制御できます。
NKEは、エアギャップ環境でも有効化できます。(詳細はこちらをご覧ください)
NKEは、Kubernetesノードをインストールおよび拡張するためのOSイメージを提供します。 NKEは、NKEを有効化したKubernetesクラスタを作成するための、CentOS Linuxベースのオペレーティングシステムを使用します。 脆弱性を修正するパッチを含む、新しいOSイメージバージョンが定期的にリリースされます。 サポートされるOSイメージバージョンのリストについては、NKEのリリースノートを確認してください。 (詳細はこちらをご覧ください)
OSイメージの持ち込み(Bringing your own OS image)は、サポートされていません。
推奨される構成には2つの選択肢があります:
Development ClusterとProduction Cluster
Development Clusterを選択すると、高可用性のコントロールプレーンを持ちません。 コントロールプレーンノードがオフラインになった場合は、Kubernetesクラスタに影響があります。
Developmentの最小クラスタサイズは3ノードです:
Production Clusterを選択すると、高可用性のコントロールプレーンを持ちます。 この構成の選択には、単一障害点がありません。
Productionの最小クラスタサイズは8ノードです:
Kubernetesクラスタに必要なネットワークは合計で3つあり、仮想マシンネットワークとKubernetesネットワークにグループ化できます。
仮想マシンネットワークまたはノードネットワーク: これは、DHCP(Development Clusterのみ)またはIPAMが有効で管理されているネットワーク(関連するドメイン設定とIPアドレスプールを設定してある)のいずれかによって割り当てる必要があります。 Production構成では、アクティブ-パッシブモード、およびアクティブ-アクティブモードのために追加の静的IPアドレスが必要です。
Kubernetesネットワーク: クラスタには、少なくとも2つのClassless Inter-Domain Routing(CIDR)範囲が必要であり、1つはKubernetesのサービスネットワーク、もう1つはKubernetesのPodネットワークです。
NKEは、Kubernetesのために2つのContainer Network Interface(CNI)プロバイダーをサポートしています: FlannelとCalico
サービスCIDRとPod CIDRの範囲はデフォルトのままにできますが、クラスタ内のPodが外部ネットワークへのアクセスを必要とする場合は、お互いに、あるはデータセンター内の既存ネットワークと、範囲が重複したりしないようにする必要があります。
コントロールプレーンのモードがアクティブ-アクティブのProduction Clusterでは、外部のロードバランサーが必要です。
Kubernetesクラスタをデプロイする際には、一緒にNutanix Container Storage Interface(CSI)ドライバーもデプロイされます。
デプロイ処理の中でデフォルトのStorageClassも作成され、これはNutanix Volumesを使用します。 これは、監視用のPrometheusや、メトリックとログを保存するためのEFK(Elasticsearch、Fluent Bit、Kibana)ロギングスタックといった同梱されているアドオンで必要です。 デプロイ後に、同じCSIドライバーを使用してストレージクラスを追加できます (例はこちら)。
Nutanix Volumesとは別に、Nutanix Filesを使用してファイルストレージのためのStorageClassを作成することもできます。 StorageClassで構成されているストレージバックエンドに依存して、PersistentVolumeClaimを作成するときに異なるアクセスモードがサポートされます。
ストレージバックエンド | ReadWriteOnce RWO |
ReadOnlyMany ROX |
ReadWriteMany RWX |
ReadWriteOncePod RWOP |
---|---|---|---|---|
Volumes | ||||
Files |
アクセスと認証に関して、覚えておくべき2つのコンポーネントがあります: PC内のNKEと、NKEが有効化されたKubernetesクラスタです。
NKEは、Prism Centralの認証とRBACを使用します。 Nutanixでは、NKEユーザーを、Microsoft Active DirectoryなどのPrism Centralのディレクトリサービスに設定する必要があります。 ユーザーはNKEコンソールにアクセスし、割り当てられたロールに基づいて特定のタスクを行えるようになります。
PCの"User Admin"ロールのメンバーは、NKEとその機能に完全なアクセス権限を持ちます。
"Prism Central Admin"ロールまたは"Viewer"ロールのメンバーは、kubeconfigのダウンロードのみが可能です。
NKEが有効化されたKubernetesクラスタは、デプロイした直後に(out-of-the-boxで)Prism Central認証で使用できるように、PCの"User Admin"ロールとKubernetesの"cluster-admin"ロールをマッピングしています。
認証の視点では、KubernetesクラスタはPCのディレクトリサービスを使用するNKEに認証リクエストを送信します。 これは、デプロイした直後にActive Directoryでユーザー認証ができることを意味します。
RBACの観点では、PCの"User Admin"ロールは、"cluster-admin"という名前のKubernetesのスーパー管理者にあたるロールにマッピングされます。 これは、PCの"User Admin"ロールのユーザーメンバーが、NKEインスタンスによって管理されるすべてのKubernetesクラスタのスーパーユーザーであることを意味します。 一方で、PCロールの"Prism Central Admin"と"Viewer"には、Kubernetesロールとのマッピングがありません。 つまり、これら2つのロールのいずれかのユーザーメンバーは、NKEからkubeconfigをダウンロードできますが、Kubernetesレベルでのアクションは実行できません。 スーパー管理者のユーザーは、Kubernetes内に正しいロールマッピングを作成する必要があります。
NKEによって生成されたkubeconfigは24時間有効であり、その後、ユーザーは新しいkubeconfigファイルを要求する必要があることに注意してください。 これは、NKE GUI、CLI、API、または kubectlプラグイン(推奨)を使用して実行できます。
KubernetesノードへのSSHアクセスは、一時的な証明書を使用してロックダウンされます。これは、NKEコンソールで入手でき、24時間後に有効期限が切れます。 ノードOSでのソフトウェアのインストールや設定の変更は非サポートであり、変更はアップグレードまたはノードプールのスケールアウトの際に永続化されません。 SSH経由でノードにアクセスする唯一の理由は、Nutanixサポートの裁量でのトラブルシューティングです。
Nutanixは、NKEが有効化されたKubernetesクラスタをCIS Kubernetes Benchmark 1.6にて評価しました。 コンプライアンスについては、GitHubで入手できる自動化されたオープンソースツールであるKube Benchで確認できます。 レポートは、こちら から確認できます。
NKEアドオンは、デプロイしたクラスタに追加機能を提供するオープンソースソフトウェアによる拡張です。 Kubernetesクラスタをデプロイすると、アドオンは自動的にインストールされます。
Nutanix Kubernetes Engineには、以下のアドオンが含まれます:
これらのアドオンは、クラスタの内部のみで使用されます。 これらの構成は、Kubernetesクラスタで実行されているアプリケーションによって生成されたデータをサポートするようには設計されていません。 コンテナ化されたアプリケーションのログとメトリックを収集するには、EFKとPrometheusの専用インスタンスをデプロイするか、環境で利用可能な既存のものを再利用します。
ロギングスタックは、Kubernetesノードからのすべてのオペレーティングシステムとインフラストラクチャのログを集約します。 Kibanaダッシュボードは、NKEコンソールからアクセスできます。
NKE 2.4以降、ロギングスタックを無効にでき(詳細はこちら)、Fluent Bitを外部の既存のロギングスタックへのログ転送に使用することができます(詳細はこちら)。
KubernetesクラスタにはPrometheus Operatorがインストールされており、インフラストラクチャのメトリックを収集するために1つのインスタンスがデプロイされています。 追加のPrometheusインスタンスは、例えばアプリケーションのモニタリングのために、Operatorを使用してデプロイできます(ブログ)。
NKE 2.4以降、電子メールアドレスへのSMTPベースのアラート転送を有効にできます(詳細はこちら)。
NKEのアップグレードには、2つの異なる種類があります:
Karbonの現在のバージョンを確認する、もしくは新しいバージョンにアップグレードするには、LCMを使用してPrism Centralのインベントリ確認を実行します。 LCMは、以下のNKEコンポーネントをアップグレードします:
最新バージョンのNKEにアップグレードする場合は、すべてのKubernetesクラスタが実行されているか、最初にアップデート先のNKEによってサポートされているバージョンにアップグレードしておく必要があることに注意してください。 サポートされているバージョンの更新については、Nutanixポータルを確認してください。
Kubernetesクラスタのアップグレードには、次の2つの側面があります:
ノードOSまたはKubernetesバージョンのアップグレードは、KubernetesクラスタのDevelopmentまたはProductionといった種類によっては、破壊的でありうることに注意してください。
ノードOSイメージのアップグレードが利用可能な場合、NKEは"OS Images"タブに、新しいイメージをダウンロードするオプションを表示します。 NKEは、Clustersビューのクラスタの横に"Upgrade Available"アイコンも表示します。
アップグレード対象となるKubernetesバージョンがあるクラスタでは、テーブルで"Upgrade Available"アイコンが表示されます。 アップグレードプロセスの一環として、Kubernetesバージョンと、インストールされているアドオンで利用可能な更新版をアップグレードします。
NKE CLIであるkarbonctlを使用すると、ユーザーはNKEおよびKubernetesクラスタのライフサイクル管理タスクを実行できます。 特定の高度なタスクについては、karbonctlのみで実行できます。
karbonctlを使用するには、Prism CentralインスタンスにSSHで接続する必要があります。 バイナリのパスは、/home/nutanix/karbon/karbonctlです。
karbonctlで実行できる一般的なタスクは以下です:
NKE APIを使用すると、ユーザーはNKEとKubernetesクラスタの管理タスクをプログラムによって実行できるようになります。 APIドキュメントは、https://www.nutanix.dev/reference/karbonで確認できます。
Nutanix Cloud Platformは、認定Kubernetesディストリビューションを実行するための理想的なソリューションです。 Nutanixは、大規模なモダンアプリケーションを正常実行するために必要なすべてのリソースを備えた、エンタープライズクラスのプラットフォームを提供します。
Kubernetesディストリビューションは、コンピューティング、ネットワーク、ストレージを必要とします。 Nutanixを使用することで、IT管理者や開発者はこれらのリソースに簡単にアクセスでき、好みのKubernetesディストリビューションを実行できます。 Red Hat OpenShift、Google Anthosなどを含むいくつかの主要なKubernetesディストリビューションプロバイダーは、ソリューションをNutanixで使用することを認定しています。 サポートされているパートナーソフトウェアソリューションは、Nutanixサポートポータルでオンラインで表示します。
![]() |
![]() |
![]() |
すべてのKubernetesディストリビューションには、少なくとも以下のコンポーネントによる基本的なアーキテクチャーがあります:
さらに、これらのコンポーネントがすべてのKubernetes コントロールプレーンとワーカーのノードで実行されます。
これらのコンポーネントの詳細情報は、Kubernetes documentationで見つけることができます。
これまでのインフラストラクチャーの歴史と、現在の状況に至るまでのおおまかな流れを簡単に振り返ってみましょう。
データセンターは、過去十年で大きな進化を遂げています。以下のセクションで、各時代を詳しく見てみましょう。
長年に渡りメインフレームは、世の中を支配し今日のシステムの中核的な基礎を築いていきました。多くの企業は主にメインフレームの次のような特性を活かすことができました:
一方でまた、次のような問題も発生しています:
一部のユーザーは、メインフレームでは実現することができない数々の特徴を持つピザボックス型やスタンドアローン型のサーバーへと移行しました。スタンドアローンサーバーの主な特徴は:
しかし、これらのスタンドアローンサーバーでは次のような問題が発生しました:
ビジネスでは常に利益を生み出す必要があり、データはその重要な要素となります。 直結ストレージ(DAS)を使用する場合、実際に使用する以上の容量が必要となり、またサーバー障害によってデータアクセス出来なくならないよう、データの高可用性(HA)対策が必要でした。
集中型ストレージは、メインフレームとスタンドアローンサーバーを共有可能な大規模なストレージ プールで置き換え、同時にデータ保護機能も提供しました。集中型ストレージの主な特徴は:
集中型ストレージにおける問題点:
この時点では、サーバーの使用率は低く、リソース効率性が収益に影響を与えていました。 そこに仮想化技術が登場し、1台のハードウェア上で複数のアプリケーションやオペレーティングシステム(OS)を仮想マシン(VM)として稼動させることができるようになりました。 仮想化は、ピザボックスの使用率を向上させましたが、さらにサイロの数を増やし、機能停止が与える影響を増加させる結果となりました。 仮想化の主な特徴は:
仮想化の問題点:
ハイパーバイザーは、その効率が向上し機能も充実してきました。 VMware vMotionやHA、DRといったツールの出現により、ユーザーは、VMの高可用性を手に入れることができるようになり、サーバーワークロードを動的に移行できるようになりました。 しかし、1点注意しなければならないのは、集中型ストレージに対する依存性によって競合が発生することです。 つまり、これまで以上のストレージアレイ負荷の増加と不要なVMの乱造がストレージI/Oの競合を招いているのです。
主な特徴:
問題点:
SSDはI/Oのボトルネックを軽減します。より高いI/Oパフォーマンスを提供しますし、大量のディスク筐体も必要ありません。 確かにパフォーマンスは非常に優れていますが、コントローラーやネットワークは、その膨大なI/O処理に追い着いていません。 SSDの主な特徴は:
SSDの問題点:
クラウドの定義は非常に曖昧なものです。 簡単に言えば、別の誰かがどこかでホストしているサービスを購入し活用できる機能ということです。
クラウドの登場によって、IT部門や業務部門、そしてエンドユーザーのあり方も変わってきています。
業務部門やITの利用者は、クラウドと同様の俊敏性や、価値実現までの早さをIT部門に求めます。 これがかなわない場合には、自ら直接クラウドを利用しようとさえします。 しかし、これがIT部門に別の問題をもたらすのです。 それはデータセキュリティという問題です。
クラウドサービスの柱となるもの:
一般的にクラウドは、主に以下の3つのサービス形態に分類することができます(レベルの高い順に並べてあります):
クラウドは、IT部門に対して目をそむけることのできないジレンマをもたらしています。 IT部門自身がクラウドに取り組んだり、同様の機能を提供したりすることは可能です。 しかし、データは社内に確保したいと望むものの、クラウドのセルフサービス機能や迅速性を提供しなければならないのです。
このような変化によって、IT部門は、エンドユーザー(自社の社員)に対する合理的なサービスプロバイダーとなることを強いられています。
以下の表に、各I/Oタイプ別のレイテンシーを示します:
項目 | レイテンシー | 補足 |
---|---|---|
L1キャッシュ参照 | 0.5 ns | |
L2キャッシュ参照 | 7 ns | L1キャッシュ×14 |
DRAMアクセス | 100 ns | L2キャッシュ×20、L1キャッシュ×200 |
3D XPointベースのNVMe SSD READ | 10,000 ns(期待値) | 10 us または 0.01 ms |
NAND NVMe SSD R/W | 20,000 ns | 20 us または 0.02 ms |
NAND SATA SSD R/W | 50,000-60,000 ns | 50-60 us または 0.05-0.06 ms |
SSDから4KをランダムREAD | 150,000 ns | 150 us または 0.15 ms |
P2P TCP/IPレイテンシー(物理から物理) | 150,000 ns | 150 us または 0.15 ms |
P2P TCP/IPレイテンシー (仮想から仮想) | 250,000 ns | 250 us または 0.25 ms |
メモリから1MBシーケンシャルREAD | 250,000 ns | 250 us または 0.25 ms |
データセンター内のラウンドトリップ | 500,000 ns | 500 us または 0.25 ms |
SSDから1MBシーケンシャルREAD | 1,000,000 ns | 1 ms, メモリ×4 |
ディスクシーク | 10,000,000 nsまたは10,000 us | 10 ms、データセンターラウンドトリップ x 20 |
ディスクから1MBシーケンシャルREAD | 20,000,000 nsまたは 20,000 us | 20 ms、メモリ x 80、SSD x 20 |
CAカリフォルニア州からパケット転送 -> オランダ -> カリフォルニア州 | 150,000,000 ns | 150 ms |
(典拠: Jeff Dean, https://gist.github.com/jboner/2841832)
上記の表から、CPUのキャッシュに対するアクセスは、 ~0.5-7ns(L1対L2)で実施されることが分かります。 メインメモリに対するアクセスは~100 nsで、ローカルのSSDに対する4KのReadは、~150,000 ns、つまり0.15msになります。
一般的なエンタープライズ向けSSD (この場合は、Intel S3700 - 仕様) を利用すれば、次のような性能が得られます:
従来のストレージの場合、I/Oのための主要なメディアタイプが幾つかあります:
以下の計算には、Intel S3700のRead 500MB/s、Write 460MB/sのバンド幅を使用します。
計算式は次の通りです:
numSSD = ROUNDUP((numConnections * connBW (in GB/s))/ ssdBW (R or W))
注意: SSDを半端な区切りでは利用できないので、端数は切り上げ(ROUNDUP)しています。 また、全てのI/Oの処理に必要なCPUが十分にあるものとし、また、コントローラーCPUの能力も十分なものと想定しています。
ネットワーク帯域幅 (BW) | 帯域幅の飽和状態に必要なSSD本数 | ||
---|---|---|---|
コントローラーの接続性 | 使用可能な帯域幅 | Read I/O | Write I/O |
Dual 4Gb FC | 8Gb == 1GB | 2 | 3 |
Dual 8Gb FC | 16Gb == 2GB | 4 | 5 |
Dual 16Gb FC | 32Gb == 4GB | 8 | 9 |
Dual 32Gb FC | 64Gb == 8GB | 16 | 19 |
Dual 1Gb ETH | 2Gb == 0.25GB | 1 | 1 |
Dual 10Gb ETH | 20Gb == 2.5GB | 5 | 6 |
この表に示したように、SSDの最大論理パフォーマンスを得ようとすると、ネットワークのタイプによって、1~9つのSSDいずれでもネットワークがボトルネックとなる可能性があります。
一般的にメインメモリのレイテンシーは ~100ns (幅がある) なので、以下のように計算できます。
一般的なネットワークRTTを~0.5ms(スイッチベンダーにより異なる)、つまり~500,000nsと仮定すると:
非常に高速なネットワークで、RTTが10,000nsと理論的に仮定すると:
つまり、どんなに理論的に高速なネットワークであっても、ネットワークを介さないメモリアクセスに比べ、10,000%のオーバーヘッドがかかるということです。 低速なネットワークなら、レイテンシーオーバーヘッドは、500,000%にも達することでしょう。
このオーバーヘッドを軽減するために登場したのが、サーバーサイドでのキャッシュテクノロジーです。
よく議論に上るのは、ユーザー空間とカーネル空間の分担についての話題です。ここでは、それぞれの意味とメリット、デメリットについて説明します。
どんなオペレーティングシステム (OS) にも、2つのコアとなる処理領域があります:
これら2つの空間が連携することで、OSは機能します。先に進む前に、幾つかの重要な用語を定義しておきます:
例えば、データをディスクに書き込むような単純なアプリケーションの例を見てみましょう。ここでは次のような処理が行われます:
以下にこのようなやり取りの例を示します。
どちらの空間が優れているのでしょうか?実際には、それぞれにメリットとデメリットがあります:
もう1つのコアは、カーネル空間とユーザー空間のやり取りを実施するコンポーネントです。やり取りには2つタイプがあります:
昔に比べると、デバイスは遙かに高速になり(例えば、NVMe、Intel Optane、pMEMなど)、カーネルとデバイスのやり取りがボトルネックになってきています。 このようなボトルネックを排除するために、多くのベンダーが処理をカーネルからユーザー空間に移し、ポーリング方式を採用することで、より優れた結果を得ようとしています。
この良い例として、Storage Performance Development Kit (SPDK)やData Plane Development Kit (DPDK)が上げられます。これらのプロジェクトは、パフォーマンスを最大化し、レイテンシーを最大限縮小して、優れた結果を生みだしています。
このようなシフトは、2つの主要な変更によって可能となっています:
この方式の場合には、以下を排除できるため、これまでのカーネルベースに比べて遙かにすぐれたパフォーマンスを得ることができます:
ユーザー空間に置かれたドライバーを使用したデバイスとのやり取りを以下に示します:
実際に、NutanixがAHVのために開発したソフトウェアの一部 (vhost-user-scsi) が、IntelのSPDKプロジェクトで使用されています。
Webスケール – ウェブスケール – 名詞 – コンピューターアーキテクチャー
インフラストラクチャーおよびコンピューティングのための
新しいアーキテクチャー
本セクションでは、「Webスケール」インフラストラクチャーの核となる概念と、なぜそれを採用するのかについて説明します。 始める前に、Webスケールだからといって、GoogleやFacebook、Microsoftのような「超大規模なスケール」になる必要はないということを明言しておきます。 Webスケールな構成はどんな規模(3ノードでも、数千ノードでも)でも可能であり、その恩恵を受けることができます。
これまでの課題は:
Webスケールなインフラストラクチャーについて説明する場合、いくつか重要な要素があります:
その他の要素:
以下のセクションでは、これらの技術的な意味を説明します。
ハイパーコンバージェンスとは何か?という点については、複数の異なる見解が存在します。 対象とするコンポーネント(例えば、仮想化、ネットワークなど)によっても異なります。 しかし、中心となる概念は、「2つ以上のコンポーネントをネイティブに1つのユニットに統合すること」にあります。 「ネイティブに」という点が重要となります。 最大の効率を発揮するためには、該当コンポーネントは、単にひとまとめにする(bundle)のみではなく、ネイティブに統合される必要があります。 Nutanixの場合、サーバーとストレージを1つのノードとしてアプライアンスとして統合しています。 他のベンダーの場合には、ストレージとネットワークの統合という形態であったりします。
ハイパーコンバージェンスとは、つまり:
メリットとしては:
ソフトウェア デファインド インテリジェンスとは、プロプライエタリなハードウェア、あるいは特殊なハードウェア(例えばASICやFPGA)のコアなロジックを抽出し、それをソフトウェアとしてコモディティハードウェア上で実装するものです。 Nutanixの場合、従来のストレージロジック(例えばRAID、重複排除、圧縮機能など)を抽出し、標準的なハードウェアで構成するNutanix CVM上のソフトウェアとして稼動させています。
Nutanixでは、現在、x86とIBM Powerアーキテクチャーの両方をサポートしています。
つまり:
メリットとしては:
最後の項目について: 古いハードウェアでも、最新の最も優れたソフトウェアを稼動させることができます。 つまり、減価償却サイクルに入ったハードウェアでも、最新版のソフトウェアや、今工場から出荷されている新しい製品と同等な機能が使用できるということです。
自律分散システム(Distributed Autonomous Systems)は、特定のユニットがある処理に対応するという従来の概念を払拭し、その役割をクラスタ内の全てのノードで分散して受け持つというものです。 これこそが本当の分散システムです。これまでベンダーは、ハードウェアは信頼性に足るものだと仮定し、ほとんどの場合それは正解でした。 しかし、分散システムでは、いずれハードウェアは障害を起こすものと想定し、それに的確かつ停止なく対処できるということが重要だと考えます。
これらの分散システムは、障害への対応と修正が行なえるようデザインされており、自己修復あるいは自律的な回復が図られるようになっています。 コンポーネントに障害が発生すると、システムはユーザーに意識させることなく障害を処理・修復し、想定通りに運用を継続します。 ユーザーはアラートによって障害に気付きますが、急を要するものでない限り、管理者のスケジュールに沿って修復(例えば障害ノードの交換)を行うことができます。 別の方法として、障害を置き換える(交換せずに再構築する)方法もあります。「リーダー」に障害が発生した場合、新しいリーダー選定プロセスが働き、該当する対象に割り当てられます。 処理の分散については、MapReduceの概念が用いられます。
つまり:
メリットとしては:
インクリメンタル(漸増的)かつリニア(線形的)な拡張とは、当初は限定的なリソースからシステムを開始し、必要に応じてパフォーマンスをリニアに拡張していくことを意味します。この拡張性の実現には、前述した要素が全て不可欠となります。従来、仮想ワークロードを処理するためには、サーバー、ストレージ、ネットワークという3階層のコンポーネントが必要で、それぞれは個別に拡張する必要がありました。例えば、サーバー数を拡大しても、ストレージのパフォーマンスも拡張されるわけではありません。Nutanixのようなハイパーコンバージドプラットフォームでは、ノードを拡張すると同時に、以下の要素も拡張されます:
つまり:
メリットとしては:
まとめ:
Nutanixバイブルは、Dheeraj Pandey(元Nutanix CEO)とSteven Poitras(元 Nutanix Chief Architect)なしでは実現できませんでした。
Nutanixバイブルが誕生した理由と経緯について、Dheeraj の言葉を引用します。
最初に、「バイブル」という本書の名前ですが、神に関心のない方や、無神論者であるため自分には関係ないと思われる方もいらっしゃるかと思います。 しかし、辞書「Merriam Webster」によれば、「バイブル」とは、たとえ宗教とは関係のない事柄であっても、聖書のように「高い権威や幅広い読者層を持つ傑出した出版物」という意味を持ちます。 この表現によってNutanixバイブルの本質を理解することができます。 本書は、Nutanixの中では、常に控えめな立場を取りながら、一方では最高レベルの知識を有する1人で、Nutanix最初のソリューションアーキテクトでもあるSteven Poitrasが最初に執筆を始めたものです。 彼は「初期からの社員」という立場に甘んじることなく、この分野の権威であり続けています。 彼の知識そのものがNutanixに力を与えているのではなく、自らの知識を共有しようという彼の行動力こそが、Nutanixという会社をより強いものにしています。 この分野における彼の高い専門性、PowerShellやPythonを活用した面倒な作業の自動化、卓越した(そして内容と形態が美しくバランスされた)リファレンスアーキテクチャーの構築、YammerやTwitterに関して助けが必要なメンバーのリアルタイムな支援、内省や自己改善を必要としているエンジニアとの透明な関係、さらに、常に意欲的であることこそが、Nutanixという会社の文化を形成しているのです。
彼はブログを書き始めるにあたって、内容の透明性を維持し、デザインをオープンにすることで業界の支持を築きあげるという大きな夢を持っていました。 企業として考えた場合、彼がブログに書いたようなレベルでデザインやアーキテクチャーを公開することは稀です。 確かに、オープンソース企業は、ソースコードを公開しているため透明性が高いように思われますが、デザインの詳細や内部的な動作の仕組みについては、決して語ろうとはしません。 しかしNutanixの競合相手が製品やデザインの弱点を知れば、逆にそれはNutanixを強くすることにも繋がるのです。 なぜなら、Nutanixに隠すべきものがほとんどなく、特定の領域でピンポイントの批評が得られるなら、それはNutanixにとって役に立つものだからです。 機能やデザインに対する一般からの評価については、それが本当の弱みなのか、あるいは、本来は強みにもかかわらず誰かの恐怖心を煽っているだけなのかを、企業向けソーシャルネットワークであるYammerを通じて、遅かれ早かれ結論付けることができます。 つまりNutanixバイブルによって、自分達を過信するといったあやまちを避けることができるのです。 本Nutanixバイブルは、お客様やパートナーに対する誠実心の表明なのです。
この日々進歩し続ける記事の内容は、単に専門家だけでなく、世界中の読者を楽しませています。 アーキテクトやマネージャー、CIOまでがカンファレンス会場のロビーで私を呼び止め、鮮やかで明解な記述と詳細な解説図や図表についての賛辞を述べてくれます。 本書においてSteven Poitrasは、話の内容を省略することなくWebスケールについて語っています。 ほとんどの現場のITの担当者が、世の中の「スピード」に追随できず埋もれていく中で、誰もがNutanixの分散アーキテクチャーを活用できるようにすることは、決して容易ではありませんでした。本バイブルでは、コンピューターサイエンスとソフトウェアエンジニアリングのトレードオフを非常に分かりやすい言葉で表現しており、ITとDevOpsの間のギャップを埋めることができます。Nutanixは、この3~5年間で、IT担当者がDevOpsのWebスケールな専門用語を使って会話するようになるだろうと考えています。
いつも誠実たらんことを
-- 元 Nutanix CEO、Dheeraj Pandey
さらにNutanixを学ぶために、ご自身で Nutanix Test Drive をチェックしてください!
Nutanixバイブルをお読みいただき、ありがとうございました。これからも更新を続けていきますので、どうかお見逃しなく。そして、どうぞNutanixプラットフォームをお楽しみください!