Nutanix FilesのFSVMとVolumesの関係を簡単な検証を含めて調べてみました

1. Filesの内部的な仕組みを調べてみた
2020年8月26日
真砂 暁

2. 2
◆【氏名】真砂 暁（マサゴ アキラ）
◆【生年月日】1991年7月24日（平成３年）
◆【出身地】生まれも育ちも大阪
◆【趣味】釣り・スノーボード・ゲーム・ 飲み会など
◆【経歴】
・学生時代は、4年間システム開発系の専門学校でお勉強。
・2015年、東京のDC事業会社へ新卒入社。2年間VDI製品の構築、保守を担当。
・2017年、大阪のSierに入社し約2年間、中小規模案件にて設計・構築・保守を担当。
・2019年、セールス寄りの領域に挑戦したいと考え、現職の
某通信キャリア系ディストリビューターへ入社。
現在は主に仮想化製品のプリセールスエンジニアとして修行中・・・
ブログ「半端者エンジニアのインフラメモ」やってます。（検索お願いします！）
https://hanpamonoengineer.blogspot.com/

3. 3
Nutanix Filesのおさらい

4. 4
Nutanix HCIの分散アーキテクチャー上で動作するファイルサービスです。
Nutanix HCIと同じように可用性と拡張性、負荷分散に優れた特徴を備えた
ファイルサーバーを利用することが出来ます。
Nutanix Filesについて
FSVM
※FSVMのアイコンです

5. 5
Filesは最少3台のFilesVM（FSVM）と呼ばれる仮想アプライアンスが
NASヘッドとして動作し、クライアントマシンからアクセスが行われます。
ファイルサーバーの領域にはNutanix Volumesが利用され、
FSVMにNutanix Volumesがマウントされる形で提供されます。
Nutanix Filesの構成
Nutanix
Volumes

6. 6
Filesの共有フォルダの種類
・標準共有フォルダ（Standard Share）
組織別の多⽬的ファイルサーバー、特に明⽰的な⽬的を持たない
雑多なファイルサーバとして汎用的な利用が可能。
1台のFSVMからデータエクスポートや接続の管理を行う。
・分散共有フォルダ（Distributed Share）
主にVDIの移動ユーザープロファイルを格納する⽬的に利用するための
ファイルサーバーとして利用する。
データは複数FSVMに分散配置されます。
標準 分散or

7. 7
標準共有フォルダの
FSVMとVolumesの関係

8. 8
Filesから標準共有フォルダを作成すると、自動的にVolumesが作成されます。
Filesから作られるVolumes（標準）
共有フォルダ
共有フォルダを作成したことで
自動的に作成されたVolumes
※Volumesは[NTNX-{Files名}-UUID…]の命名で作成されます。

9. 9
すべてのFSVMを見てみると、1台のFSVMにVolumesがマウントされている。
FSVMのディスク情報を見てみる（標準）
FSVM1
FSVM2
FSVM3

10. 10
FSVMにマウントされているVolumesは末尾のUUIDから判断。
FSVMのディスク情報を見てみる（標準）
・Prism上のNutanix Volumes画面
・FSVMのCLI
２つのディスクがマウントされているように見えますが、
実際に容量が消費されるのは下のディスクのようです。
…

11. 11
２つ⽬の標準共有フォルダの作成すると。
複数の標準共有フォルダを作ってみる

12. 12
再度FSVMを見てみると、FSVM3に新たな共有フォルダのVolumesが
マウントされている。
FSVMのディスクを見てみる（標準）
FSVM2
FSVM3
FSVM1

13. 13
標準共有フォルダを２つ作成すると、FSVM2と3にマウントされた状態。
ここまでのFilesのイメージ図（標準）
共有１ 共有２
FSVM1 FSVM2 FSVM3
共有１の
Volumes
共有２の
Volumes

14. 14
どのようにアクセスされるのか？

15. 15
この状態から・・・
ここまでのFilesのイメージ図（標準）
共有１ 共有２
FSVM1 FSVM2 FSVM3
共有１の
Volumes
共有２の
Volumes

16. 16
共有フォルダ１に複数のクライアントから、データの書き込みをしてみる。
複数のクライアントからアクセス
共有１ 共有２
FSVM1 FSVM2 FSVM3
共有１の
Volumes
共有２の
Volumes

17. 17
共有１に複数のクライアントマシンから、データの書き込みを実施。
コピー中は共有１のVolumesがマウントされているFSVM2のみCPU使用率が
大きく上昇した。
FSVMのCPU負荷を比較
FSVM1
FSVM2
FSVM3
テスト1回目 テスト2回目
※共有２に同じテストを実施すると、FSVM3のCPUに負荷が発生しました。

18. 18
テスト結果の通り、標準共有フォルダは一つのFSVMと関連付けされます。
共有フォルダを分けずに一つでヘビーな使い方をしていると、「あれ？思った
よりパフォーマンスが出ない・・・」なんてことに・・・
テスト結果から・・・
共有１ 共有２

19. 19
標準共有フォルダを複数作成すれば効率よくアクセスの分散が行われます。
共有フォルダを分割するなど、設計を工夫することで最大のパフォーマンスを
発揮することが出来ます。
標準共有フォルダの負荷分散
営業2課 人事部営業1課
営業部
1課 2課 人事部

20. 20
分散共有フォルダはどうなのか？

