サービス概要
前回、[技術検証]FSx for ONTAPでドメイン参加できなかったのでCIFSサーバーを立ててドメイン参加⇨ファイル共有までしてみたで、FSx for ONTAPをドメイン参加させてファイル共有まで作成しました。
今回は、フォルダ階層構造でクォーター制限をしたいという要望があったため、その実現方法について検証します。
目的・やりたいこと
ファイルサーバーでONTAPを利用していて、各フォルダに対して容量制限をかける際、第二階層以降のフォルダに対しても容量制限をかけたい。
各フォルダに対して容量制限をかけたい場合、qtreeコマンドを利用してフォルダに対して容量制限を行う。だが、ONTAPの仕様上、qtreeでは第二階層以降には容量制限をかけることができず、
ボリューム内のqtreeの下にqtreeを階層的に作成できますか。
回答：ボリューム内のqtreeにqtreeを階層的に作成することはできません。
お客様の要望として、第二階層以降のフォルダに対して容量制限をかけたいというのがある。
対象者
ONTAPでサブフォルダに対してもクォーターを効かせたいONTAP運用技術者
対象となる技術
条件（導入にあたっての前提事項）
- ドメイン参加したFSx ONTAPが作成済みであるとします。
参考URL
- System Manager のジャンクションパスウィンドウ - ONTAP 9.7 以前
- NetApp AFF C190で考えるファイルサーバの設計 〜その4〜｜技術ブログ｜C&S ENGINEER VOICE
- NetApp公式Discord ONTAPチャンネル
ここで質問してみたところ、以下の回答が得られたので、実践すべくこれを検証します。
サブフォルダを flexvol として作成し、それらを名前空間に結合することができます。FlexVol のサイズは基本的にクォータになります。ただし、管理オーバーヘッドが追加されます。
ONTAP 9を起動しました。13.1ラボでこれをテストしたところ、動作しました。
System Manager を使用して次のことを実行しました(CLI を使用しても同じことができます) 。
1. 10TBボリュームを作成し、CIFS経由で共有しました(マウントパスは/DataVolume)
2. ボリューム内にQtreeを作成し、50MBクォータを適用しました(マウントパスは/DataVolume/Qtree1)
3. 10TB ボリュームを作成しましたが、最初はマウントしませんでした。
4. ボリュームマウントパスを編集し、/DataVolume/Qtree1/MySubFolder にマウントすることを選択します)
10TBのデータを\CIFSServer \DataVolume にコピーできます。
\CIFSServer\DataVolume\Qtree1 に最大50MBまでしかコピーできません。
\CIFSServer\DataVolume\Qtree1\MySubFolder に10TBのデータをコピーできます。
明らかに、別個のFlexVolであるため、通常どおりにスナップショットポリシーとスナップミラー保護を適用する必要があります。新しいflexvolは親ボリュームからこれらの設定を継承しないことに注意してください。\CIFSServer\DataVolume\Qtree1\MySubFolder にマウントしたFlexVolのサイズを制限することで、一種のことができます。FlexVolはクォータです。
\DataVolume = メインの FlexVol/FlexGroup (Qtreeが含まれる)
\Qtree = ツリー クォータが含まれる
Qtree\MySubFolder = このパスにマウントした1TB FlexVolなので、 FlexVolは本質的にクォータです。ユーザーは1TB(ストレージ効率によってはもう少し多くのことも可能)を超える量を書き込むことはできません。スナップショットリザーブに対応する最適なFlexVolサイズを割り出すには、少し計算する必要があります。最初のQtreeの下に別のQtreeを作成することはできないので、ボリュームにマウントするのが私のやり方です。数百または数千のflexvolを管理することと何ら変わりはありません。また、パフォーマンス、データ保護、さらにはファブリックプールに対してさまざまなポリシーを使用できるという利点もあります。
フォルダーアイコンにはショートカットのような矢印がありますが、これは再解析ポイントまたはジャンクションを示し、クライアントが容量やサイズなどの独自の属性を持つ別のファイルシステムであることを理解できるようにするためです。
要するに、すべてのフォルダをFlexVolで作成し、その個々のFlexVolフォルダをジャンクションパスを使って名前空間で結合し、フォルダ階層のように見せるという手法があるようです。FlexVol一つ一つのクォータサイズがそのままフォルダ容量でありクォーター制限が適用されるので、顧客の要望を実現できそうです！
一応使用実績もあるらしい。
私の顧客には、単一のFlexGroup内に10PiB近くのデータがあり、その単一クラスター上に合計20PiBを超えるデータがあります。qtreeを作成するだけで、スナップショットやスナップミラーについて心配する必要はありません。すでに処理されています。
しかし、さまざまなパフォーマンス要件や、異なるものを必要とするデータセットの階層化と保護ポリシーをどのように管理すればよいでしょうか? ユーザーに対して同じ名前空間を維持する必要があるでしょうか? FlexGroupsやQtreesのような機能ではこれを達成することはできません。それは、そのように設計されているものではありません。
すべての顧客が同じであるわけではなく、またその要件も同じではありません。あらゆる要件に合わせて機能させることができます。私はこれを巨大なグリッドコンピューティング環境で行いました。トップレベルの1g flexvolを多数作成しました(例として開発製品テスト) 。次に、それぞれの下に作業中の項目を表す15個のflexvolの別セットを配置しました。その下には年が記載されたflexvolがありました。そのフレックスグループにはqtreeがありました。毎年の場合、最後に、その年のボリュームは読み取り専用として /mounted としてマークされ、それ以上のデータを排除するためにサイズが縮小されます。20億のファイルを含む4ノードのクラスター(2014年)を持っていました。
これは、単一のFlexGroup内に10PiBを備えた私の研究顧客に似ています(それはFlexgroup自体内の単なるデータです) 。FlexGroupのルート下には、全国の各研究プロジェクトのqtreeがあり、すべての作業データがこれに入力されます(これは、研究者が分類、分析して何を処理するかを決定する前にONTAPにダンプするだけの膨大なデータ ポイントです)。各qtree下には、さまざまな目的で にマウントされた多数のflexvolがあります。プロジェクトが終了し、研究グループによってデータが整理されると、前述のように、さまざまなflexvolが読み取り専用に変更されるか、ボリュームがよりパフォーマンスの低いストレージ層に移動されるか、またはFabricPoolで階層化されます。
すべてのデータは共通の構造下で編成され、アクセスされ、管理されますが、ボリュームはさまざまな場所からマウントされます。大規模な場合、データの膨大なサイズとファイル数を管理し、異なる保護、セキュリティ、および配置要件を持つデータセットを個別にターゲットにできる柔軟性を維持できる、当社と顧客にとって最良の方法であることがわかりました。
注意事項
- フォルダ構造やフォルダ自体のメンテナス（設定、変更、削除、移動等）が若干手間かも
例えば、フォルダ名の変更はこのようにWindows上からはできず、FSxコンソールから変更する必要があります。
概要図
作業の流れ
検証手順
B（20MB）
┏ーー┻ーー┓
C(100MB) D(200MB)
若干歪ですがこのようなフォルダ構成を作り、それぞれ既定のサイズ以上保存できないことを確認する。
やり方は、FlexVolをそれぞれのサイズで作り、ジャンクションパスでフォルダパスを指定する。
1．FlexVolの作成[ボリュームの作成]
2．ファイルシステムを以下のように設定
3．ボリュームの詳細を以下のように設定
元々のデフォルトボリュームをAという名前で作成してしまったため、ジャンクションパスは「/A/B」になっています。
4．残りのフォルダも同様に設定
5．フォルダが作成されていることを確認
この状態でマウントして見るとまずBフォルダが見える。
C:\Users\Administrator>net use Z: \\10.0.21.81\cifs-share
\\10.0.21.81\cifs-share のパスワードが無効です。
'10.0.21.81' のユーザー名を入力してください: Admin@nozaki.com
10.0.21.81 のパスワードを入力してください:
コマンドは正常に終了しました。
Bフォルダを潜るとちゃんとC,Dフォルダが作成されている。
若干気になるとしたら、ご覧のようにフォルダアイコンにショートカットのような矢印マークが付いてしまうことでしょうか。
6．クォータ制限の確認
10MBほどのテストファイルを用意し、B,C,Dそれぞれのフォルダにどこまで置けるかテストしてみたところ、それぞれちゃんと既定の20MB、100MB、200MB以上置けないようになっていたので、設定したクォーターサイズが効いていることが確認できました。
ちなみにフォルダ階層構造として
・第1階層「共有フォルダ」
・第2階層「Personal」
・第3階層：クォータ適用対象
っとなっているとして、容量制限を行いたい第3階層より上の階層全てをFlexVolで作成しなければならないかどうかというと、手動で作成することもできることを確認。
試しに第1階層で「Personal」を手動で作成し、その下にFlexVolでEを作成できました！
ここで新たな課題検討
クォータとしてのFlexVolの容量が動的に変更可能でないと厳しいだろうなと思ったので、変更できるか検証して見ることに。試しにDを200MB⇨50MBに変更してみる。
検証手順
1．ボリュームを選択した状態で[アクション] > [ボリュームを更新]
2．50MBに変更
ところが、当然と言えば当然だが以下の変更後のボリュームサイズが小さすぎるというエラーが
実際に収容できるサイズになるよう現状のファイルを削除しないとエラーになるということで、これはむしろ正しい。
3．そこでエクスプローラ上で50MB以下になるように実際のファイルを削除してみる。
ところがこれでも変わらずエラーが出続ける。
CLIでやっても同様。むしろこっちの方が適正サイズまで指摘してくれていて親切
FsxId0f542a58430378e5d::> volume show -volume D -fields size
vserver volume size
---------- ------ -----
nozaki_SVM D 200MB
FsxId0f542a58430378e5d::> volume modify -volume D -size 50MB
Error: command failed: Unable to set volume attribute "size" for volume "D" on
Vserver "nozaki_SVM". Reason: Selected volume size is too small to hold
the current volume data. New volume size must be at least 188MB to hold
the current volume data.
4．スナップショットの削除
そこで、以下を参考にスナップショットも削除して見ることに
System Manager - ONTAP 9.7 以前を使用して Snapshot コピーを削除します
ディスクスペースを節約したり解放したりする場合、 ONTAP System Manager クラシック（ ONTAP 9.7 以前で使用可能）を使用して Snapshot コピーを削除できます。
FsxId0f542a58430378e5d::> snap delete -vserver nozaki_SVM -volume D -snapshot *
Warning: Deleting a Snapshot copy permanently removes data that is stored only in that Snapshot copy. Are you sure
you want to delete Snapshot copy "hourly.2024-03-16_1105" for volume "D" in Vserver "nozaki_SVM" ?
{y|n}: y
Warning: Deleting a Snapshot copy permanently removes data that is stored only in that Snapshot copy. Are you sure
you want to delete Snapshot copy "hourly.2024-03-16_1205" for volume "D" in Vserver "nozaki_SVM" ?
{y|n}: y
Warning: Deleting a Snapshot copy permanently removes data that is stored only in that Snapshot copy. Are you sure
you want to delete Snapshot copy "hourly.2024-03-16_1305" for volume "D" in Vserver "nozaki_SVM" ?
{y|n}: y
Warning: Deleting a Snapshot copy permanently removes data that is stored only in that Snapshot copy. Are you sure
you want to delete Snapshot copy "hourly.2024-03-16_1405" for volume "D" in Vserver "nozaki_SVM" ?
{y|n}: y
4 entries were acted on.
FsxId0f542a58430378e5d::> df -h D
Filesystem total used avail capacity Mounted on Vserver
/vol/D/ 185MB 39MB 145MB 13% /A/B/D nozaki_SVM
/vol/D/.snapshot 15MB 0B 15MB 0% /A/B/D/.snapshot nozaki_SVM
2 entries were displayed.
FsxId0f542a58430378e5d::> volume show -volume D -fields size
vserver volume size
---------- ------ ----
nozaki_SVM D 50MB
スナップショットを削除するコマンドも必要で若干クセがありましたが、50MBに変更できました。
ただし、マネジメントコンソールからクオーターサイズが50MBになっているのを確認するのにタイムラグがあるようで、この表示がされるまで時間かかりました。
この辺りドメイン参加と同様、GUIから操作してもそれが反映されず、CLIで操作してようやく実現されるという仕様があるっぽいのでFSx ONTAPは要注意
懸念事項
- スナップショットとAWS backupがボリューム単位で設定が必要で300ぐらいのボリュームを個別で設定して、管理しなければならない。300ぐらいのボリュームを同じ時間帯にバックアップ取るのってサーバー負荷大丈夫？
スナップショットに関しては、ONTAPスナップショットはミリ秒単位で作成され、多くの場合それより高速です。
300のボリュームが同時にヒットしないように、スナップショットを数分間にずらした方がいいでしょう。
1つのHAペアに500以上のボリュームがある環境を構築したことがあるが、問題なくすべて同時にスナップショットされました。
- 管理オーバーヘッドはある？
管理オーバーヘッドは、1つのFlexグループに対して1つのボリュームとして扱われることです。つまり、スナップショットポリシーは1つです。レプリケートする場合は、1つのsnapmirror関係になります。どのアグリゲートまたはボリュームでデータをホストするかを決定する必要はなく、Flexgroupを構成する基本的なコンポーネントがその決定を行います（Flexgroupを作成または拡張するときにのみ決定する必要があります）。新しいデータセットがあれば、qtreeを作成し、CIFSであれば新しい共有を作成し、デフォルトのファイルレベルパーミッションを設定すれば完了です。
すべてのデータセットがそれ自身のFlexvolである場合、（どのアグリゲート、どのノード、どのLIF経由で接続するのが最適か、どのsnap-reserveを使用するかなど）いくつか決定しなければならないことが増えます。使用するスナップショットポリシー、マウントパス、エクスポー トポリシー、新しいsnapmirror関係の作成、使用するポリシーなどです。データセットごとに異なるポリシ ーを設定できる柔軟性は、大きなメリットになる場合があります。
所要時間
2時間
