前回、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のストレージコンテナに移動するコマンドを実行した場合どうなるかを試してみました。
実行すると、コマンド自体はエラーもなく通ります。しかし、タスク自体はキューに入ったままで処理されることはありません。（ずっとタスクに残ったままになります）
ということで、ちょっとロックの仕方が甘い気もしますが、仕様通り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」コマンドを実行してみます。
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」というパラメーターが出てきました。
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は、検証等々では便利ですが、制約が多いので、ご利用は計画的に。
