Yüksek Kullanılabilirlik ve Olağanüstü Durum Kurtarma

System Center – Operations Manager sunucuları ve özellikleri, Operations Manager işlevselliğini etkileyerek başarısız olabilir. Bir hata sırasında kaybedilen veri ve işlevsellik miktarı her hata senaryosunda farklıdır. Bu, başarısız özelliğin rolüne ve başarısız özelliği kurtarmak için gereken süreye bağlıdır.

Yüksek kullanılabilirlik

Yüksek kullanılabilirlik gereksinimleri Operations Manager işletimsel ve veri ambarı veritabanları, ağ geçidi ve yönetim sunucuları ve belirli iş yükleri için yönetim grubuna yedeklilik oluşturarak giderilir. Bu iş yükleri arasında daha önce Kök Yönetim Sunucusu tarafından yönetilen ağ cihazı izleme, platformlar arası izleme ve yönetim grubuna özgü iş yükleri bulunur.

Birden çok sunucu, tek yönetim grubu yapılandırması, Operations Manager veritabanlarının yüksek kullanılabilirliğini ve hizmet sürekliliğini sağlamak için SQL Server AlwaysOn'ı kullanabilir. Yönetim sunucusu hataya dayanıklılık, en az iki yönetim sunucusuna sahip olmak ve UNIX sunucularını, Linux sunucularını ve ağ cihazlarını izlemek için kaynak havuzları kullanılarak sağlanır. Aracı tabanlı Windows sunucuları, bir yönetim sunucusu başarısız olursa aracı iletişimlerini yeniden yönlendirmek için birincil ve ikincil bir yönetim sunucusuyla yapılandırılabilir.

RMS Öykünücüsü'ne ev sahipliği yapan yönetim sunucusu kullanılamaz duruma gelirse RMS Öykünücüsü de başka bir yönetim sunucusuna taşınabilir.

İşletim konsolu bağlantıları, Veri Access Hizmetleri için yüksek kullanılabilirlik yapılandırılarak yüksek oranda kullanılabilir hale getirilebilir. Bu, Microsoft Ağ Yükü Dengeleme (NLB) yüklenerek veya donanım tabanlı yük dengeleyiciler veya DNS diğer adı kullanılarak yapılabilir. Bir veya daha fazla yönetim sunucusu NLB havuzunun üyesi olarak eklenir ve konsolu açarken yük dengeli yönetim sunucularının DNS'de kayıtlı sanal adına başvurursunuz.

Not

Operations Manager web konsolu sunucusu için Ağ Yükü Dengeleyici desteklenmez.

Güven sınırı ötesindeki aracılara yedekli iletişim yolları sağlamak için güven sınırları ötesine birden çok ağ geçidi sunucusu dağıtılabilir. Aracılar, birincil bir yönetim sunucusu ile bir veya daha fazla ikincil yönetim sunucusu arasında yük devredebildikleri gibi ağ geçidi sunucuları arasında da yük devredebilirler. Ek olarak, aracısız yönetilen bilgisayarların ve yönetilen ağ aygıtlarının yönetim iş yükünü dağıtmak için birden çok ağ geçidi sunucusu kullanılabilir.

Ağ geçidi sunucuları, aracı-ağ geçidi arası yük devri aracılığıyla yedekleme sağlamaya ek olarak, bir yönetim grubunda birden çok yönetim sunucusu varsa, bu yönetim sunucuları arasında da yük devredebilirler.

SQL Server Reporting Services, tek bir rapor sunucusu veritabanını paylaşan birden çok rapor sunucusu örneği çalıştırmanıza olanak tanıyan bir genişleme dağıtım modelini desteklese de, Operations Manager ile desteklenmez. Operations Manager Raporlama, ön uç bileşenlerinin kurulumunun bir parçası olarak özel bir güvenlik uzantısı yükler ve bu uzantı web grubunda çoğaltılamaz.

Olağanüstü durum kurtarma

Olağanüstü durum kurtarma, olağanüstü bir hata (örneğin, birincil altyapıyı barındıran veri merkezinin tamamının kaybı) durumunda işlemlerin sürdürülebilmesini sağlamak için alınan önlemlerle ilgilidir. Bu, herhangi bir dağıtımda dikkate alınması gereken önemli bir unsurdur ve olağanüstü durum kurtarma planlamasında alınan kararlar, Operations Manager'ın kritik BT hizmetlerinizin performansını ve kullanılabilirliğini proaktif izleme ve raporlamayı desteklemeye nasıl devam edebileceğini etkiler. Bu bölüm, olağanüstü durum kurtarma ve dayanıklılık için önerilen stratejiye ve sorunsuz bir kurtarma sağlamak için hangi adımların izlenmesi gerektiğine odaklanacaktır.

