ストレージ容量の拡張 - Nutanix vs VMware vSAN

  • 3 February 2021
  • 0 replies
  • 800 views

Userlevel 3

本記事は2020年2月10日にJosh Odgers氏が投稿した記事の翻訳版です。

原文はこちら。本シリーズの索引はこちら

 

このシリーズの最初の記事では、同じハードウェア上でのNutanix ADSFとVMware vSANの実際の使用可能な容量を比較しました。

 

その結果、Nutanixの方が、約30~40%多くの容量を提供できることがわかりました。

 

次に重複排除と圧縮の技術を比較したところ、NutanixはvSANよりも容量効率、柔軟性、回復力、パフォーマンスの面で優れていることがわかりました。

 

その後にはイレイジャーコーディングについて見てきました。(EC-Xと呼ばれる)Nutanixの実装では、パフォーマンスとキャパシティの効率性をリアルタイムにバランスさせることができ、動的でありながら柔軟性も提供できることを学びました

 

一方、vSAN は「オール オア ナッシング」という原始的なアプローチを採用しているため、フロントエンドへの影響が大きくなります。また、最適なデータに対してイレイジャーコーディングを動的に適用できるわけでもありません。

 

この記事では、両プラットフォームがどのようにストレージ容量を拡張できるのかを学びましょう:

 

機能

Nutanix

VMware vSAN

単独ドライブの追加

ノードの追加

 

この典型的な「チェックボックス」形式の比較からは、両方のプラットフォームが単独のドライブやノードを追加して容量を拡張できることがわかります。私の以前の投稿をいくつか読んでいただいた皆様にはご想像どおりかもしれませんが、以下では、上記のような比較が大きな誤解を招くものであることを説明していきます。

 

顧客が、プラットフォームを選択したり、既存の環境を拡張したりする際に、考慮すべき重要な要素は数多くあります。

 

vSANの問題  その1 - 重複排除と圧縮を有効にしたディスクグループにドライブを追加すると、新しく追加されたドライブでは自動的には重複排除と圧縮は実行されません

 

参照:  https://blogs.vmware.com/virtualblocks/2017/11/29/vsan-operations-adding-removing-drives-deduplication-compression-enabled/

 

新しいドライブはデータを保存するために使用されますが、そのデータは重複排除および圧縮は施されていません。ディスクグループ内の(新しいドライブを含む)すべてのキャパシティドライブが重複排除および圧縮されたデータを保存できるようするためには、そのディスクグループを削除して再作成する必要があります

 

Nutanixでは、ドライブが1台、もしくは複数台のノードに追加された場合、そのキャパシティはほぼすぐに利用可能になります。そして、設定されているすべてのデータ効率化技術が適用されます。データの再フォーマットや大量のデータの移動は必要ありません。

 

Nutanixにはディスクグループという制約がないので、何らかの理由でディスクグループを削除して作り直す必要もありません。

 

では、それぞれのプラットフォームがデータ効率化技術を使用したときに、どのようにストレージ容量を拡張できるかを学んで行きましょう:

 

機能

Nutanix

VMware vSAN

データ効率化技術(圧縮/重複排除)利用時に単独のドライブを追加

データ効率化技術(圧縮/重複排除)利用時にノードを追加

️*

 

* 追加ノードのキャパシティを利用するためにリバランスを行う必要があります。これについては問題その3で説明します。

 

このようにすると、単独のドライブでvSANの容量を拡張する際の明確な問題点が見えてきます。vSAN環境では、管理者が手動の影響の大きな作業(ディスクグループの再作成)を行わなければ、重複排除と圧縮の恩恵を受けられません。

 

これにより、既存のノードにドライブを追加することでvSANの容量を拡張することの魅力はなくなります。その上、以前の記事で説明したvSANが圧縮と重複排除から得られるかもしれないメリットをさらに低下させてしまいます

 

vSANの問題  その2 - vSANは、最大255GBまで肥大しうる大規模な「オブジェクト」のレベルでデータ/容量をバランスさせています。

 

これにより、vSANの顧客はvSANクラスタのリバランシングを実行しなければならなくなります。クラスタが80%に達したときに開始されるクラスタのリバランス(リアクティブバランシング)を使用するか、または自動化されたリバランシング(VMwareによるとパフォーマンスに影響を与えるため、オフにすることもできる)を設定するかです:

 

