Sektörde eski konuları anlatan kaç tane teknik danışman vardır bilemiyorum ama yeni mimarilerin kolaylıklarını gördükten sonra eski zamanlarda “neler yapmışız” demeden sözlere başlayamıyorum…

Exchange server ilk zamanlarda olduğu gibi günümüz şartları içinde iş kritik sunucular arasında yer almakta ve eski sürümleri içinde yüksek erişilebilirlik, kesintisiz çalışma özelliklerine sahipti.

Şimdilerde, Exchange Server 2010 ile birlikte gelen DAG mimarisiyle birlikte veri tabanı seviyesinde iş süreklilik gereksinimlerini esnek, hızlı ve kolay bir şekilde gerçekleştiriyor olsak bile bu kolaylığın geçmişi üzerinden henüz bir nesil bile geçmedi.

Bu makale içinde aşağıdaki alt başlıkları inceleyeceğiz;

• Exchange Server 2007 ile Birlikte Değişim Sürecine Giren Exchange Server Mimarisi
• Exchange Server 2007 Veri Tabanı Seviyesinde Yüksek Erişilebilirlik Çözümleri
• Exchange Server 2010 Veri Tabanı Seviyesinde Yüksek Erişilebilirlik Çözümleri
• Business Continuity Plan (BCP) ve Disaster Continuity Plan (DRP) Farkı
• Database Availability Groups Tasarım Seçenekleri

Exchange Server 2007 ile Birlikte Değişim Sürecine Giren Exchange Server Mimarisi

Exchange 2010’da başlayan ve günümüz sürümü olan Exchange 2016’ da devam eden sürümü anlatmadan önce Exchange Server iş süreklilik planlarını geçmişi ile birlikte anlatmayı, biraz nostalji yapmayı ve sektöre yeni katılmış olan IT Professional unvanına sahip meslektaşlarıma “eskiler nelerle uğraşıyormuş” dedirtmeyi planlıyorum. Belki “ben bunlarla ben uğraşmazdım” derler, kim bilir…

Şaka-şaka.
Böyle bir gayem bulunmamakta.
Gayem, yeni mimaride sunulan kolaylıkları, esneklikleri ve hızlı kurulumların nasıl geliştiğini aktarmak. Yoksa her birimiz, bütün IT Professional unvanına sahip kişiler zaten bilmektedir, teknoloji ilerledikçe yapmış olduğumuz işlerin kolaylaştığını ve bir o kadarda yetişmek için zaman-zaman yavaş kaldığımızı…

Exchange Serverların her bir sürümü için iş süreklilik senaryoları zorunlu olmuştur. Hele ki günümüz şartlarında bu zorunluluk olmazsa-olmaz şartların başında gelmektedir. Exchange 2003’de nasıl yapıldığını aktarmak istedim, evet o kadar geriye gitmek istedim ama ilgili dokümanlar kaldırılmış ve bende çok detaylı hatırlamıyorum artık.
Paylaşımlı bir disk alanı ve aynı özelliklere sahip (donanım ve yazılım seviyesinde) iki sunucunun temel şart olduğunu hatırlamaktayım. Kalan bu bilginin vermiş olduğu tramvayı tahmin edersiniz herhalde. Zaten bu gereksinimleri hatırlayınca bu kadar geriye gitmeye ihtiyaç görmedim. Microsoft’ da ilgili dokümanları kaldırmış ki kendisi de mazisinden çok mutlu değil herhalde diye düşüneceğim derken hatırlıyorum fark ediyorum, o zamanlarda teknoloji bu gereksinimleri kullanmaya zorunluydu…

Exchange Server 2007’de kadar gidebiliyorum.
Exchange 2003 mimarisinin o zamanın şartlarına cevap verememesi nedeniyle gelişen, sahip olduğu rolleri beş parçaya bölen ve o günün şartlarına cevap vermeye çalışan yeni Exchange Server sürümü. Ama bizleri bir o kadarda yoran, kurulum, yükseltme ve bakım işlemlerinde mesleği bırakma düşüncelerine sürükleyen, Exchange Server sürümü.
Exchange 2003’de Backend ve Frontend olarak adlandırmış olduğumuz iki farklı bölüm vardı ve her iki bölüm için ayrı-ayrı iş sürekliliği planları gerçekleştiriyorduk. Kitap okumayı bu dönemde bıraktım zaten, teknik doküman okumaktan kitap okumaya artık fırsat bulamıyordum…

