CAS

MSExchange.orgにてExchange Server 2013の負荷分散についての記事が公開されていました。 Introducing Load Balancing in Exchange Server 2013 (Part 1) :: High Availability & Recovery :: Exchange 2013 Articles :: Articles & Tutorials :: MSExchange.org 要点は以下です。 - 2013のCASはただのReverse Proxyでありユーザーの存在するMailboxにトラフィックを届ける - OWAのレンダリングもCASではなくMBXで行う - OutlookからもMAPIではなくRPC over HTTPS - CASへのHTTPSだけ考えればいい - どのCASにパケットが到達しても問題無い。フォームベース認証の問題はHTTPのクッキーではなくSSLのセッションIDで解決されており、CAS毎に再認証は必要ない。 - CASはすべて同じ証明書を利用する。 - ハードウェアロードバランサーを使わず、DNSラウンドロビンでも冗長化が行える。 - ただし、DNSラウンドロビンには欠点もある。 きれいに負荷分散されず負荷は偏る。 - 何かCASにエラーが起きていてもアクセスし続ける。(これはNLBも同じ) - ハードウェアロードバランサーを使う場合でもExchange2010のようにレイヤー7ではなく、レイヤー4で負荷分散できれば十分。 - 1つのVIPでは特定のサービスだけの障害時でも全部のサービスの切り替えになってしまう。手間を掛けるならサービス毎にVIPを作成しサービス毎に振り分けることも考えられる。 Exchange Server2013は2010までに比べて随分とシンプルになりましたね。冗長化さえできてしまえば良い…というケースではDNSラウンドロビンでもそれを実現できるというのはなるべくコストを掛けたくないお客様にとっては随分と素敵な事に思えます。ハードウェアロードバランサーは安いものもあるとはいえ、やはり構成し、トラブルを解決し…というあたりでかなり手間がかかりますからね。