vSAN は、標準でディスクグループのデータを自動的にリバランスします。自動リバランスの設定は変更することができます。

 

vSAN クラスタでは、デバイスへの I/O パターンが不均一であったり、ホストや容量デバイスを追加した場合に、不均衡になることがあります。クラスタが不均衡になると、vSAN は自動的にディスクのバランスを再調整します。この操作により、使用率の高いディスクから使用率の低いディスクにコンポーネントが移動します。

 

自動リバランスを有効または無効にしたり、自動リバランスをトリガーするための閾値の値を設定できます。クラスタ内のいずれかの2つのディスクの容量の値がリバランシングの閾値を満たす場合、vSANはクラスタのリバランシングを開始します

 

ディスクのリバランスは、vSANクラスタのI/Oパフォーマンスに影響を与える可能性があります。このパフォーマンスへの影響を回避するには、ピークパフォーマンスが必要な場合には自動リバランスをオフにすることができます

 

参照: HTTPS://DOCS.VMWARE.COM/EN/VMWARE-VSPHERE/6.7/COM.VMWARE.VSPHERE.VSAN-MONITORING.DOC/GUID-968C05CA-FE2C-45F7-A011-51F5B53BCBF9.HTML

 

vSANのリバランシングは、オブジェクト/コンポーネントレベルで自動または手動で実行されるポストプロセス(言い換えると「リアクティブ」)の処理です。あまり粒度が細かくなく、データの大規模な移動が必要になります。VMwareによれば、それはパフォーマンスに大きな影響を与えますし、オフにする必要があるかもしれません。

 

vSANのキャパシティマネジメントの実装は、本当の意味でキャパシティとパフォーマンスのどちらかで妥協を強いられます。重複排除と圧縮の両方を一度に ON または OFF にしなければならなかったりイレイジャーコーディングをON にしてインラインですべてのデータに適用するか、または OFF にするかを選ばなければならないのとよく似ています。

 

一方、Nutanixは、書き込みパスの中(つまり「インライン」)でのプロアクティブでインテリジェントなレプリカ配置機構を利用して、個別のノード/ドライブの容量とパフォーマンスの利用率に基づいてリアルタイムに新しいデータを配置します。

 

その結果、新しいノードやドライブが動的に利用されますし、クラスタ全体のバランスが均等になることで、回復力とパフォーマンスが向上します。そして先に説明したようなキャパシティが断片化され使用不可能になることも回避できます。

 

これはまた、ポストプロセスでのディスクのバランシングの必要性と潜在的な作業量を最小限に抑えます。Nutanixのポストプロセスのディスクバランシングは、クラスタが著しくバランスを崩した場合に発動します。大きな違いは、Nutanixはオブジェクト(最大255GB)単位ではなく、エクステントグループ(4MB)レベルでバランスをとるということです。移動しなければならないデータ量は少なくなりますし、断片化に伴う非効率性はゼロです。

 

vSANの問題  その3 - ノードを追加した際、新しいvDiskまたはVMが作成されるまで、もしくは管理者が手動で設定を実施するまで、そのノードのキャパシティは使用されません。

 

ただし、単独のドライブの使用率が80%以上の場合は、vSANが自動的にクラスタのリバランスを行います。しかし、こういう自体になった場合にはクラスタはVMwareが推奨する25~30%の「スラックスペース」を維持していないということになるため、問題が発生する可能性があります。

 

(vSAN)クラスタのキャパシティを拡張してから手動で再調整し、リソースをクラスタ全体で均等に配分します。詳細については、『vSAN の監視とトラブルシューティング』の「手動リバランス」を参照してください。

 

参照: HTTPS://DOCS.VMWARE.COM/EN/VMWARE-VSPHERE/6.7/COM.VMWARE.VSPHERE.VIRTUALSAN.DOC/GUID-41F8B336-D937-498E-AE87-94953A66DF00.HTML

 

Nutanixで単独ドライブやノードを追加した際には、既存のVMのパフォーマンスはすぐに向上されます。ADSFはより多くのドライブにデータを送信することができますし、ノードが追加された場合にはコントローラVM(CVM)も増えるため、分散ストレージファブリックでより多くのワークロードを処理することができるようになります。

 

