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

Önemli

Operations Manager'ın bu sürümü desteğin sonuna ulaştı. Operations Manager 2022'ye yükseltmenizi öneririz.

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. 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 ihtiyaçları, Operations Manager işletimsel ve veri ambarı veritabanları, ağ geçidi ve yönetim sunucuları ve belirli iş yükleri için yönetim grubunda yedeklilik oluşturularak ele alınır. 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 yer alır.

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 Always On'ı 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 sunucusunun başarısız olması gerekirken aracı iletişimlerini yeniden yönlendirmek için birincil ve ikincil bir yönetim sunucusuyla yapılandırılabilir.

RMS Öykünücüsü’nü barındıran yönetim sunucusunun kullanılamaz duruma gelmesi durumunda RMS Öykünücüsü de farklı bir yönetim sunucusuna taşınabilir.

İşletim konsolu bağlantıları, Veri Erişim 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 konsoldan birini 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ğ Load Balancer 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, yıkıcı 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 öğedir 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 edebileceklerini etkiler. Bu bölümde olağanüstü durum kurtarma ve dayanıklılık için önerilen strateji ile sorunsuz bir kurtarma için gerçekleştirilmesi gereken adımlar üzerinde durulmaktadır.

HA ve DR çözümleri sistem hatalarına veya sistem kaybına karşı koruma sağlayacak olsa da, yanlışlıkla, istenmeyen veya kötü amaçlı veri kaybına veya bozulmasına karşı koruma için bu çözümlere güvenilmemelidir. Bu gibi durumlarda, geri yükleme işlemleri için kopyalanan veya gecikmeli çoğaltma kopyalarını yedeklemek gerekebilir. Çoğu durumda, bir geri yükleme işlemi en uygun olağanüstü durum kurtarma biçimidir. Düşük öncelikli raporlama veritabanı veya analiz verileri buna bir örnek olarak verilebilir. Çoğu durumda, sistem veya uygulama düzeyinde olağanüstü durum kurtarmayı etkinleştirme maliyeti verilerin değerinden fazladır. Verilerin yakın vadeli değerinin düşük olduğu ve bir hata veya site DR'si aşırı olduğunda iş üzerinde ciddi bir etki olmadan verilere erişim gereksiniminin gecikebileceği durumlarda, maliyet tasarrufları bunu garanti ederse DR için basit yedekleme ve geri yükleme işlemlerini kullanmayı göz önünde bulundurun.

Kapalı kalma süresi için etkiyi ve toleransı anlamak, Operations Manager için mimariyi ve olağanüstü durum kurtarmayı desteklemek için gereken karmaşıklık ve maliyet düzeyini düzgün bir şekilde tasarlamak üzere anlaşılması gereken kararların verilmesine yardımcı olur. Ayrıca, BT kuruluşunun iş sonuçlarına neden olmadan dayanabileceği veri kaybını izleme kapsamını da göz önünde bulundurun. Bu iki terim ile en iyi şekilde açıklanabilir: 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ırmaları şunlardır:

• İkincil veri merkezinize dağıtılan ve birincil yönetim grubunu ölçek ve yapılandırmada çoğaltan yinelenen bir yönetim grubu oluşturma.
• İşletimsel ve Veri Ambarı veritabanını desteklemek için bir ikincil veri merkezine yönetim sunucuları soğuk bekleme yapılandırmasıyla dağıtılan ve kurtarma işlemlerinin gerçekleştirilmesi gerekene kadar yönetim grubuna katılmayan ek sunucular dağıtmak.

Kapalı kalma süresi 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 bir 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. Verilerin çoğaltılması için aracılar iki yönetim grubu arasında birden çok ana bilgisayara bağlı olur.

Aşağıdaki diyagram bu tasarım senaryosu için bir örnektir.

Operations Manager dağıtımınız için anında kurtarma gerekmiyorsa 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ü bir yük devretme kümesi örneği (FCI) ve ikincil veri merkezinde tek bir Windows Server Yük Devretme Kümesi’nin (WSFC) parçası olarak tek başına bir SQL Server dağıtılmış olan 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 Always On Kullanılabilirlik Grubu uygulamayı düşünün. Always On Kullanılabilirlik Grubu için ikincil çoğaltma, aşağıdaki diyagramda gösterildiği şekilde FCI olmayan tek başına örnekte bulunur.

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.

Bu süre boyunca aracılar, 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 yeni SQL Server örneklerinin yüklenmesini ve bilinen son çalışır durumdaki yedeğinizden veritabanlarının 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, çalıştırılabilir duruma geri dönmekte büyük olasılıkla daha uzun bir gecikme olacaktır. Bu yaklaşım kabul edilebilir değilse, bekleme kurtarması için ikincil veri merkezinizdeki yönetim sunucularını 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şim, System Center Configuration Management ve Microsoft Monitoring Agent hizmetlerinin durdurulması ve el ile ayarlanması veya devre dışı bırakılması ve yalnızca bir olağanüstü durum kurtarma senaryosunda başlatılması gerekir.

Bir yönetim sunucusu tümleştirmeyi destekliyorsa (doğrudan yönetim sunucusunda veya VMM, Orchestrator veya Service Manager gibi başka bir System Center ürününden barındırılan bir bağlayıcı aracılığıyla), tümleştirme yapılandırmasına ve kurtarma adımları 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ışı kalırsa, aracının yük devretme yapılandırmasının buna izin verdiği durumlarda aracı başka bir sitedeki yönetim sunucusuna yük devreder. Windows aracılarını yalnızca birincil veri merkezinizdeki yönetim sunucularını önbelleğe alacak şekilde yeniden yapılandırarak ikincil veri merkezindeki bir yönetim sunucusuna yük devretmeye çalışmalarını önlemek için bunları yönetmesi gerekir ve bu da kurtarma ve raporlamayı yalnızca geciktirebilir. Aracıyı yükleme sırasında önceden yapılandırmak üzere bir betik (vbScript veya daha iyisi, PowerShell gibi) ile otomatik bir şekilde el ile dağıtırsanız veya aracıyı konsoldan gönderirseniz dağıtım sonrası, yine kurumsal yapılandırma yönetimi çözümünüzle yönetilen betikli bir yöntem kullanarak gerçekleştirebilirsiniz.

Operations Manager yönetilen grubun sürekliliğini korumak için alternatif bir olağanüstü durum kurtarma seçeneği olarak Azure sanal makinelerine dağıtılabilir. Bir 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 karma yapılandırmada değil Azure'da bir sanal makineye dağıtmak 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ı veya ilkeleri vb. göz önünde bulundurun.