本記事の原文はもともとNutanix社のStaff Solution Architectで、Nutanix Platform Expert (NPX) #001、
そしてVMware Certified Design Expert (VCDX) #90として活動しているJosh Odger氏によるものです。
原文を参照したい方はNutanix Resiliency – Part 2 – Converting from RF2 to RF3をご確認ください。
情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。
当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら。
ネットワールドのNutanix関連情報は、ぜひ当社のポータルから取得ください。
(初回はID、パスワードの取得が必要です)
パート1ではAcropolis Distributed Storage Fabric (ADSF)のおかげで効率よく素早くノード障害からリビルドを行えるというNutanixAOSの能力について話しました。
パート2ではストレージコンテナがどのようにしてRF2からRF3に変換できるか、そして完了までにかかる速度をお見せしたいと思います。
このテストでは12台のノードでクラスタを作成しています。
ストレージプールの使用率を確認しながら始めましょう
現在50TB以上のストレージがクラスタ内で利用されています。
RF3へするには単純にすべてのデータに3つ目の複製を追加するかです。
当然それを実施するだけの十分な容量を持っておく必要があります。
次にRedundancy Factor（FTレベル）をRF3に増やします。
これによりRF3のコンテナがサポートできるようになり、少なくても2ノードの障害でも稼働できるようになります。
次にストレージコンテナをRF３にします。
一度コンテナがRF3にセットしてまえば、CuratorがクラスタのRedundancy factorに従いバックグラウンド処理で追加の複製を作成します。
この例では凡そ50TBのデータがストレージプールにあるので、この処理では50%の複製が実施されることになるので75TBのデータ量になる事となります。
3時間以内のプロセスでは7GBps以上のスループットが出ていることが確認でき、1h/約8.3TBとなります。
クラスタが完全にRF2レベル冗長性を維持しながら、このRF3への変換プロセスの間に新しいデータが書き込みがされた場合、そのデータはRF3として作成され、保護されるという事が大切です。
下のチャートはストレージプール利用率がリニアに増えていくことを示しています。
クラスタサイズが大きくなれば、この処理にかかる時間は早くなるという事が大事なことで、ADSFが本当の分散ストレージファブリックであり、ノードが増えれば増えるほどコントローラが多くの書き込みを処理できるです。
素晴らしいノード追加の例はScale out performance testing with Nutanix Storage Only Nodesをご覧ください(英語サイト)
処理が完了するとストレージプールは予想していた75TB程度になっています。
NutanixADSFがどの程度このドライブに対して処理をさせているか興味を持っている方の為に、実行中のいくつかのステータスを取得しました。
解ることは物理ディスクが単一のキャッシュドライブでインテリジェントでないHCI環境のように容量のオフロードされているのではなく、最大限にリードライトをすべてのドライブにまたがって利用しているという事です。
Summary:
- Nutanix ADSF can change between Redundancy levels (RF2 and RF3) on the fly
- A compliance operation creating >25TB of data can complete in less than 3 hours (even on 5 year old equipment)
- The compliance operation performed in a linear manner throughout the task.
- A single Nutanix Controller VM (CVM) is efficient enough to drive 6 x physical SSDs at close to their maximum ability
- ADSF reads and writes to all drives and does not use a less efficient cache and capacity style architecture.
記事担当者 : SI技術本部 カッシー @Nutanix_NTNX
