Amazon FSx for NetApp ONTAPファイルシステムの最大ストレージサイズは実質無制限

実質無制限(176PiB)のストレージを使いこなそう
2022.06.13

NFSやSMBで接続できる領域に無制限にファイルを保存したい

こんにちは、のんピ(@non____97)です。

皆さんはNFSやSMBで接続できる領域に無制限にファイルを保存したいと思ったことはありますか? 私はあります。

Amazon S3 File Gatewayを使ってS3にデータを保存すれば良いんじゃないの?」と思われるかもしれません。しかし、私はEC2インスタンスの管理をしたくないのです。

ここで、Amazon FSx for NetApp ONTAP(FSx for ONTAP)ファイルシステムの出番です。

AWS公式のAmazon FSx ファイルシステムの比較資料を確認すると、FSx for ONTAPのファイルシステムの最大サイズは実質的に無制限(数百 PB)となっています。

Amazon FSx ファイルシステムの選択

抜粋 : Amazon FSx ファイルシステムの選択のサポート

何故、実質無制限なのかというと、FSx forONTAPファイルシステムには、プライマリストレージとキャパシティプールストレージの2つのストレージ階層があり、キャパシティプールストレージは容量上限がないからです。

???

となっていること間違い無いので、次章から詳細を説明します。

いきなりまとめ

  • FSx forONTAPファイルシステムには、プライマリストレージとキャパシティプールストレージの2つのストレージ階層がある
  • プライマリストレージはSSDストレージ
    • SSDストレージなので読み書き速度が速い
    • アクセス頻度の高いデータを保存する
    • FSx forONTAPファイルシステム作成時にプロビジョニングする
  • キャパシティプールストレージはペタバイトサイズにスケールできるストレージ
    • 裏でオブジェクトストレージに保存されるのでプライマリストレージに比べて読み書きが遅い
    • アクセス頻度の低いデータを保存する
    • 容量上限なし
    • プライマリストレージの料金と比較して安価
    • 読み込み書き込みに課金が発生する
  • FSx for ONTAPはアクセスパターンに応じてプライマリストレージとキャパシティプールストレージをブロックレベルで自動的に階層化する
  • 階層化のポリシーは以下4パターン
    • Auto : アクセス頻度の低いブロックを移動
    • Snapshot Only : スナップショットのみ移動
    • All : メタデータを除く全てを移動
    • None : 階層化を行わない
  • ボリュームサイズはプライマリストレージとキャパシティプールストレージの合算
    • キャパシティプールストレージによってボリュームで使用可能な領域が増える訳ではない

Amazon FSx for NetApp ONTAPファイルシステムのストレージの仕組み

FSx for ONTAPでは先述の通り、プライマリストレージとキャパシティプールストレージの2つのストレージ階層があります。

プライマリストレージは高速なSSDストレージです。FSx for ONTAPファイルシステム作成時にプロビジョニングするストレージはこちらです。

一方、キャパシティプールストレージはペタバイトサイズにスケールできるストレージです。こちらのストレージはFSx for ONTAPファイルシステム作成時に意識することな利用できます。

Amazon FSx for NetApp ONTAPが搭載するストレージ階層化機能 抜粋 : 1640 AWSマネージドサービス上のONTAPはデータファブリックの夢を見るか? - YouTube

キャパシティプールストレージのサイズはAWS公式ドキュメントでは度々「実質無制限」と紹介されていますが、実際は176PiBまでスケールできるようですね。

ONTAP (a NetApp product) is an enterprise data management offering designed to provide high-performance storage suitable for use with Oracle, SAP, VMware, Microsoft SQL Server, and so forth. ONTAP is flexible and scalable, with support for multi-protocol access and file systems that can scale up to 176 PiB. It supports a wide variety of features that are designed to make data management cheaper and easier including inline data compression, deduplication, compaction, thin provisioning, replication (SnapMirror), and point-in-time cloning (FlexClone).

New – Amazon FSx for NetApp ONTAP | AWS News Blog

