Exchange 2016 での名前空間の計画


(この記事は 2015 年 10 月 6 日に Exchange Team Blog に投稿された記事 Namespace Planning in Exchange 2016 の翻訳です。最新情報については、翻訳元の記事をご参照ください。)

 

マイクロソフトの多くのお客様は、環境内で既にいくつかのバージョンの Exchange を展開しています。どのバージョンを展開しているかによって、名前空間の要件は異なります。

Exchange 2010

Exchange 2010 ではクライアント プロファイルの変更に自動検出サービスが使用されます。したがって、自動検出の名前空間が使用されます。

Exchange 2010 では、名前空間の要件がさらに追加されています。特に、サイト復元用の名前空間の計画がよりいっそう複雑化しています。

  1. プライマリ データセンターのインターネット プロトコルの名前空間 (mail.contoso.com)
  2. セカンダリ データセンターのインターネット プロトコルの名前空間 (mail2.contoso.com)
  3. プライマリ データセンターの Outlook Web App のフェールバックの名前空間 (mailpri.contoso.com)
  4. セカンダリ データセンターの Outlook Web App のフェールバックの名前空間 (mailsec.contoso.com)
  5. トランスポートの名前空間 (smtp.contoso.com)
  6. プライマリ データセンターの RPC Client Access の名前空間 (rpc.contoso.com)
  7. セカンダリ データセンターの RPC Client Access の名前空間 (rpc2.contoso.com)

これらの 7 つの名前空間のうち、5 つが証明書で必要とされています。RPC Client Access の名前空間は、証明書では必要とされていません。これは、HTTP などのインターネット ベースのプロトコルではなく RPC 接続を介してアクセスが行われているためです。

Exchange 2016

Exchange 2010 と比較した場合、Exchange 2016 のアーキテクチャのメリットの 1 つは、(Exchange 2013 に初めて導入された) 名前空間モデルをシンプルにすることができる点です。

サイト復元のシナリオについて考えると、名前空間モデルをシンプルにする方法が浮かび上がってきます。2 つのデータセンターがサイト復元アーキテクチャに関与している場合、Exchange 2010 のインフラストラクチャを Exchange 2016 で置き換えると、次の 5 つの名前空間を除外できる可能性があります。

  1. セカンダリ データセンターのインターネット プロトコルの名前空間 (mail2.contoso.com)
  2. プライマリ データセンターの Outlook Web App のフェールバックの名前空間 (mailpri.contoso.com)
  3. セカンダリ データセンターの Outlook Web App のフェールバックの名前空間 (mailsec.contoso.com)
  4. プライマリ データセンターの RPC Client Access の名前空間 (rpc.contoso.com)
  5. セカンダリ データセンターの RPC Client Access の名前空間 (rpc2.contoso.com)

これには 2 つの理由があります。

1 つ目は、Exchange 2016 では RPC Client Access の名前空間が使用されなくなったことです。これは、製品内のアーキテクチャが変更されたためです。特定のメールボックスについて、要求に対してサービスを提供するプロトコルは、常に、ユーザーのメールボックス データベースのアクティブ コピーをホストするメールボックス サーバー上のプロトコル インスタンスとなります。つまり、RPC Client Access サービスは、Exchange 2010 での場合と異なり、ストアから切り離されることはありません。

2 つ目は、先に述べたように、Client Access サービスによって、データベースのアクティブ コピーをホストするメールボックス サーバーに対して要求がプロキシ転送されるようになったことです。

図 1: データベースのアクティブ コピーをホストするメールボックス サーバー (MBX Server 3 上) に対して、トラフィックをプロキシ転送する Client Access サービス (MBX Server 1 上)

このプロキシ ロジックは Active Directory サイトの境界に限定されるものではありません。Exchange 2010 とは異なり、Exchange 2016 では、アクティブ化イベント時にクライアントの名前空間を DAG と共に移動させる必要がありません。一方の Active Directory サイトのメールボックス サーバーによって、もう一方の Active Directory サイトに配置されているメールボックス サーバーに対してセッションがプロキシ転送されます。つまり、それぞれのデータセンターに一意の名前空間 (mail.contoso.com、mail2.contoso.com) は必要ありません。代わりに、データセンターのペアに対して 1 つの名前空間 (mail.contoso.com) のみ必要となります。また、フェールバックの名前空間も DAG のアクティブ化のシナリオでは不要となるため、mailpri.contoso.com および mailsec.contoso.com は使用されません。

