AOS6.0.1からサポートされたReplication Factor 1を試してみる

前回、AOS6.0.1からサポートされたRF1(Replication Factor 1)についてご紹介しました。前回は、うまく仮想マシンを作成できずに終わったのですが、今回RF1環境で仮想ディスクを作成することが出来ましたので、今回は、RF1での実際の動作についてご紹介します。

仮想ディスクにRF1のストレージコンテナを選択した場合

仮想マシンを作成時に、RF1のストレージコンテナの仮想ディスクを割り当てた仮想マシンは、Prismの仮想マシン一覧にも「RF1」と表示されます。

なお、通常のRFのストレージコンテナの仮想ディスクを割り当てている仮想マシンに、RF1のストレージの仮想ディスクを割り当てても、同様にこの「RF1」が表示されます。

Volume Groupの作成は可能か？

VolumeGroupで、RF1のストレージコンテナは選択可能かを試してみました。サラッと作成可能です。なお、仮想マシンと同様に一覧表示でRF1であることを確認することが出来ます。

RF1で作成した仮想マシンは、Live Migration可能か？

ホストに紐付いたストレージにデーターが書き込まれることを考えると、Live Migrationによる仮想マシンの稼働ホストを変更するのは無理かと思ったのですが、実はLive Migrationできます。あくまでもデーターが保存される場所が特定ホストに限定されるだけであり、このRF1のストレージは、共有ディスクで提供され、Nutanixクラスター内の各ホストにLive Migrationすることができます。

仮想ディスクをRF2のコンテナに移動できるか？

AOS 5.19からAHVに搭載された、仮想ディスクのストレージコンテナ間移動を利用して、RF1のストレージコンテナにある仮想ディスクをRF2のストレージコンテナに移動するコマンドを実行した場合どうなるかを試してみました。

vm.update_container RF1-TESTVM container=DEFAULT_CONTAINER wait=false

実行すると、コマンド自体はエラーもなく通ります。しかし、タスク自体はキューに入ったままで処理されることはありません。（ずっとタスクに残ったままになります）

ということで、ちょっとロックの仕方が甘い気もしますが、仕様通りRF1で作成した仮想ディスクを他のストレージコンテナに移動することは出来ないということになります。

DataProtectionでRF1の仮想ディスクを持った仮想マシンは保護できるのか？

仕様上、RF1の仮想マシンはスナップショット作成はサポートされていないという記載があります。実際にProtection Domainで保護を行おうとしたのですが、仮想マシンの一覧候補画面から、RF1の仮想マシンが除外される設定になっています。そのため、RF1の仮想マシンを保護対象に入れることは出来ません。

では、RF2のストレージコンテナの仮想ディスクを割り当てた仮想マシンを、Protection Domainに入れ、その後その仮想マシンにRF1の仮想ディスクを割り当てた場合はどうなるのでしょうか？
結論としては、仮想マシン自体のProtection Domainに該当の仮想マシンが残ったままとなりますが、Take Snapshotで意図的にスナップショットを作成しようとした場合、処理自体は実行されますが、実際にはスナップショット処理はスキップされた旨のアラートが発生します。

では、Protection DomainAHVの仮想マシンスナップショットではどうなるのかを確認したところ、スナップショットエラーのメッセージが表示されます。

スナップショットはRF1の場合、Protection Domainであっても、普通の仮想マシンスナップショットであってもいずれも取得できないということになります。

RF1ストレージコンテナのホスト上にあるCVMをシャットダウンした場合どのような動作になるか？

RF1の場合、特定のホストのストレージにしかデーターが書き込まれませんので、該当ホストのCVMがいなくなるとホストのSSDやHDDにアクセスできなくなるので、I/O処理が出来なくなるはずです。RF2など通常のストレージコンテナで動作しいている仮想マシンは、CVMがいなくなると、自動的にハイパーバイザーが別のCVMにパスを切り替えてI/Oを継続させる仕組みとなっているため影響はありません。
今回はCVMを正常にシャットダウンする、「cvm_shutdown -P」コマンドを実行してみます。

