こんにちは。SB C&Sで仮想化製品の技術支援を担当している真砂です。

今回はNutanix Filesの可用性の仕組みと障害時の動作について紹介いたします。

Files障害発生時の動作について

Nutanix Filesは複数のFSVMとVolumesを使い、負荷分散の仕組みが備わっていることを前回の記事にて紹介させていただきました。
この仕組みは障害時の動作においても、大きく関わってきます。

▼クライアントからのアクセスとFSVM、Volumesの関係（前回の記事で紹介）

説明がしやすいようにフォルダなどの要素は除外し、FSVMのIPアドレスとクライアントからのアクセス、Filesで利用されているVolumesだけを記載した以下の図を利用して説明します。

各クライアントはDNSにて名前解決の結果、192.168.1.1 ～ 192.168.1.3いずれかのFSVMに接続してVolumes内のファイルにアクセスしていることがわかります。
この状態で左の1ノードダウンした場合の挙動は以下のようになります。

Filesを利用するクライアントは左側のノードがダウンしたことにより、その上で動作していたFSVMとの接続が失われてしまいます。
このような状態になると、残りのFSVMが接続できなくなったFSVMのIPアドレスを持った仮想NICが作成され、クライアントからのアクセスを継続させます。
また、Volumesに関しても異なるノードで複製され、Volumes内の共有フォルダが利用できる状態を維持します。
※Volumesは各ノードに分散してデータを配置しているため、正確には上記の図とは動きが異なりますが、ここでは説明しやすい形で表現をしています。

実機の検証環境を準備

上で説明した図の状況を実機で確認してみましょう。
以下のような環境を準備しました。

Filesを「EV-Files」という名称で作成し、「共有A」、「共有B」、「共有C」３つの共有フォルダを作成しています。


Volumesの一覧を見ると、Files名が含まれるVolumes名が存在することを確認できます。

SSHにて各FSVMに接続すると、これらのVolumesがマウントされていることが確認できます。

1ノード障害時の動作

上記のFilesが稼働している状況で、1ノードを強制的に停止させてみましょう。



1ノード停止後、稼働しているノード上に存在するFSVMのVolumesを確認すると、停止したノード上のFSVMがマウントしていたVolumesが異なるFSVMで再マウントされていることがわかります。


また、この状態でFSVMのIPアドレスを確認すると、停止したFSVMのIPアドレス[192.168.45.110]が異なるFSVMの仮想NICとして付与されていることも確認できます。

この状態を図で表現すると、以下のようになります。

1ノード停止してから上記の状態になるまで、今回の検証では1分程度で確認ができました。

さらに少し時間が経過すると、停止したFSVMが異なるノードにてHAで再起動されます。


FSVMがHAで再起動されると、障害発生直後に異なるFSVMに紐付けられたVolumesとIPアドレスはもとの状態に戻ります。
ハード障害などによってノードの復旧に時間を要する場合であっても、FSVMの台数は障害前と同じ台数で継続して運用することができるため、Filesのパフォーマンスが低下することはありません。


停止したノードが起動すると、自動的にFSVMのライブマイグレーションが行われ、障害発生前の状態へ戻ります。

　

まとめ

Nutanix FilesはFSVMとVolumesを組み合わせた仕組みにより、負荷分散だけでなく可用性を実現できる機能を提供することができます。
本記事で紹介させて頂いたとおり、ノード障害が発生した場合であってもダウンタイムが非常に短いため、利用クライアントがFilesの障害に気がつくことも少ないと思います。
また、これらの仕組みは構築時・障害発生時どちらにおいても作業者・運用管理者が設定・操作することなく実現できるため、導入が非常に簡単であることも大きなメリットになると考えています。