HA ve DR çözümleri sistem hatalarına veya sistem kaybına karşı koruma sağlarken, yanlışlıkla, istenmeyen veya kötü amaçlı veri kaybına veya bozulmasına karşı korunmaya güvenilmemelidir. Bu gibi durumlarda, geri yükleme işlemleri için kopyalanan veya gecikmeli çoğaltma kopyalarının kullanılması gerekebilir. Çoğu durumda, geri yükleme işlemi DR'nin en uygun biçimidir. Bunun bir örneği düşük öncelikli raporlama veritabanı veya analiz verileri olabilir. Çoğu durumda, sistem veya uygulama düzeyinde çok siteli DR'yi etkinleştirme maliyeti verilerin değerinden çok daha fazladır. Verilerin yakın vadeli değerinin düşük olduğu ve bir hata veya site DR aşırı olduğunda ciddi iş etkisi olmadan verilere erişme gereksiniminin gecikebileceği durumlarda, maliyet tasarrufu bunu garanti ederse DR için basit yedekleme ve geri yükleme işlemlerini kullanmayı göz önünde bulundurun.

Kapalı kalma süresinin etkisini ve toleransını anlamak, Operations Manager mimarisini ve olağanüstü durum kurtarmayı desteklemek için gereken karmaşıklık ve maliyet düzeyini düzgün tasarlamak için anlaşılması gereken kararların alınmasına yardımcı olur. Ayrıca, BT kuruluşunun iş sonuçlarına neden olmadan tolere edebildiği veri kaybının kapsamını da göz önünde bulundurun. Bu en iyi iki terimle açıklanır: kurtarma süresi hedefi (RTO) ve kurtarma noktası hedefi (RPO).

Operations Manager için en yaygın iki olağanüstü durum kurtarma tasarım yapılandırması şunlardır:

• İkincil veri merkezinize dağıtılan ve birincil yönetim grubunu ölçek ve yapılandırma açısından kopyalayan, yinelenen bir yönetim grubu oluşturma.
• Kurtarma eylemlerinin gerçekleştirilmesi gerekene kadar yönetim grubuna katılmayan, soğuk bekleme yapılandırmasında dağıtılan yönetim sunucuları ile İşletimsel ve Veri Ambarı veritabanını desteklemek için ek sunucuları ikincil bir veri merkezinde dağıtma.

Kapalı kalma süresi için tolerans olmadığında yinelenen bir yönetim grubu dağıtmak bir seçenektir; ancak en karmaşık seçenektir. Her ikisi arasındaki yapılandırmanın tutarlı olması gerekir; böylece kesinti yaptığınızda izlenen, uyarılan veya bildirilen, sunulan ve son olarak yükseltilenlerde fark yoktur. System Center - Service Manager, Remedy veya ServiceNow gibi diğer izleme platformlarıyla veya ITSM platformlarıyla tümleştirmenin de mevcut olması ve olayların, yapılandırma öğelerinin vb. çoğaltılmasını önlemek için etkin/pasif durumda yapılandırılması gerekir. Aracılar her iki yönetim grubu arasında birden çok ana bilgisayarlı olacak, bu nedenle verilerin çoğaltılması olacaktır.

Aşağıdaki diyagramda bu tasarım senaryosuna bir örnek verilmiştir.

Operations Manager dağıtımınız için anında kurtarma gerekli değilse ve yinelenen bir yönetim grubunun karmaşıklığını önlemek istiyorsanız, yönetim grubunuzun işlevselliğini korumak için alternatif olarak ikincil veri merkezinize ek yönetim grubu bileşenleri dağıtabilirsiniz. Birincil veri merkezinde iki düğümlü yük devretme kümesi örneğinin (FCI) dağıtıldığı ve tek bir Windows Server Yük Devretme Kümesi'nin (WSFC) parçası olarak ikincil veri merkezinde tek başına bir SQL Server'ın dağıtıldığı iki veya daha fazla veri merkezi arasında İşletimsel ve Veri Ambarı veritabanlarının kurtarılmasını sağlamak için en azından bir SQL Server 2014 veya 2016 AlwaysOn Kullanılabilirlik Grubu uygulamayı göz önünde bulundurun. Always On Kullanılabilirlik Grubu için ikincil çoğaltma, aşağıdaki diyagramda gösterildiği gibi FCI tek başına olmayan örnekte olacaktır.

Bu örnekte, aynı donanım yapılandırmasına ve bilgisayar adına sahip bir veya daha fazla Windows Sunucusu dağıtmanız ve /Recover parametresini kullanarak yönetim sunucusu rolünü yeniden yüklemeniz gerekir. Bu ayara ilişkin örneği aşağıda bulabilirsiniz:

