次の方法で共有

Skype for Business Serverでのフロントエンド プールのディザスター リカバリー

  • [アーティクル]

ディザスター リカバリーのために、Skype for Business Serverでは、1 つのプールがダウンした場合に備え、プールとフェールオーバーのペアリングが提供されます。

Skype for Business Serverで最も堅牢なディザスター リカバリー オプションについては、地理的に分散した 2 つのサイトにフロントエンド プールのペアをデプロイします。 各サイトのフロントエンド プールは、他のサイトの対応するフロントエンド プールとペアになっています。 両方のサイトがアクティブになっており、バックアップ サービスが提供するリアルタイムのデータ レプリケーションによってプールの同期が維持されます。 フロントエンド プールのペアリングを実装する場合は、「Skype for Business Serverでのディザスター リカバリーのためにペアのフロント エンド プールをデプロイする」を参照してください。

2 つの異なるサイトのフロント エンド プールを互いにペアにして表示します。

一方のサイトのプールで障害が発生した場合は、そのプールから他のサイトのプールにユーザーをフェールオーバーでき、それ以降はそのサイトが両方のプールの全ユーザーに対応します。 容量計画では、障害発生時に両方のプールの全ユーザーのワークロードを処理するように各プールを設計する必要があります。

相互にペアとなるフロント エンド プールが含まれる 2 つのデータ センター間の距離に制限はありません。 同一地域内の 2 つのデータ センターをペアにして、これらの間を高速リンクで接続することをお勧めします。

異なる地域にある 2 つのデータ センターを使用することもできますが、障害が発生した場合、データ レプリケーションの待ち時間が原因でデータ損失が発生する可能性が高くなります。

どのプールをペアにするかを計画する場合、サポートされるのは次の組み合わせのみであることに注意してください。

  • Enterprise Edition プールとペアにできるのは他の Enterprise Edition プールのみです。 同様に、Standard Edition プールとペアにできるのは他の Standard Edition プールのみです。

  • 物理プールとペアにできるのは他の物理プールのみです。 同様に、仮想プールとペアにできるのは他の仮想プールのみです。

  • ペアにするプールは、同じ基本オペレーティング システムを実行している必要があります。

トポロジ ビルダーでもトポロジ検証でも、この推奨事項に従わない方法で 2 つのプールをペアにする操作は阻止されません。 たとえば、トポロジ ビルダーでは、Enterprise Edition プールと Standard Edition プールをペアにできます。 ただし、そのような組み合わせのペアはサポートされません。

バックアップ レジストラーの関係と存続可能なブランチ アプライアンス

障害復旧の機能を提供するほか、ペアになった 2 つのプールは互いにバックアップ レジストラーの役割も果たします。 各プールは、他の 1 つのフロントエンド プールのみのバックアップにすることができます。

たとえ 2 つのフロント エンド プール間のバックアップ関係が 1 対 1 であって対称的でなければならないとしても、各フロント エンド プールは依然として、任意の数の存続可能ブランチ アプライアンスのバックアップ レジストラーになる可能性があります。

Skype for Business では、障害復旧のサポート対象に存続可能ブランチ アプライアンスに所属するユーザーが含まれません。 存続可能ブランチ アプライアンスのバックアップとしての役割を果たすフロント エンド プールがダウンした場合、存続可能ブランチ アプライアンスにサインインしていたユーザーは、フロント エンド プールに所属していたユーザーがバックアップのフロント エンド プールにフェールオーバーされた後でも、復元モードになります。

プールのフェールオーバーおよびフェールバックの復旧時間

プールのフェールオーバーとプールのフェールバックの場合、目標復旧時間 (RTO) のエンジニアリング ターゲットは 15 分から 20 分です。 これは、管理者が障害が発生したと判断し、フェールオーバー手順を開始した後に、フェールオーバーを実行するために必要な時間です。 これには、管理者が状況を評価して決定する時間は含まれません。また、フェールオーバーが完了した後にユーザーが再びサインインする時間も含まれません。

プールのフェールオーバーおよびフェールバックで、エンジニアリング上想定される復旧時点目標 (RPO) は 5 分です。 これは、障害が発生したときに、バックアップ サービスのレプリケーション待機時間に起因してデータが消失する可能性がある時間を表すものです。 たとえば、プールがダウンしたのが午前 10:00 で、RPO が 5 分の場合、午前 9:55 から午前 10:00 の間にプールに書き込まれたデータはバックアップ プールに複製されない可能性があり、消失します。

このドキュメントに示す RTO と RPO の数値はすべて、待ち時間の少ない高速接続で 2 つのサイトが結ばれている同じ地域内に 2 つのデータ センターが設置されていることを前提としています。 これらの数値は、データ レプリケーションにバックログがない定義済みのユーザー モデルに関して、40,000 人の同時アクティブ ユーザーと 200,000 人のユーザーがSkype for Businessに対して有効になっているプールについて測定されます。 これらの数値は、パフォーマンス テストおよび検証に基づいて変更される可能性があります。

中央管理ストアのフェールオーバー

中央管理ストアは展開内のサーバーとサービスに関する構成データを含んでいます。 各Skype for Business Server展開には、1 つのフロントエンド プールのバックエンド サーバーによってホストされる 1 つの中央管理ストアが含まれています。