Exchange Server 2003 de bulunan bu iki bölüm aklınızın bir ucunda kalsın, bu bölümlerden makalenin ilerleyen satırlarında tekrar bahsedeceğim.
Exchange 2003 mimarisinin yeni sürümü olan Exchange 2007 piyasaya ilk çıktığı zaman, o zamanın bütün isteklerine cevap verebiliyordu. Bir önceki sürümünde bulunan iki farklı Rol sayısı yeni sürümde beş farklı bölüme ayrılmış ve o günün bütün ihtiyaçlarına cevap vermek üzere mimari değişime gitmişti.

Exchange Server 2007 ile birlikte artık sesli ve anlık iletişim ihtiyacımızı karşılayan Office Communication Server ile Exchange Serverin yeni Rolü Unified Messaging Rolü sayesinde bütünleşik iletişim kurabiliyorduk. Artık sesli ve yakın zamanda görüntülü e-maillerin hayatımıza gireceğini tahmin edebiliyorduk. Zaman ile gelişimden bahsetmiş olduğum konu bu Rol ile ilgili bir durum. Artık iletişim çağındaydık ve sektör yazılı iletişimin ötesinde iletişim kurmak istiyordu.

Bu rol ayrıcalıklıydı ve diğer Rollerden bağımsızdı ve Exchange Server mimarisinde yeni bir roldü.

Yukarıdaki topolojiye bakarsanız eğer, Exchange Server için temel roller olan Client Access Rol, Hub Transport Rol ve Mailbox Rolleri birlikte çalışabiliyorken bu rol tek başına ayrı olarak hizmet ediyordu. Exchange 2007’de gelen bu yeni rolü Exchange 2010 SP1’e kadar sanal ortamda çalıştıramadık. Exchange 2010 Service Pach 1’e kadar temel gereksinimi fiziksel bir kaynaktı. Çünkü bu rol, topolojide göreceğiniz gibi fiziksel bir santral ürünü ile birlikte çalışmaktaydı ve bu sebepten ötürü sanal ortamda hizmet edemiyordu. İlk zamanlar OCS, daha sonra Lync Server ve bu günlerde kullanmaya başlamış olduğumuz Skype for Business sunucunun ilk temelleri, Exchange 2007 UM Rolü ile birlikte atıldı.

O zamanlar bu rolü yapılandırırken diğer taraftan Media Player ile dinlemiş olduğumuz müzikleri Messenger üzerinden paylaşabiliyorduk.

Exchange 2007 ile birlikte yeni bir rolle daha tanıştık. Microsoft’un bugüne hizmet vermediği bir alanda barınan bir ürün. Exchange 2007 Edge Rolü. Bu yeni rol e-mail trafiğini güvenli bir duruma getiren yeni bir Exchange Server rolüudü ve bu rolde Unified Messaging Rolü gibi seçmeli kuruluma sahipti. Exchange organizasyonumuz içine bu Rolü kurmadığımız zaman Exchange organizasyonumuz hizmet verebiliyordu.
Exchange 2007 ile birlikte hayatımıza girmiş olan ve Exchange Server 2016 ile birlikte yaşamaya devam eden bu Rol, daha önceki Exchange Server sürümlerinde bulunmamaktaydı. Bu rolün görevi üçüncü firmaların yazılımları-donanımları tarafından destekleniyordu. Exchange Server Edge Rolünün yapmış olduğu bu görevi üçüncü firmalar halan daha yerine getirebilmekteler.

