メールボックスの移行パフォーマンスの解析


(この記事は 2014 年 3 月 24 日に The Exchange Team Blog に投稿された記事 Mailbox Migration Performance Analysis の翻訳です。最新情報については、翻訳元の記事をご参照ください。)

 

オンプレミスのメールボックスを Office 365 に移行する際、メールボックス移行全般において、さまざまな要素が速度とパフォーマンスに影響します。マイクロソフトは、一連の移動要求のパフォーマンスを解析してパフォーマンス低下の理由を探るために、AnalyzeMoveRequestStats.ps1 スクリプト (英語) を用意しています。この記事では、このスクリプトを使用して考えられる原因を調査し、それを解決する方法について説明します。

この AnalyzeMoveRequestStats スクリプトを使用すると、ある一連の移動要求に関する統計情報の中から、パフォーマンス関連の重要な統計情報が得られます。また、このとき 2 つのファイル (エラー リストと、移動要求の各種統計情報) が生成されます。

手順 1: スクリプト (英語) をダウンロードし、次のコマンドを実行してインポートする

> . .\AnalyzeMoveRequestStats.ps1

手順 2: 解析対象の移動要求を選択する

この例では、キューに入っていない、現在実行中の要求をすべて取得します。

> $moves = Get-MoveRequest | ?{$_.Status -ne ‘queued’}

手順 3: 解析対象の各移動要求から移動レポートを取得する

注: この処理には一定の時間を要し、特に、多数の移動を解析している場合は数分程度かかる場合があります。

> $stats = $moves | Get-MoveRequestStatistics –IncludeReport 

手順 4: ProcessStats 関数を実行して統計を生成する

> ProcessStats -stats $stats -name ProcessedStats1

出力結果は次のようになります。

StartTime: 2/18/2014 19:57
EndTime: 3/3/2014 17:15
MigrationDuration: 12 day(s) 19:10:55
MailboxCount: 50
TotalGBTransferred: 2.42
PercentComplete: 95
MaxPerMoveTransferRateGBPerHour: 1.11
MinPerMoveTransferRateGBPerHour: 0.43
AvgPerMoveTransferRateGBPerHour: 0.66
MoveEfficiencyPercent: 86.36
AverageSourceLatency: 123.55
AverageDestinationLatency:
IdleDuration: 1.16%
SourceSideDuration: 78.93%
DestinationSideDuration: 19.30%
WordBreakingDuration: 9.63%
TransientFailureDurations: 0.00%
OverallStallDurations: 4.55%
ContentIndexingStalls: 1.23%
HighAvailabilityStalls: 0.00%
TargetCPUStalls: 3.32%
SourceCPUStalls: 0.00%
MailboxLockedStall: 0.00%
ProxyUnknownStall: 0.00%

出力結果の意味

出力結果を理解するために、まず、次のレポート項目の定義を説明します。

レポート項目

定義

StartTime

要求が最初に追加されたときのタイムスタンプ。

EndTime

要求が最後に完了したときのタイムスタンプ。完了した要求、または AutoSuspended 状態の要求がない場合、この値には現在時刻が設定されます。

MigrationDuration

StartTime から EndTime までの時間。

MailboxCount

メールボックス数。

TotalGBTransferred

データ転送量の合計。

PercentComplete

完了した割合。

MaxPerMoveTransferRateGBPerHour

メールボックスごとの最大転送率。

MinPerMoveTransferRateGBPerHour

メールボックスごとの最小転送率。

AvgPerMoveTransferRateGBPerHour

メールボックスごとの平均転送率。Office 365 へのオンボードでは、0.5 GB/h を超えていれば転送率は正常です。通常、この値は 0.2 ~ 1 GB/h です。

MoveEfficiencyPercent

一時的な障害などの影響により、転送量は必ず元のメールボックスの容量よりも多くなります。この値は SourceMailboxSize の値を TotalBytesTransferred の値で割ったもので、実際の転送量から見た元のメールボックスの容量の割合を表しています。正常な値は 75 ~ 100% です。

AverageSourceLatency

この値は、処理不要の WCF Web サービス呼び出しを元の MRSProxy サービスに送信したときの待機時間を表しています。これは、ネットワークの Ping とは異なります。良好なスループットを得るには、100 ミリ秒程度の値が理想的です。

