Birçoğumuz OpsMgr sunucularımızı farklı sebeplerden dolayı zaman zaman kapatmak, reboot etmek zorunda kalabiliyoruz. Bununla birlikte donanım veya yazılım arızaları sonucunda sunucu rollerinden bir veya daha fazlası işlevsiz duruma gelebiliyor. Bu yazımda sizlere OpsMgr 2007 sunucu rollerinde olası bir kesintinin etkilerinden bahsedeceğim.

Root Management Server (RMS)

Bildiğiniz gibi her OpsMgr 2007 Management Group’ta sadece bir adet RMS bulunuyor. Bu sebepten dolayı “ikinci bir RMS kurup riski dağıtayım” gibi bir yaklaşım ne yazık ki mümkün olmuyor. RMS’i kesintilerden korumanın en doğru yolu ise clustered bir ortama kurmak.

RMS sunucunuz işleviz hale geldiğinde:

• Ortamdaki konsollar (ve web konsol) çalışmaz, çünkü ortamdaki management server’lar arasında sadece RMS veri tabanından veri okuyabilir.
• Management group’un konfigürasyonunu değiştirmeniz için gereken servisler sadece RMS üzerinde çalıştığı için management group’un konfigürasyonunu değiştiremezsiniz.
• Ortamınızda birden fazla management group varsa, diğer management grouplar ile bağlantınız kesilir.
• Operations Manager ortamınızı yönetmek ile ilgili herhangi bir görev gerçekleştiremezsiniz.
• Connector’leriniz çalışmaz.

Eğer ortamınızdaki agent’lar RMS sunucunuza bağlıysa (farklı bir management server’a bağlı değilse) o zaman aynı zamanda bir sonraki başlıkta belirteceğim Management Server etkilerini de hissedeceksiniz demektir.

Management Server (MS)

Yüksek performans gerektiren ve çok sayıda bilgisayar ve cihazın izlendiği ortamlarda OpsMgr agnet’larının RMS’e bağlanması önerilmez, farklı bir Management Server(MS) kullanılması önerilir. RMS’in aksine, ortamda birden fazla MS bulunabilir ve bir MS işlevsiz hale geldiğinde üzerindeki agent’ların farklı bir MS’e otomatik olarak devredilmesini sağlayabilirsiniz. Dolayısıyla MS’ların yüksek erişilebilirliği, ortama birden fazla MS kurularak sağlanabilir.

MS sunucunuz işlevsiz hale geldiğinde:

• Veriler agent kurulu bilgisayarlarda birikirler ve MS işlevsiz olduğu sürece veri tabanına yazılamazlar.
• Agentless bilgisayarlar yönetilemez.
• Gateway sunucular agent’lardan MS’a veri gönderemez.

OperationsManager Veritabanı

OperationsManager veritabanı failover cluster’a kurularak veya SQL Log Shipping yöntemi ile yüksek erişilebilir hale getirilebilir. Failover cluster yöntemi ile yüksek erişilebilirliği sağlanmış bir OperationsManager veritabanının node’larından biri çalıştığı sürece erişilebilirlik problemi olmayacaktır. Eğer veritabanını korumak için Log shipping kullanıyorsanız veritabanı hedef sunucuda veritabanını oluşturana kadar servis performansı düşebilir, veritabanını oluşturmanız belirli bir sürenin üzerine çıkarsa (Management Server cache’i dolarsa) veri kaybı olabilir.

OperationsManager veritabanı işlevsiz hale geldiğinde:

• Management Server’lar agent’lardan gelen verileri cache’lerinde tutmaya başlarlar. Management Server üzerinde Powershell’den “Get-ManagementServer” komutunu çalıştırırsanız Management Server’ınızın ne kadar veri cache’leyebileceğini görürsünüz (defaule 100MB). Bu değeri yine powershell ile arttırabilirsiniz.
• Datawarehouse’unuzun ve Reporting sunucularınızın sorunsuz çalıştığını düşünürsek, raporlara ulaşabilirsiniz, ancak güncel verileri göremezsiniz.
• Yönetimsel herhangi bir görev gerçekleştiremezsiniz (obje oluşturma, yetkilendirme vb)
• Konsollar çalışmaz

Audit Collection (ACS) Database

ACS veritabanınız işlevsiz hale geldiğinde:

• Güvenlik olayları agent yüklü bilgisayarlarda birikir ve bir süre sonra performans sıkıntısı yaratmaya başlar.
• Datawarehouse’unuzun ve Reporting sunucularınızın sorunsuz çalıştığını düşünürsek, ACS raporlarına ulaşabilirsiniz, ancak güncel verileri göremezsiniz.