Exchange Server Load Balancer Gereksinimi

Опубликовано: 27 Март 2026
на канале: pera2005
1,951
like

#exchangeserver #fatihkaraalioglu #pera2005

Bu çalışmanın blog yazısına aşağıda ki adresten ulaşabilirsiniz.
1. https://pera.net.tr/blog/exchange-ser...
2. https://pera.net.tr/blog/microsoft-ex...

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.