Lync Server 2013 フロントエンド サーバー、インスタント メッセージングおよびプレゼンスのトポロジおよびコンポーネント

  • [アーティクル]

 

トピック最終更新日時: 2014-10-24

インスタント メッセージング (IM) とプレゼンスに必要なコンポーネントは、次に示すものだけです。

  • 組織のフロントエンド サーバーまたは Standard Edition サーバー。 これらのサーバーで、IM およびプレゼンス機能は常にオンになっています。

  • ロード バランサー (Enterprise Edition フロントエンド プールがある場合) 詳細については、「 Lync Server 2013 の負荷分散要件」を参照してください。

フロントエンド プールの展開の計画

Lync Server 2013 では、フロントエンド プールのアーキテクチャが変更され、これらの変更はフロントエンド プールを計画および保守する方法に影響します。

すべてのEnterprise Edition フロント エンド プールには、少なくとも 3 つのフロントエンド サーバーが含まれていることをお勧めします。 Lync Server では、フロントエンド プールのアーキテクチャは分散システム モデルを使用し、各ユーザーのデータはプール内の 3 つのフロントエンド サーバーに保持されます。 この新しいアーキテクチャの詳細については、「 Lync Server 2013 でのトポロジの変更」を参照してください。

3 つのEnterprise Edition フロント エンド サーバーを展開せず、ディザスター リカバリーが必要な場合は、Lync Server Standard Edition を使用し、ペアのバックアップリレーションシップを持つ 2 つのプールを作成することをお勧めします。 これにより、2 台のサーバーだけでディザスター リカバリー ソリューションが提供されます。 高可用性とディザスター リカバリーのトポロジと機能の詳細については、「 Lync Server 2013 での高可用性とディザスター リカバリーの計画」を参照してください。

フロントエンド プールの管理の計画

フロントエンド プールの場合は、このセクションのガイドラインに従います。

プールが機能していることを確認する

フロントエンド プールの新しい分散モデルでは、プールが機能するためには、プールのサーバーの特定の数が実行されている必要があります。 プールには 2 つの損失モードがあります

  • 特定のルーティング グループに対して十分なレプリカ サーバーが不足しているため、ルーティング グループ レベルのクォーラム損失。 ルーティング グループは、プールに所属する一連のユーザーの集計です。 各ルーティング グループには、プール内に 1 つのプライマリと 2 つのセカンダリという 3 つのレプリカがあります。

  • プール レベル クォーラム損失。プールで十分な数のシード サーバーが実行されていない場合に発生します。

ルーティング グループ レベル クォーラム損失

新しいフロント エンド プールを初めて起動するときには、次の表に示すように、サーバーの 85% が実行されていることが必要です。 実行されているサーバーの数がそれより少ないと、サービスが起動状態で行き詰まり、プールが起動されないことがあります。

プール内のサーバーの合計数 プールを初めて起動させるために実行する必要があるサーバー数

2

1

3

3

4

3

5

4

6

5

7

5

8

6

9

7

10

8

11

9

12

10

その後もプールが起動されるたびに、サーバーの 85% が起動されている必要があります (前出の表を参照)。 この数のサーバーを起動できない (ただし、プール レベル クォーラム損失にはならない数のサーバーが起動されている) 場合は、Reset-CsPoolRegistrarState –ResetType QuorumLossRecovery コマンドレットを使用して、プールをルーティング グループ レベル クォーラム損失から復旧させ、処理を続行させることができます。 このコマンドレットの使用方法の詳細については、「 Reset-CsPoolRegistrarState」を参照してください。

注意

Lync Server はプライマリ SQL データベースを監視として使用するため、プライマリ データベースをシャットダウンしてミラー コピーに切り替え、前の表に従って十分に実行されないように十分なフロントエンド サーバーをシャットダウンすると、プール全体がダウンします。 詳細については、「 データベース ミラーリング監視」を参照してください。

プール レベル クォーラム損失

フロントエンド プールがまったく機能するためには、プール レベルのクォーラム損失にはできません。 次の表に示すように、実行中のサーバーの数が機能レベルを下回った場合、プール内の残りのサーバーはすべての Lync Server サービスを停止します。 次の表の数値は、プール内のバックエンド サーバーが実行されていることを前提としています。

プール内のフロント エンド サーバーの合計数 プールを機能させるために実行する必要があるサーバーの数

2

1

3 ～ 4

任意の 2 台

5 ～ 6

任意の 3 台

7

任意の 4 台

8 ～ 9

最初の 7 台のうちの任意の 4 台

10 ～ 12

最初の 9 台のうちの任意の 5 台

この表でいう最初のサーバーとは、プールが初めて起動されたとき先に立ち上げられたものから順に数えたサーバーです。 これらのサーバーを特定するには、–PoolFqdn オプションを使用して Get-CsComputer コマンドレットを使用できます。 このコマンドレットはサーバーをトポロジ内に出現した順に表示するので、そのリストの先頭にある方が最初のサーバーです。

