Exchange Queue & A: 負荷分散、エッジトランスポートなど

[アーティクル]
08/24/2016

Exchange Queue & A負荷分散、エッジトランスポートなど

Henrik Walther

質問 - Microsoft® Office SharePoint® Server を実行する複数のサーバーを自社の運用環境に展開しています。これらの各サーバーを使用し、最近展開した Exchange Server 2007 インフラストラクチャ内のハブトランスポート (HT) サーバーを経由して、送信メッセージを中継する必要があります。図 1 に示すように、SharePoint サーバーでは、[サーバーの全体管理]、[サーバー構成の管理] を順にクリックすると表示される [送信メールの設定] ページで 1 台の SMTP (Exchange) サーバーの完全修飾ドメイン名 (FQDN) を指定することしかできませんが、どうすればこの単一障害点をなくすことができるでしょうか。

図 1 SharePoint の [サーバーの全体管理] ページの [送信メールの設定] (画像をクリックすると拡大表示されます)

回答 - とても良い質問ですね。非常に多くの組織が高可用性の実現に力を入れており、自社の運用環境全体で単一障害点をなくすことに努めています。このことは、特にメッセージングおよびコラボレーションサービスに当てはまります。

Exchange 2007 HT サーバーでは、既定で高い回復力が提供されます。つまり、Active Directory® サイト内に複数の HT サーバーを展開しており、その Active Directory サイト内の 1 台の HT サーバーが使用できない場合、メッセージの配信元の HT サーバーは、同じ Active Directory サイト内にある次の使用可能な HT サーバーに切り替わります。この処理は、ラウンドロビン DNS メカニズム (一覧内の最初の HT サーバーが応答しない場合は、次の HT サーバーにアクセスするメカニズム) を使用して行われます。

したがって、すべての HT 間の通信、およびメールボックスサーバーと HT との間 (つまり、組織内) の通信では、Exchange 2007 のネイティブ機能によって高可用性 (さらに言うと、負荷分散) が提供されます。ただし、メールボックスサーバーの役割が既にインストールされているコンピュータに HT サーバーの役割をインストールすると、Microsoft Exchange メール発信サービスによってメッセージが送信されるときに、メールボックスサーバーの役割によって、必ず Active Directory サイト内の他の HT サーバーよりも、ローカル HT サーバーが優先される (使用できるかどうかにかかわらず) ことに注意してください。

上記の情報は SharePoint サーバーの観点から見るとそれほど役立つものではありませんが、これ以降の説明を理解するうえでは重要です。HT サーバーでは、既定で高い回復力が提供されるので、ハードウェア負荷分散装置または Windows® ネットワーク負荷分散 (WNLB) 機能を使用して、Exchange 2007 の HT サーバー間で組織内通信の負荷を分散することはできません。

実際に、Exchange 2007 RTM では、HT サーバーへの受信 SMTP トラフィックの負荷を分散することはできませんでしたが、Exchange 2007 SP1 ではこの仕様が変更されています。SP1 でも、ハードウェア負荷分散装置や WNLB 機能を使用して組織内通信の負荷を分散することはできません (そのような操作は必要ないからです) が、Exchange 以外のサーバー (SharePoint サーバーなど) からの受信 SMTP トラフィック、および HT サーバー上で既定のクライアント受信コネクタを使用する Exchange 2007 組織にメッセージを送信する Exchange クライアント (IMAP クライアントや POP クライアントなど) からの受信 SMTP トラフィックの負荷を分散することができます。

このため、Exchange 2007 SP1 組織を経由してメッセージを中継するように SharePoint サーバーを構成するには、Active Directory DNS に DNS レコードを作成し、そのレコードにハードウェア負荷分散装置を指定して、複数の HT サーバー間でトラフィックを分散できるようにするか、WNLB 機能を使用するだけで済みます。WNLB 機能を使用するには、仮想 IP アドレスと FQDN (mail.contoso.com など) を指定して WNLB クラスタを構成し、[ポートの規則] タブでポート 25 (Exchange 以外のサーバーからの受信 SMTP トラフィック) とポート 587 (IMAP や POP などの Exchange クライアントからの受信 SMTP トラフィック) を追加します。図 2 は、このような構成を行った [ポートの規則] タブを示しています。特定の仮想 NLB クラスタの IP アドレスを両方の規則に割り当てると、複数の IP アドレスを選択する必要がなくなります。

図 2 定義済みのポートの規則 (画像をクリックすると拡大表示されます)

NLB クラスタが構成されている場合は、ポート 25 でリッスンする新しい受信コネクタを作成し、このコネクタを使用してメッセージを中継するサーバーからのトラフィックのみを許可する必要があります。また、このコネクタでは、既に作成した仮想 NLB クラスタの IP アドレスを使用するようにしてください。