名前空間のモデル

アーキテクチャとインフラストラクチャに応じて 2 つの選択肢があります。

  1. サイト復元データセンターのペアに対して、統合された名前空間を展開する (無制限モデル)。
  2. サイト復元ペアの各データセンターに対して、専用の名前空間を展開する (制限付きモデル)。

これらの選択肢は DAG アーキテクチャとも関連しています。

無制限モデル

無制限モデルでは、データセンターのペアに対して単一の DAG を展開します。この DAG には、各データセンターのメールボックス サーバーが含まれます。通常、すべてのメールボックス サーバーはアクティブであり、データベースのアクティブ コピーをホストしますが、すべてのアクティブ コピーを単一のデータセンターに展開することができます。どちらのデータセンターのメールボックスも、この DAG 内のメールボックス データベースに分散されます。このモデルでは、WAN の障害が発生したときに、クライアントはどちらのデータセンターにも接続することができます。どちらのデータセンターへの接続も制限がないので「無制限モデル」と呼んでいます。保証はされませんが、両方のデータセンターに対して均等に接続が行われます。つまり、1 つの接続で低待機時間と広帯域幅を実現できるため、ユーザー エクスペリエンスを強化できます。

無制限モデルでは、どちらのデータセンターもユーザーの要求に対してサービスを提供できるので、単一の名前空間の使用が適しています。これは負荷分散の視点から考えると、両方のデータセンターの Exchange 2016 メールボックス サーバーがトラフィックを処理しているということになります。次の図では、VIP (仮想 IP アドレス) が、名前空間と関連付けられた負荷分散対象の IP アドレスとして示されています。

図 2: サイト復元データセンターのペアに対して使用される、単一の名前空間 (無制限モデル)

結果、データセンターのトラフィックの 50% は、他のデータセンターからプロキシ転送されたものとなるはずです。

制限付きモデル

名前のとおり、制限付きモデルでは、ユーザーは特定のデータセンターに関連付けられます (= 制限されます)。つまり、通常時は一方のデータセンター内で処理が行われ、障害の発生時にはもう一方のデータセンター内で処理が行われます。また、両方のデータセンターに均等に接続が行われない可能性があります。一般的に制限付きモデルでは、データセンターのペアに対して 2 つの DAG が展開されます。それぞれの DAG には、特定のデータセンターのメールボックス データベースのセットが含められます。データベースのマウント先を制御することで、接続を制御できます。

制限付きモデルの場合、複数の名前空間の使用が適しています。各データセンターに 2 つの名前空間 (プライマリとフェールバック) を使用することにより、接続が制限されているデータセンターに対してクライアントが接続を試みないようにすることができます。他のデータセンターへの切り替えは制御されます。

図 3: サイト復元データセンターのペアに対して使用される、複数の名前空間 (制限付きモデル)

自動検出の名前空間

Exchange 2016 では、自動検出サービスを使用してクライアント プロファイル構成を行います。したがって、名前空間 autodiscover.contoso.com は引き続き使用されます。

Office Online サーバーの名前空間

Outlook on the web のドキュメント共同作業支援機能を使用するには、Office Online サーバーが必要です。サイト復元を展開するとき、サイト復元データセンターのペアで使用される各データセンターに、Office Online サーバー ファームを展開してください。これによって、ローカル メールボックスに対するドキュメント共同作業の要求に対応できるローカル インスタンスを確保できるほか、クロスサイト プロキシのシナリオを回避できます。

名前空間の視点から考えると、サイト復元データセンター ペアの各データセンターには、Office Online サーバー用の一意の名前空間が必要です。つまり、Office Online サーバーの名前空間は制限付きモデルということになります。Office Online サーバーによって使用される名前空間モデルと Exchange で使用されるモデルは相互排他的であるため、次の図で示すように、無制限モデルを使用して Exchange を展開する一方で、Office Online サーバーに制限モデルを使用することが可能です。

図 4: Office Online サーバーの名前空間 (制限付きモデル) と Exchange の制限なし名前空間モデル

