本記事の原文はもともとNutanix社のStaff Solution Architectで、Nutanix Platform Expert (NPX) #001、
そしてVMware Certified Design Expert (VCDX) #90として活動しているJosh Odger氏によるものです。
原文を参照したい方はNutanix Scalability – Part 5 – Scaling Storage Performance for Physical Machinesをご確認ください。
情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。
当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら。
ネットワールドのNutanix関連情報は、ぜひ当社のポータルから取得ください。
(初回はID、パスワードの取得が必要です)
このシリーズでは私はどれだけレジリエントがNutanix Platformでは素晴らしいか
障害中のあたしい書込みデータ、障害が発生した後にその後のリスクを最小限にするためのリビルドの機能を含めてカバーしていきています。
全てのこの情報にも関わらず、他のベンダーは依然としてNutanixが提供している
リビルドパフォーマンスは問題ではなく、二つのコピーセットが消えたらという？というデータの信頼性という簡単に言え、両方のデータが消える可能性は極めて低いことについて触れていますが、もちろんNutanixはこのようなお客様に対してデータの3重化をサポートしています。
それではパート10に行きましょう。
ここではDiskスクラブとチェックサムという2つお客様はRF2,3の展開が非常にレジリエンシーがありデータロストする可能性がほとんどないという事を学んでいただけるはずです。
ではチェックサムから始めましょう、チェックサムとはなんでしょうか？
チェックサムは書込み操作の間に作成された小さいデータを後に読み込みデータが正しいかを確認します。
一方 Disk スクラブは定期的にデータの一貫性を確認するバックグラウンド処理となり、いかなるエラーでも発生すれば、Diskスクラブはシングルコレクタブルエラーを実施するようになります。
Nutanixは全ての書込み操作(RF2 又は3)へのチェックサムを行い、全てのリード操作でチェックサムを確かめます！この意味はデータの完全性がIOパスの一部で、スキップまたはOFFにされていない事になります。
データの完全性は全てのストレージPlatformの一番の優先事項であり、Nutanixが決して無効にしないオプションなのです。
Nutanixはリードのチェックサムを行っている以上、データがアクセスされると常にチェックされる事となり、もしエラーが発生すした場合はNutanix AOSは自動的にRFコピーからデータを復元しIOのサービス、同時にデータロスが発生しないように修復します。
Nutanixがノード/ドライブまたはExtent(1MB のブロックデータ)から復旧するスピードはデータの完全性には非常に重要な事です。
コールドデータについてはどうか？？
多くの環境では非常に多くのコールドデータを持っており、つまりアクセスが頻繁にされないという事になるため、データのチェックサムが行われず、頻繁にアクセスされないデータのチェックは全くされないことになってしまいます。データがアクセスされない場合、どのようにしてデータを保護するのでしょうか？
単純です、Diskスクラブになります。
フロントエンドの読み込み操作を通しているデータ（VM/Appからの読み込みデータ）に関しては
一日に一回のNutanixのディスクスクラブ実行がコールドデータをチェックします。
Diskスクラブタスクはクラスタ内の全てのDiskへ実施するため、ドライブ障害や、Extent(1M ブロックデータ),データがある2つのディスクの同時障害というような複数の同時障害が発生する可能性は極めて低いのです。これはRF2を利用した場合を仮定しています。
データの障害は完全に直近24時間でデータの読み込みが発生していなかった事、バックグラウンドディスクスクラブが2つのコピーデータに対して実施されていなかったこと、AOSの予測ドライブ障害がドライブ障害を発見できなかった、AOSのPredictiveなドライブ障害がドライブ障害を検知できない、またそこへすでにデータの再保護がされてしまっている事が同時に発生している必要があります。
いま、シナリオが発生したと仮定します、ドライブ障害は破損したデータブロックと同じストアがある必要があり、NX3460などの4ノードの小さいクラスタでさえあっても、ドライブは24となるため可能性は非常にすくなくなります。クラスタが大きくなればなるほど、この可能性は低くなりますし、以前のシリーズでお話したとおり、リビルドの時間は早くなります。
まだとてもリスクがあると感じ、全てのイベントを完全に列挙してからRF3を展開し3ノード障害に加えてデータロスを起こすために奇跡を起こす必要があります。
VSANを展開しているとDisk スクラブは年に一度実行され、VMwareは頻繁にチェックサムをOFFにする事を推奨しています。SAP HANAドキュメントもそうでしたが後にデータロスのリスクがあるため、このドキュメントは更新されています。
#DellEMC & #VMware want you to run #SAP HANA on #vSAN but they can only meet the performance requirements if they disable checksums, which in short puts you at high risk of data corruption.
— Josh Odgers (@josh_odgers) 2018年9月18日
Do not use vSAN - This is beyond a joke
Source: https://t.co/pvNjHMUZPu#CIO #sysadmin pic.twitter.com/IdFuHuzPbX
NutanixはまたDiskスクラブアクティビティを監視する機能があります。
下にあるスクリーンショットは2TB SATAディスクで75%程利用されているDisk ID 126のディスクスキャンを表しています。
AOSはディスクスクラブを保証し、ディスクのサイズに関わらず24時間ごとに実施します。上のスクリーンショットはスキャンが 48158724ms走っているものとなります。 googleによると13.3時間で556459ms(0.15hrs)でETAが完了します。
データが動的に容量、パフォーマンスを基準に分散するADSFの性質と組み合わせると、Nutanix Clusterは各ノードの複数の同時ディスク障害に対応する機能を持っており、チェックサムは全てのリードライト操作で実施され、ディスクスクラブは毎日完了します。プロアクティブなドライブ健康状態の監視はドライブ障害が発生する様々なケースのデータ再保護が行われます。
同じく、ADSFはデータのリビルドを行いRF2を利用していたとしても簡単に素晴らしいレジリエンシーを提供するのです。
まだ満足していない様でしたらRF3へ変更し、よりレジリエンシーを高めるようにしてみましょう。
レジリエンシーファクター,vSANでいうFailure Tolerateを考慮するとき、それぞれ2重化でも動作がことなりますので、間違えないようにしまし、それぞれあったものを検討頂ければと思います。
以下はその他の Josh Odger氏が投稿しているBlogの外部リンクとなります
Index:
Part 1 – Node failure rebuild performance
Part 2 – Converting from RF2 to RF3
Part 3 – Node failure rebuild performance with RF3
Part 4 – Converting RF3 to Erasure Coding (EC-X)
Part 5 – Read I/O during CVM maintenance or failures
Part 6 – Write I/O during CVM maintenance or failures
Part 7 – Read & Write I/O during Hypervisor upgrades
Part 8 – Node failure rebuild performance with RF3 & Erasure Coding (EC-X)
Part 9 – Self healing
Part 10: Nutanix Resiliency – Part 10 – Disk Scrubbing / Checksums
記事担当者 : SI技術本部 カッシー @Networld_NTNX
