概要
当エントリーでは、Nutanix Clusters on AWS (以後NCA)削除時のAWSインフラ視点の注意点について記載します。
画面キャプチャーは執筆時点(2021/10)の内容となり、最新のものと異なる場合がある可能性がある点ご注意ください。
NCA削除の手順について
以下blogの「Nutanix Cluster の削除」を参照ください。
一言でいうとMy Nutanixの画面よりGUIでポチポチとTerminate をするだけのとても簡単な作業です。
NCA削除時にMy Nutanix経由で実行されるAWS APIについて
My Nutanix経由で構築されたAWSリソースが明示的に指定され、好ましい順番で削除処理が実行されていくといったざっくりイメージでOKです。
(参考) 削除時の AWS CloudTrailのイベント
NCA構築時に「既存VPCを指定」して構築された環境の場合は、指定VPC内のNutanixから作成されたリソースすべて、例えば EC2ベアメタルインスタンスは勿論、セキュリティグループや Elastic Network Interface(ENI)や Amazon Elastic Block Store (EBS)、NAT Gatewayといったものも同時に削除が実行されます。
そして、「新規VPC」を指定して構築された環境の場合には、当然ですが対象VPCの削除 も実行されます。
この一言で、AWSに携わる方であれば"とある予感"がすると思いますが、ご想像の通りで
My Nutanix経由で作成されたVPC内にて、手動でリソースを作成したり関連付けをしているモノがあると削除処理が正常に完了しません。
NCAを活用する上で、UVM用のサブネットの作成とネットワーク関連付け作業は必須と言っても良いのでほとんどすべての環境で考慮が必要となってきます。
実際の挙動を把握する
よくある例として、My Nutanix経由でVPCを新規作成した環境に、AWS側で手動作成したUVM用サブネットが存在している状態で NCAの削除 を実行してみます。
図には描画されていないですが、手動作成したUVM用サブネット内には、ENIが1つ作成されています。
ご想像の通り、My Nutanix経由で作成されたリソースは正しい順番で削除処理が進んでいきますが、最後のVPCそのものを削除する 「Delete Vpc」が、先に削除すべきUVMサブネットおよびENIが存在している為に失敗します。
実際のAWS CloudTrail のイベント
最初のDelete Vpcの実施
- October 26, 2021, 10:27:57 (UTC+09:00)
最後のDelete Vpcの実施
- October 26, 2021, 10:57:56 (UTC+09:00)
でしたので、1min間隔で当該APIを実行し続けて、30min経過した際にタイムアウトするといった挙動をするようです。
ここで一点注意なのが、My Nutanix の画面ではタイムアウトしても 表向きは処理が正常完了したように見える 事です。
この後に実際にAWSインフラ側を確認すると、対象VPCとその中のUVM用サブネットだけが抜け殻のように残っている状態でした。
(参考) 残ったAWSリソースの構成図
※上の画面キャプチャーとは別環境のため一部情報が異なります
AWSインフラ管理者として意識すべき事
My Nutanix経由で、NCAの削除処理が正常完了した場合でも、AWS側で関連リソースが全て削除出来ている事の確認を実施すべきです。
更に言うと、その環境に必要な削除手順を踏むべきです。
上で紹介したAWS側で手動作成したUVMサブネットがある構成例にするとお作法的には、
NCA内でVMやらのNutanixリソースを削除 -> UVM用のENIをAWS APIからデタッチし削除 -> UVM用の SubnetをAWS APIから削除 -> 最後に、My Nutanix画面から Cluster を Terminate となります。
まとめ
少しマニアックな内容でしたが、管理者として把握しておきたい注意点についてご紹介しました。
NCAでは、AWSインフラとNutanixインフラの担当やら組織が異なるケースが結構あるかと思いますので、必要な連携作業の1つと捉えて良いでしょう。