Office Online サーバーによってサービス提供されるデータは、Exchange または SharePoint のいずれかに格納されます。データセンターのサービスが停止したとしても、名前空間に対する操作は不要です。たとえば、前の図で、West (西部) のデータセンターに障害が発生した場合、West の Office Online サーバーの名前空間の DNS レコードを変更して East (東部) ロード バランサーを指定する必要はありません。その理由は、Exchange および Office Online サーバーのアーキテクチャにあります。クライアントの要求は、いずれの Exchange 2016 メールボックス サーバーからも、ユーザーのメールボックス データベースをホストするメールボックス サーバーに常にプロキシ転送されます。ユーザーのメールボックス サーバーをホストするメールボックス サーバーは、OWA で使用される Office Online サーバー URL を生成します。この URL はメールボックス サーバーごとに定義されるため、Office Online サーバーとのすべての通信は、常にメールボックス サーバーに対してローカルで実行されます。

内部の名前空間と外部の名前空間

Exchange 2007 のリリース以来、分離型 DNS インフラストラクチャを展開して、インターネット ベースのクライアントの名前空間を使用することをお勧めしています。分離型 DNS インフラストラクチャを展開すると、クライアントの場所に基づいて、特定の名前空間に対して異なる IP アドレスが返されます。クライアントが内部ネットワークに存在する場合、内部のロード バランサーの IP アドレスが返されます。クライアントが外部ネットワークに存在する場合は、外部のゲートウェイやファイアウォールの IP アドレスが返されます。

このアプローチは、エンドユーザーのエクスペリエンスを簡素化します。ユーザーは、どこから接続する場合でも、1 つの名前空間 (例: mail.contoso.com) を知っていればデータにアクセスすることができます。分離型 DNS インフラストラクチャでは、環境内の InternalURL と ExternalURL に同じ値を使用できるので、Exchange サーバーの仮想ディレクトリの構成をシンプルにすることも可能です。

分離型 DNS (スプリット DNS とも呼ばれる) インフラストラクチャを展開しない場合、Exchange 2016 では、内部クライアントと外部クライアントなどすべてのクライアントに対して、異なる名前空間を指定できます。

重要: 分離型 DNS インフラストラクチャを使用している場合、内部と外部の Outlook Anywhere 設定に同じ認証値を使用するか、Outlook Anywhere の内部と外部に異なる名前を使用して切り替えるようにする必要があります。Outlook では、外部の設定よりも内部の設定が優先されます。クライアントが内部か外部かに関係なく、どちらにも同じ名前空間が使用されるため、内部認証の設定のみ が使用されます。

地域別の名前空間

地域別の名前空間の概念は、1997 年に OWA が発表されて以来存在します。この名前空間は、データをホストしているメールボックス サーバーの最寄りのクライアント アクセス エンドポイントに、クライアントが接続するための手段として使用されます。

地域別の名前空間は、必ずしも制限付きモデルで使用する必要はありません。これは、インフラストラクチャとネットワークの機能に応じて、各データセンター ペアに専用の名前空間を使用することを選択できるためです。たとえば、北米とヨーロッパにデータセンターのセットを配置していて、地域間のネットワーク トラフィックを削減する必要がある場合、各地域に専用の名前空間を展開することができます (地域内では無制限モデルが使用されます)。

図 5: 地域内のデータセンター間でラウンド ロビンを実行するために Geo DNS を使用した地域別の名前空間

名前空間と Active Directory サイトのトポロジ

名前空間のアーキテクチャについて計画するとき、Active Directory サイト内では名前空間と認証設定が同一または一貫したものでなければならない点を理解しておくことが重要です。たとえば、クライアントに送信する応答が自動検出機能によって生成されると、メールボックスが配置されている Active Directory にあるメールボックス サーバーの仮想ディレクトリ設定に基づいて、内部 URL のリストが生成されます。単一の Active Directory サイト内に複数の名前空間を設定すると、クライアントは異なる名前空間にランダムに接続されることになります。同様に、Active Directory サイト内にさまざまな認証設定が使用されていると、クライアントでの動作が異なってしまいます。つまり、Active Directory サイト間では異なる名前空間および認証設定を使用できますが、Active Directory サイト内では使用できないということです。

まとめ

Exchange 2016 では、名前空間のアーキテクチャの柔軟性が大幅に向上しています。そのため、サイト復元データセンターのペア (またはワールドワイド) に 1 つの統合された名前空間を展開したり、複数の名前空間を展開したりすることができます。負荷分散の原則やクライアントの接続性について掘り下げて考えると、どうすれば最善の名前空間モデルを選択できるかが (きっと) 見えてくるでしょう。

Ross Smith IV

プリンシパル プログラム マネージャー

Office 365 カスタマー エクスペリエンス担当

Skip to main content