AOS5.18の新機能（その2）：ストレージ容量の表示改善

AOS5.18からストレージの空き容量や表示方法の変更が行われました。
今日は、新しく改善されたストレージサマリーの改善について紹介致します。

Prismのダッシュボード画面にあるストレージサマリー画面が、よりわかりやすくなりました。最も大きい点は、N+1やN+2の耐障害性を意識した際に、ダウンして良いノードの分のストレージの空き容量を保持しておく必要があります。
今までのPrismでの空き容量表示では、全体のキャパシティに対して80%や90%といった閾値をもとに黄色や赤色で表示されていましたが、実際のNutanixクラスターの構成台数によって、1ノード落ちた際にも問題なく稼動できるパーセンテージは変わってきます。

以下を例にして考えてみましょう。例えば3ノードで構成されたNutanixクラスターがあります。1ノード当たりRF2で20TBの容量を提供できるように構成されています。
この場合、Nutanixクラスターとして利用できるストレージ容量は60TBですが、1ノードの耐障害性に絶えられるためには、1ノード分を差し引く必要がありますので、以下の計算式の通り、40TBまでが利用できる容量となります。

全体ノード(3ノード：20TB×3) ー 耐障害性(1ノード：20TB×1) ＝ 利用できる容量(40TB)

となります。この場合、ストレージ容量を割合で考えると、3ノードのクラスターなので1ノード当たりのストレージ提供容量は33.3333・・・%となります。1ノードの耐障害性に絶えるためには、3ノード中2ノードで稼動できる必要があるため、以下の計算式の通り、「100%ｰ（100%/3)=66.6666・・・%」となります。
すなわち、2台分まで利用可能なので66.6666・・・%までが利用が可能となります。

全体ノード数（3ノード:100%）ー耐障害性ノード（100%/全体ノード:3)＝利用できるストレージ容量パーセント

つまり3ノードの場合における、ストレージの利用上限値は、この構成の場合、66%までが利用可能であり、67%を超える利用量の場合、1ノードの障害に耐えられないことになります。

▼3ノード時における1ノード障害について

一方で、これが4ノードになった場合は、上記の式に当てはめると1ノード当たり25%の割合になるため、1ノード障害時には、75%までストレージを利用することができます。

▼４ノードにおける１ノード障害について



つまり、従来までのストレージですと、90%までストレージを利用していると容量枯渇とか、80％超えたら追加を考えないとといった運用を行うことが出来ましたが、NutanixをはじめとするHCI製品は、ノード障害＝ストレージの部分障害と考える必要があるため、ノード数に応じて、ストレージの何％までを使って良いかが変わってきます。
Nutanixにおいては、ストレージの空き容量がN+1に耐えられなくなった場合、Data Resiliency Statusが、Criticalに変わるため耐障害性がなくなったことを知ることが出来ますが、事前にどの容量まで使って良いかは把握しておく必要があります。
今回AOS5.18から、耐障害性を考慮した際にどこまでのストレージ容量を利用して良いかが閾値の表示が出るように改善されました。

▼Storage Summaryに閾値が表示されている


実際にPrismの画面では、StorageSummaryで、このクラスターで耐障害性（N+1）を保つために利用して良いストレージの容量はどこまでかと、閾値を基準にグラフの色が変わるように変更されました。

小さな変更点かも知れませんが、ストレージの使いすぎてしまい、ノードに障害が発生してしまった際にクラスターが一時的に停止してしまうような事故を、この機能により防ぐことが可能です。（もちろん利用者側の意識がないといけませんが）

このスクリーンショットの環境では、3ノードでN+1の構成で、ストレージの使用率は閾値に近い黄色で表示されています。この環境で1ノードを追加を行うと、両々の表示がグリーンに変わったことが分ります。４ノードにおいて１ノード障害が起きてもこの使用量であれば、問題が無いことがわかります。今までの全体容量に対する使用率％ではなく、ノード数に応じて、耐障害性を考慮した使用率表示に変わっていることがこのことから分ります。

▼同じストレージ利用率で４ノード時の表示

なおこのワーニングの設定値は、Storage Summaryのギアマークから変更することも出来ます。（これは、冗長化を加味した上での利用できる容量の75％となります）

また、View Detailsをクリックすると、実際にトータルのストレージ容量、現在利用している容量、耐障害性を考慮した際に利用できる容量をそれぞれ確認することが出来ます。

