Exchange Server 2016 ile beraber yıllardır kullanmış olduğumuz ve bu geçen yıllarda sürekli olarak mimari, role değiştiren bir ürünün günün sonunda tekrar eski yapısına döndüğünü görüyoruz. Zamanın ve teknolojinin gereksinimleri gereği aslında tek bir sunucu hizmeti olarak başlayan Exchange server yıllar içerisinde 5 Role, 3 Role ve geldiğimiz noktada yine tek sunucu rolü ile hizmet vermeye devam etmektedir. ( Edge rolü hariç tutulmuştur ). Özetle eskiler bilir aradaki 2003, 2007, 2010 v2 2013 den sonra tekrar tek role mimarisi ile ilerliyor olacağız.
Tabi ki üründeki tek yenilik mimari tarafta değil, bu konu zaten makalenin önemli bir bölümünü kaplayacak ancak onun dışında üründe pek çok yeni özellikte bulunmaktadır. İlk olarak akıllara gelen şu soruyu cevaplamak isterim, “Exchange Server 2016 ya geçmeli miyiz?” Tabi ki bu şirket ihtiyaçlarına göre değişen bir durum, makaleyi okuduktan sonra belki sizin için çok önemli be beklediğiniz bir özelliğin olduğunu görecek ve geçme kararı alacaksınız, ama hemen yine sektörde çok akla gelen konu ürün ne kadar hazır? Malum üzülerek te olsa itiraf etmek gerekir ki Exchange Server 2013’ ün ilk sürümleri, 2010 dan sonra bir hayal kırıklığı oluşturdu, çünkü 2010 çok kararlı bir sürümdü, ancak 2013 sanki biraz aceleye getirilmiş gibiydi, ben RTM sürümünü incelerken hala bazı yerlerde Exchange 2010 ibaresini görüyordum, bunu zaten sektörden de tecrübe eden çok oldu ne yazık ki, sütten ağzı yanan yoğurdu üfleyerek yer misali geçenlerde twitter üzerinden yaptığım ankette gördüm ki en az SP1 beklentisi var, haklısınız ancak o zaman yine yazdığım makale, forum postu ve benzeri paylaşımlarıma bakacak olursanız ürünün henüz çok kararlı olmadığını paylaşmıştım, yine tam tersi olarak Exchange Server 2013 CU2 den sonra ise işler değişti, şu anda geldiğimiz noktada ise 2013, 2010 gibi oldu, yani ürün çok kararlı ve herkes çok memnun, 2010, 2013 geçişinde olduğu gibi şimdi 2013 süper çalışıyor 2016 acaba noktasındayız. Ancak rahat olun bu konuda da aktif olarak sahada danışmanlık ve proje yaptığımız için tüm tecrübelerimi yine sizler ile paylaşıyor olacağım.
Neler yeni?
Öncelikle CPU maliyetlerinin düşmesi ile artık yönetimsel zorluklar getiren çoklu role modeli artık teke düştür. CAS ve HUB transport yok ( Exchange 2013 de zaten ilk olarak HUB transport rolü kaldırılmıştı). Sadece mailbox rolü var artık. Tabii kitabi olarak yazarsak aslında tek role değil, çünkü EDGE kurmanız halinde iki role ama malum EDGE gerekli bir role olmayıp bütçesi olan kurumlar bunun yerine SMTP GW ürünü kullanıyor bu nedenle ben tek role olarak anlatıyor olacağım.
Özetle, Exchange Server 2016 da Mailbox server eski yapıdan bildiğimiz tüm role sorumluluklarını tek başına yerine getirebilmektedir
Client Access protocols, Transport service, Mailbox databases, Unified Messaging.
Bu yeni mimari sayesinde çok büyük yapılarda bile geçiş projeleri kolaylaşmıştır. Çünkü yeni mailbox sunucu rolü gelen trafiği Exchange 203 den 2016 ya yönlendirebildiği gibi, 2016 ya gelen trafiği de 2013 e yönlendirebilmektedir (Proxy).
Aşağıdaki resim konuyu daha iyi anlatmama yardımcı olacaktır.
Bu mimariye single building block deniyor, yani tek bir mimari ile küçük şirketler veya global şirketler mail hizmeti alabiliyor.
Yapın son derece basit çalışıyor, Mavi ile gösterilen çizgiler mail trafiğini gösteriyor, internet üzerinden yani dış dünyadan gelen mailler öncelikle EDGE ( zorunlu değil ) veya bir SMTP GW’ e iletilir, küçük kurumlar dahil günümüzde artık Firewall ile beraber gelen SMTP GW özellikleri dahil bir koruma katmanı kullanıyor. Bu katmandan sonra ise eğer tek Mailbox sunucu var ise ona, birden çok mailbox sunucu var ise öncelikle birine veya yine bütçeniz var ise bu birden çok olan mailbox sunucu için bir NLB cihazı alarak mail trafiğini onun üzerinden ilgili mailbox sunucularına iletebilirsiniz. Benzer şekilde koyu renkli çizgi ile gösterilmiş olan istemci istekleri de NLB veya direkt olarak Exchange Server Mailbox sunucusuna gitmektedir. Eğer Exchange Online Protection kullanıyorsanız da sarı renkli çizgi ile onun da mail iletimi ile aynı yolu kullandığını göreceksiniz.
Sunucuların arasındaki trafik ise yine Exchange Server 2013 de olduğu gibi “every server is an island” her sunucu kendi başına bir ada mantığı ile devam ediyor. Yani burada aslında mimari olarak eski ve kararlı yapı korunmuş.
Sunucu arası iletişim protokol seviyesinde gerçekleşmektedir. Örneğin bir snucu üzerindeki transport servisi diğer sunucu üzerindeki transport servisi ile görüşür, yani çapraz görüşme olarak nitelendirdiğimiz bir sunucudaki transport servisi diğer sunucu üzerindeki business Logic veya storage seviyesi ile direkt iletişim kuramaz.
Peki yeni mimaride Mailbox Server neler yapıyor? Aslında eski mimarideki tüm rollerin sorumluluklarını yerine getiriyor;
Transport servis sayesinde mail trafiğini yönetir
Mailbox database sayesinde maillerin saklanmasını sağlar.
Client Access servisleri sayesinde istemci isteklerini karşılar. Ek olarak routing veya proxying yapar.
UM desteği sağlar
Eskiden olduğu gibi yine yönetimi Exchange Admin Center veya Exchange Management Shell – PS ile yapabiliyoruz.
Peki, ilk olarak transport servisi için detay inceleme yapmak gerekir ise mail iletimi aşağıdaki gibidir;
Temel olarak 3 bileşenden oluşan bir mail iletim mimarimiz vardır.
· Front End Transport service on Mailbox servers
· Transport service on Mailbox servers
· Mailbox Transport service on Mailbox servers
o Mailbox Transport Submission service
o Mailbox Transport Delivery service
Ek olarak
· Transport service on Edge Transport servers
Front End Transport service
Bu servisin temel görevi tüm gelen ve giden SMTP trafiğini yönlendirmektir. Mesaj içeriği ile ilgilenmez, mesajları kuyruklamaz yani bekletmez, doğrudan Mailbox Tranport servisi ile konuşamaz, gelen mesajı hızlı bir şekilde transport servisine iletmek başlıca görevidir. Aynı şekilde transport servisinden gelen mesajı da göndermek. Bir nevi şirketlerdeki karşılama masası gibi geleni yönlendiriyor, içeriden gönderilen evrakları da benzer şekilde doğru yere iletilmesini sağlıyor.
Transport service
Bu servisi aslında Exchange server 2010 HUB sunucu rolünün sanallaştırılmış hali gibi düşünebilirsiniz. Organizasyonunuzdaki tüm SMTP trafiğinin gerçekleşmesini, mesajların kategorize edilmesini, mesaj içeriğinin kontrol edilmesini sağlar. Ancak doğrudan postaları posta kutularına bırakmak için mailbox database ile iletişimi yoktur. Yani maillerin posta kutularına iletimi için bir ara katman daha kullanılır (Mailbox transport service). Özetle SMTP için Front End, Mailbox transport ve duruma göre Edge transport arasındaki trafiğin sorunsuz bir şekilde gerçekleşmesini sağlar. Temelde 4 görevi vardır
· SMTP Receive
· Submission
· Categorizer
· SMTP Send
SMTP Receive
Bir mail geldiğinde transport servisi bu maili alır, mesaj içeriğini mevcut kurallar çerçevesinde kontrol eder, transport rule var ise uygular, anti-spam ve anti-malware özellikleri açık ise yine benzer şekilde bu kuralları da işletir. Aslında mail kabul edilmeden bu işlemlerin bazılarını gerçekleştirmek zorundadır. Yani anti spam özelilği açık ve IP reputation yada black list var ise zaten smtp session seviyesinde paket kabul edileyeceği için transport rule işletme veya benzeri işlemler hiç bir zamna gerçekleşmez. Mesaj bir şekilde kabul edilir ise artık submission kuyruğuna gönderilir.
Submission
Aslında iletim kuyruğu olarak isimlendirilebilir. Mailin kategorizasyonunun yapılması için bir yerde tutulması gereklidir. Receive connector, Pickup klasörü veya transport agent üzerinde mail kabul etmektedir.
Categorizer
Temel görevi mail için alıcıların belirlenmesini sağlar. İlk olarak top-level dediğimiz ve bir grup içerisinde olmayan yani maildeki direkt mail adresi tanımlı ( ad üzerinde ) kişileri bir liste halinde hazırlar ve bunu ilerleyen aşamada kullanmak için cache alır. Daha sonra eğer gelen mail içerisinde dağıtım grupları var ise onu genişletir ve yine alıcı listesini oluşturur, alıcıların limitleri veya okundu, iletildi gibi farklı ayarları var ise mesajların kopyasını oluşturur ve sonuç doğrultusunda bu mailin nasıl iletileceğini belirler (routing resolution). Ek olarak organizasyon seviyesindeki mail akış kuralları da uygulanır. Kategorizasyon tamamlandıktan sonra mesaj delivery queue – iletim kuyruğuna bırakırlır.
SMTP Send
Bir mail için nasıl iletileceğine kategorizasyon sırasında karar verilir, yani bir route çizilir, bu route aşağıdaki gibi olabilir;
Aynı Mailbox sunucusu üzerindeki bir Mailbox Transport servisi
Farklı bir Mailbox sunucusu üzerindeki bir Mailbox Transport servisi ( DAG var ise aynı DAG üyesi)
Farklı Active Directory forest, Active Directory site veya DAG üyesi bir mailbox server üzerindeki transport servisi
Eğer mail internete gidiyor ise;
Aynı mailbox server üzerindeki bir send connector
Başka bir mailbox server üzerindeki transport servisi
Eğer outbound Proxy ayarı yapılmış ise aynı veya farklı bir mailbox sunucusu üzerindeki Front End transport servisi
EDGE yüklü ise EDGE üzerindeki Transport servisi
Olabilir.
Mailbox Transport service
Adından da anlaşılacağı üzere posta kutularına direkt erişimi olan katmandır. Temel olarak iki alt servisten oluşur, Mailbox Transport Submission service, bu servis RPC üzerinden local mailbox database ine bağlanır ve mesajları çeker, yani dış dünyaya veya bir başka posta kutusuna iletilecek olan mesajları alır ve bir üst takman olan transport servisine iletir. Mailbox Transport Delivery service ise tam tersi posta kutusuna gönderilen maili yine RPC üzerinden iletmek için kullanılır. Her iki serviste hiçbir şekilde mail kuyruklama yapmaz ve yine direkt olarak Front End servisi ile görüşemez. Yine bu iki servis mail iletimi için eğer posta kutusu yerel değil ise direkt olarak posta kutusunu saklayan mailbox server üzerinde çalışan Transport servisi ile görüşebilir
Transport service on Edge Transport servers
Eğer EDGE rolü kurarsanız mailbox sunucu üzerindeki Transport servisine benzer bir rol üstlenir, yani SMTP tarafında dış dünyadan gelen maili almak ve iletmek, içeriden dış dünyaya gönderilen maili almak ve yine iletmekten sorumludur.
Anlattıklarımızı özetlemek gerekir ise dışarıdan gelen bir mail aşağıdaki gibi posta kutusuna iletilmektedir.
Eğer ortamınızda EDGE rolü yüklü ise mail akışı aşağıdaki gibidir;
Dışarıya gönderilen bir mail için ise akış aşağıdaki gibidir ( EDGE rolü yüklü değil ise )
Burada bir istisna söz konusudur. Normalde mail 1-2-3-4 şeklinde ilerler, ancak 4 nolu adımda iki farklı durum söz konusudur Varsayılan olarak mail Submission servisi tarafından alınır, transport servisine iletilir ve transport servisi bunu ya direkt olarak muhatabına SMTP protokolü ile gönderir veya önündeki bir EDGE, SMTP GW’ e iletir. Ancak siz varsayılan bu ayara ek olarak oluşturacağınız bir send connector ile dışarıya gönderilen maillerin birden çok olan posta kutularından değil de bir tane seçtiğiniz bir posta kutusu sunucusu üzerindeki Front end servis üzerinden dış dünyaya çıkmasını isterseniz, bu durumda mailler bir üst katmandaki servise çıkar ve oradan gönderilir
Yukarıdaki gibi send connector oluştururken Frontend Transport seçebilirsiniz.
EDGE rolü yüklü ise dış dünyaya gönderilen maillerin akışı aşağıdaki gibidir;
Evet, bu bölüme kadar temel olarak Exchange Server 2016 Mimari yeniliklerinden rol yapısı ve bu role yapısı içerisindeki ana unsur olan Mail akışını detaylandırdım. Bir sonraki bölümde ise Client Access Protokol mimarisinden bahsedeceğim.
Kaynak
https://technet.microsoft.com/en-us/library/jj150540(v=exchg.160).aspx
