Bu makale serisinde SCOM 2007 R2 Root Management Server ve Operations Manager Database’lerinin ayrı Cluster sistemler üzerinde olduğu bir deployment senaryosunu adım adım kurulum işlemlerini göstererek paylaşmak istiyorum. SQL ve SCOM için gerekli hesapların oluşturulması , IP ve Disk Yapılandırmasının yapılması ile başlayalım.
Öncelikli olarak SCOM ve SQL kurulumları için gereken hesapların oluşturulması ile başlıyoruz. Hesapları oluştururken User’ların şifrelerini depğiştirememeleri ve şifrenin süresiz olması için aşağıdaki seçeneklerin seçilmiş olması gerekmektedir.
Resim 1
Ben bu çalışma için SCOM tarafında 4 SQL tarafında ise 3 account oluşturdum. İsimlendirmeler tamamen örnektir ve kendi isimlendirmenizi kullanabilirsiniz.
SCOM Accountlar :
opsaction ( Management Server Action Account )
opssdkconfig ( SDK ve Config servisi Account’u )
Reporting Kurulacak ise ;
opsdwwriter (Data Warehouse Write Account )
opsdwreader (Data Warehouse Read Account )
SQL Accountlar :
sqldbengine ( SQL Service account )
sqlagent ( SQL Agent service account )
Reporting Kurulacak ise ;
sqlreport ( SQL Reporting service account)
Resim 2
Şimdi size bu accountları ve accountların kullanacağı servisleri biraz anlatmak istiyorum. Servis isimlerinde R2 ile bazı değişimler olduğunu belirtmek istiyorum.
| R2 Öncesi Servislerin görüntüleme isimleri | R2 için Servislerin görüntüleme isimleri | Servis İsimleri |
| OpsMgr Config Service | System Center Management Configuration | OMCFG |
| OpsMgr Health Service | System Center Management | HealthService |
| OpsMgr SDK Service | System Center Data Access | OMSDK |
| OpsMgr VSS Vriter Service | OpsMgr VSS Vriter Service | OpsMgrVSSWriter |
| Operations Manager Audit Collection Service | Operations Manager Audit Collection Service | AdtServer |
| Operations Manager Audit Forwarding Service | Operations Manager Audit Forwarding Service | AdtAgent |
System Center Data Access ( OMSDK ) Service
System Center Data Access Service Operations Manager 2007 R2 için core service olarak gözönünde bulundurulabilir. Database’e olan ve Database’den olan tüm data akışları bu servis tarafından yapılır. Aşağıdaki fonksiyonların listesi SDK servisi içerisinden yönlendirmesi yapılan işlemleri göstermesi açısından yararlıdır.
- Database’e Console erişiminin sağlanması
- Monitored objenin geçerli durumunun görüntülenmesi
- Management Group MP’ lerini db ‘ye Import etmek ve depolamak.
- Database ‘de depolanan Management Group configuration bilgisine ulaşmak.
Aşağıdaki fonksiyonlar ise yalnızca SDK servisi ile değil ayrıca diğer component ler tarafından da ele alınan işlemlerdir.
- Event datayı database’e yazmak
- State change datasını database’e yazmak
- Performance counter datasını database’e yazmak
System Center Management Configuration ( OMCFG ) Service
OpsMgr Config Service OpsMgr 2007 environment’ının relationship lerini ve topology sini düzenler. Her bir Agent’ın Health servisine Monitoring Configuration bilgisini sağlamakla sorumludur. Bu servis Agent üzerindeki Health Service’i yapılandırmak için kullanılan data nın hassas bir bölümünü yollar. Bununla beraber bu hassas data Operational database tarafından depolanır ve korunur. SDK API OpsMgr Config Service’inin datayı görmesini engeller ve OpsMgr Config Service’ine verilecek datayı hedef olan health service ‘in public key’i ile encrypt etmeyi force eder. Bu process de , OpsMgr Config Service ‘i encrypt olmuş konfigürasyon bilgisini database ‘den Monitored agent üzerindeki health service’e göndermek için bir aracı rolü oynar
System Center Management / OpsMgr Health Service ( HealthService )
Bir Healht service monitor edilen modüller için genel bir çalışma ortamını sağlayan bir bileşendir. Örneğin end-to-end monitoring senaryolarını aktif eden farklı workflowlar için module formları. Health Servisin 2 farklı uygulamasının olduğunu fakat yalnızca 1 servis içerisinde çalıştığını not etmemiz önemlidir. Birinci uygulama , Monitor edilen Windows Computer’larında task ‘ları çalıştıran , performans data’larını toplayan v.s. Agent Health Servisidir .Health Servisin diğer bir uygulaması ise Operations Manager 2007 Management Server üzerinde çalışır . Bu servisin fonksiyonu setup sırasında , Management Pack installation’ı sırasında ve bazı binaries’ler ile belirlenir. Agent Health Service disconnected mode ‘da çalışabilir ve hala data , event toplayabilir ve onları Management Server connection’ı restore olduğunda raporlayabilir.Health State detection , automated recovery actions v.s. gibi Localize olmuş workflow ‘lar çalışmaya devam edebilir . Health Service yeni / ilave Management Pack kurulumları ile genişler. Gelecekte olacak Management Pack kurulumları update’lerini agent healt servislerini sağlayacaktır. Bu gerekli güncellemelerin Management Server tarafından yollanacağını belirtir.
Health Service ‘in özellikleri
- Lifetime Management – Health Service MP’lere ve objelere bağlı olarak workflow ‘ları oluşturur / günceller / siler
- Hosting of module execution – Health Service modullerin çalışması için process lere host etmeyi sağlar
- Module State Persistence – Health Service eğer gerekli olursa state’i yönetir.
- Credential Management – Health Service farklı userlar kullanılarak modüllerin çalıştırılmasını destekler
- Data streaming for distributed workflows – Health Service distributed workflow’ları stream dataya uygulamak için channel/data kuyruğu sağlar.
- Health State Management – Health Service monitorlerin state’ini yönetir
System Center Data Access ( OMSDK ) ve System Center Management Configuration ( OMCFG ) Service Account
SDK ve Config Service Account , SDK Service ve Config Service tarafından Operational Database ‘i update etmek için kullanılır. SDK ve Configuration Service Account için kullanılan credentiallar Operational DB de sdk_user role’üne atanırlar .
Managed entities ‘den Operational Database ‘e yazılan datalar security-related nature olabilirler. Bu account ile ilgili seçeneklerde bu account Local System Account olarak , bir Domain ya da Local Account olarak tanımlanabilir. Bu account a atanmış credential ların high privileged account olması ve Management Server Action Account ile aynı olmaması tavsiye edilir.
Eğer Operational Database , Root Management Server dan ayrı bir server’a kurulmuş ise ve SDK ve Configuration Service Account için Local System seçilmiş ise bu durumda Root Management Server için computer account’u Operational Database’de sdk_user role’üne atanacaktır.
Eğer Operational Database , Root Management Server dan ayrı bir server’a kurulmuş ise SDK ve Configuration Service Account için local bir user account kullanmak imkansızdır.
Action Account
Action Account managed computer (managed computer bir Management Server de olabilir Agent installed bir computer ‘de olabilir) üzerinde bilgi almak ve cevapları çalıştırmak için kullanılır. MonitoringHost.exe bu account altında çalışır. OpsMgr herbir provider’ı ya da response ‘u MonitoringHost.exe’nin failure olması halinde diğer instance ları korumak için farklı bir instance da çalıştırır. Bu yüzden birden daha fazla MonitoringHost.exe process’i aynı anda agent üzerinde ya da management server üzerinde bu account altında çalışabilir.
OpsMgr 2007 RunAs accounts ‘lar vasıtası ile multiple identity ‘i destekler. Böylelikle , bir çok identity altında çalışan birçok MonitoringHost.exe processes’i bulunabilir.
Spesifik olarak , MonitoringHost.exe process’i workflowları manage eder. Bu workflow itemları ;
- Windows event log datasını Monitor etme ve toplama
- Windows performance counter datasını Monitor etme ve toplama
- Windows Management Instrumentation (WMI) datasını Monitor etme ve toplama
- IIS logları gibi application-specific log datasını Monitor etme ve toplama
- Script ve batches gibi Management Pack responses larını çalıştırma
- Bir managed code module çalıştırma
SCOM monitoring için gereksinimlerimizden birisi olan Management Server Action Account’unun Monitor olacak sistemler üzerinde Performance Monitor Users grubuna dahil olmasını sağlamalıyız. Bunu tek tek yapabileceğiniz gibi basitçe aşağıdaki gibi Performance Monitor Users grubunu Restricted Group olarak atayıp üyesi olarakta Management Server Action Account’u olacak şekilde GPO ile de tüm ortamınıza uygulayabilirsiniz.
Bu işlemi eğer domain controllerlarıda monitor edecek isek hem Domain hem de Domain Controller policy üzerinde uygulamamız gerekecektir.
Resim 3
SQL ve SCOM için oluşturduğumuz account’ları SQL nodelarda Local admin olacak şekilde Administrators grubuna ekliyoruz. Bu işlemi her iki node için uyguluyoruz. İsterseniz bu accountları içeren bir group oluşturarakta bu işlemi uygulayabilirsiniz.
Resim 4
RMS Cluster node ‘larımızda ise sadece SCOM için oluşturduğumuz account’ları Local admin olacak şekilde Administrators grubuna ekliyoruz. Bu işlemi her iki node için uyguluyoruz. İsterseniz bu accountları içeren bir group oluşturarakta bu işlemi uygulayabilirsiniz.
Resim 5
Ben bu kurulumda 2 Node’lu SQL 2 Node’lu RMS yapısı kullanacağım.
Her bir node için Public ve Private isimli iki adet NIC olması gerekiyor. Public için seçilen IP subnet’i adından da anlaşılacağı üzere sistemlerin birbiriyle networkte konuşacağı bir IP yapılandırmasını içermelidir.
Resim 6
Ben test sistemimde nodelar içim isimlendirme ve IP yapılandırmasını aşağıdaki gibi kullandım : Her iki cluster’ın private subnetlerinin değişik olduğuna lütfen dikkat ediniz.
Makina İsmi Public IP Adresi Private IP Adresi
SQLNode1 192.168.100.102 10.0.0.1
SQLNode2 192.168.100.103 10.0.0.2
RMSNode1 192.168.100.104 192.168.1.1
RMSNode2 192.168.100.105 192.168.1.2
Bütün Nodeların her biri üzerinde Private için IP yapılandırması yaparken NIC üzerinde sadece Internet Protocol ‘ünün etkin kalmasını sağlayın. Diğer protokoller devre dışı bırakılmalıdır.
Resim 7
Bu protokolü yapılandırırken ise sadece IP address ve Subnet mask girilmelidir.
Resim 8
Advanced ayarlarında ise DNS sekmesinde “Register this connection’s adresses in DNS” check box temizlenmelidir.
Resim 9
WINS tabında ise “Disable NetBIOS over TCP/IP” seçeneği seçilmelidir.
Resim 10
Ayrıca Her bir node üzerinde Network and Sharing Center / Change Adapter Settings’de , Advanced menüsünden Advanced settings altında Public kartların 1. sırada olduğunu doğrulayınız.
Resim 11
IP yapılandırmamızı bu şekilde yaptıktan sonra şimdi nodelarımız için disk yapılandırmasını uygulayacağız. Bu işlemde herbir node üzerinde yapılması gerekiyor. Bu işlem için Start alanına ISCSI yazınız ve karşınıza gelen Set up Initiator seçeneğini çalıştırınız.
Ardından aşağıdaki gibi bir uyarı ile karşılaşacaksınız. Bu uyarıya Yes seçeneği ile onay veriniz
Resim 12
Açılan Utulity ‘de Discovery tabına geliniz ve buradan Discover Portal butonuna tıklayınız. Buraya Discover Portal’inin IP adresini yazınız ve OK tıklayınız.
Resim 13
Discover Portali girdikten sonra Discover Portale connection ile ilgili bir sorun yok ise bu durumda Targets tabında Discover edilmiş Target’ı inaktif olarak göreceksiniz.
Resim 14
Aktif etmek için Connect butonuna tıklayınız ve ilk check box seçili iken OK butonuna tıklayınız. Eğer bu check box seçili olmaz ise sistem her restart ettiğinde bu connectionı sağlamanız gerekecektir.
Resim 15
Artık target connected olacaktır.
Resim 16
Bundan sonrasında Computer Management / Disk Management ta göreceğiniz diskleri Online etmek , Initialize yapmak ve formatlamanız gerekecektir. Bundan sonrasında ise Computer alanında oluşturulan diskleri görebileceksiniz.
Resim 17
İkinci bölümde Operations Manager için gerekli olan SQL Database’imizi nasıl cluster bir yapıya dönüştüreceğimizi göstereceğim.
Bu ve bunun gibi SCOM 2007 ve SCOM 2007 R2 ürünleri hakkında ayrıtılı Türkçe bilgilere Buradan ulaşabilirsiniz
Bu konuyla ilgili sorularınızı alt kısımda bulunan yorumlar alanını kullanarak sorabilirsiniz.
Referanslar
