はじめに
AWS のストレージサービスの一つに、Amazon FSx for NetApp ONTAP があります。ONTAP を使ったマネージドサービスで、共有ファイルストレージを簡単に起動して実行し、柔軟荷管理ができます。
といいつつ、NetApp ONTAP の経験がなく、どういった構築方法かよくわからなかったため、Amazon FSx for NetApp ONTAP のハンズオンを参考に色々触ってみる記事です。
このハンズオンは、CloudFormation で作成する内容でしたが、実際に細かなパラメータを見たいので、マネージメントコンソールから構築を進めていきます。それ以外にも、いくつか気になった項目を追加しています。
構成図
NetApp ONTAP の概念が慣れないところもあり、構成図を整理します。具体的な内容はハンズオンの中で見ていきましょう。
Security Group の作成
今回は手順を簡単にするために、VPC 内の CIDR からのアクセスを全て許可する Security Group を作成します。本番環境では、以下の Document を参照しながら、必要なポートだけ解放するように設定してください。
FSx for NetApp ONTAP の作成
Create file system を選択します。
NetApp ONTAP を選択して、Next を押します。
名前や、AZ のタイプ、SSD 容量の指定などをします。
Network に関する指定をします。NetApp 専用の Security Group や、Route Table を選択します。
パスワードを指定します。
SVM(Storage Virtual Machine) のパラメータを指定します。Windows からもアクセスするため、AD 参加はアリにしてみます。
この記事の環境では、次のパラメータを指定します。AWS 上で稼働している Microsoft AD を指定します。
fsxnetapp01
cloud.sugi.local
10.0.100.47
10.0.1.113
OU=Computers,OU=cloud,DC=cloud,DC=sugi,DC=local
Volume に関する指定です。重複排除 (deduplication) や圧縮 (compression)、compaction を有効にします。
Storage の階層化を有効にします。2 日間アクセスがないデータは、自動的に Capacity Pool Storage に移動する指定です。
デフォルトのまま作成します。
Create を押します。
Creating になりました。
作成されました。
詳細画面を備忘録的に残しておきます。
Network の状況がわかります。
なお、Management endpoint 向けに Route Table の Route が自動的に裏側で追加されています。
SVM が 1 個作成されています。
SVM の詳細画面を開くと、Active Directory に参加していることがわかります。また、Management, NFS, SMB, iSCSI の Endpoint が生成されていることがわかります。
Volume が 2 つ作成されています。
Route Table へ紐づけ
既存の Public Route Table が、こんな感じになっています。
NetApp を紐づける Route Table を増やします。
Public Route Table も含めて Associate を押します。
Updating となります。
Route Table の紐づけができました。
次のように、NetApp ONTAP の Management Endpoint や NFS, SMB アクセス用の Route が自動的に出来上がりました。VPC 外にある Endpoint に通信するため、ENI を経由した Route が追加されています。
ONTAP CLI で状態を確認
FIle system の Management Endpoint に SSH します。「198.19.255.17」は、VPC 外ですが、Route Table と紐づけたことにより、ENI 経由で接続が可能です。
ssh fsxadmin@198.19.255.17
実行例
- Password を入力してログインをします。
> ssh fsxadmin@198.19.255.17
The authenticity of host '198.19.255.17 (198.19.255.17)' can't be established.
ECDSA key fingerprint is SHA256:mAGmeQ2wkQbIJ+lNv7LPUztJk70/s/oejiiVitUwba8.
ECDSA key fingerprint is MD5:6d:3a:86:11:39:8b:81:25:85:24:ac:b1:c7:01:f1:13.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '198.19.255.17' (ECDSA) to the list of known hosts.
Password:
This is your first recorded login.
Unsuccessful login attempts since last login: 1
FsxId0567d10c673202269::>
? を実行すると、使えるコマンド一覧が見えます。
FsxId0567d10c673202269::> ?
cluster> Manage clusters
event> Manage system events
exit Quit the CLI session
history Show the history of commands for this CLI session
job> Manage jobs and job schedules
lun> Manage LUNs
man Display the on-line manual pages
network> Manage physical and virtual network connections
qos> QoS settings
redo Execute a previous command
rows Show/Set the rows for this CLI session
security> The security directory
set Display/Set CLI session settings
snaplock> Manages SnapLock attributes in the system
snapmirror> Manage SnapMirror
statistics> Display operational statistics
statistics-v1> The statistics-v1 directory
storage> Manage physical storage, including disks, aggregates, and failover
system> The system directory
top Go to the top-level directory
up Go up one directory
volume> Manage virtual storage, including volumes, snapshots, and mirrors
vserver> Manage Vservers
vol show コマンドで、Volume の一覧が見えます。
FsxId0567d10c673202269::> vol show
Vserver Volume Aggregate State Type Size Available Used%
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
fsxsvm01 fsxsvm01_root
aggr1 online RW 1GB 971.4MB 0%
fsxsvm01 vol1 aggr1 online RW 1GB 972.2MB 0%
2 entries were displayed.
network interface の一覧も見えます。
FsxId0567d10c673202269::> network interface show
Logical Status Network Current Current Is
Vserver Interface Admin/Oper Address/Mask Node Port Home
----------- ---------- ---------- ------------------ ------------- ------- ----
FsxId0567d10c673202269
fsxadmin up/up 198.19.255.17/24 FsxId0567d10c673202269-01
e0e true
inter_1 up/up 10.0.101.147/24 FsxId0567d10c673202269-01
e0e true
inter_2 up/up 10.0.102.21/24 FsxId0567d10c673202269-02
e0e true
fsxsvm01
iscsi_1 up/up 10.0.101.145/24 FsxId0567d10c673202269-01
e0e true
iscsi_2 up/up 10.0.102.63/24 FsxId0567d10c673202269-02
e0e true
nfs_smb_management_1
up/up 198.19.255.229/24 FsxId0567d10c673202269-01
e0e true
6 entries were displayed.
CIFS 共有の作成
vol1 の Volume を指定して、CIFS 共有を作成します。
vserver cifs share create -vserver fsxsvm01 -share-name cifsshare01 -path /vol1/
Windows からアクセス
SVM (Storage Virtual Machine) の詳細画面で、SMB DNS name を確認します。
FSXNETAPP01.CLOUD.SUGI.LOCAL
SVM が所属している AD 配下の Windows 機から NetApp ONTAP の CIFS 共有にアクセスしてみます。
\\fsxnetapp01.cloud.sugi.local
作成した CIFS 共有が見えました。
この共有は、Everyone にフルアクセスとなっています。
普通にファイルを作成できました。
ドライブにマウントすると空き容量が見えます。1024 MB で作成したので、だいたい 972 MB が空き容量となっています。
データ保護
概念図をまず掲載します。
Snapshots 概要 : 引用
新しいスナップショットが作成されると、ボリューム上の既存のブロックへの新しいポインタが作成されます。データはコピーされないため、スナップショットは作成時にスペースを消費せず、瞬時に実行されます。ボリューム上のデータブロックが変更または削除されると、スナップショットによってロックされたブロックが保持され、スナップショットは時間の経過とともにスペースを消費し始めます。
スナップショットは短期的なリカバリーに適しており、ポイントインタイムコピーを使用して単一のファイル、ディレクトリ、またはボリューム全体を復元する機能を提供します。スナップショットはボリュームと一緒に保存されるため、長期的なオフサイト・バックアップには適しておらず、ボリュームやファイルシステムの障害からは保護されません。スナップショットポリシーを使用して自動スナップショットをスケジュールしたり、手動でスナップショットを作成することができます。
Amazon FSx バックアップ 概要 : 引用
Amazon FSx バックアップでは、耐久性の高いAmazon S3に保存されたボリュームの、耐久性の高い自動日次バックアップまたは手動バックアップを取ることができます。これらのバックアップは増分が保存され、自動デイリーバックアップは、0~90日の保持期間を持つデイリーバックアップウィンドウの間に実行されるようにスケジュールすることができます。
Amazon FSx バックアップでは、追加のインフラストラクチャを用意する必要がないため、最大90日の保持期間で費用対効果の高いオフサイトバックアップを実現します。
Snapshot 作成
NetApp ONTAP の管理エンドポイントで、Snapshot の一覧を確認できます。
FsxId0567d10c673202269::> volume snapshot show
---Blocks---
Vserver Volume Snapshot Size Total% Used%
-------- -------- ------------------------------------- -------- ------ -----
fsxsvm01 fsxsvm01_root
daily.2023-06-09_0010 212KB 0% 12%
backup-0d9669915620d151d 1.77MB 0% 54%
daily.2023-06-10_0010 168KB 0% 10%
hourly.2023-06-10_0405 156KB 0% 9%
hourly.2023-06-10_0505 156KB 0% 9%
hourly.2023-06-10_0605 156KB 0% 9%
hourly.2023-06-10_0705 168KB 0% 10%
hourly.2023-06-10_0805 156KB 0% 9%
hourly.2023-06-10_0905 148KB 0% 9%
vol1
daily.2023-06-09_0010 492KB 0% 50%
backup-0f977bdecf9e025c0 408KB 0% 45%
daily.2023-06-10_0010 384KB 0% 44%
hourly.2023-06-10_0405 296KB 0% 38%
hourly.2023-06-10_0505 148KB 0% 23%
hourly.2023-06-10_0605 304KB 0% 38%
hourly.2023-06-10_0705 272KB 0% 36%
hourly.2023-06-10_0805 312KB 0% 39%
hourly.2023-06-10_0905 148KB 0% 23%
18 entries were displayed.
Snapshot の取得スケジュールの確認です。デフォルトのスケジュールでは、合計10個のスナップショット(毎時6個、毎日2個、毎週2個)が保存されることがわかります。
-
hourly
とdaily
とweekyt
という 3 種類のスケジュールが有効になっている
FsxId0567d10c673202269::> snapshot policy show -policy default
Vserver: FsxId0567d10c673202269
Number of Is
Policy Name Schedules Enabled Comment
------------------------ --------- ------- ----------------------------------
default 3 true Default policy with hourly, daily & weekly schedules.
Schedule Count Prefix SnapMirror Label
---------------------- ----- ---------------------- -------------------
hourly 6 hourly -
daily 2 daily daily
weekly 2 weekly weekly
NetApp ONTAP で定義されているスケジュールを確認します。多くの定義が見えますが、実際にデフォルトで利用されているのは、hourly
と daily
と weekyt
という 3 種類のスケジュールだけです。
- 1時間毎のスナップショットは5分毎に、1日毎のスナップショットは午前0時10分毎に、1週間毎のスナップショットは日曜日の午前0時15分毎に行われるのがわかると思います。
FsxId0567d10c673202269::> job schedule cron show
Cluster Vserver Name Description
------- -------- ----------- --------------------------------------------------
FsxId0567d10c673202269
FsxId0567d10c673202269
10min @:00,:10,:20,:30,:40,:50
12-hourly @0:15,12:15
5min @:00,:05,:10,:15,:20,:25,:30,:35,:40,:45,:50,:55
6-hourly @0:15,6:15,12:15,18:15
8hour @2:15,10:15,18:15
daily @0:10
hourly @:05
monthly 1@0:20
pg-15-minutely
@:10,:25,:40,:55
pg-6-hourly @3:03,9:03,15:03,21:03
pg-daily @0:10
pg-daily-set2
@6:25
pg-daily-set3
@12:40
pg-daily-set4
@18:55
pg-hourly @:07
pg-hourly-set2
@:22
pg-hourly-set3
@:37
pg-hourly-set4
@:52
pg-remote-15-minutely
@:00,:15,:30,:45
pg-remote-6-hourly
@3:08,9:08,15:08,21:08
pg-remote-daily
@0:15
pg-remote-hourly
@:12
pg-remote-weekly
Sun@0:20
pg-weekly Sun@0:15
pg-weekly-set2
Tue@4:30
pg-weekly-set3
Thu@10:44
pg-weekly-set4
Sat@16:59
weekly Sun@0:15
手動でスナップショットを作成することもできます。
volume snapshot create -vserver fsxsvm01 -volume vol1 -snapshot vol1_FSxOntapWorkshop -comment "Manual Snapshot created for FSx Workshop"
一瞬で作成されました。
FsxId0567d10c673202269::> volume snapshot show vol1
---Blocks---
Vserver Volume Snapshot Size Total% Used%
-------- -------- ------------------------------------- -------- ------ -----
fsxsvm01 vol1
daily.2023-06-09_0010 492KB 0% 55%
backup-0f977bdecf9e025c0 408KB 0% 50%
daily.2023-06-10_0010 384KB 0% 48%
hourly.2023-06-10_0405 296KB 0% 42%
hourly.2023-06-10_0505 148KB 0% 27%
hourly.2023-06-10_0605 304KB 0% 43%
hourly.2023-06-10_0705 272KB 0% 40%
hourly.2023-06-10_0805 312KB 0% 43%
hourly.2023-06-10_0905 300KB 0% 42%
vol1_FSxOntapWorkshop 136KB 0% 25%
10 entries were displayed.
以下のコマンドを実行して、ボリュームに割り当てられたスナップショットの snapreserve スペースを確認します。Volume の容量のうち 5% が Snapshot 用にsnapreserve として予約されています。その snapreserve のうち 6% が使われています。
FsxId0567d10c673202269::> volume show vol1 -fields percent-snapshot-space,snapshot-space-used
vserver volume percent-snapshot-space snapshot-space-used
-------- ------ ---------------------- -------------------
fsxsvm01 vol1 5% 6%
また、以下のコマンドを実行して、ボリューム上のスナップショット snapreserve のスペース使用量を確認することもできます。
FsxId0567d10c673202269::> df -h vol1
Filesystem total used avail capacity Mounted on Vserver
/vol/vol1/ 972MB 564KB 972MB 0% /vol1 fsxsvm01
/vol/vol1/.snapshot 51MB 3052KB 48MB 6% /vol1/.snapshot fsxsvm01
2 entries were displayed.
次にスナップショットの動作確認のために、NetApp ONTAP の中のファイルを変えてみましょう。
プロパティにある以前のバージョンから、復元ができます。
前のバージョンに戻りました。
FSx バックアップ
FSx で提供されているバックアップは、Volume 単位のバックアップです。Volume を選択します。
Restore backup を押します。
既存の Volume に上書きして Restore が出来ないので、別の Volume 名 vo1_restored
を入力します。
Volume のパラメータを入れて、Confirm を押します。
新たに Volume が作成されました。
vol1_restored がリストアされています。
FsxId0567d10c673202269::> volume show
Vserver Volume Aggregate State Type Size Available Used%
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
fsxsvm01 fsxsvm01_root
aggr1 online RW 1GB 970.9MB 0%
fsxsvm01 vol1 aggr1 online RW 2TB 858.6GB 2%
fsxsvm01 vol1_restored
aggr1 online RW 1GB 1022MB 0%
4 entries were displayed.
vol1_restored の Volume を指定して、CIFS 共有を作成します。
vserver cifs share create -vserver fsxsvm01 -share-name cifsshare01_restored -path /vol1_restored/
リストアされた Volume を使った CIFS 共有が見えます。
Volume の容量拡張
Volume が 1 GB で作ったので、50 GB に拡張してみましょう。
Update volume を押します。
容量を指定して、Update を押します。
すぐに反映され、CIFS アクセスしているクライアント側でも空き容量が増えていることがわかります。
FlexClone
FlexClone 概要 : 引用
FlexClone により、ソースボリュームのクローンを作成し、それぞれのボリュームに独立して変更を加えることができます。一般的なユースケースには、本番ボリュームのコピーを作成してテストに使用する開発環境またはテスト環境が含まれます。例えば、データベースのクローンを作成し、変更を本番環境に適用する前にテストすることができます。 FlexClone を使用すると、データを別のボリュームにコピーする必要はありません。 FlexCloneを作成すると、ONTAP は親ボリュームのスナップショットを作成し、FlexClone はこのスナップショットから作成されます。スナップショットは即座に作成されるため、FlexClone はすぐに使用でき、追加のスペースを占有しません。FlexClone ボリュームが作成されると、それを別のボリュームとして管理できます。 FlexClone ボリュームに書き込む新しいデータはすべて新しいブロックに書き込まれ、ディスク上のスペースを使用します。
同じ親ボリュームに対して複数のクローンを作成できます。親ボリュームとFlexCloneボリュームを物理的に別々の2つのボリュームに分割できます。分割すると、共有データブロックは2つの別々のコピーに分割されます。
FlexClone の作成
FlexClone の作成を試すために、一度元のボリュームに 1 GB ほどのファイルを格納します。適当な CentOS 7 の仮想マシンファイルを置きました。
まず、NetApp ONTAP の管理エンドポイントに SSH 接続し、Snapshot の一覧を確認します。
FsxId0567d10c673202269::> vol snapshot show -volume vol1
---Blocks---
Vserver Volume Snapshot Size Total% Used%
-------- -------- ------------------------------------- -------- ------ -----
fsxsvm01 vol1
daily.2023-06-09_0010 492KB 0% 0%
backup-0f977bdecf9e025c0 408KB 0% 0%
daily.2023-06-10_0010 396KB 0% 0%
hourly.2023-06-10_0605 304KB 0% 0%
hourly.2023-06-10_0705 272KB 0% 0%
hourly.2023-06-10_0805 312KB 0% 0%
hourly.2023-06-10_0905 300KB 0% 0%
vol1_FSxOntapWorkshop 156KB 0% 0%
hourly.2023-06-10_1005 324KB 0% 0%
hourly.2023-06-10_1105 360KB 0% 0%
10 entries were displayed.
コマンド実行後、数秒待機すると Job が succeeded になります。
FsxId0567d10c673202269::> volume clone create -vserver fsxsvm01 -flexclone vol1_clone1 -parent-volume vol1
[Job 79] Job succeeded: Successful
FlexClone のボリュームを確認します。
FsxId0567d10c673202269::> volume clone show
Parent Parent Parent
Vserver FlexClone Vserver Volume Snapshot State Type
------- ------------- ------- ------------- -------------------- --------- ----
fsxsvm01
vol1_clone1 fsxsvm01
vol1 clone_vol1_clone1.2023-06-10_114018.0
online RW
もう一度ボリュームのスナップショットをリストします。FlexClone により作成された新しいスナップショットが見えます。
FsxId0567d10c673202269::> vol snapshot show -volume vol1
---Blocks---
Vserver Volume Snapshot Size Total% Used%
-------- -------- ------------------------------------- -------- ------ -----
fsxsvm01 vol1
daily.2023-06-09_0010 492KB 0% 0%
backup-0f977bdecf9e025c0 408KB 0% 0%
daily.2023-06-10_0010 396KB 0% 0%
hourly.2023-06-10_0605 304KB 0% 0%
hourly.2023-06-10_0705 272KB 0% 0%
hourly.2023-06-10_0805 312KB 0% 0%
hourly.2023-06-10_0905 300KB 0% 0%
vol1_FSxOntapWorkshop 156KB 0% 0%
hourly.2023-06-10_1005 324KB 0% 0%
hourly.2023-06-10_1105 364KB 0% 0%
clone_vol1_clone1.2023-06-10_114018.0 168KB 0% 0%
11 entries were displayed.
Volume が新たに作成されています。
FsxId0567d10c673202269::> volume show
Vserver Volume Aggregate State Type Size Available Used%
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
fsxsvm01 fsxsvm01_root
aggr1 online RW 1GB 971.0MB 0%
fsxsvm01 vol1 aggr1 online RW 50GB 46.34GB 2%
fsxsvm01 vol1_clone1 aggr1 online RW 50GB 46.34GB 2%
fsxsvm01 vol1_restored
aggr1 online RW 1GB 1023MB 0%
4 entries were displayed.
ちなみに、マネージメントコンソール上では、FlexClone で作成された Volume を確認することが出来ませんでした。数時間 (?) 後に表示されるようになるので、後で確認してみてください。
クローンボリュームの Junction Path を作成します。
volume mount -vserver fsxsvm01 -volume vol1_clone1 -junction-path /vol1_clone1
Clone 元の Volume の消費容量などを確認します。
FsxId0567d10c673202269::> volume show -vserver fsxsvm01 -volume vol1 -fields size,used,available,percent-used,physical-used,physical-used-percent
vserver volume size available used percent-used physical-used physical-used-percent
-------- ------ ---- --------- ------ ------------ ------------- ---------------------
fsxsvm01 vol1 50GB 46.34GB 1.16GB 2% 1.16GB 2%
Clone 先の Volume の消費容量を確認します。used
が 1.16GB に対して physical-used
が 1.14 MB となっていることがわかります。
FsxId0567d10c673202269::> volume show -vserver fsxsvm01 -volume vol1_clone1 -fields size,used,available,percent-used,physical-used,physical-used-percent
vserver volume size available used percent-used physical-used physical-used-percent
-------- ----------- ---- --------- ------ ------------ ------------- ---------------------
fsxsvm01 vol1_clone1 50GB 46.34GB 1.16GB 2% 1.14MB 0%
Clone 先で CIFS Share を作成します。
vserver cifs share create -vserver fsxsvm01 -share-name cifsshare01_clone1 -path /vol1_clone1/
clone1 側が作成されています。
アクセスできます。
Clone 先で同様に重めのファイルを作成してみましょう。
想定通り、Clone 元の Volume の消費容量 (physical-used
) は、変化はありません
FsxId0567d10c673202269::> volume show -vserver fsxsvm01 -volume vol1 -fields size,used,available,percent-used,physical-used,physical-used-percent
vserver volume size available used percent-used physical-used physical-used-percent
-------- ------ ---- --------- ------ ------------ ------------- ---------------------
fsxsvm01 vol1 50GB 46.34GB 1.16GB 2% 1.16GB 2%
Clone 先の Volume で消費容量 (physical-used
) が増えました。
FsxId0567d10c673202269::> volume show -vserver fsxsvm01 -volume vol1_clone1 -fields size,used,available,percent-used,physical-used,physical-used-percent
vserver volume size available used percent-used physical-used physical-used-percent
-------- ----------- ---- --------- ------ ------------ ------------- ---------------------
fsxsvm01 vol1_clone1 50GB 45.36GB 2.14GB 4% 1002MB 2%
ストレージ効率化機能
ストレージ効率化機能の概要 : 引用
- 圧縮: データブロックを圧縮し、必要な物理ストレージの量を削減します。
- 重複排除: 重複するデータブロックを排除して、ストレージ効率とコストの最適化を実現します。ボリュームのインラインおよび後処理において重複排除を有効にできます。
- コンパクション: 複数の小さなファイルIO操作とゼロが埋め込まれたIO操作をディスク上の単一の4KBブロックに集約します。例えば、小さなファイルIO(<4KB)がある場合、各IOに1つの4KBブロックを割り当てる代わりに、Compactationは複数の小さなIO操作を単一の4KBブロックに集約します。
Amazon FSx for NetApp ONTAP ボリュームのこれらの ストレージ効率化 機能は有効または無効にできます。重複排除、データの圧縮、およびデータコンパクションは一緒に、または個別に実行することができ、ボリュームにとって最適なスペースの節約が実現できます。3つの機能すべてを有効にして、新しいデータがボリュームに書き込まれると、次のようになります。
- まず、インラインデータ圧縮は受信データブロックを圧縮します。
- 次に、インライン重複排除により重複ブロックが削除されます。
- 次に、インラインデータコンパクションは、ファイルシステムに書き込む前に、すでに圧縮や重複排除されていたり、また圧縮や重複排除がされないが、小さな(<4KB の)IO を 4KB ブロックにコンパクト化します。
ストレージ効率化を試す
現状の設定値の確認です。State が Enabled となっています。
FsxId0567d10c673202269::> volume efficiency show
Vserver Volume State Status Progress Policy
---------- ---------------- --------- ----------- ------------------ ----------
fsxsvm01 vol1 Enabled Idle Idle for 68:51:37 auto
fsxsvm01 vol1_clone1 Enabled Idle Idle for 68:51:37 auto
fsxsvm01 vol1_restored Enabled Idle Idle for 00:34:08 auto
3 entries were displayed.
より詳細な情報を確認します。
-
Efficiency Policy Name
が Auto なので、リアルタイムでインライン重複排除 (Inline Dedupe) もしながら、バックグラウンドで継続的にストレージ効率化の各機能が実行されます。また、ボリューム上のデータの 20% が変更されたときにも実行されます。
FsxId0567d10c673202269::> volume efficiency show -vserver fsxsvm01 -volume vol1
Vserver Name: fsxsvm01
Volume Name: vol1
Volume Path: /vol/vol1
State: Enabled
Status: Idle
Progress: Idle for 69:00:31
Type: Regular
Schedule: -
Efficiency Policy Name: auto
Blocks Skipped Sharing: 0
Last Operation State: Success
Last Success Operation Begin: Wed Jun 07 15:04:36 2023
Last Success Operation End: Wed Jun 07 15:04:36 2023
Last Operation Begin: Wed Jun 07 15:04:36 2023
Last Operation End: Wed Jun 07 15:04:36 2023
Last Operation Size: 0B
Last Operation Error: -
Changelog Usage: 2%
Logical Data Size: 1.32GB
Logical Data Limit: 640TB
Logical Data Percent: 0%
Queued Job: -
Stale Fingerprint Percentage: 0
Compression: false
Inline Compression: true
Storage Efficiency Mode: efficient
Constituent Volume: false
Inline Dedupe: true
Data Compaction: true
Cross Volume Inline Deduplication: false
Cross Volume Background Deduplication: false
Extended Compressed Data: true
ストレージ効率化の節約度合いの確認ができます。
- 重複排除で、160.9 MB がなされています。
FsxId0567d10c673202269::> volume show -vserver fsxsvm01 -volume vol1 -fields compression-space-saved,compression-space-saved-percent,dedupe-space-saved,dedupe-space-saved-percent
vserver volume dedupe-space-saved dedupe-space-saved-percent compression-space-saved compression-space-saved-percent
-------- ------ ------------------ -------------------------- ----------------------- -------------------------------
fsxsvm01 vol1 160.9MB 12% 0B 0%
こんな感じで、同じファイルを 2 回コピーしてみました。
重複排除の度合いも大きく増えました。
FsxId0567d10c673202269::> volume show -vserver fsxsvm01 -volume vol1 -fields compression-space-saved,compression-space-saved-percent,dedupe-space-saved,dedupe-space-saved-percent
vserver volume dedupe-space-saved dedupe-space-saved-percent compression-space-saved compression-space-saved-percent
-------- ------ ------------------ -------------------------- ----------------------- -------------------------------
fsxsvm01 vol1 2.76GB 56% 0B 0%
SnapMirror
ハンズオンは、2 つの FSx for NetApp ONTAP が必要だったのでスキップします。URL と概要を置いておきます。
概要 : 引用
このセクションでは、Amazon FSx for NetApp ONTAP ファイルシステムで使用できる SnapMirror 機能について説明します。 SnapMirror は、NetApp ONTAP が災害復旧とデータ移行のためにネイティブに提供するブロックレベルのレプリケーション テクノロジーです。SnapMirror を使用して次のことが実現できます。
- 異なるリージョンにある2つの Amazon FSx for NetApp ONTAP ファイルシステム間でデータをレプリケートして、ディザスターリカバリーのためにクロス リージョン レプリケーション(CRR)をセットアップします。
- オンプレミスの NetApp ハードウェアから Amazon FSx for NetApp ONTAP ファイルシステムにデータを移行します。
- 同じリージョン内の 2 番目の Amazon FSx for NetApp ONTAP ファイルシステム上のデータの、2 番目のコピーを作成します。
- クラウド上にDRをセットアップし、オンプレミスの Net App ストレージと Amazon FSx for NetApp ONTAP ファイルシステム間でデータをレプリケートします。
Tip : ディザスターリカバリーを計画する際に、Amazon FSx for NetApp ONTAP ボリューム用ののコスト効率の高いオフサイトバックアップを提供する Amazon FSx のバックアップ機能の使用を検討してください。 Amazon FSx のバックアップは、同じリージョン内の耐久性の高い Amazon S3 に保存されます。
FlexCache
ハンズオンは、2 つの FSx for NetApp ONTAP が必要だったのでスキップします。URL と概要を置いておきます。
概要 : 引用
このセクションでは、Amazon FSx for NetApp ONTAP ファイルシステムに FlexCache をセットアップし、データセットまたはボリューム全体をコピーするのではなく、アクティブに読み取られたデータのみをキャッシュする方法について説明します。 FlexCacheを使用して次のことができます。
- 地震解析、メディアレンダリングワークフロー、チップ設計、財務シミュレーションなどの読み取り集約型アプリケーションのスループットを向上させます。
- 別リージョンからの Amazon FSx for NetApp ONTAP ファイルシステムのデータへの低レイテンシー アクセスを提供し、ワークフローを複数の AWS リージョン間またはオンプレミスの NetApp 環境に拡張します。
- FSx ファイルシステムに FlexCache ボリュームを作成し、それをオンプレミスの NetApp ストレージのオリジン ボリュームにリンクすることで、ワークロードをクラウドにバーストします。
FlexCache ボリュームは、オリジン ボリュームとも呼ばれるソース ボリュームのキャッシュとして機能し、頻繁にアクセスされるデータを格納する、まばらに配置されたボリュームです。ファイルが FlexCache ボリュームで使用できない場合、そのファイルは元のボリュームから読み取られ、クライアントに提供されます。その後のデータへのアクセスは、低レイテンシーで高速になります。
ElasticTiering
概要 : 引用
このセクションでは、Amazon FSx for NetApp ONTAP ファイルシステムの、コスト最適化された伸縮自在なキャパシティプール階層化機能について説明します。
primary storage (SSD ストレージ) 層と、より安価な capacity pool storage 層の間でデータを移動する階層化ポリシーを有効にすることで、コストを最適化できます。最近利用したデータは、primary storage に配置され、一定時間使われないファイルは自動的に裏側で capacity pool storage 層に配置されます。capacity pool storage 層は伸縮自在で、使用量に基づいて増減します。
次の階層化ポリシーを構成できます。
- スナップショットのみ : アクティブなファイルシステムに関連付けられていないボリューム スナップショット コピーのデータブロックを capacity pool storage 層に移動します。最小冷却期間は 2 日で、2 〜 183 日の間で変更できます。
- 自動 : スナップショットとアクティブなファイルシステムの両方のコールドデータブロックを capacity pool storage 層に移動します。デフォルトの冷却期間は 31 日で、2 〜 183 日の間で変更できます。
- すべて : アクティブなファイルシステムとスナップショット内のすべてのユーザーデータブロックを capacity pool storage 層に移動します。ブロックを primary storage 層に戻すことは許可されていません。
- なし : データの移動はありません。すべてのデータは primary storage 層に保存されます
階層化ポリシーを[自動]から[スナップショットのみ]、または[なし]に変更しても、すでに capacity pool storage 層に移動されているアクティブなファイルシステム ブロックが primary storage 層に戻されることはありません。データの読み取りパターンは、以下に示すデータ取得ルールポリシーに基づいてデータが capacity pool storage 層から読み取られるかどうかを決定します。
- すべて: シーケンシャルおよびランダム読み取り
- スナップショットのみ: シーケンシャルおよびランダム読み取り
- 自動: ランダム読み取り
- なし: データを取得しない
ElasticTiering を試す
ボリュームに設定されている階層化ポリシーを確認します。auto になっています。
FsxId0567d10c673202269::> vol show -volume vol1 -fields tiering-policy
vserver volume tiering-policy
-------- ------ --------------
fsxsvm01 vol1 auto
-
Footprint in Performance Tier
が primary storage 層です。 -
Footprint in FSxFabricpoolObjectStore
が capacity pool storage 層です。データを入れたばかりなので、capacity pool storage が全く使われていないことがわかります。
FsxId0567d10c673202269::> volume show-footprint -volume vol1
Vserver : fsxsvm01
Volume : vol1
Feature Used Used%
-------------------------------- ---------- -----
Volume Data Footprint 2.15GB 0%
Footprint in Performance Tier
2.15GB 100%
Footprint in FSxFabricpoolObjectStore
0B 0%
Volume Guarantee 0B 0%
Flexible Volume Metadata 118.0MB 0%
Delayed Frees 5.30MB 0%
Total Footprint 2.27GB 0%
Policy を AUTO から ALL にして、全てのデータを capacity pool storage の層に移動してみましょう。
volume modify -volume vol1 -vserver fsxsvm01 -tiering-policy ALL
ALL に変わりました
FsxId0567d10c673202269::> vol show -volume vol1 -fields tiering-policy
vserver volume tiering-policy
-------- ------ --------------
fsxsvm01 vol1 all
Footprint を確認すると、かなりのデータが Footprint in FSxFabricpoolObjectStore
に移動しています。
FsxId0567d10c673202269::> volume show-footprint -volume vol1
Vserver : fsxsvm01
Volume : vol1
Feature Used Used%
-------------------------------- ---------- -----
Volume Data Footprint 2.15GB 0%
Footprint in Performance Tier
53.64MB 2%
Footprint in FSxFabricpoolObjectStore
2.10GB 98%
Volume Guarantee 0B 0%
Flexible Volume Metadata 118.0MB 0%
Delayed Frees 6.78MB 0%
Total Footprint 2.27GB 0%
ちなみに、capacity pool storage 層にファイルを置いた状態で 1 端末からアクセスしてみましたが、まったくアクセスの遅さは感じませんでした。ダウンロードしたファイルは 1.3 GB で、大体 5 秒くらいで終わりました。230 MB/s ほどのダウンロード性能でした。アップロードについても 330 MB/s ほどの性能は出ました。
Policy を ALL から AUTO に戻しましょう。
volume modify -volume vol1 -vserver fsxsvm01 -tiering-policy AUTO
Auto に戻りました。Auto に戻したので、capacity pool storage 層に置かれているデータにアクセスすると、自動的に primary storage に戻るはずです。
FsxId0567d10c673202269::> vol show -volume vol1 -fields tiering-policy
vserver volume tiering-policy
-------- ------ --------------
fsxsvm01 vol1 auto
Over Provisioning
Filesystem に SSD Storage capacity を 1024 GiB 割り当てています。
この割り当てている容量以上に Volume を割り当てることができます。capacity pool storage 層の活用を考えると、SSD Storage capacity より大きいファイル共有が欲しいタイミングがあったりもします。ただし、実際の SSD Storage capacity の空き容量がなくならないようにしっかりモニタリングが必要です。CloudWatch Alarm で、一定の閾値を超えたらメールを発行するなど、慎重で確実な運用が必要になります。
それでは、拡張してみます。
2,097,152 MiB = 2048 GiB の Volume に拡張します。
拡張されました。
Client から見ても、Over Provisioning された状態で拡張されています。
検証を通じてわかったこと
- File system の SSD Storage Capacity の容量指定は 1024 GiB ~ 192 TiB で指定可能。1024 GiB 未満は指定できないため、小さい容量が必要な場合は FSx for Windows File Server を検討しても良いかも。
- SSD Storage Capacity の容量変更は、増やすことが出来る。一方、減らすことは出来ない。
- SSD Storage Capacity の容量を増やすときに、最低でも現在の容量の 10 % を増やさないといけない制限がある。
- 一方、Volume の容量拡張は 1 MB 単位で指定が可能。File system 側の SSD Storage Capacity をある程度の大きさにしつつ、Volume で細かく刻む管理方法は考えられる。
- Throughput Capacity は、128 MB/s, 256 MB/s, 512 MB/s, 1024 MB/s の 4 つから選択可能
- 同一の Volume で CIFS 共有と NFS 共有を共存する場合には、いくつかの設定と考慮が必要
- FlexClone で簡単に、かつ、消費容量を抑えて Volume の複製が可能。ただし、FlexClone で Volume を作成した直後は、AWS マネージメントコンソール上に表示されなかった。数時間後 (?) には表示されたので、すぐに表示されなくても焦らずに。
- ストレージ効率化機能の中に含まれている インライン重複排除 (Inline Dedupe) について。NetApp ONTAP にデータが送信され、ディスクに書き込まれる間に重複排除が行われる。スケジュール実行されるわけではなく、リアルタイムで実施してくれるのが素敵なポイント。
- File system に割り当てている SSD Storage capacity より大きいサイズの Volume を Over Provisioning 的に割り当てることが可能。SSD よりコストが安い capacity pool storage 層の活用を考えると、SSD Storage capacity より大きいファイル共有が欲しいユースケースで有効に活用できると思う。
- ただし、実際の SSD Storage capacity の空き容量がなくならないようにしっかりモニタリングが必要。CloudWatch Alarm で、一定の閾値を超えたらメールを発行するなど、より慎重で確実な運用が必要。
Tips : primary storage と capacity pool storage の性能の簡易検証
以下のツールを使って、primary storage と capacity pool storage の性能検証を行う。
- DiskSPD
- CrystalDiskMark
まとめ : primary storage と capacity pool storage で性能の違いは特に見受けられなかった (?)。あくまで、1 端末から性能ツールで簡易的に実行しただけなので、より大規模な本番環境になってくると差が出てくるかもしれないです。
実行方法 : NetApp ONTAP の CIFS 領域をネットワークドライブに割り当てを行う。その後に、PowerShell を管理者権限で実行し、そのネットワークドライブに移動
cd \\fsxnetapp01.cloud.sugi.local\cifsshare01
以下のコマンドで負荷を掛ける
- カレントディレクトリに 40 GBのファイル「test.dat」を作成し、60 秒間の読み込みを実行します。
.\diskspd.exe -c40G -d60 -Sh test.dat
**capacity pool storage : diskspd **
PS Microsoft.PowerShell.Core\FileSystem::\\fsxnetapp01.cloud.sugi.local\cifsshare01> .\diskspd.exe -c40G -d60 -Sh test.dat
Command Line: \\fsxnetapp01.cloud.sugi.local\cifsshare01\diskspd.exe -c40G -d60 -Sh test.dat
Input parameters:
timespan: 1
-------------
duration: 60s
warm up time: 5s
cool down time: 0s
random seed: 0
path: 'test.dat'
think time: 0ms
burst size: 0
software cache disabled
hardware write cache disabled, writethrough on
performing read test
block size: 64KiB
using sequential I/O (stride: 64KiB)
number of outstanding I/O operations per thread: 2
threads per file: 1
using I/O Completion Ports
IO priority: normal
System information:
computer name: EC2AMAZ-P7CTB7C
start time: 2023/06/10 13:26:22 UTC
Results for timespan 1:
*******************************************************************************
actual test time: 60.00s
thread count: 1
proc count: 8
CPU | Usage | User | Kernel | Idle
-------------------------------------------
0| 28.95%| 0.57%| 28.38%| 71.05%
1| 0.18%| 0.16%| 0.03%| 99.82%
2| 22.99%| 0.42%| 22.57%| 77.01%
3| 0.96%| 0.31%| 0.65%| 99.04%
4| 3.57%| 1.30%| 2.27%| 96.43%
5| 0.23%| 0.16%| 0.08%| 99.77%
6| 3.18%| 1.82%| 1.35%| 96.82%
7| 2.06%| 1.98%| 0.08%| 97.94%
-------------------------------------------
avg.| 7.76%| 0.84%| 6.93%| 92.24%
Total IO
thread | bytes | I/Os | MiB/s | I/O per s | file
------------------------------------------------------------------------------
0 | 16913793024 | 258084 | 268.82 | 4301.20 | test.dat (40GiB)
------------------------------------------------------------------------------
total: 16913793024 | 258084 | 268.82 | 4301.20
Read IO
thread | bytes | I/Os | MiB/s | I/O per s | file
------------------------------------------------------------------------------
0 | 16913793024 | 258084 | 268.82 | 4301.20 | test.dat (40GiB)
------------------------------------------------------------------------------
total: 16913793024 | 258084 | 268.82 | 4301.20
Write IO
thread | bytes | I/Os | MiB/s | I/O per s | file
------------------------------------------------------------------------------
0 | 0 | 0 | 0.00 | 0.00 | test.dat (40GiB)
------------------------------------------------------------------------------
total: 0 | 0 | 0.00 | 0.00
**capacity pool storage : CrystalDiskMark **
- SEQ1M Q8T1 : Sequential 1 MiB, Queue=8, Thread=1
- SEQ1M Q1T1 : Sequential 1 MiB, Queue=1, Thread=1
- RND4K Q32T1 : Random 4 KiB, Queue=32, Thread=1
- RND4K Q1T1 : Random 4 KiB, Queue=1, Thread=1
**capacity pool storage : diskspd **
PS Microsoft.PowerShell.Core\FileSystem::\\fsxnetapp01.cloud.sugi.local\cifsshare01> .\diskspd.exe -c40G -d60 -Sh test.dat
Command Line: \\fsxnetapp01.cloud.sugi.local\cifsshare01\diskspd.exe -c40G -d60 -Sh test.dat
Input parameters:
timespan: 1
-------------
duration: 60s
warm up time: 5s
cool down time: 0s
random seed: 0
path: 'test.dat'
think time: 0ms
burst size: 0
software cache disabled
hardware write cache disabled, writethrough on
performing read test
block size: 64KiB
using sequential I/O (stride: 64KiB)
number of outstanding I/O operations per thread: 2
threads per file: 1
using I/O Completion Ports
IO priority: normal
System information:
computer name: EC2AMAZ-P7CTB7C
start time: 2023/06/10 13:58:29 UTC
Results for timespan 1:
*******************************************************************************
actual test time: 60.00s
thread count: 1
proc count: 8
CPU | Usage | User | Kernel | Idle
-------------------------------------------
0| 43.02%| 0.49%| 42.53%| 56.98%
1| 0.03%| 0.00%| 0.03%| 99.97%
2| 30.44%| 0.05%| 30.39%| 69.56%
3| 0.73%| 0.21%| 0.52%| 99.27%
4| 3.80%| 0.10%| 3.70%| 96.20%
5| 0.13%| 0.08%| 0.05%| 99.87%
6| 1.80%| 0.05%| 1.74%| 98.20%
7| 0.08%| 0.05%| 0.03%| 99.92%
-------------------------------------------
avg.| 10.00%| 0.13%| 9.87%| 90.00%
Total IO
thread | bytes | I/Os | MiB/s | I/O per s | file
------------------------------------------------------------------------------
0 | 15992684544 | 244029 | 254.19 | 4067.08 | test.dat (40GiB)
------------------------------------------------------------------------------
total: 15992684544 | 244029 | 254.19 | 4067.08
Read IO
thread | bytes | I/Os | MiB/s | I/O per s | file
------------------------------------------------------------------------------
0 | 15992684544 | 244029 | 254.19 | 4067.08 | test.dat (40GiB)
------------------------------------------------------------------------------
total: 15992684544 | 244029 | 254.19 | 4067.08
Write IO
thread | bytes | I/Os | MiB/s | I/O per s | file
------------------------------------------------------------------------------
0 | 0 | 0 | 0.00 | 0.00 | test.dat (40GiB)
------------------------------------------------------------------------------
total: 0 | 0 | 0.00 | 0.00
**primary storage : CrystalDiskMark **