2021年7月12日月曜日

Nutanixのデータ保護について(その 1)

みなさん、こんにちは


本日投稿の内容について、以前別サイトで私が投稿したブログの内容です。
サイトの閉鎖に伴い、こちらで再度掲載いたします。

今回はNutanixのデータ保護に関してご紹介します。
内容は若干長いため、2回に分けてご紹介します。
(画像の⼀部はNutanix様の資料から拝借させて頂いております)

1.Site Failover Operations
サイトがフェイルオーバーした時のオペレーションのことを考えてみましょう。

まず、スナップショットとレプリケーションのスケジュールを設定した後で、あるサイトから別のサイトにフェイルオーバーする必要があるかもしれません。 3つのフェイルオーバーシナリオが可能です。

計画的フェイルオーバー︓
両⽅のサイトが稼働していて、その構成が正しく機能することをテストしたい場合、または1次サイトの計画的保守またはサイト拡張の前にフェイルオーバーします

災害時フェイルオーバー︓
プライマリサイトが停⽌したときのフェイルオーバー

フェイルバック︓
システム停⽌を解決してプライマリサイトに戻したい場合に、復旧サイトから計画的フェイルオーバーを開始します

2.計画的なフェイルオーバーもしくはフェイルバック
この操作は以下のことを行います。 
  • 保護ドメインのスナップショットを作成して複製します。 
  • ローカルサイトのVMをシャットダウンします。 
  • 保護ドメインの別のスナップショットを作成して複製します。 
  • すべてのVMの登録を解除し、それらに関連付けられているファイルを削除します。 
  • ローカルサイト保護ドメインを非アクティブとしてマークします。 
  • 最後のスナップショットからすべてのVMファイルを復元し、 それらをリモートサイトに登録します。 
  • リモートサイト保護ドメインをアクティブとしてマークします。 
3.災害時フェイルオーバー/保護ドメイン
災害時フェイルオーバー操作は以下のことを行います。 
  • 最後の完全複製スナップショットからすべてのVMファイルを復元します。
  • 復旧サイトにVMを登録します。
  • フェールオーバーサイト保護ドメインをアクティブとしてマークします。
保護ドメイン変更操作は以下のことを行います。 

既存の保護ドメインを変更するには、ドメインモードの変更(アクティブ/非アクティブ)、ドメインの複製、ドメインの移行、ドメイン設定の更新、またはドメインの削除を行います。 

4.保護ドメインのガイドライン
メトロアベイラビリティポリシーを適用するための一般的なガイドライン
保護ドメインは、ローカルクラスタ上のプライマリストレージコンテナと、リモートクラスタ上の同じ名前のスタンバイストレージコンテナを指定することによって作成されます。以下は、メトロアベイラビリティを適用するための設定とガイドラインです。 

  • ストレージコンテナをメトロアベイラビリティで使用する場合、データストア名はストレージコンテナ名と同じである必要があります。 
  • 2つのサイトにわたるデータストアの可用性を確保するには、両方のサイトにリアルタイムでデータが存在する必要があります。したがって、クラスタ間のラウンドトリップレイテンシは5ms未満である必要があります。
  • ピーク書き込みに対応するために十分な帯域幅を維持します。サイト間に冗長な物理ネットワークを用意することをお勧めします。 
  • 特定のVMに関連付けられているすべての仮想ディスクが、メトロアベイラビリティが有効になっているコンテナに存在することを確認します。 
  • 保護されたVMは、アクティブストレージコンテナに関連付けられているNutanixクラスタまたはスタンバイストレージコンテナに関連付けられているクラスタのどちらでも実行できます。ただし、スタンバイストレージコンテナに関連付けられているクラスタ上でVMが実行されていると、アクティブストレージコンテナへのネットワークを介して読み取りと書き込みが行われます。したがって、ネットワークトラフィックとそれに関連するネットワークの待ち時間を減らすために、VMのデータが存在するアクティブコンテナに対してVMのデータがローカルに実行されるアクティブコンテナに対してVMをローカルに実行することをお勧めします。 
  • メトロアベイラビリティポリシーはストレージコンテナ(クラスタではなく)ごとに適用されるため、クラスタはあるデータストアに対してアクティブで、別のデータストアに対してスタンバイになることができます。たとえば、ストレージコンテナ1にOracleデータストア(データストアA)、ストレージコンテナ2にExchangeデータストア(データストアB)を持つクラスタ構成を考えます。クラスタAはデータストアAに対してアクティブで、クラスタBはスタンバイです。データストアBに対してアクティブで、クラスタAをスタンバイにします。さらに、メトロアベイラビリティのストレージコンテナは、同じクラスタ内の通常のストレージコンテナと共存できます。 
5.VMセントリックのデータ保護
AOSは、ネイティブのオンサイトバックアップと、オフサイトバックアップおよびディザスタリカバリ用のリモートレプリケーションの両方に統合データ保護ソリューションを提供します。
これらの機能は、スナップショットがソースVMと同じクラスターに格納されるタイムストリームと、スナップショットがクラスター間で非同期に複製されるサイト間レプリケーションの2つのユースケースで使用できます。 

VMのスナップショットはクラッシュコンシステントです。つまり、VMDKのオンディスクイメージは一時点で一貫性を保っています。つまり、スナップショットはVMがクラッシュしたかのようにディスク上のデータを表します。状況によっては、スナップショットもアプリケーションと整合性があります。
つまり、スナップショットの時点でアプリケーションデータが静止します。アプリケーション整合性のあるスナップショットは、ESXiハイパーバイザーによってホストされているVMにインストールできる一連のユーティリティであるVMware Toolsを介して適用されます。この機能はVSSを起動してVM用のアプリケーション整合性のあるスナップショットを作成します。これは単一のVMを持つ整合性グループに限定されます。

スナップショットは、定義されたスケジュールまたは必要に応じて作成できます。作成されたすべてのスナップショットは有効期限に関連付けられており、有効期限が過ぎるとNutanixクラスタは自動的にスナップショットを削除します。重要ではないVMファイル(スワップファイルやログファイルなど)はスナップショットに含まれません。 

6.データ保護の概念
データ保護に関してはこちらのような概念があります。それぞれに関しての説明を行いたいと思います。

  • 保護ドメイン
保護ドメインについては⾮同期DRとMetroAvailabilityの2種類でドメインが存在することを覚えて頂ければと思います。

保護ドメイン(非同期DR):標準保護ドメインは、クラスター上でローカルにバックアップされ、オプションで1つ以上のリモートサイトに複製された定義済みのVMのグループです。このタイプの保護ドメインは、スナップショットを作成するために非同期データ複製Async D)を使用します。
保護ドメイン名はサイト間で一意である必要があります。 VMは最大1つの保護ドメインに属することができます。クラスタ上の保護ドメインは、次の2つのモードのいずれかにあります。 

アクティブ:稼働中のVMを管理します。スナップショットを作成、複製、およびExpireします。 
非アクティブ:リモートクラスタからスナップショットを受け取ります。 

保護ドメイン(メトロ可用性):メトロ可用性保護ドメインは、メトロ可用性が有効になっているときに同期データ複製が行われるリモートサイトの同じ名前の(スタンバイ)コンテナにリンクされたローカルクラスタの指定(アクティブ)コンテナで構成されます。 
  • 整合性グループ
