2020年9月28日月曜日

Nutanix Filesの内部的な仕組みを調べてみた②

前回と同様にとあるセミナーでお話した内容の続きです。

引き続きNutainx Filesが題材となり、今回は障害時の動作について検証していたときの結果をご紹介します。

Nutanix Filesの障害時の動作

障害テストは1台のNutanixノードが停止した際のFSVMとVolumesの動きについて見てみます。

障害テスト前の準備

障害テストを行うため、標準共有フォルダを3つ作成した環境を準備しました。

各FSVMにVolumesが割り当てられていることも確認しておきます。

テストの開始

この状態でIPMIからNutanixノードを1台停止させます。

ノードを停止させてから数十秒後、停止したノードで稼働していたFSVMにマウントされていたVolumesが異なるノードで新たにマウントされました。

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

FSVMが再起動すると、異なるFSVMにマウントしていたVolumesはもとのFSVMへ再度マウントされ、もとの状態へ戻ります。

ノード復旧後は自動的にFSVMがもとのノードへライブマイグレーションされました。


ここまでの流れを図で説明

まずはじめにノードの停止に伴い、ノード上で動作しているFSVMが停止します。

停止直後、異なるノードのFSVMにて停止したFSVMにマウントされていたVolumesが新たにマウントされます。

更に一定時間が経過するとHAにて異なるノードでFSVMが再起動され、VolumesはもとのFSVMにて再マウントされます。

ノードが復旧すると自動的にもとのノードへFSVMがライブマイグレーションされ、障害発生前の正常な状態へ戻ります。


障害テストの結果から

まずテストを試していて感じたことは、障害テスト中にファイルサービスの停止を感じなかったことです。
Nutanix FilesはFSVMとVolumesを組み合わせた仕組みにより、NASヘッドに障害が発生しても僅かなダウンタイムでファイルサービスを再開する仕組みを提供していることがわかります。
今回のテストではノード停止直後にすべての共有フォルダへ接続を試してみましたが、接続に失敗するなどの問題は発生しませんでした。

もちろん、実際にはVolumesを再マウントするまでの間に接続出来ないタイミングはあるはずですが、「HAでファイルサーバーが再起動するまで使えない」なんてことはないので、一般のファイルサーバーと比べ非常に高い可用性を持っていることがわかります。


以上でFilesの障害時の動作について紹介させて頂きました。
障害時の動作には、説明していないFSVMのIPアドレス切り替わりなども行われており、そういったネットワーク部分の動作には今回触れていないので、機会があれば紹介したいと思っています。

2020年9月14日月曜日

Nutanix Filesの内部的な仕組みを調べてみた①

少し前にとあるセミナーでお話した内容をこちらのブログでも紹介したいと思います。

内容は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からデータエクスポートや接続の管理を⾏う。

・分散共有フォルダ(Distributed Share)

主にVDIなどの移動ユーザープロファイルを格納する⽬的に利⽤するためのファイルサーバーとして利⽤する。
データは複数FSVMに分散配置されます。

2つの共有フォルダにおける内部的な動作の違い

標準/分散共有フォルダを作成した際に、内部のFSVMとVolumesの構成と動作について見ていきます。

■標準共有フォルダ

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


作成後、FSVMにSSHにて接続しディスクのマウント状態を確認すると、先程共有フォルダ作成時に自動で作成されたVolumesがFSVM2にマウントされていることが確認できました。
(FSVMはCentOSベースの仮想アプライアンスのため、ターミナルソフトから接続することができます。)


なお、Prism上のVolumesとFSVMにマウントされたディスクを見分ける方法は、末尾の数字で判断できます。


続けて2つ目の共有フォルダを作成します。


2つ目のVolumesはFSVM3にマウントされたことが確認できました。


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

この状態でアクセスがどのように行われるのか動作テストを行います。
共有フォルダ1のみに対して、複数のクライアントから同時に書き込みをしてみます。



Prismからデータ書き込み時のFSVMのCPU負荷を確認すると、共有フォルダ1に紐づくVolumesがマウントされているFSVM2のみ、負荷の上昇を確認できました。
なお、共有フォルダ2に同様のテストを行うと紐づくVolumesがマウントされているFSVM3の負荷が上昇しました。

この検証結果から、標準共有フォルダは仕様の通り一つの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で負荷分散されるため「すべてこれでいいじゃないか」、と思ってしまいますが分散共有フォルダ配下のフォルダに対するアクセス権の設定や手動でのフォルダ作成は別のツールが必要になるなど、管理面でのデメリットが存在します。

