« 2015年9月 | メイン | 2015年11月 »

2015年10月

2015/10/30

ONTAP8.3降臨編 これであなたも!ONTAPシミュレーターマスターだだだっ!!⑦

皆さんこんにちは。NetAppチームの和田です。

 

この連載がシミュレーターマスターだだだっ!シリーズの最終話となります。

 

途中からシミュレーターがova形式になって「最初の方の記事意味あるのかなぁ・・・」となったり、

先週久々に記事を書こうとしたらシミュレーターが動かなくなっていたり、

一番よくなかったのは記事タイトルの「降臨」を「光臨」と誤変換していることにしばらく気づかなかったり様々なことがありました。

 

ちなみに今週の記事を書いている際にもroot volumeのログがあふれて動かなくなり、シミュレーターを作り直すことになりました。

やはりova形式になってからシミュレーター作成が楽になりましたね

 

 

こちらが今回の目次でございます。

 

目次(確定)

ONTAPシミュレータの入手とVMデータストアへの展開編

シミュレータ起動前の下ごしらえ編

初期セットアップ編

ディスク本数/容量を増やしてみましょう編

ClusterSetup編

・SVMも作っちゃいます?編←前回のテーマ 

・BroadcastDomain編←今回のテーマ

 

 

まずはBroadcast Domainについて簡単に解説していきます。

現在のBroadcast Domainの構成を確認しましょう。

Wsa000020

図にするとこのような構成です。

Wsa000024

 仮にDataLIFがnode1:e0cに乗っているとすると、node1:e0cに障害が発生した際にはnode1:e0d, node2:e0c, node2:e0dのいずれかにフェイルオーバーします。

「・・・それってONTAP8.2時代のFailoverGroupとどう違うの?」という声が聞こえてきそうですが、、

 

・・・大体同じようなものと考えても問題ないかと思います。

ただ、以下のようなMTUがセグメントごとに異なる構成ですと、FailoverGroupでフェイルオーバーする先を指定するのではなく、Broadcast Domainを明示的に分ける必要があります。

Wsa000026


こちらが現在のLIFのフェイルオーバーの設定となります。

FailoverGroupはBroadcast Domain"Default"で、現在LIFがいるポートに障害が起きた際には各ノードのe0c,e0dにフェイルオーバーすることになります。

Wsa000028

 

ESX側で擬似的に障害を起こして、どのポートにフェイルオーバーするか確認してみましょう。

仮想マシンの設定からネットワークアダプタの「接続中」のチェックを外します。

Wsa000031

すると・・・

 

Wsa000032_2

 

LIFが乗っていたnode2:e0cがdownしたので、 Broadcast Domain内の別のポートにフェイルオーバーしました。

ただ、以下のような構成でnode2:e0cにフェイルオーバーされるとまずいので、Broadcast Domainを別にします。

(図は再掲)

 

Wsa000026

 

Broadcast Domainを分ける詳細な手順は割愛させていただくとして、以下のような構成に変更しました。

Broadcast Domainの操作はLIFが作成されている状態だと非常に複雑な手順になるので、できれば設計段階できっちり決めておきたいところです・・・

 

Wsa000034

 

LIFのフェイルオーバー先の設定は以下のようになります。

これで先ほどの様にESXからポートを落としたときに反対側のノードのe0dにフェイルオーバーしてくれれば大丈夫ですね。

 

Wsa000035

 

きちんと意図したとおりにフェイルオーバーしてくれました。

Wsa000036

 

 

 

全7話の8.3版シミュレーターマスターシリーズは以上となります。

以前のシミュレーターマスターの記事の焼き直しではなく、少しはパワーアップした内容にしようと努力しましたが、いかがでしたでしょうか・・・?

 

 

OSがバージョンアップすると新しい機能が増えると同時に設定が難しくなるという部分も確かにありますが、シミュレーターで慣れることもある程度は可能かと思います。

「シミュレーターではなくやはり実機じゃないと!」という方には、二日間ガッツリ設計から構築を実機で行う炎のトレーニングも不定期で開催しておりますので、今後もネットワールドを宜しくお願い致します。

 

和田

 

 

 

 

 

ONTAP8.3降臨編 これであなたも!ONTAPシミュレーターマスターだだだっ!!⑥

皆さんこんにちは。そしてお久しぶりです(本連載二回目)、NetAppチームの和田です。

 

あまりにBlogを書くのをサボっていたので、ESX上のシミュレーターが動かなくなっていました。