HCIにおいては従来のストレージと空き容量の考え方が考え方がすこし違うところがあります。この違いに気づきやすいようにAOS5.18のPrism空はこのように、ストレージの利用率についてわかりやすい表示で、運用におけるトラブルが発生しないように工夫がなされています。

AOS5.18の新機能（その1）：仮想マシンゴミ箱機能の紹介

 AOS 5.18から仮想マシンを削除した場合、24時間以内であれば復活させることが出来る機能が搭載されました。

今回はこのゴミ箱機能について見ていきたいと思います。

まずこのゴミ箱機能の基本は、以下となります。

• ゴミ箱機能はデフォルトで有効です
  
• クラスターのストレージ空き容量が重要な閾値に達しない限り、コンテンツを最大24時間保持します。

ゴミ箱機能は、デフォルトで有効になっているとのことですが、ゴミ箱機能が不要の場合、以下のコマンドをCVMで実行することでゴミ箱機能を無効にすることが出来ます。

recycle_bin -operation update_time_to_live -recycle_bin_ttl_secs -1

なお、ゴミ箱設定は、「container_name」を指定することで、ストレージコンテナごとに設定することも出来ます。
ゴミ箱を空にするタイミングは、デフォルト24時間のようですが、-recycle_bin_ttl_secsを変更することで時間を変更することも可能です。

▼ストレージコンテナ「STG01」で48時間まで仮想マシンをゴミ箱で保持するコマンド

recycle_bin -operation update_time_to_live -recycle_bin_ttl_secs 172800 -container_name STG01

ゴミ箱を空にするには以下のコマンドを実行します。
この例では、ストレージコンテナ「STG01」のゴミ箱を空にしようとしています。

recycle_bin -operation delete -container_name STG01 -delete_all 

すると、以下のようにZookeeperとのやりとりが出力されたあと、Y/Nの質問受けますので、Yを入力することでゴミ箱が削除されます。

ainer_name STG01 -delete_all

I20200830 03:17:40.660087Z  1950 medusa.cc:1275] CreateGlobalMedusaBinaryLoggerRegistry
2020-08-30 03:17:40,661Z:1950(0x7fb8fa20ad00):ZOO_INFO@log_env@960: Client environment:zookeeper.version=zookeeper C client 3.4.3
2020-08-30 03:17:40,661Z:1950(0x7fb8fa20ad00):ZOO_INFO@log_env@964: Client environment:host.name=ntnx-17sm6c100126-a-cvm
2020-08-30 03:17:40,661Z:1950(0x7fb8fa20ad00):ZOO_INFO@log_env@971: Client environment:os.name=Linux
2020-08-30 03:17:40,661Z:1950(0x7fb8fa20ad00):ZOO_INFO@log_env@972: Client environment:os.arch=3.10.0-1127.13.1.el7.nutanix.20200722.cvm.x86_64
2020-08-30 03:17:40,661Z:1950(0x7fb8fa20ad00):ZOO_INFO@log_env@973: Client environment:os.version=#1 SMP Wed Jul 22 01:48:43 UTC 2020
2020-08-30 03:17:40,661Z:1950(0x7fb8fa20ad00):ZOO_INFO@zookeeper_init@1008: Initiating client connection, host=zk3:9876,zk2:9876,zk1:9876 sessionTimeout=20000 watcher=0x55f8f1524200 sessionId=0 sessionPasswd=<null> context=0x55f8f4078040 flags=0
I20200830 03:17:40.661561Z  1950 zeus.cc:2062] recycle_bin is attempting to connect to Zookeeper
2020-08-30 03:17:40,663Z:1950(0x7fb8fa066700):ZOO_INFO@zookeeper_interest@1954: Connecting to server 192.168.XXX.YYY:9876
2020-08-30 03:17:40,663Z:1950(0x7fb8fa066700):ZOO_INFO@zookeeper_interest@1991: Zookeeper handle state changed to ZOO_CONNECTING_STATE for socket [192.168.XXX.YYY:9876]
2020-08-30 03:17:40,663Z:1950(0x7fb8fa066700):ZOO_INFO@check_events@2191: initiated connection to server [192.168.XXX.YYY:9876]
2020-08-30 03:17:40,670Z:1950(0x7fb8fa066700):ZOO_INFO@check_events@2239: session establishment complete on server [192.168.XXX.YYY:9876], sessionId=0x27428bdbfab48ff, negotiated timeout=20000
I20200830 03:17:40.670706Z  1954 zeus.cc:2124] Received new client id: 0x27428bdbfab48ff
I20200830 03:17:40.670790Z  1954 zeus.cc:617] Connected to Zookeeper instance 192.168.XXX.YYY:9876
I20200830 03:17:40.670869Z  1950 zeus.cc:341] Zookeeper client health notification enabled
I20200830 03:17:40.670938Z  1950 zeus.cc:3207] Scheduling next shuffle leadership intent routine after 240 seconds
I20200830 03:17:40.670981Z  1950 zeus_connector.cc:169] Started zeus_connector with session id 27428bdbfab48ff
I20200830 03:17:40.672344Z  1954 zeus_configuration_ops.cc:588] Established Zeus watch id 0
I20200830 03:17:40.673498Z  1954 zeus_configuration_ops.cc:697] ReadConfigurationOp(0)[watch_cbks:1 watch_id:0 convert_ssd:1 sync:0]: Found config with timestamp 1056279
I20200830 03:17:40.673553Z  1954 zeus_connector.cc:377] Received a Zeus configuration update.

