Exchange Server 2007’de Client Access Server rolü authentication, proxy/redirection ve Internet protocol Clientlarına (OWA,EAS,EWS,IMAP ve POP gibi) veri işleyerek hizmet sunarken Exchange 2010’da MAPI içinde CAS kullanılmaya başlanmıştı.
Exchange Server 2013 Client Access Server rolü daha önceki versiyonlarla aynı ismi paylaşmasına rağmen artık bu hizmetler için herhangi bir veri işlemi veya yorumlaması gerçekleştirmiyor. Bu nedenle sadece proxy/redirection sağlayan, Unified Messaging ve transport servisi sunan herhangi bir bağlılığı bulunmayan bir rol halini aldı. (Transport servisi CAS ve Mailbox Server arasında bölünmüş durumda, bu konu ile ayrıntılı bilgiyi yakın zamanda yayınlanacak olan Transport servisi değişiklik makalesinde bulabilirsiniz)
Önceki Exchange versiyonlarında özellikle Exchange 2007 yapısında CPU performansı çok önemli ve o dönemde yüksek performans sağlamak için yüksek masraflar yapmak gerekiyordu bu nedenle Microsoft Exchange yapısında farklı sunucu rolleri sunmuştu. Client Access, Hub Transport, Mailbox, Unified Messaging ve Edge Transport. Bu rol yapısı Exchange 2010’a bire bir taşınmıştı. Bu durum geo-affinity (bütün rollerin aynı AD site içerisinde bulunma gereksinimi), session affinity (layer 7 hardware load balancing) ve namespace (servis adresleri) planlama zorluğu gibi ihtiyaçlara sebep oluyordu. Exchange Server 2013 artık session affinity gerektirmiyor. Bunu daha iyi anlamak için CAS sunucusunun load balancer bulunan bir ortamda protokol seviyesinde yaptığı işlemlere bakarsak:
- Kullanıcı DNS aracılığı ile load balanced virtual IP addresini buluyor.
- Load balancer havuz içerisindeki bir CAS sunucuya kullanıcı oturumunu sağlıyor.
- CAS authentication kullanıcı için authentication işlemlerini gerçekleştiriyor ve kullanıcının Mailbox versiyonu ve Mailbox bilgilerini alıyor. (Database bilgileri, ExternalURL gibi)
- CAS bu oturum için proxy veya farklı bir CAS sunucuya redirect(yönlendirme) işlemlerinden hangisini gerçekleştireceğine karar veriyor.
- CAS Active Manager’ı sorgulayıp hangi Mailbox Server’da kullanıcı mailbox database’in aktif olduğu bilgisini alıyor.
- CAS Mailbox Server’e isteği Mailbox sunucusuna iletiyor. (Proxy işlemi ile)
Eğer kullanıcı HTTP protokolü ile istekte bulunuyorsa altıncı adımda CAS – Mailbox Server iletişimi HTTP protokolü ile (SSL kullanılarak); istek IMAP veya POP ise CAS-Mailbox Server iletişimi IMAP veya POP protokolü ile gerçekleşecektir.
Aşağıdaki diagram sizlere Exchange 2013 Client Access Protocol yapısını göstermektedir.
Resim-1
Beşinci adımda CAS Active Manager’ı sorgulayarak hangi Mailbox Server’da kullanıcı mailbox database’in aktif olduğu bilgisini alması session affinity ihtiyacını ortadan kaldırmış oluyor. Bu sayede kullanıcının mailbox’ının bulunduğu database sunucusu oturum sırasında değişmiş olsa bile isteğin geldiği noktaya bakılmaksızın CAS yeni Mailbox sunucuya bağlantı sağlar.
Forms Based authentication (FBA) için sunulan cookie her Server için farklı bir şifreleme anahtarı kullandığından OWA’da FBA kullanılması durumunda session affinity gereksiniminin bir diğer önemli nedeniydi. Exchange 2013 artık her Server için farklı bir şifreleme anahtarı kullanmak yerine sertifikada bulunan private key’i kullanıyor. Bu nedenle eğer aynı sertifika tüm CAS sunucularda aynı ise, session affinity gerekmeyecektir.
Protokol seviyesinde Client Access Server’ın yaptığı işlemlerin dördüncü adımında proxy veya redirection kullanma kararı verdiğinden bahsetmiştik. Bu aşamada redirection işlemi aşağıdaki koşullardan biri oluştuğunda kullanılır:
- Gelen istek eğer telephony isteği ise UM için redirection kullanılır.
- Eğer OWA için gelen erişim isteği başka bir Active Directory site içerisinde bulunan bir mailbox için ise ve o site içerisinde bulunan CAS 2013 sunucularının ExternalURL değeri isteğe karşılayan ilk CAS 2013 sunucusunun değerinden farklı ise.
- OWA için gelen erişim isteği Exchange 2007 Mailbox Server’da bulunan bir mailbox için ise istek Exchange 2007 CAS sunucusuna redirect edilir.
Sonuç olarak, CAS 2013 artık tamamen gelen isteği aktif mailbox’ın bulunduğu mailbox sunucuya iletmek ve gelen cevabı kullanıcıya sunmak dışında başka birşey yapmıyor.
Dikkat ederseniz şu ana kadar Outlook veya farklı bir MAPI Client için herhangi bir RPC/TCP bağlantısından bahsetmedik. Bunun nedeni, Exchange 2013 RPC/TCP Exchange 2013 CAS tarafından desteklenmiyor. Outlook RPC/HTTP (Outlook Anywhere) kullanarak bağlanmak zorunda.
Daha stabil ve güvenilir bir bağlantı açısından bu önemli bir değişiklik. CAS stateless yani herhangi bir bağlılığı bulunmayan bir rol aldığından RPC/TCP’yi devam ettirebilmek için bu servisin Mailbox sunucusuna taşınaması gerekiyordu ancak bu hizmeti Mailbox sunucuna taşımak demek herhangi bir database switchover veya failover durumunda Outlook’un bağlantısının kopması anlamına gelecektir. Bu nedenle RPC/TCP yerine RPC/HTTP tercih edilmiştir. Bunu sağlamak için ise RPC son noktası için FQDN yerine GUID kullanımına geçilmiştir. Kısaca Outlook kullanarak mailbox erişimi sağlandığında Outlook hesap ayarlarında sunucu ismi yerine mailbox GUID kullanılmaya başlanmıştır. Bu sayede artık mailbox’ın hangi sunucuda aktif olduğunun bir önemi kalmadan CAS gerekli mailbox’a erişim isteklerini iletebilmektedir.
Exchange 2013 CAS yapısındaki değişiklikler sayesinde gelen bir diğer önemli rahatlık ise adres aralığı basitleştirmesidir. (Namespace Simplification). Bu konu Exchange 2010 yapısı kuranlarımız için hep bir soru işareti olmuştur. Serfika üzerinde hangi adresler olacak, iki farklı datacenter modelinde ne tür bir isim yapılandırması gerekiyor gibi sorular hep planlama aşamasında karşımıza çıkan sorulardı. İki farklı datacenter modelinde Exchange 2010 yapısı planlarken genellikle aşağıdaki adreslerin belirlenmesi gerekiyordu.
- Merkez datacenter Internet protocol adresi
- İkinci datacenter Internet protocol adresi
- Merkez datacenter Outlook Web App failback adresi
- İkinci datacenter Outlook Web App failback adresi
- Merkez datacenter RPC Client Access adresi
- İkinci datacenter RPC Client Access adresi
- Autodiscover adresi
- Legacy adresi (Exchange’in önceki versiyonlarından upgrade yapılıyorsa)
- Transport adresi (Şifreleme için)
Biraz önce RPC/TCP kullanımının kalktığını belirtmiştik bu nedenle artık şu adreslere ihtiyacımız yok:
- Merkez datacenter RPC Client Access adresi
- İkinci datacenter RPC Client Access adresi
CAS 2013 için artık Active Directory site bir sınır olmadığından ve mailbox hangi active directory site içerisinde olursa olsun proxy yapabileceği için şu adreslere de ihtiyacımız yok:
- İkinci datacenter Internet protocol adresi
- Merkez datacenter Outlook Web App failback adresi
- İkinci datacenter Outlook Web App failback adresi
Bu değişiklikler sayesinde Exchange 2013 yapımızda sadece şu adresleri kullanarak artık daha basit bir adres yapılandırması kullanabiliriz:
- Merkez datacenter Internet protocol adresi
- Autodiscover adresi
- Legacy adresi (Exchange’in önceki versiyonlarından upgrade yapılıyorsa)
- Transport adresi (Şifreleme için)
Örnek olarak iki datacenter modelinde sadece tek datacenter Internet protocol adresi kullandığımızı ve External DNS için DNS round robin kullandığınızı varsayalım. Bu durumda kullanıcımız adres bilgisini aldıktan sonra herhangi bir Active Directory’deki site’da bulunan CAS 2013 sunucusuna ulaşacaktır ve CAS 2013 mailbox’ın bilgilerini aldıktan sonra site farketmeksizin kullanıcı isteğini o Mailbox sunucusuna proxy gibi davranıp iletecektir.
Resim-2
Tabii ki bu yapıyı kullanmak içinde bazı koşullar bulunuyor. Eğer sitelar arası bağlantılarınız yeterli değil ise halen datacenterlar için Internet protocol adresini farklı tutmak isteyebilirsiniz.
Özet olarak CAS 2013 yapısal olarak köklü bir değişime uğramıştır. Bu değişikliklerin bize daha fazla esneklik sağlayacağı kesin. Exchange 2013 ile gelen transport yapısındaki değişikliklerde CAS rolünün önemi de değişmiştir bu konuyu Transport değişiklerini anlatacağımız makalemizde yakın tarihte bulabilirsiniz.
Bu konuyla ilgili sorularınızı alt kısımda bulunan yorumlar alanını kullanarak sorabilirsiniz.
Referanslar