Exchange 2007 Edge Transport rolü seçmeli bir roldü ve Exchange Organizasyonumuz için koruma sağlamaktaydı. Yukarıda paylaşmış olduğum topolojide göreceğiniz gibi DMZ olarak adlandırmış olduğumuz arındırılmış bölge içinde barınıyordu. Exchange 2007 sunucusunun piyasaya sürülmesi ile aynı zamanda piyasaya sürülen Microsoft Forefront Güvenlik ürün ailesinin bir parçası olan Forefront Security for Exchange yazılımı ile birlikte çalıştığı zaman bütünleşik koruma sağlayan, Exchange organizasyonumuz içinde dahili ve harici saldırılara karşı koruma sağlayan bir üründü ve Exchange organizasyonlarımızı koruyorduk. Exchange 2007 EDGE Rolü ve Exchange 2007 Hub Transport Rolü ile birlikte uyumlu çalışan Forefront Security for Exchange yazılımı ile artık e-mail tarafında ihtiyaç duyulan güvenlik çözümlerini sağlayabilir duruma gelmiştik.

Forefront Güvenlik ürün ailesi yaşamına son vermiş olsa bile Edge Rolü yaşamını sürdürmektedir ve Exchange Server 2016 için seçenekli kurulum olarak hizmet etmeye devam etmektedir.

Özetlemeye çalıştım ve fark edeceğiniz üzere Exchange Server Mimarisi, Exchange Server 2003’den Exchange Server 2007’e gelene kadar köklü bir devrim geçirdi. Sadece tek bir versiyonda ve ileride rol bazlı bu değişimlerden bahsedeceğiz. Ve biz bu makalenin konusu olan Exchange Server Veri tabanı seviyesinde nasıl bir değişim gösterdi bu konuya odaklanalım.

Exchange Server 2007 Veri Tabanı Seviyesinde Yüksek Erişilebilirlik Çözümleri

Exchange 2003 mimarisi içinde Frontend ve Backend olmak üzere iki rol vardı. Frontend demiş olduğumuz Roller, son kullanıcılarımızın posta kutularına erişmek için kullanmış oldukları Exchange Rolü idi. Bugün kullanmış olduğumuz Client Access Rolünün o zamanlardaki ismi. Backend olarak adlandırmış olduğumuz Exchange 2003 Rolü ise Exchange Server veri tabanlarını üzerinde barındıran Exchange Rolü idi. Bugün kullanmış olduğumuz Mailbox Rolü. Aynı zamanda bu rol üzerinde SMTP trafiğini de barındırmaktaydı ki bu Rolde Exchange Server 2007 ve Exchange Server 2010’da ayrı bir rol olarak karşımıza çıkmış olsa bile Exchange 2013 ile birlikte tekrardan Mailbox Rolü üzerine geri geldi ve bugün ki sürüm olan Exchange Server 2016 mimarisi içinde aynı şekilde devam etmekte.

Biz veri tabanı özelliklerine geri dönelim.

Exchange 2003 Fail Over Cluster yapısına göre biraz daha iyileştirilmiş ama aynı temel mantıkta çalışan Exchange 2007 Single Copy Clusters mimarisi ile tanıştık. Bu mimari, Exchange 2003’de olduğu gibi paylaştırılmış bir disk alanı zorunluydu ve Exchange 2003’de olduğu gibi Active-Passive teknolojisi ile hizmet etmekteydi. Single Copy Clusters teknolojisinin sınırlamaları Exchange 2003’den mirastı. O zamanlar paylaşılmış bir disk alanı fazlasıyla masraflı ve her organizasyon içinde bu tür veri depolama ürünlerini göremiyorduk. Veri depolama birimleri haricinde bir diğer masraf fiziksel sunucu masrafıydı. Passive Node olarak yapılandıracak olduğumuz Exchange sunucumuz içinde Active Node’ nin sahip olduğu fiziksel kaynakların aynısı isteniliyordu. Ek bir donanım masrafı ve beraberinde ek bir Windows Lisansı ve Exchange Server lisansı takip ediyordu. Çok masraflı gereksinimlerdi. O dönemlerde Microsoft, Passive Node içinde lisans ücretini istemekteydi ki bugün birçok ürün için Passive Node üzerinde bulunan Microsoft lisansları için ücret ödememekteyiz.