整合性グループは、保護ドメイン内のVMのサブセットです。 (保護ドメインを作成するときに整合性グループが構成されます)。その保護ドメインのコンシステンシグループ内のすべてのVMは、クラッシュコンシステントな方法でスナップショットを取られます。コンシステンシグループ内のすべてのVMに対して、スナップショットはグループ内のすべてのVMに対して1つのスナップショットを作成します。 

データ保護を⾏う上で重要なのは、スナップショットを取ったデータが整合性を保っていることが重要です。リストア後に整合性が保った状態に戻すのはアプリケーション次第ではあるが、クラッシュコンシステントのバックアップで停電後でも仮想マシンの電源⼊れている状態に戻せるようにしておきましょう。仮想マシンには必ずNGT(Nutanix Guest Tools)を⼊れておきましょう。
  • スナップショット
スナップショットについては、特に説明する内容はほとんどないので、画⾯イメージを載せておきます。
  • タイムストリーム
タイムストリームについても、スナップショットと同様のお話ですので、画⾯イメージを掲載のみです。
  • タイムストリーム
リモートサイトは、バックアップデータを複製するためのターゲットの場所として使用される独立したクラスタです。リモートサイトは、別の物理クラスタまたはパブリッククラウドにあるクラスタのどちらでもかまいません。 1つのクラスタに1つ以上のリモートサイトを設定できます。 
  • レプリケーション
レプリケーションとは、スナップショットを1つのクラスタから1つ以上のリモートサイトに非同期的にコピーするプロセスです。いくつかのレプリケーションシナリオがサポート
レプリケーションについては、1つもしくは複数サイトにレプリカを作成することができます。注意事項としては、マルチサイトで複製取る場合には、ライセンスのエディションにご注意下さい。(UltimateもしくはPro Edition選択時はオプションのライセンスが必要になります)
  • スケジュール
スケジュールは、スナップショットをとる間隔とスナップショットを保持する期間を指定する保護ドメインの特性です。 (保護ドメインを設定するときにスケジュールが設定されます)。スケジュールは、どのリモートサイトに複製するかをオプションで指定します。 
スケジューリングについては、⾮同期DRについては間隔が短い場合はNear Syncになりますので、その場合は仕様も含めて確認してから設定してください。

本⽇のデータ保護の説明は以上とさせて頂きます。
次回は、複製の⽅式についてご説明したいと思います。

よろしくお願い致します。















2021年7月11日日曜日

Nutanixにおけるハイパーバイザーの変換プロセスについて

みなさん、こんにちは

本日投稿の内容について、以前別サイトで私が投稿したブログの内容です。
サイトの閉鎖に伴い、こちらで再度掲載いたします。

今回はNutanixのハイパーバイザーの変換プロセスについてご紹介します。

NutanixではハイパーバイザーをESXiからAHVへの変換することができます。
ハイパーバイザーを変換する際のプロセスがいくつかあるので覚えて頂ければと思います。

1. ESXiからAHVへの変換について
変換プロセスを開始すると、クラスタ内のすべてのノードが1つずつAHVに変換されます

ESXiホストの現在の状態は、ESXiに戻すために保存されます。Foundation内部でESXiホストをAHVに変換します

最初に、すべてのコントローラーVMがAHVに移行されます。コントローラVMがAHV側で起動した後、ESXiで実行されているVMはAHVに移行されます

仮想マシンの移行が完了したら、AHVで仮想マシンを手動で起動する必要

すべてのホストと仮想マシンがAHVに移行されたら、AHVクラスターの使用を開始します。

2. 仮想マシンの変換
ハイパーバイザーの変換ということはつまり仮想マシンも変換することになります。
そのため、仮想マシンにNGT(Nutanix Guest Tools)をインストールして変換を開始すると、仮想マシンの変換も同時に行われます。変換プロセスは以下のようになります。

①検証
クラスタ内の仮想マシンが変換可能かどうか検証します。
②起動
変換を⾏います。変換のプロセスは記録されます。
③仮想マシン変換ためのノードを準備
ノード内の仮想マシンの情報はノードのUUIDに応じて収集され、仮想マシンが保護されているときには変換はできません。仮想マシンはマスター変換レコードに格納されていて、仮想マシンファイルは変更されません。
④仮想マシンの変換を実⾏
ノードの変換レコードを参照して、ハイパーバイザータイプを⽐較して、変換先のハイパーバイザーに変換します。仮想マシン変換後は仮想ネットワークなどもハイパーバイザーの情報に合わせて変換を⾏います。変換が完了すると変換元の仮想マシンファイルは削除されます。

3. ポートグループとVLANの変換およびAHVからESXiへの変換について
ポート仮想マシン変換ためのノードを準備
特定のグループに属するすべてのESXiポートグループ、すべてのVLAN ID、および仮想マシンがキャプチャされ、クラスタ上のすべての一意のESXiポートグループに対応するAcropolis仮想ネットワークが作成され、対応するVLAN IDが割り当てられてからVM正しい仮想ネットワークに転送されます。 

ESXiホストの管理ポートグループにVLANが設定されている場合は、変換後にAcropolis管理インターフェースとController VMパブリックインターフェースが同じVLANに配置されます。 

AHVからESXiへの変換プロセス
逆方向の変換(AHVからESXiへの変換)の間、変換のプロセスは類似しています。
また、クラスタにESXi ISOが保存されていない場合は、変換プロセス中にESXi ISOイメージを提供する必要があります。

注:提供するイメージは、ESXiからAHVへの変換中に使用したものと同じ主要なESXiバージョンのものである必要があります。

4. クラスタ変換作業の中止について
クラスタ変換作業も必ず成功するわけではありません。失敗してしまった時に戻せなくなるのではないかと⼼配する⽅もいらっしゃるかと思いますが、Nutanixの変換作業で失敗したときは失敗した内容のポップアップが表⽰されます。こちらで元の環境に戻すかどうか聞かれるので、「Yes」をクリックすると元の環境に戻すことが可能です。

ハイパーバイザーの変換は通常の変換作業以外にも、DR先にレプリケーションする時もクロスハイパーバイザーでDRするときも同様のことが⾏われます。

以上、参考情報として読んで頂ければと思います。
よろしくお願い致します。

2021年7月10日土曜日

Nutanixの障害シナリオについて学んでみよう!

みなさん、こんにちは

本日投稿の内容について、以前別サイトで私が投稿したブログの内容です。
サイトの閉鎖に伴い、こちらで再度掲載いたします。

今回はNutanixの障害シナリオについてご紹介します。

Nutanixはハードウェアおよびソフトウェアで構成されておりますが、ホストなどのハードウェアが障害があるケース、CVMなどのソフトウェアの障害またはネットワークなどの障害により挙動が違ってきます。今回はその想定される障害シナリオについていろいろとお話したいと思います。

1. 障害シナリオについて
上記イメージを見て頂ければと思いますが、この中で、⾼密度型で導⼊していないお客様については、ブロックに関する障害はあまり関係ありませんが、どのようなケースなのかを覚えて頂くことも良いかもしれません。

2. ノード障害について(コントローラVMの障害)
ノード障害は物理障害であるため、ホスト・CVMの両コンポーネントがアクセスできなくなります。そのため、正常な物理ホストのみでクラスタを構成できるようになります。
こちらのスライドはその障害判断プロセスを記載しています。
実際に障害あった場合、ユーザはどのようにして気が付くのでしょうか︖それを以下に記載します。

