Exchange Server 2016 ile birlikte Exchange Server mimarisinin değiştiğini ve bu mimari değişikliğin de Exchange Server tasarımlarına etki ettiğini konuşmuştuk

Exchange Server 2013 zamanında kullanılan Client Access Rol artık bulunmamakta.

Bu görev Exchange Server Mailbox Rol çatısı altnda bir servis olarak yani Client Access Services olarak hizmet vermekte.

Bu değişiklik Exchange Server 2016 zamanında oldu ve Exchange Server 2010 yada Exchange Server 2013 ‘den Exchange Server 2016 yada 2019 sürümlerine upgrade yapmak isteyen kurumlara Load Balanger maliyeti olarak yansıdı.

Halbu ki ilk tasarım eskiden de önerilmekteydi fakat destek kapsamı içindeydi..

Exchange Server Logad Balanger Gereksinimi adlı çalışmada bu tasarımın şartlarını dile getirmiştik ve bir kez daha hatırlatma yapalım.

Load balanger hizmeti iş süreklilik hizmeti için zorunlu olsa da load balanger için üçüncü taraf firmaya finansal yatırım yapmak zorunlu değildi.

Bu finansal yatırımı ya dolaylı yoldan Windows Server Lisansı ve Exchange Server lisansı olarak bana vereceksin yada işi bu olan işi network olan firmaların üçüncü taraf yük dengeleme çözümlerine yatırım yapacaksın demekteydi.

Bir önceki çalışmamızın özetini de böylelikle yapmış olduk ve Exchange Server e-posta sistemleri için load balanger ihtiyacının olduğunu hatırladık.

Bu çalışmada ise Load Balanger tasarımı nasıl yapılmalı ve eğer load balanger çözümü yoksa ne yapabiliriz bunları konuşacağız.

Bir önceki derste konuşmuş olduğumuz, Exchange Server Logad Balanger tasarımlarını silmedim.

Bu iki tasarımında Exchange Server 2016 yada Exchange Server 2019 e-posta sistemleri olduğunu var sayalım.

Biliyorsunuz 2016 ile birlikte artık sadece Exchange server Mailbox Role bulunmakta ve Client Access Rol ‘de Mailbox Role çatısı altında servis olarak hizmet vermekte.

Şimdi ilk sorumuzu soralım.

Load Balanger çözümü yoksa nasıl bir tasarım yapmalıyız.

Ön uçta durmakta olan Exchange server Mailbox üzerinde hiç bir şekilde Exchange database barındırmayacağız ve hiç bir kullanıcı posta kutusu da bu exchange Serverlar üzerinde hizmet vermeyecek.

DNS ‘de ise bu iki exchange Server erişim yolu için bir CNAME oluşturacağız ve bu cname kaydı da exchange server internal url ve external URL ‘de tanımlı olacak.

Kullanıcılar DNS üzerinden round Robin hizmetini kullanarak bu Cname kaydına gelecekler ve DNS ‘de kullanıcıları posta kutularına yönlendirecektir.

Posta kutularına yönlendirme işlemi de Active Directory yardımıyla yapılmakta.

Kullanıcıların, barınmış olduğu Exchange Server Database bilgisi kullanıcı özniteliklerinde saklanmakta ve bu erişim de active Directory kütüphanesi içinde bulunan kullanıcı bilgileri ile yapılmakta.

Iç erişimi sağladık.

Bu tasarım desteklenmekte ve iç ağda erişimi sağladık.

Peki ama dışarıda ne olacak, şimdi ikinci sorumuzu sorduk ve bu soruya da cevaplar verelim.

Içeride DNS Round Robin hizmeti var ve bu da isim tabanlı olarak yük dengeleme hizmetini yaptırmakta.

Dışarıda ise en az iki adet Public IP adresine ihiyacımız bulunmakta ve böylece Içeride yapmış olduğumuz Cname kayıtlarının bir benzerini public dns üzerinde ve external erişimlerde de yapabilmekteyiz.

