Microsoft Exchange Server DAGs ve Load Balancer Gereksinimi, Microsoft Exchange Server Role Konsalidasyon süreci ile birlikte değişim göstermiş, Exchange Server Business Continuity Plan / Disaster Recovery Plan çözümlerine etki etmiştir.
Microsoft Exchange Server Role Konsalidasyon sürecinden önce ve Exchange Server Database Availability Groups tasarımları için ve Load Balancer ihtiyacı zorunlu değilken Exchange Server 2016 ile birlikte Load Balancer ürün ve çözümleri zorunlu olmuştur.
Microsoft Exchange Server DAGs ve Load Balancer Gereksinimi konu başlığı ile paylaşmış olduğumuz makalemiz de aşağıda ki bilgilere sahip olacaksınız.
1. Microsoft Exchange Server Dönüşüm Süreci ve BCDR Projelerine etkisi
Microsoft firması Exchange Server müşterilerine daha iyi hizmet vermek için Microsoft Exchange Server 2007 ‘den Microsoft Exchange Server 2016 /2019 sürümüne kadar bir çok evrimi gerçekleştirdi ve Exchange Server Role Konsolidasyon Süreci başladı.
Bu süreç bu gün de her bir Microsoft Exchange Server Cumulative Update Paketleri ile devam etmektedir.
Microsoft Exchange Server Role ve Exchange Servisleri dönüşüm gösterirken Exchange Server High Availability Süreçleri ‘de bu dönüşümden nasibini aldı.
Değişen sadece Microsoft Exchange Server mimarisi değil aynı zamanda Exchange Server Tasarımları da değişti ve bu tasarım değişiklikleri de Microsoft Exchange Server Kurulum yöntemlerine, Exchange Server tasarımlarına etki etti.
Bu dönüşümler çok kısa zaman içinde ve de çok hızlı bir şekilde oldu ve Microsoft Exchange Server uzmanlarını da yordu.
Çünkü doğru bir Exchange Server tasarımı yapmak için bir-biri ile uyumlu ve uyumsuz Exchange Server Role ve Exchange Server Servislerini iyi bilmemiz gerekmekte ve Exchange Server yeniliklerini de sürekli takip etmemiz gerekmekte.
Ayrıca, doğru bir tasarım yapabilmemiz için Microsoft Exchange Server ‘in kullanmış olduğu çevre birimleri ve bağımlılıklarını da iyi bilmemiz gerekiyor.
Microsoft Exchange Server Kurulum işlemleri için bir çok bağımlılık bulunmaktadır.
Active Directory bağımlılığı ve Windows işletim sistemlerinin bağımlılıkları Microsoft Exchange Server Tasarımlarına ve özellikle Exchange Server DAGs tasarımlarına bire-bir etki etmektedir.
Microsoft Exchange Server evrime uğrarken diğer ürünlerde dönüşüme uğradı. Sağlıklı, doğru ve özellikle desteklenen bir tasarım yapabilmemiz için Microsoft Exchange Server ‘in bağımlı olduğu ürünleri de iyi bilmemiz ve dönüşümlerini takip etmemiz gerekmekte.
Exchange Organizasyonu içinde bulunan üçüncü firmaların Exchange Server için geliştirdiği uygulama ve donanım cihazları da yeni nesil Exchange Server Mimarisine uyumlu olabilmek için bir çok evrim geçirmiştir.
2.Microsoft Exchange Server 2010 DAGs Tasarımı ve Load Balancer Gereksinimi
Microsoft Exchange Server 2010 ile Database Availability Groups mimarisi ile tanıştık.
Exchange Server DAGs mimarisi daha önceki Microsoft Exchange Server mimarilerinde yoktu. Aynı zaman diliminde Exchange Server için Load Balancer zorunluluğu da ortaya çıktı. Daha önce ki Exchange Server alt yapılarında Load Balancer zorunlu değil kuruluş ihtiyacına göre önerilen bir çözümdü. Microsoft firması, Exchange Server 2016 ile birlikte artık Exchange Server High Availability ihtiyacı için üçüncü firmaların ürettiği Load Balancer çözümlerini işaret etmeye başladı.
Load Balancer çözümleri Exchange Server 2016 ‘dan sonra High Availability ihtiyacı için zorunludur.
3.Exchange Server Load Balancer Gereksinimi
Microsoft ‘un ücretsiz çözümü olan Microsoft Laad Balancer Servisi, Exchange Server High Availability çözümleri için kullanılmakta fakat bir takım sınırlamaları vardır. Aşağıda paylaşılan resimde iki farklı Exchange Server Database Availability Groups tasarımını görmektesiniz.
Şimdi bu iki tasarımın artıları ve eksilerini ve gereksinimlerini inceleyelim.
Exchange Server 2010 DAGs Design
Sol tarafta bulunan topoloji içinde, Microsoft Exchange Server organizasyon kurulumu için ihtiyaç duyulan Exchange Server Role ve Exchange Services aynı sunucu üzerinde çalışmakta. Exchange Server organizasyon kurulumu için zorunlu olan iki Exchange Role yani Exchange Server Client Access Role ve Exchange Server Mailbox Role aynı sunucu üzerinde çalışmakta ve bu tasarım günümüz Exchange Server Organizasyonlarında desteklemektedir. Exchange Server 2016 ‘da gelinen mimari de zaten budur. Hub Transport Role ve Client Access Role artık Servis olarak hizmet vermekte.
Bu tasarımda Exchange Server High Availability tasarımı için bir handikap bulunmakta. Eğer, Exchange organizasyonu resimde görüldüğü gibi üçüncü firmaların üretmiş olduğu bir Load Balanger kullanılmadan Microsoft Exchange E-posta sistemi tasarlanırsan, bu e-posta sistemi problemlere gebedir.
Exchange Server High Availability yapılarında Exchange Server Client Access Role ve Exchange Server Mailbox Role aynı sunucu üzerinde desteklenmemektedir. Exchange Server Client Access Role için tasarlanacak olan yedekli mimari Load Balanger çözümlerine ihtiyaç duymaktadırç
Exchange Server Client Access Role, Windows Server işletim sistemi üzerinde Network Load Balancing Serices kullanmaktadır. Exchange Server Mailbox Role ise Failover Cluster Services kullanmaktadır. Bu satır aklımızın bir köşesinde kalsın ve devam edelim.
Exchange Server Database Availability Groups tasarımını gerçekleştirirken Windows Server mimarisini de iyi bilmemiz gerekmektedir. Yukarıda paylaşmış olduğum topoloji içinde Microsoft Technet üzerinde ki açıklamayı de paylaştım. Bu iki Windows Server servisi aynı Windows Server işletim sistemi üzerinde desteklenmemektedir.
İki sunucu ile Exchange Organizasyonu kurulacaksa eğer ve Exchange Server High Availability tasarımı yapılacaksa üçüncü firmaların üretmiş olduğu Load Balancer yazılımına veya cihazına ihtiyaç bulunmaktadır.
Failover Cluster Servisi ve Microsoft NLB servisi aynı Windows Server üzerinde desteklenmez. Sol tarafta ki tasarım içinde bulunan Load Balancer çözümü bu ihtiyacı karşılanmak üzere Exchange Server tasarımı içinde bulunmaktadır.
Database Availability Groups tasarımını gerçekleştirirken sadece Exchange Server odaklı gitmemiz hatalara sebep olacaktır ve bu tasarımda vermiş olduğumuz örnek bunu göstermektedir. Microsoft Exchange server mimarisinin kullanmış olduğu çevre birimleri, uygulamalarda ki sınırlamalar Database Availability Groups tasarımına bire-bir etki etmektedir.
Üçüncü firmaların üretmiş olduğu Load Balancer cihazları Exchange Server 2010 ile birlikte kullanımı başladı ve yaygınlaştı. Her kurum, bu türden bir cihaza sahip değil ve çok uygun fiyata sahip olmayan ürünlerdir.
4.Microsoft Network Load Balancer Service Kullanımı
Sağ Tarafta bulunan topoloji içinde Exchange Server Client Access Role ve Exchange Server Mailbox Role ‘ lerinin yüklü olduğu sunucularının farklı Windows Sunucuları üzerinde çalıştığını görebilirsiniz. Exchange Server 2016 öncesi yapmış olduğumuz Exchange Server tasarımlarına örnektir.
Bu tasarım da Client Access Role ‘nin ihtiyaç duyduğu Microsoft Network Load Balancer servisi Exchange Server Client Access Role yüklü olan sunucular üzerinde çalışmaktadır. Mailbox Role ‘nin ihtiyaç duyduğu Failover Cluster servisi ise Exchange Server Mailbox Role yüklü olan sunucular üzerinde çalıştığını görmektesiniz.
Microsoft Exchange Server Organizasyonu içinde üçüncü firmaların üretmiş olduğu Load Balancer ürünleri yoksa eğer Exchange Server Role dağılım işlemini yapmamız zorunluydu. Exchange Server High Availability ve Database Availability Groups tasarımını gerçekleştirmek için ortamda en az 4 adet Microsoft Exchange Server olması gerekmekte.
Özet ile Exchange Client Accesss Role ile Exchange Mailbox Role hizmetini farklı Microsoft Exchange Server üzerinde çalışması gerekmektedir.
5. Database Availability Groups Lisanslama Maliyetleri Karşılaştırma
Exchange Server High Availability ve Database Availability Groups çözümleri Microsoft Exchange e-posta sistemine sahip kuruluşların BT bütçelerini zorlamaktaydı. Bu büyük bütçeler, bir çok bilgi teknolojileri uzmanının yanlış tasarımlar yapmasına da neden olmuştur.
Ayrıca, Exchange Server ‘in yüklenecek olduğu Windows Server işletim sistemi için de ayrı bir handikap bulunmaktaydı. Hatırlarsanız, Windows Server 2008 sürümleri Standart, Enterprise ve Datacenter olmak üzere üç farklı sürüm vardı ve teknik yeterlilikleri de bir birlerinden farklıydı.
Microsoft NLB Services ‘in sadece Enterprise ve Datacenter sürümleri üzerinde çalışacağını söyleyen danışmanlar vardı ki bu yanlış bir bilgi ve bu kötü bilgi nedeniyle bir çok Exchange Server uzmanı da yanlış yatırımlar yapmıştır.
Microsoft Network Load Balancer Servisi, Windows Server 2008 Standart sürüm üzerinde hizmet verebiliyordu. Failover cluster servisi ise Datacenter ve Enterprise sürümleri üzerinde desteklenirdi. Microsoft Network Load Balancer Servisinin Standart sürümde çalışmayacağını düşünen bir çok kişi gereksiz yatırım yapmış ve Exchange Server Client Access Role hizmetini Windows Server Enterprise ve Datacenter sürümleri üzerinde çalıştırmıştır.
Neyse ki Windows Server 2012 ile birlikte Windows Server işletim sistemlerinin teknik yeterlilikleri eşitlendi de bu yanlış yatırımlar da kısa süre içinde telafi edildi.
6.Exchange Server 2013 Load Balancer Gereksinimi
Exchange Server 2013 ile birlikte ufak ölçekte bir evrim daha yaşadık. Exchange Server Hub Transport Role artık Exchange Server Mailbox Role içinde çalışan bir servisti ve Exchange Server 2013 ile birlikte Hub Transport Role tarihe karışmıştı.
Bu mimari dönüşüm Database Availability Groups tasarımlarına bir etkisi olmadı. Dikkat ederseniz, Exchange Server 2010 üzerinde anlatmış olduğum tasarımlarda Exchange Server Hub Transport Role ile ilgili bir bilgi vermedim. Çünkü Exchange Server Hub Transport Role için Microsoft seviyesinde bir High Availability çözümü bulunmamaktadır. Bu role Exchange Server Client Access Role ve Mailbox Role üzerinde çalışabilen uyumlu bir Exchange Role ‘dir. Microsoft Exchange Server 2013 ile birlikte servis olarak dönüşmesi, tasarımlara etki etmemiştir.
Exchange Server 2013 Dags Design
Fakat, Exchange Server 2013 ile birlikte Microsoft ‘un Exchange Server High Availability ve Database Availability Groups tasarımları için bir Load Balancer çözümünü işaret etmeye başladı.
Exchange Server 2010 ‘dan Exchange Server 2013 sürümüne gelene kadar Load Balancer çözümlerinde de gelişme oldu. Exchange 2010 zamanında fiziksel bir çözüm olan Load Balancer çözümleri artık uygulama seviyesinde çalışabiliyordu. Microsoft Hyper-V veya Vmware ESX Sunucu sanallaştırma platformlarında artık sanal makine olarak hizmet edebilir oldu.
Exchange Server 2013 ile birlikte Load Balancer gereksinimleri Layer 7 seviyesinde ki çözümleri de terk etti. Daha uygun maliyetli olan Leyer 4 Load Balancer çözümleri de artık piyasada bulunmaktaydı. Bu dönüşüm, eskiye göre daha uygun tasarımlar yapmamızı sağladı.
Microsoft, Exchange Server High Availability tasarımları için çizdiği sembollerde Layer 4 Load Balancer çözümlerine yer verdi. Microsoft artık, Windows Network Load Balancer çözümlerinin terk edilmesi gerektiğini belirtiyordu.
Exchange server 2010 ‘da yapmış olduğumuz tasarımların biraz daha gelişmiş sürümünü Exchange Server 2013 için uygulamaya devam ettik. Microsoft Network Load Balancer servisini Exchange server 2013 Client Access Role üzerinde çalıştırabiliyoruz. Aynı Exchange Server 2010 ‘da olduğu gibi.
Windows Server sürümlerinde ki değişim Exchange Server 2013 içinde büyük bir avantaj sağladı. Windows Server 2012 Standart sürümünde desteklenen Failover Cluster servisi için ek maliyetler ödemiyorduk.
7.Exchange Server 2016 Load Balancer Gereksinimi
Exchange Server 2016 Dags Design
Exchange Server 2016 ile birlikte asıl evrimi yaşadık. Artık, Exchange Server Client Access Role yoktu. Exchange Server 2016 ile birlikte Client Access Role evrimleşmiş ve Client Access Services olmuştu. Bu dönüşüm Database Availability Groups Tasarımlarına bire bir etki etti. Exchange Server High Availability tasarımları değişti.
Exchange Server 2016 ile birlikte Microsoft Network Load Balancer servisinin Exchange Server tasarımlarında kullanılmaması gerektiğini belirtiyordu. Zaten desteklenen bir tasarım istiyorsak kullanamıyorduk ve artık üçüncü firmaların Load Balancer çözümleri olmadan Database Availability Groups tasarımları yapamıyorduk.
Exchange Server 2016 üzerinde yapılan bu mimari değişim ihtiyaçları karşılamayan tasarımların yapılmasına neden oldu. Load Balancer ürünü olmayan ve Microsoft NLB çözümünü kullanamayan kuruluşlar Dns Round Robin hizmetini kullanmaya başladılar.
Dns Round Robin hizmeti en az Microsoft NLB servisi kadar eski bir çözümdü, fakat sahip olduğu sınırlamalar nedeniyle tercih edilmiyordu. DNS Cache süresinin uzun olması, kullanıcı bilgisayarına bağımlılık, uygulamayı ve Exchange Servisi dinlememesi tercih edilmeme nedenlerinin başındaydı. Fakat, Exchange Server 2016 ile birlikte artık tek role sahiptik ve Load Balancer çözümümüz yoksa DNS Round Robin hizmeti haricinde kullanabileceğimiz bir çözüm bulunmamaktaydı.
Exchange Server 2016 üzerinde ki bu mimari değişm ister istemez bir çok kurumun Load Balancer çözümleri ile tanışmasına neden oldu ve Exchange Server 2013 ile önerilen çözümler Exchange Server 2016 ile birlikte zorunlu oldu.
