System Center Operations Manager 2012 Geçişi – Bölüm 2: Planlama ve Tasarım

Yazı dizimizin ilk bölümünde System Center Operations Manager 2012 kurulumu öncesinde firmaların Operations Manager’dan gerek yönetim gerek Bilgi Teknolojileri olarak beklentilerini karşılamak üzere temel değerlendirmeleri ne yönde yapmalarının faydalı olacağını değerlendirmiştik. Bu bölümde ise firmalara planlama ve tasarım aşamalarında yardımcı olmak üzere bu adımlar üzerinde konuşuyor olacağız.

Tasarım Dökümanınızı Oluşturun

Tasarım dökümanımız bizim daha önceden yaptığımız değerlendirmeleri ve bu değerlendirme sonucu oluşturulmuş beklentilerimizi içeren ve Operations Manager ile ilgili her safhada başucumuzda bulunduracağımız dökümanımızdır (mümkün olduğunca bu dökümanı basit tutmanızı ve yapılacak işleri de bir kontrol listesi (checklist) olarak tutmanızı tavsiye ederim.)

Tasarım dökümanımızda Operations Manager kurulum ve yaygınlaştırma ile ilgili, firmanın durumuna ve taleplerine uygun olarak aşağıdaki adımlarda yapılacak işler bulunur:

  • Kavram kanıtlama (proof of concept): Kurulum izole bir ortamda yapılır, firmanın canlıda (production) olan sistemini etkilemez. Genellikle tanıtım ve kurulum öncesi denemeler için kullanılır.
  • Pilot kurulum: Canlı ortamda az sayıda sunucuya kurulum yapılması. Kavram kanıtlamanın canlı ortamda yapılanı olarak düşünebiliriz.
  • Canlı ortam (production): Operations Manager’ın firmanın canlı ortamına kurulması.
  • Göç (migration): Firma tarafından hal-i hazırda kullanılan Operations Manager’ın yeni sürüme güncellenmesi. Eğer firmanın ortamında bir Operations Manager kurulumu yoksa bu tasarım dökümanının oluşturulmasına da –haliyle– gerek yoktur.

Kullanılacak Hesapları Belirleyin ve Oluşturun

Operations Manager tarafından kullanılacak hesapların ve grupların belirlenmesi ve bu hesapların tanımlanması bize zaman kazandıracaktır. Özellikle bazı firmalarda bir kullanıcı hesabının açılmasının birkaç gün sürdüğünü düşünürsek, bu hesapların önceden belirlenmesi ve açılmasının bize sağlayacağı kolaylığı daha iyi anlayabiliriz. Operations Manager sağlıklı çalışmak için aşağıdaki hesapları kullanır:

  • Action
  • Data reader
  • Data writer
  • SDK

Ayrıca sistem izleme, kullanıcılar için – gerekiyorsa – ek hesaplar ve gruplar tanımlanabilir. Böylece kurulum sırasında RunAs hesaplarının tanımlanması ve yetkilendirilmelerin yapılması çok kolay olacaktır.

Mümkün Olduğunca Genel Tasarım Prensiplerine Bağlı Kalın

Genel olarak bu tarz izleme yazılımlarında bağlı kalınacak genel tasarım prensipleri vardır. Tabii ki bunlar değiştirilemez değildir, ancak bu prensiplerden ayrıldığımızda yapacağımız değişikliklerin nelere sebep olabileceğini ve neler elde etmeyi amaçladığımızı çok iyi hesap etmemiz gerekir:

  • Tasarımı basit tutun: Sistemleri çok detaylı izlemek çok “havalı” gözükebilir ancak bu sistemi yönetmenizi zorlaştırır ve ortamı karmaşıklaştırmanıza sebep olur ancak bu izlemenizi tamamen en basit haline indirmeniz anlamına da gelmez. Sisteminizi daha detaylı izlemek sadece bir iş gereksinimini karşılamak için olmalı, “biz sistemlerimizi çok detaylı” izliyoruz demek için olmamalı.
  • Sanallaştırma: Eğer bir Depolama Alan Ağı (Storage Area Network – SAN) üzerinde değilse, Operations Manager’ın veritabanlarının olduğu sunucuları sanallaştırmayın. Özellikle Operations Manager veritabanı (Datawarehouse değil) diskler üzerinde çok fazla okuma yazma (I/O) yapacağından, sanal veritabanı sunucusu sanal ortamda bulunan diğer sunucuların performanslarını da negatif olarak etkileyebilir.
  • Hepsi bir arada kurulum: Yönetim sunucusu, rapor sunucusu, veritabanı sunucusunu rollerinin hepsini bir sunucuya kuracaksanız, bunu sadece laboratuar ortamında ya da kavram kanıtlama kapsamında yapın. Canlı ortamda bu şekilde bir sunucu istendiği şekilde çalışmayacaktır.

