AWS FSx for NetApp ONTAP を使用して EKS 上で Multi-AZ ステートフルアプリケーションを実行する方法

このブログは 2022 年 4 月 27 日に Benson Kwong (Solution Architect) 、Haofei Feng (Senior Cloud Architect) 、Joe Guo (Cloud Support Engineer) によって執筆された内容を日本語化したものです。原文はこちらを参照して下さい。
Amazon Elastic Kubernetes Service (Amazon EKS) は、お客様自身が Kubernetes のコントロールプレーンやノードをインストール、運用、保守することなく、AWS 上で Kubernetes を簡単に実行できるフルマネージドサービスです。 組織では、Kubernetes クラスター上でステートレスアプリケーションとステートフルアプリケーションを混在させて実行することがよくあります。ステートフルアプリケーションに関しては、外部ストレージのパフォーマンスと可用性の間にトレードオフが生じることがよくあります。組織は、アプリケーションの高可用性 (複数のアベイラビリティーゾーンで利用できる) の実現と同時に、ミリ秒未満の低レイテンシーと高い IOPS を実現したいと考えています。

本記事では、 Amazon FSx for NetApp ONTAP （以下、 FSx for ONTAP ） に注目し、Amazon EKS 上のワークロードの永続層として、読み取り/書き込みレイテンシーとIOPS のパフォーマンスを確認します。 NetApp の Trident Container Storage Interface (CSI) ドライバを使用して、Amazon EKS 上のステートフルアプリケーションのサンプルをデモします。CSI ドライバは、Amazon EKS クラスターが NetApp ONTAP ファイルシステムによって作成されるストレージボリュームのライフサイクルを管理することを可能にします。

ソリューション概要

このソリューションのインフラストラクチャは、3 つの EC2 ワーカーノードを含む Amazon EKS クラスターと、複数のアベイラビリティーゾーンにまたがる FSx for ONTAP ファイルシステムで構成されています。3 つのワーカーノードと FSx for ONTAP ファイルシステムは VPC のプライベートサブネットにあります。ここでは NetApp の Trident Container Storage Interface（CSI）を使用して、Amazon EKS クラスター上で動作する MySQL データベース用に FSx for ONTAP ファイルシステム ストレージボリュームを作成する方法について説明しますによって。次のアーキテクチャ図は、本記事で使用する環境を示しています。

FSx for ONTAP とは ?

FSx for ONTAP は、NetApp の人気の ONTAP ファイルシステムをベースに、高い信頼性、拡張性、パフォーマンス、豊富な機能を備えたファイルストレージを提供するフルマネージドサービスです。NetApp のファイルシステムのおなじみの機能、パフォーマンス、性能、マルチプロトコル（iSCSI/NFS/SMB）、API を、 AWS のフルマネージドサービスとして俊敏性、拡張性、簡便性をもって提供します。

FSx for ONTAP の仕組みについては、以下を参照してください。https://docs.thinkwithwp.com/fsx/latest/ONTAPGuide/how-it-works-fsx-ontap.html

ソリューションウォークスルー

デプロイメントを完了するための主な手順は次のとおりです。

1. GitHub リポジトリからコードを クローンする。
2. AWS CloudFormation を使用して AWS アカウントに VPC 環境を作成する。 (オプション)
3. AWS CloudFormation を使用して FSx for ONTAP ファイルシステムを作成する。
4. eksctl を使用して Amazon EKS クラスターを作成する。
5. FSxONTAP という名前の ボリュームをサンプルアプリケーションのストレージ層として作成する。
6. Pod レベルのフェイルオーバをテストする。
7. FIO を使用し、Amazon EKS 上の k8s Pod 内から FSx for ONTAP ファイルシステムのパフォーマンスをテストする。
8. アベイラビリティーゾーン間での FSx for ONTAP ファイルシステムレベルのフェイルオーバーとフェイルバックを実施する。

前提条件

本ウォークスルーでは、次の前提条件を満たしている必要があります。

