【NetApp コラボ特集】Virt 屋のひとりごと : Trident のドライバ選定 ～ontap-nas か ontap-san か～

皆さんこんにちは。OpenShift Virtualization とストレージを生業にしている Red Hat のうつぼ（宇都宮）です。

今回から NetApp コラボ特集シリーズを始めます。それは NetApp 様のご厚意によって機器をお貸し出しいただけることになり、私の OpenShift 環境で様々な検証をさせていただけるようになったからです。
NetApp 様に心より御礼申し上げます。ありがとうございます！

これから全 8 回にわたり、お貸し出しいただいた NetApp AFF を使った検証をベースに OpenShift Virtualization + NetApp Trident の特集をお届けします。

回	テーマ
第1回（本記事）	ストレージ基本設計、Trident のドライバ選定
第2回	容量設計
第3回	性能設計
第4回	VM 移行（Shift Toolkit）
第5回	マルチテナント設計
第6回	データ保護
第7回	DR 設計
第8回	監視と運用

お付き合いいただけると幸いです。
ということで、今日のテーマは手始めに "OpenShift Virtualization + NetApp Trident で選ぶべきストレージドライバ" です。

• 検証環境
• VMware 管理者にとってのストレージ選択
• そもそも NetApp Trident とは
• NAS 系と SAN 系
• Virt でサポートされる ONTAP ドライバ
  • ontap-nas
  • ontap-san
  • ontap-san-economy
• 仮想ディスクの置き場としてどれを選ぶべきか
• まとめ

※ 以降、社名は敬称略とさせていただきます。ご容赦ください。

検証環境

この記事を作る上で、お借りした NetApp 機器を OpenShift クラスタに接続した検証環境を構築して動作を確認しました。以下には環境情報を記載します。

NetApp 機器および Trident

項目	値
ストレージモデル	NetApp AFF C190 x 2（HA ペア）
ONTAP バージョン	9.18.1P2
Trident バージョン	26.02
ディスク	SSD x 12 本（モデル: X382_S1643960ATE / 894.3GB）
SVM	svm-openshift（両ノードのアグリゲートを使用）
ネットワーク	10GbE x 4

OpenShift クラスタ

項目	値
OpenShift バージョン	4.22.0
OpenShift Virtualization バージョン	4.22.2
Control Plane Node	3 x 仮想マシン（8vCPU, 24Gi RAM）
Compute Node	3 x ベアメタルマシン（8c/16t CPU, 64Gi RAM）
ネットワーク	ネットワーク接続は以下（All 10GbE, MTU=9000）

ざっくりネットワーク図

注意：Trident バージョンについて

本記事（第1回〜第3回）の検証環境では Trident 26.02 を使用していますが、Trident 26.02 は OpenShift 4.22 を公式にはサポートしていません。検証の範囲では動作に影響はありませんでしたが、私の不注意をお詫び申し上げます。実際に環境を構築される際は、必ず Trident のサポートマトリクス を確認し、お使いの OpenShift バージョンに対応した Trident バージョンを使用してください。

VMware 管理者にとってのストレージ選択

この記事シリーズは「VMware で実現できていた運用を、OpenShift Virtualization ではどう実現するか」を軸に書いていきます。
VMware からの移行を検討されている方にも、新規に OpenShift Virtualization を導入される方にも参考になるよう、VMware での考え方との対比を挟みながら進めます。

さて、VMware 管理者の皆さんにとって、ストレージの基本設計で最初に考えることは何だったでしょうか。
データストアを NFS にするか、VMFS（iSCSI / FC）にするかですよね。

• NFS データストア : ESXi から NFS マウントするだけでデータストアとして使える。構成がシンプルで、ONTAP 側でのボリューム管理も容易。
• VMFS データストア（iSCSI / FC） : LUN をフォーマットして VMFS を載せる形。ブロックレベルのアクセスで、低レイテンシが求められるワークロードで好まれる。

どちらを選ぶかは、既存のネットワーク構成、性能要件、運用チームのスキルセットで決まっていたのではないでしょうか。