FSx for ONTAPファイルシステムに保存されたデータは階層化ポリシーに応じてプライマリストレージとキャパシティプールストレージをブロックレベルで自動的に階層化します。階層化のポリシーは以下4パターンあります。

  • Auto : アクセス頻度の低いブロックを移動
  • Snapshot Only : スナップショットのみ移動
  • All : メタデータを除く全てを移動
  • None : 階層化を行わない

キャパシティプールストレージにあるブロックを読み取ると自動的にプライマリストレージに移動します。なお、シーケンシャルな読み取りはキャパシティプールストレージのようです。

  • 自動 は、アクティブなファイルシステムとスナップショットコピーの両方のコールドユーザーデータブロックをストレージプール層に移動します。

    データがランダムにストレージプール層から読み取られると、ストレージ層のコールドデータブロックがホットになり、プライマリストレージ層に移動します。インデックススキャンやアンチウイルススキャンに関連する読み取りなど、連続読み取りで読み取ると、コールドデータブロックはコールドのままになり、プライマリストレージ層に移動しません。

  • スナップショットのみ アクティブなファイルシステムに関連付けられていないボリュームスナップショットコピーのユーザーデータブロックをストレージプール層に移動します。

    読み取りを行うとストレージ層のコールドデータブロックがホットになり、プライマリストレージ層に移動されます。

  • すべて は、スナップショットコピーとアクティブファイルシステムの両方のコールドユーザーデータブロックをストレージプール層に移動します。

    読み取りの場合、ストレージプール層のコールドデータブロックはコールドのままで、プライマリストレージ層に書き戻されません。

  • なし (デフォルト) ボリュームのデータをプライマリストレージ層に保持し、ストレージプール層に移動しないようにします。

FSx for ONTAP ボリュームの管理 - FSx for ONTAP

ストレージ階層化の詳細はNetApp公式の動画でよく説明されています。

動画内14:25頃の説明によると、ストレージプールキャパシティは内部的にはオブジェクトストレージが使われているようです。

ONTAP 9.8からGAになったONTAP Simple Storage Service(ONTAP S3)を恐らく活用しているのではないかと考えます。

内部的にオブジェクトストレージが使われているとなると気になるのは性能ですよね。

FAQにはキャパシティープールストレージ内のデータに数十ミリ秒のレイテンシーでアクセスできるようになっていると記載があります。

低レイテンシーアクセス

Amazon FSx for NetApp ONTAP では、一貫してサブミリ秒のレイテンシーで SSD ストレージ上のデータにアクセスすることができ、さらにキャパシティープールストレージ内のデータに数十ミリ秒のレイテンシーでアクセスできるように構築されています。レイテンシーやパフォーマンスに敏感なワークロードに対して、高速で一貫したパフォーマンスを実現します。

FSx for NetApp ONTAP の特徴 – Amazon Web Services

レイテンシーが数十ミリ秒だとしても、レイテンシーが大きくなってしまうと聞いてしまっては階層化ポリシーをAutoにするのは躊躇してしまいますよね。そういった「ちょっとアクセスしなかっただけでレイテンシーが大きくなるオブジェクトストレージに移行されるのは困る」という方のために、階層化のクーリング期間が設けられています。クーリング期間はAutoSnapshot Onlyで選択可能で、範囲は2~183日間です。この設定はFSx for ONTAPのボリューム単位で行います。

また、階層化のための最小冷却期間を指定することもできます。これによりデータがコールドとみなされ、ストレージプール階層に移動される前に、ボリューム内のユーザーデータが非アクティブのままになる必要がある時間を設定します。Snapshot Only および Auto 階層化ポリシーに適用される最小冷却期間で、範囲は 2~183 日間です。(デフォルトでは ‭Snapshot Only‬ は 2 日間で、Auto‬ ポリシー は 31 日間です。)

FSx for ONTAP ボリュームの管理 - FSx for ONTAP

プライマリストレージとキャパシティプールストレージの料金

プライマリストレージとキャパシティプールストレージとで料金が異なります。