vSANは、顧客にキャパシティ管理とパフォーマンスのどちらかを選択することを強要します。これは合理的でなく、現実的でもありません。

 

単独のドライブを追加することでvSANの容量を拡張することはできますが、多くの頭痛の種を伴うことがわかりました。対照的に、Nutanixは、Acropolis 分散ストレージファブリック(Acropolis Distributed Storage Fabric - ADSF)のおかげで、拡張はスムーズに行われます。

 

これまでに学んだことをまとめてみましょう:

 

機能

Nutanix

VMware vSAN

インライン(リアルタイム)でのキャパシティのバランシング

インライン(リアルタイム)でのパフォーマンスのバランシング

完全に自動化された細かい粒度(MB)でのポストプロセスでのバランシング

*

 

* vSAN は、どのストレージデバイスでも利用率 >=80% で自動的にバランスをとりますが、これは大規模なオブジェクトレベル (最大 255GB) で行われます。

 

CPU/RAMリソースを使わずにストレージ容量だけを拡張する場合はどうでしょうか?

 

チェックボックス型の比較に戻って見てみましょう:

 

機能

Nutanix

VMware vSAN

ストレージ専用ノード

 

ここでは、両方のプラットフォームが「ストレージ専用ノード」を提供できることがわかります。ですが、ここからが非常に面白いところです。

 

VMwareは通常、ストレージ専用ノードの概念については語りません。これは(長い話を短くまとめると)vSANではNutanixが「ストレージ専用ノード」で提供するメリットの、ほんの一部分しか提供できないからです。(ストレージ専用ノードを利用する場合には)vSAN 環境では大幅に複雑さとリスクが増大します。DRS のルールや、ホストでどのようなネットワークが提供されているかという点についての考慮事項があるためです。

 

このプロセスがどれほど悲惨なものかは、「vSANでストレージ専用ノードを構成する (そしてメインフレームを買わない!)方法 」と題された投稿で解説されています。そこではストレージ専用ノードにはメリットが無いと印象付けようとしています。また、HCIにストレージ専用ノードを組み合わせることのメリットが理解されていないことが浮き彫りになっていますが、これは、この記事の著者が好んで使用している製品がその機能を持っていないためではないかと思います。

 

その投稿では、ストレージ専用ノードを以下のように定義しています:

 

ストレージ専用ノードは、クラスタにコンピュートリソースを提供しないノードです。構成の変更なく仮想マシンを実行することはできません。

 

ストレージ専用ノードは、コンピュートリソースは提供しませんが、クラスタにストレージのパフォーマンスとキャパシティを追加します。

 

これが正しいのであれば、vSANとNutanixは同等のものですよね? もう一度考えてみてください!

 

最初の定義を取り上げましょう - 「ストレージ専用ノードは、クラスタにコンピュートリソースを提供しないノードです。構成の変更なく仮想マシンを実行することはできません。」

 

vSANの場合は、VMwareの従業員の方のブログで解説されていたように、2つの方法で実現することができます。どちらの方法を採るかは、顧客が保有しているvSphereのライセンスによります。(別のポイントは後ほど提起します)

 

  1. ストレージノード用に別の vDS を配置します。仮想マシンのポートグループは構成しません。ポートグループが見つからないホストでは、仮想マシンは起動できません。
  2. DRS の "アンチアフィニティ" ルールを活用して、仮想マシンがホスト上で実行されないようにします。”MUST" ルールを必ず使用し、仮想マシンがホスト上で実行されないように定義してください。

 

それでは、Nutanixではストレージ専用ノード(2015年にリリース)がどのように展開されるのかを見ていきましょう。

 

  1. (Foundationと呼ばれる)初期セットアップ中に、ノードをストレージ専用ノードとしてチェックします。それで完了です。
  2. 既存のコンピュート+ストレージのノードをストレージ専用ノードに変換したい場合は、ノードを "Never schedulable "とマークすることで行うことができます。(訳注:原文のまま翻訳していますが、実際には既存ノードを一度クラスタから削除し、再度追加する際に”Never scheduleable”とマークして追加します。)
  3. クラスタに追加されたHCIノードは、VMが手動または動的にホスト上に移動されるまで、基本的にストレージ専用ノードとして機能します。

 