クラスタを作り直してこの記事を書くに至りますが、作成したクラスタ名が前回の記事と異なっていますね。。

(前回の記事の終わりでは"cDOT83"というクラスタ名でした)

さて、どうしましょう・・・

 

こちらが今回の目次でございます。

 

目次(ほぼほぼ確定)

ONTAPシミュレータの入手とVMデータストアへの展開編

シミュレータ起動前の下ごしらえ編

初期セットアップ編

ディスク本数/容量を増やしてみましょう編

ClusterSetup編←前回のテーマ

・SVMも作っちゃいます?編←今回のテーマ 

・BroadcastDomain編

 

 

前回の記事で作ったクラスタにログインしてみましょう。

 

sshでクラスタ管理IPに接続します。

User:"admin", password:"各自設定したパスワード" です。

 

Wsa000006

どう見ても前回の記事とクラスタ名が違います。

せっかくですのでクラスタ名を変えてみましょう。

 

Wsa000007

"cluster identtity modify"コマンドでクラスタ名を変更できました。

 

ではノード名も変えられるの?となるとは思いますが、、

 

Wsa000005

一応可能です。

無秩序にノード名を変えることも可能ですが、シミュレーター上でのみにしておきましょう。

 

Wsa000008

ノード名はアルファベット順で並ぶので、NOBUNAGAがこれまでのnode01に相当することになります。

どちらがどちらかわからなくなって非常にしんどくなります。

 

SVMを作成しましょう。

と、その前にデータ用Aggregateが必要なので、"aggr create"コマンドを使ってこんな感じで。

 

Wsa000009

こんな感じでさくっと"aggr1_n2"をノード2に作成しました。

aggr1_n1を作るときのスクリーンショットを撮り忘れたので、ノード2がアクティブ側ということにしましょう。

 

Aggregateの詳細設計のコツ等々につきましては、ネットワールド開催の

「NetApp炎のトレーニング」に来ていただければと思います。

次回は関西で開催予定です。

 

 

さて、本題のSVM作成に入りましょう。

 

NFSサービス用SVMを作成するという想定ですと、

SVM作成→ボリューム作成→LIF作成→ExportPolicy作成→NFSサービス開始

というのが一連の流れになります。

 

スナップショットや重複排除の設定などになると長くなってしまいますので、この記事では割愛させていただきます。

 

LIF作成までをざっと流した時のコンソール画面が以下のようになります。

やはり長いですね、コマンド・・・

 

Wsa000010

上のコマンドで作成したものをそれぞれshowコマンドで確認すると次のようになります。

 

Wsa000011

 すごく自然にsvm_nfsのデータ用ボリュームを作る先のAggregateの指定を間違えました。。

これではcluster interconnectを経由するインダイレクトアクセスになってしまうので、この機会にvol moveしてみましょう。

 

Wsa000017

 

ExportPolicyについては、まずはNFSでクライアントからマウントできるまで!ということで、

どのクライアントからもrootアクセスできる非常に緩いポリシーで作成しましょう。

 

Wsa000013

あとは"nfs create"コマンドを実行すれば・・・というところなのですが、

ライセンスを入れ忘れていると・・・

 

Wsa000014
こうなります。"license add"コマンドでライセンスを入れてあげましょう。

 

ここまで設定すればLinuxからNFSマウントが可能なので、実際にマウントして確認しましょう。

 

Wsa000016_2
とりあえずRW可能なことを確認できました。

以上、SVM作成編でした。

 

次回はとうとう最終話のBroadcast Domain編です。

どういう記事の構成にするか非常に悩みますが、来週も気合入れて行きます。

 

2015/10/26

FVPのスケールアウトアーキテクチャ

本ブログエントリーはPernixData社のシニアテクニカルディレクターであるMahesh Patil氏のブログの翻訳版です。 

Fig307

Mashesh氏はPernixData社のシニアテクニカルディレクターで、耐障害性Write-Backの主な発明者です。それ以前には彼はVMwareでスタッフエンジニアとして務め、11年以上に渡り様々な仮想化のテクノロジーを手がけてきました。

アセンブリコードを簡単に使いこなすのと同様、彼はRubyも得意としており、専門は仮想化、カーネル開発、リソース管理、OSコンテナ、クラウドオペレーティングシステムなど多岐にわたります。彼はESXi製品の基盤を成したエンジニアの一人です。クラウドOSに関する専門性を買われ、VMwareではCloud Foundryのプロジェクトにも貢献していました。