Yönetim Gruplarını Tasarlayın

Tasarımınıza tek bir Yönetim Grubu (Management Group) üzerinden başlayın ve ihtiyacınız olması durumunda Yönetim Gurubu ekleyin.

Aşağıdaki durumlarda Yönetim Grubu eklemek doğru olacaktır:

  • Test ve canlı ortamlarını ayırmak için,
  • Her bir Yönetim Grubunda bulunabilecek en fazla ajan sayısı geçildiğinde
  • Ayrı kişi ya da grupların ayrı sistemleri yönetebilmelerini sağlayabilmek için

Yönetim Grubunun isimlendirilmesinde ise aşağıdakilere dikkat etmemiz gerekir:

  • Eğer Operations Manager’ın önceki sürümlerinden güncelleme yapıyorsak, Yönetim Grubu adı aynı kalır,
  • Eğer birden çok Yönetim Grubuna veri gönderen (multi-homed) ajan varsa, Yönetim Grubu adı değiştirilir,
  • Operations Manager’daki yönetim grubu adının (eğer kullanılıyorsa) Service Manager’daki yönetim grubu ile aynı olmamasına dikkat edilir.

Yönetim Sunucuları

Tasarımınıza Yönetim Grubunda olduğu gibi tek bir Yönetim Sunucusu ile başlayın ve ihtiyaçlarınız doğrultusunda Yönetim Sunucusu ekleyin. Aşağıdaki şartlarda yeni Yönetim Sunucusu eklemeniz doğru olacaktır:

  • Mevcut Yönetim Sunucusunun kaynakları yetersiz kaldığında,
  • Yönetim Sunucusu başına 3000 ajandan daha fazlasının düşmesi durumunda,
  • Yedeklilik sağlamak amacıyla,
  • Ağ cihazlarını izlemek amacıyla (sadece ağ cihazlarını izlemek için ayrı bir Yönetim Sunucusu kurulabilir),
  • Ağ geçidi kurulması durumunda (ne olursa olsun, kesinlikle ağ geçidi (gateway) rolü ve yönetim sunucusu rollerini aynı sunucuya kurmayın).

Ağ Geçidi Sunucuları

Tasarımınıza hiç Ağ Geçidi Sunucusu kullanmayacakmışsınız gibi başlayın. Bir Operations Manager ortamında Ağ Geçidi Sunucusu aşağıdaki şartlarda zorunludur:

  • Sunucularınız Kerberos Etki Alanı Ormanı (Active Directory Forest) dışında ise,
  • Aynı Etki Alanı Ormanı içinde uç lokasyonları izlemek gerekiyor ise.

Aşağıdaki şartlarda ise yeni bir Ağ Geçidi Sunucusu eklemek doğru olacaktır:

  • Eğer Ağ Geçidi Sunucusuna 2000’den fazla ajan düşüyorsa,
  • Ağ Geçidi Sunucusunda yedeklilik (redundancy) isteniyorsa.

Veritabanı Sunucuları

Yine benzer şekilde tasarımınıza tek bir veritabanı sunucusu ile başlayın. Aşağıdaki durumlar için veritabanı sunucusu eklememiz gerekebilir:

  • Operations Manager veritabanı çok aktiftir, sürekli okuma, yazma, sorgulama işlemleri yapılıyordur ve bu işlemler mevcut sistem kaynaklarını çok fazla tüketiyordur. Bu durumda bu veritabanı ayrı bir sunucu üzerine alınabilir.
  • Operations Manager Data Warehouse veritabanı çok büyümüştür. Veritabanı boyutunun çok büyük olması diğer veritabanlarını etkiliyordur ya da daha fazla disk alanına ihtiyaç duyuyordur. Bu durumda Data Warehouse veritabanının başka bir sunucuya alınması gerekebilir.
  • Denetleme verileri toplama (Audit Collection) servisinin devreye alınması sonucunda ihtiyaç duyulabilecek ek kaynakların mevcut veritabanı sunucusundan karşılanamaması durumunda bu servisin kullanacağı veritabanı ayrı bir sunucuya alınabilir.
  • Operations Manager veritabanlarının yedekliliğini sağlamak amacıyla veritabanı sunucuları yeni sunucular eklenerek küme (cluster) yapıda çalıştırılabilir.
  • Raporlama rolü, Operations Manager veritabanlarının bulunduğu sunucu yerine ayrı bir sunucu üzerine kurulabilir.

Reklamlar

Bir Cevap Yazın

Aşağıya bilgilerinizi girin veya oturum açmak için bir simgeye tıklayın:

WordPress.com Logosu

WordPress.com hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap / Değiştir )

Twitter resmi

Twitter hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap / Değiştir )

Facebook fotoğrafı

Facebook hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap / Değiştir )

Google+ fotoğrafı

Google+ hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap / Değiştir )

Connecting to %s