21. 21
次は分散共有フォルダを作成してみます。
先程と同じようにPrismから、分散共有フォルダを作成すると・・・
Filesから作られるVolumes（分散）
分散共有フォルダ

22. 22
自動的に複数（検証環境では15個）のVolumesが作成されました。
Filesから作られるVolumes（分散）

23. 23
各FSVMに複数（検証環境では5個）のVolumesがマウントされている。
FSVMのディスク情報を見てみる（分散）
FSVM1
FSVM2
FSVM3

24. 24
ここまでのFilesのイメージ図（分散）
Profile

25. 25
アクセスも分散されるのか？

26. 26
この状態から・・・
ここまでのFilesのイメージ図（分散）
Profile

27. 27
複数のクライアントからアクセス
Profile
移動ユーザー用のプロファイル領域として、複数のクライアントからアクセス。
森下
小泉
萩原

28. 28
すべてのFSVMで約35%のCPU使用率が発生。
前回（標準）はFSVM2のみ65%のCPU使用率が発生していたため、
分散共有を利用したことにより、負荷分散されているようです。
FSVMのCPU負荷を比較
FSVM1
FSVM2
FSVM3
テスト１回目 テスト１回目

29. 29
テスト結果から・・・
分散共有フォルダを活用することで、ユーザーごとの負荷が分散されます。
森下
小泉
萩原
Profile

30. 30
改めて共有フォルダの用途について・・・
・標準共有フォルダ（Standard Share）
組織別の多⽬的ファイルサーバー、特に明⽰的な⽬的を持たない
雑多なファイルサーバとして汎用的な利用が可能。
1台のFSVMからデータエクスポートや接続の管理を行う。
・分散共有フォルダ（Distributed Share）
主にVDIの移動ユーザープロファイルを格納する⽬的に利用するための
ファイルサーバーとして利用する。
データは複数FSVMに分散配置されます。
標準 分散or

31. 31
負荷分散はなんとなくわかった。
障害時の動きは？

32. 32
1ノード停止させてみる（障害テスト）
共有２ 共有３共有１

33. 33
事前準備
障害テスト用に３つの標準共有フォルダを用意します。

34. 34
事前準備
それぞれのFSVMにVolumesがマウントされていることも確認。
FSVM2
FSVM3
FSVM1

35. 35
1ノード障害テスト開始
共有２ 共有３共有１
停止方法はIPMIからサーバーの即時停止を実施しました。

36. 36
1ノード障害テスト中
共有２ 共有３共有１
まず、PrismからFSVM3が停止したことを確認します。
停止
※Prism上のFSVMが停止したスクショ取り忘れました・・・

37. 37
1ノード障害テスト中
FSVM3が停止した状態でVolumesのマウント状況を見てみると、
FSVM2に２つのVolumesがマウントされていることが確認出来ます。
（FSVM3が停止してから、数十秒後に確認しています）
FSVM2
FSVM1

38. 38
1ノード障害テスト中
さらに一定時間経過すると、異なるホストにFSVMがHAで再起動してきました。
２台のFSVMが同一のホストで動作している

39. 39
1ノード障害テスト中
FSVMが再起動すると、一定時間でVolumesも元通りに再マウントされました。
FSVM2
FSVM3
FSVM1

40. 40
1ノード障害テスト中
更に更に、停止させていたノードを復旧・起動すると、自動的にFSVMが
もとのノードにライブマイグレーションされ、正常な状態に戻りました。
障害時はノード1で動作していたが、
ノード復旧後は自動的にノード3へ

41. 41
障害テストを図で説明すると・・・
まずはノードの停止に伴い、ノード上で動作しているFSVMがダウンします。
共有２ 共有３共有１
停止

42. 42
障害テストを図で説明すると・・・
ファイルサーバーの領域であるVolumesはNutanix HCIの分散アーキテク
チャーで冗長化されているため、動作上の影響はありません。
そのため、Volumesを異なるFSVM上でマウントすることが出来ます。
共有２ 共有３共有１
Volumesを即時、別のFSVMでマウントするため、
共有フォルダほぼ停止なく継続して利用可能。

43. 43
障害テストを図で説明すると・・・
一定時間が経過すると、HAにてFSVMが異なるホスト上で再起動されます。
これにより、単一ホスト上ではあるがFSVMレベルでの負荷分散が実施されます。
共有２ 共有３共有１
HAにてFSVMが再起動

44. 44
障害テストを図で説明すると・・・
停止させたノードを復旧すると、一定時間でFSVMがもとのノードへ
ライブマイグレーションされることで、正常な状態に戻ります。
共有２ 共有３共有１

45. 45
テストの結果から
Nutanix Filesはノード停止レベルの障害が発生した場合も、
FSVMとVolumesを組み合わせた仕組みを用いることで、
ほぼタウンタイムがなくファイルサービスを継続して
利用することが出来ます。
実際に検証しているときも、ノードを停止して数十秒後にアクセス
してみましたが、問題なくファイルサーバーに接続出来ました。

46. 46
最後に

47. 47
最後に
１．NASヘッドの役割を担うFSVMが仮想アプライアンスとして
提供されることにより、柔軟な負荷分散と拡張性を実現。
２．FSVMとVolumesを組み合わせた仕組みにより、ダウンタイムを
極力減らした高レベルの耐障害性・可用性を実現。
３．ティアリング、ポインタベーススナップショットを始めとした
Nutanix HCIの分散アーキテクチャーが用いられるため、
高機能、高性能なファイルサーバーを簡単に利用できる。