Setup.exe /silent /AcceptEndUserLicenseAgreement:1 /recover /InstallPath:<Install Directory> /ManagementGroupName:MGNAME /SqlServerInstance:SQLServerName.domain.com /DatabaseName:OperationsManager /DWSqlServerInstance:SQLServerName.domain.com /DWDatabaseName:OperationsManagerDW /ActionAccountUser:DOMAIN\omaa /ActionAccountPassword:password /DASAccountUser:DOMAIN\omdas /DASAccountPassword:password /DatareaderUser:DOMAIN\omdr /DatareaderPassword:password /DataWriterUser:DOMAIN\omdw /DataWriterPassword:password /EnableErrorReporting:Always /SendCEIPReports:1 /UseMicrosoftUpdate:0

Daha fazla bilgi için komut isteminden Operations Manager'ı yükleme bölümüne bakın.

Aracılar bu süre boyunca toplanan verileri (uyarılar, olaylar, performans vb.) yönetim grubundaki bir yönetim sunucusuyla iletişimi sürdürene kadar kuyruğa alır. Bu yaklaşım, SQL Server'ın yeni örneklerinin yüklenmesini ve veritabanlarının bilinen son iyi yedeklemenizden geri yüklenmesini önler. Ancak bu kurtarma senaryosunda, en düşük izleme işlevselliğini sürdürmek için gereken diğer rolleri dağıtmanız gerektiğinden, büyük olasılıkla daha uzun bir gecikme yaşanacak. Bu yaklaşım kabul edilebilir değilse, bekleyen kurtarma için ikincil veri merkezinize yönetim sunucuları dağıtabilirsiniz. Bunları üç birincil kaynak havuzunun üyesi olarak kaldırın: Tüm Yönetim Sunucuları Kaynak Havuzu, Bildirimler ve AD Ataması. Bu, birincil veri merkezinde barındırılan ve kurtarma planının bir parçası olarak çalışmaya devam etmesi gereken yönetim sunucularını içerebilen tüm özel kaynak havuzlarını da içerir. System Center Veri Erişimi, System Center Yapılandırma Yönetimi ve Microsoft Monitoring Agent hizmetleri durdurulmalı ve el ile veya devre dışı olarak ayarlanmalıdır ve yalnızca olağanüstü durum kurtarma senaryosunda başlatılmalıdır.

Bir yönetim sunucusu tümleştirmeyi destekliyorsa (doğrudan yönetim sunucusunda barındırılan bir bağlayıcı aracılığıyla veya VMM, Orchestrator veya Service Manager gibi başka bir System Center ürününden), tümleştirme yapılandırmasına ve kurtarma adımlarının dizisine bağlı olarak bunun el ile veya otomatik kurtarma adımlarıyla planlanması gerekir. Bu, yönetim sunucusundaki diğer bağımlılıkların yakalanmasını ve olağanüstü durum kurtarma planının uygulanması gerektiğinde planlanmasını sağlar.

Bir site çevrimdışı olursa, aracının yük devretme yapılandırmasının buna izin verdiği varsayılarak aracı başka bir sitedeki yönetim sunucusuna yük devredecektir. Windows aracılarını yalnızca birincil veri merkezinizdeki yönetim sunucularını önbelleğe alıp ikincil veri merkezindeki bir yönetim sunucusuna yük devretmeye çalışmalarını önlemek için yönetmesi gereken ve yalnızca kurtarma ve raporlamayı geciktirecek şekilde yeniden yapılandırın. Aracıyı yükleme sırasında önceden yapılandırmak üzere bir betik (vbScript veya daha iyisi, PowerShell) ile otomatik bir şekilde el ile dağıtırsanız veya aracıyı konsoldan gönderirseniz, yine kurumsal yapılandırma yönetimi çözümünüzle yönetilen betikli bir yöntem kullanarak dağıtım sonrası gerçekleştirebilirsiniz.

Operations Manager, yönetim grubunun sürekliliğini korumak için alternatif bir olağanüstü durum kurtarma seçeneği olarak Azure sanal makinelerine dağıtılabilir. Yönetim sunucusu ile Operations Manager veritabanlarını barındıran SQL Server arasındaki gecikme süresi yönetim grubunun performansını olumsuz etkileyeceğinden, SQL Server'ın karma yapılandırmada değil Azure'daki bir sanal makineye dağıtılması da gerekir.

Azure IaaS veya diğer genel bulut sağlayıcıları içinde bu senaryonun düzgün bir şekilde tasarlanması için izleme kapsamını, ağ topolojisini ve Microsoft Azure'a ağ bağlantısını (siteden siteye VPN veya ExpressRoute), tümleştirme noktalarını (ITSM çözümleri, diğer System Center ürünleri, üçüncü bölüm eklentileri vb.), konsol erişimini, mevzuat veya ilgili yasaları ve ilkeleri vb. göz önünde bulundurun.