• Amazon VPC、Amazon EKS クラスター、FSx for ONTAP ファイルシステム、および CloudFormation スタックの作成と管理に必要な権限を持つ AWS アカウント
• eksctl、kubectl、および Helm3 が PC にインストールされていること。
  • eksctl: https://docs.thinkwithwp.com/eks/latest/userguide/eksctl.html
  • kubectl: https://docs.thinkwithwp.com/eks/latest/userguide/install-kubectl.html
  • Helm 3: https://docs.thinkwithwp.com/eks/latest/userguide/helm.html
• AWS コマンドラインインターフェイス (AWS CLI) バージョン 2.7.3 またはそれ以降で、作業環境に設定されていること。AWS CLI のインストールと設定については、AWS CLI の最新バージョンのインストールまたは更新 をご確認ください。

1. GitHub リポジトリからコードをクローンする

GitHub repo に CloudFormation のテンプレートとコードがあります。次のコマンドを実行して、リポジトリをローカルワークステーションにクローンします。

git clone https://github.com/aws-samples/mltiaz-fsxontap-eks.git

次の手順で参照する必要のあるフォルダが 2 つあります。「eks」フォルダには eks クラスターリソースに関連するすべてのマニフェストファイルを含み、「FSxONTAP」フォルダは VPC 環境と FSx for ONTAP ファイルシステムをスピンアップするための Cloudformation テンプレートを含みます。

2. Amazon EKS と FSx for ONTAP 用の VPC 環境を作成する (オプション)

CloudFormation を使用して、2 つのプライベートサブネットと 2 つのパブリックサブネットを持つ新しい VPC を作成します。この手順はオプションで、既存の VPC を Amazon EKS クラスターと FSx for ONTAP ファイルシステム用に再利用できます。

CloudFormation スタックを起動して、 FSx for ONTAP と EKS クラスターの両方のネットワーク環境を設定します。

$ cd mltiaz-fsxontap-eks/FSxONTAP
$ aws cloudformation create-stack —stack-name EKS-FSXONTAP-VPC —template-body file://./vpc-subnets.yaml —region <region-name>

スタックが正常にデプロイされた後、PrivateSubnet1、PrivateSubnet2、VPCId、PrivateRouteTable1 の ID をメモしておきます。EKS クラスターと FSx for ONTAP ファイルシステムを作成するときに必要になります。

3. FSx for ONTAP ファイルシステムを作成

次の CLI コマンドを実行し、FSx for ONTAP ファイルシステムを作成します。（上記で作成した VPC 環境に基づいて、パラメータを変更する必要があります。）

$ aws cloudformation create-stack \
 —stack-name EKS-FSXONTAP \
 —template-body file://./FSxONTAP.yaml \
 —region <region-name> \
 —parameters \
 ParameterKey=Subnet1ID,ParameterValue=[your_preferred_subnet1] \
 ParameterKey=Subnet2ID,ParameterValue=[your_preferred_subnet2] \
 ParameterKey=myVpc,ParameterValue=[your_VPC] \
 ParameterKey=FSxONTAPRouteTable,ParameterValue=[your_routetable] \
 ParameterKey=FileSystemName,ParameterValue=EKS-myFSxONTAP \
 ParameterKey=ThroughputCapacity,ParameterValue=512 \
 ParameterKey=FSxAllowedCIDR,ParameterValue=[your_allowed_CIDR] \
 ParameterKey=FsxAdminPassword,ParameterValue=[Define password] \
 ParameterKey=SvmAdminPassword,ParameterValue=[Define password] \
 —capabilities CAPABILITY_NAMED_IAM 

この CloudFormation スタックの完了にはしばらく時間がかかります。ファイルシステムがデプロイされるのを待っている間、手順 4 に進んでください。

デプロイ完了後、スクリーンショットのように FSx for ONTAP ファイルシステムと Storage Virtual Macihne （SVM）が作成されていることが確認できます。

FSx for ONTAP ファイルシステムの詳細を見てみましょう。ファイルシステムには Preferred Subnet (優先サブネット)と Standby Subnet (スタンバイサブネット) があります。

SVM も作成されます。

4. Amazon EKS クラスターの作成