項目 ストレージの圧縮と重複排除を有効にした料金設定* 料金
SSD ストレージ容量 毎月の GB あたり 0.0525USD 毎月の GB あたり 0.150USD
使用した標準キャパシティープールストレージ 毎月の GB あたり 0.0083USD 毎月の GB あたり 0.0238USD
バックアップストレージ 毎月の GB あたり 0.0175USD 毎月の GB あたり 0.050USD
スループットキャパシティー 毎月の MBps あたり 0.906USD 毎月の MBps あたり 0.906USD
SSD IOPS 毎月の IOPS あたり 0.0204USD 毎月の IOPS あたり 0.0204USD
キャパシティープールの読み取りリクエスト 1000 リクエストあたり 0.0004USD 1000 リクエストあたり 0.0004USD
キャパシティープールの書き込みリクエスト 1000 リクエストあたり 0.0047USD 1000 リクエストあたり 0.0047USD

*汎用ファイル共有ワークロード向けの圧縮と重複排除による節約
NetApp ONTAP ファイルシステム管理の料金 – Amazon Web Services

プライマリストレージとキャパシティプールストレージをのデータの保存にかかる料金を比較すると、キャパシティプールストレージはプライマリストレージの1/6以下の料金で使用できます。ただし、キャパシティープールストレージにあるデータを読み書きする際にも課金が発生するので注意が必要です。

階層化と課金のイメージはNetApp公式動画内14:45頃の以下スライドが非常に分かりやすいと思います。

TieringでPrimary Tierのコストを削減

抜粋 : 1640 AWSマネージドサービス上のONTAPはデータファブリックの夢を見るか? - YouTube

やってみた

検証方法の整理

それでは検証をやってみたいと思います。

検証は階層化ポリシーをNoneもしくはAllにした場合、それぞれボリュームサイズがどのように見えるのかを確認してみます。

検証で使うボリュームは以下の通りです。

{
  "Volume": {
    "CreationTime": "2022-06-13T02:10:09.876000+00:00",
    "FileSystemId": "fs-0967312eff2f5f5e1",
    "Lifecycle": "CREATING",
    "Name": "volume_tiering_test",
    "OntapConfiguration": {
      "FlexCacheEndpointType": "NONE",
      "JunctionPath": "/volume_tiering_test",
      "SecurityStyle": "MIXED",
      "SizeInMegabytes": 10240,
      "StorageEfficiencyEnabled": true,
      "StorageVirtualMachineId": "svm-0a3a78e7c64ff2c5d",
      "StorageVirtualMachineRoot": false,
      "TieringPolicy": {
        "Name": "NONE"
      },
      "OntapVolumeType": "RW"
    },
    "ResourceARN": "arn:aws:fsx:ap-northeast-1:558476238088:volume/fs-0967312eff2f5f5e1/fsvol-09324531b76f1dedf",
    "Tags": [
      {
        "Key": "Name",
        "Value": "volume_tiering_test"
      }
    ],
    "VolumeId": "fsvol-09324531b76f1dedf",
    "VolumeType": "ONTAP"
  }
}

階層化ポリシーがNoneの場合

まず、階層化ポリシーがNoneの場合です。

検証の前に現在のボリュームの使用量を確認しておきます。

# ボリュームの使用率の確認
FsxId0967312eff2f5f5e1::> volume show -volume volume_tiering_test
Vserver   Volume       Aggregate    State      Type       Size  Available Used%
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
classmethod-dev-fsx-netapp-ontap-single-az-svm
          volume_tiering_test
                       aggr1        online     RW         10GB     9.50GB    0%

# プライマリストレージとキャパシティプールストレージのサイズの確認
FsxId0967312eff2f5f5e1::> volume show-footprint -volume volume_tiering_test

      Vserver : classmethod-dev-fsx-netapp-ontap-single-az-svm
      Volume  : volume_tiering_test

      Feature                                          Used    Used%
      --------------------------------           ----------    -----
      Volume Data Footprint                           296KB       0%
             Footprint in Performance Tier            992KB     100%
             Footprint in FSxFabricpoolObjectStore
                                                         0B       0%
      Volume Guarantee                                   0B       0%
      Flexible Volume Metadata                      61.95MB       0%
      Delayed Frees                                   696KB       0%

      Total Footprint                               62.91MB       0%