ユーザーには何が通知されるのでしょうか︖
切り替え処理中に障害が発⽣したコントローラVMを持つホストは、共有ストレージが使⽤できないと報告 することがあります。このホスト上のゲストVMは、ストレージパスが復元されるまで「ハング」しているように⾒えます。ゲストVMデータのプライマリコピーは、障害が発⽣したコントローラVMにマップされたディスクに格納されているため使⽤できませんが、そのデータのレプリカにはまだアクセス できます。リダイレクトが⾏われるとすぐに、VMは読み取りと書き込みを再開できます。
I/Oが内部ネットワークを経由するのではなく、ネットワークを介して移動しているため、パフォーマンスがわずかに低下する可能性があります。すべてのトラフィックが10GbEネットワークを通過するため、 ほとんどのワークロードはユーザーに認識されるようには減少しません。

別のノードが障害になった場合はどうなりますか︖
2番⽬のコントローラVMの障害は他のホストのVMにも同じ影響を与えます。つまり、2つのホストがネットワークを介してI/O要求を送信します。しかし、さらに重要なことは、ゲストVMデータに追加のリスクがあることです。2つのコントローラVMを使⽤できないため、アクセス不能な2つの物理ディスクセットが存在するようになりました。RF2を持つクラスタでは
少なくとも1つのコントローラVMが動作を再開するまで、⼀部のVMデータエクステントが完全に⽋落する可能性があります。

3. ノード障害について(ホスト障害)
ホスト障害時の挙動についてはこちらをご覧ください。
ノード障害が発⽣すると、他のノードでVMが再起動しますが他のノードにデータが存在していれば、問題なくデータにアクセスすることができます。ただし、3ノードで構成した場合は、障害時は正常なクラスタではありませんので、早急に復旧が必要になります。

ユーザーには何が通知されるのでしょうか︖
HA保護されたVMにアクセスしているユーザーは、新しいホストでVMを再起動している間はそのVMを 使⽤できないことに気付きます。HAなしでは、VMを⼿動で再起動する必要があります。

別のノードが障害になった場合はどうなりますか︖
2番⽬のホストの障害により、残りのホストの処理能⼒が不⼗分になり、2番⽬のホストからVMを再起動 する可能性があります。ただし、負荷の軽いクラスタであってもゲストVMデータに対する追加のリスクが懸念されます。
アクセス不能な2組の物理ディスクを使⽤すると、⼀部のVMデータエクステントが完全に失われる可能性があります。

4. ドライブ障害について
ドライブには起動⽤の領域のブートドライブ、階層化データやOplog(書き込みデータ)がSSDおよびHDDなどのデバイスに格納されています。
コールド層の永続データは、ノードのハードディスク・ドライブに格納されます。ストレージメタデータ、ホットプラグ、ホットティア永続データ、コントローラVMブートファイルは、ドライブベイ1のSATA-SSDに保存されます。2つのSATA-SSDを搭載したシステムでは、追加のホット層DSFデータストレージに2台目のドライブを使用します。
オールフラッシュノードでは、すべてのタイプのデータがSATA-SSDに格納されます。

ブートドライブの障害
各コントローラVMはSATA-SSDもしくは2枚のM.2 SSDを利用して起動します。かつてはブートドライブの冗長化はされていなかったのですが、最近はRAID1構成の冗長化になっていることから、1枚のM.”デバイスの障害に耐えられる構成になっています。
クラスタの運用中は、このドライブにもコンポーネントログと関連ファイルが保存されます。
ブートドライブの故障により、最終的にはコントローラVMが異常終了します。ホストはブートドライブに直接アクセスしないため、他のゲストVMは引き続き実行できます。データパス冗長性は、ストレージパスを別のコントローラVMにリダイレクトします。


メタデータドライブの障害
メタデータドライブは多くの目的に役立ちます。各ホストのoplogを保持し、書き込み要求を送信するVMに高速応答を提供します。永続データ層として使用されます。また、Cassandraデータベースはクラスタメタデータに対する高速な読み書き応答を提供するためにも使用されます。これらのストレージ使用はすべて障害の可能性を考慮して設計されているため、クラスタ内の他のメタデータディスクに複製されます。
メタデータドライブ(SSD)とデータドライブ(HDD・オールフラッシュ構成はSSD)については、クラスタ全体で複製されているため、単⼀障害では特に影響できることはありません。

メタデータドライブに障害が発生した場合、問題を認識する最初のコンポーネントはCassandraです。

データベースのシェアにアクセスできなくなり、問題を解決するための再起動の継続的なサイクルが開始されます。

StargateはMedusaを通じてCassandraと依存関係にあるため、最終的にStargateは障害を起こしたことをクラスタによって検出され、パスはデータパスの冗長性に基づいて自動的にリダイレクトされます。 まもなく、障害があったメタデータドライブを持つホストは、ネットワーク経由で別のStargateに リダイレクトされます。

Cassandraプロセスがノードで5分以上ダウンした場合、残りのCassandraノードはCassandraデータベースからノードを切り離し、使用できないメタデータを他のノードに複製することができます。データベースを修復するプロセスは約30〜40分かかります。

Cassandraプロセスが再起動して5分間継続した場合、回復手順がまだ実行中の場合、ノードを切り離す手順はキャンセルされます。回復手順が完了してからプロセスが再開し安定した場合、nCLIコマンドを使用してノードを手動でデータベースに追加できます。

ncli> host enable-metadata-store id = cvm_id 

ユーザーには何が通知されるのでしょうか︖
スイッチング処理中に障害が発⽣したSSDのホストは、共有ストレージが使⽤できないと報告することがあります。このホスト上のゲストVMは、ストレージパスが復元されるまで「ハング」するように⾒えます。
リダイレクトが⾏われるとすぐにVMは読み取りと書き込みを再開できます。I/Oが内部ネットワークを経由するのではなく、ネットワークを介して移動しているため、パフォーマンスがわずかに低下する可能性があります。すべてのトラフィックが10 GbEネットワークを経由するため、ほとんどのワークロードはユーザーに認識されるようには減少しません。

別のノードが障害になった場合はどうなりますか︖
2番⽬のメタデータドライブの障害は、他のホスト上のVMにも同じ影響を与えます。つまり、2つのホストがネットワークを介してIO要求を送信します。
Cassandra Ringの回復機能は、第2の障害が回復プロセスが完了する前に起こらない限り、第2のノードを失うことに伴うリスクを軽減する。


データドライブの障害
各ノードはデータ・ドライブをクラスター・ストレージ・プールに提供します。
コールドデータはHDDに保存され、ホットデータはSSDに保存されて高速のパフォーマンスが得られます。
HDDには可動部品があり、他のハードウェアコンポーネントを上回っているため、故障が発生する可能性が最も高いコンポーネントです。データはクラスタ全体に複製されるため、単一のハードディスクドライブに障害が発生してもデータが失われることはありません。オールフラッシュノードでは、すべてのタイプのデータがSSDに格納されます。
クラスタソフトウェアは、ホストからデータドライブ(HDDまたはSSD)に障害が発生したハードウェアアラートを受信し、直ちに作業を開始して2回目の障害の影響を軽減します。Curatorはドライブに格納されているゲストVMデータの2番目のレプリカを作成するようにStargateに指示します。