Single Copy Clusters mimarisi biraz masraflı ve her kurum bu masrafları bütçelerine dahil edemiyordu. Ama Exchange mimarisinde iş süreklilik planları her zaman olduğu gibi zorunluydu ve her kurum bir şekilde bu gereksinimi yerine getirmek ve karşılamak istiyordu.

Microsoft bu gereksinimin farkındaydı ve tek bir Exchange server ile bu gereksinimi nasıl karşılayabilirim sorusuna cevabı üzerinde Local Continuous Replication teknolojisi ile cevap vermeyi planlıyordu.

Evet, mimariye baktığınız zaman iş süreklilik gereksinimleri sunucu seviyesinde karşılanamıyordu. Tek bir sunucumuz vardı ve bu tek sunucu erişilmez duruma geldiği zaman hizmet kesintisi oluşuyordu. Ama SCC’ de olduğu gibi ikinci bir sunucu kaynağı masrafı, ortak-paylaşılmış bir disk havuzu ve kullanılmayan pasif durumda çalışacak bir sunucu olmadığı için ek lisans maliyetleri de LCR teknolojisinde yoktu. Evet bu teknolojide tek düğüm hatasında oluşabilecek bir riske karşı bir çözümümüz bulunmuyordu ama Exchange veri tabanlarımızı aynı sunucu üzerinde iki farklı veri depolaması üzerinde barındırıyor ve veri tabanı seviyesinde iş sürekliliğini karşılayabiliyorduk.

Bugüne kadar böyle bir yenilik yoktu ve bu yeni teknoloji ile birlikte birçok çok kurum olmazsa bu olsun deyip Exchange Mailbox sunucularını bu teknoloji ile yapılandırdı.

Exchange 2007 ile birlikte birden fazla iş süreklilik planları ile tanışmıştık ve Exchange 2010’da tanışacak olduğumuz Database Available Group Mimarisinin ilk adımları Cluster Continuous Replication ile atıldı. Bu teknoloji bahsetmiş olduğum diğer iki teknolojiden farklıydı. SCR ve LCR’ den farklı olarak birçok kurumun ihtiyaçlarına cevap verdi ve en çok kurulumunu yapmış olduğumuz iş süreklilik planı olarak projelerimizi süsledi. Cluster Continuous Replication ne yapıyordu ve farkı neydi?

Yukarıdaki topolojide gördüğünüz gibi Active ve Passive olmak üzere iki fiziksel Exchange Mailbox Rolünü görebilmektesiniz. Göremediğiniz ortak, paylaşılmış veri depolama ünitesi. Bu teknolojide masraflı olan ve her kurumun sistem odasına alamadığı veri depolama ünitesi zorunlu değildi ve iş sürekliliği veri tabanı seviyesinde yapılan eşitlemeler ile yapılmaktaydı.

Cluster Continuous Replication teknolojisi veri depolama birimine gereksinim duymadığı için çok tercih edildi. Exchange Server veri tabanları, Exchange Mailbox sunucuları üzerinde bulunan yerel disklerde barınmak üzere dizayn edildi. Elbette bu teknolojinindi bir eksikliği vardı. Ortak-paylaşılmış veri depolama biriminden tasarruf ederken Single Copy Cluster mimarisinde olduğu gibi kullanılmayan pasif durumda bulunan Exchange sunucusu için donanım ve lisanslama yazılımları için yatırımlar yaptık ve gereksinim Single copy Cluster mimarisinde olduğu gibi iki Exchange Server in bir-biri ile eşit özelliklere sahip olmasıydı. Sağlamış olduğu getiri, ortak-paylaşılmış bir veri depolama biriminden tasarruf sağlarken bu teknoloji ile replicasyon mimarisinin getirmiş olduğu maliyetlere de sahip oluyorduk. Single Copy Cluster mimarisin içinde bir tane Exchange veri tabanımız X birimde ise Cluster Continuous Replication mimarisinde 2X birimdi. Yani SCC mimarisinde bir Exchange veri tabanımız 100 GB boyutlarında ise bu veri tabanımız paylaşılmış bir veri depolama birimi üzerinde barındığı için veri depolama birimi üzerinden 100 GB lık bir alanı kullanıyorduk. Ama CCR mimarisinde replicasyon teknolojisi olduğu için, Exchange veri tabanımız iki farklı Exchange Sunucusu üzerinde Active ve Passive olarak iki ayrı yerde barındığı için 100 GB lık bir veri tabanı için 200 GB lık bir disk alanı ayırmak zorunda kalıyorduk. Fak ettiğiniz üzere CCR mimarisinin bir diğer getirmiş olduğu avantaj ortak-paylaşılmış veri depolama birimi üzerinde barınmadığı için veri depolama birimi üzerinde oluşabilecek tek düğüm hatalarından etkilenmiyordu.

