この記事では、フォールトトレラントメールサービスMicrosoft Exchange 2010 SP1を構築した私の経験について説明します。
理論を理解するために、初心者にとって大部分は役に立ちます。
実用的な側面については掘り下げませんが、フェールオーバーExchangeクラスターを構築するために必要な理論的基礎を説明しようとします。
それ以外はすべて削減されています。 （たくさんのテキスト！）
したがって、Exchange 2010に基づいてフェールセーフメールシステムを構築することがタスクである場合、唯一の（許容される）オプションはDAG（データベースアクセスグループ）を使用することです。
DAGに加えて、必要なExchangeの役割の復元力を確保するために、さらにいくつかのサーバーが必要になります。 それらについては後で説明します。
次の目標を達成する必要がありました。
•内部ネットワークでOutlookを使用しているクライアントのフォールトトレランス
•インターネットからHTTPS経由でRPC経由でOutlookを使用するクライアントの部分的なフォールトトレランス
•ActiveSyncクライアントの部分的なフォールトトレランス
•（インターネットからの）受信メールを失う可能性を最小限に抑える
私の目標に関連して、私は次のスキームに従って作業を開始しました（小さな説明-データセンターとオフィス間のチャネルは30 Mb / s同期です）。
Exchange 2010では、メールボックスサーバーだけがDAGアレイの要素になることができるため、バージョン2007と比較して作業が大幅に簡素化されることを思い出してください。
最初に行うことは、両方のサイトでTMGツールを使用してエッジトランスポートをDMZに配置することです。
ドメインのDNSレコードに、異なる優先順位で3つのMXレコードを書き込みます-1つはDatacenterのTMGを、もう1つはOfficeのゲートウェイを、3つ目はTMGでセットアップされ、ISP冗長性（フェールオーバー）で構成された、オフィスのバックアップチャネルを指します。 これにより、私の目標のリストの4番目のポイントが満たされ、受信メールが失われる可能性が最小限に抑えられます。
データセンターでインターネットが消えた場合/サーバーに障害が発生すると、すべての受信メールがオフィスのサーバーに届きます。 インターネットがデータセンターとオフィス（2つのチャネル）ですぐに消えた場合、メールが届かない唯一のオプションは30分以上です。
次に、内部ネットワークでOutlook 2010を使用しているクライアントにフォールトトレランスを提供します。 これには、メールボックスとクライアントアクセスの役割の回復力が必要です。
メールボックスの役割を持つ2つのExchangeサーバーでは、2つのデータベースが異なるサイトに作成されます-1つは最初のサイトでアクティブになり、2つ目はもう1つのサイトでアクティブになります。
これは何のためですか：
1）すべてが正常に機能する場合の負荷分散。
2）データセンターのサーバーに障害が発生した場合、または使用できなくなった場合、オフィスにはデータベースのコピーがあり、自動的にアクティブモードに切り替わります。 ユーザーは引き続き作業できます。
3）サーバーのサービス保守を実行し、アクティブなサーバーを「ホット」に切り替える機能。
GUIからDAGクラスターを作成する場合、少なくとも1つのFile Witnessサーバーを指定する必要があります。 率直に言って、ファイル監視サーバー（ファイル監視）は、メールボックスサーバーの1つに障害が発生した場合に、クォーラムの音声をサポートする共有フォルダーを持つサーバーです。 しばらく利用できなかったサーバーがバックオンラインになった後、他のクラスターメンバーからの変更を同期（読み取りレプリケート）できると同時に、既に存在しているものと何が「混同」されないようにする必要があります。十分ではありません。
クォーラムを維持するために、各サイトに1つのFile Witnessサーバーを作成しました（インターネットがサイトの1つでクラッシュすると、メールボックスとFile Witnessサーバーの両方がExchangeサーバーの2番目の部分で使用できなくなります）。 しかし、Outlookクライアントにフォールトトレランスを提供するタスクはまだ完了していません。
この段階で、疑問が生じます。「 しかし、Outlookでは誰もが特定のクライアントアクセスサーバーを登録していますか？！ そして、オフラインになった場合、クライアントはどこに接続しますか？ 「。
ネットワーク負荷分散サービスが使用されるのは、このような状況を防ぐためです。 クラスターサービスの役割を持つWindows Server 2008 R2で使用可能な機能を使用しましたが、ハードウェアNLBを使用することを強くお勧めします。
NLBサーバーとして、File Witnessサーバーを使用してリソースを節約しました。
NLBでは、クライアントアクセスの役割を持つ2つのExchangeサーバー間の負荷分散を構成しました。
ただし、これらのサーバー[約。 -クライアントアクセス]はメールボックスサーバーではありません！ これらの役割を異なるサーバー/仮想サーバーに分散することを強くお勧めします。
Outlookクライアントの場合、サーバー（アカウントの設定時に指定する）はNLBサーバーです。 フォールトトレランスをさらに強化するため（NLBサーバーの1つに障害が発生した場合）、同じ名前（ たとえばexchange.contoso.com）を持つタイプAの2つのDNSレコードを作成しました。 NLBサーバー。
同時に、DNSラウンドロビンテクノロジーのおかげで、NLBサーバーの1つに障害が発生した場合、クライアントの約50％が動作可能になります。 もちろん、DNSキャッシュもここで機能しますが、MicrosoftナレッジベースでこれとRound Robinについて個別に読むことができます。
そこで、目標のリストの最初の項目、 つまり内部ネットワーク上のOutlookクライアントのフォールトトレランスを完成させました。
小さな追加-NLBでは、VIPアドレス（内部サブネット全体）を設定します。これは常に（サーバーが利用できない場合を除き）オフィスのExchangeで動作し、インターネットトラフィックを削減し、パフォーマンスを向上させます。 サーバーの1つに障害が発生した場合のみ、クライアントは別のクライアントアクセスサーバーに切り替えます（特に、このルールは、DNSクエリに戻るため、オフィスのWi-Fiに接続するモバイルデバイスにも適用されますローカルネットワークからのIPアドレス）。 私にとってそれは関連性がありました、なぜなら 2番目のサイトにはクライアントがありません。
ローカルネットワーク外のクライアントに適用されるさらに2つのポイントがあります。 ここではすべてが非常に簡単です-私のドメインのパブリックDNSレコードでは、データセンターの外部Forefront TMG IPとそれに対応するものを参照するタイプAレコードを2つ（今回はオフィスのバックアップチャネルでトラフィックを節約するために2つ）示します。 オフィスのIPアドレス。 自動検出サービスはあちこちでアクティブです。
繰り返しますが、ラウンドロビンDNSテクノロジーにより、ActiveSyncおよびRPC over HTTPSクライアントの部分的なフォールトトレランスが保証されます。
PS私はあなたの質問と建設的な批判に喜んでいるでしょう。