Test Results

セントラル サイトのリンク遅延

北側と南側の間のシミュレーションされた WAN リンク上に遅延を発生させるために、ネットワーク遅延シミュレーターを使用しました。推奨トポロジでは、地理上のサイト間で最大 20 ミリ秒の遅延をサポートしています。Lync Server 2010 のアーキテクチャの改良により、許容できる遅延は Microsoft Office Communications Server 2007 R2 の大都市サイト復元トポロジの場合の最大値である 15 ミリ秒よりも大きくできます。

• 15 ミリ秒の場合。 最初に、2 つのサイト間のネットワーク パスと、2 つのサイト間でのデータ複製に使用されるデータ パスの双方に 15 ミリ秒の往復遅延を発生させました。トポロジは、これらの条件および負荷の下で問題なく動作し続けました。

• 20 ミリ秒の場合。 続いて、遅延を増やし始めました。ネットワークとデータの双方のトラフィックで往復遅延を 20 ミリ秒にしても、トポロジは問題なく動作を続けました。20 ミリ秒は、Lync Server 2010 におけるこのトポロジでサポートされている最大の往復遅延です。

  重要:
  Microsoft では、ネットワークおよびデータ遅延が 20 ミリ秒を超えるソリューションをサポートしません。

• 30 ミリ秒の場合。 30 ミリ秒の往復遅延では、パフォーマンスの低下が観測され始めました。特に、アーカイブ データベースと監視データベースのメッセージ キューが増大し始めました。こうした遅延増大の結果として、ユーザー エクスペリエンスも悪化しました。サインインおよび会議作成にかかる時間がどちらも長くなり、音声ビデオに関するエクスペリエンスは大幅に低下しました。こうした理由から、Microsoft では往復遅延が 20 ミリ秒を超えるソリューションをサポートしていません。

フェールオーバー

既に述べたように、トポロジ内のすべての Windows Server 2008 R2 クラスターでは、ノードおよびファイル共有マジョリティ クォーラムを使用しています。その結果、サイト フェールオーバーのシミュレーションを行うためには、南サイトと監視サイトの双方への接続をなくすことですべてのサーバーとクラスターを分離する必要がありました。北サイトでは、すべてのサーバーの "ダーティ" シャットダウンを使用しました。

北サイトの障害発生に伴う結果と監視状況は、次のとおりです。

• パッシブな SQL Server クラスター ノードは数分以内にアクティブになりました。その厳密な時間は、変動する可能性があり、環境の詳細に依存します。北サイトに接続している内部ユーザーは、いったんサインアウトされた後、自動的にサインインされました。フェールオーバーの間、プレゼンスは更新されず、新しいアクション (新たな IM セッション、会議など) は適切なエラーによって失敗しました。フェールオーバーの完了後、それ以上のエラーが発生することはありませんでした。

• ピア間に有効なネットワーク パスが存在する限り、進行中のピアツーピア通話は中断することなく続けられました。

• UC-PSTN 通話は、この通話をサポートしているゲートウェイが使用不可能になった場合に切断されました。その場合も、ユーザーは手動で通話を確立し直すことができました。

• 北サイトに接続していた Lync 2010 ユーザーは、接続が切断され、数分以内に南サイトへの再接続が自動的に行われました。その後、ユーザーは以前と同じように作業を続行できました。

• 再接続を行うために、グループ チャット クライアントのユーザーはいったんサインアウトしてからサインインし直す必要がありました。南サイトのグループ チャット チャネル サービスと参照サービスは、通常は停止状態または無効にされるので、手動で開始する必要がありました。

• 北サイトでホストされていた会議は、南サイトへのフェールオーバーが自動的に行われました。すべてのユーザーには、会議に参加し直すように促すメッセージがフェールオーバー完了後に表示されました。会議のレコーディングは、フェールオーバー中も続けられました。アーカイブ処理は、ホット スタンバイ アーカイブ サーバーがオンラインになるまで停止しました。

• 管理機能は、北サイトがダウンしても動作し続けました。たとえば、ユーザーを存続可能ブランチ アプライアンスからフロント エンド プールに移動できました。

• 北サイトがオフラインになって数分後に、南サイトの SQL Server クラスターとファイル共有クラスターがオンラインになりました。

• 今回のテストで観測されたサイト フェールオーバー時間は、わずか数分でした。

フェールバック

今回のテストのために、フェールバックの定義を、ユーザーが北サイトのサーバーに再接続できるようにすべての機能を北サイトに復元することとしました。北サイトが復元された後、すべてのクラスター リソースは北サイトのそれぞれのノードに移されました。

フェールバック手順の実行時には一部のユーザーの作業が中断される可能性があるので、フェールバックは、なるべく勤務時間外に、制御された方法で実行することをお勧めします。北サイトのフェールバックに伴う結果と監視状況は、次のとおりです。

• クラスター リソースを北サイトのそれぞれのノードに戻す前に、記憶域の完全な再同期が必要でした。記憶域が再同期されていない場合、クラスターをオンライン状態にできません。記憶域の再同期は自動的に行われました。

• ユーザーへの影響を最小限に抑えるために、クラスターは自動的にはフェールバックしないように設定されました。推奨されるのは、記憶域の再同期が完全に済んだ後、次のメンテナンス ウィンドウまでフェールバックを延期することです。

• フロント エンド サーバーは、Active Directory ドメイン サービスに接続できるようになるとオンライン状態になります。フロント エンド サーバーがオンラインになってもまだバック エンド データベースが使用できない場合、ユーザーの機能は制限されます。

  北サイトのフロント エンド サーバーがオンラインになった後、それらのサーバーに対して新しい接続のルーティングが行われます。オンライン状態のユーザーや、通常は北サイトのフロント エンド サーバーを利用して接続しているユーザーは、いったんサインアウトしてから各自の通常の北サイト サーバーにサインインし直すことになります。

  北サイトのフロント エンド サーバーが自動的にオンライン状態にならないようにする場合 (たとえば、プロセス全体をきめ細かく制御する場合や、2 つのサイト間の遅延が許容できるレベルにまで戻っていない場合) は、フロント エンド サーバーをシャットダウンすることをお勧めします。

• 今回のテストで観測されたサイト フェールバック時間は、1 分未満でした。