Getirisi ve götürüsü çok tartışılan bir teknolojiydi ve bu tartışmalar yaşam süresi içinde cevap bile bulamadan Exchange 2010 DAG mimarisinin gelmesi ile birlikte rafa kalktı.

Exchange 2007 Mimarisi içinde bulunan Standby Continuous Replication teknolojisi; Disaster Recover Plan adımlarını karşılamayan ama Disaster Recovery Plan gereksinimlerini karşılamak üzere dizayn edilmiş bir mimariydi.

Topolojiyi yukarıda görebilmektesiniz. Felaket Konumlandırma Merkezi yani Disaster Recovery Site projeleri yapmış her IT Professional unvanına sahip kişi bu dizayna bir anlam veremeyecektir. Bu topolojiyi kullanmış ve yapmış kişi parmak kaldırırsa aklımdaki soruları sormak isterim.

Bu mimari yokmuş gibi devam ediyorum, o zamanlarda yokmuş gibi davrandım. Neden görmezden geldiğimi Technet dokümanı içinde paylaşılan bilgiyi işaretleyerek aktarmaya çalıştım…

Felaket konumlandırma merkezi projelerinde Exchange server seviyesinde kullanmış olduğum topoloji yukarıda paylaşmış olduğum topolojiydi. Topolojiye dikkatli bakarsanız eğer, merkez site olarak adlandırılan Redmond Active Directory Site içinde Exchange 2007 Sunucuları için Cluster Continuous Replication çözümü uygulanmış. Bu topoloji içinde Redmon Merkez site iş süreklilik planına uygun olarak dizayn edilmiş ve Exchange Server 2007 Veri tabanları tek düğüm hatasından kaynaklanabilecek bir problemin yaşanılmasından kaçınılmış.

Quincy olarak adlandırılmış olan Felaket Konumlandırma merkezinde tek düğüm mimarisini görebilmektesiniz. Bu bir seçenektir ve bildiğiniz üzere FKM yerleşimleri felaket yaşanılmadığı sürece bir öneme sahip olmayan ölü yatırımlardır.

Bu konu çok derin bir konu ve her kurumun ayırmış olduğu bütçe, kurum içinde barınan teknolojiler, kurumun barınmış olduğu coğrafya ve kurumun felakete bakış açısı ve beklentilerine kadar birçok değişken FKM Projelerine, dizaynına etki eden projelerdir. Bu günlük bu konu için yeterli olmayacak ve asıl konudan bizi ayıracak bir konu olduğu için başka bir günlüğe bu konuyu saklıyorum.

Business Continuity Plan (BCP) ve Disaster Continuity Plan (DRP) Farkı

Geçmişte bu konuya özel etkinlikler gerçekleştirmiştik ve o zamanın şartlarına özel derinlemesine konuşma fırsatı bulmuştuk. Bir başka etkinlikte yapmış olduğumuz müzakerelerde tekrar çözümler aramış ve Business Continuity Plan (BCP) ve Disaster Continuity Plan (DRP) nedir sorularına cevap vermeye çalışmıştık.

Exchange 2007 veri tabanı seviyesinde gerçekleştirilen iş süreklilik planlarını bahsetmeye çalıştım.

Fark ettiğiniz üzere Exchange Server 2007 zamanında bu işlemler hiç kolay değil ve bir o kadar karmaşık, uzmanlık gerektiren işlemlerdi. Son bahsetmiş olduğum topolojiyi yapan kişi sayısı çok az ve neredeyse bir elin parmaklarını geçmiyor. Bu ve benzeri projeyi yapan kişiler ise parmakla gösteriliyordu.