5.ネットワークリンクの障害
各ホストの物理ネットワークアダプタは外部ネットワーク上でグループ化されています。両方の10GbEポートが顧客のネットワークに接続されている場合、ネットワークリンクの障害はユーザーに影響を与えずに許容されます。クラスタが1GbEリンクにフェイルオーバーする必要がある場合、書き込みパフォーマンスは低下します。
Nutanixを構成する際はほとんど10GbEの構成になると思いますので、現状気にする必要はないと考えられます。

6. ブロックフォールトトレランスについて
ブロックフォールトトレランスはNutanixクラスタが任意のデータの冗長コピーを作成し、同じブロックにないノードにデータを配置する機能です。また、メタデータはブロックフォールトトレラントでなければ ならない。

ブロックは、 1〜4個の2U4Nのノードを含むラックマウント型筐体です。電源装置、フロントコントロールパネル、バックプレーン、およびファンは、ブロック内のすべてのノードで共有されます。

ブロックフォールトトレランス機能を有効にすると、ゲストVMデータとメタデータの冗長コピーが他のブロックに存在するため、ゲストVMはブロック障害を発生したまま実行されます。

特定の条件が満たされると、Nutanixクラスタはブロックフォールトトレラントになります。ブロックフォールトトレランス機能は、クラスタ内の各ストレージ階層には、各ブロックに少なくとも1つのドライブが含まれています。
クラスタ内のすべてのストレージコンテナには、少なくとも2つのレプリケーションファクタがあります。

RF2の場合、クラスタには最低3つのブロックがあります。
クラスター内の少なくとも複製ファクター数のブロックには、すべての層に十分な空き領域があります。 例えば、クラスタ内のストレージコンテナのレプリケーションファクタが2である場合、少なくとも2つの ブロックに空き領域が必要です。
Eraser Codingは、どのストレージコンテナにおいても有効にしてはいけない。
(AOS5.8よりブロック環境においてもEraser Codingをサポート)

ブロックフォールトトレランスの状態は、Prism Web ConsoleおよびNutanix CLIで表示できます。
管理者はストレージ階層またはストレージコンテナを設定する必要がありますが、データの移行先は特定できません。AOSはデータの移行先を決定します。

ブロックフォールトトレランス条件が満たされると、クラスタは特定の数のブロック障害に耐えられます。
  • 3つ以上のブロックを有するRF2またはRF3 クラスタは、1つのブロックの最大障害を許容することができる。
  • 5つ以上のブロックを有するRF3クラスタは、2つのブロックの最大障害を許容することができる。
ブロックフォールトトレランスはResiliencyの一部です。インフラストラクチャのかなりの部分が利用できない状況では、ディスク領域とCPU /メモリリソースの可用性などの他の制約は取り除かれません。

ブロックのフォールトトレランスには、メタデータのブロック認識が必要です。RF2およびRF3に対してメタデータ ブロックのAwareness機能を有効にすることができます。メタデータブロックのフォールトトレランス機能を有効にするには、メタデータが上記のReplication Factorの要件を満たしている必要があります。

7. ブロックフォールトトレラントデータ配置
Stargateはブロック間でデータを配置する役割を果たし、CuratorはStargateにデータ配置要求を行いブロック耐障害性を維持します。
新しいクラスタと既存のクラスタは、ブロックフォールトトレラントな状態になります。新しいクラスタは構成がサポートしていれば、作成直後にフォールトトレラントにすることができます。以前はフォールトトレラントではなかった既存のクラスタは、ブロックフォールトトレランスをサポートする方法でクラスタを再構成することで耐性を持たせることができます。
ブロックフォールトトレラントクラスタ内の新しいデータは、ブロックフォールトトレランスを維持するために配置されます。ブロック耐障害状態にない既存のデータは、キュレーターによってブロックフォールトトレラント状態に移動およびスキャンされます。
再配置が必要なデータの量に応じて、ブロック間でデータを配信するために、キュレーターが数時間にわたって複数のスキャンを実行することがあります。
ブロックフォールトトレラントデータ配置はベストエフォートベースで行われますが保証はされません。ブロック間のディスク使用率が高いなどの条件により、クラスタがゲストVMの冗長コピーデータを他のブロックに配置できなくなる可能性があります。

以下にわかりやすいイメージを載せておきますので、参考にして頂ければ幸いです。

メタデータ/構成データ
Nutanix MedusaコンポーネントはCassandraを使用してメタデータを格納します。Cassandraはリング内のピアにデータをコピーしてデータの一貫性と可用性を確保するリング型の構造を採用しています。クラスタはメタデータの少なくとも3つの冗長コピーを保持します。少なくとも半分は一貫性を確保するために利用可能でなければなりません。

ブロック・フォールト・トレランスでは、Cassandraのピアはブロック間に分散され、同じブロックに2つのピアが存在
しないようにします。ブロックに障害が発生した場合、少なくとも2つのメタデータのコピーがクラスタに存在します。

Nutanix Zeusコンポーネントは、Zookeeperを使用してクラスタの必須の構成データを格納します。Zookeeperの役割はブロックに障害が発生した場合の可用性を確保するためにブロック間で分散されます。

8. Redundancy Factor3
Redundancy Factor3はNutanixクラスタが2つのノードまたは異なるブロックのドライブの障害に耐えることを可能にする構成可能なオプションです。
デフォルトではNutanixクラスタはRedundancy Factor2を持ちます。つまり、単一のノードまたはドライブの障害を許容することができます。クラスタが大きいほど、複数の障害が発生する可能性が高くなります。Redundancy Factor3が
ないと複数の障害が発生すると、障害が修復されるまでクラスタが使用できなくなります。

Redundancy Factor3には次の要件があります。
  • クラスタにはRedundancy Factor3を有効にするために、少なくとも5つのノードが必要
  • ゲストVMが異なるブロック内の2つのノードまたはドライブの同時障害を許容するには、RF33のストレージコンテナにデータを格納する必要
  • コントローラVMは少なくとも24GB以上のメモリで構成する必要があります。
Redundancy Factor3のイメージ

メタデータ/構成データ
メタデータの冗長コピーの少なくとも半分は、一貫性を確保するために利用可能でなければなりません。 Redundancy Factor3がない場合、クラスタはメタデータの3つのコピーを保持します。 Redundancy Factor3の場合、クラスタは5つのメタデータを保持し2つのノードに障害が発生した場合、少なくとも3つのコピーが使用可能になります。

Nutanix Zeusコンポーネントは、Zookeeperを使用してクラスタの必須の構成データを格納します。 Redundancy Factor3がない場合、クラスタは構成データの3つのコピーを保持します。 Redundancy Factor3の場合、クラスタは構成データのコピーを5つ保持し2つのノードに障害が発生した場合、少なくとも3つのコピーを使用できるようにします。

9. 劣化ノード (Degrade Node)
劣化ノードには、完全に応答しない状態ではないCVMが含まれていますが、正常なクラスタ操作を確実に実行することはできません。劣化した(または部分的に利用可能な)ノードはクラスタ全体のパフォーマンスに悪影響を及ぼします。 劣化ノード検出は、劣化ノードの結果を軽減するために導入されています。劣化ノードを継続して実行するとクラスタ 全体とユーザーVMのパフォーマンスに影響を与える可能性があります。劣化したノード検出を有効にすることにより、ZooKeeperはノードをメンテナンスモードにします。メンテナンスモードではノードをリーダーシップの位置から移動し、タスクを自動的に配布します。