Footprint in Performance Tierが100%で、Footprint in FSxFabricpoolObjectStoreが0%であることから、データは全てプライマリストレージにあることが分かります。

ストレージサイズはNetApp ONTAP CLIだけでなく、CloudWatchメトリクスからでも確認できます。AWSマネージメントコンソールからFSx for ONTAPファイルシステム全体のプライマリストレージとキャパシティプールストレージのサイズを確認してみます。

CloudWatchメトリクスからFSx for ONTAPファイルシステム全体のプライマリストレージとキャパシティプールストレージのサイズを確認

キャパシティプールストレージが0GBでプライマリストレージが3.29GB使われていますね。

こちらのボリュームをマウントしてみます。

# マウントポイントの作成
sh-4.2$ sudo mkdir /volume_tiering_test

# マウント
sh-4.2$ sudo mount -t nfs svm-0a3a78e7c64ff2c5d.fs-0967312eff2f5f5e1.fsx.ap-northeast-1.amazonaws.com:/volume_tiering_test /volume_tiering_test

# ディスクサイズの確認
sh-4.2$ df -hT
Filesystem                                                                                       Type      Size  Used Avail Use% Mounted on
devtmpfs                                                                                         devtmpfs  462M     0  462M   0% /dev
tmpfs                                                                                            tmpfs     470M     0  470M   0% /dev/shm
tmpfs                                                                                            tmpfs     470M  456K  470M   1% /run
tmpfs                                                                                            tmpfs     470M     0  470M   0% /sys/fs/cgroup
/dev/nvme0n1p1                                                                                   xfs       8.0G  1.7G  6.4G  21% /
/dev/mapper/3600a09806c574231752b53784865462f1                                                   ext4      2.0G  6.1M  1.8G   1% /lun/part1
/dev/mapper/3600a09806c574231752b537848654672p2                                                  ext4      2.9G  9.1M  2.8G   1% /lun/part2
svm-0a3a78e7c64ff2c5d.fs-0967312eff2f5f5e1.fsx.ap-northeast-1.amazonaws.com:/volume_tiering_test nfs4      9.5G  256K  9.5G   1% /volume_tiering_test

# マウントされていることを確認
sh-4.2$ mount | grep nfs
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)
svm-0a3a78e7c64ff2c5d.fs-0967312eff2f5f5e1.fsx.ap-northeast-1.amazonaws.com:/volume_tiering_test on /volume_tiering_test type nfs4 (rw,relatime,vers=4.1,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.0.0.162,local_lock=none,addr=10.0.10.31)

マウント後、8GBのバイナリファイルをマウントポイント配下に作成します。

# 8GBのバイナリファイルをマウントポイント配下に作成
sh-4.2$ sudo dd if=/dev/urandom of=/volume_tiering_test/testfile bs=1M count=8192
8192+0 records in
8192+0 records out
8589934592 bytes (8.6 GB) copied, 65.7837 s, 131 MB/s

# ディスクサイズの確認
sh-4.2$ df -hT
Filesystem                                                                                       Type      Size  Used Avail Use% Mounted on
devtmpfs                                                                                         devtmpfs  462M     0  462M   0% /dev
tmpfs                                                                                            tmpfs     470M     0  470M   0% /dev/shm
tmpfs                                                                                            tmpfs     470M  456K  470M   1% /run
tmpfs                                                                                            tmpfs     470M     0  470M   0% /sys/fs/cgroup
/dev/nvme0n1p1                                                                                   xfs       8.0G  1.7G  6.4G  21% /
/dev/mapper/3600a09806c574231752b53784865462f1                                                   ext4      2.0G  6.1M  1.8G   1% /lun/part1
/dev/mapper/3600a09806c574231752b537848654672p2                                                  ext4      2.9G  9.1M  2.8G   1% /lun/part2
svm-0a3a78e7c64ff2c5d.fs-0967312eff2f5f5e1.fsx.ap-northeast-1.amazonaws.com:/volume_tiering_test nfs4      9.5G  8.2G  1.4G  86% /volume_tiering_test