Geçmiş zamanda konuşmuş olduğumuz Business Continuity Plan (BCP) ve Disaster Continuity Plan (DRP) Farkı konulu seminer videosunu izleyebilirsiniz.

Exchange Server 2010 Veri Tabanı Seviyesinde Yüksek Erişilebilirlik Çözümleri

Exchange Server 2010 piyasaya sürüldüğü zaman bütün uzmanlar yorulmuştu. Exchange Server 2007’nin sahip olduğu mimari zor, karmaşık ve derin teknik bilgi istiyordu. Microsoft’ da bu eksi yönlerin farkındaydı ve yeni mimaride Database Availability Groups teknolojisi ile tanıştık. Exchange 2007’de bahsetmiş olduğumuz topolojilerin hiçbir tanesi artık yoktu. Sizlere aktarmaya çalışmış olduğum topolojilerin her birisi üç sene yaşayabildi ki zaten ilk duymuş olduğumuz zamanlarda çok fazla yaşamayacağını da öngörmüştük.

Yeni DAG mimarisi ile birlikte kullan at olarak adlandırmış olduğumuz just a bunch of disks (JBOD), diskleri Exchange mimarilerimiz içine dahil edebilir duruma geldik. Bundan iki nesil önce ortak, paylaşımlı veri depolama üniteleri yüksek erişilebilirlik mimarileri için olmazsa olmaz şart iken bugün ucuz dikler ile çözüm üretebiliyorduk. İsteyen Exchange server mimarisini Sata diskler üzerinde hizmet ettiriyor isteyen daha kaliteli diskler ile çözümler üretebiliyordu. Exchange 2007 mimarisinde en fazla 8 adet Mailbox Sunucusunu tek bir düğüm içinde çalıştırabiliyorken Exchange 2010 DAG mimarisi Windows Failover cluster mimarisinin sahip olduğu sınırları kullanıyor ve tek bir düğüm içinde en fazla 16 adet Mailbox sunucusunu barındırabiliyordu.

Exchange Mailbox sunucusu oluşturulan DAG’ in bir üyesi yapılıyor ve Mailbox sunucusu üzerinde bulunan Exchange Veri tabanını küme içinde bulunan başka bir sunucuya eşitleyebiliyordu. Dag mimarisi yüksek erişilebilirlik senaryolarının her birisini karşılayabiliyor ve küme içinde oluşabilecek Sunucu arızası, ağ hatası gibi nedenlerden ötürü veri tabanında oluşacak başarısızlıklara karşı otomatik kurtarma senaryosu sunuyordu.

Exchange 2010 DAG mimarisi Felaket senaryoları içinde hazırlıklıydı. Merkez site içine kurmuş olduğumuz DAG mimarisini farklı bir coğrafya içine Site Resilience teknolojisi yardımıyla eşitleyebiliyor ve Felaket senaryoları için çözümler üretebiliyorduk.

Database Availability Groups Tasarım Seçenekleri

Değişim gösteren, esnekleşen ve dağılan Roller ile birlikte her kurum için doğru-yanlış olmak üzere bir çok farklı tasarımları gerçekleştirdik. Yapılan bu tasarımların bir çoğu kurumların ihtiyaçlarını karşıladı veya günü kurtardı diyebiliriz. Exchange Server 2010 ile başlayan Dag serüveni bu günde devam etmektedir ve Exchange Server 2010’dan miras kalan bir çok tasarımı bu gün yani Exchange Server 2016 ile birlikte kullanabilmekteyiz.

Belirttiğim gibi yapacak olduğumuz tasarımlar sadece fikir vermek adına paylaşılmış tasarımlar olmakta ve ihtiyaçlarınıza göre ve kullanmış olduğunuz üçüncü firma ürünlerin konumlandırmalarına göre değişkenlik gösterebilecek ve esnekleşecektir.