分散共有フォルダについて詳しくは、過去の記事「Nutanix Files(共有フォルダの種類と負荷分散)」をご覧ください。



以上でNutanix Filesを構成するFSVMとVolumesについてご説明しました。
次回は障害発生時のFSVMとVolumesの動作について、ご紹介させて頂きます。

2020年9月1日火曜日

Nutanix Filesの分析②(File Analytics)

前回はFile Analyticsの導入手順をご紹介させて頂きました。

本記事では実際にFile Analyticsでどのようなことが出来るのか、実際の運用中によく利用されそうな情報・機能についてご説明させて頂きます。

Dashboard

File Analyticsにログインすると表示されるダッシュボードからご説明します。

・Capacity Trend

Filesで利用されているデータ容量の増減をグラフで表示します。
緑色は増加、赤色は減少を表すグラフで表示され、右上のメニューから7日間、30日間、1年間ごとの期間で表示出来ます。
未来予測とまでは行きませんが、容量増強を行う指標として利用することが出来ます。

・Permission Denials

フォルダにアクセス拒否された回数をユーザー毎に表示します。
極端に拒否回数が多いユーザーは機密情報の持ち出しなどを狙った悪意を持った操作を行っている可能性もあり、そういったユーザーを判断する材料として利用することが出来ます。
なお、右上のメニューから24時間、7日間、30日間、1年間ごとの期間で表示でき、右下の「More...」から全てのユーザーを確認することが出来ます。


・Data Age

Filesの全体の使用容量と3ヶ月、6ヶ月、12ヶ月、それ以前で追加された容量を表示します。

・File Distribution by Type

保存されたデータ形式ごとの容量を表示します。
右上の「View Details」から期間別のグラフが表示出来ます。

・File Operations

Filesで行った作成・読書・削除・権限変更の回数を表示します。


Audit Trails

画面左上の「Audit Trails」から監査証跡を確認することが出来ます。

監査証跡はFiles上の「ファイル」「フォルダ」や「ユーザー」「接続元IPアドレス」から検索して確認することが出来ます。
ここでは「sales1」ユーザーの監査証跡を確認してみます。

検索結果の名前をクリックすると、この様な画面が表示されます。
左上から期間を指定すると、該当期間に実施した操作が表示されます。

例えば削除のみを抽出したい場合は、上部の検索バーにて「Delete」を選択することで、該当の操作内容のみが表示されます。
また画面下部には時系列毎に、該当の操作を行ったファイル名が一覧で表示されます。

このように、Files上の操作内容を後から把握することが可能になります。

なお、Dashboardの赤枠に表示されているユーザーやファイルなどからも、監査証跡の画面に遷移することが可能です。



Anomalies

異常を定義するルール(Anomaly Rules)を作成し、異常な操作を行った場合に通知を行うことが出来ます。
右上の「+Define Anomaly Rules」からルールを作成することが出来ます。

この様な画面がポップアップで表示されます。
青枠には検知時に通知を行うメールアドレスを入力します。
右側の「+Configure new anomaly」を選択することで、異常と判断する基準を設定することが出来ます。
種類は削除・コピー・アクセス拒否・アクセス権限変更の4つをベースに、それぞれの操作で異常と判断するための間隔としきい値、上限数が指定出来ます。
また検知対象を特定のユーザー(全ユーザー対象も可)に絞ることも出来ます。

ルールの作成が完了すると、以降は定義した内容の通り検知が実施されます。
Anomaliesのトップ画面では、期間、ユーザー、フォルダ毎に表示され、どの様な異常が発生したのかも円グラフ形式で表示されます。

なお、Dashboardでも右上にアラートが表示されますので、メール以外にもこちらから異常を把握することも出来ます。


簡単にですが、File Analyticsの紹介は以上です。

今回ご紹介したFile Analyticsは無償で利用することが出来るため、わざわざ有償のサードパーティ製分析ツールを用意する必要がありません。
ファイルサーバーの分析を行う上で、具体的に何を分析するのかは企業によって異なります。
要件が曖昧な状態で導入する際に、わざわざ有償の製品を用意することなく、気軽にお試し感覚で利用出来るのもFile Analyticsの良いところだと考えています。

また、Nutanix FilesではFile Analyticsによる分析が可能になるため、他のファイルサーバーと比較しても明確なメリットの一つになります。