本記事の原文はScale Out Architecture of FVPで閲覧可能です。

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

スケールアウトはスケールアップとは対照的にソリューションを多くのホストをクラスタ内に追加することで成長させることを約束するものです。しかし、この約束をうまく果たせていないソリューションを目にすることも稀にあります。なぜスケールアウトは難しいのでしょうか?それぞれのソリューションが固有にもかかわらず、スケールアウトが難しい理由にはいくつかの共通したテーマがあります。

  • 複数のホストは複数のデータのコピーを意味する
  • 複数のコピーは一元性と一貫性を維持し続ける必要がある

コピーの一元性を維持し続けるためには、「キャッシュの一貫性」について紐解く必要があります。以下のリストで紐解いていきましょう。リストの下ほど一貫性のための値段(コスト)が高くなります。

  • 変更できないオブジェクト
  • 変更可能なオブジェクト  Single Reader, Single Writer (Single-RW)
  • 変更可能なオブジェクト Multiple Readers, Multiple Writers (Multi-RW)

変更できないオブジェクトの一貫性を保つのはとても簡単です。変更可能なオブジェクトについては、システムにより多くのWriterが追加されシステムが複雑化してくると、オブジェクトの一貫性を保つために、ネットワークを通じてメッセージのやり取りを初める必要が出てきます。そして、これらのメッセージの数がクラスタ内のホストが増えるに連れて級数的に増えていくということが頻繁に起こります。つまり、クラスタ内のホスト数が増えるごとにキャッシュの一貫性のためにしなくてはならないこと(コスト)が増えるのです。

しかし、全てのスケールアウトシステムがMulti-RWに紐づく「キャッシュの一貫性」のためのコストを支払う必要はありません。業界ではMulti-RWのキャッシュ一貫性のためのコストを支払っている場合でも、Single-RWのキャッシュ一貫性のキャッシュ一貫性アルゴリズムしか必要ない場合が多くあります。このMulti-RWアルゴリズムのマズイ選択はシステムのパフォーマンス、複雑さ、安定性に波及効果を及ぼします。以下の例で説明していきましょう。

例1

分散ファイル編集システム

  • 複数のユーザーが地理的に隔たって分散しています。
  • 複数のユーザーは同じドキュメントを同時に共有、編集可能です。ドキュメントに対する更新はすべてのユーザーからほぼリアルタイムに閲覧可能です。
  • ユーザーのレイテンシはローカルのデスクトップ上のドキュメントの編集とさほど変わりないことが期待されます。

Fig308もし、レイテンシがこのシステムの行く末を決めるキーメトリックであるならば、このシステムは上で表したようなソフトウェアがユーザーに対してドキュメントをローカルで編集させながら、一方でバックグラウンドで複数のユーザーの編集を調停するような分散システムになることでしょう。結果としてMulti-RWキャッシュ一貫性を保証し、システムは様々なホストが保持しているコピーを最新に保つためのメッセージを交換することになります。Multi-RWキャッシュ一貫性アルゴリズムに加え、システムは以下の点を解決しなくてはなりません。

  • 一元性 - それぞれのユーザーにどのように更新を表示されるか。これは様々なモデルを採用することができます。完全一元化、時々一元化など。もしあるユーザーがとある更新を別の更新の前に見たとしたら、それ以外のユーザーも同じ順番でそれを見たいと思うはずです。
  • 分断 - もしネットワークの分断が起き、いくらかのユーザーが他のユーザーから切断されてしまった場合にシステムはどうすべきなのか?
  • 高可用性 - データはしっかりとレプリケーションされているべきです。

今日ではそれぞれについてよく知られたアルゴリズムやソリューションがあります。これらのソリューションの殆どはパフォーマンス、正確さ、可用性の全てのタイトロープを渡りきったものです。多くの場合、一つのことは他のものへ影響を与えます。 例えば、高いパフォーマンスを求めるシステムは完全に一貫していなくても良い事があります。様々なトレードオフがそれぞれのソリューションにありますが、詳細に分け入らなければ大きなパフォーマンスへの影響やアルゴリズムの複雑さ、各タスクが正しく実装されているかを言及することはできません。

例2

ファイル編集システム

  • 複数のユーザーが地理的に隔たって分散しています。
  • それぞれのユーザーは自分自身のドキュメントしか編集できません。
  • ユーザーはロケーションを動きまわることができますが、自分自身のファイルしかアクセスができません。
  • ユーザーのレイテンシはローカルのデスクトップのドキュメントを編集する程度であることが求められます。

