本記事は2021年12月14日にJosh Odgers氏が投稿した記事の翻訳版です。

原文はこちら。

以前にNutanix AOSソリューションが提供するリビルドのパフォーマンスを含む拡張性、回復力、及び性能についての多くの優位性の詳細について述べてきました。これらはNutanix環境が障害発生後に自分自身で、完全な回復力を備えた状態にまでのリカバリを、可能な限り早く実行することを保証しています。

これはNutanix環境を支えるキャパシティとパフォーマンスに応じてデータをクラスタ全体で動的に分散させるAOSストレージファブリックによって可能になっています。

AOSストレージファブリックにはAOSがデータを1MB および 4MBのエクステントで保存するのとは反対に、未発達なHCI製品がデータの保存に巨大なオブジェクトを利用しているために潜在的に発生してしまう、個々のノードのキャパシティの問題に対して未然に対処する事ができる、という点以外にも多くの優位性があります。

AOS 6.1では、複数のノードを同時に取り外す事ができる新しい機能が搭載されますが、これを使うことによって同じAOSアーキテクチャ上で、合理的な時間内に効率的に複数のノードを取り外すことができるようになります。

ノードの取り外しは管理者が各々のノードの進捗状況を監視する必要なく行われ、1ノードが完了すると、それに続くノードの取り外しが前のノードと同様に行われます。

一つずつ取り外すのと比べてどれぐらい効率的なのか?

たとえば、8ノードのクラスタがあり、そこから２もしくはそれ以上のノードを取り外すときのことを考えてみましょう。

以前のAOSと、Nutanix以外のHCIプラットフォームではノード8からクラスタ内の他のノードへ移動されていました。

AOSはこれを、データを残されたすべてのノードに細やかなレベルでバランスしながら効率的に実施していましたが、それに続くノード７の取り外し時にはノード８に格納されていたデータのいくらかがノード7上に配置されており、再度データ移動の対象となってしまっていました。データを2回(もしくはもっと)移動させることは不必要ですし、クラスタへのオーバーヘッドと処理時間の長期化の両方が発生させます。

ノードのサイズと取り外すノードの数に従って、2重/3重でのデータのハンドリングによって取り外しの処理/時間が、特に大規模なクラスタをダウンサイズする際には劇的に遅れてしまうことになります。

運用上のタスクが高度に効率化され、それに対する時間や影響は小さくあるべきである、と誰もが望むはずです。ですから、私はこの機能をリクエストしましたし、既存の機能にとって明らかに価値のある改善です。

新しいマルチノードの取り外しのプロセスでは、システム管理者が取り外すために複数のノードをマークする以外に必要なことはありません。AOSはメタデータを分析し、データの移動を1回限りにするため、マルチノードの取り外しのオーバーヘッドと影響は小さくなり、結果としてタスクの完了ももちろん早くなります。

スマートかつ、やりすぎず、そして市場をリードするAOSを支える分散アーキテクチャを活用する文字通りのwin/win/winです。

Nutanix Clusters on AWS および/またはAzureを活用するユースケースにおける優位性を考えましょう。

Nutanix Clusters on AWS および/または Azureの一つの大きな優位性は月末や期末の業務におけるピークの間だけ、または流通業におけるピークデマンド(ブラックフライデーを考えてみてください)の必要に応じてバーストすることができるというものです。

多くの製品が「バースト」できるということを謳いますが、詳細を突き詰めると悪魔が潜んでいる事があるということを理解しておくことは重要です。 Nutanix AOS は(ということはAOSをベースとしているNutanix Clusters on AWS/Azureソリューションも)即時に新しいノードを活用する機能を備えています 。これはキャパシティにおいてもパフォーマンスにおいてもCPU/メモリリソースにおいても、アプリケーションもしくはストレージ管理者が介在することなく実現されます。これはVMware Cloud on AWSのようなvSANの拡張や回復力においてアーキテクチャ上の制限を抱える製品を利用する製品には当てはまりません。

