🍩

Google Cloud のつよいファイルストレージ NetApp Volumes を試してみた

2024/04/18に公開

Google Cloud

storage

netapp

tech

はじめに

こんにちは！クラウドエースの SRE 部に所属している小田です。
今回は、Google Cloud と NetApp が開発した Google Cloud NetApp Volumes というファイルストレージのお話です。
ずっと前から気になっていたけど、ネット上に全然情報が無かったので自分で試してみました。

Google Cloud NetApp Volumes とは

Google Cloud NetApp Volumes は、2023 年 8 月 25 日から一般提供開始されたフルマネージドサービスです。
マーケットプレイスで提供されている NetApp Cloud Volumes ONTAP とは別のサービスです。

NetApp Cloud Volumes ONTAP は ONTAP を Compute Engine 上で動作させるため自由度が高く、オンプレミス環境の NetApp のストレージと同じように利用することができるサービスですが、本記事で扱う Google Cloud NetApp Volumes は ONTAP を利用したことが無い方でも簡単に利用できるフルマネージドのファイルストレージサービスです。

アーキテクチャ

Google Cloud NetApp Volumes は、サービスプロデューサーによって管理されている VPC ネットワーク内に構築されます。
そのため、Cloud SQL などのサービスと同様にプライベートサービスアクセスを構成して、ユーザー側の VPC ネットワークから接続できるようにする必要があります。

NetApp Volumes のネットワーク構成

対応プロトコル

NFS は v3、v4.1 に対応。SMB は 2.1、3.0、3.1.1 のバージョンに対応。
マルチプロトコルにも対応しています。

ボリュームで選択できるプロトコルは以下の通りです。

NFSv3
NFSv4.1
Both (NFSv3/NFSv4.1)
SMB
Dual-protocol (SMB & NFSv3)
Dual-protocol (SMB & NFSv4.1)

サービスレベル

Standard、Premium、Extreme の 3 つのサービスレベルが提供されています。

	Standard	Premium	Extreme
ストレージプールサイズ	2TiB ~ 200TiB	2TiB ~ 10PiB	2TiB ~ 10PiB
パフォーマンス	TiB あたり最大 16 MiB/s	TiB あたり最大 64 MiB/s	TiB あたり最大 128 MiB/s
ボリュームサイズ	100 GiB ~ 100TiB	100 GiB ~ 100TiB	100 GiB ~ 100TiB
サービスレベルの変更	❌変更不可	✅Premium ↔ Extreme 間で変更可能	✅Premium ↔ Extreme 間で変更可能
SLA	99.9%(単一地域)	99.95%(単一地域)	99.95%(単一地域)
ボリュームのレプリケーション	サポートされているリージョンペア内の同じサービスレベル間	同じサービスレベルと Premium ～ Extreme サービスレベルの間	同じサービスレベルと Premium ～ Extreme サービスレベルの間
プロトコル	NFSv3 NFSv4.1 SMB2.1、3.0、3.1.1	NFSv3 NFSv4.1 SMB2.1、3.0、3.1.1	NFSv3 NFSv4.1 SMB2.1、3.0、3.1.1
暗号化	Google 管理の暗号化キー顧客管理の暗号化キー (CMEK)	Google 管理の暗号化キー顧客管理の暗号化キー (CMEK)	Google 管理の暗号化キー顧客管理の暗号化キー (CMEK)

ユースケース

パフォーマンスが要求される多様なワークロードに利用できます。

たとえば、以下のような使い方ができると思います。

Windows や Linux とのファイル共有
汎用データベース
Google Kubernetes Engine の永続ストレージ
VMware Horizon などの VDI プロファイル
Google Cloud VMware Engine
SAP ファイル共有

料金

料金について説明します。
執筆時点で、NetApp Volumes は Google Cloud 料金計算ツールには対応していません。

ストレージプールの料金