この手順では、手順 2 で作成した 2 つのプライベートサブネットにまたがって存在する 3 つのワーカーノードを含むマネージドノードグループ を持つ EKS クラスターを作成します。cluster.yaml ファイルを手順 2 で起動した CloudFormation スタックの出力に基づいて VPC ID とサブネット ID を置き換えてください。

次のコマンドで EKS クラスターを作成します。

$ cd ../eks
$ eksctl create cluster -f ./cluster.yaml

$ kubectl create ns trident
namespace/trident created

# ダウンロード
$ curl -L -o trident-installer-21.10.1.tar.gz https://github.com/NetApp/trident/releases/download/v21.10.1/trident-installer-21.10.1.tar.gz

# ダウンロードしたファイルを解凍
$ tar -xvf ./trident-installer-21.10.1.tar.gz

# trident フォルダへ移動
$ cd trident-installer/helm

# クラスター設定ファイルのアップデート
$ aws eks update-kubeconfig —name FSxONTAP-eks

# helm コマンドで trident operator をインストール
$ helm install trident -n trident trident-operator-21.10.1.tgz

$ helm status trident -n trident
...
NAMESPACE: trident
STATUS: deployed
...

# リポジトリ内の svm_secrets.yaml を編集し、"SVMPassword" を置き換えてください
$ kubectl apply -f svm_secret.yaml
secret/backend-fsx-ontap-nas-secret created

$ kubectl get secrets -n trident |grep backend-fsx-ontap-nas
backend-fsx-ontap-nas-secret Opaque 2 30s

(2) Trident バックエンドの作成

クローンしたリポジトリの eks フォルダに移動し、 backend-ontap-nas.yaml ファイルを確認してください。managementLIF と dataLIF を正しい内容に置き換え、保存してください。( アプリケーションに応じてどちらの LIF を使用するか検討する際には、Trident ドキュメントを参照し、詳細を確認してください) 。

注: ManagementLif は Amazon FSx コンソールを使用して確認できます。次の図では、 Management DNS name としてハイライトされています。

デプロイされた Trident バックエンド構成のステータスが ”Success” であることを確認します。

$ cd eks
$ kubectl apply -f backend-ontap-nas.yaml
tridentbackendconfig.trident.netapp.io/backend-fsx-ontap-nas created

$ kubectl get tbc -n trident
NAME BACKEND NAME BACKEND UUID PHASE STATUS
backend-fsx-ontap-nas fsx-ontap 6329459a-55e9-4606-881d-f83e34f558db Bound Success

(3) StorageClass の作成

StorageClass の yaml マニュフェストは storage-class-csi-nas.yaml です。

$ kubectl apply -f storage-class-csi-nas.yaml
storageclass.storage.k8s.io/trident-csi create

# StorageClass のステータス確認
$ kubectl get sc
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
trident-csi csi.trident.netapp.io Retain Immediate true 42s

(4) PersistentVolumeClaim の作成

PersistentVolumeClaim マニュフェストは pvc-trident.yaml です。

PersistentVolume が正常に作成され、PersistentClaim のステータスが “Bound” であることを確認します。

$ kubectl create -f pvc-trident.yaml
persistentvolumeclaim/basic created

#　作成した永続ボリュームの状態確認
$ kubectl get pv

NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pvc-23d6b9f3-17ce-4845-a433-56b27a996435 10Gi RWX Retain Bound default/basic trident-csi 25s

Amazon FSx コンソールに戻ったら、ファイルシステムの Volumes を選択し、対応するボリュームが作成されていることを確認します。

これで Trident Operator の設定が終わり、Kubernetes の PersistentVolumeClaim を正常にプロビジョニングできることを確認できました。次のセクションでは、Amazon EKS 上で動作するステートフルアプリケーションをデプロイし、Trident によって PersistentVolume をプロビジョニングします。

7. ステートフルアプリケーションのデプロイ

ここでは、Kubernetes の Statefulset を使用して、Kubernetes クラスターに高可用性 MySQL クラスターをデプロイします。Kubernetes の Statefulsets は、データの整合性と一貫性を維持するために、元の PersistentVolume が再スケジュールされるときに同じ Pod ID にマウントされることを保証します。

