はじめに
これまでの FlashArray//C（以降、//C）の連載で、//C はオールフラッシュでありながら HDD と同等の GB 単価を実現し、データ削減率を考慮しなくても「No More HDD」が可能であること、また、その理由はピュア・ストレージが長年培ってきたフラッシュに関する技術と、多くの稼働実績から得られたノウハウによるものであることを解説しました。
第 3 回となる今回は、「結局 //C はどう使われているの？」という疑問にお答えすべく、日本国内のユースケースの代表例をご紹介します。
FlashArray//C のユースケース
2019 年に //C をリリースして約 3 年が経ちました。日本国内におけるこれまでの代表的なユースケースには、次のものがあります。
- サーバーの仮想化（VSI）：VMware vSphere 環境のデータストア
- バックアップ・ターゲット：バックアップ・ソフトウェアのバックアップ・ターゲット
- ファイルの格納場所：VDI プロファイル、セキュリティ・ログ など
さっそく各ユースケースにおける「なぜ FlashArray//C なのか ― Why FlashArray//C？」を深堀りしていきましょう。
ユースケース 1：サーバーの仮想化（VSI）
VSI は FlashArray//X（以降、//X）の代表的なユースケースですが、//C でも同様の傾向がみられました。//X も //C も同じ FlashArray ファミリーであるため、これは想定どおりといえます。
興味深いのは、既に //X を使用している既存ユーザーが、同じ用途である VDI（VMware vSphere のデータストア）に //C も導入するケースです。IaaS（Infrastructure as-a-Service：サービスとしてのインフラ）であれば、性能に特化した VM は //X のデータストアから切り出し、GB 単価に特化した VM は //C のデータストアから切り出す、という使い分けです。これにより、IaaS を支えるストレージは FlashArray ファミリーで統一されて可用性が高まり、設計と運用も統一されるため効率性が高まります。さらに、Pure1 がストレージ・システム全体に対するプロアクティブな予測型サポートを提供するため、GB 単価が同等であれば //C を導入しない理由はありません。
ユースケース 2：バックアップ・ターゲット
バックアップ・ターゲットは、//X ではなく //C ならではのユースケースです。例えば、バックアップ・ソフトウェアやデータベース（Oracle Database なら RMAN）から作成されたバックアップ・ファイルは、VSI やデータベース本体ほどの高いデータ削減率が見込めません*。そのため、//X では割高に見えてしまうかもしれませんが、//C であれば問題ありません。これまでご紹介してきたように、//C の最大の魅力は、オールフラッシュでありながらデータ削減率を考慮しなくても「No More HDD」が可能である点にあります。
* ファイル類であっても 2 倍前後のデータ削減率が期待できます。これは他社と比較すれば十分に高い値です。
さらに //C は、ピュア・ストレージが持つランサムウェア対策機能 SafeMode との相性も抜群です。
ストレージ・レイヤーで準拠するべきランサムウェア対策では、「バックアップからのデータやシステムの復旧を迅速かつ確実に行えるように」という注意喚起がされています。
- 確実性：
ランサムウェア感染時でもバックアップが保護されるように留意する必要があります。バックアップ・ソフトウェアやストレージの管理者権限を奪われた場合に、バックアップは全て消去されてしまうため、管理者権限でも削除できないバックアップが必要です。
- 迅速性：
「管理者権限でも削除できないバックアップ」を実現するには、次のような方法があります。-
- ネットワークからの隔離（バックアップ時のみ対象機器と接続するといった方法）
- 物理的に別の場所にデバイスを輸送（テープ・バックアップなどを利用）
-
しかし、これらのバックアップからのリストアには何日かかるでしょうか？物理的な輸送などを含め、迅速なリストアが可能といえるでしょうか？リストアにかかる数日間は、ビジネスに甚大な影響を及ぼします。
ピュア・ストレージの FlashArray および FlashBlade では、ユーザーが指定した期間は管理者権限でもアクセスできない金庫のようなセキュアな領域にバックアップを保管する SafeMode を標準機能として無償で提供しています。SafeMode というセキュアな金庫は、ネットワークから隔離されているわけでも、物理的に別の場所に格納されているわけでもないため、瞬時のリストアが可能です。
図 2 の構成図では、本社データセンターの VMware vSphere 環境（VSI）で稼働する VM のバックアップを Veeam で取得しています。そして、各拠点のバックアップも含めた統合バックアップ・ターゲット（一次バックアップ）として //C を使用しています。最終的には、AWS の Amazon S3 をアーカイブ目的の二次バックアップとして FlashArray のレプリケーション機能でバックアップを転送しています。
仮にランサムウェアに感染した場合には、AWS 上のバックアップからのリストアも可能かもしれませんが、迅速・確実に実行できるでしょうか？
本ケースでは、一次バックアップである //C の SafeMode 機能を使用して、ランサムウェアからバックアップを保護することにしました。ランサムウェア感染時には、//C 内のセキュアな SafeMode 領域から正常なバックアップを瞬時にリストアし、本社データセンターの Veeam および各拠点では、正常なバックアップ・ファイルへのアクセスがすぐに可能になります。
ユースケース 3：ファイルの格納場所
これも //C ならではのユースケースです。公開事例である株式会社スクウェア・エニックス様の事例を見てみましょう。
VDI 環境での開発作業を行う上で VDI にドライブとして見える大容量ストレージの必要性が出てきました。開発に必要となるデータは開発者ごとに 1～2 TB、場合によっては 4 TB 以上にもなります。
株式会社スクウェア・エニックス
もともと //X 上で VDI を稼働させていた環境で、VDI を使用するユーザー（社員様）にさらなる利便性を提供するため、各 VDI に開発データの格納場所としてテラバイト級のドライブを提供し、開発作業を支援することになりました。
下図のとおり、性能が重視される VDI の OS 領域は //X、容量（GB 単価）が重視される開発データは各 VDI に //C からドライブを提供することで、用途にあわせて FlashArray ファミリーをうまく使い分けていただいています。
おわりに
FlashArray はブロック・ストレージの印象が強いですが、2020 年にリリースされた Purity//FA 6.0 から FA File 機能で NFS および SMB のファイル・プロトコルもサポートし、統合ストレージになりました。
//C はこれまでにご紹介した特長上、ファイル・プロトコルとも相性がよく、特に、前述のバックアップ・ターゲットや VDI プロファイルは検証済みで実績のあるユースケースです。ピュア・ストレージの担当営業と SE に是非ご相談ください。
//C は、オールフラッシュでありながら SAS HDD と同等の GB 単価を実現しているため、今回ご紹介したユースケースに限らず、極めて幅広い使い方が可能です。さらに、//C の GB 単価は、ベンダーとして無理をした価格付けや値引きではなく、技術力で実現している点が最高に熱いところです。
//C が皆様の環境の「No More HDD」に貢献できることを祈って、当連載を終わります。
Pure Storage、Pure Storage のロゴ、およびその他全ての Pure Storage のマーク、製品名、サービス名は、米国およびその他の国における Pure Storage, Inc. の商標または登録商標です。その他記載の会社名、製品名は、各社の商標または登録商標です。
