Başarılı bir Exchange yapısında monitoring tamamlayıcı önemli bir parçadır. Bu serimizde Exchange Server 2013 ile gelen Managed Availability özelliğini sizlere aktarmaya çalışacağım. Managed Availability’nin nasıl çalıştığını ve nasıl yönetildiğini anlatmadan önce Exchange Team tarafından alınan kararların ve bu yapının nasıl planlandığını anlamak gerekiyor.
Daha önceki Exchange sürümlerinde, korelasyon motoru geliştirmek için Exchange ekibi büyük yatırımlar yapmış ve Exchange ortamlarında geniş kapsamlı bir uyarı çözümü sağlamak için System Center Operations Manager (SCOM) ürün grubu ile yakın çalışmıştı.
Geleneksel olarak, monitoring veri toplama içeriyor ve eğer gerekliyse toplanan verilere dayalı bir eylem gerçekleştiriyor. Örneğin, SCOM ortamında, Exchange Management Pack ile veri toplamak için farklı mekanizmalar kullanılmıştı.
Exchange Server 2013 Monitoring Hedefleri
Exchange 2013 geliştirmeye başladığında, asıl odak noktası dünyadaki en küçük on-premise ve en büyük bileşenlere hitap eden Office 365’te tüm Exchange bileşenleri için uçtan uca görüntüleme geliştirmekti.
1. On-premises müşterilerine Office 365 te edinilen tüm bilgi ve deneyimleri aktarmak.
Yaklaşık 6 yıldır, Exchange ürün grubu Exchange Online yapısını yönetiyor. Bu faaliyette kullanılan model The Developer Operations (DevOps) modeli olarak biliniyor. Bu modelde, eğer özellik hizmet sırasında kötü performans sergiliyorsa ya da bilinmeyen sorun bildirimi artış gösterdiyse, sorunlar doğrudan ürünün geliştiricisine aktarılır. Problemin kaynağı ne olursa olsun doğrudan ürün geliştiricisine gitmesi yazılım hataları ele alınarak yazılımın geliştirilmesinde bazı sorumluluklar gerektirir.
Bu modeli kullanarak Exchange ekibi Exchange 2013 yapısında değişikler de bulundu. Örneğin Exchange 2010 Management Pack’de, neredeyse 1100 tane uyarı vardı. Ancak yıllar içinde aralarından sadece 150 tanesi Office 365 için yararlı olduğu anlaşıldı. (Geri kalanını etkisiz bırakıldı). Ayrıca sık karşılaşılan sorunların doğrudan developer’a gitmesi, tekrar tekrar aynı sorunlar için çalışmalarına ara vermek veya bölünmek zorunda kalmak istemediklerinden, onları daha sorumlu ve çözüme ulaşmak için sıkı çalışmasını sağladı (kod düzelterek, işakışını kurtararak, uyarı ayarı yaparak gibi). DevOps modeli içinde, her hafta görevdeki yetkililerle bir önceki haftanın sorunlarının görüşüldüğü bir toplantı süreci vardır ve bunun sonucunda kurum içi kurtarma iş akışlarının gelişimini sağladı. Örneğin: ISS application pool reset, vb.
2. Son kullanıcı deneyimine dayalı görüntüleme.
Kullanılan birçok görüntüleme yönteminin ortam yönetimi için yeterli olmadığı anlaşıldı. Sonuç olarak görüntüleme yaklaşımı daha müşteri odaklı vizyona döndü. Önceki sürümlerde her ekip kendi sistemi içinde tüm bileşenleri içeren sağlıklı bir model geliştirmek durumundaydı. Örneğin: transport yapısı SMTP-IN, SMTP-OUT, transport agents, routing engine, store driver vb.den oluşuyor. Her bir bileşen için uyarılar düzenleniyor ve Management paketi içinde bu bilgiye dayalı store driver’ın başarısız olduğunu bildiren uyarılar bulunur. Ancak eksik olan uyarının uçtan uca kullanıcı deneyimi hakkında veya deneyimdeki eksiklikler hakkında bilgi vermemesidir. Bu nedenle Exchange 2013 için model tersine çevrildi. Önemli olduğu için sistem seviyesindeki görüntülemeye devam ediliyor ancak bir hizmet yönetilmek isteniyorsa gerçekten önemli olan kullanıcıların ne gördüğüdür. Bu yüzden model kullanıcı deneyimini görüntülemek için yapılandırıldı
3. Kurtarma odaklı programlama ile kullanıcı deneyimini korumak. Exchange’in önceki sürümlerinde monitoring son kullanıcının deneyimini otomatik olarak kurtarma veya yeniden yüklemesi yerine Exchange sistem ve bileşenleri üzerine yoğunlaşıyordu.
Serimizin ikinci yazısında Managed Availability ve Bileşenlerine bakacağız.
Bu konuyla ilgili sorularınızı alt kısımda bulunan yorumlar alanını kullanarak sorabilirsiniz.
Referanslar
