クラウドObjectストレージとの連携機能「FabricPool」の謎を解け！
第5回：FabricPool Mirrorで実現するマルチクラウド構成

2021.01.26 2022.02.17 ストレージチャンネル編集部

みなさま、こんにちは。ペレキアン福住です。前回はFabricPool+FlexGroup構成で実現する「なんちゃってマルチクラウド」構成についてお話しました。今回はONTAP9.7で実装された新機能FabricPool Mirrorを利用し、「なんちゃって」ではない「ちゃんとしたマルチクラウド」構成を試します。

FabricPool Mirrorってなんだ？

FabricPool Mirrorを語る前に、FabricPool利用時のAggregateとオブジェクトストレージの関係について説明しましょう。

FabricPool Mirrorってなんだ？-1

ONTAP9.6以前では、Aggregateとオブジェクトストレージのバケットは1：1、もしくはn:1で接続することしかできませんでした。n:1とは複数のAggregateをひとつのバケットに接続することができる、ということです。その逆である1:ｎ、つまりひとつのAggregateを複数バケットには接続できません。ところが、ONTAP9.7からFabricPool Mirrorがサポートされたことで、この1:nの接続も可能になったのです。しかも、ひとつのAggregateを異なるクラウドオブジェクトストレージのバケットに接続することもできます。

FabricPool Mirrorってなんだ？-2

FabricPool Mirror構成でひとつのAggregateを複数のバケットに接続すると、

ColdデータをAWS S3とAzure Blobへ同時に書き込む
AWSを利用していたが、Azureに切りかえることになったのでS3からBlobへColdデータを移動する

といったことが可能になります。なんだかよくわかりませんが、便利そうですね。

FabricPool Mirrorを試してみる

なんだかよくわからないものは試してみるのが一番です。さっそくやってみましょう。

FabricPool Mirrorを試してみる

まずは上図の環境を用意しました。ONTAP9.7の環境で、aggr1_n1はIBM Cloud Object Storage（ICOS）に、aggr1_n2はAWS S3に接続しています。AzureのBlobはクラウド階層としてONTAPに登録していますが、まだAggregateとは接続していません。

::> storage aggregate object-store show
Aggregate　　  Object Store Name  Availability　Mirror Type
-------------- ----------------- ------------- ------------ ------------- -----------
aggr1_n1　　　  ibm_cos_876　　　　available　　 primary
aggr1_n2　　　  aws_s3_348　　　　 available　　 primary

storage aggregate object-store showコマンドを打つと、ICOSとS3のMirror Type が両方とも“primary”であると確認できます。

FabricPool Mirrorを試してみる-1

それでは実際にFabricPool Mirrorを設定してみます。GUIの場合「FabricPoolミラーの接続」を選択します。CLIでは下記コマンドを利用します。

::> storage aggregate object-store mirror -aggregate <aggregate名> -object-store-name <object store名>
FabricPool Mirrorを設定すると、S3からBlobへデータが転送（初期同期）されます。もちろんAWSからAzureへ魔法のようにデータが転送されるわけではなく、オンプレのAFFを経由してS3にあるデータがAzureのBlobにコピーされます。

FabricPool Mirrorを試してみる-2

FabricPool Mirror初期同期時のsysstatからもデータの動きを追ってみましょう。上記ログから、

Net in/out, Cloud read/writeの値から、データはAFFを経由してコピーされる
SSDにはデータを読み書きしていない
つまりFabricPool Mirror初期同期時、データはAFFを素通りする
ということが読み取れます。

FabricPool Mirrorを試してみる-5
初期同期をイメージ図にすると上図のようになります。初期同期が完了するとAWS S3,Azure Blobの各バケット内には同数のチャンクデータ（1つ4MB）が保存されているはずです。

初期同期完了後に再度storage aggregate object-store showコマンドを打ってみましょう。

::> storage aggregate object-store show
Aggregate　　　 Object Store Name Availability　Mirror Type
-------------- ----------------- ------------- ----------- ------------- -----------
aggr1_n1　　　　ibm_cos_876       available　　　　primary
aggr1_n2　　　　aws_s3_348        available　　　　primary
aggr1_n2　　　　azure_cloud_407   available　　　  mirror

AzureがMirror Type ‘mirror’として登録されています。

FabricPool Mirrorを試してみる-6

