Performans tabiki başlı başına bir konu, ancak hep bu şekilde yaklaşıldığı için genellikle en az kaynak bulunan konular performans ve sorun çözümüdür. Bende eğer sonunu getirebilirsem çok güzel bir makale serisine başladığımı düşünüyorum.
Konumuz çok net, MTA noktasında çok yüksek bir pazar payına sahip olan Exchange Server 2010 için yaşanan pek çok yönetim zorluğunun yanında büyük organizasyonlarda ek olarak performans sorunları da gözlemlenmektedir. Malum küçük yapılarda temel olarak satın alması yapılan sunucular Exchange server mimarisine hizmet etmek için yerli iken, 500, 1000 veya 5000 üstü kullanıcısı olan kurumlar için çok ciddi sunucu alt yapılarının tasarlanması gerekmektedir.
Her ne kadar bu şekilde bir alt yapı tasarlanmış olsa da bu tür büyük yapılarda ani veya uzun süreli performans sorunları yaşanabilmektedir.
Aslında bu performans problemleri daha çok istemci tarafında yani outlook yazılımlarının direkt olarak exchange server üzerinden çalıştığı senaryolarda gözlemlenmektedir ( online mode ).
Online mode olarak isimlendirdiğimiz bu mode ciddi manada sistem kaynağı kullanan bir çözümdür. Bunun temel sebebi her bir outlook istemci programındaki hareket ( mail okuma, silme, değiştirme, taşıma vb ) aslında direkt olarak Exchange Server mailbox sunucularının diskleri üzerinde I/O yapmaktadır. Oysaki cache mode kullandığınız zaman bu tüm hareketler kullanıcı lokal disklerinde olup kısa gecikmeler ile bu tüm hareketler exchange server üzerindeki kullanıcı posta kutusu ile replike olur.
Yukarıdaki resimde cache mode çalışacak şekilde ayarlanmış bir outlook programını görüyoruz.
Eğer terminal server gibi bir yapı kullanıyorsanız cache mode kullanmanız bir hayli zor olacaktır. Bu zorluğun en temel kaynağı bir sunucuya 50, 100 belki 250 kullanıcı bağlanacak ve hepsinin ortalama 1GB lık posta kutusu olsa cache mode nedeni ile 250GB lık disk kullanımı olacaktır. Dahası bu disk kullanımı işletim sistemi performansına da yansıyacaktır. Ek olarak Load balance cihazları ile yönetilen bir RDS sisteminde yine keza cache mode sorun teşkil edecektir.
Bu nedenle bu ve benzeri durumlarda cache mode yerine online mode kullanmak zorunda olabilirsiniz. Durum böyle olunca zaman zaman kullanıcılardan outlook ların yavaş çalıştığına dair geri dönüşler alabilirsiniz. Eğer sadece Exchange Server’ a özel bir storage mimariniz yok ise bu muhtemel disk sorunlarıdır. Ancak her zaman disk sorunu demek doğru olmaz. Genel olarak bu şekilde yorum yapmamın sebebi aşağıdaki gibi bir kullanım alışkanlığımızın olmasıdır.
1 Fiziksel server üzerindeki lokal disklerde kurulu sanal makine içindeki exchange server’ ın sanal disklerinde mailbox data base açtığımız için
1 fiziksel server üzerindeki lokal disklerde kurulu exchange server içerisinde mailbox database açtığımız için
1 fiziksel server üzerindeki RAID yapılı lokal disklerde kurulu exchange server içerisinde mailbox database açtığımız için
1 veya daha fazla fiziksel sunucuya bağlı ortak ( file server, portal, exchange, sql, backup vb ) storage diskleri üzerinde mailbox database açtığımız için
En doğru ve ideali ise tabiki maliyetli bir durum, birden çok exchange server mailbox role yükleyip, bunlara sadece exchange server için dedike edilmiş bir storage bağlamaktır.
Durum bu olsa bile yinede bu yavaşlık noktasında kontrol etmeniz gereken noktaları iyi biliyor olmanız gerekmektedir.
Performans problemleri temel iki nedenden ortaya çıkmaktadır
1 – Beklenmeyen yükler
2 – Sistem kaynaklarındaki Darboğazlar
Beklenmeyen yüklerden kastımız, örneğin gün içerisinde posta kutularının arşivlenmesi, yine gün içerisinde yedek alınması, gün içerisinde kullanıcı posta kutularının taşınması, yani aslında gün içerisindeki rutin yoğunluğun dışında ek olarak sistemlere getirecek her yük beklenmeyen yük ve performans problemi olarak görülebilir. Net bir örnek vermek gerekir ise, arşivleme için Symantec EV programını kullandığınızı düşünün, rutin bir şekilde çalışan bu sistem birden yönetici tarafından rapor alınmak için kullanılabilir. Yani tüm posta kutularındaki arşiv yüzdesi nedir diye bir rapor çekmeniz demek her bir posta kutusuna bağlanıp boş alan ve kota bilgisinin kontrol edilmesi demektir. Bu da size performans problemi olarak dönebilir.
Diğer başlık ise mevcut sistem kaynaklarınızdaki dar boğaz. Örneğin sahip olduğunuz üzerinde yüklü olan bir backup, log yönetimi, izleme programları ve benzeri bir agent’ ın aniden aşırı ram veya başka bir sistem kaynağı kullanması ile mevcut exchange hizmetlerinde performans yaşanacaktır. Veya gündüz yedek alınması disklere iki kat yük bindireceği için, veya ortak bir storage kullanıyorsanız bu storage üzerindeki diğer sistemlerin anormal bir şekilde disk kullanımı ve benzeri mevcut kaynaklardaki dar boğaz performans sorunlarına neden olacaktır.
Burada çözüm için eğer ortamınızda SCOM ürünü var ise bunun üzerinden rapor almanız mümkündür.
Bu işin biraz kolay yanı, ancak taktir edersiniz ki her şirket ortamında SCOM veya benzeri bir monitoring yazılımı bulamayabiliriz.
Bu durumda biz Windows Server tarafından bize sunulan performans counter ları ile çözüm yolunu bulmamız gerekmektedir.
İlk olarak Exchange Server istemci tarafında bir yavaşlık söz konusu ise, ben ilk olarak aşağıdaki counter’ ı kontrol ederim
MSExchangeIS Client (*)\RPC Average Latency
Sunucu için RPC isteklerindeki gecikme değerini ms olarak gösterir. Bu değer son 1024 paket içerisindeki geçikme süresinin ortalamasını ms cinsinden gösterir. Bu her bir istemci için 50ms den düşük olmalıdır. Bu süre sunucuya gelen bir isteğin store.exe tarafından işlenip cevap dönülmesi için geçen süredir. Ancak burada önemli olan bu sürenin network gecikmeleri ile ilgili bir bilgi içermiyor olmasıdır. Bunu yazmamın sebebi latency yani gecikme kavramı network tarafında çok kullanıldığı için öyle yanlış bir algı oluşuyor bu süre tam olarak yukarıda yazdığım gibi “sunucuya gelen bir isteğin store.exe tarafından işlenip cevap dönülmesi için geçen süredir” tabiki son 1024 paket için ortalama bir değer verir.
MSExchangeIS Client\ RPC Average Latency
All instances seçmemin sebebi tüm mailbox veri tabanları için ortak bir değer öğrenmek istememdir.
Yukarıdaki şekilde kırmızı ile işaretlediğim counter benim için kritik bir counter olup istemcilerin outlook programlarının yavaş cevap almalarının temel sebebidir.
Tabiki bu değer 90 iken aslında çok ciddi sorunlar yaşamazsınız. Her ne kadar 50ms değerinden bahsediyorsak bile bunu aslında aşağıdaki gibi bir tablosu bulunmaktadır.
500 Kullanıcıdan az olan ortamlarda bu değer 15ms den düşük olmalı
500 – 3000 kullanıcı arasındaki ortamlarda bu değer 30ms den düşük olmalı
3000 ve üzeri için ise 50ms den düşük olmalıdır.
Bu değer 100ms ve üzerinde ise bu durumda outlook programında istemci tarafında aşağıdaki gibi bir pop-up çıkacaktır.
Bu da kullanıcıların mail okumalarını, işlemelerini ve benzeri operasyonlarını ciddi manada etkileyecektir.
Burada bir önemli noktayı daha sizlerle paylaşmak istiyorum. RPC Average Latency bazen yanıltıcı değerler sunmaktadır. Eğer istemcileriniz online mode kullanıyorsa ve çok büyük boyutlu posta kutularında son derece kompleks aramalar yapıyorlar ise bu durumda geçici olarak counter değeri yüksek çıkar. Ancak bu genel bir sorun olduğu anlamına gelmez. RPC değeri uzun bir süre örneğin yarım saat boyunca yüksek çıkıyor ise bu durumda sebeplerini kontrol etmeliyiz. Ancak anlık pikler için aksiyon almaya gerek yoktur.
Bu tür kullanıcı aksiyonlarından doğacak ve geçici olan değerleri görmezden gelebilirsiniz.
Peki gelelim bunun nedenlerine. Yani kullanıcılardan bir isyan noktasına gelen dönüşler almaya başladınız. Hemen counterları kontrol ettiniz ve RPC Average Latency değerinin 150ms lerde dolaştığını gördünüz. Bu durumda ne yapmalı?
Yukarıda bahsettiğim gibi iki ana sebep ile böyle bir sorun yaşıyorsunuzdur
1 – Beklenmeyen yükler
2 – Sistem kaynaklarındaki Darboğazlar
Yük noktasını kesinleştirmek için size tavsiyem PAL aracını en az yarım gün veya iş çok kritik ise en azından bir yarım saat çalıştırın ve rapor alın. Rapor size zaten son derece net bilgiler verecektir.
Örnek bir kaç tane rapor görüntüsü paylaşıyorum ( PAL için detaya girmedim çünkü bu konuda yazılmış bir makale hali hazırda portalımızda var ve bende yukarıdaki Sözlük linki içerisinde bunun olduğunu bildiğim için ek olarak burada paylaşmıyorum. )
Yukarıda da görüldüğü gibi son derece detaylı raporlar sunmakta olup disk okuma yazma hızları başta olmak üzere, CPU, RAM ve benzeri tüm kaynakların raporunu sunmaktadır. Bu rapor size aşırı bir yük mü yoksa sistem tarafındaki bir dar boğaz mı olduğunu gösterir.
Örneğin yukarıda örnek raporlarını paylaştığım sunucu için durum ciddi manada disk yetersizliği gibi görünmektedir.
Bu durum eğer uzun süre devam ediyor ise yeni bir disk kümesi, yeni bir LUN veya yeni bir storage mimarisine geçmeniz gerekmektedir. Veya mevcut bir sunucu üzerinde ise tüm mailbox veri tabanları bunu ek bir sunucu + storage ile ikiye bölebilirsiniz.
Evet, makalemin bu ilk bölümünde genel olarak istemci tarafındaki bağlantı sorunlarına değinmeye çalıştım. Malum söz konusu Exchange server olunca yazacak, anlatacak çok şey var ama bende zamanımın ve tecrübemin el verdiği ölçüde makalenin ilk bölümünü tamamladım. Bir sonraki bölümde görüşmek üzere.
Konu ile ilgili aşağıdaki video yu izleyebilirsiniz
