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

closeBu yazı 5 yıl 10 ay 26 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.

3.Bölümde İlk senaryomuzda Hardware Load Balancer kullandık ve bu Hardware Load Balancer kullanırken dikkat etmemiz gereken bazı konulardan bahsettik.

Makale serimizin bu son bölümünde geri kalan senaryoları inceleyeceğiz.

İkinci senaryomuz ilkine göre daha çok sunucu kullandığımız ve rolleri böldüğümüz bir senaryo. Bu senaryo da 2 adet Client access server ve HUB rollerine sahip sunucumuz ve 2 adette mailbox sunucumuz bulunuyor. Bu yapıda Array IP adresimiz Windows NLB tarafından kullanılacak ve ilk senaryoda bahsettiğim gibi RPCClientAccessServer bilgisinin database ayarlarında düzeltilmiş olması gerekiyor. Bu bilgiyi tekrarlayıp duruyorum ama en çok yapılan hatalardan biri Client Access Array yaratıldıktan sonra önceden kullanılan databaselere bu değerin verilmemesi oluyor.

DAG yapısı her senaryoda aktif durumda. Bu senaryoda Load balancing için Windows NLB kullanıyoruz. Bunun nedeni biraz öncede açıkladığım gibi Mailbox sunucular ayrı olduğundan CAS sunucularda artık cluster servisine ihtiyacımız yok. Cluster servisi olmadığından Windows Network load balancer kullanmamızda bir sakınca da bulunmuyor.

Windows Network Load Balancerlar Hardware Load balancerlar ile karşılaştırıldığında daha düşük bir kapasite sağlıyor gibi görünebilir ancak yine de büyük sayılara ulaşan bir kullanıcı bağlantı havuzunu rahatlıkla yönetebilir. 7 veya 8 CAS sunucuya kadar herhangi bir performans sıkıntısı yaşatmaz. 8 ve üzerine çıkılması durumunda ki bu çok yüksek sayıda kullanıcı anlamına geliyor performans sıkıntısı yaşamanız mümkün.  Bir diğer önemli eksiği ise biraz önce bahsettiğimiz önerilen persistence yöntemlerinden sadece Source IP yi desteklemesi. NAT uygulanmış Source IP’den gelen kullanıcıların hepsi aynı source IP olarak algılanacağından gelen bütün kullanıcıların tek bir Client Access Sunucu üzerine toplanması durumu oluşabilir.

Bu senaryonun en büyük avantajı ise Network Load Balancer özelliğinin Windows ile birlikte geliyor olması ve ücretsiz olup işini tam yapması diyebilirim.

Bu senaryo da Hardware Load Balancer kullanmamız da tabi ki mümkün ama maliyet yükseleceğinden yönetim tercihine kalabilir.

3. Senaryomuzda DNS Round Robin kullanarak Client Access Server array’i sunuyoruz. Hardware Load Balancerımız yoksa tercih edebileceğimiz bir yöntem. Arada herhangi bir başka ürün veya cihaz olmadığında gayet efektif bir çözüm olacaktır.

Burada array için DNS üzerinde iki farklı ip adresi veriyoruz ve TTL değerini düşük tutuyoruz. Bunun amacı sunuculardan herhangi birinde sıkıntı olursa sorunlu sunucunun DNS kaydını silerek bütün clientları diğer sunucuya göndermek. Load Balancer, ISA, TMG, UAG gibi urunler serverınızın çalışmadığı durumları anlayıp trafigi yönlendirmeyi kesebilir ama DNS için böyle bir durum söz konusu olmayacağından bu işlemi manuel yapmamız gerekecek.

Otomasyon sağlamadığından bu yapı yüksek erişilebilirlik için tam ihtiyacı karşılayamıyor gibi gözüksede en ucuz çözüm olarak ta seçimlerimiz arasında bulunabilir.

4ncu senaryomuzda ISA/TMG/UAG kullanacağız. ISA/TMG/UAG Windows Network Load Balancerlara göre daha fazla özelliğe sahip olmasına rağmen RPC trafiğinin yük dağılımını yapamıyorlar. Bu nedenle ISA/TMG/UAG kullandığınızda RPC trafiği için yine farklı bir yük dağılım modeli seçmek gerekecek.

ISA/TMG/UAG maliyet olarak Hardware Load Balancerdan ucuz Windows Network Load Balancerdan pahalı olacaktır. Persistence açısından ISA TMG UAG  cookie oluşturabilir, Source IP kullanabilir. Ayrıca ISA/TMG/UAG preauthentication yapabildiklerinden herhangi bir sunucuya yönlendirilmiş olan kullanıcı serverda sorun yaşanması durumunda tekrar authentication safhasından geçirilmeden yeni Client Access Server a yönlendirilebilir.

Bu son senaryomuz ile konumuz tamamlandı. Bu konu ile ilgili 11 Ağustos 2010 tarihinde sunduğum Webcast’i Videolar Sayfasından seyredebilirsiniz.

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.