AverageDestinationLatency

AverageSourceLatency と同様のものですが、Office 365 からオフボード移行を実施するときに使用します。今回のシナリオでは使用しません。

IdleDuration

リソースの使用状況により MRSProxy サービスの要求が MRSProxy サービスのメモリ内のキューで待機した時間を表しています。

SourceSideDuration

移行元 (オンボードの場合はオンプレミスの MRSProxy サービス、オフボードの場合は Office 365 の MRSProxy サービス) での経過時間を表しています。オンボードでは、通常、この値は 60 ~ 80% です。平均待機時間が長い場合、および一時的な障害の発生率が高い場合は、この値が高くなります。正常な値は 60 ~ 80% です。

DestinationSideDuration

移行先 (オンボードの場合は Office 365 の MRSProxy サービス、オフボードの場合はオンプレミスの MRSProxy サービス) での経過時間を表しています。オンボードでは、通常、この値は 20 ~ 40% です。CPU、コンテンツのインデックス作成、高可用性機能などにより移行先での処理が停止すると、この値が高くなります。正常な値は 20 ~ 40% です。

WordBreakingDuration

コンテンツのインデックス作成時に単語分割処理に要した時間を表しています。正常な値は 0 ~ 15% です。

TransientFailureDurations

MRS と MRSProxy サービスの間で発生したインターネットの接続障害など、一時的な障害が発生した時間を表しています。正常な値は 0 ~ 5% です。

OverallStallDurations

CPU、CA (コンテンツのインデックス作成)、HA (高可用性機能) などによる待機時間を含む、システムのリソースが使用可能になるまで待機した時間を表します。正常な値は 0 ~ 15% です。

ContentIndexingStalls

コンテンツのインデックス作成による待機時間を表します。

HighAvailabilityStalls

高可用性機能 (パッシブ データベースへのデータの複製) による待機時間を表します。

TargetCPUStalls

移行先で CPU リソースが使用可能になるまで待機した時間を表します。

SourceCPUStalls

移行元で CPU リソースが使用可能になるまで待機した時間を表します。

MailboxLockedStall

接続障害が発生した場合などに、移行元のメールボックスが一時的にロックされることがあります。そのようなときに、メールボックスのロック解除を待機した時間を表します。

ProxyUnknownStall

CPU など、リモートのオンプレミスのリソースが使用可能になるまで待機した時間を表します。リソースは、生成されたエラー ログ ファイルの内容から特定できます。

次に、SourceSideDuration と DestinationSideDuration の値を確認して、移行元と移行先のどちらのコンポーネントがボトルネックになっているかを判断します。

注: SourceSideDuration の値と DestinationSideDuration の値の和は、通常は 100% になりますが、そうならない場合もあります。

SourceSideDuration の値が正常な範囲の 60 ~ 80% よりも大きい場合、移行元の方がボトルネックになっています。DestinationSideDuration の値が正常な範囲の 20 ~ 40% よりも大きい場合は、移行先の方がボトルネックになっています。

オンボード移行で移行元側の速度が遅い原因

ここからは、オンボード移行で移行元側のパフォーマンスが通常よりも低下する場合に考えられる原因について説明します。

一時的な障害が頻発する

一時的な障害の最も一般的な原因は、メールボックス サーバーのオンプレミスの MRSProxy Web サービスへの接続の不具合です。出力結果の TransientFailureDurations と MailboxLockedStall の値、およびスクリプトが生成したエラー ログを確認し、何らかの障害がないか検証します。一時的な障害が発生している間は移行元のメールボックスがロックされるので、これが原因で移行のパフォーマンスが低下している場合があります。

ネットワークのロード バランサーの構成が不適切

他に、接続の不具合の一般的な原因として、ロード バランサーの構成ミスがあります。サーバーの負荷分散を行っている場合、ロード バランサーは、移行処理独自の要求の呼び出しがすべて MRSProxy サービス インスタンスをホストしている同一のサーバーに転送されるように構成する必要があります。

一部のロード バランサーでは、ExchangeCookie を使用して、移行関連の要求をすべて MRSProxy サービスがホストされている同一のメールボックス サーバーに関連付けています。