中央管理ストアをホストするプールを組み合わせる場合は、バックアップ中央管理ストア データベースをバックアップ プール内にセットアップします。 任意の時点で、2 つの中央管理ストア データベースのいずれかがアクティブであり、他の 1 つがスタンバイになります。 コンテンツはバックアップ サービスによりアクティブ データベースからスタンバイに複製されます。

アクティブな CMS ストアとパッシブ バックアップ CMS ストアの 2 つのフロントエンド プールを表示します。

中央管理ストアをホストしているプールを含むプール フェールオーバーでは、フロント エンド プールをフェールオーバーする前に中央管理ストアをフェールオーバーする必要があります。

障害が修復された後に中央管理ストアをフェールバックする必要はありません。 修復後、中央管理ストアはフェールオーバーしたプール内に残ります。

中央管理ストアのフェールオーバーのエンジニアリング目標は、5 分の目標復旧時間 (RTO) と 5 分の目標復旧ポイント (RPO) です。

フロントエンド プールのペアリング データのセキュリティ

バックアップ サービスは、ペアになった 2 つのフロント エンド プール間でユーザー データと会議コンテンツを継続的に転送します。 ユーザー データには、ユーザーの SIP URI のほか、会議スケジュール、連絡先リストと設定が含まれます。 会議コンテンツには、Microsoft PowerPoint のアップロードのほか、会議で使用するホワイトボードが含まれます。

ソース プールから、このデータはローカル ストレージからエクスポートされ、zip 形式でエクスポートされた後、ターゲット プールに転送され、そこで解凍され、ローカル ストレージにインポートされます。 Backup Service は、2 つのデータ センター間の通信リンクが、インターネットから保護されている企業ネットワーク内にあることを前提としています。 2 つのデータ センター間で転送されたデータは暗号化されず、HTTPS などのセキュリティで保護されたプロトコル内にネイティブにカプセル化されるデータもありません。 そのため、企業ネットワーク内の内部担当者からの中間者攻撃が可能です。

複数のデータ センターにSkype for Business Serverをデプロイし、ディザスター リカバリー機能を使用する企業は、データ センター間のトラフィックが企業イントラネットによって保護されていることを確認する必要があります。 内部攻撃からの保護を求める企業は、データ センター間の通信リンクをセキュリティで保護する必要があります。 これは標準的な要件であり、データ センター間で転送される他の種類の企業の重要データを保護するのにも役立ちます。

企業ネットワーク内では中間者攻撃のリスクが存在しますが、トラフィックをインターネットに露出することに比べればまだ無難です。 具体的にいうと、バックアップ サービスによって露出されるユーザー データ (SIP URI など) は一般的に、その他の手段 (グローバル アドレス帳やその他のディレクトリ ソフトウェアなど) によって、社内の従業員全員が利用できます。 そのため、ペアになった 2 つのプール間でデータをコピーするためにバックアップ サービスを使用する場合は、2 つのデータ センター間の WAN を保護することに重点を置くべきです。

セキュリティ リスクの軽減

Backup Service トラフィックのセキュリティ保護を強化するには、さまざまな方法があります。 これは、データ センターへのアクセスの制限から、2 つのデータ センター間の WAN トランスポートのセキュリティ保護までです。 ほとんどの場合、Skype for Business Serverをデプロイする企業には、必要なセキュリティ インフラストラクチャが既に用意されている可能性があります。 ガイダンスを探している企業向けに、Microsoft はセキュリティで保護された IT インフラストラクチャを構築する方法の例としてソリューションを提供します。 詳細については、を参照してください https://go.microsoft.com/fwlink/p/?LinkId=268544。

私たちは、それが唯一の解決策であることを意味せず、また、それがSkype for Business Serverのための好ましい解決策であることを意味しません。 企業のお客様には、IT セキュリティのインフラストラクチャと要件に基づいて、各社のニーズに合ったソリューションを選択することをお勧めします。 マイクロソフトのソリューション例では、サーバーとドメインの分離に IPSec とグループ ポリシーを採用しています。

もう 1 つのソリューションは、バックアップ サービスそのものによって送信されたデータのセキュリティ保護だけに IPSec を使用するというものです。 この方法を採用する場合は、プール A とプール B が 2 つのペアになったフロント エンド プールになっている次のサーバーについて、SMB プロトコルの IPSec ルールを構成する必要があります。

  • プール A の各フロント エンド サーバーからプール B によって使用されるファイル ストアへの SMB サービス (TCP/445)。

  • プール B の各フロント エンド サーバーからプール A によって使用されるファイル ストアへの SMB サービス (TCP/445)。

注意

IPsec は、SSL/TLS のようなアプリケーション レベルのセキュリティに代わるものではありません。 IPsec を使用する利点の 1 つは、既存のアプリケーションを変更することなく、ネットワーク トラフィックのセキュリティを提供できることです。 2 つのデータ センター間のトランスポートをセキュリティで保護するだけの企業は、ベンダーの機器を使用してセキュリティで保護された WAN 接続を設定する方法について、それぞれのネットワーク ハードウェア ベンダーに問い合わせてください。

関連項目

Skype for Business Serverでのディザスター リカバリーのためにペアのフロント エンド プールをデプロイする