劣化したノードのアラートは、Webコンソールの[アラート]ページに表示されます。

以下のイベントは、ノードの劣化に寄与する可能性があります。
  • ネットワーク帯域幅の削減
  • ネットワークパケットドロップ
  • ソフトロックアップ
  • 部分的に不良なディスク
  • ハードウェアの問題(ECCエラーのある信頼性の低いDIMMなど)
劣化ノード検出は、ピア正常性グローバルデータベースで構成されます。これらのサービスは、クラスタの各ノードで実行されます。各ノードは、他のノードで実行されているサービスに対してスコア発行。ピア・スコアは、次のようなメトリックを評価します。

リモートプロシージャコール(RPC)の待ち時間
RPCの失敗またはタイムアウト
ネットワーク待ち時間

1つのノードが約10分間低いスコアを一貫して受信した場合、ピアはそのノードを劣化ノードとしてマークします。

クラスタリングアルゴリズムは、異常値を識別するために使用されます。

劣化ノードの検出
ノードが不良ピアスコアを受信し始めたときに、Webコンソールはユーザーに警告します。数分のスコアが悪いとノードは劣化しているとマークされます。
劣化したノード検出ソフトウェアは、障害の影響を緩和しクラスタ全体への影響を軽減します。影響を軽減するために、このソフトウェアは次のいずれかの操作を実行できます。プロンプトが表示されたら、
次のいずれかを選択します。
  • 劣化したノードのコンポーネントがリーダーシップの役割を獲得できないようにする
  • 劣化ノードCVMを保守モードにしてCVMを再起動し、サービスを停止します
  • ホストをシャットダウンする
劣化ノードの検出の有効化
Webコンソールで劣化したノード検出設定を有効にします。
  1. クラスタのWebコンソールにログインします。
  2. ページの隅にある歯車のアイコンをクリックします。
  3. Degraded Node Settingsをクリックします。劣化ノード設定ウィンドウが表示されます。
  4. 劣化ノードの検出ステータスを「縮退ノード検出を有効にする」に設定します。 
    チェックボックスをオンにすると、劣化ノードの検出が有効になります。
    それ以外の場合は、劣化ノードの検出を無効にする場合は、ボックスをクリアしてください。
  5. [保存]をクリックして設定を確定します。劣化ノード設定ウィンドウが閉じて、Webコンソールには、ポップアップの 確認が表示されます。
  6. アラートポリシーを更新し、アラートを有効または無効にするには:
    1.Webコンソールで、[アラート]をクリックします。
    2.縮退ノードをクリックすると縮退ノードウィンドウが表示されます。
    3.可能な劣化ノードのサイドバー、クリック可能な劣化のノードを。ノードは、数分間の不良ピア・スコアを受信した後、劣化とマークされます。
    4.Update Policyポップアップが表示されます。
    5.ポリシーを更新し、[保存]をクリックします。チェックボックスをオンにしてポリシーを有効にします。
    6.チェックボックスをオフにしてポリシーを無効にします。
非常に長い文章になってしまいましたが、障害シナリオの紹介でした。

以上、よろしくお願い致します。








2021年7月9日金曜日

Nutanixのクラスタの コンポーネントを覚えてみよう︕

みなさん、こんにちは

本日投稿の内容について、以前別サイトで私が投稿したブログの内容です。
サイトの閉鎖に伴い、こちらで再度掲載いたします。

今回はNutanixのクラスタのコンポーネントをご紹介します。

