Exchange Server Role Konsalidasyon süreci Exchange Server 2007 ile birlikte başlamış ve günümüz e-posta sistemi olan Exchange server 2019 ile devam etmiştir. Her bir sürüm ve her bir Exchange Server Cumulative Update paketinde de bu değişim de devam etmektedir.
Exchange Server Role Konsalidasyon süreci Exchange Server mimarisinde değişiklikler yapmış ve bu değişiklikler de Exchange Server Business Continuity Plan çözümlerine etki etmiştir. Exchange Server Business Continuity Plan çözümlerini eskiden Exchange Server Rolleri seviyesinde yaparken şimdi ise Exchange Server seviyesinde bu planları yapmaya başladık.
Exchange Server Dag mimarisi özelinde yedeklilik planı, iş süreklilik planı ve felaket konumlandırma çözümlerini ayrıca konuşacağız. Onlar ayrı başlıklar, bizler bu çalışmamız da erişim çözümlerini nasıl yedekli yapmalıyız, nasıl yük dengeleme çözümlerini kullanmalıyız bunları konuşacağız.
Bu çalışmamızla birlikte daha önce paylaşmış olduğumuz Exchange Server Erişim yolları çalışmalarını da desteklemiş olacağız.
Exchange Server Logad Balanger Gereksinimi
Derse başlamadan önce ilk olarak şunu belirteyim, Exchange Server 2013 zamanında kullanmış olduğumuz Microsoft Network Load Balanger çözümü Exchange server 2016 ile birlikte terk edilmiştir. Artık Windows NLB desteği Exchange Server için desteklenmiyor ve e-posta sistemlerinde Windows NLB Servisini kullanan müşterilere destek verilmiyor.
Biraz geçmişe gidelim ve bunun nedenini sizlere paylaşalım.
Exchange Server 2013 zamanında yapmış olduğumuz temel yedeklilik planı bu şekildeydi.
Ön uç da bekleyen en az iki adet Exchange Server Client Access Rol sunucusu Windows NLB Servisi ile bir küme oluyor ve Exchange Server erişim yöntemleri için yük dengeleme ve iş süreklilik sağlıyordu.
Arka uçta bekleyen en az iki adet Exchange server Mailbox Rol sunucusu da Windows Fail over cluster servisi ile bir küme oluyor ve veri tabanı seviyesinde yedekli olarak çalışıyordu.
Exchange Server 2013 zamanında yapılan iş süreklilik çözümleri bu şekildeydi.
Bu tasarım, Exchange Server e-posta sisteminde, fiziksel yada sanal üçüncü taraf bir yük dengeleme çözümü olmadan kullanılıyordu ve Windows NLB Servisi de bu ihtiyacı karşılıyordu.
Şimdilerde ne oldu, Exchange Server Rol Konsalidasyon süreci ile birlikte neler değilti, şimdi bunları konuşalım.
Windows Server desteğine baktığımız zaman Fail Over Cluster servisi ve Windows Network Load Balanger servisi ayını Windows Server üzerinde desteklenmez.
Bu nedenden ötürü eski e-posta sistemlerinde Exchange Server Client Access Rol ve Mailbox Rol ayrılmış sunucular üzerinde tasarlanırdı.
Eğer, kuruluş sanal yada fiziksel bir yük dengeleme cihazına sahipse ne yapılıyordu şimdi bunu incelelim.
Kuruluşun sahip olduğu load balanger cihazı ön uçta hizmet vermekte ve arkasında duran Exchange Server sunucularını desteklemekteydi.
Her bir exchange Server üzerinde Client Access Rol ve Mailbox Rol bulunmakta.
Iki farklı exchange rol, aynı sunucu üzerinde barınabilir ve bu da desteklenmektedir.
Günümüz Exchange Server 2019 ‘da zaten bu mimari de çalışmaktadır ve Exchange Sunucuları üzerinde Windows Network Load balanger servisi yüklü durumda değil.
Windows NLB ‘nin yapmış olduğu işi bu tasarımda fiziksel yada sanal yük dengeleme cihazı yapmaktadır.
Client Access Rol ve Mailbox Rol aynı exchange server üzerinde çalışmakta ve windows Server seviyesinde sadece Failover cluster servisi hizmet vermektedir.
Windows Failover Cluster Servisi Sunucular üzerinde çalışmakta ve Windows NLB Servisi de kullanılmadığu için bu tasarım desteklenmektedir.
Resme uzaktan baktığımız zaman Exchange Server 2016 ‘da ki tasarımı görebilirsiniz.
Bu gün de Exchange server 2019 ‘da bu tasarımı kullanmakta, Client Access Rol değil de Client Access Services olarak çalışmaktadır.
Exchange server 2013 zamanına geri dönelim ve bu gün kullandığımız Exchange server 2016 yada 2019 ‘un henüz konsolide olmadığını düşünelim ve Iki tasarım arasında ki farklara bakalım, artıları ve eksileri inceleyelim.
Birincisi tasarımda 4 adet Exchange Server var, iki tanesi ön uçta çalışmakta iki tanesi de arka uçta hizmet vermekte.
Ön uçta duran Sunucular üzerinde Exchange Server Database bulunmamakta ve kullanıcı posta kutuları burada barınmamakta.
Ön uç sunucularına yani Exchange Server Client Access Rol sunucusuna gelen talepler arka uçta bulunan mailbox sunucularına yönlendirilmekte.
Bu yönlendirme hizmeti Exchange server proxy servisleri tarafından yapılmaktadır.
Exchange server eğitim serimizi takip edenler hatırlayacaklar.
Active Directory derslerinde bu erişim yollarını ve servisleri detaylı olarak çalışmıştık.
Active Directtory Site and services mimarisi ve Exchange Server Mail Flow mimarisini bu çalışmalarımız da masaya yatırmıştık.
Exchange Server 2013 zamanında proxy olarak hizmet veren erişimler artık Mailbox Transport Servis, Hub Transport Services ve Front end Transport services olarak konsolide olmuştur.
Yeni mimarinin en büyük artısı bu, Client Access Rol artık proxy görevini yapmamaktadır. Yapmış olduğu özel durumlar var da var Exchange Server upgrade projeleri yada Exchange Server Cross Forest Migration projelerinde bu servis bu günde kullanılmakta.
Ama temel erişim çözümleri için kullanılmamaktadır.
Iki tasarım arasında ki artı ve eksileri konuşuyoruz demiştik, işte en büyük artı da bu.
Eğer, fiziksel yada sanal bir yük dengeleme çözümü kullanıyorsak e-posta akışları ve erişimi çok daha sağlıklı olmaktadır.
Biraz da şirket bütçelerine etkisini, Load Balanger kullanan firma ile kullanmayan firmaların yaptıkları yatırımları, maliyetleri inceleyelim.
Göze ilk çarpan yatırım load balanger maliyetini görmektesiniz.
Maliyet avantajı olarak ilk tasarım daha uygun gibi gözükse de unutulmamalı ilk tasarımda da yapılmış olan bir exchange server lisans maliyeti bulunmakta.
Ilk tasarım da 4 adet Exchange server lisansı ve 4 adet de Windows Server lisansı varken ikinci tasarım da 2 adet Exchange Server lisansı ve 2 adet de Windows Server lisansı bulunmakta.
Ikinci tasarım üçüncü taraf bir yük dengeleme cihazına yatırım yaparken ilk tasarım da finansal yatırım Microsoft ‘da yapılmış durumda.
Microsoft o zamanlar da bu duruma ne demekteydi.
Yedeklilik ve iş sürekliliği istiyorsan parayı ya bana vereceksin yada üçüncü taraf bir bir yük dengeleme cihazına vereceksin.
Şimdi ne demekte.
Parayı, işi bu olan işi network seviyesinde yük dengeleyen, networkü dinleyen, networkü bilen firmaya ver, parayı doğru ürüne yatır ben ise arka tarafta senin e-posta hizmetini sağlıklı ve güvenli bir şekilde çalıştırayım demektedir.
Bu günlerde kullanmış olduğumuz tasarım da zaten ikinci tasarımdır ve bir sonraki bölümde Exchange server 2016 ve 2019 için Load Balanger tasarımını ve Load Balanger ürünü yoksa ne yapabiliriz bunları konuşacağız.
Ayrıca, microsoft ‘un değişen fiyatlandırma politikasını, Business Continuity Plan çözümlerine etki eden maliyet avantajlarını da Exchange Server DAG çalışmalarımız da sizlere sunacağız.
Bu Vlog çalışmasını destekleyen blog yazısına Microsoft Exchange Server DAGs ve Load Balancer Gereksinimi makalesinden ulaşabilirsiniz.
