Share via


ハイブリッド展開のベスト プラクティス

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

 

Office 365 のハイブリッド展開は、移行プロセスの柔軟性に優れ、各種の共存シナリオに対応し、オンボーディング時には非常にシームレスなユーザー エクスペリエンスを実現します。このため、お客様の多くがハイブリッド展開オプションを利用しています。ただし、このような柔軟性のメリットをもたらす一方で、計画や展開のフェーズにおいていくつかの選択を誤ると、移行プロセスが妨げられたり、サポート対象外の構成になってしまったり、ユーザー エクスペリエンスが低下したりといった事態を招く可能性があります。今回の記事では、よくある間違いを回避しながらハイブリッド構成で最善の選択を行う方法を紹介します。Exchange のハイブリッド構成の詳細については、こちらのページを参照してください。

* この記事の発行時点で、Exchange Server 2016 のプレビュー版の提供が開始されています。プレビュー版は、運用環境での使用を想定してリリースされたものではないため、運用環境にはインストールしないでください。

オンプレミス版 Exchange の展開を適切に行う

ハイブリッド構成に関する便利なガイダンスが Exchange Server 展開アシスタント (EDA) で提供されていますが、この展開アシスタントではオンプレミスとハイブリッドの構成が別々に紹介されています。ハイブリッドのガイダンスでは、明示的に書かれていないものの、オンプレミス環境で現行バージョンの Exchange を適切に展開し共存プロセスを完了していることが前提となっています。このため、Exchange のハイブリッド構成に着手するよりも先に、既存の環境を適切に展開しなければなりません。

つまり、お客様環境で使用している Exchange のうち最も新しいバージョンが Exchange 2010 である場合、通常の接続とオンプレミス環境の全メールボックスのメール フローの負荷を処理できる適正な数の 2010 サーバーを展開する必要があるのです。同様に、お客様環境で使用している最も新しいバージョンが Exchange 2013 であれば、負荷を処理するのに十分な数の 2013 サーバーを展開する必要があります。オンプレミス版 Exchange Server のサイジングの詳細については、こちらのページ (英語) を参照してください。

注: ルールには例外が付きものです。この場合はメール フローが例外となります。メールボックスの大部分を Exchange Online に移行した後でも、すべてのメールがオンプレミス環境を経由するようにハイブリッド構成を行う必要があるお客様もいらっしゃるでしょう。また、オンプレミ スの Exchange サーバーを SMTP 中継として利用するアプリケーションを使用しているお客様もいらっしゃいます。こうした例外をすべて把握して、それらのシナリオを想定してサイジング計画 を行う必要があります。現在、メール ルーティング環境用の計画およびサイジングを行うツールセットが提供されていますが、例外を伴うような複雑なシナリオには対応していません。

一般的なハイブリッド展開を想定してみると、1 日目にはまだクラウド上にメールボックスが存在しないはずです。したがって多くの場合、現行のオンプレミスのワークフローをすべて処理できる環境を使用します。その後 Exchange Online にメールボックスを移行すると、クライアント接続やメール フローのタスクの大半が Exchange Online に引き継がれるので、オンプレミス サーバーの負荷は軽減されます。たとえば Exchange Online への移行後にクロスプレミスで Exchange Online メールボックスの空き時間情報を参照する際などにオンプレミスで必要とされる少量の処理能力は、オンプレミスのメールボックスに必要とされる処理能力には及びません。

ハイブリッド固有の URL を使用する必要があるか

複数の Exchange 2010 サーバーを参照する既存の Mail.Contoso.com および Autodiscover.Contoso.com を維持しつつ、いくつかの Exchange 2013 サーバーを参照する新しいハイブリッド URL (hybrid.Contoso.com など) を使用することにした展開の例もあります。この例の環境では、Exchange 2013 が推奨される方法で導入されていません。少しハイブリッドの話から離れますが、Exchange 2013 を環境に導入するとき、サポートされた方法で共存を構成する必要があります。つまり、オンプレミスの全メールボックスのプロキシの負荷を処理するのに十分な数の Exchange 2013 サーバーを用意して、サイト内の最も新しいバージョンの Exchange への外部 URL を参照するように構成するということです。繰り返しになりますが、ハイブリッド構成に着手する前に、最新バージョンを適切に展開するようにしてください。