この例ではドキュメントは唯一のユーザーからしか編集ができなくなっていますので、このシステムは単純にSingle-RWのためのキャッシュ一貫性アルゴリズムを利用すれば良いことになります。このアルゴリズムではドキュメントを最新に保つために他のシステムとメッセージを交換する必要がありません。「例1」で解決しなくてはならなかった他の問題も見てみましょう。

  • 一元性 - 1人のユーザーが自身のドキュメントを更新するので、ドキュメントのコピーは常に一元的です。
  • 分断 - 同様にネットワークの分断もユーザーに影響を与えません。ユーザーは自身のドキュメントを操作しているだけなので、そのまま継続ができます。ですから、この問題も些細なものになります。
  • 高可用性 - 「例1」と同様、データはしっかりとレプリケーションされなくてはなりません。

Fig309

分散スケールアウトソリューションを構築する際に、「例1」とは違い、こちらの立場で考えるべきだとお分かりいただけて来たのではないかと思います。どうしてどうしてこの特定の問題がスケールアウトソリューションを低遅延で構築する際に重要なのかも理解いただけてきたかもしれません。

問題に見合ったソリューション

上の2つの例からすべての分散システムが同じではないということはよくお分かりいただけたと思います。もし開発者が彼らが相対している問題に見合うソリューションを見つけられたら、それによってソリューションのメリットを阻害することなく、不必要に複雑なものを導入する必要はありません。明らかに上の例では「例1」のために作られたソリューション、つまりMulti-RWキャッシュ一貫性は「例2」つまり Single-RWキャッシュ一貫性の問題も解決できているはずです。ですが、本当にMulti-RWキャッシュ一貫性が必要なのでしょうか?

この考え方がFVPのスケールアウトデザインの根本的な部分です。我々は自らにといました。もしも、仮想化環境のスケールアウトソリューションを作ることができたら?それはどんなものか?どのキャッシュ一貫性アルゴリズムを使うべきなのか?

Fig310上の図は典型的な仮想化環境を表しています。上の絵はほとんど「例2」に似たようなものであるということがわかるでしょう。仮想マシンのデータは完全にvmdkファイルにカプセル化されています。仮想マシンは自分自身のvmdkにしかアクセスしません。つまりSingle-RWです。仮想マシンは任意の時点で一つのホスト上のみで動作しますので、これらのvmdkファイルは必ず唯一のホストからのみアクセスされます。もし仮想マシンがvMotionした場合、ユーザーが別のロケーションに移動するようなものです。移動後も自身のファイルにアクセスし続けるだけで、他のクラスタ内の無数の仮想マシンのファイルには興味はありません。では、FVP ソリューションを登場させましょう。

Fig311FVPがシステムに導入されると、仮想マシンはローカルフラッシュデバイスを利用してローカルにキャッシュを構築し始めます。それぞれのホスト上のフラッシュデバイスはそのホスト上で動作している仮想マシンのvmdkすべてを格納できるほどに大きいと思ってください。このすべてのvmdkを格納できるという想定や実際にどれだけのデータがローカルに保存されているのかという点はスケールアウトの観点からは全く問題にはなりません。

Fig312上のシナリオでは、それぞれの仮想マシンのvmdkへのReadは全てローカルのキャッシュから提供されます。もし、ユーザーがクラスタに1つのホストを追加したとしたら、図は以下のように変わります。

Fig313

リニアにスケール

上にある通り、FVPクラスタに新しいホストが追加され、追加の高速化リソースがホスト上で高速化されている仮想マシンで利用できるようになっています。今のところ、仮想マシンは動きまわらないと考えてください(後でこの単純化については戻ってきて言及します)、ですから、これらの仮想マシンはローカルフラッシュデバイスのみで高速化されます。この実装ではクラスタ内の他のホストとのやり取りは一切発生しません。キャッシュ一貫性のためのメッセージはネットワークを流れることはないのです。クラスタのサイズではFVPソフトウェアの挙動は一切変わることはありません。1台、32台、1000台のクラスタであっても問題にならないのです。Readのパフォーマンスは仮想マシンが動作しているホストで利用可能なフラッシュの総量によってのみ制限をうけ、クラスタ内のホスト数の影響は受けないのです。お分かりのとおり、このソリューションではReadはシステム内のホストの数が増えるに連れてリニアにスケールし、フラッシュの容量によってのみ制限を受けることになります。これは非常に重要な特性です。クラスタ内のホスト数によってリニアにスケールする能力を備えているのです。