OpenShift Virtualization に来ると、Trident のストレージドライバがこの「データストアのタイプ選択」に相当する役割を担います。NFS で VM ディスクを提供するか、iSCSI / FC でブロックとして提供するかを、ストレージドライバの選択で決めるわけです。

この記事では、VMware でのデータストア選択の考え方と対比しながら、Trident のストレージドライバの種類と選び方を整理していきます。

そもそも NetApp Trident とは

VMware からの移行のご相談をいただく中で、移行先のストレージに NetApp の FAS/AFF を使いたい、というお客様は少なくありません。
NetApp FAS/AFF は VMware 環境で最もよく使われるストレージの一つなので、同じ系統のストレージを継続して使いたいというのは極めて自然なことです。

VMware 環境では、ESXi がネイティブに NFS クライアントや iSCSI イニシエータを持っていて、データストアを直接マウントしていました。追加のソフトウェアが必要になるのは、VAAI プラグイン（ONTAP tools for VMware）くらいだったと思います。

OpenShift Virtualization（以下 Virt）の世界では事情が違います。OpenShift 環境で NetApp FAS/AFF を使うには NetApp Trident（旧称 Astra Trident）が必要です。
NetApp Trident（以下 Trident）は NetApp が提供するオープンソースの CSI ドライバです。CSI ドライバ以外にも様々な機能があるのですが、OpenShift/Kubernetes から NetApp の ONTAP（FAS/AFF/ASA/Cloud Volumes ONTAP/FSx for ONTAP 等を含む）や他のストレージを動的にプロビジョニングできるようにしてくれる、ストレージプロビジョナーです。

VMware でいえば、「ESXi のデータストア管理 + VAAI + ストレージプロビジョニング」を Kubernetes のお作法に合わせて一手に引き受けてくれるもの、と思っていただくとイメージしやすいかもしれません。

docs.netapp.com

Trident では "バックエンド（backend）" という単位でストレージ接続先を定義します。バックエンドには OpenShift に接続する StorageVM（SVM）の情報やストレージドライバの指定を含みます。
VMware でいうと、「どのストレージのどのボリュームをデータストアとしてマウントするか」を定義していたのと同じ感覚です。ただし Trident ではプロビジョニングも動的に行うため、「接続先 + 自動作成のルール」をまとめて定義する形になっています。

実際にバックエンドを作るときは、TridentBackendConfig（TBC）というカスタムリソースを作成します。すると Trident が裏で実体である TridentBackend というカスタムリソースを作り、これがバックエンドを定義してくれる形になっています。
（※古くからある tridentctl という専用 CLI に JSON を食わせて作る方法もあり、これを使うことももちろんできます。両者を行き来することもできます。）

1 つの Trident には複数のバックエンドを登録できます。なので、複数の SVM を使い分けたり、単一の SVM で使い分けたり、用途に応じて StorageClass を作り分けることができます。VMware でいう「NFS データストアと VMFS データストアを並行して使う」「チームごとにデータストアを分ける」といった運用が、バックエンドと StorageClass の組み合わせで実現できるわけです。
なお、SVM を使ったマルチテナント設計（チームごとの分離、ストレージティアの割り当てなど）については、第5回で詳しく扱います。

TBC のサンプルはこのような具合です。

apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: tbc-ontap-san
  namespace: trident
spec:
  credentials:
    name: ontap-svm-openshift-secret
  defaults:
    snapshotPolicy: default
    spaceReserve: none
  managementLIF: 192.168.124.103
  sanType: iscsi
  storageDriverName: ontap-san
  svm: svm-openshift
  version: 1

svm に対象とする SVM を指定し、credentials にはその SVM の認証情報を格納した Secret を指定します。managementLIF は Trident が ONTAP を管理するためのエンドポイントで、SVM 管理 LIF でもクラスタ管理 LIF でもどちらでも指定できます。どちらを指定しても、ボリュームが実際に作られるのは svm で指定した SVM です。

で、ここで立ち止まるポイントが、さっきサラッと流した "ストレージドライバ" です。上のサンプルでは storageDriverName: ontap-san と指定されているところです。

