みなさま、はじめまして。株式会社ネットワールドの福住です。普段はNetAppストレージの専任営業として活動していますが、ときどきストレージ探偵ず～みんとしてストレージとクラウドの謎を追っています。フランスの小説家ジョルジュ・ペレックとクラウドが大好きです。
これまでネットワールドではこのストレージチャンネルの場をお借りして、NetApp AFFシリーズのPerformance検証結果をご案内してきました。今回からは少し方向性を変え、NetApp注目の新機能FabricPoolのさまざまな謎に迫ってみたいと思います。
FabricPoolとは？
FabricPoolとはどんな機能なのでしょうか？簡単に言うと、NetAppのAll Flash FASと（クラウドの）オブジェクトストレージ間でデータをティアリングする機能です。昨今、Flash Storageの容量単価下落は著しく、重複排除率を考慮すればSSDの容量単価はSAS-HDDよりも安価になっています。それでも、NL-SAS等の大容量HDDの容量単価とSSDの単価を比較してまだまだSSDは高い、というイメージを持っている方も多いかと思います。
実際、ハイパフォーマンスを求めて数百TBに及ぶ大規模なストレージをAll Flashで用意しようとすると、かなりのコストが必要です。一方、ストレージに保存されているデータのうちActiveなものは限られています。特にファイルサーバーでは、保存されているデータのほとんどが更新も参照されない、なんてこともあります。
そんな状況に最適なソリューションがFabricPoolという機能です。FabricPoolにより自動階層化をAFF（もしくはFASのSSD Aggregate）に導入することができます。頻繁に参照されるデータ（Hotデータ）はオンプレミスのSSD領域に保存し、あまりアクセスされないデータ（Coldデータ）はオブジェクトストレージに保存します。高価なSSD領域を削減でき、SSDのハイパフォーマンスとオブジェクトストレージのコストメリットをバランス良く利用できることがFabricPoolの魅力です。
詳しくは、こちら「クラウドObjectストレージとの連携機能「FabricPool」の謎を解け！第2回：FabricPoolのパフォーマンスと「読者への挑戦状」」記事でご参考にしてください。
NetAppは自動階層化の導入に否定的だった？
この魅力的な自動階層化機能ですが、実はNetAppはこれまで頑なにこの機能を実装してきませんでした。競合他社のストレージが、SSD/SAS/SATA間で階層化機能を導入する一方、NetAppのFASシリーズではVST（Virtual Storage Tier）と呼ばれるSSDをキャッシュとして利用する技術しか導入してきませんでした。
VST（具体的な機能名としてはFlashCacheやFlashPool）では、SSDに保存されるのはよくアクセスされるデータのキャッシュです。実データ自体は常にHDDに保存されています。なぜNetAppはFASシリーズに階層化機能を実装してこなかったのでしょうか。一般的なストレージ階層化機能では、SSD⇔HDD間のデータ移動は一日一回程度です。仮に、低速なHDDに保存されたデータへのアクセスが急激に増加したとしても、データがSSDへ移動するのは翌日になります。それであれば、リアルタイムにキャッシュをコントロールできるVSTの方が優れている、というのがNetApp社の考え方だったと思います。
これまでそのように考えてきたNetAppが初めて実装したストレージの自動階層化機能がFabricPoolです。それでは、FabricPoolは急激なデータアクセスパターンの変更にもリアルタイムに対応できるのでしょうか？そんなところにも注目してみたいと思います。
FabricPoolのもう一つのユースケース
本稿執筆時点での最新OSバージョンであるONTAP9.6では、4つのポリシーからFabricPoolの動作を指定できます。「auto」はこれまで説明してきた一般的な自動階層化ポリシーです。あまりアクセスのないデータを一定のルールに従いコールドデータと判定して、オブジェクトストレージに保存します。「Snapshot-only」はSnapshot領域にのみ存在するデータを階層化します。多数のSnapshotを保有しているケースに役立ちます。本番領域に対するパフォーマンスインパクトがほとんどなく、導入しやすい点も魅力です。「none」はFabricPoolを利用しません。そして「all」はVolume内のほぼすべてのデータを即座に階層化します。このポリシー「all」をもっとも活用できるのユースケースは、Cloud Volumes ONTAPをオンプレミスAFF/FASシリーズのDR機とする構成と言えるでしょう。AFF/FASシリーズだけではなく、Cloud Volumes ONTAPでもFabricPoolは使えるのです。
たとえば、オンプレミスのFAS/AFFに30TBのデータを保管していたとします。そのデータをSnapMirrorでAWS上のCloud Volumes ONTAPへ転送した場合、30TB分の比較的高価なEBSをアタッチする必要があります。一方、Cloud Volumes ONTAPでFabricPoolのポリシー「all」を利用した場合、30TBのデータのほとんどをより安価なS3に保管することができます。Cloud Volumes ONTAPではFabricPoolは無償で利用できるため、そのコストメリットは非常に大きくなります。Cloud Volumes ONTAPでFabricPoolを使わない手はないですね。
FabricPoolの作り方
それでは、ここからFabricPoolの設定方法を見ていきましょう。AWS S3とAFFを接続するケースを想定して解説します。まずはAWSのマネジメントコンソールでS3画面にアクセスします。
S3に任意のバケットを作成します。
ここでは「kensho-lan-fabricpool-test」というバケットを作成しました。
ここからはAFF側の設定作業となります。あらかじめFabricPoolライセンスがインストール済みであること、InterClusterLIFが10Gbpsポート上に設定されていることが前提となります。System Managerの【ストレージ】＞【アグリゲートとディスク】＞【クラウド階層】を選択して、【＋追加】からオブジェクトストアプロバイダとしてAmazon S3を指定します。タイプ/名前/サーバ名（FQDN）は入力済みとなっているため、「アクセスキーID」と「シークレットアクセスキー」、「コンテナ名」だけ入力すれば設定完了です。これでAggregateとオブジェクトストアが接続されます。一度接続すると、解除する方法はAggregateを壊すことしかありませんので、慎重に。
続いてVolumeの設定です。データ容量がほぼ満杯になったVolumeをあらかじめ作成しておきます。System ManagerのVolume一覧画面で該当Volumeを右クリックし、「階層化ポリシーの変更」を選択します。適用したいポリシーを指定して、保存するだけです。ここではポリシー「auto」を選びました。以上でFabricPoolの設定は終わりです。とっても簡単ですね。
FabricPoolの動作を確認
FabricPoolポリシー「auto」の設定が終わったら、あとはなにもせずに自動階層化機能が働くのを待ちましょう。デフォルトでは31日間参照されなかったブロックがコールドデータとして判定され、一日一回オブジェクトストアにアップロードされます。コールドデータとされるまでの期間は2～63日間で調整可能です。
気になるクラウドへのアップロードパフォーマンスを見てみましょう。上図はsysstat -d 1の結果ですが、ピンクで囲った部分がS3へのアップロードパフォーマンスとなります。平均して35MB/s程度の結果となりました。残念ながら我社ではDirectConnectなんて高級なものはありませんので標準的なInternet回線でのパフォーマンスとなります。
AWSマネジメントコンソールでFabricPool用に作成したS3バケットの中身を除いてみましょう。ポリシー「auto」を適用したVolumeには.pptx/.pdf/.xlsといったファイルが保存されていました。ところが、S3バケットに保存されているのはそれらのファイルではなく正体不明の４MBファイルです。FabricPoolではブロック単位でアクセス頻度を管理しています。Coldデータと判定されたブロックが4MBのチャンクとしてS3にアップロードされたのです。
再びSystem Managerに戻ります。FabricPool適用によりAFFの利用率はどう変わったのか見てみましょう。まずはAggregateです。
FabricPool適用前のAggregateは1.1TBのサイズに1.04TBのデータが保存されていました。階層化が実施されると、このAggregateの使用済みスペースはわずか27.73GBでした。1TB強のデータがクラウド階層へ移行されました。SSDを利用していた実データの97%が節約できたことになります。
次はVolumeを見てみましょう。System Managerを確認すれば該当Volumeがどの程度クラウド階層を利用しているかわかります。一方、エクスプローラーからVolumeが提供しているCIFS共有を確認してみると、
FabricPool動作後もVolumeはほぼ満杯です。利用率は変わっていません。フォルダを開いてみると、そこにはいつもと変わらずファイルが保存されています。データの大部分がクラウド階層に移動しているにもかかわらず、各ファイルにショートカットリンクが表示されることはありません。つまりユーザーは、データがどの階層にあるか意識することなく通常のファイルサーバーとして利用できます。
Aggregateにわずかに残されたデータにはファイルシステムのメタデータが保存されています。ユーザーがAFF上のVolumeにアクセスすると、通常のファイルサーバーが見える。ファイルを開こうとするとS3に保存されたチャンクからデータをダウンロードしてファイルがオープンする、という仕組みになっています。こうなると気になるのはS3からデータをダウンロードする場合、どの程度のパフォーマンスになるのか？あるいは、FabricPoolを利用しない場合と比べどの程度パフォーマンスが劣化するのか？になりますよね。それは次回のお楽しみ。
アクセスキーID/シークレットアクセスキーの謎
最後に、ストレージ探偵らしく謎解きをしてみましょう。
FabricPool設定時にAWSのアクセスキーID/シークレットアクセスキーの入力が必要なことは前述したとおりです。設定自体はとても簡単なのでさらっと流してしまいましたが、よく考えてみましょう。このアクセスキーID/シークレットアクセスキーの発行にはどのようなアクセス許可（IAMポリシー）をもったIAMユーザーが必要なのでしょうか？NetApp社のマニュアルやベストプラクティスガイドを調べてみましたが、FabricPoolに必要なAWSのアクセス許可（IAMポリシー）についての詳細はどこにも記載されていないようです。めんどくさがってAdministrator Accessを使っていませんか？AWSでは目的に応じた最小権限を付与することが推奨されていますので、Administrator Accessなんてもってのほかです！FabricPoolはS3へアクセスできれば良いだけと推測できますので、「AmazonS3FullAccess」などのIAMポリシーを利用すればよさそうです。でもほんとうにそれでいいのか気になりますよね。S3にアクセスするだけのIAMポリシーの設計なんて自明なのでマニュアルに書いていないのでしょうか。なんとなくはわかるけど、メーカーの指針がないとやっぱり不安ですよね。ストレージ探偵としてはなんとしてもFabricPool用IAMポリシーのベストプラクティスを見つけたいところ。
ドキュメントを調べてもわからなければ発想を転換してみましょう。クラウドでわからないことがあればクラウドを調べればいいのです。先に説明したとおりCloud Volumes ONTAP(CVO)でもFabricPoolは利用できます。ではCVOはどのような権限（IAMロール）でS3にアクセスしているのでしょうか。ここにヒントがありそうです。実際に確認してみましょう。EC2インスタンスにアクセスキーID/シークレットアクセスキーを埋め込むことはご法度のため、CVOではFabricPool利用にキー入力は不要です。代わりに「fabric-pool-resources-xxxxxxxxx」というIAMロールがデプロイ時に自動でアタッチされます。このIAMロールには「ontapcloud-instance-policy」というIAMポリシーがアタッチされていました。このポリシーはNetApp社が作成したものですから、信頼しても問題ないでしょう。どんなポリシーなのか確認してみましょう。
{
"Version": "2012-10-17",
"Statement": [
{
"Action": "s3:ListAllMyBuckets",
"Resource": "arn:aws:s3:::*",
"Effect": "Allow"
},
{
"Action": [
"s3:ListBucket",
"s3:GetBucketLocation"
],
"Resource": "arn:aws:s3:::バケットのARN",
"Effect": "Allow"
},
{
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": "arn:aws:s3:::バケットのARN/*",
"Effect": "Allow"
}
]
}
中身はいたってシンプルですね。S3バケットのリストを取得して当該バケットに対してのみGet/Put/Deleteの権限を与えています。このIAMポリシーであれば、それなりにセキュアな作りになっていますので、そっくりそのままオンプレのAFFでも使えそうですね。こちらを参考にIAMポリシーを設計してみてはいかがでしょうか。あとはこのポリシーをアタッチしたIAMユーザーを作成して、アクセスキーID/シークレットアクセスキーをダウンロードするだけなので、簡単ですね。
以上、FabricPool概要と設定方法をご案内しました。次回はFabricPoolのパフォーマンス検証です。お楽しみに。
株式会社ネットワールド
お問合せ窓口：netapp-info@networld.co.jp
執筆者：
株式会社ネットワールド 
ストラテジック・プロダクツ営業部
福住 遊
NetAppの営業10年目。エンジニア経験は一切ない純粋な営業だが、CVOとクラウドが大好き。さわっているうちに詳しくなったので、最近はパートナー向けCVOトレーニングの開発/講師を担当。クラウドサービスの新機能検証なども勝手にやっている。
NetApp Hybrid Cloud Architect & Administrator, AWS Solution Architect Associate, Perecien
福住が講師の資格取得プログラムやコミュニティイベント実施中！
NetAppくらうどコミュニティ「くらこみゅ」～クラウドSEに、俺はなる！～
https://www.networld.co.jp/product/netapp/kurakomyu/
最新情報お届け！Twitter / Facebook のフォローもお願いします！
- ネットワールドFacebook （@Networld.TeamNetApp）
- Networld Twitterアカウント（@nw_netapp）
