2013年のDAGは、他のサーバー上のDBをいくらか恣意的にアクティブ化し、それらがアクティブだったサーバーから移動するようです。メトリックを見ると、RAM/IO /ネットワークなどに目立ったスパイクはなかったので、なぜ移動しているのかわかりません。
データベースが移動する理由を監査する方法が見つからず、このトラブルシューティングに役立つ可能性のあるログファイルまたはPowerShellコマンドレットを探しています。
明確にするために、物事を大幅に単純化します。サーバー1にはDB1がアクティブですサーバー2にはDB2がアクティブですサーバー3にはDB3がアクティブです
各サーバーには、他の2つのデータベースのパッシブコピーがあります。一晩、明白な理由もなく、物事は動き、次のようになります。
サーバー1にはDB1とDB3がアクティブですサーバー2にはDBがアクティブではありませんサーバー3にはDB2がアクティブです
助けてくれてありがとう!
PS:誰かがこれに対処していて、いくつかの機能(つまり自動フェイルオーバー)が失われたときにそれを停止したい場合は、自動フェイルオーバーを停止したい各サーバーで次のポリシーを使用することを検討してください。
Set-MailboxServer -Identity EXSRV01 -DatabaseCopyAutoActivationPolicy Blocked
EXSRV01は、自動アクティブ化を停止するExchangeサーバーの名前に置き換えられます。
より完全な答えを得るためにコメントに追加します。クラスタリングに関するmfinniの応答に基づいて構築すると、データベースがフェイルオーバーすると常にエラーが発生します。エラーに対するExchangeのデフォルトの反応は、データベースをフェイルオーバーして、スプリットブレインシナリオ(両方のデータベースがアクティブであると考え、人道に対する罪を引き起こしている)から保護することです。
完全に妥当なCPU /メモリを使用でき、ネットワークのブリップはないように見えますが、MSFTクラスタリングでは、さまざまな理由で障害が発生します。クラスタリングで問題があると判断した場合は、クラスタリングサービスを再起動して、すべてが機能していることを確認するという素晴らしい仕事をします。その場合、Exchangeはすべてのデータベースをフェイルオーバーします。これは、次のような多くの問題が原因で発生する可能性があります。
イベントビューアのログをクラスタリングすると、「障害」が発生した時刻がわかります。これを高可用性イベントビューアのログと関連付けて、問題が発生したのか、突然のイベントであったのかを判断できます。データベース自体が、一部の部門が制御不能なcronジョブによって引き起こされたいくつかのメール爆弾に追いつくのに忙しすぎて、トランザクションログがデータベースヘルスのレプリケーションしきい値制限を超えてしまったところを見てきました...ブーム。 ..フェイルオーバー。
これらのログに何かが見つかった場合は、それを投稿してください(機密データをスクラブしてください)。また、すべてのExchangeサーバーで最新のパッチが適用されていることを確認してください。理由もなく同様の問題を引き起こしたCUアップデートがいくつかありました。
これらがVMであり、バックアッププロセスにVmwareスナップショットの取得が含まれる場合、許可されたDAGハートビートでタイムアウトになる可能性があります。 SameSubnetおよびCrossSubnetの遅延としきい値をデフォルトよりも高く設定する必要があります。
cluster /prop SameSubnetDelay=2000:DWORD cluster /prop CrossSubnetDelay=4000:DWORD cluster /prop CrossSubnetThreshold=10:DWORD cluster /prop SameSubnetThreshold=10:DWORD