株式会社ネットワールドのエンジニアがお届けする技術情報ブログです。
各製品のエキスパートたちが旬なトピックをご紹介します。

運用のシンプルさ

本ブログエントリーはPernixData社のテクノロジーエバンジェリストであるFrank Denneman氏のブログの翻訳版です。

本記事の原文はOperational simplicityで閲覧可能です。
ネットワールドのPernixDataに関する情報はこちら

今日、Twitter上でこんな他愛のない会話がされており、興味を引かれました。

Fig35

訳註:  Duncan Epping氏(@DuncanYB) : 多くの人が新しい(フラッシュを含む)アレイの登場でパフォーマンスについて話してばっかりいるけど、運用のシンプルさも同じぐらい重要だと思う!

運用のシンプルさは(フラッシュを含む)アレイの隠れたコストというだけでなく、David氏自身がいうように高速化のプラットフォームなのです。

Fig36

訳註: David Owen氏(@vMackem) 全くその通り。運用が複雑なために、ソフトウェアのストレージ加速ソリューションが悪さをしてないって、納得してもらうのが大変なことがしょっちゅうあるよ。

私はDavid氏にPernixDataを検証してみたかどうか、確認しましたが、残念なことに検証したことはないそうです(今のところ)。FVPが登場してなかったとしたら、David氏のTweetは今後もっと露骨になっていくところだったでしょう!

FVPは根本から可能な限り操作しなくて済むような操作感を提供するように設計されています。最低限のシンプルな選択だけを行えば、動作させているあらゆるワークロードを高速化できるようになっています。我々は、管理者が有効に時間を使えるようにするためにも、プラットフォームの管理部分も最低限になるべきだと考えています。

ワークロードをFVPで高速化する

FVP内では高速化する仮想マシン、もしくはデータストアを選択することが出来ます。仮想マシンはそれ全体が高速化されます。仮想ハードディスクや他の項目を設定する必要はありません。我々は仮想マシンが生成するI/Oのうち、いずれかだけを高速化するのではなく、すべてのI/Oを高速化するのがベストであると考えています。ただ、仮想マシンを選択し、高速化ポリシーを選ぶ。ポリシーはWrite-ThroughもしくはWrite-Backです。Write-Backを選んだ場合には冗長性のレベルを選択する。これだけです。

Fig37I/Oの高速化という観点からは、仮想マシンの構成を変更する必要は一切ありません。例えば、他のデータストアへ移動させたり、エージェントやドライバーをゲストOSにインストールするなどの必要はないということです。

データストアの高速化はそのデータストアでの標準の高速化ポリシーを作成するということで、設定の項目はすべて仮想マシンの高速化時と同様のワークフローに従います。フラッシュクラスタ内のデータストアの追加を選択、データストアを選び、適切な書き込みポリシーを選択します。Write-Backを選択した場合には冗長性のレベルを選択してOKをクリックすればそのデータストア内に現在、そして今後動作することになるワークロードはすべて高速化されます。

Fig38書き込みポリシーは自動的に既存の、そして新しくそのデータストア内に展開される仮想マシンに適用されます。仮想マシン単位の高速化ポリシーは標準のデータストアのポリシーを上書きし、共通の高速化システム内の特定のワークロードだけを差別化するということも出来ます。

Fig39

データストアの高速化は同じようなサービスレベルが必要とされる環境にとっては理想的です。例えば、VDI環境です。もう一つの理想的なユースケースStorage DRSクラスタ(リンク先は英文)です。データストアクラスタのベストプラクティスは、同じようなデータサービス、スピンドルの速度、スピンドル数などの特性をもったストレージリソースをグループにするということでした。共通の高速化ポリシーをすべてのデータストアクラスタ内のデータストアに適用することで、展開の手順において多くの運用手順を削減することができるでしょう。

Fig40仮想マシンはDRSが選択したコンピューティングパフォーマンスの観点で適切なホストに対して展開されます。また、Storage DRSがデータストアクラスタ内のデータストアのうち、最も適切で推奨されるものを提供します。すべてのデータストアが高速化されていればそれ以上の設定は必要ありません。FVPは自動的に仮想マシンがデータストア内に展開された時に高速化ポリシーを適用します。データストアクラスタ内のすべてのデータストアを高速化しておけば、ストレージDRSによって移行が行われてもパフォーマンスへの影響はありません。仮想マシン毎に適用された高速化ポリシーも移行で影響をうけることはありません。仮想マシンレベルのポリシーはデータストアレベルの高速化ポリシーを上書きするようになっているからです。

これはvCloud Directorの環境でも同様に動作します。プロバイダーvDC(Provider vDC)をDRSとStorage DRSが有効なクラスタに割り当て、利用者がvAppをオーガナイゼーションvDC(Org vDC)内に展開すると、vAppはvSphere環境のデータストアレベルで設定されたポリシーによって自動的に高速化されます。

データストアレベルのポリシーの変更は自動的に仮想マシンに適用されます。これによって管理者は仮想マシンのグループ単位での高速化の変更を容易に行うことが出来ます。蛇足かもしれませんが、仮想マシンレベルの高速化ポリシーがデータストアレベルのポリシーを上書きするため、データストアの高速化ポリシーの変更の影響をうけることはありません。

運用のシンプルさは展開の手順を超え、FVPは設計の段階から自立的に動作できるかぎり動作するように構成されています。例えばフォルトトレラントライトアクセラレーション(冗長性つきの書き込み高速化)を例に取ると、ハードウェア障害やネットワーク切断などの問題が生じた際に、FVPはデータを保護するために、問題が生じている間、すべてのWrite-Back状態の仮想マシンをWrite-Throughモードへ変更します。FVPは問題が生じたことを自動で検出しこの変更を実施しますが、エラーが解消した際には自動的に要求されている書き込みポリシーへ戻します。高速化プラットフォームを加えたアーキテクチャを利用する際に、最も気にしなくてはならないのは管理者がプラットフォームに触れる手間を軽減しながらデータの可用性と一貫性を提供することです。詳しくはフォルトトレラントライトアクセラレーションを。

FVPをインフラストラクチャレイヤにインストールし、仮想マシンをフラッシュプラットフォームに追加し、仮想マシンのパフォーマンスがどれだけ上がったかを見るだけで、特に邪魔をするものは全くないのです。

記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)