Clearing all recycle bin contents for container STG01
Proceed? (y/n) y

Clearing recycle bin for container STG01
I20200830 03:17:49.262601Z  1952 tcp_client.cc:293] Setting up new connection with 127.0.0.1:2049

I20200830 03:17:49.263690Z  1952 recycle_bin.cc:140] Recycle bin DeleteAll operation completed

I20200830 03:17:49.263725Z  1950 recycle_bin.cc:458] Exiting
I20200830 03:17:49.263742Z  1950 zeus_connector.cc:183] Closing down zeus_connector with session id 27428bdbfab48ff
I20200830 03:17:49.263751Z  1950 zeus.cc:355] Destroying Zeus
2020-08-30 03:17:49,364Z:1950(0x7fb8fa20ad00):ZOO_INFO@zookeeper_close@3104: Closing zookeeper sessionId=0x27428bdbfab48ff to [192.168.XXX.YYY:9876]
I20200830 03:17:49.464782Z  1950 tcp_connection.cc:645] TcpConnection with fd 12, conn_id 0 waiting for quiescing callbacks peer info 127.0.0.1:2049:TCP
I20200830 03:17:49.464963Z  1950 tcp_connection.cc:657] TcpConnection with fd 12, conn_id 0 wait for quiescing callbacks finished  peer info 127.0.0.1:2049:TCP

標準出力の中に、オペレーションが必要なメッセージやステータスのメッセージが紛れているので見づらいのですが、メッセージを見ながら確認をしていく必要があります。

なお、Prismから仮想マシンを作成した場合、今までの画面と同じ画面で特に変更はありません。

実際にストレージコンテなのかを見ると、「.nutanix_recycle_bin」というディレクトリが新たに出来ていることが分ります。

この「.nutanix_recycle_bin」内に、削除した仮想マシンの構成情報と仮想ディスクが移動していることが分ります。

「.config」の拡張子は、仮想マシンの設定ファイルで、UUIDで表示されているのが仮想ディスクのようです。

なお、Prismを使用せず、ストレージコンテナのファイルを直接ファイル操作オペレーションで削除した場合においても、自動的に「.nutanix_recycle_bin」フォルダに移動します。


recycle_binコマンドには、実際に「-operation」に「restore」というオプションパラメーターが有り、「-source_path」と「-restore_path」のパラメーターがありファイル自体のリストアは出来るようですが、そこから仮想マシンとして再登録するオプションがまだ実装されていないようで、このためリストアにおけるオペレーションは、現行Nutanixサポートに依頼をする必要があります。

AOS 5.18の新機能を紹介

 AOS5.17がリリースされたまだ日が浅いですが、STSは3ヶ月おきのリリースがベースとなっているため、8月末にAOS 5.18がリリースされました。

AOS5.18にも多くの新機能が搭載されています。

• Leap機能利用時のSelf Service Restore(SSR)のサポート
  Asycn DRでなくLeap機能を利用したスナップショット取得時に、SSRをサポートします。なお、NearSyncは未対応ですが、
  
  