この状態で、新たに100MBのファイルをポリシーallのVolumeに追加してみます。そうするとAWS S3,Azure Blobの双方へほぼ同時にデータをアップロードします。実際、バケットに保存されているチャンク数を確認したところ、それぞれ「71」^※と一致していました。一方、ダウンロードはprimaryのオブジェクトストレージのみを利用します。

FabricPool Mirrorを切りかえてみる

現在はAWS S3がprimaryで、Azure Blobがmirrorです。それでは、このprimary/mirrorの関係を切りかえてみましょう。

::> storage aggregate object-store modify -aggregate <aggregate名> -object-store-name <objectstore名> -mirror-type mirror

このObjectstore名にS3を入力すればS3がmirrorに切りかわります。

::> storage aggregate object-store show
Aggregate　　  Object Store Name　Availability　Mirror Type
-------------- ----------------- ------------- ----------- ------------- -----------
aggr1_n2　　　  aws_s3_348        available     mirror
aggr1_n2　　　  azure_cloud_407   available     primary

無停止ですんなりprimary/mirrorが切りかわりましたね。いったん、再度S3側をprimaryに戻してから次の検証をしてみましょう。

FabricPool Mirrorを切りかえてみる

ポリシーallのVolumeから10GBのファイルをReadしている最中に、S3とAFFの通信だけを無効化してみます。このとき、ダウンロード元をAzureに自動で切りかえてくれるのでしょうか。ちなみにS3との通信のみを遮断するため、データダウンロード中にアクセスキー／シークレットアクセスキーを一時「無効化」しました。これでAFFはS3からデータをGetする権限がなくなります。連載第一回に記載したポリシーがそっくり無効になりますので、もうデータをダウンロードすることはできません。

結果は残念ながらそのままファイルオープンがエラーとなってしまいました。自動でAzure側に切りかえてデータダウンロードを継続してくれる仕様にはなっていないようです。

FabricPool Mirrorを切りかえてみる-1

気を取り直して、もう一度試してみましょう。今度はポリシーallのVolumeから10GBのファイルを取り出している間に、コマンドでAzure BlobをFabricPoolのmirrorからprimaryへ切りかえてみます。さらに、切りかえ直後にAWSのアクセスキー／シークレットアクセスキーを一時無効化してS3からデータダウンロードできないようにします。はたして、無事にファイルオープンできるのでしょうか？

こちらは見事にファイルオープンが成功しました。データダウンロード元をAWS S3からAzure Blobに変更してくれたようです。切りかえ直後にAWSのキーを無効化していますので、絶対にS3からはデータダウンロードできないはずです。そうすると、残りデータはAzureからダウンロードしているはずです。このことはAPIレベルでも確認できますが、詳細は次回に譲ります。

FabricPool Mirrorをやめてみた

最後にFabricPool Mirrorをやめてみましょう。

::> storage aggregate object-store unmirror -aggregate <アグリゲート名>

でミラー解除できます。ミラー解除するとすぐにmirror側のバケット（ここではAWS S3）とローカル階層の接続が解除され、バケットの中身も自動ですべて削除されます。ただし、AWSの登録自体はONTAPに残ります。この登録はAggregateを削除するまで残ります。

FabricPool Mirrorの使いどころ

さて、これで一通りFabricPool Mirrorの動作を確認できました。ここまでの検証をもとにFabricPool Mirrorの特徴と使いどころを改めて考えてみましょう。まず、FabricPool Mirrorの特徴はなんと言ってもCloudプロバイダーの変更が簡単にできる、ということです。AWSからAzure、AzureからAWSへの移行が容易に実現できます。なんらかの事情でプロバイダーを変更せざるを得ない、というケースはありうるでしょう。そんなときにFabricPool Mirrorは大活躍してくれます。ただし、データ移行時にはクラウドからオンプレへのデータダウンロードと、異なるオブジェクトストレージへアップロードが発生します。当然この動作には時間とコストが伴います。特に大量のデータをダウンロードする際のコストには注意が必要です。