Trident は、接続するストレージプラットフォーム（ONTAP、各社パブリッククラウドのマネージドサービス）や、使用するプロトコル（NAS、SAN）に合わせて、複数のストレージドライバを提供しています。*1
このドライバがたくさんあって、何が違ってどう使い分けるべきなのか？が最初は分からないところだと思います。ということで Virt でサポートされている ONTAP ドライバに絞って紹介していきます。

NAS 系と SAN 系

細かいドライバの前に、ONTAP 向けのドライバはまず NAS 系と SAN 系に分かれます。

VMware 管理者の方にはなじみ深い区分だと思います。VMware でも NFS データストアと VMFS データストア（iSCSI/FC）で大きくアーキテクチャが異なっていました。Trident でも同様に、NAS 系と SAN 系で PV のプロビジョニング方式が変わります。

• NAS 系（ontap-nas*） : NFS（あるいは SMB）でファイルとしてマウントします。PV は ONTAP の FlexVol として作られます。OpenShift 目線では Pod にファイルシステムをそのままマウントする形です。
  VMware でいえば NFS データストアに VMDK を置くのと同じ感覚で、ストレージ側のボリュームをそのままファイルシステムとして見せます。
• SAN 系（ontap-san*） : iSCSI / FC / NVMe/TCP でブロックデバイスとしてアタッチします。PV は ONTAP の LUN として作られます。OpenShift 目線では Pod にブロックデバイスが生えてくる形です。
  VMware でいえば VMFS データストア上の VMDK、あるいは RDM（Raw Device Mapping）に近い形で、ブロックレベルでストレージにアクセスします。

「じゃあどっちがいいの？」という話ですが、大抵の用途はどっちでも動くけど、要件によって向き不向きがあるという感じです。VMware でも「NFS と VMFS どちらがいいか」は永遠のテーマだったと思いますが、Virt でも同じ議論があり、特に後述する理由で、この NAS/SAN の選択がわりと効いてきます。

Virt でサポートされる ONTAP ドライバ

Trident には ONTAP 向けのドライバが ontap-nas、ontap-nas-economy、ontap-nas-flexgroup、ontap-san、ontap-san-economy の 5 種類ありますが、すべてが Virt で正式にサポートされているわけではありません。

次のリンク先にもある通り、Trident 26.x で Virt の正式サポート対象は以下の 3 つです。「Trident に存在するドライバ」と「Virt で正式サポートされるドライバ」は別の話なので、ここは注意してください。それぞれ見ていきます。

docs.netapp.com

ontap-nas

• プロビジョニング単位 : PV 1 つにつき FlexVol 1 つ
• プロトコル : NFS, SMB
• 特徴 : 一番オーソドックスな NAS ドライバです。PV ごとに独立した FlexVol が作られるので、ONTAP の機能（Snapshot、Clone、QoS、レプリケーション等）をボリューム単位でフルに享受できます。

VMware でいえば、NFS データストアに VMDK を置いていた運用に最も近い形です。NFS データストアを使っていた環境であれば、この ontap-nas が一番なじみやすいでしょう。ONTAP 側のボリューム管理（Snapshot、レプリケーション等）も VMware 時代とほぼ同じ操作感で行えます。

• 用途 : 迷ったらまずこれ。特に理由がなければ Virt でもこれが第一候補になりやすいです。

ontap-san

• プロビジョニング単位 : PV 1 つにつき LUN 1 つ（その LUN 専用の FlexVol の中に作られる）
• プロトコル : iSCSI, FC, NVMe/TCP
• 特徴 : ブロックストレージ用途の王道ドライバです。PV ごとに独立した LUN で、Snapshot や Clone がボリューム単位で効きます。volumeMode: Block との相性がよく、Virt の仮想ディスク向けの筆頭です。

VMware でいえば、VMFS データストアや RDM を使っていた運用に近い形です。iSCSI や FC で接続し、LUN をブロックデバイスとして提供します。「VMware では iSCSI SAN で運用していた」という環境であれば、ontap-san が自然な選択肢になります。