8GBのバイナリファイル作成後NetApp ONTAP CLIでボリュームサイズを確認してみます。

# ボリュームの使用率の確認
FsxId0967312eff2f5f5e1::> volume show -volume volume_tiering_test
Vserver   Volume       Aggregate    State      Type       Size  Available Used%
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
classmethod-dev-fsx-netapp-ontap-single-az-svm
          volume_tiering_test
                       aggr1        online     RW         10GB     1.38GB   85%

# プライマリストレージとキャパシティプールストレージのサイズの確認
FsxId0967312eff2f5f5e1::> volume show-footprint -volume volume_tiering_test

      Vserver : classmethod-dev-fsx-netapp-ontap-single-az-svm
      Volume  : volume_tiering_test

      Feature                                          Used    Used%
      --------------------------------           ----------    -----
      Volume Data Footprint                          8.12GB       1%
             Footprint in Performance Tier
                                                     8.13GB     100%
             Footprint in FSxFabricpoolObjectStore
                                                         0B       0%
      Volume Guarantee                                   0B       0%
      Flexible Volume Metadata                      61.95MB       0%
      Deduplication                                  9.92MB       0%
      Delayed Frees                                  7.75MB       0%

      Total Footprint                                8.20GB       1%

Footprint in Performance Tierが100%で、Footprint in FSxFabricpoolObjectStoreが0%であることから、作成したデータは全てプライマリストレージにあることが分かります。

AWSマネージメントコンソールからFSx for ONTAPファイルシステム全体のプライマリストレージとキャパシティプールストレージのサイズを確認してみます。

AWSマネージメントコンソールからFSx for ONTAPファイルシステム全体のプライマリストレージとキャパシティプールストレージのサイズを確認

プライマリストレージの使用量が3.29GBから12GBに増えました。キャパシティプールストレージの使用量は変わらず0GBのままです。

この状態で、さらに8GBのバイナリファイルを追加しようとしてみます。

# 8GBのバイナリファイルをマウントポイント配下に作成
sh-4.2$ sudo dd if=/dev/urandom of=/volume_tiering_test/testfile2 bs=1M count=8192
dd: error writing ‘/volume_tiering_test/testfile2’: No space left on device
dd: closing output file ‘/volume_tiering_test/testfile2’: No space left on device

# ファイルが作成されたか確認
sh-4.2$ ls -l /volume_tiering_test/
total 9852548
-rw-r--r-- 1 root root 8589934592 Jun 13 02:43 testfile
-rw-r--r-- 1 root root 1532645376 Jun 13 02:47 testfile2

ストレージの空き容量が足りず、1.5GB程度のファイルしか作成できませんでした。当然です。

階層化ポリシーがALLの場合

次に階層化ポリシーがALLの場合です。

先ほどのボリュームの階層化ポリシーをNoneに変更します。

階層化ポリシーを "ALL" に変更
$ aws fsx update-volume \
    --volume-id "$volume_id" \
    --ontap-configuration TieringPolicy={Name=ALL}
{
    "Volume": {
        "CreationTime": "2022-06-13T02:10:09.876000+00:00",
        "FileSystemId": "fs-0967312eff2f5f5e1",
        "Lifecycle": "CREATED",
        "Name": "volume_tiering_test",
        "OntapConfiguration": {
            "FlexCacheEndpointType": "NONE",
            "JunctionPath": "/volume_tiering_test",
            "SecurityStyle": "MIXED",
            "SizeInMegabytes": 10240,
            "StorageEfficiencyEnabled": true,
            "StorageVirtualMachineId": "svm-0a3a78e7c64ff2c5d",
            "StorageVirtualMachineRoot": false,
            "TieringPolicy": {
                "Name": "NONE"
            },
            "UUID": "f7a1b768-eabd-11ec-8b1b-41bd7f3524dc",
            "OntapVolumeType": "RW"
        },
        "ResourceARN": "arn:aws:fsx:ap-northeast-1:558476238088:volume/fs-0967312eff2f5f5e1/fsvol-09324531b76f1dedf",
        "VolumeId": "fsvol-09324531b76f1dedf",
        "VolumeType": "ONTAP"
    }
}