FabricPool Mirrorのもうひとつの特徴はさらなる冗長性を確保できる、という点です
FabricPool MirrorではAWSとAzure双方へ同時に同じコールドデータを保存できます。万一片方のクラウドで大規模障害があったとしてもミラー側のデータにアクセスでるので、データ保護と可用性を担保できます。クラウドプロバイダーでの大規模障害が大きな問題となっている昨今、利用企業が取りうる対策としては異なるクラウドを複数利用するマルチクラウド構成しかありません。FabricPool Mirrorであれば簡単にこのマルチクラウド構成を実現できます。注意点としては、これまで見てきたとおりプライマリのクラウド側で障害が発生したとしても自動でミラー側に接続変更してくれない、ということです。ONTAP9.7ではオブジェクトストレージの切りかえには手動オペレーションが必要です。もうひとつ重要な注意点としては、果たして大量のデータを複数のクラウドでもつ意味はどれほどあるのか？ということです。一般的にクラウドオブジェクトストレージではひとつのデータを3重コピーしている、と言われています。データ耐久性はイレブンナイン（99.999999999％）とも。そうであれば、データの可用性はともかく、耐久性についてはまったく問題ないでしょう。そのうえで大量のデータを異なるクラウド間で常時二重に保持する意味はどこまであるのでしょうか。もちろんコストも倍になります。

最後にFabricPool Mirrorがもっとも活かせるユースケースについて考えてみましょう。

FabricPool Mirrorの使いどころ

それは、上図のようなオンプレ⇔クラウドのオブジェクトストレージ間のデータ移行ではないでしょうか。例えば、AWS S3とオンプレのAFFをFabricPoolで接続していたとします。ところが、思いの外オブジェクトストレージからのデータ読み出し量が多く、ダウンロードコストとパフォーマンスが問題になってしまった。そういったケースであれば、オンプレミスのオブジェクトストレージへ移行する選択肢も考えられます。FabricPoolでは、AWSやAzureなどのクラウドオブジェクトストレージだけではなく、StorageGRIDなどのオンプレミスに配置するオブジェクトストレージもサポートしています。最近ではCloudianなどのサードパーティ製オブジェクトストレージも使えます。オンプレのオブジェクトストレージであれば、ネットワーク遅延はそれほど心配する必要はありません。さらにStorageGRIDなら、FabricPoolの容量ライセンスが不要になるというおまけ付きです。FabricPool Mirrorであれば、オンプレ-クラウドのオブジェクトストレージ移行も簡単に実現できます。単純にコストとパフォーマンスだけを考えれば、AWSからAzureに切りかえるケースよりも、オンプレ-クラウド間の切りかえの方が効果あるのではないでしょうか。

FabricPool Mirrorを使えばマルチクラウドもハイブリッドクラウドも自由自在に実現でそうですね。みなさまの素敵なクラウドライフにNetAppの技術をぜひ活用してみてください。

いよいよ次回はFabricPool連載記事の最終回？「FabricPoolよ、お前は結局何をやっているのだい？」の予定です。お楽しみに。

株式会社ネットワールド

お問合せ窓口：netapp-info@networld.co.jp

～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～

株式会社ネットワールド　

セールスコンサルティング部

福住遊

fukusumi-sama

ペレキアン。SE、エンジニア経験0の100％純粋なセールス（マーケティング部所属だけど）。

『ハムレット』で言う十一時と十二時の間とはなにか？『Wあるいは子供の頃の思い出』11章と12章の間にはあるものといえば、あの中断付（…）だ。亡霊（revenant）とはなにか？ペレック風にいえばLes Revenentesだろうか。『戻ってきてた女たち』、それは『煙滅』で消えたはずのEが、彼女たち（eux）が、亡霊として戻ってくるのだろうか。

fabricpool-networld-05-13

福住が講師の資格取得プログラムやコミュニティイベント実施中！

NetAppくらうどコミュニティ「くらこみゅ」～クラウドSEに、俺はなる！～

https://www.networld.co.jp/product/netapp/kurakomyu/

最新情報お届け！Twitter / Facebook のフォローもお願いします！

ネットワールドFacebook （@Networld.TeamNetApp）

Networld Twitterアカウント（@nw_netapp）

※100MBのファイルを4MB毎に分割すると25個のチャンクとなります。47+25=72となるはずですが、これまでの連載で述べたとおりポリシーallでもすべてのデータがオブジェクトストレージにアップロードされるわけではありません。メタデータはAFFのAggregateに残りますので、アップロードされたのは71個のチャンクとなります。