Single-RWキャッシュ一貫性

一般的な分散システムではMulti-RWキャッシュ一貫性問題を解決しなければならないことで、リニアにスケールすることが難しくなっています。「例1」において、ユーザーに対して書き込みの順序を保証できるように合意を取ろうとしてクラスタ内の全てのシステム・ホストが一貫した表示を実現しようとすることはシステムに非常に巨大なオーバーヘッドを生み出します。そして、このオーバーヘッドは大抵の場合、クラスタ内のホストの数によって増大します。FVPソリューションはこのような制限に悩まされることはありません。問題の解決はSingle-RWキャッシュ一貫性ソリューションによって実現可能で、分散された同士がコンセンサスを取ることが必須とされているMulti-RWキャッシュ一貫性ソリューションを使う必要が無いからです。

キャッシュ一貫性とvMotion

しかしながら、現実の世界では仮想マシンは動き回ります。仮想マシンが別のホストに移動を始めると、キャッシュの一貫性を維持するためにFVPのキャッシュ一貫性アルゴリズムが呼び出されます。我々のキャッシュ一貫性アルゴリズムは仮想マシンが新しいホストへ移行する際にのみ、呼び出される様になっています。その後の仮想マシンからのIOはキャッシュの一貫性にペナルティを与えることはありません。全てのIOについてキャッシュの一貫性についてのタスクを実施するのではなく、FVPソリューションは上の図の通りに再度動き始めます。つまり、システム内のホスト数でリニアにスケールするのです。vMotion後のリモートのReadについてもシステム内のホスト数が増えることで、増えるものではないことをご確認ください。FVPのキャッシュ一貫性アルゴリズムは以前どのホストでその仮想マシンが動作していたということを理解しており、リモートReadを行うホストにダイレクトにアクセスするのです。

まとめ

FVPのパフォーマンスのスケールアウトは仮想マシンが自分自身のvmdkファイルにしかアクセスしないということをよく理解した上でそれを活用するように構成されています。仮想マシンがSAN/NAS上の自分自身のデータにアクセスする際に、周りと相互確認を行うことはありません。このことをキャッシュ一貫性アルゴリズムと結合することで、仮想マシンのIOへオーバーヘッドを全く与えない、システム内のホスト数でほとんどリニアにスケールするスケールアウトアーキテクチャをFVPは提供するのです。

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

2015/10/19

PernixData FVPで高速化した実環境の IIS/.NETのワークロード

本ブログエントリーはPernixData社のシステムズエンジニアであるPeter Chang氏のブログ記事を翻訳しています。 Peter氏はネットワールドのプリセールス活動をサポートしてくださっている担当エンジニアでもあります。

本記事の原文はReal World IIS/.Net Workload Acceleration with PernixDataで閲覧可能です。

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

実際のエンタープライズアプリケーションに関するシリーズ記事を続けましょう。今回は中規模のエンタープライズの環境で動作しているWindows 2003とWindows 2008の.NETを動作させているウェブサーバとアプリケーションサーバの高速化について示していきます。

環境を簡単におさらいしましょう :

  • ESXi 5.0 Update 2がインストールされた8台のDell M620ブレードサーバのクラスタ
  • 10Gbのネットワーク
  • ストレージへはFCで接続
  • バックエンドのストレージ装置はだいたい250本のスピンドル(FC, SAS, SATAを組み合わせ)で35,000~40,000IOPSを提供可能
  • PernixData FVP 1.0と400GBのIntel S3700のSSDが各ホストにインストール
  • 200より少し少ないぐらいの仮想マシンがWrite-Back(WB)と冗長化のために2つのレプリケーションで高速化

サーバ名はメインで動作しているアプリケーションに合わせて変更してあります。

アプリケーション: IIS/ .NETウェブサーバが動作しているWindows 2003 Std 64 ビット

概要: 外部のエージェントが利用するインターネットへ公開されたWebサーバのフロントエンド。サーバはポータルのウェブアプリケーションで、ユーザーを認証し、他のサーバからのデータのリクエストを中継します。

レイテンシ:

以下のグラフが示しているのは業務開始時間近くの1時間の値で、データストアのレイテンシはある辞典では10ミリ秒ほとのピークに達しています。この間隔の中でも仮想マシンから見たレイテンシは2ミリ秒ほどを推移しており、低いところで0.5ミリ秒、高いところでも4ミリ秒を保っています。これはWriteのためのレプリカを2つも作成している状態での値です。オレンジのラインで表示されているフラッシュデバイスのレイテンシは一貫して1ミリ秒未満であり、ユーザー・エクスペリエンスの観点からはFVPを実装した後のユーザー・エクスペリエンスは以前より非常に早く、クリックしてからページが切り替わるまでは「パッ!」という具合で、全体としてのパフォーマンスはより一貫した、そして予測可能なものになります。

Fig299

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

2015/10/14

【連載】第5回 始めてみよう!CommVault Simpana VMwareバックアップ応用編(2) およびリストア


第4回では、ストレージのスナップショットと連携する VMware vSphere 環境の仮想マシンのバックアップ方法をご紹介しました。今回の第5回では、Simpana の重複排除機能を利用した手法と、VMware 仮想マシンのリストア手法をご紹介します。

Simpana が持つデータ重複排除機能を使用することにより、ストレージやネットワークリソースを節約しながら、バックアップ時間が削減されます。

昨年、重複排除機能の概要をご紹介しましたように、Simpana の場合、標準機能として搭載されておりますが、一部のサードパーティ製のバックアップソフトウェアの場合、同機能が有償オプションとして提供されているものもありますが、最近は一般的な機能として活用されています。

Simpana で活用される主な重複排除機能として、重複排除データベース内のデータを並べ替えてフルバックアップを作成する合成バックアップDASH FULLや、リモートの複製先にないブロックのみを転送することで、複製処理のコストを削減するDASH COPYが提供されています。

 

【DASH FULL 処理フロー】

Dash_full

1.メタデータ情報の読取り
2.バックアップイメージの抽出は不要
3.メタデータ情報の合成
4.合成用のデータ格納領域は不要
5.メタデータ情報の書込み
6.重複排除処理は不要

【DASH COPY 処理フロー】

Dash_copy_2

1.ソース側で署名情報の取得
2.ターゲット側の DDB に対し、署名情報があるかを問合せ
3.ターゲット側で検出された場合、メタデータのみを送信
4.検出されない場合、メタデータおよびデータを送信

続きを読む »

2015/10/12

FVP上の実環境のドメインコントローラー

本ブログエントリーはPernixData社のシステムズエンジニアであるPeter Chang氏のブログ記事を翻訳しています。 Peter氏はネットワールドのプリセールス活動をサポートしてくださっている担当エンジニアでもあります。

本記事の原文はReal World Domain Controller on FVPで閲覧可能です。

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

実際のエンタープライズアプリケーションに関するシリーズ記事を続けましょう。今回は中規模のエンタープライズの環境でのWindows 2008のドメインコントローラーの高速化について示していきます。

環境を簡単におさらいしましょう :

  • ESXi 5.0 Update 2がインストールされた8台のDell M620ブレードサーバのクラスタ
  • 10Gbのネットワーク
  • ストレージへはFCで接続
  • バックエンドのストレージ装置はだいたい250本のスピンドル(FC, SAS, SATAを組み合わせ)で35,000~40,000IOPSを提供可能
  • PernixData FVP 1.0と400GBのIntel S3700のSSDが各ホストにインストール
  • 200より少し少ないぐらいの仮想マシンがWrite-Back(WB)と冗長化のために2つのレプリケーションで高速化

サーバ名はメインで動作しているアプリケーションに合わせて変更してあります。

Domain Controller 1

概要: Windows 2008R2 のドメインコントローラー、ADが統合されたDNSサーバ、10サイトあるデータセンタのマルチフォレストのADのうちの一つ 

レイテンシ:

以下のグラフは後ろのストレージ装置と仮想マシン間の間のレイテンシが3ミリ秒(とても良い)から10ミリ秒のあたりを推移iしており、1時間の間に10ミリ秒を超えるスパイクが28ミリ秒ほどになっていることを示しています。ですが、ローカルフラッシュのレイテンシは0.5ミリ秒ほどで一貫しており、仮想マシンへの実効レイテンシは時々のスパイク時もレプリケーションを2箇所に対して行っていても2ミリ秒かそれ未満です。28ミリ秒ほどの最初のスパイク発生時も仮想マシンへのレイテンシは1/3ほとで、2つ目の27ミリ秒ほどのスパイク時には実効レイテンシは2ミリ秒かそれ未満です。13倍も低いのです。

Fig297

Domain Controller 1 のデータストアのレイテンシ 1時間

ヒット率:

以下の時間間隔のリードキャッシュのヒット率は大きく変動しています。これはこの中規模のエンタープライズは数千のアカウントと100を超えるアプリケーションがあるため、ユーザーやサービスアカウントからの数多くのAD認証や多くのLDAPクエリ、ADに対する数多くの書き込みが定常的に起こっているからです。見て分かる通り、上のグラフではストレージ装置上のデータストアのレイテンシは様々で、Readのオフロードだけでは仮想マシンやアプリケーションに対してはパープルのレイテンシが見えてしまいます。実際にReadだけを高速化した場合、仮想マシンから見えるレイテンシはさらに悪化します。パープルのラインはホスト内のSSDを通してReadとWriteが提供された後のデータストアのレイテンシだからです。ですから、実際にはパープルのラインはストレージ上のレイテンシのちらつきをスムーズ化し、スパイクを吸収している値なのです。そうでなければもっと高いレイテンシの値を記録したことでしょう。

Fig298Domain Controller 1 のヒット率 1時間

サマリ:

見て分かる通り、ドメインコントローラーに対するストレージパフォーマンスの向上は目覚しいものです。この短時間だけでもストレージのレイテンシは5倍以上改善しており、バックエンドのストレージ装置から比べると10倍以上ということもあります。ADのレイテンシは全てのネットワーク上のAD認証を利用するアプリケーションに影響します。この値が低いことはアプリケーションの応答が良いということと同じで、ユーザーはよりハッピーということになります。

これらのグラフからは見えませんが、多くのネットワーク上のグループのユーザーがアプリケーションにログオンしたり、夜間のバックアップ時にストレージ装置のレイテンシが更に、そして頻繁にスパイクした際に更に大きな改善が見られるでしょう。レイテンシが落ちてしまうと見落としてしまいますが、以下の様な重要な点が挙げられます :

  • 高速化したワークロードと高速化していないワークロードの両方でバックアップスピードが改善(ホットデータがキャッシュにあることと、そうでなくてもストレージ装置が以前ほど忙しくないため)
  • バックアップのタイミングでオンラインでログオンしたオフショアの従業員、夜間シフトの従業員、残業中のシステム管理者などのユーザー・エクスペリエンスが改善
  • 夜間のバッチジョブの完了にかかる時間の改善
  • 24時間体制でシフトを組んでいるネットワーク運用センターのオペレーターのエクスペリエンスの改善

マイレージ(訳注:得られる改善の総計)は環境内のワークロードによって異なりますが、これらの中規模のエンタープライズの実際の環境のドメインコントローラーグラフのFVPによる改善のほんの一部からご想像いただけると幸いです。

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

2015/10/05

PernixData FVPで実際のSharePointのワークロードをスピードアップ

本ブログエントリーはPernixData社のシステムズエンジニアであるPeter Chang氏のブログ記事を翻訳しています。 Peter氏はネットワールドのプリセールス活動をサポートしてくださっている担当エンジニアでもあります。

本記事の原文はSpeeding Up Real World Sharepoint Workloads with PernixData FVPで閲覧可能です。

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

実際のエンタープライズアプリケーションに関するシリーズ記事を続けましょう。今回は中規模のエンタープライズの環境でSharePoint 2010のワークロードを高速化した結果をお見せいたします。SharePointアプリケーションサーバとSharePointサーチサーバの両方について触れていきます。

環境を簡単におさらいしましょう :

  • ESXi 5.0 Update 2がインストールされた8台のDell M620ブレードサーバのクラスタ
  • 10Gbのネットワーク
  • ストレージへはFCで接続
  • バックエンドのストレージ装置はだいたい250本のスピンドル(FC, SAS, SATAを組み合わせ)で35,000~40,000IOPSを提供可能
  • PernixData FVP 1.0と400GBのIntel S3700のSSDが各ホストにインストール
  • 200より少し少ないぐらいの仮想マシンがWrite-Back(WB)と冗長化のために2つのレプリケーションで高速化

サーバ名はメインで動作しているアプリケーションに合わせて変更してあります。

SharePoint 2010 App Server 1

概要: SharePoint 2010が動作しているWindows Server 2008R2 

レイテンシ:

以下のグラフではデータストアのレイテンシがだいたい2ミリ秒ーとても良いーから8ミリ秒ほどまで変化しており、ひどい時には一時的に30ミリ秒や40ミリ秒にまでなっています! ですが、ローカルのフラッシュデバイスはだいたい1ミリ秒かそれ未満で一貫しており、SharePointの仮想マシンの実効レイテンシは2つのWriteの冗長化のためのWrite-Back接続を含めても2~3ミリ秒程度です。データストアのレイテンシが40ミリ秒以上にスパイクしても、実効レイテンシは15ミリ秒ぐらいで、データストアのレイテンシが35ミリ秒程度でも、仮想マシンからの実効レイテンシは2ミリ秒からそれ未満です!

