Microsoft Exchange Server DAG Nedir ve Exchange DAG Kurulumu bu makale içinde en ince detaylarına kadar anlatılmaktadır.
Microsoft Exchange Server DAGs Mimarisi oluşana kadar Exchange Server Business Continuity Plan çözümleri bir çok dönüşüme uğramıştır. Exchange Server Database Availability Group mimarisi ilk olarak Microsoft Exchange Server 2010 ile birlikte kullanmaya başladık ve Microsoft Exchange Server 2016 sürümü ile son şeklini almıştır.
Microsoft Exchange Server için yedeklilik, süreklilik ve felaket konumlandırma ihtiyaçlarını tek bir mimari içinde karşılayan Microsoft Exchange Server özelliğidir.
Microsoft Exchange Server Role Konsolidasyon Süreci konu başlığı ile paylaşmış olduğumuz video eğitim içeriklerinde Exchange Database Availability Group mimarisinin gelişimini sizlere paylaşmıştık.
Exchange Server 2007 ‘nin sahip olduğu karmaşık mimari ve Exchange Server 2003 ‘den devir alınan miras problemler Microsoft Exchange Server için Business Continuity Plan çözümlerinin yapılmasına engel oluyordu.
Microsoft Exchange Server 2007 ‘ nin sahip olduğu bu problemler Microsoft Exchange Server 2010 ile birlikte rafa kalkmıştı. Yeni Exchange Server Database Availability Group çözümlerinin esnekliği bir çok kuruluşun ihtiyacını karşılamış, Exchange Server High Availability, Exchange Server Disaster Recovery ve Exchange Server Site Resilience çözümleri kolaylıkla yapılabilir olmuştur.
Bu makale içinde Microsoft Exchange Server DAGs Mimarisi ve Exchange DAG Kurulumu anlatılacak olup aşağıda ki başlıklara odaklanacağız.
1. Exchange Server Database Availability Group Nedir?
Microsoft Exchange Server Database Availability Group mimarisi her bir veritabanının Exchange Server DAGs kümesi içinde bulunan Exchange Mailbox Server ‘a çoğaltılması – eşitlenmesi diyebiliriz.
Bu özellik ile Microsoft Exchange Server Database özelinde yedeklilik, süreklilik ve felaket konumlandırma çözümleri yapılmaktadır.
Microsoft Exchange Database Availability Groups mimarisi bir veri tabanının en fazla 16 sunucuya kadar çoğaltılmasını sağlamaktadır.
Eski Windows Server işletim sistemi üzerinde yapılandırılan Failover Cluster servisi en fazla 16 Adet Nod kabul ediyordu ve Microsoft Exchange DAGs mimarisi de bu sınırlar içinde çalışmaktadır.
Günümüzde, Windows Server 2016 Failover Cluster mimarisi 64 Adet Node ile çalışabilse de bu sayı Microsoft Exchange Server DAGs yapısına etki etmedi ve Microsoft Exchange Database Availability Groups içinde bu günde fazla 16 adet Exchange Mailbox Server çalışmasına izin verilmektedir.
Database Availability Groups
Microsoft Exchange Server Database Availability Group yapısı, daha önce kullanmış olduğumuz yapmış olduğumuz Exchange Server High Availability çözümlerine göre farklıdır.
Yeni Exchange DAGs mimarisi shared storage kullanmamakta, single point of olarak adlandırdığımız tek bir veri tabanını üzerinde çalışmamaktadır.
Exchange Organizasyonu içinde bulunan her bir Exchange Database, Exchange DAGs mimarisi içinde bulunan her bir Exchange Mailbox Server ‘a ağ üzerinden veri tabanı seviyesinde eşitleme yapmaktadır.
Exchange Server High Availability çözümlerinin en büyük problemi olan shared storege Exchange Dag mimarisi ile birlikte tarih olmuştur.
Fakat bu özelliğin bir dezavantajı bulunmaktadır ve Exchange Organizasyonu içinde bulunan her bir Exchange Database kaç tane Exchange Mailbox Server üzerine eşitlenirse Exchange Veri tabanı boyutu kadar ek disk alanı Exchange Server sürekliliği için ayrılmak zorundadır.
Exchange Server Database Availability Groups
Bu mimariyi bir örnek ile sizlere aktaralım.
Exchange Mailbox Server üzerinde barınan Exchange Database 100 GB boyutuna sahip ve bu Exchange Database ‘i ikinci bir Exchange Mailbox Server ‘a çoğaltmak istersek, bu exchange veri tabanı özelinde yedeklilik, süreklilik yapmak istersek eşitleme yaptığımız Exchange Mailbox Server üzerinde de bu veri tabanı için 100 GB boyutunda bir disk alanına ihtiyacımız bulunmaktadır.
Eşitleme yapacak olduğumuz Exchange Mailbox Server kadar bu sayı artış gösterecektir. yapılmaz ama konunun pekişmesi için saçma bir örnek verelim.
100 GB boyutunda olan bir Exchange Server veri tabanını, Microsoft Exchange DAGs kümesi içinde bulunan bütün sunuculara eşitlemek, çoğaltmak istedik. Exchange Dag limiti de günümüzde 16 Adet ve bütün Exchange Mailbox Server ‘a bu eşitmemeyi yaparsak 100 GB boyutunda olan bu Exchange Database için toplam da 1.6 TB veri depolama havuzuna ihtiyacımız olacaktır.
Microsoft Exchange Server için bu türde bir tasarım yok ama konunun anlaşılması için bu uç örneği sizlere paylaşmak istedim.
Kabul gören yapılandırmada süreklilik için en az 2 Exchange Mailbox Server ‘e eşitlenmesi, optimizasyon ve veri tabanı yedekleme görevleri de ayrılmak isteniliyorsa üçüncü bir Exchange Mailbox Server ‘ a eşitleme yapılması önerilir. Exchange Site Resilience mimarisi yapıldıysa ve Felaketten korunma projesi için Exchange Database kullanılacaksa bu veri tabanı uzak site içinde bulunan Exchange Mailbox Server ‘a da eşitleme yapılarak 4 yada ihtiyaçlara bağlı olarak 5 farklı Exchange Mailbox Sunucusuna eşitleme yapılması önerilmektedir.
Paranoyakça yapılan tasarımlar, planlanmayan veri tabanı çoğaltma işlemleri, disk üniteleri üzerinde alan problemleri oluşmasına neden olacağı gibi maliyetleri yukarıya çecekek ve Exchange Server üzerinde gereksiz iş yüklerine ve performans kayıplarına da neden olacaktır.
2. Exchange Server Site Resilience Nedir?
Exchange Server Database Availability Group mimarisi Exchange Server Site Resilience çözümleri için de hazırdı. Exchange Server DAGs mimarisi aynı veri merkezi içinde Exchange Server High Availability ihtiyacını karşılarken aynı mimari çatısı altında uzak veri merkezi için de bulunan Exchange Mailbox Server ‘larda Disaster Recovery ihtiyacı için çalışabilmektedir.
Exchange Server Database Availability Group mimari tek bir çatı altında Exchange Server Business Continuity Plan çözümlerini ve aynı zaman da Exchange Server Disaster Receovery çözümlerini karşılayabilir durumda.
Exchange Server 2003 ‘de olduğu gibi donanıma bağımlı kalmadan hazırlanan Microsoft Exchange Server Disaster Recovery çözümü Exchange Server DAGs mimarisi için de hazır durumda ve Microsoft Exchange Server 2007 ‘de ki gibi karmaşık mimariler tasarlanmadan bir kaç adımlama ile Exchange Server Disaster Recovery ihtiyacı karşılanabilir durumdadır.
Exchange Server Site Resilience
Örnek senaryo da görüldüğü gibi Redmon isimli Active Directory Site içinde bulunan Exchange Mailbox Server ‘ları görmektesiniz.
Bu Exchange Mailbox Server üzerinde barınan Exchange Database ‘leri Dublin isimli Active Directory Site içinde bulunan Exchange Mailbox Server ile aynı Exchange DAGs kümesi içinde çalışabilmektedir.
Exchange Server Database Availability Group mimarisi IP tabanlı çalıştığı için ve ağ üzerinden veri eşitlemesini gerçekleştirdiği için Exchange Server Site Resilience çözümleri artık çok kolay bir şekilde yapılabilmekte ve sahip olduğu bu esnekliği ile her kurumun ihtiyaç duyduğu Exchange Server Disaster Recovery projeleri kolaylıkla yapılabilmektedir.
Dünyanın herhangi bir ucunda bulunan ve IP üzerinden erişim sağlanan Exchange Mailbox Server ‘lar aynı Exchange Database Availability Group içinde çalıştırabilmekteyiz.
3. Microsoft Exchange DAG Gereksinimleri Nedir?
Microsoft Exchange Server DAGs kurulumu Eski Exchange Server süreklilik, yedeklilik ve felaket konumlandırma projelerine göre daha kolay ve esnek olsa bile Exchange Server bağımlılıklarını, ön gereksinim ve şartları gereği bir çok ön talepleri bulunmaktadır.
Microsoft Exchange Server Kurulumu için bir çok ön gereksinimleri (Microsoft Exchange Server Requirments) bulunmakta ve bunları tamamlamamız gerekmektedir.
3.1 Database Availability Groups Gereksinimleri
Microsoft Exchange Server Role Konsalidasyon süreci ile birlikte artık tek bir Exchange Mailbox Role Sahip durumdayız ve bu da aynı zaman da Exchange Server olarak adlandırılmaktadır.
Sadeleşen Microsoft Exchange Server Architecture mimarisini aşağıda ki ekran görüntüsünde sizlere paylaşmaktayım.
Microsoft Exchange Server Architecture
Yukarıda paylaşmış olduğumuz topoloji içinde Microsoft Exchange Server 2016 ve Microsoft Exchange Server 2019 Mimarisini görmektesiniz. Exchange Server Role Konsolidasyon sürecinden sonra temel donanım gereksinimleri Microsoft Exchange Server gereksinimleri ve ön şartları ile aynıdır.
Fakat, Microsoft Exchange Server Database Availkability Group için bunlara ek ihtiyaçlar da vardır ki şimdi DAG mimarisinin ihtiyaç duyduğu özel gereksinimleri ve şartları nedir bunları konuşalım.
3.1.1 Veri Depolama Alanı
Microsoft Exchange server DAG mimarisi, Exchange Server tarafından yönetilen ortak havuzlara ihtiyaç duymamaktadır. Exchange Server DAG mimarisi, Microsoft Exchange Server alt yapısına özel Third Party Replication API kullanmaktadır ve DAG üyesi içine dahil edilmiş olan her bir veri tabanını DAG üyesi durumunda bulunan Microsoft Exchange Server database ‘lerine eşitleme yapmaktadır.
Önerilen, DAG özelliği ile birlikte çalışacak her bir Exchange Database barınmış olduğu Exchange Server üzerinde ayrı bir veri depolama havuzunda barınacak ve eşitlenecek olduğu Exchange Server üzerinde de benzer özellik ve kapasitede depolama havuzunun olması gerekecektir.
3.1.2 Microsoft Exchange Server Version
Microsoft DAG mimarisi Exchange Server 2010’dan beri hizmet ediyor olsa bile her bir DAG kümesi farklı Exchange Serverlar versiyonlarında çalışmaz.
Farklı Exchange sürümlerine sahip olan bir organizasyon içinde farklı DAG kümelerini eş zamanlı hizmet ettirebiliriz fakat aynı DAG kümesi içinde bulunan Exchange Serverlar aynı versiyona sahip olması temel şarttır.
Yani bir organizasyon içinde farklı sürümlere sahip durumda bulunan Exchange Serverlar çalışabilir. Microsoft Exchange Server yükseltme, Exhange Server upgrade projelerinde zaten bunu yapmaktayız.
Aynı organizasyon içinde bulunan Microsoft Exchange Server 2016 Mailbox Rolleri için ayrı bir DAG kümesi ve aynı Exchange Server organizasyonu içinde bulunan Exchange server 2019 için ayrı-ayrı Dag kümeleri kullanabiliriz.
Fakat, aynı Exchange Server Organizasyon içinde bulunan Exchange Server 2016 Sunucuları ile Exchange Server 2019 sunucularını aynı DAG kümesi içinde bir araya getiremeyiz.
Yukarıda paylaşmış olduğum Powershell komutu ile organizasyon içinde yüklü bulunan Exchange Serverları, versiyonlarını görüntüleyebilirsiniz.
3.1.3 Exchange Server ve DAG Lisans
Exchange Server sürümleri, Exchange server 2016 Standart Edition ve Exchange Server 2016 Enterprise Edition olmak üzere iki farklı sürüme sahip durumdadır. Her iki sürüm de Database Availability Groups teknolojisini desteklemektedir. Fakat sürümler arasındaki farkı incelediğiniz zaman veri tabanı seviyesinde sınırlama bulunmaktadır.
Microsoft Exchange Server Editions
Microsoft Exchange Server Standart Edition 5 Adet Exchange Server Database ev sahipliği yapabiliyorken Exchange Server 2016 Enterprise 100 Adet veri tabanına ev sahipliği yapabilmektedir.
Microsoft Exchange Server Standart Edition ve Microsoft Exchange Server Enterprise Edition üzerinde barınan Database sayıları farklılık göstermekte ve Standart Edition ‘in sahip olduğu sınırlamalar ise bir çok kuruluşun ihtiyaçlarını karşılamamaktadır.
Exchange Server öğreniyorum eğitim serimizde bu konu için Microsoft Exchange Server Optimizasyonu ve Default Database Önemi ve Taşıma işlemleri başlığı altında Exchange Default database önemini ve yapılması gerekenleri paylaşmıştık.
3.1.4 Exchange Server Aktif-Pasif Lisanslama
Microsoft Exchange DAG mimarisi Aktif-Aktif çalışabildiği gibi Aktif-Pasif olarak da çalışabilmektedir. Exchange Database Availability Group içinde bulunan ve Pasif Node olarak yapılandıran her bir Microsoft Exchange Server için lisans almamıza gerek yoktur.
Biraz karmaşık galiba. Örnek bir topolojiyi aşağıda paylaşıyorum.
Exchange Server Organizasyonu içinde 2 adet Exchange Server sunucusu bulunmakta. Her bir Exchange Server Standart sürüme sahip ve ikisi de aynı Exchange DAG kümesinin üyesi durumunda ve bizler de bir tane Microsoft Exchange Server lisansına sahibiz.
Bu Microsoft Exchange DAG kümesi toplam 5 adet Aktif Exchange Database sahip olsun ve lisansı aktif duruma getirdiğimiz Exchange Server üzerinde 5 adet Exchange Database hizmet edecek ve DAG Kümesi içinde bulunan diğer Exchange Server üzerinde sadece Pasif kopyaları barınacak.
Bu senaryo da Pasif durumda çalışan Exchange Server için herhangi bir lisans almanıza gerek yoktur. Bu durum ne zaman değişir sorusu içinde aşağıda ki senaryolara bakalım.
3.1.4.1 Planlı Kesinti (Aktif Nod Değiştirme)
Microsoft Exchange Server üzerinde Planlı bir hizmet kesintisi yapacağız. Lisanslaması aktif durumda bulunan Microsoft Exchange Server üzerinde bulunan Exchange Databaselerinin sadece bir tanesini bile aktif duruma getirdiğimiz zaman bile pasif olarak çalışan ve Exchange Server Lisanslamasını yapmadığımız sunucu bu andan itibaren lisans isteyecektir.
Eğer tek bir Exchange server lisansı ile devam etmek istiyorsak ve Exchange Server DAG Kümesi içinde çalışan Pasif Node için Lisans almak istemiyorsak Pasif Node üzerinde bulunan Exchange Database kopyalarını aktif olarak değiştirmemiz gerekmektedir. Exchange Server üzerinde barınan bir Exchange Database için aktif-pasif nod değişimini Exchange Database üzerinde Activation Preference number özelliği ile yapabilir ve bu bölümde ki sayıyı değişdirebiliriz.
Activation Preference number
Bu işlemi yaptıktan sonra Exchange DAG kümesi içinde aktif olarak hizmet veren Exchange Server bu işlemden sonra pasif olarak hizmet verecek ve sadece Exchange Database kopyalarını tutacaktır.
Planlı çalışmamız bitti. Aktif nod artık ortama hizmet edebilir durumda. Lisanslama sınırlaması gereği pasif nod üzerinde çalışan (yukarıda ki işlemden sonra artık bu Exchange server aktif nod oldu unutmayalım) Exchange Database ‘leri geri alamıyoruz.
Planlı kesintilerde bu dönüşüm yapıldığı zaman lisans yasal düzenlemesi gereği 180 gün boyunca Exchange Databaselerimiz Pasif nod üzerinde bekletmek zorunda. Teknik açıdan bir sınırlama olmadığını bir kez daha hatırlatmak isterim, benden duymadınız.
Exchange DAG kümesi içinde çalışan ve Pasif Exchange Nod’ e nin lisanslanmadığı senaryolarda planlı bakım çalışmalarının süreci teknik işlemlerde değil ama lisasn yasaları gereği zorluklar oluşturmakta.
Microsoft Exchange Server üzerinde yapacak olduğumuz Microsoft Exchange Server Cumulative Update Paketleri yükleme işlemleri Microsoft Exchange Server Security Update Paketleri yükleme işlemleri süreç olarak bu politikadan etkilenmektedir.
3.1.4.2 Plansız Kesinti (Hizmet Kesinti Senaryosu)
Microsoft Exchange organizasyonu içinde bulunan Exchange Server üzerinde plansız hizmet kesintisi oluştu ve Exchange lisanslarını aktif ettiğimiz Exchange Server kapandı.
Microsoft Exchange DAG mimarisi gereği e-posta sisteminin sürekliliği için Pasif durumda çalışan Exchange Server bu hizmet kesintisi sonrası otomatik olarak aktif duruma geçer ve sahip olduğumuz Exchange Server Standart Lisansı da bu sunucu üzerine kaydırılır.
Buraya kadar her şey normal ve bunun olması beklenir. Fakat, plansız kesinti durumu ortadan kalktı ve sizlerde sistemin eskisi gibi çalışmasını yani Pasif duruma geçen aktif Exchange Server ‘in tekrardan aktif, plansız kesinti sonrası aktif duruma geçen Exchange Server ‘in da tekrardan pasif olmasını istiyorsunuz.
Teknik olarak bu dönüşümü yapmamız mümkün fakat lisans sözleşmesi gereği bu dönüşümü yapmamız için de tekrardan 180 gün boyunca beklememiz gerekmektedir.
Bu şartlar, lisans sözleşmesi içinde yer almakta ve teknik açıdan bunları yapmamız da hiçbir sınırlandırma bulunmamaktadır. Aynı Exchange Dag kümesi içinde bulunan Exchange Server veri tabanlarını Dag kümeleri arasında rahatça gezdirebiliriz. Bu kısıtlama, lisanslama kısıtlamasıdır.
Microsoft Exchange Server 2010 için bu süre 120 gündür ve dikkat ettiyseniz bu süre zaten satın alma öncesi sağlanan deneme süresi ile sınırlıdır.
3.1.5 Windows İşletim Sistemi
Microsoft Exchange Dag mimarisi Exchange Server 2010 ‘da hayatımıza girdi ve günümüz Exchange Server 2019 ‘da devam etmektedir.
Bu zaman içinde hayatımıza girmiş olan bütün Microsoft Exchange Server sürümleri, Exchange Server 2013 ve Exchange Server 2016 ‘da dahil olmak üzere farklı Windows Server sürümlerinin üzerine yüklendi.
Bazı özel durumlarda bazı Microsoft Exchange Server Cumulative Update Paketleri bile farklı Windows Server sürümlerini istedi. Exchange Server sürümleri bir çok kez farklı Windows Server işletim sistemi istemekte olup bu planı yapmak bazen bulmaca çözmeye benzer.
Bu konu için Microsoft Exchange Server Kurulumu ve Desteklenen Windows Server Türleri konu başlığı ile aşağıda ki video çalışmasını hazırlamış ve Microsoft Exchange Server Kurulum işlemlerini yapmadan önce kurulum işlemini yapacak olduğunuz Exchange Server ‘in desteklediği Windows işletim sistemini teyit etmenizi şiddetle öneririm.
Aynı Exchange Server DAG kümesi içinde çalışan Exchange Server ‘ların aynı CU sürümünde olması zorunlu değildir (öneridir) ama aynı Exchange Server DAG kümesi içinde çalışan Exchange Server ‘ların aynı Windows Server işletim sistemine sahip olmaları zounludur.
Bunun nedeni Exchange Server Database Availability Groups mimarisi Windows Failover Clustering teknolojisini kullanmakta ve Failover Clustering teknolojisi aynı düğüm içinde çalışan üyelerin aynı Windows işletim sistemine sahip olmasını istemektedir.
3.1.6 Network Gereksinimi
Exchange Server Database Availability Group düğümü olacak olan her bir Exchange Server üzerinde en az iki adet network kartının olması gerekmektedir.
Bu gereksinim Exchange Server 2016’a kadar öneriydi şimdi ise seçenekli olarak bizlere sunulmaktadır. Bana soracak olursanız, ben bu günde projelerimde en az iki adet network kartının önemine dikkat çekerim.
Database Availability Group düğümü olan Exchange Server Mailbox sunucuları üzerinde bulunan bu iki network kartının temel görevi ve isimleri aşağıdaki gibidir.
Exchange Server Dag Network
3.1.6.1 Mapi Network
Mapi Network Exchange server ile etki alanı sunucularının iletişimini sağlamaktadır. Exchange Server 2016 ile birlikte Client Access rolü de bu sunucu üzerinde olduğu için son kullanıcılarımıza hizmet veren, Exchange Client ‘ları Exchange Server ‘a eriştiren network kartı olduğunu söyleyebiliriz.
3.1.6.2 Replication Network
Exchange 2016 ile birlikte mapi networkü ve Replication Networkü aynı network kartı üzerinde çalıştırabilmekteyiz. Daha önce belirttiği gibi ben gün de bu iki networkün bir-birinden bağımsız olmasını istemekteyim.
Sebebi ise amaçları farklı olan bu iki networkün bir-birlerinin sahip oldukları iş yüklerinden etkilenmemeleri için ayrı network blok dizaynı hala yapmaktayım.
Exchange Dag Network Adapter Configuration
Exchange Mapi network ve Exchange Replication Network kartlarını ayrı yaptığımız zaman yukarıdaki yapılandırmayı network kartları üzerinde uygulamanız gerekmektedir. İki networkü iki network kartı ile ayırdığınız zaman yapmanız gerekli olan en temel yapılandırma aşağıdaki gibidir;
- Client for Microsoft Networks ve File and Printer Sharing for Microsoft Networks kutularının Replication Network kartı üzerinde seçilmemiş olması gerekmektedir.
- Replication Network kartı üzerinde Register this connection’s addresses in DNS kutusunun işaretli olmaması gerekmektedir
- Replication Networkü üzerinde Default Gateway atamasının yapılmamış olması gerekmektedir. Eğer Replication networkünün başka bir network ile iletişim kurması gerekiyorsa (bu özellik sadece site resilience için gereklidir) static routing tabloları düzenlenmesi gerekmektedir.
- Replication network kartlarının DHCP üzerinden IP almamış olması ve sabit IP adresinin tanımlı olması gerekmektedir.
Exchange Server öğreniyorum video eğitim serimiz de Microsoft Exchange Server Internal IP Adres Tasarımı konu başlığını detaylı olarak incelemiştik ve aşağıda paylaşmış olduğum video eğitim içeriğinde konuyu sizlere aktarmıştım.
3.1.7 Witness Server Gereksinimi
Microsoft Exchange Dag mimarisi Database Availability Group üyelerini, üyelerin durumunu ve DAG üye sayısının yeterli sayıda olup-olmadığını denetlemek için Witness Server gereksinimi zorunludur.
Adı üstünde bu sunucu bir tanık sunucusudur ve Exchange DAG kümesi içinde bulunmayan harici bir Windows işletim sistemi olmak zorundadır. Witness Server ‘in sahip olduğu Windows işletim sistemi Exchange DAG kümesi içinde bulunmayan Exchange Server ‘lar ile aynı olmasına gerek yoktur.
DAG üye sayısı çift sayıya sahip her bir Exchange DAG Cluster Mimarisi, Witness Server kullanmak zorundadır. Bu zorunluluğu aşağıdaki örnek ile açıklayalım.
3.1.7.1 Node majority (no witness)
Node majority (no witness)
Yukarıda Node majority (no witness) özelliği ile çalışmakta olan bir Exchange DAG kümesini görmektesiniz. Exchange DAG Kümesi içinde bulunan Exchange Server sayısı 9 ve tek sayı. 1-3-5-7-9-11-13-15 gibi sayılara sahip Exchange DAG Kümesinde Witness Server kullannılmaz ve Node majority (no witness) olarak hizmet verir.
Witness satırına baktığınız zaman zaten görülmekte olup, ortamda Witness Server olmasına rağmen Witness Server devreye girmemekte çünkü aktif çalışmakta olan bütün Exchange Server ‘ların sayısı tekli olduğu için Witness Server şu anda kullanılmamakta.
3.1.7.2 Node majority with witness
Witness Server Node majority with witness
Yukarıda ise Witness Server Node majority with witness özelliği ile çalışmakta olan bir Exchange DAG kümesini görmektesiniz. Exchange DAG Kümesi içinde bulunan Exchange Server sayısı 2 ve çift sayı. 2-4-6-8-10-12-14-16 gibi sayılara sahip Exchange DAG Kümesinde Witness Server kullanılmakta ve Witness Server Node majority with witness olarak hizmet verir.
Witness satırına baktığınız Exchange DAG kümesi için kullanılmakta olan Witness Server adresini ve Witness Server paylaşımlı alana erişimi görebilmektesiniz.
Özet ile Witness Server yapılandırması ister tekil sayıda bir Exchange Server DAG mimarisi kurun, isterseniz çift sayıda. Bu önemli değildir. Exchange Server DAG mimarisini kurabilmeniz için Witness Server zorunludur ve küme içinde Exchange Server sayısı çift olduğu zaman Witness Server devreye girer ve Exchange DAG kümesine sahitlik yapmaya başlar.
Diğer zamanlarda, Exchange DAG kümesi içinde bulunan Exchange Server sayısı tek olduğu zaman Exchnage Server ‘lardan bir tanesi hata durumuna düşerse devreye girer ve Exchange DAG ‘ın devamlılığını sağlar.
3.1.7.3 Witness Server Builtin Administrator
Witness Server için bir takım ön hazırlıklar bulunmaktadır ve bunları inceleyelim.
Witness Server Builtin Administrator
Witness Server üzerinde Builtin Administrator grubu bulunmaktadır ve etki alanımız içinde bulunan Exchange Trusted Subsystem grubunu Witness Server üzerinde bulunan Builtin Administrator grbunun üyesi yapmamız gerekmektedir.
Witness Server olarak etki alanımız içinde bulunan etki alanı yöneticilerimizi yani Domain Controller sunucularımızı yapabiliriz. Ama bilmemiz gerekli olan birtakım handikaplar bulunmaktadır ki bu handikapları Microsoft Exchange Server Domain Controller Üzerine Kurulumu konu başlığı ile sizlere paylaşmıştık.
Exchange Server öğreniyorum eğitim serimizde yer alan bu konu başlığını aşağıda izleyebilir ve oluşabilecek güvenlik riskleri hakkında detaylı bilgiye sahibi olabilirsiniz.
3.1.7.2 Witness Server Folder Permissions
Witness Server Builtin Administrator bölümünde söylemiş olduğumuz güvenlik riski Witness Server Folder Permissions içinde geçerlidir. Witness Server olarak eğer etki alanı içinde yer alan bir Domain Controller sunucusu tercih edilirse bu güvenlik riski dosya izinleri içinde devam edecektir.
Witness Server Permission
Witness Server, Microsoft Exchange DAG Cluster kümesi içinde yer alan Exchange Sunucularına sahitlik yapması için Witness Server üzerinde paylaştırılmış bir dosyaya ihtiyaç duyar.
Witness Server üzerinde bir dizin oluşturuyoruz ve bu dizin üzerinde Exchange Trusted Subsystem gurubu için Full Control izinlerinin atamasını gerçekleştiriyoruz. Microsoft Exchange organizasyonu içinde bulunan her bir Exchange Server , Exchange Trusted Subsystem grubunun üyesi olduğu için vermiş olduğumuz bu izinler ile Exchange Sunucuları Witness Server ‘a erişim yapabileceklerdir.
3.1.8 Etki Alanı ve DNS Server Gereksinimi
Exchange Server öğreniyoum eğitim serimizde bir çok konu başlığında bahsettik. Microsoft Exchange Server için Active Directory ortamı zorunlu bir ihtiyaçtır ve bu zorunlu ihtiyaç Microsoft Exchange DAG kurulumu için de bir takım ön şartları temel koşmaktadır.
Exchange DAG Cluster Name Object – CNO
Etki alanımız içinde kuracak olduğumuz Exchange DAG mimarisi için Cluster Name Object ‘e ihtiyaç bulunmaktadır. Bu bilgisayar hesabı Windows Failover Clustering servisi için kullanmakta olan sanal bilgisayar hesabıdır.
Etki alanımız içinde bir tane bilgisayar hesabı oluşturuyoruz ve bu hesabı disabled duruma getiriyoruz. Bilgisayar hesabına vermiş olduğum isim kuracak olduğumuz Exchange DAG ‘in virtual account ‘u olacaktır.
Bizim örneğimizde Dag01 isimli kümenin ismi aynı zaman da bu bilgisayar hesabı da DAG kümesinin ismi olacaktır.
Oluşturmuş olduğum bu bilgisayar hesabını Exchange Trusted Subsystem grubunun üyesi yapıyorum.
Exchange DAG Dns Host Name
Oluşturmuş olduğum DAG01 isimli CNO için bilgisayar hesabı oluştu ve Active Directory dizini içinde barınmakta. Exchange DAG için oluşturulan CNO için dNSHostName Attribute niteliği boş durumdadır. Etki alanımız içinde oluşturmuş olduğumuz Failover clustering virtual account niteliklerinde düzenleme yapıyoruz ve DAG01 isimli bilgisayar hesabının etki alanı içinde kullanılacak olan FQDN bilgisini tanımlıyoruz.
Database Availability Group DNS Name for CNO
Exchange organizasyonu için Database Availability Group kurulumuna geçmeden önce DNS sunucumuz üzerinde DAG bilgisayar hesabımız için oluşturulan bilgisayar hesabı ile eşleşen bir A kaydını oluşturmamız gerekmekte.
A kaydının eşleşmiş olduğu IP adresi Exchange Serverlarımızın Mapi Network kartlarıdır. DAG kurulumunu henüz gerçekleştirmediğimiz için oluşturulan bu isim Ping isteklerine cevap veremeyecektir.
Exchange DAG kurulumu için oluşturulan bu virtual hesap ve dns erişim bilgileri Active Directory içinde saklanmaktadır ve görüldüğü gibi Exchange DAG Kurulumu için de Active Directory zorunluluğu da bulunmaktadır.
Microsoft Exchange Server Active Directory ihtiyacı konu başlığı ile paylaşmış olduğumuz video eğitim içeriğine aşağıdan izleyebilirsiniz.
4. Exchange Server DAG Kurulumu
Exchange Server Database Availability Group kurulumu için gerekli olan yazılım ve donanım gereksinimlerini karşıladıysak artık kurulum aşamasına geçiş yapabiliriz.
Exchange Database Availability Group Kurulumu
Microsoft Exchange Control Panel yönetim konsolumuza bağlantı gerçekleştiriyoruz. Exchange Control Panel üzerinde Server sekmesine geçiş yapıyoruz ve bu bölümde Database Availability Groups sekmesine ulaşıyoruz.
Bu bölümde artı (+) butonu ile New Database Availability Group sihirbazı karşımıza çıkmakta ve Bu bölümde aşağıda ki adımları takip ediyoruz.
- Database availability group name satırına etki alanı içinde oluşturmuş olduğumuz CNO’ nin ismini veriyoruz.
- Witness server satırına yapılandırmış olduğumuz witness sunucumuzun FQDN bilgisini yazıyoruz.
- Witness directory satırına ise Witness server üzerinde oluşturmuş olduğumuz ve izinlerinin atamasını yapmış olduğumuz dizinin bilgisini veriyoruz. UNC path veya paylaşılmış alan bilgisini vermiyoruz ki zaten bu dizini paylaştırmamız gerekmemektedir.
- Database availability group IP addresses satırına ise DNS alanımız içinde oluşturmuş olduğumuz, DAG01 isimli Cluster Name Object’e işaret eden A kaydının karşılığında ki IP adresini yazıyoruz. Tekrar hatırlatıyorum bu bölüm içinde yer alan IP adresi MAPI IP blok içinde olmalıdır.
Save dedikten sonra Database availability group oluşturulacaktır.
Active Directory Exchange Administrative Group
Evet, kurulum için next-next ilerleme butonları bekleyebilirsiniz ama yok. Microsoft Exchange Server DAg Kurulumunda ki en temel adımlar Exchange DAG gereksinimlerini tamamlamaktır. Eğer, temel gereksinimler doğru bir şekilde tamamlanırsa Exchange DAg kurulumu yukarıda görüldüğü gibi hızlı ve problemsiz bir şekilde tamamlanacaktır.
Exchange Server kurulumu ve yapılan hemen-hemen her değişiklik etki alanı içine yazılmaktadır. Yapmış olduğumuz bu işlemler her ne kadar Exchange Server üzerinde yapıyor olsak bile (Exchange DAG Kurulum adımlarında olduğu gibi) bu işlemler yukarıdaki göstermiş olduğum ADSI Edit ekran görüntüsünden anlaşılacağı üzere etki alanı veri tabanına yazılmaktadır.
Exchange Control Panel üzerinde DAG kurulumunu gerçekleştirdikten sonra oluşturmuş olduğunuz DAG hesabının etki alanı veri tabanına yazılmış olduğundan emin olmalısınız.
Etki alanı üzerinde gerekli kontrolü ve eşitleme işlemini çalıştırdıktan sonra oluşturulan Exchange DAG nesnesinin etki alanı içinde bulunan bütün etki alanı yöneticileri tarafından bilindiğine eminiz.
Manage Database Availability Group Members
Şimdi yapacak olduğumuz işlem ise ECP üzerinde oluşturmuş olduğumuz Exchange DAG kümesini seçiyoruz ve Manage Database Availability Group membership bölümüne geliyoruz. Bu bölümde oluşturmuş olduğumuz DAG objesi içine üyeleri yani Exchange Server ‘ları ekliyoruz.
Exchange DAG kurulum kurallarını bir kez daha hatırlatmak istiyorum. Bir Exchange organizasyonu içinde birden fazla DAG kümesi olabilir ama her bir DAG düğümü aynı sürüme sahip Exchange serverları barındırabilir. Exchange Server 2013 ile Exchange Server 2016 sürümüne sahip durumda ki Exchange Serverları aynı DAG kümesine ekleyemeyiz.
Bu bölümde ekleyecek olduğum Exchange Serverların sahip olduğu sürümler Exchange Server 2016’dır.
Exchange Server DAG Members
Exchange Control Panel üzerinde Database Availability Groups bölümüne geldiğimiz zaman oluşturmuş olduğumuz DAG01 isimli DAG kümesini, Witness server bölümünde belirlemiş olduğumuz DC01 isimli witness sunucumuzu ve members servers bölümünde ise DAG01 isimli düğüme dahil ettiğimiz Exchange Sunucularımızı görebilmekteyiz.
Exchange DAG Failover Cluster Virtual Account
Exchange DAG Cluster oluşturulduktan sonra ve DAG Cluster içine üye Exchange Server ekledikten sonra etki alanımız içinde oluşturmuş olduğumuz ve disable olarak tanımladığımız Cluster Name Object (CNO) hesabının kendiliğinden aktif duruma geldiğini görebilirsiniz.
Bu hesap Exchange Dag Cluster oluşturulduktan sonra ve ilk üye Exchange Server ‘in DAG Kümesine eklenmesi ile birlikte etkin duruma gelecektir. Bu sanal hesabı el-ile aktif duruma getirmeyin.
Exchange DAG Failover Cluster Name Object
Etki alanımızın yapısının büyüklüğüne göre eşitleme zamanı farklılık gösterebilir. Exchange DAG Cluster içine Exchange Server Database ‘leri eklemeden önce, aktif duruma gelen DAG Cluster Name Obje’ sinin diğer etki alanı yöneticilerine eşitlenmiş olduğundan emin olmalısınız.
Eşitleme tamamlandıktan sonra, DNS sunucumuz üzerinde eşleştirmiş olduğumuz IP adresi ve CNO bilgileri ile ping isteklerimize cevap verecektir.
5. IP-Less DAG Nedir ve IP-Less Dag Kurulumu
Exchange Server projelerinde önermemiş olduğum ve bu türden bir Exhange DAG Kurulumu için taraf olmadığımı belirtmek istiyorum. Tamam, bu kurulum yöntemini yani IP-Less DAG diğer ismi ile Homeless DAG nedir, bunları konuşalım ve neden önermediğimizin altını çizelim.
5.1 IP-Less DAG Nedir ?
Exchange 2013 ile birlikte No Administrative Access Point and IP-Less Dag bilgisi paylaşılmıştı. Microsoft Ignite 2015 oturumlarında yer alan High Availability and Site Resilience: Learning from the Cloud and Field oturumunda bu konuya detaylı yer verilmişti.
IP-Less Exchange DAG
Exchange 2013 SP1 ile duyurusu yapılan bu yöntem Exchange 2016 için desteklemektedir ve bu kurulum yönteminin artıları ve eksileri bulunmakta.
En büyük artısı ön gereksinimler olmaksızın Exchange DAG düğümünü yönetecek bir Cluster Name Object (CNO) oluşturmadan ve bu oluşturulan CNO için etki alanı izinleri ve ip yapılandırmasını gerçekleştirmeden kurulumu hızlı bir şekilde yapmamızdır.
Bu yöntem Exchange 2013 SP1 ve Exchange 2016 için desteklemektedir ve Exchange Sunucularının barınacak olduğu Windows işletim sisteminin Windows Server 2012 ve üstü olması temel şarttır.
Exchange server 2013 organizasyonları içinde değil ama Exchange server 2016 Organizasyonları için dikkat edilmesi gerekli olan bir konu bulunmakta.
Exchange server 2016 için işletim sistemi desteği Windows Server 2012 ve üstü için desteklenmektedir. Exchange Server 2013 SP1 ise Windows Server 2008 R2 işletim sistemi üzerine de yükleyebilmekteyiz. Ve hatırlatmak istiyorum Windows Server 2008 R2 ile Windows Server 2012 ve sonrasındaki sunucu işletim sistemleri için lisanslama ve Failover Clustering limitleri de farklıdır.
IP-Less Dag yaparak bu limit ve lisanslama sıkıntıları ile karşı-karşıya kalmamanız için bu tercihi iyi yapmanızı önermekteyim.
cannot connect without an administrative access point
IP-Less Dag Kurulum yöntemini tercih edersek eğer Failover Cluster Manager erişimi olmayacak ve yönetim sadece Windows Powershell ile gerçekleştirilecektir.
Sebebi ise Failover cluster manager yönetim ara yüzü Cluster Name Object (CNO) üzerinden yapılmakta ve bizler IP-Less Dag kurulum adımlarını tercih edersek Exchange DAG ortamını yönetecek bir Cluster Name Object (CNO) olmayacaktır.
Bu nedenle, geleneksel Exchange DAG mimarisine göre IP-Less Dag ortamlarının yönetimi biraz daha zordur ve Fail Over Cluster yönetimi Windows Powershell ile yapılmaktadır.
Ip-Less Exchange DAG Configuration
IP-Less Dag yöntemine belki de en fazla etken edecek olan çözümler, üçüncü firmaların sağlamış olduğu yedekleme ve izleme yazılımlarıdır. IP-Less Dag kurulumunu neden tercih etmemeliyiz bölümüne şimdi giriş yapıyoruz.
IP-Less Dag Kurulumu ile ilgili TechNet üzerinde ilgili dökumanı sarı olarak işaretledim.
Dökuman içinde söylenmek istenen, Exchange Organizasyonu için kullanılan yedekleme, arşivleme ve izleme yazılımları Exchange DAG Cluster kurulmuş ortamlarda Cluster Name Obje ye ihtiyaç duymaktadır. Exchange organizasyonları için çalışan yedekleme, arşivleme ve izleme yazılımlarının sağlıklı çalışabilmesi için Administrative Access Point hesabı üzerinden Exchange DAG Cluster içinde bulunan Exchange Server ‘lara erişim yapmaktadır.
IP-Less Dag kurulumu yapıldığı zaman Cluster Name Obje ‘e sahip olmuyoruz ve böylece Exchange Organizasyonu için kullanılan yedekleme, arşivleme ve izleme yazılımlarıda Administrative Access Point hesabına erişim yapamadıkları için görevlerini sağlıklı bir şekilde yapamamaktadırlar.
IP-Less Dag kurulumu yapıldığı zaman bizler fail over cluster yönetimini Windows Power Shell komut araçları ile yaparak çözüm bulsak bile üçüncü taraf yazılımlar için bu bir çok probleme açık durumdadır.
5.1 IP-Less DAG Kurulumu
Microsoft Exchange IP-Less DAG yada diğer bilinen ismi ile Homeless DAG mimarisinde herhangi bir yönetim arayüzü olmadığını belirtmiştik. IP-Less DAG yönetim işlemleri Exchange Management Shell üzerinden yapılabileceği gibi IP-Less DAG kurulum işlemleri de benzer şekilde Exchange Management Shell üzerinden yapılmaktadır.
Exchange IP-Less DAG kurulumu için de 3.1 Database Availability Groups Gereksinimleri bölümünde bahsetmiş olduğumuz ön gereksinim ve şartlar devam etmektedir. Bu ön gereksinimleri tamamladıktan sonra Exchange IP-Less DAG kurulum adımlarına geçiş yapabiliriz.
Exchange IP-Less DAG Kurulum
IP-Less Dag Kurulum işlemleri Exchange Management Shell komutları ile gerçekleştireceğiz.
IP-Less Dag Kurulum işlemleri için kullanacak olduğumuz komut yukarıda bulunmakta. Bu Exchange Management shell komutu organizasyonum içinde bulunan Microsoft Exchange Server ‘lardan bir tanesi üzerinde çalıştırıyorum.
Komutun içeriği Dc01 isimli sunucumu Witness Server olarak yapılandırmakta ve bu komut DC01 üzerinde WitnessDirectory oluşturmaktadır.
Yukarıda bulunan hatayı almamız, benim IP-Less Dag Kurulum işlemlerini yapmış olduğum ortam için çok normal. Makalemiz içinde 3.1.8 Etki Alanı ve DNS Server Gereksinimi bölümünde eğer bir Witness Server etki alanı içinde bulunan Domain Controller sunucuları yapılandırılırsa bu riskleri sizlere aktarmıştım ve bu risk için bir uyarı almaktayız.
IP-Less Dag Kurulum işlemleri için kurulum yapmış olduğum platform test ortamı olduğu için bu riski satın alıyorum fakat gerçek ortamlar için önerilmediğini bir kaz daha hatırlatıyorum.
IP-Less Dag Kurulum işlemi ile birlikte Database Availability Groups Gereksinimleri bölümünde bir takım değişiklikler bulunmaktadır. Bu değişiklikler IP-Less Dag mimarisi gereği normal olan değişikliklerdir ve bunlar aşağıda sıralanmıştır.
- IP-Less Dag mimarisinde etki alanı içinde cluster name object (CNO) bulunmaz.
- IP-Less Dag Cluster için ortak bir IP adresi bulunmaz.
- IP-Less Dag Cluster için DAG Cluster ismi bulunmaz.
- IP-Less Dag Cluster için DNS üzerinde kayıt açılmaz.
Fakat, yukarıdaki uyarıyı dikkate almanızı önermekteyim. Witness sunucunun Exchange Trusted Subsystem grubunun üyesi olması gerekmektedir ve oluşturulan Witness dizini üzerinde Exchange Trusted Subsystem grubu için izinlerin verilmesi gerekmektedir. Witness dizini için verecek olduğunuz izinler ön gereksinimler için zorunludur.
Exchange IP-Less database availability group
Dag01 isimli IP-Less Dag Cluster başarılı bir şekilde oluşturuldu ve etki alanı içinde yer aldı.
Etki alanımız içinde bulunan etki alanı denetleyicilerimizi eşitledikten sonra database availability group içine Exchange Server ‘ları ekleyebiliriz. Kullanacak olduğumuz komutu yukarıda paylaştım ve bu komut ile Exchange01 isimli sunucumuzu DAG01 isimli IP-Less DAG kümesinin üyesi yapmaktadır.
Bu komutu dikkatli bir şekilde incelerseniz eğer Exchange Server üzerine windows failover clustering servisini de yüklemektedir.
IP-Less DAG Exchange Member Server
IP-Less DAG Cluster kümesinin üyesi olan Exchange Server ‘lara windows Failover clustering servisi yüklendikten sonra DAG01 isimli küme oluşacak ve sonrasında aynı diğer küme sunucularınıda yukarıda paylaşmış olduğum komutu kullanarak eklemeye devam edebilirsiniz.
IP-Less DAG Database Availability Group
IP-Less DAG Kurulum işlemleri başarılı bir şekilde tamamlandı.
Son olarak yukarıda çalıştırmış olduğum komut ile oluşturmuş olduğum Dag kümesinin ismini, witnessServer’i ve sahip olduğu IP adresi gibi temel bilgileri görebilirsiniz.