例えば、VMware Cloud on AWSまたはオンプレミスのvSANを利用されているお客様は、ノードの追加したとしてもすぐにメリットは得られません。新しいノードのキャパシティやパフォーマンスを活用するためにはマニュアルでのリバランス操作や新しい仮想マシンや仮想ディスクの作成が必要になります。

バーストの機能は素晴らしいものですが、それはビジネス規模が平常時に戻った際に効率的にスケールバックする方法が用意されていればの話です。そうでなければバーストのためのコストは、本来あるべきコストよりも高くなってしまうでしょう。

以前にもネットワークパフォーマンスの観点からパブリッククラウドで起こりうる課題について取り上げており、そこでは帯域の制限によって、特に大容量のデータを動かさなければならない際には運用に影響が出る可能性があることを指摘しています。

Nutanixのデータローカリティはこうした制限による潜在的な影響を最小化し、更にマルチノードの取り外し機能はローカリティとAOSの効率的なデータ配置を活用してこの問題に対し、マニュアル、または自動化されたディスクのバランシングやデータが複数回移動されるという必要性を予防/防止しています。

マルチノードの取り外し機能は、バーストを行うことを選択したお客様が必要以上にベアメタルインスタンスのコストを支払うことがないことを保証するだけでなく、クラスタがもともとのサイズに戻った際に最適化された状態で、マニュアルでのバランシングなどの管理者の介入の必要もないことも保証します。

現状がRF2でもマルチノードの取り外しは可能でしょうか?RF3が必要ですか?

マルチノードの取り外しはRF2でもRF3でもサポートされます。これはAOSが常にデータの整合性を維持しているためです。もしも2ノードが取り外される際に、RF2の環境では2つのコピーのデータのうちのいくらかがそのノードに保存されているということが大抵の場合で起こりえますが、そのデータは実際の取り外しが行われる前にクラスタ内の残りのノードへ永続的な形で保存されることになります。

重要なことは、取り外し対象のノードは取り外しプロセスの最中には新たなWrite I/Oを受け付けず、またバックグラウンド作業も行わないということです。これによってフロントエンド側の作業(例：仮想マシンやアプリによるI/O)によって不必要にプロセスが長引くことを防止します。

Nutanix AOSとVMware vSANとのWrite I/Oパスの比較で説明したように、Nutanix AOSは常にI/Oの整合性を維持し、ストレージポリシー(RF2 または RF3)のコンプライアンスを満たされない場合には、Writeが行われたことの完了通知を返すことはありません。これはマルチノードの取り外しの際も同じです。

マルチノードの取り外しのプロセスの最中も、新たなWrite I/Oは通常と全く同じやり方で書き込まれます、つまり新たなレプリカは仮想マシンにとってローカルにあ当たる場所に書き込まれ、1つまたは2つ(RF3の場合)のレプリカはクラスタ内の取り外し対象ではない全てのノードに対して分散されます。

同時に何台までのノードを取り外しできますか?

取外し可能なノードの数はクラスタ内で利用できるリソース(例: ストレージ)とクラスタの構成上の最小値によってのみ制限されます。 

例1 : RF3を利用しているクラスタでは最低5ノードが必要です (RF2では3ノード)

例2: ラックもしくはブロックアウェアネスを利用しているクラスタでは構成されている回復力に応じたノード/ブロックが必要です

以下はRF3で構成された8ノードのクラスタで、私が3ノードを同時に取り外ししており、RF3のワークロード向けに最低限必要な5ノードのクラスタへ変更している際のスクリーンショットです。

まとめ

マルチノードの取り外しという新機能のおかげで、オンプレミスそしてパブリッククラウドのNutanixのお客様の皆様はこれまで以上の運用上の効率性を得ることができ、その結果、コストを低減することができます。特にパブリッククラウドで不必要なノードを短時間で取り外し、ベアメタルのコストを下げたい、というクラウドバーストにおいてNutanixの先進性を活用している状況のお客様では顕著です。

マルチノードの取り外しによって、お客様はピークを過ぎた後にはほんの数クリックで迅速/簡単に、平常時のビジネスにおけるクラスタサイズに戻せるという確信を持って利用することが可能です。