nutanix@NTNX-21SM9C999999-A-CVM:192.168.XXX.171:~$ cvm_shutdown -P now
2021-08-27 12:29:23,979Z INFO MainThread zookeeper_session.py:193 cvm_shutdown is attempting to connect to Zookeeper
2021-08-27 12:29:23,984Z INFO Dummy-1 zookeeper_session.py:625 ZK session establishment complete, sessionId=0x27b86ada51404b1, negotiated timeout=20 secs
2021-08-27 12:29:24,032Z INFO MainThread lcm_genesis_utils.py:47 Rpc to [192.168.XXX.172] for LCM [LcmFramework.is_lcm_operation_in_progress] is successful
2021-08-27 12:29:24,033Z INFO MainThread cvm_shutdown:174 No upgrade was found to be in progress on the cluster
2021-08-27 12:29:24,197Z INFO MainThread cvm_shutdown:91 Acquired shutdown token successfully
2021-08-27 12:29:24,438Z CRITICAL MainThread cvm_shutdown:206 Found powered on VMs with RF1 disks managed by the current CVM. Please proceed to shutdown with --auto_shutdown_rf1_vms flag, and the system will attempt to shut them down before proceeding with CVM shutdown. RF1 VMs: RF1-TESTVM

どうやら、RF1の仮想マシンがいるためシャットダウンが出来ない旨が表示されています。合わせて「--auto_shutdown_rf1_vms」というパラメーターが出てきました。

では、「shutdown -P now --auto_shutdow_rf1_vms」を実行してみましょう。

nutanix@NTNX-21SM9C999999-A-CVM:192.168.XXX.171:~$ cvm_shutdown -P now --auto_shutdown_rf1_vms
2021-08-27 12:36:40,467Z INFO MainThread zookeeper_session.py:193 cvm_shutdown is attempting to connect to Zookeeper
2021-08-27 12:36:40,472Z INFO Dummy-1 zookeeper_session.py:625 ZK session establishment complete, sessionId=0x17b86ada50204e9, negotiated timeout=20 secs
2021-08-27 12:36:40,512Z INFO MainThread lcm_genesis_utils.py:47 Rpc to [192.168.XXX.172] for LCM [LcmFramework.is_lcm_operation_in_progress] is successful
2021-08-27 12:36:40,513Z INFO MainThread cvm_shutdown:174 No upgrade was found to be in progress on the cluster
2021-08-27 12:36:40,560Z INFO MainThread cvm_shutdown:91 Acquired shutdown token successfully
2021-08-27 12:36:40,842Z INFO MainThread cvm_shutdown:217 Found powered on VMs with RF1 disks managed by the current CVM. The system will attempt to automatically shut them down before proceeding with the CVM shutdown. RF1 VMs: RF1-TESTVM
2021-08-27 12:36:40,842Z INFO MainThread cvm_shutdown:116 Validating command arguments.
2021-08-27 12:36:40,842Z INFO MainThread cvm_shutdown:119 Executing cmd: sudo shutdown -k -P now
2021-08-27 12:36:41,005Z INFO MainThread cvm_shutdown:99 Setting up storage traffic forwarding
2021-08-27 12:36:41,016Z WARNING MainThread genesis_utils.py:145 Deprecated: use util.cluster.info.get_factory_config() instead
2021-08-27 12:36:41,021Z INFO MainThread genesis_utils.py:3192 Verifying if route is set for 192.168.XXX.171
2021-08-27 12:36:41,445Z INFO MainThread genesis_utils.py:3197 HA Route is not yet set for 192.168.XXX.171
2021-08-27 12:36:43,824Z INFO MainThread genesis_utils.py:3197 HA Route is not yet set for 192.168.XXX.171
2021-08-27 12:36:46,249Z INFO MainThread zookeeper_session.py:193 cvm_shutdown is attempting to connect to Zookeeper
2021-08-27 12:36:46,253Z INFO Dummy-2 zookeeper_session.py:625 ZK session establishment complete, sessionId=0x37b86b195f204c9, negotiated timeout=20 secs
2021-08-27 12:36:46,266Z INFO MainThread genesis_utils.py:1948 The CVM 192.168.XXX.171 is not in maintenance mode
2021-08-27 12:36:46,281Z INFO MainThread cluster_upgrade.py:824 ZK path /appliance/logical/genesis/rf1_vms is empty for SVM 3
2021-08-27 12:36:46,310Z INFO MainThread ahv_rf1_api_impl.py:258 Sending acropolis task HandleRf1VmBeforeAosMaintenance to SVM ID 3 to listed RF1 VMs, task_uuid 7fc7b917-d161-49a6-bc17-9dbdef499e05
2021-08-27 12:36:46,313Z INFO Dummy-3 client.py:232 Creating stub for Ergon on 192.168.XXX.171: 2090
2021-08-27 12:36:46,688Z INFO MainThread cluster_upgrade.py:844 Setting RF1 VM list into the ZK path /appliance/logical/genesis/rf1_vms for SVM 3, VM UUID list: ['90ba4083-ad15-40d2-8434-a1d299bacdd0']
2021-08-27 12:36:46,713Z INFO MainThread ahv_rf1_api_impl.py:258 Sending acropolis task HandleRf1VmBeforeAosMaintenance to SVM ID 3 to shut down RF1 VMs, task_uuid bbcd24f6-3ec2-4fed-b71e-d444fa2320de
2021-08-27 12:37:18,329Z INFO MainThread cluster_upgrade.py:851 Successfully complete handling RF1 VMs task before CVM 3 shutdown
2021-08-27 12:37:18,340Z INFO MainThread genesis_utils.py:1810 Adding entry of planned_outage in planned_outage_history
2021-08-27 12:37:18,341Z INFO MainThread genesis_utils.py:1870 Planned outage entry is start_time: 1630067838

