Exchange クライアントの帯域幅予測、およびタイム ゾーンの問題
原文の記事の投稿日: 2012 年 6 月 20 日 (水曜日)
2012 年 6 月 22 日更新 - この記事および関連するダウンロードが更新されました。
Exchange Client Network Bandwidth Calculator の最新リリース (英語)にはいくつかの更新内容が含まれていますが、最も重要な更新はタイム ゾーンのサポートです。過去 12 か月近くの間、タイム ゾーンの問題への対処方法を考えてきましたが、実用的な解決方法を見つけるには少し時間がかかりました。解決方法について説明する前に、まずタイム ゾーンの問題とは何かについて説明します。
タイム ゾーンの問題とは
この記事では、読者がタイム ゾーンおよびタイム ゾーンの目的について理解していることを前提とします。これらについてより理解を深めたい場合は、次に示す Wikipedia の記事を参照してください。
https://en.wikipedia.org/wiki/Time_zone (英語)
ネットワークの帯域幅を予測する観点から見ると、タイム ゾーンの問題は、同じネットワーク接続または同じエンド サービスを共有している、世界中のさまざまな場所にいるユーザーによるワークロードをモデル化する場合に発生します。ほとんどのユーザーの使用のピーク時間は各ユーザーのローカル タイム ゾーンに関連しているため、このことが問題になります。
たとえば、平均的な 1000 ユーザーを持つ組織の標準的な営業日では、通常、午前 10 時ごろを中心に 2 時間、午後 2 時ごろを中心に 4 時間の 2 つのピークが存在します。グラフで表すと次のようになります。
世界の 5 つの異なる場所に対する要件をモデル化するとします。それぞれの場所では、ニューヨークにある共有リソースにアクセスする 1000 ユーザーがサポートされています。ここでは、共有リソースは社内の Exchange 2010 の前に配置されたロード バランサーであると仮定します。
- ロンドン (GMT) = 1000 ユーザー
- ワルシャワ (GMT+1) = 1000 ユーザー
- ジャカルタ (GMT+7) = 1000 ユーザー
- レッドモンド (GMT-8) = 1000 ユーザー
- ニューヨーク (GMT-5) = 1000 ユーザー
これらのユーザーの各セットのピークを予測し、それらを加算するという従来の手法を使用してモデル化した場合、結果は次のようになります。
このグラフは、1000 ユーザーを持つ各サイトでは毎日ピーク時に約 1.56 MB/秒の帯域幅を必要とするため、ニューヨークのロード バランサーを共有するすべてのユーザーを考慮に入れるためにこれら各サイトの帯域幅を加算して、ピーク要件は 7.81 MB/秒となることを示しています。従来は、分散したユーザーの帯域幅を計画する場合、このようにそれぞれのピーク要件を予測し、それらを 1 つのテーブルにまとめて、値を加算するという方法で計画していました。
問題は、レッドモンドのユーザーが起床するときにはヨーロッパのユーザーは帰宅する時間であり、ジャカルタのユーザーは床に就く時間であるということです。
これらのサイトのタイム ゾーンを考慮すると、グラフは大きく変わります。
このグラフは、タイム ゾーンを考慮してワークロードを計算すると、従来の計画とは大きく異なる使用プロファイルが得られることを示しています。注目すべき点は、ピーク ワークロードがもともと予測した 7.81 MB/秒よりも大幅に低い 3.78 MB/秒であることです。使用プロファイルも、最初の予測とは大きく異なっています。
この問題への対処方法
上記のグラフから推測できるように、Network Calculator を拡張して、タイム ゾーンの詳細を組み込むことができるようにしました。
このために、ピーク ワークロードのみを予測する方法をやめて、提供された使用パターン (午前中のピーク時間や午後のピーク時間など) に基づいて 1 時間ごとの帯域幅使用量を予測することにしました。Calculator では、この方法を採用することによって、使用のピーク時間を把握できるだけでなく、1 日のすべての時間帯の使用状況も把握できるようになりました。1 時間ごとの使用量の曲線を取得した後、タイム ゾーンを考慮してそのデータを加算します。
単一システムへの統合を行っているユーザーの事例
多くの組織で、可能な限りワークロードを統合しようと試みられています。このために、設計チームは、しばしば異なるプロファイルを持ち、異なるタイム ゾーンに位置する非常に分散化されたユーザーのサービス ワークロードを計画する必要があります。特にワークロードをクラウドに移動する場合にはこのような計画が必要になります。Office 365 ではテナントの場所として用意されるのは単一の地域のみなので、Office 365 を使用するグローバルな組織では、大部分のユーザーがまったく異なる地域およびタイム ゾーンから、多くの場合共有のインフラストラクチャを経由してサービスにアクセスする際のワークロードを計画する必要があります。
また、協力して作業したお客様の多くは、数多くの小規模なデータセンターを、少数の大規模なデータセンターに統合しています。これらの統合されたサイトでは、以前は分散して処理されていたユーザーからのワークロードを処理できる必要があります。多くの場合、これらのユーザーは異なるタイム ゾーンに位置しているため、このようなワークロードに対応するには、以前は分散されていたワークロードをタイム ゾーンを考慮して合算する方法が必要です。
すべてのユーザーが同じタイム ゾーンに位置している場合は、このような計算は必要なく、通常どおりに Calculator を使用できます。
新しいタイム ゾーン機能の使用
タイム ゾーンのサポートが必要なシナリオでは、この新機能をどのように使用すればよいでしょうか。
まず、[Input] シートの [TimeZone Configuration] テーブルを構成する必要があります。ここで入力するパラメーターによって、ワークロードを合算するために使用される使用量の曲線の形状が制御されます。これらの値は、組織内の平均的な使用パターンを反映したものであることが必要です。通常は、Exchange サーバーを実行した際のパフォーマンス データを確認することに加えて、お客様にユーザーの作業状況やピーク時間を尋ねることによって、このデータを作成します。
[Input] シートに入力したら、[Client Mix] シートに移動します。このシートには、タイム ゾーン データを構成するための 2 つの新しい領域があります。
1 つ目の領域は、[Model Timezone] です。これは、ネットワーク リンクやロード バランサーなどの計画対象リソースのタイム ゾーンを表しています。前の例では、ロード バランサーが存在しているニューヨークの GMT-5 にモデル タイム ゾーンを設定します。
2 つ目の領域は、[TimeZone] という新しい列です。これは、個別のサイトのタイム ゾーンを GMT に対する相対表記で表しています (私はイギリス人なので GMT を使用しましたが、要望が多く寄せられれば今後 UTC に変更する可能性があります)。
予測結果は、前に示したように、[Client Mix] テーブルの下にグラフとして表示されます。このテーブルの値の単位は MB/秒であり、1 時間ごとの予測ネットワーク使用量を表しています。
追加の機能
さらに、別の便利な機能として、Mailbox Role Calculator にコピーして、DAG ネットワーク レプリケーション予測に使用できるテーブルが用意されています。
Network Calculator の [Client Mix] シートの予測グラフの右側に、1 時間ごとの変化をパーセントで表したテーブルがあります。これをクリップボードにコピーします。
次に、Mailbox Server Role Calculator の [Input] シートの下部にスクロールすると、[Log Replication Configuration] テーブルがあります。Network Calculator の数値をこのテーブルに貼り付けます。
これで、Mailbox Server Role Calculator において、組織データおよびタイムゾーン構成の両方を考慮して DAG レプリケーションの帯域幅要件を予測できます。
まとめ
この新機能によって、ネットワーク帯域幅要件をより正確に予測できるようになります。すべての展開で必要なわけではありませんが、この問題で苦労している大企業のアーキテクトは、このタイム ゾーン機能を利用できます。
引き続き、netcalc@microsoft.com まで皆様の貴重なフィードバックをお寄せください。内容はどのようなものでもかまいません。お待ちしております。
Neil Johnson
シニア コンサルタント、MCS UK
これはローカライズされたブログ投稿です。原文の記事は、「Exchange Client Bandwidth Prediction – the time zone problem…」をご覧ください。