Exchange を常に最新の状態に維持する

オンプレミス サーバーで実行される累積更新プログラム (CU)、ロールアップ、サービス パックも見過ごすことはできません。通常の状況では、その時点でリリースされている Exchange の更新プログラムの 2 つ前までがサポート対象になりますが、ハイブリッド環境にはさらに厳格なルールが適用され、1 つ前のビルドまでがサポート対象となっています。最新の更新プログラムが Exchange 2013 CU9 であれば、サポート状況を考慮して Exchange 2013 CU9 または CU8 を使用する必要があります。ハイブリッドのサポート要件を厳しくしている理由は、オンプレミス環境と Exchange Online 環境の連携を強化するためです。使用可能な更新プログラムの詳細については、こちらのページを参照してください。

「ハイブリッド サーバーのみを常に最新状態に維持することはできるのか」と疑問に思われる方もいらっしゃると思います。しかし「ハイブリッド サーバー」というものは存在しません (これについては、後ほど詳しく説明します)。この質問が実際に意味しているのは「ハイブリッド構成ウィザード (HCW) を実行するサーバーのみを常に最新状態に維持することはできるのか」ということでしょう。それならば答えは「ノー」です。この記事を読み進めていくとわかりますが、ハイブリッド展開を構成するということは、大多数のサーバーを活用してクロスプレミスの接続を行うことを意味します。シームレスなエクスペリエンスが実現され、サポート対象となる環境を用意するには、1 ~ 2 台のサーバーだけでなく環境全体で最新状態を維持する必要があります。

オンプレミス構成を最新の状態に正常に更新できれば、サポートされた最適な方法でメッセージング環境にハイブリッド構成を導入するための適切な基盤を築くことができます。

「ハイブリッド サーバー」というものは存在しない

よく「ハイブリッド サーバーを展開したい」という声を耳にしますが、これではまるで特定の 3 ~ 4 台のサーバーを「ハイブリッド サーバー」として指定しているかのようです。ハイブリッドとは組織全体の一連の構成であり、HCW が実行されるサーバーは構成のスタート地点にすぎないという点を見落としているのではないでしょうか。

空き時間情報を参照する場合を例に、簡単に説明します。オンプレミス ユーザーが会議出席依頼を作成してクラウド ユーザーの空き時間情報を参照すると、その要求は自動検出機能によって返された EWS URL に送信され (下図のステップ 1)、そのサーバーは空き時間サービスを開始して Office 365 サービスと通信を行い、要求を代わりに処理します (下図のステップ 2)。この時点では、環境内のどのサーバーでも処理可能です。つまり、ハイブリッド構成を行うと、2010 CAS、2013 メールボックス、2016 サーバー (サポート対象の場合) など、環境内のどのサーバーでも空き時間情報のフェデレーション データに対する要求を処理できます。なお、空き時間情報のフェデレーション データに対する要求を特定のサーバー セットに直接送信する合理的な方法はありません。


オンプレミスから EXO を参照

次に、逆のシナリオについても考えてみましょう。クラウド ユーザーがオンプレミス ユーザーの空き時間情報を参照する場合の処理について説明します。このシナリオでは、EXO サーバーが自動検出機能の要求を実行してオンプレミスの EWS エンドポイントを決定すると (下図のステップ 1)、Autodiscover.Consoto.com エンドポイントまたは Mail.Contoso.com エンドポイントに応答するいずれかのサーバーが代わりに自動検出機能や空き時間情報要求を処理します (下図のステップ 2)。注意していただきたいことは、すべてのオンプレミス ユーザーがクライアント接続などにこれらのエンドポイントを同じく使用するため、大規模環境においてこれを処理できるサーバーが 1 ~ 2 台のみに限られていると望ましくないという点です。つまり、環境内に Exchange を適切に展開してから、ハイブリッド構成を行う必要があります。


EXO からオンプレミスを参照

この混乱が生じる一因として、HCW ではユーザーに対して CAS サーバーやメールボックス サーバーが要求されるという点が挙げられます。CAS を要求する理由は、それらのサーバーの受信コネクタを構成できるようにするためです。また、メールボックスを要求する理由は、送信コネクタを正しく構成できるようにするためです。それらのサーバーを選択することが「ハイブリッド サーバー」を選択することにはなりません。単に、メール フローを明示的に制御するために選択しています。どのサーバーを使用するべきか、また、メール フローのためにいくつのサーバーを追加する必要があるかについて、具体的な推奨事項はありません。メール フローには、シート数、移行スケジュール、地域など、多くの要素が関係しています。

