本ブログエントリーはPernixData社のテクノロジーエバンジェリストであるFrank Denneman氏のブログの翻訳版です。
本記事の原文はWhat’s new in PernixData FVP 2.0 – User Defined Fault Domainsで閲覧可能です。
ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら。
FVP 2.0のアナウンスに際して、分散耐障害性メモリとNFSへの対応について多くの噂がでてくるものと想像しています。これは歴史上メモリが初めてストレージシステムの一部になるということや、ファイルベースのストレージシステムを高速化できるようになるということを考えると当たり前のことです。しかしながら、新機能の中で最も私が胸を躍らせているものの1つは障害ドメインです。
FVP 2.0ではデータセンタの障害ドメイントポロジを反映して、ホストをグループ化し、書き込みのデータを障害ドメインの外に保存することで冗長性を保証できるようになります。さぁ、このテクノロジを掘り下げましょう。まずは、これまでのヴァージョンの耐障害性書き込み高速化を最初に見てみます。
FVP 1.5の耐障害性書き込み高速化
FVP 1.xでデータストア、もしくは仮想マシンを高速化する際には、書き込みのデータの冗長性については0, 1, 2個のレプリカを指定していました。｢ローカル および 2つのネットワークフラッシュデバイス｣オプションを選択した際には、FVPは自動的にデータストアと接続されており、ソースホストとネットワーク接続されている2つのホストをクラスタ内から選び出していました。もし、ソースホストの接続が切れる、クラッシュする、フラッシュデバイスに障害が起きる、などの問題が起きた場合には、レプリカの書き込みデータを持っているホストのうちの1つが成り代わって、高速化層からストレージシステムにコミットされていないデータのすべてを送信します。更に詳しく知りたい場合については、耐障害性書き込み高速化をご参照ください。
4ホストで構成されているvSphereクラスタを例に取ってみましょう。この4ホストはすべてFVPがインストールされており、FVPクラスタに参加しています。仮想マシンAはローカルコピーと1ネットワークフラッシュデバイスの書き込みポリシーに設定されています。このシナリオではESXiホスト1がピアホストとなり、ホスト2が冗長化書き込みデータ(Redundant Write Data - RWD)をホスト1に送信しています。
しかし、ホスト1とホスト2が同じ障害ドメイントポロジの一部であったとしたらどうでしょう?障害ドメインとは単一障害点を共有するコンポーネントの集合のことです。例えば同一の電源を利用するブレードシステムやサーバラックなどが挙げられます。多くのブレードシステムを利用する組織では、そのエンクロージャーを障害ドメインとして取り扱います。もしもブレードシステムのバックプレーンが障害を起こすと、すべてのサーバがネットワークから切断され、ストレージ、および接続された他のシステムにデータを送信できなくなくなります。
このシナリオではネットワーク接続が落ちてしまうと、コミットされていない両方のデータをストレージアレイに書き込むことができなくなります。もしすべてのブレードシステムがダウンしてしまい、メモリ(RAM)を高速化リソースとして利用している場合にはさらに悪い状況になります。
FVP 2.0 のユーザー定義障害ドメイン
障害ドメインはFVP内にデータセンタのトポロジを反映することができるようになります。このトポロジはWrite-Backモードでの動作時にどこにデータがレプリケーションされるかをコントロールするために利用することができます。
標準での振る舞い
すべてのvSphereクラスタ内のホストは標準で標準障害ドメインに設定されます。標準障害ドメインは名前を変えること、削除すること、専属の組み合わせを指定することはできません。新しく追加されたホストは自動的に標準障害ドメインに配置されます。ホストは1つの障害ドメインのメンバーにしかなることができません。結果として、vSphereクラスタ内のFVPクラスタはすべて障害ドメインを共有することになります。
これ以降のステップについてはこちらの記事の中で言及します : PernixData FVP 2.0の障害ドメインを設定する、 2つの追加の障害ドメインが登場します : Blade Center 1とBlade Center 2です。
レプリカの配置
データストア、もしくは仮想マシンの高速化を設定する際に、Write-Back高速化において、今度はデータをどこにレプリケーションするかを制御できるようになります。特定のホストや、特定の障害ドメインを指定する必要はありません。ただ単に、レプリカ数と同じ障害ドメインに配置するか、外の障害ドメインに配置するかを選ぶだけです。FVPがクラスタ内の異なるvSphereホスト間でワークロードをロードバランスします。ネットワーク帯域と高速化リソースの消費の分散を保持しながら、障害ドメインのポリシーによってコンプライアンスを安全に保つことができるのです。
FVPは同じFVPクラスタ、vSphereクラスタに所属する障害ドメインしか選択できないことにご注意ください。FVPは別のvSphereクラスタに所属するいかなる障害ドメインも選択しません。標準ではFVPのWrite-Back書き込みポリシーは同じ障害ドメイン内の1つのピアホストを選択するようになっています。ですが、これは簡単に別の構成に変更することができます。適切な障害ドメインと必要なレプリカコピー数を選択するだけです。ピアホストの最大数は2を超えることはできないことにご注意ください。例えば、もし別の障害ドメインに2つのピアホストを選択した場合、同じ障害ドメイン内で1つもピアホストを設定することができなくなります。
リスクを出来る限り排除するという設計のため、2つ以上の障害ドメインが構成されているのであれば、FVPはレプリカを2つの障害ドメインにわたって分散することが可能です。つまり、データは3つの別々の障害ドメインに配置されます(ローカル + 障害ドメイン1 + 障害ドメイン2)。
このシナリオでは、ソースホストの障害時には指定された障害ドメインのピアホストがコミットされていない書き込みデータをストレージシステムに書き込むことになります。ネットワーク接続の障害や、ピアホストの障害等の場合にはPernixData管理サーバが新しいピアホストを障害ドメイン内から選択します。これら全ては透過的に行われ、ユーザーの操作は必要ありません。
トポロジの配置と障害ドメイン
障害ドメインはFVP 1.xが保持していた強力な耐障害性機能の上に構成されており、環境をより多くの場合のコンポーネント、ネットワーク、ホストの障害から堅牢に保護する場合に素晴らしい効果を発揮します。FVPの障害ドメインをデータセンタトポロジに合わせることで、書き込みデータを選択的に配置して堅牢に冗長化できるのみならず、ブレードシステムの内部ネットワークの冗長性をも活用できるようになるのです。
記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)