• 用途 : ブロックで見せたい場合。低レイテンシが欲しい、SCSI コマンドを使いたい、みたいなケース。

補足: VMware でいう RDM のように VM にブロックデバイスを直接見せたいときも、出元はこの手のブロックストレージです。ただし厳密には volumeMode とディスクのタイプは別の軸なので、RDM と完全に同じではありません。詳しくはディスクの種類の記事を参照してください。

ontap-san-economy

• プロビジョニング単位 : PV 1 つにつき LUN（1 つの FlexVol に複数 LUN を詰める）
• プロトコル : iSCSI
• 特徴 : ontap-san のスケーラビリティ強化版です。1 つの FlexVol に複数の LUN を詰めることで、FlexVol 数の上限を超えて大量の PV を作れます。Snapshot や Clone は使えますが、PV 単位の QoS やレプリケーションには制約があります。

VMware でいえば、1 つの大きな VMFS データストアに多数の VMDK を詰め込む運用に近い考え方です。スケーラビリティは高いですが、個別の VMDK（PV）単位での細かい制御には限界がある、という点も似ています。

• 用途 : iSCSI を使用し、必要な PV 数が FlexVol 数の上限を超える場合に検討してください。

補足: ontap-san では CSI Snapshot は FlexVol の Volume Snapshot（ポイントインタイムコピー）として作られますが、ontap-san-economy では 1 つの FlexVol に複数 LUN が同居しているため、対象 LUN の FlexClone LUN として作られます。"Clone" という名前ですが、WAFL のブロック共有によるほぼ瞬時の空間効率的なコピーであり、フルコピーではありません。きちんと Snapshot と同様に動作します。（参考: Volume snapshots - Trident documentation）

以上 3 つのストレージドライバを一覧にするとこんな感じです。VMware でのデータストアとの対応関係も併記します。

ドライバ	系統	PV の実体	Snapshot/Clone/DR	VMware での近い構成	ざっくり用途
ontap-nas	NAS	FlexVol	フル対応	NFS データストア + VMDK	迷ったらこれ
ontap-san	SAN	LUN	フル対応	VMFS データストア / RDM	ブロックで使いたい
ontap-san-economy	SAN	複数 LUN/FlexVol	一部制約あり	大容量 VMFS に多数 VMDK	ブロックで大量 PV

なお FlexVol や LUN の上限値は ONTAP のバージョンや FAS/AFF のモデル・搭載メモリによって変わります。正確な数字はご自身の環境（モデル + ONTAP バージョン）で NetApp Hardware Universe（HWU）を確認してください。

https://hwu.netapp.com/

仮想ディスクの置き場としてどれを選ぶべきか

それでは、Virt で使う場合にどのドライバを使うべきか。

VMware では、NFS と VMFS のどちらを選んでも vMotion（Live migration）はできていました。NFS データストアでも VMFS データストアでも、vMotion は ESXi 側が透過的に処理してくれていたからです。
Virt でも Live migration は同様に重要ですが、ストレージ側の要件が少し異なります。

Virt では VM の Live migration をやりたいので、PVC が ReadWriteMany（RWX）の AccessMode に対応していることが最重要になります。Virt の Live migration はディスクを引き渡すタイミングで移行元ノードと移行先ノードの両方から同じディスクにアクセスするため、どうしても RWX が必要になります。

VMware では vMotion 時のストレージアクセスは ESXi が VMFS のクラスタリング機構や NFS の排他制御で透過的に処理していたので、管理者がアクセスモードを意識することはほとんどなかったと思います。Virt では PVC の AccessMode を明示的に RWX にするという一手間が必要になります。

ontap-nas は、NFS で volumeMode: Filesystem の PV を提供するため、複数ノードから何の問題もなく同時マウントでき、RWX は素直にできます。よって Live migration は問題なくできます。

一方 ontap-san は、提供される PV はノードから見るとブロックデバイスですが、volumeMode: Block を指定することで RWX を実現できます。よって Live migration する際は、accessModes: ReadWriteMany & volumeMode: Block の組み合わせで実現できます。以前の RDM の記事でも同様の指定をしています。