reason: "CVM shutdown"

2021-08-27 12:37:18,348Z INFO MainThread configuration_validator.py:962 Did Configuration Validator succeed : True
2021-08-27 12:37:18,394Z INFO MainThread genesis_utils.py:1826 Configured CVM 192.168.XXX.171 with maintenance mode status True
2021-08-27 12:37:18,399Z INFO MainThread cluster_upgrade.py:905 Stopping all services before reboot
2021-08-27 12:37:18,399Z INFO MainThread cluster_upgrade.py:905 Stopping all services before reboot
2021-08-27 12:37:54,131Z INFO MainThread cluster_upgrade.py:914 Attempting to stop any remaining services forcefully!
2021-08-27 12:37:54,141Z INFO MainThread service_utils.py:1097 No process has lock_path /home/nutanix/data/locks/catalog open
...

RF1の仮想マシンが自動でシャットダウンされた後、CVMは正常にシャットダウンされました。

なお、CVMが復活すると自動でシャットダウンされたRF1の仮想マシンが起動します。この動作からすると、アンチアフィニティルールが指定されている仮想マシンが、ハイパーバイザーのアップデートなどでライブマイグレーションが出来ない仮想マシンをシャットダウンし、アップデート完了後に起動する動作と同じ挙動のように思われます。

では、RF1で作成したVolume Groupを他のホストでRF2で稼動中の仮想マシンにSCSI Direct Attachすると、この仮想マシンもシャットダウンされるのかも確認してみたところ、SCSIダイレクトアタッチでVolumeGroupのディスクをマウントした仮想マシンは正常にシャットダウンされました。（おそらくiSCSI経由の接続の場合、OS制御が出来ませんので無視してシャットダウンされると思われます）

少しだけですが、RF1の挙動について調べてみました。Nutanix上ではRF1の利用は制約があることから制約のロックもそれぞれUIレベルで行われていることが分かりました。

PrismのData Resiliency Status部分には、RF1の仮想ディスクが幾つ存在するかも数量が表示されています。

RF1は、検証等々では便利ですが、制約が多いので、ご利用は計画的に。

AOS6.0.1からサポートされたReplication Factor 1について

先日AOS 6.0リリースの紹介をしましたが、AOS6.0.1から新たにサポートされる機能があります。それは「Replication Factor 1」です。

本来、データーの冗長性から考えてデーターを二重化（ないしは三重化）しないというのは、大事なデーターを保存する上であり得ない話しですが、逆に言うと大事ではないデーターを二重化するのは、ストレージ容量がもったいないと考えることも出来ます。極端な話し消えても問題ないデーターを保存する際に、このRF1を活用するという物です。

かといって、RF1を多用すると確実に事故が発生しますので、Nutanixでは、RF1の利用について厳しく制限が設けられております。

• RF1コンテナは、レプリケーション係数の増加をサポートしていません。
  （RF1からRF2への変更）