Exchange 2010を仮想化し役割を統合することについて以下で書かれています。(英語) - [Exchange Server and Active Directory Blog: Exchange 2010 Virtualization and Combining Server Roles ?](http://smtp25.blogspot.jp/2013/01/exchange-2010-virtualization-and.html) 要約は以下です。 - 仮想化によって様々な利益が得られる - HUB, CASを1台に、MBXを1台にというのがよく見られる構成だが、HUB, CAS, MBXを1台にまとめることができれば台数は半分に減らせる。**この構成はMicrosoftにサポートされている**。 [Announcing Enhanced Hardware Virtualization Support for Exchange 2010 - Exchange Team Blog - Site Home - TechNet Blogs](http://blogs.technet.com/b/exchange/archive/2011/05/16/announcing-enhanced-hardware-virtualization-support-for-exchange-2010.aspx) ただし、この構成ではDAGはFailOverClusterを使っており、Fail Over Clusterが機能している状態でのNLBはサポート外なので、ハードウェアロードバランサーは必須になります。実際に私の知っているある程度大規模な顧客でも３つのロールを共存させた構成で正常に稼働しており、悪くない構成であると思います。 以下のExchange Teamのブログエントリではかなりこの構成をおすすめしています。 - [Robert’s Rules of Exchange: Multi-Role Servers - Exchange Team Blog - Site Home - TechNet Blogs](http://blogs.technet.com/b/exchange/archive/2011/04/08/robert-s-rules-of-exchange-multi-role-servers.aspx) HUB, CASが同居、MBXは別サーバーという構成はExchange Server 2007の時にはMBXを冗長化した上で他のロールと共存できなかったのでよくありましたが、2010以降では３ロール共存をまず検討してよさそうです。 ...

最近はメールシステムが大容量化、重要化したり、Exchange Serverがソフトレベルで標準でDR(Disaster Recovery = 災害対策)の仕組みを備えているなどの事情があり、DRサイトを構築する機会が増えてきました。また、やはり震災の影響も大きいですね、本格的にDRサイトを構築するのが当たり前の時代になってきたように思います。 Exchange Server 2003のころは標準でDRの仕組みを持たなかったり、Exchange Serverが存在するサイトのGCをOutlookが使いだしてしまうこともあってExchange Server専用のサイトを作成し、その中にExchangeとExchange用のGC(DC)を配置することが多かったのですが、ずいぶんと時代は変わったものです。 さて、Exchange Server 2010でDRサイトを構築するとなるとたいていの場合Exchange ServerをActive Directoryの複数サイトにまたがって構築することになります。そうするとシングルサイトで構成していたときにはあまり考えなくても良かった考慮点が色々と出てきます。 その中から今回は2点取り上げて記録しておきたいと思います。(最近質問されて調べたのでまとめておきます) サイトをまたいだCAS ArrayとDAGの接続について CASはMBXを配置するサイト内に必ず1つは必要です。またCAS Arrayはサイト内に1つしか作成できません。なので本番サイトとDRサイトにそれぞれ1つずつCAS Arrayが作成されるのはほぼ自動的に決まります。 一方、DAGに関しては、素直に設計するなら本番サイトとDRサイトにまたがって構築されることが多いだろうと思います。データもコピーしたいし、フェールオーバーしたいですし。 この時、Outlookの接続しているCASのサイトと、DAGのアクティブノードが別サイトになったときにどのような挙動になるでしょうか？DAGのみ問題が起きてフェールオーバーした場合やクライアントが意図せず別サイトにアクセスしているケース、本番サイトからDRサイトへの切り替え、切り戻しの際の一時的な状況等で発生する可能性がある状況です。 調べたところ以下の事が分かりました。Exchange 2010 SP2 RU3で挙動が変更になっています。 Exchange 2010 SP2RU2及びそれ以前 CASは自分の存在するサイト、DAGのアクティブサーバーの存在するサイトを意識しません。 クライアントはちゃんとアクセスできていれば、Autodiscoverの値が変わってても無視します。 結果、CASとMBXの間がサイトまたぎのアクセスになってもそのままつながります。(つながっちゃいますの方が表現として正確かもしれません。) - Exchange 2010 SP2RU3以降 DAGのプロパティーのAllowCrossSiteRPCClientAccessが使えるようになります。規定の値は$falseです。 AllowCrossSiteRPCClientAccessが$trueの場合(あえて設定変更した場合)以前のバージョンと同じ動きになります。 AllowCrossSiteRPCClientAccessが$falseの場合、CASは違うサイトのMBXへのアクセスに関してはクライアントに「サイト間違ってるよ。正しいCASArrayはあっち」と教えます。 クライアントは教えられたらきちんとプロファイルを更新します。 このことやこの周辺のことは以下のブログで解説されています。 RPC Client Access Cross-Site Connectivity Changes - Exchange Team Blog - Site Home - TechNet Blogs ### ### ### ### サイトをまたいだOWAのアクセスについて OWAとMBXの関係についても同様に考慮が必要です。OWAの場合にはユーザーがサイトをまたいでメールボックスを移動したとき等に一番効率的なOWAを伝える必要等も発生するのでその点からも確認が必要です。 こちらもSP2で挙動が変化できるようになっています。 OWAに関してはExchangeのバージョンまたぎの問題や、External URLが指定されている、されていない、IISの仮想ディレクトリの認証モードによって挙動が異なるなど様々な要因によって挙動が変化します。詳細は以下のブログで解説されているので確認してみてください。 OWA Cross-Site Silent Redirection in Exchange 2010 SP2 - Exchange Team Blog - Site Home - TechNet Blogs私は単純化して以下のように理解しました。(はしょり過ぎかもしれませんが……) ...

CassArrayは必ず作成すべし Exchange Server 2010では、OutlookクライアントからのMAPIアクセスに対してCasへのアクセスポイントを集約するための仕組みとしてCasArrayが存在します。それをコントロールするRPCClientAccessServerという属性がデータベースに存在します。この動きを理解していないと思わぬ落とし穴にはまる可能性があります。 基本的にCasArrayは2台以上のCASサーバーがサイト内に存在している場合にOutlookの接続先を指定するもので、接続先を単一の名前にすることで冗長化することを可能にしています(冗長化の仕組み自体はCasArrayは提供しないので、別途HWロードバランサー、SWロードバランサー、NLBなどで冗長化の仕組みを構築する必要があります)。サイト内に1台しかCASサーバーが存在しない場合には特にCASArrayを作成する必然性はありません。・・・が、実はその場合でもCasArrayを作成しておいたほうが良いです。つまり、どんな場合でも例外なくCasArrayを作成しておき、そこに対して接続させるように構成すべきなのです。このことは以下のドキュメントにも明記されています。 - [RPC クライアント アクセスについて: Exchange 2010 のヘルプ](http://technet.microsoft.com/ja-JP/library/ee332317.aspx) **クライアント アクセス サーバー アレイは、組織内に 1 つのクライアント アクセス サーバーしかない場合でも作成することをお推めします。**クライアント アクセス サーバー アレイが作成されると、クライアントは、クライアント アクセス サーバーの完全修飾ドメイン名 (FQDN) に直接ではなく、クライアント アクセス サーバー アレイの仮想名によって接続します。1 つのクライアント アクセス サーバーを Active Directory サイト内部で置き換える必要があるか、2 つめのクライアント アクセス サーバーを追加する場合、クライアント上でプロファイル更新は必要ありません。 つまり、一度プロファイルが作成されてしまうとCASの実ノードへのアクセスがクライアントに記憶されてしまい、その後CasArrayを使う構成にしたりCasを切り替えたりする場合にプロファイルの更新がクライアント側で必要になってしまう危険性があるのです。サーバー側で管理者が操作するだけで変更できるならともかく、クライアント側で個別に作業が発生してしまうのは管理者にとって悪夢です。しかもそれが自動化しづらいものとなると・・・。事前の準備が肝心です。 構築時の注意点 構築時にはいくつか注意点があります。知っていないと思わぬ挙動に頭を悩ませることになる危険性があります。 まず新しくCasArrayを作成するのは簡単です。 - New-ClientAccessArray Name "CAS Array" Fqdn "casarray.test.local" Site "SiteName" これでおしまい…ではないことに注意が必要です。Cas Arrayが作成されても自動的にそれが使われるようにはならないのです。きちんとDatabaseに対してCassArrayを使用するように設定を行う必要があります。具体的にはMailboxDatabaseのRpcClientAccessServer属性をCassArrayのFQDNにする必要があります。 - Set-MailboxDatabase DB1 -RpcClientAccessServer "casarray.test.local" この指定を忘れていると「CasArrayを構成しているのにCASが1台落ちたらクライアントがつながらなくなってしまった」というトラブルが発生します。しかもその時に全部のクライアントが同じ挙動になるのではなく、正常に接続できるOutlookクライアントもあれば、正常に接続できないOutlookクライアントもある・・・という状況になってしまうはずです。なぜかというと、MailboxDatabaseのRpcClientAccessServer属性は以下のように決定、設定されるからです。 - サイト内にCasArrayが存在する場合 → CasArrayが設定される - サイト内にCasArrayが存在しない場合 → MBXとCASが同居している場合 → サーバー自身が設定される - サイト内にCasArrayが存在しない場合 → MBXとCASが同居していない場合 → サイト内のCASからランダムに選ばれ設定される つまり、CasArray作成前に先行的にMailboxDBが作成され、Outlookプロファイルが作成されるとそのクライアントはCASの実ノードに接続されてしまうのです。その後CasArrayの構成を正しくやり直すと、そのあとで作られたOutlookプロファイルはCasArrayにきちんと向きますが、それ以前のものは自動では変更されません。 ...

最近はメールシステムが大容量化、重要化したり、Exchange Serverがソフトレベルで標準でDR(Disaster Recovery = 災害対策)の仕組みを備えているなどの事情があり、DRサイトを構築する機会が増えてきました。また、やはり震災の影響も大きいですね、本格的にDRサイトを構築するのが当たり前の時代になってきたように思います。 Exchange Server 2003のころは標準でDRの仕組みを持たなかったり、Exchange Serverが存在するサイトのGCをOutlookが使いだしてしまうこともあってExchange Server専用のサイトを作成し、その中にExchangeとExchange用のGC(DC)を配置することが多かったのですが、ずいぶんと時代は変わったものです。 さて、Exchange Server 2010でDRサイトを構築するとなるとたいていの場合Exchange ServerをActive Directoryの複数サイトにまたがって構築することになります。そうするとシングルサイトで構成していたときにはあまり考えなくても良かった考慮点が色々と出てきます。 その中から今回は2点取り上げて記録しておきたいと思います。(最近質問されて調べたのでまとめておきます) サイトをまたいだCAS ArrayとDAGの接続について CASはMBXを配置するサイト内に必ず1つは必要です。またCAS Arrayはサイト内に1つしか作成できません。なので本番サイトとDRサイトにそれぞれ1つずつCAS Arrayが作成されるのはほぼ自動的に決まります。 一方、DAGに関しては、素直に設計するなら本番サイトとDRサイトにまたがって構築されることが多いだろうと思います。データもコピーしたいし、フェールオーバーしたいですし。 この時、Outlookの接続しているCASのサイトと、DAGのアクティブノードが別サイトになったときにどのような挙動になるでしょうか？DAGのみ問題が起きてフェールオーバーした場合やクライアントが意図せず別サイトにアクセスしているケース、本番サイトからDRサイトへの切り替え、切り戻しの際の一時的な状況等で発生する可能性がある状況です。 調べたところ以下の事が分かりました。Exchange 2010 SP2 RU3で挙動が変更になっています。 - Exchange 2010 SP2RU2及びそれ以前 CASは自分の存在するサイト、DAGのアクティブサーバーの存在するサイトを意識しません。 - クライアントはちゃんとアクセスできていれば、Autodiscoverの値が変わってても無視します。 - 結果、CASとMBXの間がサイトまたぎのアクセスになってもそのままつながります。(つながっちゃいますの方が表現として正確かもしれません。) - Exchange 2010 SP2RU3以降 DAGのプロパティーのAllowCrossSiteRPCClientAccessが使えるようになります。規定の値は$falseです。 - AllowCrossSiteRPCClientAccessが$trueの場合(あえて設定変更した場合)以前のバージョンと同じ動きになります。 - AllowCrossSiteRPCClientAccessが$falseの場合、CASは違うサイトのMBXへのアクセスに関してはクライアントに「サイト間違ってるよ。正しいCASArrayはあっち」と教えます。 - クライアントは教えられたらきちんとプロファイルを更新します。 このことやこの周辺のことは以下のブログで解説されています。 RPC Client Access Cross-Site Connectivity Changes - Exchange Team Blog - Site Home - TechNet Blogs サイトをまたいだOWAのアクセスについて OWAとMBXの関係についても同様に考慮が必要です。OWAの場合にはユーザーがサイトをまたいでメールボックスを移動したとき等に一番効率的なOWAを伝える必要等も発生するのでその点からも確認が必要です。 ...

CassArrayは必ず作成すべし Exchange Server 2010では、OutlookクライアントからのMAPIアクセスに対してCasへのアクセスポイントを集約するための仕組みとしてCasArrayが存在します。それをコントロールするRPCClientAccessServerという属性がデータベースに存在します。この動きを理解していないと思わぬ落とし穴にはまる可能性があります。 基本的にCasArrayは2台以上のCASサーバーがサイト内に存在している場合にOutlookの接続先を指定するもので、接続先を単一の名前にすることで冗長化することを可能にしています(冗長化の仕組み自体はCasArrayは提供しないので、別途HWロードバランサー、SWロードバランサー、NLBなどで冗長化の仕組みを構築する必要があります)。サイト内に1台しかCASサーバーが存在しない場合には特にCASArrayを作成する必然性はありません。・・・が、実はその場合でもCasArrayを作成しておいたほうが良いです。つまり、どんな場合でも例外なくCasArrayを作成しておき、そこに対して接続させるように構成すべきなのです。このことは以下のドキュメントにも明記されています。 - [RPC クライアント アクセスについて: Exchange 2010 のヘルプ](http://technet.microsoft.com/ja-JP/library/ee332317.aspx) **クライアント アクセス サーバー アレイは、組織内に 1 つのクライアント アクセス サーバーしかない場合でも作成することをお推めします。**クライアント アクセス サーバー アレイが作成されると、クライアントは、クライアント アクセス サーバーの完全修飾ドメイン名 (FQDN) に直接ではなく、クライアント アクセス サーバー アレイの仮想名によって接続します。1 つのクライアント アクセス サーバーを Active Directory サイト内部で置き換える必要があるか、2 つめのクライアント アクセス サーバーを追加する場合、クライアント上でプロファイル更新は必要ありません。 つまり、一度プロファイルが作成されてしまうとCASの実ノードへのアクセスがクライアントに記憶されてしまい、その後CasArrayを使う構成にしたりCasを切り替えたりする場合にプロファイルの更新がクライアント側で必要になってしまう危険性があるのです。サーバー側で管理者が操作するだけで変更できるならともかく、クライアント側で個別に作業が発生してしまうのは管理者にとって悪夢です。しかもそれが自動化しづらいものとなると・・・。事前の準備が肝心です。 構築時の注意点 構築時にはいくつか注意点があります。知っていないと思わぬ挙動に頭を悩ませることになる危険性があります。 まず新しくCasArrayを作成するのは簡単です。 - New-ClientAccessArray Name "CAS Array" Fqdn "casarray.test.local" Site "SiteName" これでおしまい…ではないことに注意が必要です。Cas Arrayが作成されても自動的にそれが使われるようにはならないのです。きちんとDatabaseに対してCassArrayを使用するように設定を行う必要があります。具体的にはMailboxDatabaseのRpcClientAccessServer属性をCassArrayのFQDNにする必要があります。 - Set-MailboxDatabase DB1 -RpcClientAccessServer "casarray.test.local" この指定を忘れていると「CasArrayを構成しているのにCASが1台落ちたらクライアントがつながらなくなってしまった」というトラブルが発生します。しかもその時に全部のクライアントが同じ挙動になるのではなく、正常に接続できるOutlookクライアントもあれば、正常に接続できないOutlookクライアントもある・・・という状況になってしまうはずです。なぜかというと、MailboxDatabaseのRpcClientAccessServer属性は以下のように決定、設定されるからです。 - サイト内にCasArrayが存在する場合 → CasArrayが設定される - サイト内にCasArrayが存在しない場合 → MBXとCASが同居している場合 → サーバー自身が設定される - サイト内にCasArrayが存在しない場合 → MBXとCASが同居していない場合 → サイト内のCASからランダムに選ばれ設定される つまり、CasArray作成前に先行的にMailboxDBが作成され、Outlookプロファイルが作成されるとそのクライアントはCASの実ノードに接続されてしまうのです。その後CasArrayの構成を正しくやり直すと、そのあとで作られたOutlookプロファイルはCasArrayにきちんと向きますが、それ以前のものは自動では変更されません。 ...