今回Nutanix社から機材を提供頂き、実機検証をする機会をいただきました。
検証結果はついては、【技術白書公開】SAP on Nutanix 基本性能検証結果報告書からダウンロード可能ですが、そこに書きれなかった内容を補足説明させて頂きます。
Nutanixは複数サーバーでクラスター構成をとりますが、外部ストレージを必要としません。
Distributed Storage Fabric(DSF)と呼ばれる独自の分散ストレージの仕組みにより、各サーバーの内蔵ディスクをまとまった領域として、可用性も確保したうえでHypervisorに提供します。
DSFをHypervisorから利用するためには、各ディスクをストレージプールに組み込み、そこからストレージコンテナを切り出すという手順が必要となります。
可用性の維持は、ストレージコンテナにRedundancy Factor(データへのアクセス不可となり得る障害箇所の数)を設定して実現します。Redundancy Factorが2の場合は、異なるノードの2本のディスクにデータを保存し、3の場合は異なるノードの3本のディスクにデータを保存するというのが基本動作ですので、複製数(Replication Factor)と考えていただいてもある程度あっています。説明の歯切れが悪いのは、Erasure CodingというParityを利用するRAID5タイプのオプションがあり、これを念頭に置くと複製数という説明が正しくなくなるためです。
ここまでの説明でLinuxに馴染みのある方はピンと来たかもしれませんが、DSFの考え方はLVMと同様です。LVMもディスクをVolume Groupに組み込んで、Logical Volumeを切り出す仕組みですので、それをサーバー跨ぎで構成できるのがDSFと捉えていただくとイメージしやすいかもしれません。
DSFには性能面も考慮した動作が実装されています。下図はRedundancy Factor 2の動作を示しています。VMからの書き込み処理は各サーバー上のController VM(CVM)が処理し、自サーバーと別のサーバーにデータを書き込みます。そして、データを読み出す場合はすべて自サーバーから読み出します。
では、VMが別サーバーに移動した場合はどうなるかというと、下図のように、VM移動直後は別サーバーからのディスクの読み出しが発生しますが、一定期間後はVMが稼働するサーバーへデータが集約されるようになります。
万一、内蔵ディスクサイズを超えるデータ量になった場合は、使用頻度の低いデータを別サーバーのディスクに移動するといった階層化機能も備えており、SSDとHDDが混在する構成の場合は、SSDを優先して利用するよう動作します。SAPのようなデータベースを利用するシステムの場合、データベースの整合性チェックや再編成等の運用処理によって、データ全体へのアクセスする場面がありますので階層化機能が効率的に機能しない可能性があるため、すべてのディスクをSSDで構成するオールフラッシュ構成を推奨します。
DSFの動作に話を戻しますと、書込み動作にはさらなる工夫があり、書き込みのデータはoplogという書き込みリクエストの状態で各サーバーのシステム領域に書き込まれ、この段階で書き込みが完了します。Oplogの内容がデータ領域の本来あるべき場所へ書き込まれるのは、別のタイミングで処理される仕組みとなっています。DBMSがコミット時にトランザクションログに書き込み、その後データへ書き込むのと同様の動きですね。
記事が長くなってきましたので、バックアップについては次回とさせていただきます。