質問 - Exchange Server 2007 を基盤とするメッセージングインフラストラクチャを使用しています。Exchange 2007 メールボックスサーバーが、ハードウェアとストレージの両方のレベルで冗長になるように、すべてのメールボックスサーバーをクラスタ連続レプリケーション (CCR) テクノロジに基づいてクラスタ化しています。各 CCR クラスタのアクティブノードとパッシブノードは、どちらも同じ物理データセンター内に配置されています。Exchange 2007 サーバーを SP1 にアップグレードしたので、サービスとデータの可用性を活用するために、Exchange 2007 SP1 に付属する新しいスタンバイ連続レプリケーション (SCR) テクノロジを使用して、2 つ目のサイトでメールボックスデータベースをメールボックスサーバーにレプリケートすることを考えています。

SCR ソースには、スタンドアロンの Exchange 2007 SP1 メールボックスサーバーか、CCR またはシングルコピークラスタ (SCC) テクノロジに基づいてクラスタ化されたメールボックスサーバー (CMS) を使用できることは知っていますが、SCR ターゲットにはどのサーバーを使用できるのでしょうか。

回答 - SCR ターゲットサーバー (別名 SCR エンドポイント) には、どのストレージグループのローカル連続レプリケーション (LCR) も有効になっていないスタンドアロンのメールボックスサーバーか、メールボックスサーバーの役割がインストールされた Windows フェールオーバークラスタ (旧称 Microsoft クラスタサーバー) 内のパッシブノードを使用する必要があります。つまり、フェールオーバークラスタを構成してから、そのフェールオーバークラスタ内のパッシブノードにメールボックスサーバーの役割をインストールすることはできますが、クラスタ化されたメールボックスサーバーを SCR ターゲットとして使用することはできません。

質問 - 組織のメッセージングプラットフォームとして Exchange 2007 を使用しています。また、境界ネットワーク内で使用している古いスパム対策ソリューションやウイルス対策ソリューションを、Forefront™ Security for Exchange がインストールされた Exchange 2007 エッジトランスポートサーバーに基づくソリューションに置き換えて、複数層のメッセージ保護とセキュリティからメリットを得ることを考えています。近いうちに、複数のエッジトランスポートサーバーを追加で展開することを計画しています。

そこで質問です。Exchange 2007 エッジトランスポートに基づくメッセージ検疫ソリューションへの受信 SMTP 接続の負荷を分散して、ソリューションを十分に冗長化するにはどうすればよいでしょうか。

回答 - 境界ネットワーク内のエッジトランスポートサーバーが、インターネットに接続されている SMTP サーバーである場合は、Microsoft Information Technology (Microsoft IT) グループで使用されているものと同様の手法を使用できます。Microsoft IT では、6 台のエッジトランスポートサーバー (レドモンドとシリコンバレーに各 3 台) を展開し、1 日あたり 1,600 万通を超える受信メッセージ (およびスパムとしてフィルタ処理される 1,300 万通を超えるメッセージ) を処理しています。

Microsoft IT では、Microsoft.com ドメインの MX (Mail Exchange) レコードを合計 3 つ保有しています。これらは、maila.microsoft.com、mailb.microsoft.com、および mailc.microsoft.com です (図 3 参照)。各 MX レコードの優先順位値には 10 が設定されているので、DNS ラウンドロビン技法を使用してランダムに MX レコードが選択されます。さらに、2 つの IP アドレス (メールホスト) が各 MX レコードに関連付けられています。

図 3 Microsoft.com の MX レコードとインターネットメールホスト (画像をクリックすると拡大表示されます)

各 MX レコードに 2 つの IP アドレスが関連付けられている理由は、ドメイン用に構成した MX レコードの数にかかわらず、一部のメッセージ転送エージェント (MTA) によって必ず同じ MX レコードが選択されるからです。この動作は、Exchange Server には長い間 (Exchange 2000 以降) 悪影響を与えていませんが、残念ながら、このような設計上の欠陥を抱えた MTA は現在でも使用されています。そのため、どの MTA から Microsoft.com アドレスにメッセージが配信されるかに関係なく、すべての SMTP 接続は、DNS ラウンドロビンと負荷分散の組み合わせを使用して分散されます。

質問 - Windows Server® 2003 ドメインコントローラ (DC) に基づく Active Directory ドメインを使用しています。現在、Windows Server 2003 DC を Windows Server 2008 に移行し、Exchange 2003 メッセージング環境を Exchange Server 2007 に移行することを計画しています。メッセージング環境を Exchange Server 2003 から Exchange 2007 に移行する前に、Windows Server 2003 を実行しているすべてのサーバーを Windows Server 2008 にアップグレードすることによって、Active Directory ドメインを Windows Server 2008 に移行することはできますか。

回答 - はい、できます。Exchange Server 2003 SP2 は、Windows Server 2008 DC のみで構成される Active Directory ドメインで完全にサポートされるので、そのまま計画を進めていただいて問題ありません。ただし、Windows Server 2008 読み取り専用ドメインコントローラ (RODC) を使用する場合は、RODC を使用するように Exchange 受信者更新サービス (RUS) を構成しないようにしてください。

Henrik Walther は、メッセージングに関するマイクロソフト認定アーキテクトの実習生 (apprentice 段階) および Exchange MVP で、IT ビジネスの分野において 14 年以上の経験があります。また、Interprise Consulting 社のテクノロジアーキテクト、および Biblioso Corporation のテクニカルライターも務めています。

その他のリソース