NetApp Volumes は保存されているデータ量に対してではなく、プロビジョニングされているストレージプールの容量に対して料金が発生します。

そのため最低でも月額 $471.04 の料金が発生します。
※Standard Tier で最小のストレージプール容量 (2TiB) の場合

サービスレベル	Price per GiB
Standard	$0.23
Premium	$0.3383
Extreme	$0.4516

ボリュームレプリケーションの料金

ボリュームレプリケーションを利用する場合に発生する料金です。

レプリケーションの頻度によって発生する金額が異なります。
また、VPC ネットワークのデータ転送料金も別途発生します。

1 日の頻度で転送	1 時間の頻度で転送	10 分の頻度で転送
$0.11	$0.12	$0.14

バックアップの料金

バックアップされるデータ量応じて料金が発生します。
バックアップストレージの料金は 1 GiB あたり月額 $0.0518 です。

試してみる

とりあえず NetApp Volumes を触って試してみます。

ストレージプールを作成する

はじめに NetApp API (netapp.googleapis.com) を有効化します。

NetApp Volumes のプロダクトページに移動し、ストレージプールを作成します。

ストレージプール名、リージョン、サービスレベルを入力します。
ストレージプールの容量は後から増やすことができます。

VPC ネットワークを選択します。

NetApp Volumes はサービスプロデューサーの VPC ネットワーク作成されるため、VPC ネットワークにプライベートサービスアクセスを作成します。

NFS で接続する

NFS のボリュームを作成します。

各種項目を入力します。
今回は先程作成したストレージプールに 512GiB のボリュームを作成します。
ボリュームの容量も後から増やすことができます。
プロトコルは NFSv4.1 を選択しました。

必要に応じて Export Rules(NFS を利用する場合のみ)、スナップショットやバックアップの設定を行うことができます。

ボリュームの作成後、事前に VPC ネットワーク内に Ubuntu 22.04 LTS の Compute Engine インスタンスを作成していたので、このインスタンスからボリュームに接続してみます。

ボリュームの Show more から NFS のマウント手順が確認できるため、基本的にはこれに従ってボリュームをマウントします。

初めて NetApp Volumes と NFS で接続する場合、この手順では足りないため追加で操作を行います。

NFS クライアントをインストールします。

$ sudo apt-get install nfs-common

NFS クライアントの設定を行います。
今回はボリュームで LDAP を使用していないため、Domain のコメントを解除して defaultv4iddomain.com というドメイン名に変更します。

$ sudo vi /etc/idmapd.conf

[General]

Verbosity = 0
# set your own domain here, if it differs from FQDN minus hostname
Domain = defaultv4iddomain.com

[Mapping]

Nobody-User = nobody
Nobody-Group = nogroup

変更を反映します。

$ sudo nfsidmap -c

ディレクトリを作成します。

$ sudo mkdir /test-volume

ボリュームをマウントします。

$ sudo mount -t nfs -o rw,hard,rsize=65536,wsize=65536,vers=4.1,tcp 10.0.20.4:/test-volume /test-volume

マウントされたボリュームを確認します。

$ df -hT

作成した test-volume が NFSv4 でマウントされていることが確認できました。

Filesystem             Type      Size  Used Avail Use% Mounted on
/dev/root              ext4      9.6G  1.9G  7.7G  20% /
tmpfs                  tmpfs     2.0G     0  2.0G   0% /dev/shm
tmpfs                  tmpfs     781M  968K  780M   1% /run
tmpfs                  tmpfs     5.0M     0  5.0M   0% /run/lock
efivarfs               efivarfs   56K   24K   27K  48% /sys/firmware/efi/efivars
/dev/sda15             vfat      105M  6.1M   99M   6% /boot/efi
tmpfs                  tmpfs     391M  4.0K  391M   1% /run/user/1001
10.0.20.4:/test-volume nfs4      512G  320K  512G   1% /test-volume

SMB で接続する

はじめに Active Directory ポリシーを作成し、Active Directory の構成情報をストレージプールに渡します。

