少し前にとあるセミナーでお話した内容をこちらのブログでも紹介したいと思います。
内容はNutanix Filesを構成しているFSVMとVolumesの関係性を検証したものです。
Nutanix Filesの構成
まずはFilesについて簡単におさらいします。
FSVMとVolumes
Filesは最少3台のFilesVM（FSVM）と呼ばれる仮想アプライアンスがNASヘッドとして動作し、クライアントマシンからアクセスが行われます。
ファイルサーバーの領域にはNutanix Volumesが利用され、FSVMにNutanix Volumesがマウントされる形で提供されます。
共有フォルダの種類
FilesではPrismから作成できる標準共有フォルダ（Standard Share）と分散共有フォルダ（Distributed Share）の2種類が存在します。
なお、共有フォルダの種類については過去の記事でも紹介しているので、詳しくはそちらをご覧ください。
タイトル：Nutanix Files（共有フォルダの種類と負荷分散）
https://hanpamonoengineer.blogspot.com/2020/05/nutanix-files_19.html
・標準共有フォルダ（Standard Share）
組織別の多⽬的ファイルサーバー、特に明⽰的な⽬的を持たない雑多なファイルサーバとして汎⽤的な利⽤が可能。
1台のFSVMからデータエクスポートや接続の管理を⾏う。
1台のFSVMからデータエクスポートや接続の管理を⾏う。
・分散共有フォルダ（Distributed Share）
主にVDIなどの移動ユーザープロファイルを格納する⽬的に利⽤するためのファイルサーバーとして利⽤する。
データは複数FSVMに分散配置されます。
データは複数FSVMに分散配置されます。
２つの共有フォルダにおける内部的な動作の違い
標準/分散共有フォルダを作成した際に、内部のFSVMとVolumesの構成と動作について見ていきます。
■標準共有フォルダ
Prismから標準共有フォルダを作成すると、自動的にVolumesが一つ作成されました。
※自動的に作成されたVolumesの名前は[NTNX-{Files名}-UUID…]の命名で作成されます。
作成後、FSVMにSSHにて接続しディスクのマウント状態を確認すると、先程共有フォルダ作成時に自動で作成されたVolumesがFSVM2にマウントされていることが確認できました。
（FSVMはCentOSベースの仮想アプライアンスのため、ターミナルソフトから接続することができます。）
（FSVMはCentOSベースの仮想アプライアンスのため、ターミナルソフトから接続することができます。）
なお、Prism上のVolumesとFSVMにマウントされたディスクを見分ける方法は、末尾の数字で判断できます。
続けて2つ目の共有フォルダを作成します。
2つ目のVolumesはFSVM3にマウントされたことが確認できました。
ここまでの状態を図で表現するとこのようになります。
この状態でアクセスがどのように行われるのか動作テストを行います。
共有フォルダ1のみに対して、複数のクライアントから同時に書き込みをしてみます。
この検証結果から、標準共有フォルダは仕様の通り一つのFSVMと関連付けがされていることが確認できました。
この結果から、一つの標準共有フォルダに負荷が集中するような設計をしてしまうと、思ったよりパフォーマンスが出ないなどの問題が発生してしまうかもしれません。
標準共有フォルダは部署ごとに利用されるような、一般的な用途の利用を想定されています。
しかし先程の結果から人数が極端に多い部署にそのまま一つの共有フォルダを割り当ててしまうと、アクセスが集中してしまいFiles本来のパフォーマンスが発揮出来ない可能性があります。
それを回避する方法として、負荷が集中する共有フォルダは一つ階層を下げたサブフォルダ（例えば課ごと）に分けて標準共有フォルダを作成することで、うまく負荷分散が行われ最大のパフォーマンスを発揮することができます。
■分散共有フォルダ
次に分散共有フォルダを見ていきます。
Prismから分散共有フォルダを一つ作成すると、自動的に15個のVolumesが作成されました。
FSVMのマウント状況を見てみると、各FSVMに5個のVolumes（計15個全て）がそれぞれマウントされていることが確認できます。
先程と同じように、ここまでの状態を図で表すとこの様になります。
こちらもアクセスがどのように行われるのかテストを行ってみます。
分散共有フォルダは移動ユーザープロファイルなどの利用が想定された仕組みなので、クライアントからのアクセスも移動ユーザープロファイル領域としてテストしてみます。
先程の標準共有フォルダと異なり、すべてのFSVMで同様に負荷が発生することを確認できました。
（標準共有フォルダは一つのFSVMが65%ほどの数値を示したのに対して、分散共有フォルダではすべてのFSVMが35%ほどの数値となり、負荷の均一化が行われています。）
この検証結果から仕様のとおり分散共有フォルダを用いることによって、クライアントからのアクセスをそれぞれのFSVMで分散されていることが確認できました。
改めて共有フォルダの違いと用途について
今回の記事の初めでも共有フォルダの利用用途について、説明させていただきましたが最後に改めて・・・
・標準共有フォルダ（Standard Share）
組織別の多⽬的ファイルサーバー、特に明⽰的な⽬的を持たない雑多なファイルサーバとして汎⽤的な利⽤が可能。
1台のFSVMからデータエクスポートや接続の管理を⾏う。
・検証結果から
アクセスが極端に集中するような用途のフォルダは、本記事の途中で説明させていただいたようにサブフォルダの階層で分けるなどの設計を推奨します。
・分散共有フォルダ（Distributed Share）
主にVDIなどの移動ユーザープロファイルを格納する⽬的に利⽤するためのファイルサーバーとして利⽤する。
データは複数FSVMに分散配置されます。
データは複数FSVMに分散配置されます。
・検証結果から
複数のFSVMで負荷分散されるため「すべてこれでいいじゃないか」、と思ってしまいますが分散共有フォルダ配下のフォルダに対するアクセス権の設定や手動でのフォルダ作成は別のツールが必要になるなど、管理面でのデメリットが存在します。
分散共有フォルダについて詳しくは、過去の記事「Nutanix Files（共有フォルダの種類と負荷分散）」をご覧ください。
以上でNutanix Filesを構成するFSVMとVolumesについてご説明しました。
次回は障害発生時のFSVMとVolumesの動作について、ご紹介させて頂きます。
0 件のコメント:
コメントを投稿