Exchange Server 2010 sürümünden beri son derece başarılı bir şekilde çalışan DAG mimarisi sayesinde kesintisiz bir mail sistemi deneyimi sunmaktadır. Aslen 2007 sürümünde temelleri atılan ancak 2010 sürümü ile ideal yapıya kavuşan DAG yani temelde log replikasyonu sayesinde mailbox sunucuları arasındaki eşitleme özelliği sayesinde olası bir sorunda posta kutusu seviyesinde herhangi bir kesinti olmadan kullanıcılarımız mailerine ulaşmaya devam edebilmektedir.
Ancak her yeni sürüm hatta CU güncellemesi ile DAG üzerinde birtakım iyileştirmelerin yapıldığını da görüyoruz. Aslında bunlar küçük iyileştirmeler olsa bile son derece önemli sonuçlar doğurabiliyor. Bende bu makalemde aslında Exchange Server 2019’ un çıktığı şu dönemde Exchange Server 2016 CU2 ile gelen yeni bir özelliği yazmak istedim. Peki nedir bu yeni özellik ve neden şimdi yazma ihtiyacı duydum?
Öncelikle değişim aslında DAG mimarisi içerisindeki Activation Preference olarak isimlendirdiğimiz pasif kopyalar için öncelik sırası olarak da özetleyebileceğimiz bir mekanizmanın “PreferenceMoveFrequency” olarak isimlendirilen yeni bir özellikle güçlendirilmesidir. DAG mimarisini bilen ve kullanan sistem yöneticilerinin tecrübe ettiği gibi aslında Activation Preference çok kritik bir değer olup hangi veri tabanının öncelikle hangi sunucu üzerinde aktif olacağını seçebiliyoruz, bu sayede olası bir yama yükleme, sunucu kapatma açma veya felaket sonrasında sistem planladığımız tasarıma göre yük dağılımını gerçekleştirebilecektir. Ancak genel sorun Türkiye başta olmak üzere pek çok yapıda Exchange Server DAG mimarisi aynı site içerisinde 2 sunucu ile kurulmaktadır. Yani 1000 üstü kullanıcı bile olsa daha güçlü iki makine ile tüm posta kutularına hizmet verebilmekteyiz. Tabiki banka, Telekom, gsm veya büyük şirketlerde kullanıcı sayıları 5000, 10.000, 30.000 şeklinde arttıkça mimari büyüyor. Ancak zaten o boyuttaki şirketlere genelde bizim gibi üst seviye yapılarda danışmanlık yapmış insanlar destek verdiği için makalenin konusu olan özelliği biz bu CU güncellemesine kadar zamanlanmış görevler ile elle yapıyorduk. Yani bir nevi büyük yapılar zaten başının çaresine bakıyordu.
Sorun neydi peki?
Basit olarak iki sunucu kurdunuz ve 5 tane veri tabanı açtınız, açma sıranıza göre zaten sunucu1 hepsi için aktif sunucu2 ise hepsi için pasif yani öncelik numarası 2 olarak belirlenmektedir.
Örnek bir veri tabanı aktif kopyasında öncelik sıralaması 1 dir.
Bunun kopyasında ise bu numara 2
Başka seçeneğin olmamasının sebebi ortamda 3. Bir mailbox sunucusu yoktur. Sorun nerede ortaya çıkıyor? Örneğin 5 veri tabanının 3 tanesini ilk sunucuya 2 tanesini ikinci sunucuya attınız güzel güzel aktif – aktif çalışıyorsunuz ancak birinde bir kesinti oldu, yama yüklendi veya restart oldu, tüm DB ler nereye geçer? Kalan aktif sunucuya peki ondan sonra ne olur bir daha ki kesinti veya sizin elle müdahalenize kadar o sunucuda çalışmaya devam eder. İşte tam bu noktada ben devreye giriyordum ve müşterilerimizin sahip oldukları tüm bilgisayar ve depolama gücünü daha doğru kullanması için zamanlanmış görev üzerinde her gece 22:00 de PS çalıştırıyordum, bu PS ne yapıyordu peki? Tüm DB leri tekrar sunucuların arasında dağıtıyordu. Microsoft da bunu bildiği için aslında Exchange 2016 CU2 sonrasında artık bu işi otomatik yapan bir özellik ekledi ve ismine de “PreferenceMoveFrequency” dedi. Tabiki burada yine Activation Preference önemli, yani onu mutlaka istediğiniz gibi bir kereye mahsus düzenlemeniz gerekli, daha sonra eğer bu özelliği aktifleştirirseniz her saat başı bu dağıtımı herhangi bir kesinti olmadan Exchange server’ ın kendisi yapacaktır. Kesinti olmaması için tabiki database kopyalarının kontrolü sonucunda bu taşıma gerçekleşecektir. Eğer isterseniz bu özellik için saat aralığını değiştirebilir veya kapatabilirsiniz.
Bu özellik ne yazık ki Exchange Server 2013 üzerinde yoktur.
Peki nasıl yapılandırıyoruz;
Öncelikle bu özelliği kullanmak için ortamınızda minimum Exchange Server 2016 CU2 ve üstü bir sürüm olmalıdır.
Daha sonra PS ile başlayabiliriz;
Eğer CU2 geçilmiş ise durumun yukarıdaki gibi olduğunu görebilirsiniz. Yani varsayılan olarak her 1 saatte bir kontrol eder ve değişim gerekiyor ise ( aktifleşme numarasına göre uygun olmayan yerde bir veri tabanı var ise ) bunu gerçekleştirir.
Peki süreyi değiştirebiliyor muyuz? Yani örnek saat başı değil de 12 saatte bir yapsın? Örnek komut aşağıdaki gibidir;
Set-DatabaseAvailabilityGroup -Identity DAG1 -PreferenceMoveFrequency 12:00:00
DAG1 yazan yere kendi ortamınızdaki DAG ismini yazmanız yeterlidir.
Sonuç
Peki bu özelliği kapatmak isterseniz;
Set-DatabaseAvailabilityGroup -Identity DAG1 -PreferenceMoveFrequency ([System.Threading.Timeout]::InfiniteTimeSpan)
Sadece DAG1 yazan yere sizin ortamınızdaki DAG ismini yazmanız yeterli.
Sonucu tekrar kontrol ettiğinizde ise durum aşağıdaki gibidir
Ya da bu komut da aynı işi görmektedir;
Set-DatabaseAvailabilityGroup -Identity DAG1 -PreferenceMoveFrequency 00:00:00
Burada önemli nokta eğer sizde benim gibi bu özelikten önce RedistributeActiveDatabases.ps1 ile zamanlanmış görev tanımlamış iseniz artık bunu kaldırabilirsiniz.
Bir diğer önemli konu ise yaptığınız tüm bu değişikliklerden sonra Replication servisini restart etmeniz gerektiğidir.
Peki bu işlemleri nasıl takip edeceğiz?
Öncelikle olay günlüklerinden veri tabanı move işlemlerini görebiliriz;
Bunun için aşağıdaki olayları takip edebilirsiniz;
Event Log – Application and Services Logs – Microsoft – Exchange – HighAvailability – Operational altında Event ID 322 olarak takip edebilirsiniz.
Veya aşağıdaki gibi son derece kullanışlı bir komut seti ile html bir rapor alabilirsiniz
.\CollectOverMetrics.ps1 -DatabaseAvailabilityGroup DAG1 -StartTime “10/01/2018” -EndTime “10/27/2018” -GenerateHTMLReport –ShowHTMLReport
Hatta canlı bir sistemde bir süre beklerseniz elle yaptığınız bir switch over sonrası DB’ lerin öncelikli yerlerine döndüğünü görebilirsiniz.
Örneğin yukarıdaki işlemi ben server switch over ile gerçekleştirdim. DB06, EXC02 den EXC01 e gitti, ancak öncelik aktivasyon DB’ si EXC02 olduğu için bir süre sonra ( her saat başı kontrolde) otomatik olarak eski yerine geri döndü;
Evet bir makalemin daha sonuna geldim. Umarım faydalı bir makale olmuştur. Bir sonraki makalemde görüşmek dileği ile.
Kaynak