今回の内容については、Nutanix Bible(http://nutanixbible.jp/)にも記載している内容になりますが、実際には単語レベルでの説明はあるものの各プロセスについての詳細に書かれていないため、筆者が理解できるようにいろいろとまとめてみました。
Nutanixクラスターには分散アーキテクチャーがあり、クラスター内の各ノードはクラスタリソースおよびその重要性を共有しています。各ノードにはクラスタ操作中に特定のタスクを実⾏するソフトウェアコンポーネントがあります。
すべてのコンポーネントは、クラスタ内の複数のノードで実⾏され、コンポーネントを実⾏する役割の間で接続が依存しています。ほとんどのコンポーネントは、他のコンポーネントにも依存しています。

Zeus
分散システムの重要な要素は、すべてのノードがクラスターの構成を保管して更新します。内容はホストやディスクなどのクラスタ内の物理コンポーネント、およびストレージコンテナなどの論理コンポーネントに関する詳細が含まれます。
これらのコンポーネントの状態(IPアドレス、容量、データ複製ルールなど)もクラスタ構成に格納されます。
Zeusは他のすべてのコンポーネントがクラスタ構成にアクセスするために使⽤するNutanixライブラリです。現在、Apache Zookeeperを使⽤して実装されています。

Cassandra
CassandraはNutanixデータストアに格納されているゲストVMデータに関するすべてのメタデータを格納している分散型の⾼性能でスケーラブルなデータベースです。NFSデータストアの場合、Cassandraはデータストアに保存された⼩さなファイルも保持します。ファイルのサイズが512Kに達すると、クラスタはデータを保持するvDiskを作成します。
Cassandraはクラスタのすべてのノードで実⾏されます。これらのノードはGossipプロトコルを使⽤して1秒に1回、互いに通信し、データベースの状態がすべてのノードで最新であることを保証します。
CassandraはZeusに依存して、クラスタ構成に関する情報を収集します。

ZooKeeper
Zookeeperはクラスタに適⽤される冗⻑度に応じて、3つ(RF2)または5つ(RF3)のノードで実⾏されます。複数のノードを使⽤すると失効したデータが他のコンポーネントに返されるのを防ぎます。⼀⽅、奇数を使⽤すると、2つのノードが異なる情報を持つ場合に繋ぎを解除する⽅法が提供されます。
これらの3つのノードのうち、1つのZooKeeperノードがリーダーとして選出されます。リーダは情報の要求をすべて受信し、2つのフォロワノードに付与します。リーダーが応答を停⽌すると、新しいリーダーが⾃動的に選出されます。
Zookeeperには依存関係がないため、他のクラスタコンポーネントを実⾏しなくても起動できます。
Medusa
他のシステム(仮想マシンをホストするハイパーバイザーなど)のデータを格納する分散システムには、そのデータの格納場所を把握する⽅法が必要です。
Nutanixクラスタの場合、そのデータのレプリカが格納されている場所を追跡することも重要です。
Medusaは、このメタデータを保持するデータベースの前に存在しているNutanixの抽象化レイヤーです。データベースは、Apache Cassandraの変更された形式を使⽤して、クラスタ内のすべてのノードに分散されます。

Stargate
他のシステム(ハイパーバイザなど)にストレージを提供する分散システムでは、受信するデータを受信し処理するための統合コンポーネントが必要です。
Nutanixクラスタには、この責任を管理するStargateという⼤きなソフトウェアコンポーネントがあります。
ハイパーバイザーの視点からStargateはNutanixクラスターの主要な接点です。すべての読み取りおよび書き込み要求は、NutanixのvSwitchを介して、そのノード上で実⾏されているStargateプロセスに送信されます。
Stargateはメタデータを収集するMedusaとクラスタ構成データを収集するZeusに依存します。

Curator
分散システムではプロセス全体を監視するコンポーネントを持つことが重要です。未使⽤のデータブロックを指すメタデータが蓄積されたり、ノード間またはディスク階層間でデータのアンバランスが発⽣する可能性があります。
Nutanixクラスタでは、各ノードがこれらの責任を扱うCuratorプロセスを実⾏します。Curatorのマスターノードは、メタデータデータベースを定期的にスキャンし、スターゲイトまたは他のコンポーネントが実⾏すべきクリーンアップおよび最適化タスクを識別します。メタデータの分析は、MapReduceアルゴリズムを使⽤して他のCuratorノード間で共有されます。
Curatorはどのノードが利⽤可能であるかを知るためにZeusに依存し、メタデータを収集するためにMedusaを使⽤します。その分析に基づいて、Stargateにコマンドを送信します。

Prism
ユーザーがアクセスできない場合、分散システムは役に⽴たない。Prismは管理者がNutanixクラスタを構成および監視するための管理ゲートウェイを提供します。
これには、nCLIおよびWebコンソールが含まれます。
Prismはクラスタ内のすべてのノードで動作し、他のコンポーネントと同様に、リーダーを選択します。すべてのリクエストは、Linux ip tablesを使⽤してフォロワーからリーダーに転送されます。これにより、管理者は任意のコントローラVMIPアドレスを使⽤してPrismにアクセスできます。Prismリーダーが失敗した場合、新しいリーダーが選出されます。
Prismはクラスタ構成データ⽤にZeusと通信し、統計情報はユーザーに提⽰するためにCassandraと通信します。また、VMステータスおよび関連情報についてESXiホストと通信します。

少し難しい内容になっておりますが、Nutanixの重要なコンポーネントであるため、今後Nutanix Bibleを読むときに役⽴てて頂ければ幸いです。

以上、よろしくお願い致します。

2021年7月8日木曜日

Nutanixで利用可能なCLI(Command Line Interface)を覚えてみよう!

みなさん、こんにちは

本日投稿の内容について、以前別サイトで私が投稿したブログの内容です。
サイトの閉鎖に伴い、こちらで再度掲載いたします。

今回はNutanixで利用可能なCLI(Command Line Interface)をご紹介します。

普段Nutanixを運⽤する場合、Prismを利⽤してGUI上で操作することが多いと思います。
実際にたくさんの処理を実行するためにコマンドを利用したい人や⾃動化したい⼈などはどうしてもCLIが必要になります。Nutanixには複数CLIインタフェースが提供されており、運用者の使い勝手で選択することができます。
CLIの関する使い方も含めてご説明します。

1. Nutanixで利用可能なCLIについて
NutanixのCLIは以下の3つが用意されています。
  • nCLI (Nutanix CLI)︓Nutanixのクラスタ(AOS)に対してコマンドで操作できます。主にクラスタやコンテナの情報の参照・設定などを⾏うときに利⽤します。
    (利⽤する場合はJREのインストールが必須になります)
  • aCLI (Acropolis CLI)︓AHVのハイパーバイザーに対してコマンドで操作できます。仮想マシンや仮想ネットワークおよびイメージやサービスに関する内容を設定・変更するときに利⽤します。
  • PowerShell Cmdlets︓Nutanixのクラスタに対してコマンドで操作できます。nCLIと同様の操作が可能です。(利⽤する場合は、Windows環境が必須になります)
また、CLIを利⽤する場合はCVMなどに直接ログインすることで利⽤することは可能ですが、root権限でオペレーションしてシステムをおかしくすることも考えられます。そのため、どうしても利⽤する場合は、リモートの端末に必要なツールをインストールして利⽤することをお薦めします。

aCLIについては、AHVにログインせずCVM経由でSSHでログインするで利⽤可能です。【192.168.5.1のアドレスでrootでログインすることで利⽤します】

コマンドラインでシステム停⽌もできますが、コマンドの打ち間違いで正常終了しないようなオペレーションしないためにも、通常はPrismでのオペレーションをお願いします。

2. Nutanix Command Line Interface(nCLI)について
Nutanixコマンドラインインターフェース(nCLI)を使⽤すると、次のいずれかのマシンからNutanixクラスターに対してシステム管理コマンドを実⾏できます。
  • ローカルマシン(推奨)
  • クラスタ内の任意のコントローラVM
ローカルマシンへのインストールを推奨しているのは、CVMに対してログインせずにIPアドレスなどの引数で操作ができます。これにより、クラスター全体にローカルマシンから操作できるようになります。

3. nCLIのインストール
  1. ローカルマシンから利⽤するJavaRuntime Environment(JRE)のバージョンが5.0以上であることを確認最新版はこちら(http://www.java.com/en/download/installed.jsp)からダウンロード可能です

  2. nCLIをダウンロードします
    ・Nutanix Webコンソールに接続します
    ・コンソール上部のユーザーアイコンをクリックし、[Download nCLI]を選択
    ・ローカルマシンにインストールします

  3. Windowsの%PATH%またはLinuxの$ PATH環境変数を設定します
    ・ncliディレクトリ(例︓c:\ncli)
    ・JRE binディレクトリ(例︓c:\ProgramFiles\Java\jrexxxx\bin)
4. ローカルマシンからnCLIセッションを開始
ローカルマシンへのnCLIのインストール⼿順に従って、ローカルシステムにnCLIをインストールします

  1. ローカルマシンでコマンドプロンプトを開きます(Linuxの場合はbash、Windowsの場合はCMDなど)

  2. コマンドプロンプトで、次のいずれかのコマンドを使用してnCLIを起動

    lncli -s management_ip_addr -u' username ' -p ' user_password ‘
    この場合、コンソールにパスワードが表⽰されます

    lncli -s management_ip_addr -u ' ユーザー名 ' –p
    この場合、パスワードを指定するように求められます

  3. management_ip_addrをクラスタ内のNutanixコントローラVMのIPアドレスに置き換えます

  4. usernameをユーザーの名前に置き換えます(指定されていない場合、デフォルトはadminです)

  5. (オプション)user_passwordをユーザーのパスワードに置き換えます

5. コマンドフォーマット
Nutanixのコマンドラインインターフェースコマンドは、次の形式と一致する必要があります
ncli> entity action parameter1=value parameter2=value ... 

エンティティはクラスタやディスクなどのNutanixエンティティに置き換えることができます。アクションは前のエンティティに対する有効なアクションに置き換えることができます。各エンティティには固有の一連のアクションがありますが、すべてのエンティティに共通のアクションはlistです。

たとえば、次のコマンドを入力してクラスタ内のすべてのストレージプールのリストを要求できます
ncli> storagepool list 

一部のアクションではコマンドの最後にパラメータが必要です。たとえば、NFSデータストアを作成するときは、 ハイパーバイザーに表示されるデータストアの名前とソースストレージコンテナの名前の両方を指定する必要があります。

ncli> datastore create name = "NTNX-NFS" ctr-name = "nfs-ctr" 

パラメータと値のペアは、有効なエンティティとアクションが先行している限り、任意の順序で並べることができます。

6. 埋め込みのヘルプ
nCLIは、すべてのエンティティおよびアクションに対する支援を提供します。helpコマンドラインで入力することで、3つの詳細レベルのいずれかで追加情報を要求できます。 

help
エンティティとそれに対応するアクションのリストを提供します

entity help
エンティティに関連付けられているすべてのアクションとパラメータ、および必須のパラメータと任意のパラメータの一覧を提供します

entity action help
アクションに関連付けられているすべてのパラメータのリスト、および各パラメータの説明を提供します

nCLIは各レベルで追加の詳細を提供します。nCLIヘルプ出力の範囲を制御するには詳細パラメータを 追加します。詳細パラメータは、trueまたはfalseに設定できます。
たとえば、clusterエンティティのすべてのアクションとパラメータの詳細な一覧を要求するには、次のコマンドを入力

ncli> cluster help detailed = true 

説明なしでcluster edit-paramsアクションのパラメーターのリストを表示する場合、次のコマンドを入力することも可能

ncli> cluster edit-params help detailed = false 

nCLIのエンティティの詳細はNutanix Support Portalのコマンドリファレンスをご参照下さい

7. Acropolis Command-Line Interface(aCLI)
Acropolisは、ホスト、ネットワーク、スナップショット、VMを管理するためのコマンドラインインターフェースを提供します

Acropolis CLIへのアクセス
Acropolis CLIにアクセスするには、SSHでクラスター内のController VMにログオンacliし、シェルプロンプトで⼊⼒
Acropolis CLIを終了してシェルに戻るには、<acropolis>プロンプトでexitと⼊⼒します

8. PowerShell Cmdlets
Nutanixはクラスターと対話するためのPowerShellのCmdletsを提供しています
CmdletsはNutanix クラスターからダウンロードされ、Windowsマシンにインストールされます。Cmdletsがインストールされたら、Nutanix CmdletsをクリックするとデスクトップのショートカットがロードされNutanix CmdletsがPowerShellウィンドウで起動します

PowerShell Cmdletsのインストール
利⽤する前に
PowerShellバージョン2以降および.NET Framework 4.0をワークステーションにインストールします
  1. Nutanix Webコンソールにサインイン
  2. Webコンソールの右上隅にあるユーザーアイコンをクリックして、[Download Cmdlets Installer]を選択
  3. インストーラのダウンロードが完了したら、インストーラをダブルクリックして プロンプトに従います。コマンドレットがインストールされ、デスクトップショート カットNutanix Cmdletsが作成されます。ショートカットをダブルクリックして、Nutanix CmdletsがロードされたPowerShellウィンドウを起動します
9. PowerShell Cmdletsの使用方法

クラスタ接続について

コマンドを実⾏する前に、セッションを1つ以上のNutanixクラスタに接続する必要があります

> Connect-NutanixCluster -Server cluster_ip_address -UserName admin_username ` -Password admin_password'

  • cluster_ip_addressをクラスターの仮想IPアドレスまたはコントローラーVMのIPアドレスに置き換えます
  • 置き換えadmin_usernameNutanixのユーザー名(通常でadmin)
  • admin_passwordをNutanixのユーザーパスワードに置き換えます
複数のConnect-NutanixClusterステートメントを使⽤して複数のクラスタに接続します。セッションが複数の クラスタに接続されている場合は、他のコマンドレットのServerパラメーターを使⽤してコマンドを実⾏するための クラスタを指定します
接続されているクラスターから切断するには、切断元のサーバーのIPアドレスを指定してDisconnect-NutanixClusterを実⾏します

接続クラスタ情報
セッションで接続しているクラスターの詳細を取得するには、Get-NutanixClusterコマンドレットを実⾏します 複数のクラスターに接続されている場合は、接続されているクラスターごとに同じ出⼒を取得するように実⾏できます

Get-NutanixCluster -Server cvm_ip_addr

Cmdletsのバージョン情報
実⾏しているコマンドレットのバージョン詳細を取得するには、Get-NutanixCmdletsInfoのCmdletsを実⾏します

Nutanixの環境を⾃動化したい⼈は利⽤⽅法に気をつけながら是⾮使ってみてください。

以上、よろしくお願い致します。

2021年7月6日火曜日

ADS(Acropolis Distributed Scheduler)およびAffinityポリシーについて

みなさん、こんにちは

本日投稿の内容について、以前別サイトで私が投稿したブログの内容です。
サイトの閉鎖に伴い、こちらで再度掲載いたします。

今回はAcropolis Distributed Scheduler(以下ADSと省略させて頂きます)をご紹介します。

本機能については、VMwareのことをご存知の⽅はお気づき⽅と思いますが、こちらはDRS(Distributed Resource Scheduler)と同様の機能だと思って頂ければと思いますが、機能は非常にシンプルになっています。

1. Acropolis Distributed Scheduler(ADS)について


ADSの実現することは以下の通りです。

仮想マシンの初期配置
  • 新しい仮想マシンを最適なホストに配置する
ホスト内のリソースの競合を避ける
  • CPU(ホストのCPUが閾値85%を超えると移行が始まる)
  • ストレージコントローラ(CVMのCPUが閾値を85%をStargateに利用されてしまうと移行が始まる)Nutanix Volumesも対象
  • ルール違反のスケジューリング
  • vGPUについてもAOS 6.0から対象となる
ホットスポットを検出するインテリジェントシステム
  • ホットスポットの回避
  • ワークロードの変化に反応しない
  • ワークロードに必要なリソースを確保
  • オペレータの介入なし
  • 負荷分散しない
仮想マシン間のアンチアフィニティポリシー
  • 異なるホスト上で仮想マシンの分離を保証
プロビジョニングした仮想マシンを最適なホストに配置して、ホスト内のリソース競合を避けるようにすることが目的であり、VMwareのDRSのように細かく設定を行うことはありません。アフィニティポリシーについても非常にシンプルなものとして設定可能になっています。
また、仮想マシン起動時の初期配置および15分間隔で状態をチェックします。

異常が見つかった場合は、次の方法で修復します。
  1. 仮想マシン移行計画
  2. Nutanix Volumes iSCSIセッションの再指示
異常検出
  • 15分ごと
  • ホストリソースが過負荷になっていないかを確認する
  • 潜在的に十分なリソースを獲得できない仮想マシンがないかチェック
  • ポリシーに違反していないかどうかをチェック
需要予測
  • 競合するノード上のリソースの需要予測が困難
  • 統計は現在どのくらいの割合で取得しているのか指定
  • 現在の値を選択すると、移行がたらいまわしにされる可能性があります
  • 現在の解決策はコンバージェンスがより迅速になるように固定比率(+20%)で需要を拡大すること
ストレージCPUの計算
  • Stargateはスレッドカウンターを発行
  • 各vdiskコントローラが費やした時間を指定(vdiskにマップされます)
  • vdiskカウンタは対応する仮想マシンおよびSoSANを体解っとに集約
  • StargateのCPU使用率に基づく割り当て
  • Storage CPUが通常の仮想マシンCPUに追加
  • I/Oヘビーな仮想マシンをコンピュートヘビーノードへの移行を妨げます
  • ハイパーコンバージド環境での特定が重要
VMwareのDRSと異なり、仮想マシンと合わせてストレージパフォーマンスをモデル化しません。固定化されている機能であるため、特別にカスタマイズすることなく利用できます。

2. Affinity Policy for AHV
Acropolisの管理対象クラスターの管理者として、AHVクラスター上の仮想マシンのスケジューリングポリシーを指定できます。これらのポリシーを定義することで、クラスタ内のホスト上の仮想マシンの配置を制御できます。
これらのポリシーを定義することで、クラスタ内のホスト上の仮想マシンの 配置を制御できます。 2種類のアフィニティポリシーを定義できます。以下の内容を紹介します。
  • VMホストアフィニティポリシー
  • VM-VMアンチアフィニティポリシー
  • アフィニティルールの制限
3. VMホストアフィニティポリシー
VMホストアフィニティポリシーはVMの配置を制御します。このポリシーを使⽤して選択したVMがアフィニティホストリストのメンバー上でのみ実⾏できるように指定できます。
このポリシーは、ユーザーがVMの電源を投⼊したとき、またはVMを移⾏したときに、VMをどこにホストできるかを確認して適⽤します。

注意︓
  • VMホストアフィニティポリシーを適⽤することを選択した場合、アフィニティポリシーの要件に適合しないホストに 仮想マシンをパワーオンまたは移⾏できないように、Acropolis HAおよびAcropolis Distributed Scheduling(ADS)が 制限されます。この⽅針は強制的に施⾏されているため。
  • VMホストのアンチアフィニティポリシーはサポートされていません。
  • 以前のAOSリリースでは、ホストアフィニティ設定で構成されたVMはVMが新しいクラスターに移⾏されてもこれらの設定を保持します。通常、これらのVMの電源を⼊れようとしても失敗しました。このようなVMは、CBRに対応していない(バックアップとリカバリが可能)、保護されていない、保護ドメイン操作の⼀部として移⾏されていないなどのタグが付けられました。このVMタイプを選択すると、Webコンソールのメッセージが表⽰されます。このVMは バックアップとリカバリに対応していません。
    考えられる理由︓VMとホストのアフィニティが設定されている。
VMの作成またはアップデート操作中にPrismを使⽤して、VMとホストのアフィニティポリシーを定義可能

4. VM-VMアンチアフィニティポリシー
このポリシーを使⽤して仮想マシン間の⾮アフィニティを指定できます。VM-VMのアンチアフィニティポリシーでは、1台のホストで問題が発⽣したときに両⽅の仮想マシンを 失うことがないように、指定された仮想マシンを区別します。しかし、これは優先的な⽅針です。 このポリシーは、リソースの制約が発⽣した場合にAcropolisの動的スケジューリング(ADS)機能が必要な措置を講じることを制限するものではありません。
注意︓
  • 現時点では、aCLIを使⽤してのみVM-VMのアンチアフィニティポリシーを定義できます
  • VM-VMアフィニティポリシーはサポートされていません
  • アフィニティポリシーが設定された仮想マシンのクローンが作成されている場合、ポリシーはクローン作成された仮想マシンに⾃動的には適⽤されません。ただし、VMがDRスナップショットから復元されると、ポリシーは⾃動的にVMに適⽤されます
5. アフィニティ ルールの制限
  • ホストがクラスタから削除されても、ホストUUIDはVMのホストアフィニティリストから削除されません。
  • 予約ホスト⽅式を使⽤してHAが構成されているクラスタでは、VMホストアフィニティを構成できません。
  • 電源がオンになっているVMのVMホストアフィニティをPrismから削除することはできません。acliコマンドを使⽤してこの操作を実⾏できます。
    vm.affinity_unset vm_list
ここで、Affinityルールの設定をPrismの画⾯とacliで紹介したいと思います。
Nutanixのクラスタで1ホスト内でExchangeとSQLが動作している場合に、これらを同時に1ホストで動かさない設定(AntiAffinity)を設定したいと思います。
まずは、ExchangeのVMにおいて、Affinity設定を⾏います。VMのメニューからUpdateを選択して、Set Affinityをクリックして、動作するホストを選択します。
同様にSQLのVMについても同様の設定を⾏います。
ここで、⼀度SQL VMのマイグレーション設定を確認します。マイグレーションをクリックすると⻘い枠に注意書きがあり、先ほど設定したAffinityルールが適応されていることが確認できます。その後マイグレーションできるホストに関しても⾃動で移⾏する設定とホストA/Bが表⽰されています。
ここで、acliを利⽤してAntiAffinityの設定を⾏います。SSHでCVMにログインして設定します。以下は⼀例を記載します。

nutanix@NTNX-*******-A-CVM:~$ acli

<acropolis> vm_group.create SQL_Exch
<acropolis> vm_group.add_vms SQL_Exch vm_list=SQL,Exchange
<acropolis> vm_group.antiaffinity_set SQL_Exch

こちらを設定後にPrismの画⾯をしばらく⾒ていると、AntiAffinityを設定された条件でSQL VMがホストBにマイグレーションされることがわかります。

ここで、タスク画⾯にADS: Remove Resource Contentionと表⽰されます。
つまりリソースの競合を排除するという話になります。

Acropolisの管理対象クラスターでは、Acropolisの動的スケジューリング(ADS)機能により、 ⼀定期間にわたるコンピューティングおよび/またはストレージのI/Oの競合またはホット スポットについてクラスターを予防的に監視します。問題が検出された場合は、移⾏計画が 作成されて実⾏され、VMをあるホストから別のホストに移⾏することで、クラスタ内
の ホットスポットが排除されます。この機能は現在進⾏中の競合のみを検出します。これらの タスクは、Prism Webコンソールのタスクダッシュボードから監視できます。VMリンクを クリックして、移⾏先(AHVホストへの)移⾏パスを含む移⾏情報を表⽰できます。

ADS機能のその他の利点は次のとおりです。
  • この機能は、VM構成に応じてVMの初期配置も改善します。
  • アクロポリスのブロックサービス機能は、外部から⾒えるiSCSIターゲットのセッションのバランスをとるためにADS機能を使⽤します。
デフォルトではこの機能は有効になっています。Nutanixではこの機能を有効にしておくことを推奨しています。 ただし、aCLIを使⽤してこの機能を無効にすることができます。この機能を無効にしても、競合やホットスポットのチェックはバックグラウンドで実⾏され、何らかの異常が検出された場合は、3回⽬の通知後に[アラート]ダッシュ ボードにアラート
が表⽰されます。ただし、これらの競合を解決するためのADS機能による処理はありません。マニュアルで修正措置を取る必要があります。

6. Acropolisの動的スケジューリングの要件と制限
  • すべてのホストがAOS 5.0以降で実⾏していること
  • iSCSIターゲットは空のエンティティとして表⽰されます。ただし、iSCSIターゲットで何らかの操作が⾏われると、関連するメッセージが[タスク]ダッシュボードに表⽰されます。
  • 問題が検出され、ADSがその問題を解決できない場合(たとえば、CPUまたはストレージリソースが 限られているため)、移⾏計画は失敗する可能性があります。このような場合、アラートが ⽣成されます。Prism Webコンソールの[アラート] ダッシュボードからこれらのアラートを監視し、 必要な修正措置を取る必要があります。
  • ホスト、ファームウェア、またはAOSのアップグレードが進⾏中で、リソースの競合が発⽣した場合、アップグレード期間中はリソースの競合の再調整は⾏われません。
Acropolisの動的スケジューリングを無効にする
次の⼿順を実⾏してADS機能を無効にします。ADS機能を無効にすることは推奨していません
  1. SSHセッションからクラスター内のコントローラーVMにログインし、acliでアクセスします
  2. ADS機能を無効にします
        acli> ads.update enable = false

Acropolisの動的スケジューリングの有効化
ADS機能を無効状態で機能を有効にしたい場合は、次の⼿順を実⾏してください
  1. SSHセッションからクラスター内のコントローラーVMにログインし、acliでアクセスします
  2. ADS機能を有効にします
        acli> ads.update enable = true

以上、よろしくお願い致します。