# 階層化ポリシーが "ALL" に変更されたことを確認
$ aws fsx describe-volumes \
    --volume-id "$volume_id"
{
    "Volumes": [
        {
            "CreationTime": "2022-06-13T02:10:09.876000+00:00",
            "FileSystemId": "fs-0967312eff2f5f5e1",
            "Lifecycle": "CREATED",
            "Name": "volume_tiering_test",
            "OntapConfiguration": {
                "FlexCacheEndpointType": "NONE",
                "JunctionPath": "/volume_tiering_test",
                "SecurityStyle": "MIXED",
                "SizeInMegabytes": 10240,
                "StorageEfficiencyEnabled": true,
                "StorageVirtualMachineId": "svm-0a3a78e7c64ff2c5d",
                "StorageVirtualMachineRoot": false,
                "TieringPolicy": {
                    "Name": "ALL"
                },
                "UUID": "f7a1b768-eabd-11ec-8b1b-41bd7f3524dc",
                "OntapVolumeType": "RW"
            },
            "ResourceARN": "arn:aws:fsx:ap-northeast-1:558476238088:volume/fs-0967312eff2f5f5e1/fsvol-09324531b76f1dedf",
            "VolumeId": "fsvol-09324531b76f1dedf",
            "VolumeType": "ONTAP"
        }
    ]
}

階層化ポリシーがALLになったことを確認した後、AWSマネージメントコンソールからFSx for ONTAPファイルシステム全体のプライマリストレージとキャパシティプールストレージのサイズも確認します。

階層化ポリシーがALLになったことを確認した後AWSマネージメントコンソールからFSx for ONTAPファイルシステム全体のプライマリストレージとキャパシティプールストレージのサイズも確認

キャパシティプールストレージの使用量が0GBから10.1GBに増え、プライマリストレージの使用量が12GBから3.6GBに減りました。ストレージ階層の移動が発生したようですね。

NetApp ONTAP CLIでボリュームサイズに変更があるかも確認します。

# ボリュームの使用率の確認
FsxId0967312eff2f5f5e1::> volume show -volume volume_tiering_test
Vserver   Volume       Aggregate    State      Type       Size  Available Used%
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
classmethod-dev-fsx-netapp-ontap-single-az-svm
          volume_tiering_test
                       aggr1        online     RW         10GB    16.26MB   99%

# プライマリストレージとキャパシティプールストレージのサイズの確認                   
FsxId0967312eff2f5f5e1::> volume show-footprint -volume volume_tiering_test

      Vserver : classmethod-dev-fsx-netapp-ontap-single-az-svm
      Volume  : volume_tiering_test

      Feature                                          Used    Used%
      --------------------------------           ----------    -----
      Volume Data Footprint                          9.48GB       1%
             Footprint in Performance Tier
                                                    151.4MB       2%
             Footprint in FSxFabricpoolObjectStore
                                                     9.36GB      98%
      Volume Guarantee                                   0B       0%
      Flexible Volume Metadata                      61.95MB       0%
      Deduplication                                 55.68MB       0%
      Delayed Frees                                 23.55MB       0%

      Total Footprint                                9.62GB       1%

Footprint in Performance Tierが100%から2%に減少しました。一方、Footprint in FSxFabricpoolObjectStoreは0%から98%に増加しました。NetApp ONTAP CLIからもストレージ階層の移動が発生したことが確認できました。

ボリュームの使用率はストレージ階層の移動が発生しても99%のままです。どうやらキャパシティプールストレージに移動した分、使用可能な領域が増える訳ではなく、ボリュームサイズはプライマリストレージとキャパシティプールストレージの合算のようですね。

