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 2012 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
