Amazon Web Services ブログ
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.aws.amazon.com/fsx/latest/ONTAPGuide/how-it-works-fsx-ontap.html
ソリューションウォークスルー
デプロイメントを完了するための主な手順は次のとおりです。
- GitHub リポジトリからコードを クローンする。
- AWS CloudFormation を使用して AWS アカウントに VPC 環境を作成する。 (オプション)
- AWS CloudFormation を使用して FSx for ONTAP ファイルシステムを作成する。
- eksctl を使用して Amazon EKS クラスターを作成する。
- FSxONTAP という名前の ボリュームをサンプルアプリケーションのストレージ層として作成する。
- Pod レベルのフェイルオーバをテストする。
- FIO を使用し、Amazon EKS 上の k8s Pod 内から FSx for ONTAP ファイルシステムのパフォーマンスをテストする。
- アベイラビリティーゾーン間での FSx for ONTAP ファイルシステムレベルのフェイルオーバーとフェイルバックを実施する。
前提条件
本ウォークスルーでは、次の前提条件を満たしている必要があります。
- Amazon VPC、Amazon EKS クラスター、FSx for ONTAP ファイルシステム、および CloudFormation スタックの作成と管理に必要な権限を持つ AWS アカウント
- eksctl、kubectl、および Helm3 が PC にインストールされていること。
- 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 環境に基づいて、パラメータを変更する必要があります。）
この 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
5. Trident Operator のデプロイ
Trident CSI ドライバ をデプロイするには、 3 つの方法 ( helm, Trident Operator, and tridentctl))があります。本記事では、helm を使用してドライバをデプロイします ( 本記事ではバージョン 21.07 でテストしています。 )
(1) “Trident” namespace の作成
$ kubectl create ns trident
namespace/trident created(2) インストーラバンドルのダウンロード
Trident 21.07 (または最新版) のインストーラバンドル を Trident Github ページよりダウンロードします。インストーラバンドル には /helm ディレクトリに、 Helm チャート が含まれます。
# ダウンロード
$ 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
(3) Helm install コマンドでインストール
# 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(4) Trident Operator のステータスを確認します。
$ helm status trident -n trident
...
NAMESPACE: trident
STATUS: deployed
...6. Trident ボリュームと StorageClass のプロビジョニング
(1) SVM の username と password を保存するためのKubernetes Secret の作成
SVM の username と password を svm_secret.yaml という名前で保存します。
注: SVM の username と password は手順 3 で作成されています。もし覚えていない場合は、次のスクリーンショットのように、AWS Secrets Manager から取得することができます。
# リポジトリ内の 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 としてハイライトされています。
| パラメータ | 概要 | 備考 |
| backendName | Storage Backend のカスタムの名前 | |
| managementLIF | クラスターまたは SVM の管理 LIF の IP アドレスもしくは FQDN | |
| dataLIF | dataLIF の IP アドレス | バックエンドに ONTAP-SAN ドライバを選択した場合、 dataLIF はスキップすることができます。 |
| svm | 利用するストレージ仮想マシン |
デプロイされた Trident バックエンド構成のステータスが ”Success” であることを確認します。
(3) StorageClass の作成
StorageClass の yaml マニュフェストは storage-class-csi-nas.yaml です。
(4) PersistentVolumeClaim の作成
PersistentVolumeClaim マニュフェストは pvc-trident.yaml です。
PersistentVolume が正常に作成され、PersistentClaim のステータスが “Bound” であることを確認します。
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 にバインドされます。
“data-mysql-0" と ”data-mysql-1" が PersistentVolume をマウントしていることが確認できます。
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" deletedStatefulSet の Replica 数を維持するために、Pod を別のアベイラビリティーゾーンにある他の EKS ワーカーノードに再スケジュールします。 mysql-0 Pod が別のワーカーノードに再スケジュールされたことを確認します。
$ 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" deleted9. 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 のテストを実行します
9.3 性能概要
FSx for ONTAP ファイルシステムでワークロードが使えるスループットと IOPS の具体的な値は、ファイルシステム上ストレージ容量とスループット容量の設定、およびワークロードの特性に依存します。この例では、ストレージ容量として 1024 GB、スループットとして 512 MB を設定しています。
同じアベイラビリティーゾーンと異なるアベイラビリティーゾーンの性能は次の通りです。
| シナリオ | 平均 IOPS (read) | 平均 IOPS (write) | 平均 スループット (read) | 平均 スループット (write) | 平均 レイテンシー |
| 同じアベイラビリティーゾーン | 37.5K | 12.5K | 154 MB/s | 51.3 MB/s | 483.8 us |
| 異なるアベイラビリティーゾーン | 33.4 K | 11.1 K | 137 MB/s | 45.6 MB/s | 1.03 ms |
上の表が示すように、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 クラスターの削除:
FSx for ONTAP ファイルシステムの削除:
VPC CloudFormation スタックを削除:
まとめ
本記事では、FSx for ONTAP サービスの概要を説明し、NetApp Trident CSI を使用して複数のアベイラビリティーゾーンにまたがる永続ボリュームをプロビジョニングする方法を説明しました。デモの性能テストと MySQL Pod のフェイルオーバ、FSx for ONTAP ファイルシステムのアベイラビリティーゾーンレベルフェイルオーバ で示したように、FSx for ONTAP は、SSD （Solid State Drive）ストレージでミリ秒未満のファイル操作のレイテンシーで高いストレージパフォーマンスを実現し、マルチアベイラビリティーゾーンの可用性を提供します。そのため、AWS を利用されているお客様が Amazon EKS 上でビジネスに重要なステートフルアプリケーションを実行する事例に適しています。
翻訳はネットアップ合同会社の方様、監修はテクニカルアカウントマネージャーの有田が担当しました。