Eğer, bir yük dengeleme yazılımı yada donanımı yok ise her bir exchange server için ayrılmış public IP adresine ihtiyacımız vardır.

Her bir exchange Server ‘I ayrılmış bir exchange server olarak düşünüp ayrı-ayrı dış dünyaya açmamız gerekmektedir.

Bu iki exchange server da aynı organizasyon içinde bulunduğu için iç networkde yapmış olduğumuz cname kayıtlarını da public DNS üzerinde yapmamız gerekmektedir.

Harici kullanıcılarımız bu kayıtlar üzerinden güvenlik duvarına ulaşacaklar güvenlik duvarı da kullanıcı taleplerini ön uç da bulunan Exchange serverlara ulaştıracaktır.

Kullanıcı talepleri, ön uçta bulunan exchange server a ulaştıktan sonra iş artık exchange organizasyonun da bitmekte ve aynı iç ağ da olduğu gibi active directory den destek alarak kullanıcı posta kutusuna ulaşmaktadır.

Evet bu tasarım desteklenen bir tasarım olsa da hataya açık bir tasarımdır ve çok fazla önerilmez.

Kullanan var mı diye soracaksınız evet kullanan bir çok firma da bulunmakta fakat isim tabanlı bir yönlendirme olduğu için bir çok problemi içinde barındırmakta ve problem anında çözüm süreleri de uzamaktadır.

DNS Cache olarak bildiğimiz DNS tepki süreleri de problem olmadığı zamanlarda başımızı ağrıtmaktadır.

Üçüncü sorumuz, Bu süreler ve bu problemlere bir çözüm var mı diye soracaksınız, cevap, evet var.

Bulut tabanlı yük dengeleme ürünleri ile bu problemlere çözümler üretmekteyiz.

Azure Load Balanger çözümü azure bilgi işlemde çalışan sanal sunucu, hizmet ve uygulamalar için kullanılan bir yük dengeleme çözümüdür.

Azure Trafik manager ise Azure Load Balanger çözümüne ek olarak azure bulut bilgi işlemde çalışmayan sunucu, hizmet ve uygulamakar için kullanılan bir yük dengeleme çözümüdür

İç ağ da yük dengeleme ürünü olmayan firmaları Azure Trafik Manager ile desteklemekteyiz.

DNS tabanlı hatalardan etlilenmemesi için tasarımlar yapmakta ve load balanger ürünlerine yatırım yapmadan bulut tabanlı çözümler ile ihtiyaçları karşılamaktayız.

Parolasız koruma çözümlerinde konuşmuştuk.

Ikinci güvenlik duvarları ve bulut tabanlı çözümler konu başlığında ATM çözümlerine örnekler vermiştik.

Bu tasarımlara yük dengeleme çözümü ile birlikte bulut tabanlı güvenlik çözümlerini de eklemekte, yük dengeleme, iş sürekliliği ve güvenliği bulut tabanlı çözümler ile sunmaktayız.

Bu bütünleşik çözümlerler ile koruma, süreklilik ve BCP çözümlerini de sunmaktayız.

Bu çözümler Exchange server 2013 ‘de yapılmaktaydı ve Exchange Server 2016 ile yapmaya da devam ettik.

Bu tasarımlar Exchange server 2019 için de desteklenmektedir.

Eğer, ikinci tasarım da olduğu gibi yük dengeleme yazılımlarına, yük dengeleme donanımlarına yatırım yapmadan süreklilik ve güvenlik ihtiyacınız varsa bulut bilgi işlem çözümleri ihtiyaçları karşılayacaktır.

Zaten bir yatırım yapıldıysa, bir yük dengeleme çözümü varsa ve bu çözüm de ikinci firewall gibi çalışıyorsa tasarımlarımızı Exchange Server 2013 ‘de yaptığımız gibi yapmaya devam edebiliriz.