rheb.hatenablog.com

結局、どちらにせよ Virt の仮想ディスクとして使うことはできます。じゃあどっちの方がより良いの？って思いますよね。
個人的には「Virt の仮想ディスク」というポイントのみで見ると、ontap-san がいいと思います。そもそも VM が仮想ディスクとして求めるのはブロックデバイスなので、ontap-san で LUN を見せるほうが適切だと思うからです。
しかし ontap-nas でも普通に使えるし、LUN が無い分 ONTAP 側の管理はシンプルになります。この両者を比べるにはここでは余白が少なすぎるので、第2回（容量設計）と第3回（性能設計）で徹底比較します。

VMware で「NFS と VMFS どっちがいいか」に唯一の正解がなかったのと同じで、ここでも環境と要件次第です。VMware 時代の運用を思い出しながら、以下の指針を参考にしてください。

Virt でのざっくりした指針としては、こんな感じかなと思います。

• ontap-nas
  VMware で NFS データストアを使っていた環境に近い。あまり詳しくないけどひとまず使い始めたいという場合にも、RWX が取りやすく、ボリューム単位で Snapshot もできるので、仮想ディスクの置き場として扱いやすい。
• ontap-san
  VMware で VMFS / iSCSI SAN を使っていた環境に近い。既存の FC/iSCSI SAN を使いたい、性能を追求したい、RDM 的なことをやりたいという場合に Good。
• ontap-san-economy
  PV 単位の QoS やレプリケーションに制約があるため、VM ディスク用途では基本的に第一候補にはしない。iSCSI で大量の PV が必要な場合に検討、くらいの温度感でよい。

もちろん実際には、お使いの ONTAP のプロトコル構成（NFS が引けるのか iSCSI なのか）、ネットワーク、既存の運用に強く依存します。「うちは iSCSI SAN しかないんだよ」という環境なら最初から ontap-san か ontap-san-economy が選択肢になりますし、逆に「NFS でシンプルに運用したい」なら ontap-nas 一択です。

VMware 時代に ONTAP で NFS データストアを運用していた方は ontap-nas、VMFS + iSCSI/FC で運用していた方は ontap-san を出発点にすると、これまでの運用知識をそのまま活かせるはずです。

まとめ

前置きが長かったのでサクッとまとめます。

VMware では「NFS データストアか VMFS データストアか」が最初の選択でした。Virt では「Trident のストレージドライバに何を選ぶか」がそれに相当します。

Virt で NetApp FAS/AFF を使うなら、まず ontap-nas（NFS でよければ）か ontap-san（ブロックがよければ）のどちらか、というのが大方針です。ontap-san-economy は大量の PV が必要な場合の選択肢ですが、まずは上の 2 つから検討すればまず外しません。

今回はドライバの種類だけでしたが、VMware で実現していた運用を Virt でどう再現するかは、まだまだ話すことがあります。
次回以降では以下のテーマを扱っていきます。

• 第2回: 容量設計 — ontap-nas と ontap-san で ONTAP 側の容量がどう変わるか、Snapshot reserve の考え方
• 第3回: 性能設計 — NAS / SAN の性能差の検証
• 第4回: VM 移行 — Shift Toolkit を使った VMware からの VM 移行
• 第5回: マルチテナント設計 — vCenter のフォルダ・権限・SPBM を SVM + StorageClass + Namespace でどう置き換えるか
• 第6回: データ保護 — Snapshot / バックアップの設計
• 第7回: DR 設計 — SnapMirror 等を使った DR
• 第8回: 監視と運用 — 日常運用の監視と管理

次回は ontap-nas と ontap-san の容量面での徹底比較を行います。

というわけで今日はここまで。

（※本記事の内容は各種公式ドキュメントを参照しつつ執筆していますが、実際の構成・パラメータはお使いの Trident / ONTAP のバージョンによって異なる場合があります。本番投入前には必ず公式ドキュメントと検証で裏を取ってくださいね。）

*1:既に販売終了となっている SolidFire / NetApp HCI 向けのドライバも提供されていますが、新規導入で選択するものではありません