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

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

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

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

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

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

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

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

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)