適切なバージョンの Exchange を選択する

ハイブリッド構成ウィザードは Exchange 2010、2013、そして間もなく 2016 から実行可能になるため、「どのバージョンから HCW を実行するべきか」という質問が数多く寄せられています。このような疑問を解決するために必要ないくつかの意思決定について説明します。

Exchange 2003 を導入している場合

Exchange 2003 が環境に導入されている場合、ハイブリッドを実現するには Exchange 2010 を使用するしかありません。つまり、Exchange 2010 環境の展開とサイジングを適切に行う必要があります。そうすれば、ハイブリッド構成プロセスを実行できます。

展開しているうち最も古いバージョンが Exchange 2007 である場合

Exchange 2007 を展開していて Exchange 2010 を展開していないのであれば、Exchange 2013 を適切に展開してからハイブリッド展開を構成することをお勧めします。これにより、最大限の機能セットを使用できます。また、新しいバージョンの Exchange を導入する必要があるので、メインストリームのサポートでサポートされているバージョンを展開してください。

Exchange 2010 を展開している場合

このケースでは、Exchange 2010 でニーズを満たせるかどうか、Exchange 2013 の機能が必要かどうかを各自で判断する必要があります。Exchange 2013 を使用してハイブリッド展開を構成すると、クロスプレミスの電子情報開示、セキュリティ保護が強化されたメール、OAuth フェデレーション サポートなどの機能が使用可能になります。これらの機能が必要ない場合、引き続き Exchange 2010 のオンプレミスを使用してハイブリッド展開を構成しても問題はありません。

オンプレミス環境を Exchange 2013 にアップグレードする場合、ベスト プラクティスのガイダンスに従って Exchange 2013 を展開し、オンプレミスのすべてのトラフィックを処理するのに十分な数の Exchange 2013 サーバーを展開する必要があります。また、適切なステップに従ってオンプレミス環境向けに Exchange 2013 のサイジングと展開を行い、ガイダンスに従ってハイブリッド構成を適切に設定する必要があります。このため、お客様は Exchange Server 展開アシスタントを 2 回利用することになります。1 回目は Exchange 2013 を Exchange 2010 環境に展開するために、2 回目はハイブリッド構成を展開するために使用します。

展開しているうち最も新しいバージョンが Exchange 2013 であり、複数組織のハイブリッド構成を計画している場合

前述した OAuth 構成とは別に、複数組織のハイブリッド展開を構成するには、少なくとも 1 台のオンプレミス版 Exchange 2013 サーバー (サポートされる場合にはそれ以降のバージョンも可) を、複数フォレストのハイブリッド構成に組み込まれるすべてのフォレストで展開している必要があります。Exchange 2010 向けの HCW には、コネクタや組織上の関係に使用される名前付け規則を処理できる適切なロジックがありません。複数フォレストのハイブリッド展開の詳細については、こちらのページを参照してください。

Exchange 2016 では共存がより簡単に

Exchange 2016 がリリースされると、Exchange 2013 と共存させるための展開ガイダンスが今まで以上にシンプルになります。URL を最も新しいバージョンの Exchange に移動させる必要がなくなり、代わりに Autodiscover.contoso.com エンドポイントと Mail.Contoso.com エンドポイントに応答する 1 ~ 2 台の Exchange 2016 サーバーをサーバー プールに追加できるようになります。つまり、1 日目の全トラフィックを処理するのに十分な数の、最も新しいバージョンを実行しているサーバーを用意する必要がありません。

旧バージョンの Exchange を使用しているお客様には特にメリットはありませんが、Exchange 2013 から Exchange 2016 にアップグレードするお客様は、非常に簡単にシームレスなプロセスを利用できるようになります。

まとめ

少々時間が必要ですが、現行のインフラストラクチャをクリーンアップし、ハイブリッド展開のオプションを把握していただくことで、その後の作業時間や負担を大幅に軽減できます。

Lou Mandich、Scott Roberts、Ross Smith IV、Scott Landry、Timothy Heeney