• ストレージコンテナのインライン圧縮のデフォルト有効化
  今まではストレージコンテナを新規作成すると、自動的に、Compression（圧縮）のチェックが有効でDelayが60でデフォルト値で表示されます。Compressionは、AOS Starterエディションすなわちどのエディションでも利用が可能ですが、Delayが0より大きい値の設定がなされると、ポストプロセス圧縮となりAOS Proライセンス以上が必要となります。そのため、AOS Starterライセンスでデフォルト値のままストレージコンテナを作成すると、ポストプロセス圧縮の設定となってしまいライセンスに抵触しているというアラートが出ていましたが、今回変更によりAOS Starterでデフォルトのコンテナ作成時に謝ってライセンスに抵触してしまうようなことは無くなりました。
  既に作成しているストレージコンテナに対して設定が変わることはありません。
  なおNutanixでは、パフォーマンスに影響がないため圧縮を有効にすることを推奨しています。
  
  
• クロスハイパーバイザーDR（ESXi → AHV）でのNearSyncをサポート
  クロスハイパーバイザーDRにおいては、今までAsync DRでのサポートとなり最短のRPOは1時間でした。今回の変更により、NearSyncでのレプリケーションをサポートしました。
  
  
• Nutanix Objectsでイレイジャーコーディングをサポート
  アーカイブデーターなど長期保存を目的とする利用の場合、Nutanix ObjectsによるS3互換のオブジェクトストレージ機能を利用も検討すると良いと思います。データーの長期保管となると、必要とするストレージ容量も多くなるためストレージ容量の効率的な利用が求められます。Nutanixには圧縮・重複排除の他にイレイジャーコーディング機能を保有しています。今回Nutanix Objects利用時において、ストレージコンテナにイレージャーコーディングが利用できる用になりました。
  
  
• ゲストVM削除時の復元機能
  仮想マシンを誤って削除した場合24時間以内であれば復元する「ゴミ箱」機能が搭載されました。なお、現バージョンでは仮想マシンのリストアはNutanixサポートに依頼をする必要があります。本機能は次回に詳細にお伝えしたいと思います。
  
  
• ストレージコンテナにおける仮想ディスク単位の消費情報表示
  いままでは、ストレージコンテナレベルでの空き容量や使用容量はわかりましたが、どの仮想マシンやVolumeGroupがどれぐらいの容量を消費しているのかを確認するには、仮想マシン一覧からそれぞれの容量を確認するしかありませんでした。
  今回PrimsのStorage画面から、ストレージコンテナごとにどの仮想ディスクがどれぐらいの容量を消費しているのかを確認が出来るようになりました。
  
  ▼仮想ディスクファイルごとの割当・消費容量一覧
  
  
  
  
• ログタイムスタンプの変更
  通常利用時には気にする必要は無い機能ですが、NutanixのログはCVMのタイムゾーンで出力されるものが一部ありましたが、今回の変更で全てログはUTCタイムゾーンで記録されるようになりました。
  
  
• NVMeドライブの活性交換時の動作改善
  AOS5.18からNVMeドライブ交換時にCVMが再起動するという仕様が変更となり、CVM再起動せずにNVMeドライブが交換できるようになりました。（CVMが再起動するのは、ディスクドライブが見えなくなった際にディスクを再度検知するためOSレベルで再起動する仕様であり、その際仮想マシンは他のCVMのI/Oパスを利用して継続稼動するため、稼動している仮想マシンにはCVMが再起動しても動作に影響はありませんでした）
  なお、本機能は、AHVのみのサポートとなります。
  
  
• UEFIサポートの強化
  ハードウェアUEFIセキュアブートが有効になっているホストで、ESXiのセキュアブートがサポートされました。
  
  
• NGTの下位互換サポート
  ゲストVMよりもCVMのNGTバージョンが低い場合でも、NGTを引き続き利用することができます。
  
  
• NGTにおけるPython2からPython3への変更
  こちらも、ユーザーサイドとしては特に変わりは無いのですが、NGTのバイナリがPython3対応となりました。
  
  
• OVAのサポート
  PrismCentaralを介して、AHV仮想マシンにおけるOVAエクスポート機能及ぶ、OVAインポートが可能となりました。
  AHV環境の場合仮想マシンを一時的に、ファイルとして保存したい場合などにエクスポートする機能が無く、サードパーティーのバックアップソフトを利用する等を行う必要がありましたが、今回の機能追加により、OVAでの吐き出しが可能となりました。

AOS 5.18には様々な機能が追加されていることが分ります。

次回以降では機能絞って特徴を見ていきたいと思います。