Nutanixでは、ストレージ専用ノードにvSphereのライセンスは必要ありません。ESXi環境だったとしても、です。なぜならNutanixのストレージ専用ノードはAHVで動作するからです。

 

ストレージ専用ノードがAHVで動作しているとしても、それはNutanixクラスタにシームレスに統合されており、vSphereまたはHyper-Vクラスタのストレージにすべてのメリットをほぼ即座に提供します

 

要するに、vSANにはストレージ専用ノードという概念は実際には存在せず、VMware社員のブログで説明されている方法は、どんなによく言ってもハックに過ぎません。対して、Nutanixは包括的なストレージの機能を提供しています

 

それぞれの製品でストレージ専用ノードをセットアップする方法をまとめてみました:

 

機能

Nutanix

VMware vSAN

初期展開時にノードをストレージ専用としてマークできる

既存ノードをストレージ専用に変換できる

️*

vSphere DRSのライセンスが必要

(不要)

️(必要)

ストレージ専用ノードでVMが動作するのを防ぐために特別なネットワークが必要

(不要)

️(必要)

 

* 手動でハック(DRSルール&カスタムネットワーク)した場合のみ

 

あなたが私の意見に反対で、vSANがストレージ専用ノードのコンセプトをサポートできると固く信じていると仮定してみましょう。では、vSANとNutanix ADSFがストレージ専用ノードをどのように使用しているかについてお話しましょう。このセクションの後には、Nutanixが提供する主なアーキテクチャの違いとその結果としてのメリットをご理解いただけると信じています。

 

例: 4ノードのクラスタで、CPU/RAMは十分に利用可能ですが、ストレージは予想以上の速さで消費されており、利用率は75%近くになっています。これはN+1の容量が利用できなくなる境界線を越えそうであることも意味します。

 

要件: 顧客はストレージ容量を2倍にする必要があります。

 

まずはvSANから始めましょう。標準の構成を想定しています。

 

クラスタに4台の新しいノードを追加し、VMwareの友人が説明したようにDRSとネットワークの必要な構成を実施します。

 

標準では、クラスタ内のキャパシティデバイスの使用率が80%未満の場合、vSANは自動リバランスを開始しません。このプロセスは管理者が手動で開始する必要があります。

 

VMのオブジェクトが新しいノードに分散していないため、VMのパフォーマンスは変わっていません。

 

⚠️ 新しいvSANノードは基本的にクラスタに価値を提供していません。⚠️

 

では、Nutanix ADSFを比較してみましょう。同じく標準構成を想定しています。

 

Nutanix Foundation (ベアメタルイメージング)ツールを介して、ストレージ専用ノードとしてマークされた4つのノードをクラスタに追加します。

 

注:新しいノードがHCIノードの場合でも、以下に説明するのと同じプロセスが発生します。

 

クラスタ全体で平均レイテンシはすぐに低下し、VMの読み取りレイテンシと書き込みレイテンシの両方が目の前で低下します。

 

VM の IOPS も大幅に増加し、仮想マシン全体で CPU 使用率が低下していることがわかります。

 

ちょっと待って?Nutanixは、ストレージ専用ノードを追加するだけで、ストレージのパフォーマンスを向上させ、VMリソースをより効率的に利用できるようにしたのですか?

 

その通りです。ADSFは完全な分散型ストレージ・ファブリックであるため、ストレージ専用ノードが追加された瞬間に、書込みのレプリケーションは直ちに拡張された8ノードのクラスタ全体でプロアクティブにバランスされるのです。

 

これにより、すべてのVMが8つのストレージコントローラ(CVM)や追加されたSSD (ハイブリッド環境の場合はSSDとHDD)の恩恵を受けられるようになります。

 

書込みレプリケーションの大部分がストレージ専用ノードに動的に配置されるため、HCI ノード上のコントローラ VM (CVM) は省力化されます。CPU リソースが解放されて、より多くの VM や VM のパフォーマンスの向上に利用することができます。

 