今回は事前に作成していた Compute Engine の Windows Server 2022 の AD DS を利用します。
また、NetApp Volumes で使用しているプライベートサービスアクセスの IP 範囲からの通信をファイアウォールで許可し、AD と通信が行える必要があります。

ポリシー名、AD があるリージョン、ドメイン名、DNS サーバーの IP アドレス、NetApp Volumes が所属する OU、作成される NetApp Volumes コンピュータの NetBIOS 名を各種項目を環境に合わせて入力します。

また、指定した OU にオブジェクトを作成することができるユーザーの認証情報を入力して作成します。
作成後、Active Directory ポリシーをストレージプールに適用しておきます。

続いて、SMB のボリュームを作成します。
NFS のボリュームと同じように作成していきます。

プロトコルは SMB を選択します。
その他のオプションは今回設定せず作成します。

ボリュームをマウントします。
ボリュームの Show more からマウント手順が確認できます。

VPC ネットワーク内の Windows Server 2022 の Compute Engine インスタンスから接続してみます。

SMB の接続に成功しました！

バックアップを試す

スケジュールで自動的にバックアップを行う方法と、手動で行う方法があります。
それぞれ試してみたいと思います。

はじめに、バックアップを作成するには Backup Vault という保存場所を用意する必要があるため作成します。
ボリュームを asia-northeast1 リージョンに作成していたので Backup Vault も同じリージョンに作成します。

Backup Vault 名とリージョンを指定して作成します。

スケジュールされたバックアップ

バックアップ場所とバックアップスケジュールをバックアップポリシーを作成して定義します。

バックアップを保存する Backup Vault のリージョンとバックアップスケジュールを指定して作成します。
今回は、毎日バックアップを行い、2 つバージョンを保持するように指定しました。

続いて既存のボリュームにバックアップポリシーを適用します。

SMB 接続に利用したボリュームに設定していきます。
ASSIGN BACKUP POLICY を選択します。

バックアップポリシーと Backup Vault を選択し、ASSIGN します。

しばらくすると Backup Vault に test-smb ボリュームのバックアップが作成されました。

バックアップの詳細はこんな感じなっています。

手動バックアップ

次に手動でバックアップを作成してみます。

バックアップを作成するボリュームのページで CREATE BACKUP をクリックします。

バックアップソースとして現在のボリュームの状態と、既存のスナップショットを選ぶことができます。
今回は、現在のボリュームの状態からバックアップを作成します。

手動バックアップが作成されました。

バックアップから復元する

取得したバックアップを利用して新しくボリュームを作成し、データを復元してみます。

手動で取得したバックアップの Create new volume from backup をクリックします。

ボリューム名、ボリュームを作成するストレージプールなどを入力し、作成します。
容量やプロトコルはバックアップ元と同じものから変更することはできません。

バックアップから復元したボリュームに接続して確認します。

復元したボリュームが共有されていることが確認できした。

またバックアップ元のボリュームに保存していたファイルも復元されていました。

スナップショットを試す

次にスナップショットを試してみます。

NetApp Volumes には 3 種類のスナップショットがあります。

Manual snapshots
- ユーザーが手動で作成するスナップショット
- 任意の名前
Scheduled snapshots
- スケジュールで自動的に作成するスナップショット
- <schedule>-<timestamp> という命名規則で作成される
Internal snapshots
- レプリケーションやバックアップを補助するためのスナップショット。内部のスナップショットのため手動では削除できない。
- replication-<timestamp> や snapmirror.<uuid>.<timestamp>. という命名規則で作成される

スケジュールされたスナップショット

既存のボリュームの Snapshot configuration を編集し、スナップショットをスケジュールします。

今回は毎時 0 分にスナップショットを作成し、48 バージョンを保持するように指定し保存しました。

指定した時間にスナップショットが自動で作成されました。

手動スナップショット

