DAG

Exchange Server 2010のDAGのトランザクションログがDPM 2012でバックアップを実施しても消えない…という話を受けて、調査してみました。 調べた所以下のブログに非常に良い情報がありました。 - [Exchange 2010: Log Truncation and Checkpoint At Log Creation in a Database Availability Group - Tim McMichael - Site Home - TechNet Blogs](http://blogs.technet.com/b/timmcmic/archive/2012/03/12/exchange-2010-log-truncation-and-checkpoint-at-log-creation-in-a-database-availability-group.aspx) Exchange Server 2010 SP1以降挙動が変わっており、要点は以下とのことです。 - ログファイルを消しているのはバックアップソフトウェアではなくて、ExchangeのReplicationサービス - トランザクションログが作成されたタイミングのチェックポイントがログファイルに埋め込まれている - DAGのコピーノード毎にどこまでログの切り詰めをしていいか報告される - 一番わかい番号までログのきりつめを行えると判断されるが、実際には”checkpoint depth”の分だけは消さずに残しておく - 切り詰めされるのはきちんと増分バックアップされているファイルのみ - “Checkpoint at log creation time”はeseutil /ml <ログファイル名>”で確認できる 要は、きちんとバックアップが成功していても、チェックポイントとして100程度、実際のファイル数としてはそれ以上のログファイルが残っているのが正常だ、ということです。 今回の検証環境では200ファイル程度ログファイルが残っており、確かに最新のログと最古のログとでチェックポイントとして100の違いがありました。

Exchange Team BlogにてExchangeのDAGのWitnessのみをWindows Azure上に配置するという話題が有りました。結論は「まだサポートされない」ということで残念ですが、将来的にサポートされるようになりそうな感じですね。 - [Database Availability Groups and Windows Azure - Exchange Team Blog - Site Home - TechNet Blogs](http://blogs.technet.com/b/exchange/archive/2013/08/07/database-availability-groups-and-windows-azure.aspx) DAGにかぎらずですが、きちんとスプリットブレイン状態を防ぎ、稼働しているマシンで稼働させ続けるためにはどうしても3拠点が必要になります。本文中では以下のように書かれています。 You need two well-connected datacenters, in which Exchange is deployed You need a third location that is connected via the network to the other two datacenters The third location needs to be isolated from network failures that affect the other two datacenters 過半数が稼働し通信できていないといけないので、例えば2拠点でDAGを組もうと思っても、結局Witnessをどちらに置くか、という話になり、Witnessが配置された方の拠点がだめになればDAGとしては停止してしまうわけです。で3拠点目があればその問題は解決するのですが、ネットワーク的に完全に分離されていて、安定しているような拠点でできれば地理的にも離れている…というような都合の良い拠点をすぐに用意するのは難しいわけです。そこでAzure上に配置可能ならかなりメリットが出てくる…という話なのですが、まだ無理なようですね。 今後に期待したい所です。

前回の記事で見たように、Hyper-VクラスタのCSVに配置した仮想マシンはHA構成にするしか(サポートされる)選択肢がありません。 - [Hyper-Vクラスタの高可用性のオンオフと仮想ディスクの配置先の話。(高可用性にしないとCSVにディスクを配置できない) | WindowsServer管理者への道](https://windowsadmin.ebisuda.net/2013/06/12/hyper-v%e3%82%af%e3%83%a9%e3%82%b9%e3%82%bf%e3%81%ae%e9%ab%98%e5%8f%af%e7%94%a8%e6%80%a7%e3%81%ae%e3%82%aa%e3%83%b3%e3%82%aa%e3%83%95%e3%81%a8%e4%bb%ae%e6%83%b3%e3%83%87%e3%82%a3%e3%82%b9%e3%82%af/) きちんとCSVで共有するディスク領域と、個別のノードに配置するためのディスク領域を計算し、割り当ててあげればよいわけですが、個別に割り当てる…という話になるとどうしても容量に偏りが出たり、構成が複雑になったりなど少々気乗りしない感じです。全部HAにして良いのであればこういう苦労はしなくていいわけで、そういう構成が現実的に取れるのかどうか確認してみます。 まず、気になるのは製品自体でクラスタ構成を組むようなものです。 Hyper-VのHAとExchange Server 2010以降のDAGの組み合わせはExchange Server 2010 SP1以降ではサポートされるとのこと。 - [http://technet.microsoft.com/ja-jp/magazine/hh273004.aspx](http://technet.microsoft.com/ja-jp/magazine/hh273004.aspx) Exchange Server 2013もOKです。 Exchange サーバーの仮想マシン (データベース可用性グループつまり DAG の一部となっている Exchange メールボックス仮想マシンなど) は、移動されたりオフラインになったりしたときにディスクの状態を保存または復元しないように仮想マシンが構成されている限り、ホストベースのフェールオーバー クラスター化および移行テクノロジと組み合わせることが可能です。ハイパーバイザー レベルで発生するフェールオーバー動作はすべて、フェールオーバー先のノードで仮想マシンがアクティブになったときに、コールド ブートする必要があります。計画されたすべての移行は、シャットダウンしてコールド ブートするか、Hyper-V ライブ移行のような技術を利用したオンライン移行になる必要があります。仮想マシンのハイパーバイザー移行はハイパーバイザー ベンダーがサポートするため、ハイパーバイザー ベンダーが Exchange 仮想マシンの移行をテストしており、サポートすることを確認する必要があります。Microsoft は、これらの仮想マシンの Hyper-V ライブ移行をサポートしています。 Exchange 2013 の仮想化: Exchange 2013 Help http://technet.microsoft.com/ja-jp/library/jj619301(v=exchg.150).aspx その他は、できるけれどもやる必要ある？やらないほうが良くない？という情報が見つかります。 - Hyper-V2.0のホストクラスタとゲストクラスタの共存は可能でしょうか [http://social.technet.microsoft.com/Forums/ja-JP/hypervja/thread/907fedb7-c11e-49a2-bdbe-80d105c2b441/](http://social.technet.microsoft.com/Forums/ja-JP/hypervja/thread/907fedb7-c11e-49a2-bdbe-80d105c2b441/) 今回改めて調べるまでは私も上記のような認識だったのですが、そこよりはサポートする方向に年月がたって傾いてきている印象です。 NLBはどうでしょうか？…と思って結構頑張って調べたのですが、ズバリ言及している情報を見つけることができませんでした。私は30分ほど検索して見つからない場合には「無い」ものとして扱うことにしており、それ以上探すことはしません。Googleさんのインデックス能力はそれだけ高いと思っています。 一応以下の記事では高可用性のVMにNBLを追加で構成することのメリットに言及しているので、「あり」ということのように受け取れます。 NLB の機能によってフェールオーバー クラスターのノードになっている VM では、VM のメンテナンス中でもワークロードで高可用性が実現されます。VM で更新やなんらかのメンテナンスが必要な場合は、その VM のワークロードを同じホストの別の VM に転送したり、すべてを別のホストに転送したりすることができます。 仮想化: Hyper-V と高可用性 http://technet.microsoft.com/ja-jp/magazine/hh127064.aspx 動作しない理由も特にないので、普通に動作するものと思われます。テストして確認してみようと思います。 ...

Exchange Serverにてどのトランザクションログまでコミット済みかということはeseutilでチェックポイントファイルを確認することで可能ですが、「DAGでどこまでトランザクションログをコピーしたのか?」ということを確認する方法は調べても情報が見つかりません。適当に探してみたらそれらしいものがあったので記録しておきます。(情報の正確性は保証しません) いきなり答えですが、おそらくDAGのアクティブ側DBを保持しているサーバーの以下のパフォーマンスカウンタがそれを示していると思います。 - MSExchange Replication\CopyNotificationGenerationNumber - MSExchange Replication\CopyGenerationNumber - MSExchange Replication\InspectorGenerationNumber - MSExchange Replication\ReplayGenerationNumber - MSExchange Replication\ReplayNotificationGenerationNumber 検証環境で確認してみたところ、上記のカウンタがすべて24になっていました。すべて同じ数字でそろっているのは、検証環境で新しいトランザクションログが発生していないからだと思われます。 最後に複製されているトランザクションログのファイル名は「E0200000018」となっており、16進数の0x18は10進数の24なのでビンゴだと思われます。 さらに、このカウンタはアクティブなDatabaseを持っているサーバーでのみ値が確認できました。アクティブ側のみで数字を把握しているようです。 そもそも論としては「こんなこと知ってどうするの?普通にトランザクションログ自体を確認すればわかるじゃない」という感じではあるのですが、手動でDB自体やトランザクションログをごねごねしたり、シード処理を自動で行わせずに無理やりやりたいようなケースで確認したいという話があったので調べてみました。本当はそういう変なことはせずに、きちんと普通のオペレーションでできるように環境をつくったり、スケジュールを立てたりするのがいいんですけどね…。

Exchange ServerのDatabaseに対しては、バックアップが正常に動作していなかった時にトランザクションログが貯まりすぎてしまったような場合にコミット済みのログを調べ、それを手動で退避あるいは削除するというオペレーションをよく行っていました。 [XADM] Eseutil を使用してコミット済みのログを特定する Exchange Server 2010のDAGでDatabase Copyが構成されているDatabaseの場合、このあたりの操作はどのように行えるのか、行えないのか、情報を調べてもほとんどみつからないので実際の動作を確認してみることにしました。(正確性は保証しません。「私の環境ではこのように動いた」以上でも以下でもありません。) ちなみにテストしている環境はExchange Server 2010 SP2の環境です。 同期している状態 上記はコピーを開始した直後で、両者の保持しているログに差異が無い状態です。 この状態から、大きめの添付ファイルをDatabaseに存在しているユーザーに送信し、トランザクションログを発生させます。 この操作の結果、以下のようにE0200000006～E020000000Eまでのファイルが生成され、同時に、アクティブからパッシブにコピーされました。 ここでActive側のDatabaseにて、コミット済みのトランザクションログを調べ、コミット済みのログファイルを削除してみます。 「eseutil /mk」にて0x5のファイルまでコミット済みであることがわかりました。 すでにコミット済みであるファイルをActive側で手動で削除してみます。 結果、特に何の問題もなくファイルは消え、その後特にエラーも何も表示されることなく通常通り使えています。Aassive側のDatabase側にトランザクションログが削除されたという情報が伝わっている様子もありません。20分ほど時間をおいてみましたが、そのままでした。 次に、Passive側でもコミット済みであることを確認したうえで、Active側で削除したトランザクションログファイルを手動削除してみます。 この操作後も、特段何の反応もなく、正常稼働を続けています。DAGでコピーを構成したとしてもすでに処理の終わったトランザクションログに関しては取り立てて何も監視、処理はしていないという事になると思います。トランザクションログファイル自体は環境によっては大量に生成されるでしょうし、それをすべて監視するようなことはリソースの無駄になると思われますので妥当な動きだと思います。 確認のために先にPassive側を削除し、その後Active側を削除…というパターンもやってみましたが挙動は変化ありませんでした。 緊急時の対応としては、単純にコミット済みのトランザクションログの退避あるいは削除が手段として使えそうです。

最近はメールシステムが大容量化、重要化したり、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私は単純化して以下のように理解しました。(はしょり過ぎかもしれませんが……) ...

Exchange Server 関連の記事はExchange Server Blogにまとめて書くことにしました。よろしければあわせて御覧ください。 Exchange Serverにてどのトランザクションログまでコミット済みかということはeseutilでチェックポイントファイルを確認することで可能ですが、「DAGでどこまでトランザクションログをコピーしたのか?」ということを確認する方法は調べても情報が見つかりません。適当に探してみたらそれらしいものがあったので記録しておきます。(情報の正確性は保証しません) いきなり答えですが、おそらくDAGのアクティブ側DBを保持しているサーバーの以下のパフォーマンスカウンタがそれを示していると思います。 - MSExchange Replication\CopyNotificationGenerationNumber - MSExchange Replication\CopyGenerationNumber - MSExchange Replication\InspectorGenerationNumber - MSExchange Replication\ReplayGenerationNumber - MSExchange Replication\ReplayNotificationGenerationNumber 検証環境で確認してみたところ、上記のカウンタがすべて24になっていました。すべて同じ数字でそろっているのは、検証環境で新しいトランザクションログが発生していないからだと思われます。 最後に複製されているトランザクションログのファイル名は「E0200000018」となっており、16進数の0x18は10進数の24なのでビンゴだと思われます。 さらに、このカウンタはアクティブなDatabaseを持っているサーバーでのみ値が確認できました。アクティブ側のみで数字を把握しているようです。 そもそも論としては「こんなこと知ってどうするの?普通にトランザクションログ自体を確認すればわかるじゃない」という感じではあるのですが、手動でDB自体やトランザクションログをごねごねしたり、シード処理を自動で行わせずに無理やりやりたいようなケースで確認したいという話があったので調べてみました。本当はそういう変なことはせずに、きちんと普通のオペレーションでできるように環境をつくったり、スケジュールを立てたりするのがいいんですけどね…。

Exchange Server 関連の記事はExchange Server Blogにまとめて書くことにしました。よろしければあわせて御覧ください。 Exchange ServerのDatabaseに対しては、バックアップが正常に動作していなかった時にトランザクションログが貯まりすぎてしまったような場合にコミット済みのログを調べ、それを手動で退避あるいは削除するというオペレーションをよく行っていました。 [XADM] Eseutil を使用してコミット済みのログを特定する Exchange Server 2010のDAGでDatabase Copyが構成されているDatabaseの場合、このあたりの操作はどのように行えるのか、行えないのか、情報を調べてもほとんどみつからないので実際の動作を確認してみることにしました。(正確性は保証しません。「私の環境ではこのように動いた」以上でも以下でもありません。) ちなみにテストしている環境はExchange Server 2010 SP2の環境です。 同期している状態 上記はコピーを開始した直後で、両者の保持しているログに差異が無い状態です。 この状態から、大きめの添付ファイルをDatabaseに存在しているユーザーに送信し、トランザクションログを発生させます。 この操作の結果、以下のようにE0200000006～E020000000Eまでのファイルが生成され、同時に、アクティブからパッシブにコピーされました。 ここでActive側のDatabaseにて、コミット済みのトランザクションログを調べ、コミット済みのログファイルを削除してみます。 「eseutil /mk」にて0x5のファイルまでコミット済みであることがわかりました。 すでにコミット済みであるファイルをActive側で手動で削除してみます。 結果、特に何の問題もなくファイルは消え、その後特にエラーも何も表示されることなく通常通り使えています。Aassive側のDatabase側にトランザクションログが削除されたという情報が伝わっている様子もありません。20分ほど時間をおいてみましたが、そのままでした。 次に、Passive側でもコミット済みであることを確認したうえで、Active側で削除したトランザクションログファイルを手動削除してみます。 この操作後も、特段何の反応もなく、正常稼働を続けています。DAGでコピーを構成したとしてもすでに処理の終わったトランザクションログに関しては取り立てて何も監視、処理はしていないという事になると思います。トランザクションログファイル自体は環境によっては大量に生成されるでしょうし、それをすべて監視するようなことはリソースの無駄になると思われますので妥当な動きだと思います。 確認のために先にPassive側を削除し、その後Active側を削除…というパターンもやってみましたが挙動は変化ありませんでした。 緊急時の対応としては、単純にコミット済みのトランザクションログの退避あるいは削除が手段として使えそうです。

最近はメールシステムが大容量化、重要化したり、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を伝える必要等も発生するのでその点からも確認が必要です。 ...