ロード バランサーが適切に構成されていないと、移行関連の呼び出しが「誤った」MRSProxy サービス インスタンスに転送されることがあり、この場合処理は失敗します。このため移行元側のメールボックスが一時的にロックされ、移行のパフォーマンスが低下します。

ネットワークの待機時間が長い

Office 365 の MRSProxy サービスでは、定期的にダミーの Web サービスの呼び出しをオンプレミスの MRSProxy サービスに送信し、この呼び出しから統計情報を収集します。この呼び出しの平均待機時間を表すのが AverageSourceLatency であり、この値が大きい (100 ミリ秒を超える) ときは、次の原因が考えられます。

Office 365 とオンプレミスの MRSProxy サービスの間でネットワークの待機時間が長い

この場合、下記の対策によりネットワークの待機時間を短縮する方法があります。

  1. Office 365 のデータセンターに近いサーバーからメールボックスを移行する。通常、この影響はあまり大きくありませんが、移行を急ぐ必要があるときには有効な場合があります。
  2. 空のメールボックス フォルダーを削除するか、メールボックス フォルダーを統合する。フォルダー数が多いと、ネットワークの待機時間による移行速度への影響が大きくなります。
  3. エクスポート バッファーのサイズを大きくする。これにより移行関連の呼び出し数が減少します。特にサイズが大きいメールボックスでは顕著で、ネットワークの待機時間によって消費される時間が短縮されます。エクスポート バッファーのサイズを増やす場合は、MSExchangeMailboxReplication.exe.config ファイルの ExportBufferSizeOverrideKB パラメーターの値を変更します。

例: ExportBufferSizeOverrideKB=”7500″

重要: エクスポート バッファーのサイズを増やすには、Exchange 2013 SP1 がクライアント アクセス サーバーにインストールされている必要があります。なお、この場合、Exchange 2013 と Exchange 2010 のサーバーの間でフォレストをまたいだダウングレード移行はできなくなります。

移行元のサーバーの負荷が大きく、Web サービスの呼び出しへの応答速度が十分でない

この場合は、メールボックス サーバーとクライアント アクセス サーバーのシステム リソース (CPU、メモリ、ディスク IO など) の負荷を軽減します。

スケールの問題

移行要求の負荷分散を行っていなかったり、同一サーバーで他のサービスを実行していたりすると、オンプレミスのメールボックス サーバーやクライアント アクセス サーバーでのリソース消費率が高い場合があります。このようなときは、移行元のメールボックスを複数のメールボックス サーバーに分散し、物理的に異なるハード ディスク上に存在する別のデータベースにメールボックスを移動します。

オンボード移行で移行先側の速度が遅い原因

ここからは、オンボード移行で移行先側のパフォーマンスが通常よりも低下する場合に考えられる原因について説明します。移行先の環境が Office 365 であるため、ボトルネックを解消するためにユーザーがとることのできる対策は限られます。最善の方法は、移行要求を削除し、負荷が比較的低い Office 365 サーバーに移行要求が割り当てられるように再挿入することです。

Office 365 のシステム リソース不足: Office 365 のシステム リソースが不足していることが考えられます。移行先の Office 365 サーバーが、お客様の企業で日常的に使用されているサービスからの要求をサポートするため、負荷が高くなっている可能性があります。

単語分割処理の負荷による停止: Office 365 に移行されるメールボックスのコンテンツは、後でインデックスを作成するために、すべて個々の単語に分割されます。この処理は、Office 365 の検索サービスが MRS サービスと協調して実行します。WordBreakingDuration の値を見ると、この処理に要している時間が確認できます。この値が 15% を超えている場合は、一般的に、移行先の Office 365 サーバーで実行されている、コンテンツのインデックス作成サービスの負荷が高くなっています。

コンテンツのインデックス作成の負荷による停止: Office 365 サーバーでコンテンツのインデックス作成サービスによる負荷が高すぎることが考えられます。

高可用性機能による停止: 複数の Office 365 サーバーにデータをコピーする高可用性サービスの負荷が高すぎることが考えられます。

CPU による停止: Office 365 サーバーの CPU 使用率が高すぎることが考えられます。

Karahan Celikel、移行チーム

 

Skip to main content