ここでは、Kubernetes の ConfigMap を使用してコンフィグレーションと Pod を分離しています。今回の例では、mysql という名前の ConfigMap を適用します。Primary Pod とSecondary Pod がデプロイされると、対応するコンフィグレーションが読み込まれます。

# MySQL が動作する namespace の作成 
$ kubectl create namespace mysql

# MySQL の ConfigMap の作成
$ kubectl create -f mysql-configmap.yaml -n mysql

Kubernetes の Service は Pod の論理セットと、それらにアクセスするためのポリシーを定義します。StatefulSet ではヘッドレスサービスがその Pod のドメインを制御し、安定した DNS エントリで各 Pod に直接到達する必要があります。ClusterIP に “None” を指定すると、ヘッドレスサービスを作成できます。

# mysql headless service の作成
$ kubectl create -f ./mysql/mysql-service.yaml

#mysql headless service が作成されたことの確認
$ kubectl get service -n mysql
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
mysql ClusterIP None <none> 3306/TCP 7h48m

次に、MySQL 用の StatefulSet をデプロイする必要があります。MySQL pod には 2 つの init コンテナ (init-mysql と clone-mysql) と 2 つのアプリケーションコンテナ ( mysql と xtrabackup ) が含まれており、Pod は PersistentVolumeClaim の Trident CSI 経由で FSx for ONTAP ボリュームによって提供される PersistentVolume にバインドされます。

# mysql Statefulset の作成
$ kubectl create -f ./mysql/mysql-statefulset.yaml

# 全ての Pod が起動したことの確認
$ kubectl get pod -l app=mysql -n mysql
NAME READY STATUS RESTARTS AGE
mysql-0 2/2 Running 0 7m11s
mysql-1 2/2 Running 0 6m21s

“data-mysql-0" と ”data-mysql-1" が PersistentVolume をマウントしていることが確認できます。

$ kubectl get pv -n mysql
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pvc-d71cb057-6ccb-4769-95a0-15301d6db363 30Gi RWX Retain Bound mysql/data-mysql-1 trident-csi 7m26s
 pvc-fca2676b-8024-474c-9d8f-041e3f5f307b 30Gi RWX Retain Bound mysql/data-mysql-0 trident-csi 8m15s

Pod と PersistentVolume のマッピングを確認します。

data-mysql-0 → pvc-fca2676b-8024-474c-9d8f-041e3f5f307b

8. Kubernetes 上の MySQL pod のフェイルオーバ

この手順では、同じ Pod の名前を別の k8s ワーカーノードに再スケジュールし、再作成し、元の PersistentVolume をマウントしてデータの一貫性を確保する方法を紹介します。

サンプルデータの入力

データベースにサンプルデータを入力しましょう。データを挿入するために MySQL のプライマリノードに接続するコンテナをスピンアップします。

$ kubectl -n mysql run mysql-client —image=mysql:5.7 -i —rm —restart=Never — \
mysql -h mysql-0.mysql <<EOF
CREATE DATABASE test;
CREATE TABLE test.messages (message VARCHAR(250));
INSERT INTO test.messages VALUES ('hello, from mysql-client');
EOF

次のように実行して、フォロワーノード mysql-1 がデータを正常に受信したことを確認することができます。

$ kubectl -n mysql run mysql-client —image=mysql:5.7 -it —rm —restart=Never — mysql -h mysql-1.mysql -e "SELECT * FROM test.messages"

+--------------------------+
| message |
+--------------------------+
| hello, from mysql-client |
+--------------------------+
pod "mysql-client" deleted

ノード障害のシミュレーション

MySQL を実行しているノードを cordoning Off してノード障害をシミュレートします。

# ワーカーノードにおける Pod の配置を確認
$ kubectl get pod -n mysql -o wide -l app=mysql
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
mysql-0 2/2 Running 0 56m 10.0.1.177 ip-10-0-1-110.ap-southeast-2.compute.internal <none> <none>
mysql-1 2/2 Running 0 58m 10.0.0.152 ip-10-0-0-187.ap-southeast-2.compute.internal <none> <none>