試しに8GBのバイナリファイルを追加しようとしてみます。

# ディスクサイズの確認
sh-4.2$ df -hT
Filesystem                                                                                       Type      Size  Used Avail Use% Mounted on
devtmpfs                                                                                         devtmpfs  462M     0  462M   0% /dev
tmpfs                                                                                            tmpfs     470M     0  470M   0% /dev/shm
tmpfs                                                                                            tmpfs     470M  456K  470M   1% /run
tmpfs                                                                                            tmpfs     470M     0  470M   0% /sys/fs/cgroup
/dev/nvme0n1p1                                                                                   xfs       8.0G  1.7G  6.4G  21% /
/dev/mapper/3600a09806c574231752b53784865462f1                                                   ext4      2.0G  6.1M  1.8G   1% /lun/part1
/dev/mapper/3600a09806c574231752b537848654672p2                                                  ext4      2.9G  9.1M  2.8G   1% /lun/part2
svm-0a3a78e7c64ff2c5d.fs-0967312eff2f5f5e1.fsx.ap-northeast-1.amazonaws.com:/volume_tiering_test nfs4      9.5G  9.5G   17M 100% /volume_tiering_test

# 8GBのバイナリファイルの作成
sh-4.2$ sudo dd if=/dev/urandom of=/volume_tiering_test/testfile3 bs=1M count=8192
dd: error writing ‘/volume_tiering_test/testfile3’: No space left on device
dd: closing output file ‘/volume_tiering_test/testfile3’: No space left on device

# ファイルの作成が途中で終了していることを確認
sh-4.2$ ls -l /volume_tiering_test/
total 9869132
-rw-r--r-- 1 root root 8589934592 Jun 13 02:43 testfile
-rw-r--r-- 1 root root 1532645376 Jun 13 02:47 testfile2
-rw-r--r-- 1 root root   17629184 Jun 13 02:59 testfile3

# 空き容量が 17MB から 576KB に減少したことを確認 
sh-4.2$ df -hT
Filesystem                                                                                       Type      Size  Used Avail Use% Mounted on
devtmpfs                                                                                         devtmpfs  462M     0  462M   0% /dev
tmpfs                                                                                            tmpfs     470M     0  470M   0% /dev/shm
tmpfs                                                                                            tmpfs     470M  512K  470M   1% /run
tmpfs                                                                                            tmpfs     470M     0  470M   0% /sys/fs/cgroup
/dev/nvme0n1p1                                                                                   xfs       8.0G  1.7G  6.4G  21% /
/dev/mapper/3600a09806c574231752b53784865462f1                                                   ext4      2.0G  6.1M  1.8G   1% /lun/part1
/dev/mapper/3600a09806c574231752b537848654672p2                                                  ext4      2.9G  9.1M  2.8G   1% /lun/part2
svm-0a3a78e7c64ff2c5d.fs-0967312eff2f5f5e1.fsx.ap-northeast-1.amazonaws.com:/volume_tiering_test nfs4      9.5G  9.5G  576K 100% /volume_tiering_test

やはり、ボリュームサイズ以上の書き込みはできないようです。

実質無制限(176PiB)のストレージを使いこなそう

FSx for ONTAPファイルシステムの最大ストレージサイズは実質無制限という紹介をしました。

既存のファイルサーバーから移行する際は、全体のストレージサイズをそのままFSx for ONTAPファイルシステムのサイズにするのではなく、どのぐらいのファイルがアクティブに使われているのかを考慮した上でサイジングするのが良さそうです。

FSx for ONTAPではデプロイ後にプライマリストレージサイズを大きくすることも可能です。まずは、スモールスタートで様子を見るのも良いと考えます。

また、キャパシティプールストレージはプライマリストレージの1/6以下の料金で利用できるということもあり、FSx for ONTAPファイルシステム上でアーカイブ的な使い方をしても良さそうですね。

この記事が誰かの助けになれば幸いです。

以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!