Fig290

SharePoint App Server 1 のデータストアのレイテンシ 1時間

Read/Writeのレイテンシ:

以下のグラフは仮想マシンのReadとWriteをブレイクダウンしたものです。このグラフのポイントはPernixData FVPがある種の解析を行い、特定の仮想マシンやアプリケーションのRead/Writeの様子を理解することを手助けしてくれるということです。カスタムブレイクダウンチャートのオプションも用意されており、更に詳細に深く分け入ることも出来るようになっています。

Fig291

SharePoint App Server 1 のRead/Writeレイテンシ 1時間

Read/Writeスループット:

上と同じですが、スループットを表示しています。

Fig292_2

SharePoint App Server 1 のRead/Writeスループット 1時間

ヒット率/廃棄率:

アプリケーションサーバのキャッシュのヒット率は頻繁に100%になっていますが、キャッシュされていないデータに対するReadがバックエンドのストレージ装置に対しても発生しています。

Fig293

SharePoint App Server 1 のヒット率 1時間

SharePoint 2010 App Server 2

概要:SharePoint 2010が動作しているWindows Server 2008R2

このサーバは上のサーバの負荷分散のためのもう片方のノードです。もう片方の仮想マシンと比べて、この仮想マシンが配置されているデータストアのレイテンシはさほど高くスパイクしていません(冗長化と可用性のために別々のホスト、データストアに配置されています)。しかし、ReadとWriteの双方を高速化できることのメリットがはっきりと出ており、時々の小さなスパイクがある程度で、一貫してレイテンシが1ミリ秒未満から2ミリ秒の間に収まっています。

レイテンシ:

Fig294

SharePoint App Server 2 のデータストアレイテンシ 1時間

SharePoint 2010 Search server

概要:SharePoint 2010 Search serverが動作しているWindows Server 2008R2 

レイテンシ - データストア:

サーチサーバについてのデータストアのレイテンシは2ミリ秒から10ミリ秒の間を行ったり来たりしており、スパイク時は35ミリ秒から45ミリ秒にもなることがあります。最初のSharePointアプリケーションサーバと似たような数字ですから、この2つの仮想マシンは同じデータストアで動作しているのかもしれません。前と同様に、ローカルフラッシュのレイテンシは一貫して1ミリ秒未満から1.5~2ミリ秒で、1時間の間に2回ほどの頻度でスパイクが発生しています。データストアレイテンシが45ミリ秒ぐらいまで上がっている時点での仮想マシンでの実効的なレイテンシは1/3程度です。レイテンシが35ミリ秒ぐらいまで上がっている時点での仮想マシンのレイテンシは2ミリ秒ぐらいです。17倍も短いのです。大体において仮想マシンのレイテンシが後ろのデータストアから提供されているものの1/5程度になっていることがお分かりになるでしょう。これはサーチサーバにとっては特に重要なことです。

Fig295

SharePoint Search Server のデータストアレイテンシ 1時間

ヒット率/廃棄率:

以下のグラフは同じ時間の仮想マシンのヒット率と廃棄率を表しています。お分かりのとおり、ヒット率は頻繁に100%になっています。落ち込んでいるところはバックエンドのストレージに対してのReadが発生していることを表します。しかし、これは検索サーバですから、エンドユーザーの検索スピードの体感はヒット率に影響されます。廃棄率は0%であり、フラッシュデバイスの領域は効率的に管理され、この時間内ではデータを廃棄する必要がなかったことを示しています。

Fig296

SharePoint Search Server のヒット率 1時間

上のグラフは実際の中規模のエンタープライズにおいて、SharePointアプリケーションサーバとSharePointサーチサーバの両方がうまく高速化されていることを示しています。仮想マシンを高速化することで、バックエンドのストレージ装置はいつも行っている追加業務をしっかりと行える余裕が生まれます。そして、オフロードは掛け算のように200近くものサーバで起こるのです。もっとも重要なのはSharePointのエンドユーザーの体感で、ページが早く読み込まれウェブサイトをより快適に感じるようにすることです。

さて、更に実際のエンタープライズアプリケーションの解析シリーズを続けていきます。お楽しみに。

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