Exchange 2013 での名前空間の計画


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

 

先日、Exchange 2013 での名前空間の計画と負荷分散の原則について、記事で取り上げることをお約束しました。最終的に、記事をシリーズ化し、名前空間の計画、負荷分散クライアント接続の共存証明書の計画など、いくつかのトピックを扱う運びとなりました。タイトルのとおり、この初回の記事では、名前空間の計画の原則についてお話します。

 

名前空間の計画

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

Exchange 2007

Exchange 2007 の環境では、少なくとも、次の 2 つの名前空間のシナリオがあります。

  1. 自動検出の名前空間 – autodiscover.contoso.com
  2. 1 つ以上のプロトコル ベースの名前空間 – mail.contoso.com (OWA、EAS)、imap.contoso.com (POP/IMAP クライアント)、smtp.contoso.com (SMTP クライアント送信、アドホックな暗号化、パートナー間の暗号化)

さらに、複数のデータセンターの環境に展開している場合、地域ごとに追加のプロトコル ベースの名前空間を使用している可能性があります。

Exchange 2010

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

Exchange 2007 (または Exchange 2003) からのアップグレードのお客様向けに、従来の名前空間 (legacy.contoso.com) という、共存のための新しい名前空間の要件が取り入れられています。従来の名前空間は、たとえば alderaan.contoso.com など、任意の名前で呼ばれるので注意が必要です。

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)

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

Exchange 2013

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

サイト復元のシナリオについて考えると、名前空間モデルをシンプルにする方法が浮かび上がってきます。2 つのデータセンターがサイト復元アーキテクチャに関与している場合、Exchange 2010 のインフラストラクチャを Exchange 2013 で置き換えると、次の 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 2013 では RPC Client Access の名前空間が使用されなくなったことです。これは、製品内のアーキテクチャが変更されたためです。特定のメールボックスについて、要求に対してサービスを提供するプロトコルは、常に、ユーザーのメールボックス データベースのアクティブ コピーをホストするメールボックス サーバー上のプロトコル インスタンスとなります。つまり、RPC Client Access サービスは、Exchange 2010 での場合のようにストアから切り離されることはありません。

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

名前空間のモデル

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

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

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

無制限モデル

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

無制限モデルでは、どちらのデータセンターもユーザーの要求に対してサービスを提供できるので、1 つの名前空間の使用が適しています。つまり、負荷分散のために、両データセンターの CAS インフラストラクチャがトラフィックの処理に関与しています。以下の図を参照してください。

1: サイト復元データセンターのペアに対して 1 つの名前空間を使用 (無制限モデル)

結果、特定のデータセンターについて、トラフィックの 50% が他のデータセンターから仲介されることを期待できます。

制限付きモデル

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

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

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

その他の名前空間

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

Exchange 2007 からのアップグレードを予定している場合、従来の名前空間を使用して接続を確保する必要があります。従来の名前空間を使用すると、OWA への接続が可能になります。これは、自動検出応答で返される名前空間 (例: Exchange Web サービス URL) であり、インターネットに接続されていない Active Directory サイト内に存在する Exchange 2007 メールボックスへのアクセスを可能にします。

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

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

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

分離型 DNS インフラストラクチャを展開しない場合、Exchange 2013 には 1 つの改善策があります。Outlook Anywhere は、現在、分離した内部の名前空間と外部の名前空間に対応できます。

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

地域の名前空間

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

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

図 3: 地域の名前空間

まとめ

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

Ross Smith IV

Office 365 カスタマー エクスペリエンス担当
主任プログラム マネージャー

Skip to main content