Exchange 2010 Client Access Yapısında Yüksek Erişilebilirlik için Yük Dağılımı – 3.Bölüm

closeBu yazı 6 yıl 3 ay 21 gün önce yayınlanmış olduğundan güncelliğini yitirmiş veya içeriğindeki bilgilerin geçerliliği kaybolmuş olabilir. Herhangi bir yanlış anlaşılmadan bu site sorumlu değildir.

1. Bölümde Exchange CAS yapısına Exchange 2007 ve 2010 için baktık.

2. Bölümde Client Access Arrays ve öneminden bahsettik.

Bu makale serisinde amacımız Client Access sunucularda yük dağılımlarını nasıl yaparız konusunda bilgi sağlamak olduğundan Client Access Servisleri bizim için önemli.

HTTP Trafiği Kullanan Servisler

  • Outlook Web App Exchange
  • Control PanelExchange
  • Web ServicesExchange
  • ActiveSync
  • Autodiscover
  • Offline Address Book
  • Outlook Anywhere

RPC Trafiği Kullanan Servisler

  • RPC Client Access

Bu servislere baktığımızda RPC Client Access servisi dışında bütün servislerin HTTP trafiği kullandığını aklımızda bulundurmamız gerekiyor. Senaryolardan bahsederken RPC yi neden ayrı ele almamız gerektiğini daha iyi anlayacağız.

İlk senaryomuz ile başlayalım.

Bu senaryomuz da 1 site içerisinde 2 adet Exchange 2010 sunucumuz var ve her iki sunucumuz üzerinde de Client Access, HUB ve Mailbox rolleri bulunuyor. Hatırlarsanız Exchange 2007 Cluster ortamlarında bunu yapmamız mümkün değildi Cluster yapısında buna benzer bir yapı oluşturmak istediğimizde  2 CCR node ve 2 HUB/CAS olmak üzere en az 4 sunucuya ihtiyaç duyardık. Exchange 2010 Database availabilty group kısaca DAG yapısının sağladığı esneklikler sayesinde bu yapıyı artık Exchange 2010 da kullanabiliyoruz.

Bu senaryomuza baktığımız zaman karşımıza basit bir yapı çıkıyor. Kullanacağımız 2 client access server için bir array oluşturarak ve bu array IP adresini Hardware Load balancer tarafından kullandırarak yüksek erişilebilirlik sağlayabiliriz. Bu senaryoda Array için database lerimizin RPCCLientAccessServer değerini belirtmemiz yine unutmamamız gereken bir adım. Burada yük dağılımına ek olarak amacımız servislerin mümkün olduğunca kesinti durumunda kullanıcılar tarafından hissedilmeden diğer sunucuya devrinin sağlanması.

Hardware Load Balancer kullanmanın bir diğer avantajı da SSL Accelaration kullanabilecek olmak. SSL Acceleration sayesinde bütün SSL Encryption ve Decryption işlemlerinin Client Access sunucular üzerinde oluşturduğu yükü hardware load balancer üzerine alabilirsiniz bu işlemde sunucular üzerinde CPU yükünü azaltır. Security açısında farklı ihtiyaçlarınız yoksa bu işlem özellikle hardware yetersiz olan ortamlarda işinize yarayabilir.

Özet olarak bu senaryo basit olmasına rağmen en efektif çözümlerden biri olarak karşımıza çıkıyor. İstenilen bütün Client Access servislerinin yük dağılımını kullanacağımız hardware load balancer üzerinde gerçekleştirmemiz mümkün.

Hardware load balancer kullanırken servisler için farklı persistence (affinity) yöntemleri kullanabiliriz.

Persistence load balancerların istemci ve sunucu arasında ki bağlantının devamlılığını sağlama yöntemi olarak adlandırılabilir. Servisler için kullanılabilecek farklı persistence yöntemleri bulunmaktadır Exchange 2010 Client Access Servislerinde bu değerler hakkında birkaç öneri var.

Outlook Web App (OWA), Exchange Control Panel (ECP) – Source IP address veya ister varolan Browser-Based veya Hardware Load Balancer tarafından oluşturulan cookie kullanılabilir. Her iki methodda sorunsuz olarak istenen hizmet kalitesini arttıracaktır ancak kullanıcılar aynı IP adresi üzerinden geliyorlarsa bu durumda cookie kullanmak daha avantajlı olacaktır. SSL ID tabanlı persistence kullanımında IE8 yeni mesaj oluştururken, contact oluştururken ve benzeri istekleri yeni bir pencerede farklı bir worker process kullanarak yapacağından tekrar authentication isteyecektir bu nedenle SSL ID kullanılan persistence modelleri tercih edilmesi önerilmemektedir.