# mysql-0 Pod が動作するワーカーノードを cordon する
$ kubectl cordon ip-10-0-1-110.ap-southeast-2.compute.internal

# ノードのステータスを確認
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
 ip-10-0-0-187.ap-southeast-2.compute.internal Ready <none> 26h v1.21.5-eks-bc4871b
 ip-10-0-1-110.ap-southeast-2.compute.internal Ready,SchedulingDisabled <none> 26h v1.21.5-eks-bc4871b
 ip-10-0-1-131.ap-southeast-2.compute.internal Ready <none> 26h v1.21.5-eks-bc4871b

次に MySQL Pod を削除します。

$ kubectl delete pod mysql-0 -n mysql
pod "mysql-0" deleted

$ kubectl get pods -n mysql -l app=mysql -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
mysql-0 2/2 Running 0 42s 10.0.1.56 ip-10-0-1-131.ap-southeast-2.compute.internal <none> <none>
mysql-1 2/2 Running 0 15m 10.0.0.152 ip-10-0-0-187.ap-southeast-2.compute.internal <none> <none>

元の PersistentVolume (pvc-fca2676b-8024-474c-9d8f-041e3f5f307b) が mysql-0 Pod に再マウントされたことが確認できます。

$ kubectl get pvc -n mysql
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
data-mysql-0 Bound pvc-87166a6d-0395-4c88-8818-ec27b7f444cb 5Gi RWO basic-csi 24h
data-mysql-1 Bound pvc-648238a3-0b96-4859-98da-7f09f3af254a 5Gi RWO basic-csi 24h

最後に、Pod が別のワーカーノードに再スケジュールされた後も、作成されたデータベース内のデータが残っていることを確認します。

$ kubectl -n mysql run mysql-client —image=mysql:5.7 -it —rm —restart=Never — mysql -h mysql-0.mysql -e "SELECT * FROM test.messages"

+--------------------------+
| message                  |
+--------------------------+
| hello, from mysql-client |
+--------------------------+
pod "mysql-client" deleted

9. FIO と IOping による性能テスト

ここでは、Trident CSI で構築した FSx for ONTAP ファイルシステムの性能を測定するために、ストレージ性能の 2 つの最も重要なパラメータ、 IOPS とレイテンシーに注目します。人気のストレージベンチマークツールである FIO（Flexible I/O）と、 I/O レイテンシーをリアルタイムで監視するツールである IOping を使用し、EKS Pod から FSx for ONTAP ドライブの性能をテストします。

9.1 EKS Pod と FSx for ONTAP が同じアベイラビリティーゾーンにある場合

FSx for ONTAP ファイルシステムの優先サブネットは ap-southeast-2a にあるため、このテストでは、同じアベイラビリティーゾーンに EKS Pod をデプロイして性能データを確認します。

手順 6 にて、StorageClass trident-csi を作成しました。

$ kubectl get sc
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
trident-csi csi.trident.netapp.io Retain Immediate true 11d
gp2 (default) kubernetes.io/aws-ebs Delete WaitForFirstConsumer false 47d

(1) Pod_Performance_Same_az.yaml が置かれているディレクトリに移動してください。

$ cd mltiaz-fxontap-eks/eks</code

(2) yaml ファイルをデプロイして FSx for ONTAP に Pod と 10 GB ストレージをプロビジョニングします。

$ kubectl apply -f pod_performance_same_AZ.yaml

(3) コンテナにログインし、FIO と IOPing のテストを実行します

# testubg コンテナへログイン
$ kubectl exec -it task-pv-pod — /bin/bash

# FIO と IOping のインストール
root@task-pv-pod:/# apt-get update
root@task-pv-pod:/# apt-get install fio ioping -y
# /usr/share/trident-nas/　へ移動
root@task-pv-pod:/# cd /usr/share/trident-nas/

# FIO コマンドを実行
root@task-pv-pod:/usr/share/trident-nas/# fio —randrepeat=1 —ioengine=libaio —direct=1 —gtod_reduce=1 —name=fiotest —filename=testfio —bs=4k —iodepth=64 —size=8G —readwrite=randrw —rwmixread=75
Starting 1 process
.....