• RF1コンテナは、AHVイメージサービスで利用するISOやDISKの保存をサポートしていません。
• RF1コンテナでは、Reserved Capacityの設定は許可されていません。
• ホストのメンテナンス作業を行う場合、RF1の仮想マシンは停止する必要があります。（RF1の仮想マシンは、ライブマイグレーションできません）
• AHV/ESXi環境のみをサポートします。HyperV環境はサポートされていません。
• パフォーマンス上の理由から、SSD層の容量がクラスター容量の6％未満であるクラスターにRF1ストレージを構成することはお勧めしません。
• RF1の仮想マシンは、スナップショットやレプリケーションはサポートされていません。
• ESXiクラスターをAHVクラスターに変更は､サポートされません。
• イレイジャーコーディングや重複排除は、RFストレージコンテナではサポートされません。
• ストレージコンテナのゴミ箱機能はサポートされず削除したデーターは即座に削除されます。
• RF1 vDiskを備えたVMは、DRおよびMetro-Clusters環境ではサポートされていません。
• 以下のメンテナンスを行う場合、RF1の仮想マシンはシャットダウンする必要があります。
• ワンクリックのAOSアップグレード
• CVMのシャットダウン
• ホストのメモリの更新
• ESXワンクリックハイパーバイザーのアップグレード
• ネットワークセグメンテーションワークフロー
• ローリングリブートフレームワーク（AHVでの仮想スイッチサポートの有効化）
• ホストブートディスクの交換

ここで重要なことは、AOSのアップグレードであっても、RF1の仮想マシンはシャットダウンしなければいけないというのは、気になる表現です。

これは、RF1のストレージコンテナは、ノード毎に作成されるという仕様に起因しています。そのため、RF1で作成した仮想マシンはノードのローカルストレージで動作している形になりますので、ライブマイグレーションが出来ないという制限事項があります。

そのため、以下のような制限が発生します。

• ノードの削除-RF1のあるノードをクラスターから削除すると、RF1vDiskとコンテナーに削除されます
• ノードの一部のディスクやフラッシュが故障し交換した場合、RF1の仮想マシンは削除されます。
• ストレージ専用ノードを搭載したクラスターの場合、コンピュートノードのにのみRF1のストレージコンテナを作成できます。

Nutanixの各アプリケーションもサポート可否が明確に記載されています。

Nutanix Era / Files / Carbon /Objects  / Prism Central

RF1ストレージコンテナを領域の一部で利用することや、仮想アプライアンス自体をRF1のストレージコンテナに展開することはサポートされていません。

もはやここまで制限されると何の意味があるのかと思う気もしますが、先程記載したとおり、データーを保存する領域ではなく、データーベースのテンポラリーやAI,機械学習のデーターの学習用データーの保存場所としての活用が考えられます。

では、RF1のストレージコンテナの作成方法をご紹介します。

PrismのSettingsから「Redundancy State」を選択し、「Enable Replication Factor 1」にチェックを入れます。

RF1の制限事項が表示されますので確認してYesをクリックします。

元の画面に戻ったら「Save」ボタンをクリックし設定を終えます。

PrismのStorageメニューに進み、「+ Storage Container」をクリックします。

REPLICATION FACTORを選択し「1」を選択します。

すると、ドロップダウンリストが追加されます。このストレージコンテナをどのノードで作成するかの選択肢が追加されます。

予約は出来ないと言う制限がある一方でRESERVED CAPACITYが入力できますが、こちらは値を入れると、設定保存できません。なお、Advatized Capacityは設定可能です。
重複排除やイレイジャーコーディングは、明確に画面上にロックがかかっています。

Saveすればこれでストレージコンテナの作成は完了です。制約事項を除けば、通常のストレージコンテナ作成と何も変わりません。

では、仮想マシンを作成する際にこのRF1のストレージコンテナをどのように選択するのでしょうか？

通常通り仮想マシン画面から「+ Add New Disk」をクリックし、仮想ディスクを作成したいストレージコンテナをドロップダウンリストから一覧を表示させると、RF1のストレージコンテナは、横側にホスト名が表示されます。

AOS 6.0.1は、AOS 6.0.1.1として、8/27にリリース予定となります。

今回AOS6.0.1の環境でRF1の仮想ディスクを作成しようとしたところ、正しく作成が出来ませんでしたので、おそらくAOS6.0.1.1でここも修正されるのではないかと思います。
（本当は仮想ディスク作成後の動作もご紹介したかったのですが...）

RF1の利用は限定的ですが、テンポラリーの仮想マシンや検証用の仮想マシンですぐに削除する物であれば、RF1はリソースの削減として利用可能と思います。（とくに容量単価が高いオールフラッシュの場合は、コスト面のメリットもあります）

ただ、あくまでもデーターの冗長性がないので、データーベースなど大事なデーターを保存する場合には、くれぐれも利用しないようにしてください。