Exchange ActiveSync (EAS) – Exchange ActiveSync için Client IP (source IP address) veya Authorization header önerilmektedir. Ancak eğer active sync kullanan kullanıcılarınız aynı IP adresinden geliyorsa ki bu bazı durumlarda gsm operatorünüzün NAT ayarlarına bağlı olarak olma ihtimali düşükte olsa bulunan bir durum o zaman Authorization header daha iyi bir çözüm gibi görünebilir. Ayrıca mobil cihazlar SSL negotiationları sık tekrar ettiğinden yine SSL ID tabanlı persistence bu servis içinde önerilmemektedir.

Outlook Anywhere (OA) – Source IP address, Authorization header veya Outlook Session cookie tabanlı persistence kullanılabilir. (Bu arada bir not: Outlook Session persistence Outlook 2010 öncesi bulunmamaktadır) Bu nedenle ortamınızda Outlook 2010 öncesi bir istemci kullanıyorsanız bu yöntem tercih edilmemelidir.

IMAP, POP3, Autodiscover– Bu servisler için herhangi bir persistence yöntemine gerek bulunmamaktadır.

RPC Client Access Service (RPC CA); Exchange Address Book Service- Bu servisler için önerilen persistence yöntemi Source IP Address (Client IP Address)tir.

Exchange Web Services (EWS)- için önerilen Cookie veya SSL ID dir.

Burada farklı servisler için farklı persistence yöntemlerinden bahsettim ancak biraz önce servislere baktığımızda çoğunun http trafiği kullandığından söz ettim bu nedenle kullanacağınız Load Balancer modelinde split-persistence yapmak durumunda kalabilirsiniz veya aynı portu kullanan servisler için aynı yöntem ile ilerleyebilirsiniz. Örneğin OWA, ECP, EAS, Exchange Address Book Service için aynı port üzerinde Source IP Address kullanmanız mümkün. Ama hardware load balancer kullanmayı planlıyorsanız size split-persistence kullanmanız önerilen bir yöntem.

Peki bu senaryoda neden Windows Network Load Balancer kullanmadıkta Hardware load balancer gibi third party bir ürün kullanma ihtiyacı duyuyoruz?  Aslında bu senaryo da ortamda DAG olmasa ve her iki sunucu da standalone çalışıyor ve sadece Client Access sunucuların yük dağılımını yapıyor olsaydık sorun yoktu ancak DAG kullanıldığından dolayı Cluster servisleri her iki sunucuda da aktif kullanılmakta. Neden kullanmadığımıza dönersek bunun nedeni hardware paylaşım çakışmaları. Windows Network Load Balancer ve cluster servisinin aynı sunucu üzerinde bulunması halinde karşılaşabileceğiniz can sıkıcı durum olarak isimlendirebiliriz.

Bu yöntem Microsoft tarafından desteklenmediğinden dolayı kullanılması önerilmemektedir. Kısaca ya Windows NLB ya da Cluster servisini seçmeniz önerilmektedir.

Ekranda bu konu ile ilgili bilgi veren Microsoft Support makalesini görebilirsiniz. Bu bilgiye 235305 nolu support makalesinden ulaşabilirsiniz.

Microsoft Exchange 2010 ile kullanılmasını önerdiği Hardware ve Software load balancer modellerini düzenli olarak güncelleyerek yayınlıyor. Buradan bu modelleri öğrenebilirsiniz. Başlıca markaların Exchange yapısına uygun olarak ayarlanması için gereken dokümantasyonlara da yine bu adres üzerinden ulaşmanız mümkün olacaktır.

Yayınlayan: Serkan Varoğlu

Yıldız Teknik Üniversitesi Elektrik Mühendisliğini bitirdim. Türkiye'de birçok farklı sektör ve firmada Sistem Yöneticiği yaptım. Bermudada 3 yıla yakın danışmanlık yaptıktan sonra şu anda İrlanda'da çalışma hayatıma devam ediyorum.