# IOping でレイテンシーのテスト 
root@task-pv-pod:/usr/share/trident-nas# ioping -c 100 .
4 KiB <<< . (nfs4 svm-0518719800dfbb809.fs-04a7fcc8e8b5ac4f2.fsx.ap-southeast-2.amazonaws.com:/trident_pvc_f776bbf1_b0af_450b_95e7_b295a9337fd2 10 GiB): request=1 time=185.4 us (warmup)
....

# コンテナからログアウトし、 Pod を削除
root@task-pv-pod:/usr/share/trident-nas/# exit
$ kubectl delete -f pod_performance_same_AZ.yaml

9.2 EKS pod と FSx for ONTAP が異なるアベイラビリティーゾーンにある場合

ストレージと Pod が異なるアベイラビリティーゾーンにある場合のテストをしてみましょう。

(1) FSx for ONTAP 上の Pod と 10 GB ストレージを構築するための yaml ファイルをデプロイします

$ kubectl apply -f pod_performance_different_AZ.yaml

(2) コンテナにログインし、 FIO と IOping のテストを実行します

# testubg コンテナへログイン
$ kubectl exec -it task-pv-pod — /bin/bash
# FIO と IOping をインストール
root@task-pv-pod:/# apt-get update
root@task-pv-pod:/# apt-get install fio ioping -y

# /usr/share/trident-nas/ へ移動
root@task-pv-pod:/# cd /usr/share/trident-nas/

# FIO コマンドの実行し、 8 GB の書き込みを実行
root@task-pv-pod:/usr/share/trident-nas# fio —randrepeat=1 —ioengine=libaio —direct=1 —gtod_reduce=1 —name=fiotest —filename=testfio —bs=4k —iodepth=64 —size=8G —readwrite=randrw —rwmixread=75
fiotest: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64
fio-3.25
....
# IOping を使用し、レイテンシーのテスト
root@task-pv-pod:/usr/share/trident-nas# ioping -c 100 .
4 KiB <<< . (nfs4 svm-0518719800dfbb809.fs-04a7fcc8e8b5ac4f2.fsx.ap-southeast-2.amazonaws.com:/trident_pvc_2ee2111b_15ec_4862_87f9_e457e6f03aa0 10 GiB): request=1 time=732.1 us (warmup)
....

# コンテナからログアウトし、 Pod を削除
root@task-pv-pod:/usr/share/trident-nas/# exit

9.3 性能概要
FSx for ONTAP ファイルシステムでワークロードが使えるスループットと IOPS の具体的な値は、ファイルシステム上ストレージ容量とスループット容量の設定、およびワークロードの特性に依存します。この例では、ストレージ容量として 1024 GB、スループットとして 512 MB を設定しています。

同じアベイラビリティーゾーンと異なるアベイラビリティーゾーンの性能は次の通りです。

上の表が示すように、IOPS 性能はどちらのシナリオでも非常に似ていますが、平均レイテンシーは Pod とストレージが同じアベイラビリティーゾーンにある場合は約 0.5 ms、異なるアベイラビリティーゾーンにある場合は 1 msです。どちらのシナリオでも、FSx for ONTAP on EKS は、1 ms のレイテンシー、30K Read IOPS と 10K Write IOPS 以上の性能で低レイテンシーのアプリケーションをサポートしていることを示しています。

10. アベイラビリティーゾーン間のファイルシステムのフェイルオーバーとフェイルバックを実施する

業務上重要なワークローは、複数のアベイラビリティーゾーンを使用し、高い可用性を持つ必要があります。アベイラビリティーゾーンは、電源、ネットワーク、接続を冗長化した1つまたは複数のデータセンターで構成され、それぞれが別々の施設に配置されます。

本セクションでは、マルチアベイラビリティーゾーン の FSx for ONTAP ファイルシステムに対して 45 分間 FIO 書き込み処理を継続的に実行しながら、アベイラビリティーゾーン障害をシミュレートします。このプロセスでは、アベイラビリティーゾーンのフェイルオーバー中に書き込みリクエストが中断されるかどうかを確認します。

