ストレージとFVPのWBデータストアポリシーとフォルトドメインとPowerCliコマンド(あえてソフトウェア定義とは言わない)

本ブログエントリーはPernixData社のテクノロジーエバンジェリストであるFrank Denneman氏のブログの翻訳版です。 Frank氏について、詳しくはこちらもご参照ください。

本記事の原文はStorage & FVP WB datastore policies, fault domains and PowerCli commands (but I wouldn't dare to call it software defined)で閲覧可能です。

ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら。

先週、ストレッチクラスタとFVPを利用しているお客様と会話する機会がありました。ストレッチクラスタはレプリケーションされたディスクとレプリケーションされていないディスクの両方に接続されています。ビジネスクリティカルアプリケーションは最高レベルの耐障害性を必要としますし、ローカルサイトののホストや全サイトが完全に障害に陥ったとしてもvSphere HAで仮想マシンが復帰することを確実にしたいと考えています。耐障害性サービス全体がディスクのレプリケーションの状況に依存してしまうので、ストレージプロファイルとFVPのWrite-Backポリシーをデータストアレベルで組み合わせて構成することを推奨します。FVPのフォルトドメイン機能はホスト上のWriteデータが安全に冗長化され、クラスタ内のホスト障害やサイト障害から復帰できることを保証します。我々の新しいプロダクトマネージメントであるTodd Mace氏とディスカッションしました。彼は素晴らしい記事になると受け合ってくれました。

vSphere プロファイルドリブンストレージ

vSphere 5.0で登場したプロファイルドリブンストレージは迅速でインテリジェントな仮想マシンの配置を事前に定義されたストレージプロファイルをベースに実現します。vSphere 5.5では以前のヴァージョンのストレージプロファイルに改善を加え、VMストレージポリシーと名称も変更しています。FVPデータストア高速化とストレージプロファイルを一緒に使うことで、仮想マシンのプロビジョニングの最中にデータストアの正しいWriteポリシーを理想的に設定することができるようになります。

ストレージプロファイルアーキテクチャ

ストレージポリシーを用いると、全てがストレージポリシーのルールセットとして表されます。ルールセットはデータストアのストレージの特性を記述したルールの集まりです。これらの特性はベンダー固有の機能(VASAプロバイダー経由)であったり、ユーザー定義のタグとして提供されます。1つのルールセットは複数のルールとベンダー固有の機能のルールとタグベースのルールとの組み合わせを包含することができます。概略図でオブジェクト間の関連を見て行きましょう:

タグカーディナリティ

タグはカテゴリへアサインする必要があります。カテゴリはタグのカーディナリティとどのvSphereオブジェクトにタグが関連付けされるかを定義します。カーディナリティはオブジェクトがカテゴリ内の1つもしくは複数のタグを付けられるかということを定義します。今回のシナリオではタグをデータストアのレプリケーションサービスのレベルの定義に利用します。レプリケーションのステータスは完全に排他的です。同じデータストアに同時には適応することができません。これを考えるとカーディナリティは｢オブジェクト1つあたり1つ｣をアサインすることで、レプリケーションサービスの排他性を完全に表すことができます。

ストレージプロファイルとFVP

FVPのWriteポリシー、FVPの障害ドメイン、そしてvSphereのWriteポリシーを組み合わせることで、仮想マシンに正しい耐障害性ポリシーと災害対策機能を提供することができます。今回のシナリオではストレッチクラスターはレプリケーションされているデータストアとレプリケーションされていないデータストアの両方に接続されています。ストレージポリシーでタグをアサインすることで、簡単にこれらのデータストアが｢replicated datastore｣なのか、｢Non-replicated datastore｣なのかを見分けることができます。

FVPのフォルトドメインでフォルトドメイン間のレプリケーションを簡単に構成することができるようになります。データストアレベルでただしいFVPのWriteポリシーをアサインすることで、FVPのレプリケーションと高速化が現在、そしてこれから作成される(展開、もしくはStorage vMotion)すべての仮想マシンに自動的に構成されるようになります。

レプリケーションされているデータストア上の仮想マシンは大抵はビジネスクリティカルアプリケーションです。ですから、アプリケーションを高速化し、さらにWriteデータをストレッチクラスタ内の別のデータセンタのホスト上にレプリケーションで冗長化することは理にかなっています。レプリケーションしていないデータストア上の仮想マシンはフォルトドメインをまたぐレプリケーションからはメリットを受けることはできません、ですから、FVPのフォルトドメイン内でレプリケーションされるようにWriteポリシーを設定すべきです。もしも、冗長化されたWriteデータが唯一別サイトへのレプリケーションであったとすれば、FVPは正しいデータストアに対して溜まっているWriteを送信することができず、HAの動作は失敗してしまいます。データストアレベルでWriteポリシーを適応している場合、すべての新しく展開される仮想マシンは自動的にホストレベルの耐障害性を構成し、フェイルオーバーを保証しながら、データセンター内のコストの高いレプリケーションを避ける事ができます。

シナリオ

例を用いて、構成の詳細を見て行きましょう。このシナリオではvSphereクラスタは4台のホストで構成されています。ホスト1と2はサイトAに配置され、3と4はサイトBに配置されています。それぞれのホストはレプリケーションされていないデータストアとレプリケーションされているデータストアに接続されています。図が忙しくならないように、今回はレプリケーションされているものと、レプリケーションされていないデータストアとそれぞれ1つづつ記載します。FVPのフォルトドメインはホスト1と2を｢Site A｣グループ、3と4を｢Site B｣として構成しています。VM1はレプリケーションされていないデータストアに格納されており、VM2はレプリケーションされているデータストアに格納されています。ストレージレプリケーションによって両サイトにデータが安全に格納されます。

vSphere UIは展開プロセス中にはVMストレージプロファイル名のみを表示しますので、｢Replicated｣と｢Non-Replicated｣というタグをそれぞれにつけるだけで十分です。FVPレイヤでレプリケーションされているデータストアの仮想マシンポリシーに1つもしくは2つのWriteのレプリカデータの保管先の接続数を指定します。レプリケーションされていないデータストアについてはデータストアをフォルトドメイン内部で1つもしくは2つの接続をデータストアに構成します。概略図ですべてのオブジェクト間の関連性を見て行きましょう :

もしレプリケーションの必要がない仮想マシンを展開する場合には、管理者はNon-Replicatedという仮想マシンストレージポリシーを選択すれば良いのです。vSphereの展開プロセスは展開先として互換性のあるデータストアを表示し、仮想マシンを展開します。FVPは自動的にWrite-Backポリシーとしてソースホストのフォルトドメイン内から1つの接続先を選択します。

仮想マシンストレージポリシーを構成する前に、FVPからデータストアを高速化させています。これは手動でも可能ですが、PowerCLIスクリプトで

Get-Datastore –Tag “Replicated” | % { Add-PrnxDatastoreToFVPCluster -FVPCluster "Workload-NVMe" -Name $_.name -WriteBack -NumWBPeers 1 –NumWBExternalPeers 1 }

このスクリプトは｢replicated｣とタグ付けされているデータストアにFVPのフォルトドメイン内(--NumWBPeers)から1つの接続先ホスト、フォルトドメイン外(-NumWBExternalPeers)から1つのホストを選ぶというWriteBackポリシーをアサインします。

仮想マシンストレージポリシーとデータストアレベルのFVPのWriteポリシーを用いることで、仮想マシンは適切なデータストアに配置され、HAイベント時もうまくフェイルオーバーができるようなホストに対してのレプリケーションが設定されます。仮想マシンのサマリページを確認してみましょう :