ilk paylaşacak olduğum DAG Tasarımı iki mailbox sunucusuna sahip Exchange organizasyonu için geçerlidir. Paylaşmış olduğum bu tasarım Exchange 2010 ile birlikte bir çok kuruma hizmet etti ve ben de bir çok kurum içinde bu yanlış yapılandırmaları gördüm. Bu tasarım TechNet üzerinde paylaşılan bir tasarım örneğidir ve bir çok danışmanın bu tasarımdan ilham alarak benzer kurulumları yaptığını bilmekteyim.

Exchange Server 2010 temel rolleri yani Client Access Rol, Hub Transport Rol ve Mailbox Rollerini tek bir sunucu üzerinde barındırabilmekteyiz ve kurulumu yapabilmekteyiz. Exchange 2010’da bulunan bu Roller şimdiki sürüm olan Exchange Server 2016’da servis olarak hizmet etmekte ve aynı mimariyi bu günde kullanabilmekteyiz. Bu eski tasarımı ilk paylaşmamda ki neden benzer kurulumların Exchange Server 2016 içinde yapılacağını ön görmemden kaynaklıdır ki ben demiştim diyebilmek için buraya not düşüyorum…

TechNet üzerinde paylaşılan bu dokümanda tasarıma baktığımız zaman Exchange Server Dag mimarisi iki düğümden oluşmakta ve düğüm aynı zamanda Client Access Rolü içinde dizayn edilmiş. bu tasarım sonrasında veri tabanı seviyesinde ve Client Access Rol seviyesinde iş süreklilik ihtiyacını karşılamış.

Şimdi, bilinen o soruyu soruyorum. Çok gezen mi (yani tasarımı sadece gören ve yorumlayanlar için bu soru) mi bilir yoksa çok okuyan mı?

Tasarıma baktığınız zaman yapacak olduğumuz mimari özeti aşağıda ki gibi;

1. iki farklı Exchange Server üzerine bütün Rolleri kuralım.
2. Mailbox Rol için Windows Failover Clustering servisini kuralım.
3. Client Access Rol için Windows Network Load Balancing servisini kuralım.
4. CAS array ve DAG mimarisini ise aynı sunucular üzerinde hizmet ettirelim.

Bu tasarıma bakıp, TechNet dokumanı içinde detayları okumadığımız zaman hataya düşme olasılığımız kaçınılmaz ve korkarım bu hata silsilesi Exchange 2016 içinde devam edecek. Çünkü bu konu ile ilgili bir çok soru ve mail almaktayım.

TechNet dokumanı içinde bulunan ilgili satırı Sarı olarak işaretledim ki açıklamada belirtilen “Windows Network Load Balancing servisi ve Windows Failover Clustering servisi aynı sunucu üzerinde desteklemez. Kullanılması gerekli olan çözüm ve yani tasarım içinde işaret edilen ve dokumanın devamında açıklanan çözüm Client Access Rolü için üçüncü firmaların sağlamış olduğu bir load balancing kutu veya yazılım çözümüdür”

Bu tasarımda Client Access Rolü için ihtiyaç duyulan iş süreklilik çözümü Windows Network Load Balancing çözümü değildir. Bir-biri ile zıt olan bu iki rolü aynı windows işletim sistemi üzerine yüklenememektedir..!

Aynı tasarım aynı kural Exchange Server 2016 içinde geçerlidir. Hatırlayalım, Exchange Server 2016 Kurulumu ve Etki Alanı Yapılandırılması makalesinde Client Access Rolünün artık bir Rol değil bir Servis olduğunu günlüğüme not düşmüştüm. Exchange Server 2016 için iki düğümden oluşan bir DAG kümesi kuracaksanız ve Client Access Rolü için iş süreklilik planı oluşturacaksanız Exchange Server 2016 ile birlikte üçüncü firmaların sağlamış olduğu Load Balancing ürünü kullanmak zorunlu. Exchange Server 2016 ile birlikte “Windows Network Load Balancing” desteği bitti açıklamaları da bunu desteklemekte.

Üçüncü firmaların sağlamış olduğu Load Balancing çözümü için bir bütçe ayırmadım ve kurumum içinde böyle bir bütçem yok diyorsanız takipte mesafesini yakın tutmanızı önereceğim, günlükte bu konu ile ilgili konu yakın bir tarihte gerçekleştirilecektir.