Google Cloud のつよいファイルストレージ NetApp Volumes を試してみた
はじめに
こんにちは！クラウドエースの SRE 部に所属している小田です。
今回は、Google Cloud と NetApp が開発した Google Cloud NetApp Volumes というファイルストレージのお話です。
ずっと前から気になっていたけど、ネット上に全然情報が無かったので自分で試してみました。
Google Cloud NetApp Volumes とは
Google Cloud NetApp Volumes (以降、GCNV) は、2023 年 8 月 25 日から一般提供開始された Cloud Volumes Service の後継となるフルマネージド ファイルストレージ サービスです。
マーケットプレイスで提供されている NetApp Cloud Volumes ONTAP とは別のサービスです。
NetApp Cloud Volumes ONTAP は ONTAP を Compute Engine 上で動作させるため自由度が高く、オンプレミス環境の NetApp のストレージと同じように利用することができるサービスですが、本記事で扱う GCNV は ONTAP を利用したことが無い方でも簡単に利用できるフルマネージドのファイルストレージ サービスです。
Google Cloud には Filestore というマネージド ファイルストレージ サービスが別途存在しますが、Filestore では対応していない SMB プロトコルに GCNV は対応しています。
そのため、主に Windows が存在する環境でファイルストレージを利用したい場合には選択肢に入ると思います。
アーキテクチャ
GCNV は、サービス プロデューサーによって管理されている VPC ネットワーク内に構築されます。
そのため、Cloud SQL などのサービスと同様にプライベート サービス アクセスを構成して、ユーザー側の VPC ネットワークから接続できるようにする必要があります。
GCNV のネットワーク構成
対応プロトコル
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)
サービス レベル
Flex、Standard、Premium、Extreme の 4 つのサービス レベルが提供されています。
Flex サービス レベルについては 1TiB の小規模から利用することが出来ますが、利用できる機能にいくつか制約があるため注意が必要です。
| Flex | Standard | Premium | Extreme | |
|---|---|---|---|---|
| ストレージプール サイズ | 1TiB ~ 200TiB | 2TiB ~ 200TiB | 2TiB ~ 10PiB | 2TiB ~ 10PiB |
| パフォーマンス | プール容量の TiB あたり最大 16 MiB/s | ボリューム容量の TiB あたり最大 16 MiB/s | ボリューム容量の TiB あたり最大 64 MiB/s | ボリューム容量の TiB あたり最大 128 MiB/s |
| ボリューム サイズ | 1 GiB ~ 100TiB | 100 GiB ~ 100TiB | 100 GiB ~ 100TiB | 100 GiB ~ 100TiB |
| サービス レベルの変更 | ❌変更不可 | ❌変更不可 | ✅Premium ↔ Extreme 間で変更可能 | ✅Premium ↔ Extreme 間で変更可能 |
| SLA | 99.9%(単一地域) | 99.9%(単一地域) | 99.95%(単一地域) | 99.95%(単一地域) |
| ボリュームのレプリケーション | Flex サービス レベルのストレージプール間 | Standard サービス レベルのストレージプール間 | 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 |
NFSv3 NFSv4.1 SMB2.1、3.0、3.1.1 |
| 暗号化 | Google 管理の暗号化キー 顧客管理の暗号化キー (CMEK) |
Google 管理の暗号化キー 顧客管理の暗号化キー (CMEK) |
Google 管理の暗号化キー 顧客管理の暗号化キー (CMEK) |
Google 管理の暗号化キー 顧客管理の暗号化キー (CMEK) |
ユースケース
GCNV は、パフォーマンスが要求される多様なワークロードや SMB プロトコルを必要とするシステムに向いています。
たとえば、以下のような使い方ができると思います。
- Windows や Linux とのファイル共有
- 汎用データベース
- Google Kubernetes Engine の永続ストレージ
- VMware Horizon などの VDI プロファイル
- Google Cloud VMware Engine
- SAP ファイル共有
料金
料金について説明します。
Standard、Premium、Extreme サービス レベルは東京リージョン (asia-northeast1) の料金を記載しています。
Flex サービス レベルについては、東京リージョンでは利用できないため大阪リージョン (asia-northeast2) の料金を記載しています。
ストレージ プールの料金
GCNV は保存されているデータ量に対してではなく、プロビジョニングされているストレージ プールの容量に対して料金が発生します。
Flex サービス レベル、1TiB のストレージ プール容量という最小規模の場合でも $235.52 の費用が発生します。
| サービス レベル | Price per GiB |
|---|---|
| Flex | $0.23 |
| Standard | $0.23 |
| Premium | $0.3383 |
| Extreme | $0.4516 |
ボリューム レプリケーションの料金
ボリューム レプリケーションを利用する場合に発生する料金です。
レプリケーションの頻度によって発生する金額が異なります。
また、VPC ネットワークのデータ転送料金も別途発生します。
| 1 日の頻度で転送 | 1 時間の頻度で転送 | 10 分の頻度で転送 |
|---|---|---|
| $0.11 / 1GiB あたり | $0.12 / 1GiB あたり | $0.14 / 1GiB あたり |
バックアップの料金
バックアップされるデータ量に応じた料金が発生します。
バックアップ ストレージの料金は 1 GiB あたり月額 $0.0518 です。
BlueXP には未対応
従来の Cloud Volumes Service や Cloud Volumes ONTAP では BlueXP を利用して NetApp のオンプレミスやクラウド上のストレージサービスを一元管理することが出来ましたが、
GCNV は執筆時点では対応していないため、Google Cloud コンソールから操作を行う必要があります。
GCNV と同等のサービスである Azure NetApp Files については BlueXP に対応しているので、今後に期待です。
試してみる
実際に GCNV を触って試してみます！
ストレージ プールを作成する
はじめに NetApp API (netapp.googleapis.com) を有効化します。
NetApp Volumes のプロダクトページに移動し、ストレージ プールを作成します。
ストレージ プール名、リージョン、サービス レベルを入力します。
ストレージ プールの容量は後から増やすことができます。
VPC ネットワークを選択します。
GCNV はサービス プロデューサーの VPC ネットワーク作成されるため、VPC ネットワークにプライベート サービス アクセスを作成します。
NFS で接続する
NFS のボリュームを作成します。
各種項目を入力します。
今回は先程作成したストレージ プールに 512GiB のボリュームを作成します。
ボリュームの容量も後から増やすことができます。
プロトコルは NFSv4.1 を選択しました。
必要に応じて Export Rules(NFS を利用する場合のみ)、スナップショットやバックアップの設定を行うことができます。
ボリュームの作成後、事前に VPC ネットワーク内に Ubuntu 22.04 LTS の Compute Engine インスタンスを作成していたので、このインスタンスからボリュームに接続してみます。
ボリュームの Show more から NFS のマウント手順が確認できるため、基本的にはこれに従ってボリュームをマウントします。
初めて GCNV と 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 で接続する
次に SMB での接続を試してみます。
はじめに Active Directory ポリシーを作成し、Active Directory の構成情報をストレージ プールに渡します。
今回は事前に作成していた Windows Server 2022 をインストールした Compute Engine インスタンスの AD DS を利用します。
また、GCNV で使用しているプライベート サービス アクセスの IP 範囲からの通信をファイアウォールで許可し、AD と通信が行える必要があります。
ポリシー名、AD があるリージョン、ドメイン名、DNS サーバーの IP アドレス、GCNV が所属する OU、作成される GCNV コンピュータの NetBIOS 名を各種項目を環境に合わせて入力します。
また、指定した OU にオブジェクトを作成することができるユーザーの認証情報を入力して作成します。
作成後、Active Directory ポリシーをストレージ プールに適用しておきます。
続いて、SMB のボリュームを作成します。
NFS のボリュームと同じように作成していきます。
プロトコルは SMB を選択します。
その他のオプションは今回設定せず作成します。
ボリュームをマウントします。
ボリュームの Show more からマウント手順が確認できます。
VPC ネットワーク内の Windows Server 2022 の Compute Engine インスタンスから接続してみます。
SMB の接続に成功しました！
バックアップを試す
GCNV にはスケジュールで自動的にバックアップを行う方法と、手動で行う方法があります。
それぞれ試してみたいと思います。
はじめに、バックアップを作成するには 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 をクリックします。
ボリューム名、ボリュームを作成するストレージ プールなどを入力し、作成します。
容量やプロトコルはバックアップ元と同じものから変更することはできません。
バックアップから復元したボリュームに接続して確認します。
復元したボリュームが共有されていることが確認できした。
またバックアップ元のボリュームに保存していたファイルも復元されていました。
スナップショットを試す
次にスナップショットを試してみます。
GCNV には 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 に入れ替わっていることが確認できました。
まとめ
今回は GCNV の機能を一通り試してみました。
エンタープライズ向けのファイル ストレージ サービスなので設定が複雑なのかと思っていましたが、とても直感的で分かりやすいサービスでした。
NetApp のストレージを触ったことが無い方でも簡単に扱えると思うので、ぜひ使ってみてください。
Discussion