はじめに
案件でFSx for OpenZFSを扱う機会があったのですが、EFSやFSx for Windows File Serverと比べると圧倒的に情報が少なく、触ったことがある人もかなり限られている印象です。そこで、まずはファイルシステムを作成してEC2からマウントするところまでの基本的な手順を整理しておこうと思い、この記事を書きました。
構築自体はそこまで難しくありませんが、NFSのバージョン選択やマウントオプションなど、実際にやってみないとわからない部分もあったので、そのあたりも含めて共有します。
想定読者
- AWSの基本的なサービスを理解しているインフラエンジニア
- FSx for OpenZFSをこれから触ってみたい方
- NFSベースのファイルストレージに興味がある方
この記事でわかること
- OpenZFS(ZFS)の成り立ちと特徴
- FSx for OpenZFSのファイルシステム作成手順と各パラメータの意味
- EC2インスタンスからNFSマウントする手順と動作確認方法
OpenZFSとは何か
FSx for OpenZFSの「OpenZFS」について、少しだけ歴史を振り返っておきます。
ZFS(Zettabyte File System)は、2001年にSun MicrosystemsがSolaris向けに開発を始めたファイルシステムです。従来のファイルシステムとボリュームマネージャーを統合した設計が特徴で、スナップショット、圧縮、データ整合性チェック(チェックサム)といった機能を標準で備えていました。2005年にはSolarisの一部がOpenSolarisとしてオープンソース公開され、ZFSのソースコードも利用可能になりました。
2009〜2010年にOracleがSun Microsystemsを買収した後、OpenSolarisの開発は打ち切られ、ZFSのソースコードは非公開に戻されます。これを受けて2010年にillumosプロジェクトがOpenSolarisの最終版をforkし、オープンソースとしての開発を継続しました。その後、2013年にLinuxやFreeBSDなど複数のプラットフォームにまたがるZFS開発を統括する目的でOpenZFSプロジェクトが設立されました。2020年にはOpenZFS 2.0がリリースされ、LinuxとFreeBSDが同一リポジトリからサポートされるようになっています。
AWSのFSx for OpenZFSは、このOpenZFSをベースにしたフルマネージドのファイルストレージサービスです。ZFSの強力な機能(スナップショット、圧縮、クローンなど)をそのまま活かしつつ、インフラの運用管理をAWSに任せられるという位置付けになります。
ここまで聞くと「結構いい感じのファイルシステムなんだな〜」と思われる方が大半なのではないでしょうか。今後の記事でFSx for OpenZFSの深い内容まで扱っていくので、その記事を見た上で再度こちらの内容を振り返っていただければと思います。
ファイルシステムの作成
作成方法の選択
AWSマネジメントコンソールからFSxの画面を開き、「ファイルシステムを作成」を選択します。作成方法は「クイック作成」と「スタンダード作成」の2つがありますが、今回はパラメータを確認しながら進めたいので「スタンダード作成」を選択しました。
ファイルシステムの詳細
以下の設定でファイルシステムを作成しました。
今回の設定値
| 設定項目 | 設定値 | 補足 |
|---|---|---|
| ファイルシステム名 | redbull-dev-OpenZFS-tky | 任意の名前 |
| ストレージクラス | SSD | Intelligent-Tieringも選択可能。全データへの低レイテンシアクセスが必要な場合はSSD |
| デプロイタイプ | マルチAZ(HA) | 本番環境を想定して高可用性構成を選択 |
| SSDストレージ容量 | 64 GB | 最小構成。後からオンラインで拡張可能 |
| プロビジョンドSSD IOPS | 自動(ストレージ1 GBあたり3 IOPS) | 今回はデフォルトのまま |
| スループットキャパシティ | 160 MB/s | マルチAZ(HA)の場合、160 MB/sが最小値 |
今回は検証用であるため、ほぼ最小構成で動かしていますが利用用途に応じて調整してください。
ネットワークとセキュリティ
今回の設定値
| 設定項目 | 設定値 |
|---|---|
| VPC | 既存のVPCを選択 |
| VPCセキュリティグループ | NFS用に作成したセキュリティグループ |
| 優先サブネット | ap-northeast-1aのプライベートサブネット |
| スタンバイサブネット | ap-northeast-1cのプライベートサブネット |
| ネットワークタイプ | IPv4 |
| ルートテーブル | VPCのルートテーブルを指定 |
マルチAZ(HA)構成では、優先サブネットとスタンバイサブネットを異なるAZに配置する必要があります。フローティングIPアドレスによるフェイルオーバーのため、ルートテーブルの指定も必要です。
セキュリティグループではNFSに必要なポートを開放しておきます。FSx for OpenZFSで必要なインバウンドルールは以下のとおりです。
| プロトコル | ポート範囲 | 用途 |
|---|---|---|
| TCP | 111 | NFS portmapper |
| UDP | 111 | NFS portmapper |
| TCP | 2049 | NFS |
| UDP | 2049 | NFS |
| TCP | 20001-20003 | NFS mount |
| UDP | 20001-20003 | NFS mount |
ソースにはマウント元のEC2インスタンスが属するセキュリティグループやCIDRを指定します。
暗号化とルートボリュームの設定
今回の設定値
| 設定項目 | 設定値 |
|---|---|
| 暗号化キー | aws/fsx(デフォルト) |
| データ圧縮タイプ | LZ4 |
| タグをスナップショットにコピー | 有効 |
| NFSエクスポートオプション | rw,crossmnt |
| レコードサイズ | 128 KiB(デフォルト) |
データ圧縮はLZ4を選択しました。Z-Standard(zstd)のほうが圧縮率は高いですが、CPU負荷が大きくなるため、一般的なユースケースではLZ4が無難です。
バックアップとメンテナンス
今回の設定値
| 設定項目 | 設定値 |
|---|---|
| 毎日の自動バックアップ | 無効 |
| S3アクセス | 無効 |
| 週次メンテナンスウィンドウ | プリファレンスなし |
今回は検証目的なのでバックアップは無効にしていますが、本番環境ではAWS Backupとの連携で自動バックアップを有効にすることを推奨します。
確認画面で「作成後に編集可能」かどうかがわかる
作成前の確認画面では、各パラメータの横に「作成後に編集可能」かどうかがアイコンで表示されます。これがかなり便利で、作成前にどのパラメータが後から変更できるのか一目でわかります。
整理すると以下のとおりです。
| パラメータ | 作成後に変更可能か |
|---|---|
| ストレージクラス、デプロイタイプ | 不可 |
| VPC、サブネット | 不可 |
| 暗号化キー(KMS) | 不可 |
| ストレージ容量 | 可能 |
| プロビジョンドSSD IOPS | 可能 |
| スループットキャパシティ | 可能 |
| データ圧縮タイプ、レコードサイズ | 可能 |
| バックアップ設定、メンテナンスウィンドウ | 可能 |
ストレージクラスやデプロイタイプ、ネットワーク関連は作成後に変更できないため、最初の設計段階で慎重に決める必要があります。一方、容量やスループットは後からスケールアップできるので、最初は最小構成で始めて様子を見るという判断もしやすいです。
手動で作成する際にはこの画面と巡り合えるのですが、CloudFormationやTerraformではこの画面と遭遇することなく進んでしまうので、やはり手動で1度作っておくのは重要だなと思わされました。
作成完了
設定を確認して「ファイルシステムを作成」で作成が開始されます。ファイルシステムのステータスが「利用可能」になるまで待ちます。今回は10分ほどで作成が完了しました。この部分はシングルAZなのかマルチAZなのかによって変わります。
EC2からマウントする
マウント方式: DNSベースとIPアドレスベース
FSx for OpenZFSのボリュームをマウントする方法は2つあります。
| マウント方式 | 指定例 | 制約 |
|---|---|---|
| DNSベース | fs-xxxxx.fsx.ap-northeast-1.amazonaws.com:/fsx/ |
AWSが自動作成するDNSレコードは同一VPC内からのみ名前解決が可能 |
| IPアドレスベース | 10.8.15.221:/fsx/ |
別VPCからアクセスする場合はこちらを使う |
今回はEC2とFSxが同一VPC内にあるため、DNSベースでマウントします。別VPCからアクセスする場合、AWSが提供するデフォルトのDNS名(fs-xxxxx.fsx.region.amazonaws.com)は同一VPC内からしか解決できないため、IPアドレスを直接指定する必要があります。Route 53のPrivate Hosted ZoneにFSxのIPアドレスを登録し、そのPHZを別VPCに関連付ければDNS名でのアクセスも可能ですが、マルチAZ(HA)構成ではフローティングIPを使用するため、PHZへの静的なIP登録は推奨されません。
また、別VPCからのアクセス経路についても注意が必要です。マルチAZ(HA)構成ではフローティングIPのルーティングの都合上、VPCピアリングやDirect Connect、Site-to-Site VPNではアクセスできません。Transit Gatewayの利用が必須となります。Single-AZ構成であればVPCピアリングでもアクセス可能です。
NFSバージョンの選択: v3とv4の違い
FSx for OpenZFSはNFSv3、v4.0、v4.1、v4.2をサポートしています。どのバージョンを使うかはユースケースによって変わります。
| 比較項目 | NFSv3 | NFSv4 |
|---|---|---|
| パフォーマンス | レイテンシ、スループット、IOPSで有利な場合がある | v3よりやや劣る場合がある |
| ファイルロック | 別プロトコル(NLM)で処理 | プロトコル内蔵で堅牢 |
| クライアントキャッシュ | デリゲーションによるキャッシュなし | 読み取りデリゲーションによりクライアント側キャッシュが可能 |
| Windows対応 | Windowsクライアントで使用可能 | Windows NFSクライアントは非対応 |
| ポート | 111、2049、20001-20003が必要 | 2049のみで動作 |
パフォーマンス重視ならNFSv3、複数クライアントからの同時アクセスが多い場合やファイルロックの堅牢性を求めるならNFSv4が適しています。今回はパフォーマンスを重視してNFSv3を選択しました。
前提条件の確認
マウント先のEC2インスタンス(Amazon Linux 2023)にSSMセッションマネージャーで接続し、まずは前提条件を確認します。
nfs-utilsのインストール確認:
rpm -q nfs-utils
nfs-utils-2.5.4-2.rc3.amzn2023.0.3.x86_64
Amazon Linux 2023ではnfs-utilsがデフォルトでインストールされています。もしインストールされていなければsudo yum install -y nfs-utilsで導入します。
カーネルバージョンの確認:
uname -r
6.18.3+eb1.138.amzn2023.x86_64
ポートの疎通確認
マウントする前に、EC2からFSxのエンドポイントに対してNFS関連ポートの疎通を確認しておきます。
sudo yum install -y nmap-ncat
nc -vz fs-0e2fe071d9452224c.fsx.ap-northeast-1.amazonaws.com 111
Ncat: Connected to 10.8.15.221:111.
nc -vz fs-0e2fe071d9452224c.fsx.ap-northeast-1.amazonaws.com 2049
Ncat: Connected to 10.8.15.221:2049.
ポート111(portmapper)と2049(NFS)の両方に接続できることを確認しました。もしここで接続できない場合は、セキュリティグループやルートテーブルの設定を見直してください。
マウントの実行
マウントポイントを作成してマウントします。
sudo mkdir -p /mnt/fsx
sudo mount -t nfs -o noatime,nfsvers=3,async,nconnect=16,rsize=1048576,wsize=1048576 \
fs-0e2fe071d9452224c.fsx.ap-northeast-1.amazonaws.com:/fsx/ /mnt/fsx
主なマウントオプションの意味は以下のとおりです。
| オプション | 意味 |
|---|---|
| noatime | ファイルアクセス時にタイムスタンプを更新しない(パフォーマンス向上) |
| nfsvers=3 | NFSv3を使用 |
| async | 非同期書き込み(パフォーマンス優先) |
| nconnect=16 | NFSサーバーへの接続数を16に増やす(スループット向上) |
| rsize=1048576 | 読み取りブロックサイズを1 MBに設定 |
| wsize=1048576 | 書き込みブロックサイズを1 MBに設定 |
マウントの確認
df -hでマウントされていることを確認します。
df -h /mnt/fsx
Filesystem Size Used Avail Use% Mounted on
fs-0e2fe071d9452224c.fsx.ap-northeast-1.amazonaws.com:/fsx/ 64G 0 64G 0% /mnt/fsx
64 GBのボリュームが/mnt/fsxにマウントされていることが確認できました。
アンマウント
検証後はアンマウントして元に戻します。
sudo umount /mnt/fsx
df -h /mnt/fsx
Filesystem Size Used Avail Use% Mounted on
/dev/nvme0n1p1 30G 1.5G 29G 7% /
FSxのマウントが解除され、ローカルディスクの情報に戻っていることが確認できます。
まとめ
FSx for OpenZFSのファイルシステム作成からEC2でのNFSマウントまでの手順を整理しました。
| 手順 | ポイント |
|---|---|
| ファイルシステム作成 | デプロイタイプは可用性要件に合わせて選択。本番ならマルチAZ(HA) |
| セキュリティグループ | TCP/UDP 111、2049、20001-20003を許可 |
| 疎通確認 | マウント前にnmap-ncatでポートの疎通を確認しておくとトラブルシュートが楽 |
| マウント | nconnectやrsize/wsizeなどのオプションでパフォーマンスチューニングが可能 |
構築自体はEFSと大きく変わりませんが、NFSのバージョンやマウントオプションの選択肢が多い分、要件に合わせた調整の余地があります。本番利用に向けては、/etc/fstabへの永続化設定やAWS Backupの有効化も忘れずに検討してください。
次回はスナップショットやクローンなど、OpenZFSならではの機能についても触れてみたいと思います。