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

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