これは机上の理論やナンセンスなマーケティングの産物ではありません。簡単にテストできるものであり、私はかなり前にこちらの記事でこれについて実証しました。「Nutanixのストレージ専用ノードでのスケールアウトパフォーマンステスト」

 

興味深いのは、書き込みと読み取りのレイテンシが大幅に減少した一方で、パフォーマンス(総IOPS)はほぼリニアに向上したということです。

 

このような劇的なパフォーマンスの向上は、Nutanix ADSFがvSANのような大規模なオブジェクトに依存せず、クラスタのパフォーマンスとキャパシティに基づいて書き込みをバランスさせるプロアクティブな書き込みパスを有しているからこそ達成できたことです。

 

Nutanixのデータローカリティはどうなりますか?

 

ストレージ専用ノードでは、この概念や優位性が崩れてしまうのではないでしょうか?

 

全く逆です。ストレージ専用ノードを追加すると、HCI ノードに保存されている書込みレプリケーションの量が減り、データをローカルに保存するためのより多くの容量が解放されます。このためデータのローカリティの利点を最大化することができます

 

vSANがその複雑さに苦しみ、この場合、ストレージ専用ノードから実際の価値を提供できないのは、その基礎となるアーキテクチャがディスクグループと255GBの大容量オブジェクトのアーキテクチャによって大きく制限されているからです。

 

ストレージ専用ノードを使用していて、クラスタにノード障害が発生した場合はどうなりますか?

 

Nutanixでは、クラスタ内のすべてのノードが、リビルドプロセスに積極的に参加します。ADSFはキャパシティ利用率とパフォーマンスに基づいてすべてのノード(HCIノードとストレージノードの両方)でリビルドを動的にバランスさせます。その結果、リストアはより高速に完了しますし、リビルド完了後のクラスタはバランスのとれた状態になっています。

 

一方、vSAN のリビルドは、オブジェクト (最大 255GB) が 1 つのノードから別のノードにレプリケートされるという、より粒の粗い、大きな規模で実行されます。これは断片化やクラスタ内でホットスポットの発生を引き起こします。また、書込みは動的にはバランスされません。vSANはオブジェクト ストア のアーキテクチャを基盤としており、書き込みの際に最も適している場所に対しての書き込みパスが選択されるわけではないからです。

 

両プラットフォームのストレージ専用ノードの機能をまとめてみましょう:

 

ストレージ専用ノードの機能

Nutanix

VMware vSAN

キャパシティをリアルタイムに増強できる

*

パフォーマンスをリアルタイムに増強できる

信頼性をリアルタイムに増強できる

プロアクティブ(インライン)なディスクのバランシング

リアクティブ(ポストプロセス)なディスクのバランシング

**

 

* vSAN データストアのキャパシティは理論上は増加していますが、リバランス操作が完了するか、新しい VM/仮想ディスク が作成されるまでは、キャパシティは使用可能にならず、使用できません。

 

** デフォルトでは ストレージデバイスの使用率が80%を超えた場合にのみ適用されます。

 

まとめ

 

チェックボックス式のマーケティング資料や入門者レベルで比較すると、どちらのプラットフォームも似たような能力を持っているように見えます。しかし、私達は見せかけの裏側を見ることの大切さを学びました。現実世界での能力は、マーケティングスライドとは大きく異なるのです。

 

Nutanix Acropolis 分散ストレージファブリック(ADSF)によって、顧客は個別のドライブ、HCIノード、またはストレージ専用ノードを追加してストレージ容量を拡張することができることがわかりました。手動での煩わしい作業は必要はありません。

 

さらに、Nutanixのお客様は、パフォーマンス、回復力を向上させることができます。そして、妥協することなくすべてのデータ効率化技術 (重複排除、圧縮、イレイジャーコーディング) を利用することができます。

 

Nutanixはまた、複雑な管理や構成なしに、ストレージ容量、パフォーマンス、耐障害性を向上させる独自のストレージ専用ノードの機能を提供しています

 

vSANには、効率的かつパフォーマンスの高い方法でキャパシティを拡張するための基盤となるアーキテクチャがありません。

 

次は、両方のプラットフォームが物理ドライブの障害をどのように処理するかを確認しましょう。


0 replies

Be the first to reply!

Reply