次は手動でスナップショットを作成してみます。
CREATE SNAPSHOT をクリックします。

任意の名前を付けて作成します。

スナップショットが作成されました。

クライアントを利用してスナップショットから復元する

クライアントを利用し、スナップショットからデータを復元してみます。

スナップショットは ~snapshot というスナップショット用のディレクトリ作成されます。
そのためクライアントから特定時点のデータを閲覧し復元することができます。

今回は、Windows Server からスナップショットにアクセスします。
エクスプローラーで隠しファイルのチェックボックスを有効化すると、~snapshot ディレクトリが確認できます。

任意の時点のスナップショットフォルダにアクセスします。

スナップショット時点のファイルの中身を閲覧したり、必要に応じてコピーするなどして復元可能です。

ボリュームをスナップショット時点に復元する

スナップショットからボリューム作成して復元する方法と、スナップショット時点にボリュームを復元する方法がありますが、
今回は後者を試してみたいと思います。

4 月 17 日の 23:00 に自動取得されたスナップショットの時点に復元してみます。
Revert をクリックします。

表示された内容を確認して、REVERT ボタンをクリックします。

復元時点のスナップショットより後のスナップショットとデータが削除されます。
内容に問題がなければ復元します。

ボリュームがスナップショット時点に復元されました。
4 月 17 日の 23:00 以降に作成した、2 つのテキストファイル(0417-2302.txt, 0417-2317.txt)はスナップショット時点より後に作成していたため消えました。

また、復元時点より後に取得されたスナップショット test-snapshot も消えていることが確認できました。

クロスリージョンレプリケーションを試す

ボリュームを別の場所に同期して複製するクロスリージョンレプリケーションの機能を試します。
クロスリージョンレプリケーションを構成することでより高い可用性にすることができます。

レプリケーションを作成する

今回は、asia-southeast1(シンガポール) と australia-southeast1(シドニー) リージョンに作成したストレージプールを利用し、クロスリージョンレプリケーションを構成してみます。

asia-southeast1(シンガポール) のストレージプールに作成したボリュームでレプリケーションを作ります。
Manage replication をクリックします。

SELECT STORAGE POOL をクリックします。

レプリカを作成するストレージプールを選択します。
今回は australia-southeast1(シドニー) に作成したストレージプールを選択します。

ストレージプールを選択したので、NEXT をクリックしてレプリケーションを構成します。

ソースボリュームを確認して、続行をクリックします。

レプリケーション名と、レプリケーションスケジュールを指定します。
レプリケーションスケジュールは、10 分毎、1 時間毎、1 日毎から選択できます。

宛先ボリュームのボリューム名と共有名を指定し、作成をクリックします。
レプリケーションが作成されるまで少し時間がかかるので待ちます。

レプリケーションが作成され、ボリュームのレプリケーションが行われていることが確認できました

レプリケーション元とレプリケーション先を入れ替える

続いてレプリケーション元 (asia-southeast1) とレプリケーション先 (australia-southeast1) のボリュームを入れ替えます。
災害復旧のシナリオで想定される機能だと思います。
レプリケーションされていないデータは消える可能性があるため注意してください。

まずは現在動作しているレプリケーションを停止します。

レプリケーションを停止するか確認されるので、問題なければ STOP をクリックします。

レプリケーション停止後、REVERSE AND RESUME が押せるようになっているのでクリックします。

内容を確認してソースボリュームと宛先ボリュームの役割を切り替えます。

切り替え完了後ソースボリュームが australia-southeast1 、宛先ボリュームが asia-southeast1 に入れ替わっていることが確認できました。

まとめ

今回は Google Cloud NetApp Volumes の機能を一通り試してみました。
エンタープライズ向けのファイルストレージサービスなので設定が複雑なのかと思っていましたが、とても直感的で分かりやすいサービスでした。
NetApp のストレージを触ったことが無い方でも簡単に扱えると思うので、ぜひ使ってみてください。