Exchange 2010 Active Manager

closeBu yazı 6 yıl 4 ay 12 gün önce yayınlanmış olduğundan güncelliğini yitirmiş veya içeriğindeki bilgilerin geçerliliği kaybolmuş olabilir. Herhangi bir yanlış anlaşılmadan bu site sorumlu değildir.

    Exchange Server 2007, Cluster Continous Replication yüksek erişilebilirliğin kurulumunu ve yönetimini Cluster kaynak yönetimi modelini kullanarak yapar. Bu nedenle önce Cluster kurulur ve ardından Exchange kurulumu yapılır. EXRES.DLL bu noktada cluster’a kaydedilir ve Clustered Mailbox Server (CMS) yaratılır. Tek bir node olsa bile cluster’ın önceden kurulması şarttır. Exchange Server 2010’da ise cluster bileşenleri artık gizlenmiş durumda. Exchange Server 2010 Active Manager bileşeni eski versiyonlarda olan kaynak modelinin ve fail-over yönetiminin yerini alıyor.

Not: Bütün bileşenler kaldırılmış değil bu nedenle Fail-Over Cluster Manager aracını açarsanız DAG ve Network kaynaklarını görebilirsiniz. DAG yapısına Fail-over Cluster Manager üzerinden müdahale etmeyin.

    İki farklı Active Manager rolü var. Bunlar Primary Active Manager (PAM) ve Standby Active Manager (SAM). PAM cluster quorum’a sahip olan Mailbox Server üzerinde çalışır ve hangi database’in aktif hangisinin pasif olması gerektiğine karar verir. SAM ise sunucunun sağlıklı çalışıp çalışmadığını veya database çökmesi durumlarını takip edip PAM’e bilgi vermekle sorumludur.
    Replication service de, mounted olan databaselerin durumunu ve ESE engine’de  I/O ile ilgili sorun veya hata olup olmadığını kontrol eder. Hata alınması durumunda replication service Active Manager’a bilgi verir. Bu durumda failover gerçekleşir. Active Manager hangi database kopyasının aktif edileceğine karar verir.

Not: Active Manager, DAG yapılandırmasında belirlenmiş olan fail-over sırası ile önceliklendirir. (ActivationPreference)

Active Manager, aktif duruma getirilecek database’i bazı kriterleri kontrol ederek bulur.

Active Manager, ilk olarak şu kriterlere uyan bir database var mı kontrol eder:

  • Content Index Healty durumda.
  • Copy Queue Length 20 log dosyasından az.
  • Replay Queue Length 50 log dosyasından az.

üstteki kriterler uymuyorsa şu kriterlere uyan bir database var mı kontrol eder:

  • Content Index Crawling durumunda.
  • Copy Queue Length 10 log dosyasından az.
  • Replay Queue Length 50 log dosyasından az.

üstteki kriterler uymuyorsa şu kriterlere uyan bir database var mı kontrol eder:

  • Content Index Healty durumda.
  • Replay Queue Length 50 log dosyasından az.

üstteki kriterler uymuyorsa şu kriterlere uyan bir database var mı kontrol eder:

  • Content Index Crawling durumunda.
  • Replay Queue Length 50 log dosyasından az.

üstteki kriterler uymuyorsa şu kriterlere uyan bir database var mı kontrol eder:

  • Replay Queue Length 50 log dosyasından az.

üstteki kriterler uymuyorsa şu kriterlere uyan bir database var mı kontrol eder:

  • Content Index Healty durumda.
  • Copy Queue Length 10 log dosyasından az.

üstteki kriterler uymuyorsa şu kriterlere uyan bir database var mı kontrol eder:

  • Content Index Crawling durumda.
  • Copy Queue Length 10 log dosyasından az.

üstteki kriterler uymuyorsa şu kriterlere uyan bir database var mı kontrol eder:

  • Content Index Healty durumda.

üstteki kriterler uymuyorsa şu kriterlere uyan bir database var mı kontrol eder:

  • Content Index Crawling durumda.

Sırasıyla kontrol edip uygun database var ise ActivationPreference değerinin en düşük olduğu database’i aktif hale getirmeye çalışır. Eğer hiçbir kritere uygun database bulamaz ise Healthy, DisconnectedAndHealthy, DisconnectedAndResynchronizing, veya SeedingSource durumunda bulunan databaselerden birini aktif hale getirmeye çalışır. Tekrar başarısız olması durumunda hiçbir database Active Manager tarafından aktif hale getirilemeyecektir.

Yayınlayan: Serkan Varoğlu

Yıldız Teknik Üniversitesi Elektrik Mühendisliğini bitirdim. Türkiye'de birçok farklı sektör ve firmada Sistem Yöneticiği yaptım. Bermudada 3 yıla yakın danışmanlık yaptıktan sonra şu anda İrlanda'da çalışma hayatıma devam ediyorum.