2 つのフロントエンド サーバーを備えたフロントエンド プール

2 つのフロント エンド サーバーのみを含むフロントエンド プールを展開することはお勧めしません。 このようなプールをデプロイする必要がある場合は、次のガイドラインに従います。

  • 2 つのフロントエンド サーバーのいずれかがダウンした場合は、失敗したサーバーをできるだけ早くバックアップするようにしてください。 同様に、2 台のサーバーのうち 1 台をアップグレードする必要がある場合は、アップグレードが終わり次第、オンラインにします。

  • 何らかの理由で両方のサーバーを同時に停止する必要がある場合は、プールのダウンタイムが終わったら次のことをします。

    • ベスト プラクティスは、両方のフロントエンド サーバーを同時に再起動することです。

    • 2 台のサーバーを同時に再起動できない場合は、停止した順序とは逆の順序で復旧する必要があります。

    • その順序でバックアップできない場合は、プールをバックアップする前に次のコマンドレットを使用します。

      Reset-CsPoolRegistrarState -ResetType QuorumLossRecovery -PoolFQDN <FQDN>

プールが機能していることを確認するためのその他の手順

フロント エンド プールを確実に機能させておくために、他にもいくつかの要因を監視する必要があります。

  • 初めてプールにユーザーを移動する場合は、少なくとも 3 つのフロントエンド サーバーが実行されていることを確認します。

  • ディザスター リカバリーの目的でこのプールと別のプールの間にペアリング関係を確立する場合は、そのリレーションシップを確立した後、バックアップ プールとデータを適切に同期するために、このプールに 3 つのフロントエンド サーバーが同時に実行されていることを確認する必要があります。 プールのペアリングとディザスター リカバリー機能の詳細については、「 Lync Server 2013 での高可用性とディザスター リカバリーの計画」を参照してください。

プールアップグレードの信頼性の向上

フロント エンド プール内のサーバーをアップグレードまたはパッチ適用する必要がある場合は、「 Lync Server 2013 のフロント エンド サーバーのアップグレードまたは更新」に示されているワークフローと、次のガイドラインに従います。

  • アップグレードのために 1 つのアップグレード ドメインから別のアップグレード ドメインに移行する場合 ( Lync Server 2013 のフロント エンド サーバーのアップグレードまたは更新のワークフローに従う)、 Get-CsPoolUpgradeReadinessState コマンドレットを使用して準備完了状態を確認します。 "準備完了" に達した後、各アップグレード ドメイン間に 20 分間の待機を追加すると、アップグレードの信頼性が向上します。 この 20 分間に 準備ができていない 場合は、20 分間タイマーを再起動します。 また、20 分間隔を開始する前と後に Get-CsPoolFabricState コマンドレットを実行し、ルーティング グループのプライマリとセカンダリに変更がないことを確認することもできます。

  • パッチが適用された最後のアップグレード ドメイン内のいずれかのサーバーがスタックしているか、再起動されていない場合は、次のアップグレード ドメインに移行しないでください。 これは、アップグレード内のいずれかのサーバーが起動できない場合にも適用されます。 Get-CsPoolFabricState を実行して、すべてのルーティング グループにプライマリと少なくとも 1 つのセカンダリがあることを確認します。これにより、すべてのユーザーがサービスを持っているかどうかが確認されます。

  • 一部のユーザーにサービスがあり、そうでない場合は、–Verbose オプションを指定して Get-CsPoolFabricState を実行して、レプリカが不足しているルーティング グループを確認します。 最初のトラブルシューティング手順としてプール全体を再起動しないでください。 このコマンドレットの詳細については、「 Get-CsPoolFabricState」を参照してください。

  • windows fabric のインストール/アンインストールのために、イベント ビューアーまたはパフォーマンス モニターウィンドウのすべてのインスタンスが閉じられていることを確認します。

フロントエンド プールの構成の変更

フロントエンド サーバーをプールに追加するか、プールから削除し、新しいトポロジを発行するたびに、次のガイドラインに従います。

  • 新しいトポロジが発行されたら、プール内の各フロント エンド サーバーを再起動する必要があります。 1 台ずつ再起動してください。

  • 構成変更中にプール全体がダウンしている場合は、新しいトポロジが発行された後で次のコマンドレットを実行します。

    Reset-CsPoolRegistrarState -PoolFQDN <PoolFQDN> -ResetType ServiceReset

フロント エンド サーバーが失敗し、数日間以上交換される可能性が低い場合は、トポロジからサーバーを削除します。 新しいフロントエンド サーバーが再び使用可能になったら、トポロジに新しいフロントエンド サーバーを追加します。