前のセクションで task-pv-pod という名前の Pod をデプロイしており、そのコンテナにログインします。

(1) コンテナにログインし、FIO を使用して FSxONTAP ボリュームに 45 分間書き込みを行います。

$ kubectl exec -it task-pv-pod — /bin/bash

FIO コマンドで 45 分間書き込みを実行します。

$ cd /usr/share/trident-nas/

$ fio —randrepeat=1 —ioengine=libaio —direct=1 —gtod_reduce=1 —name=fiotest —filename=testfio —bs=4k —iodepth=64 —size=8G —readwrite=randrw —rwmixread=75 —time_based=1 —runtime=2700s

(2) Amazon FSx コンソールに戻り、優先サブネットとスタンバイサブネットの両方のネットワークインターフェイスをメモします。

(3) FSx for ONTAP ファイルシステムにアソシエートされた Route Table をクリックし、トラフィックが優先サブネットのネットワークインターフェイスにルーティングされることを確認します。

(4) FSx for ONTAP ファイルシステムのスループット容量を 2048 MB/s に変更し、フェイルオーバーを実行します。

(5) Route Table をもう一度確認すると、トラフィックがスタンバイサブネットのネットワークインターフェイスにルーティングされていることがわかります。

(6) アベイラビリティーゾーンのフェイルオーバーとフェイルバック後の FIO コマンドの出力を確認します。

FIO ツールは、エラーなくファイルシステムを書き込み続けていることが確認できます。フェイルオーバーやフェイルバックは、ファイルシステムの書き込みテストでは影響されず行われます。

root@task-pv-pod:/usr/share/trident-nas/# fio —randrepeat=1 —ioengine=libaio —direct=1 —gtod_reduce=1 —name=fiotest —filename=testfio —bs=4k —iodepth=64 —size=8G —readwrite=randrw —rwmixread=75 —time_based=1 —runtime=2700s
Starting 1 processfiotest: Laying out IO file (1 file / 8192MiB)
Jobs: 1 (f=1): [m(1)][100.0%][r=158MiB/s,w=53=53.1MiB/s][r=40.4k,w=13.6k IOPS][eta 00m:00s]
fiotest: (groupid=0,jobs=1): err=0: pid=730: Sun Nov 14 15:44:28 2022
.....

(7) サマリ

FSx for ONTAP システムのフェイルオーバーとフェイルバックをシミュレートし、ファイルシステムのフェイルオーバーが IO エラーを発生させないことを確認できました。これは、Amazon EKS 上の FSx for ONTAP の マルチアベイラビリティーゾーン機能を示す事例です。

クリーンアップ

不必要なコストがかからないように、このデモのために先ほど作成したリソースをクリーンアップしてください。

EKS クラスターの削除: 

eksctl delete cluster —name=FSxONTAP-eks —region ap-southeast-2

FSx for ONTAP ファイルシステムの削除:

aws cloudformation delete-stack —stack-name EKS-FSxONTAP —region ap-southeast-2

VPC CloudFormation スタックを削除: 

aws cloudformation delete-stack —stack-name EKS-FSXONTAP-VPC —region ap-southeast-2

まとめ

本記事では、FSx for ONTAP サービスの概要を説明し、NetApp Trident CSI を使用して複数のアベイラビリティーゾーンにまたがる永続ボリュームをプロビジョニングする方法を説明しました。デモの性能テストと MySQL Pod のフェイルオーバ、FSx for ONTAP ファイルシステムのアベイラビリティーゾーンレベルフェイルオーバ で示したように、FSx for ONTAP は、SSD （Solid State Drive）ストレージでミリ秒未満のファイル操作のレイテンシーで高いストレージパフォーマンスを実現し、マルチアベイラビリティーゾーンの可用性を提供します。そのため、AWS を利用されているお客様が Amazon EKS 上でビジネスに重要なステートフルアプリケーションを実行する事例に適しています。

翻訳はネットアップ合同会社の方様、監修はテクニカルアカウントマネージャーの有田が担当しました。