Vysoká dostupnost a zotavení po havárii

Důležité

Tato verze Operations Manageru dosáhla konce podpory. Doporučujeme upgradovat na Operations Manager 2022.

System Center – Servery a funkce Nástroje Operations Manager můžou potenciálně selhat, což ovlivňuje funkce nástroje Operations Manager. Objem dat a funkce, o které přijdete při selhání, se v každém scénáři selhání liší. Závisí na roli funkce, která selhává, a na době potřebné k obnovení funkce, která selhává.

Vysoká dostupnost

Potřeby vysoké dostupnosti se řeší zavedením redundance do skupiny pro správu pro operační databázi Operations Manageru a jeho databázi datového skladu, pro servery bran a servery pro správu a pro konkrétní úlohy. Mezi tyto úlohy patří monitorování síťových zařízení, multiplatformní monitorování a úlohy specifické pro skupiny pro správu, které byly dříve spravovány kořenovým serverem pro správu.

Konfigurace několika serverů a jedné skupiny pro správu může využívat SQL Server AlwaysOn k zajištění vysoké dostupnosti a kontinuity služeb databází Operations Manageru. Odolnost serveru pro správu proti chybám je zajištěna tak, že máte alespoň dva servery pro správu a používají fondy zdrojů pro monitorování serverů se systémem UNIX, linuxových serverů a síťových zařízení. Servery Windows založené na agentech je možné nakonfigurovat s primárním a sekundárním serverem pro správu pro přesměrování komunikace agenta v případě selhání serveru pro správu.

Kdyby server pro správu, který hostuje emulaci služby RMS, přestal být k dispozici, je možné emulaci služby RMS přesunout na jiný server pro správu.

Připojení ke konzole Operations Console je možné nastavit jako vysoce dostupná konfigurací vysoké dostupnosti pro službu Data Access Services. Můžete to provést instalací služby Vyrovnávání zatížení sítě (NLB) společnosti Microsoft nebo pomocí hardwarových nástrojů pro vyrovnávání zatížení nebo aliasu DNS. Jeden nebo více serverů pro správu se přidá jako členové fondu vyrovnávání zatížení sítě a při otevření konzoly odkazujete na virtuální název serverů pro správu s vyrovnáváním zatížení zaregistrovaný ve službě DNS.

Poznámka

Server webové konzoly Operations Manageru nepodporuje síťový Load Balancer.

Napříč hranicí vztahu důvěryhodnosti lze nasadit několik serverů brány, takže agenti umístění napříč hranicí vztahu důvěryhodnosti budou mít k dispozici redundantní počet cest. Stejně tak jako mohou agenti převzít služby při selhání mezi primárním serverem pro správu a jedním nebo několika sekundárními server pro správu, mohou agenti převzít služby při selhání také mezi servery brány. Kromě toho lze použít několik serverů brány pro distribuci pracovní zátěže vznikající při správě počítačů spravovaných bez agenta a spravovaných síťových zařízení.

Kromě toho, že díky převzetí služeb při selhání agenta-brány bude dispozice redundance, servery brány lze konfigurovat pro převzetí služeb při selhání mezi servery pro správu ve skupině pro správu, není-li několik serverů pro správu k dispozici.

I když SQL Server Reporting Services podporuje model nasazení se škálováním na více systémů, který umožňuje spustit více instancí serveru sestav, které sdílejí jednu databázi serveru sestav, Operations Manager ho nepodporuje. Generování sestav nástroje Operations Manager nainstaluje vlastní rozšíření zabezpečení jako součást nastavení front-endových komponent, které není možné replikovat napříč webovou farmou.

Zotavení po havárii

Zotavení po havárii souvisí s opatřeními, která zajistí, aby bylo možné obnovit provoz v případě závažného selhání (například ztráty celého datového centra, které hostuje primární infrastrukturu). Je to důležitý prvek, který je potřeba vzít v úvahu při každém nasazení, a rozhodnutí, která jsou učiněná při plánování zotavení po havárii, mají vliv na to, jak bude Operations Manager moct i nadále podporovat proaktivní monitorování a vykazování výkonu a dostupnosti důležitých IT služeb. Tato část se zaměří na doporučenou strategii obnovení po havárii a odolnost. Zároveň popíše, co by se mělo udělat, aby obnovení proběhlo bez problémů.

I když řešení pro vysokou dostupnost a zotavení po havárii zajistí ochranu před selháním systému nebo ztrátou systému, neměli byste se na ně spoléhat při ochraně před náhodnou, nezamýšlenou nebo škodlivou ztrátou nebo poškozením dat. V těchto případech může být nutné pro operace obnovení použít záložní zkopírované nebo zpožděné replikační kopie. V mnoha případech je operace obnovení nejvhodnější formou obnovení po havárii. Jako příklad se dají uvést databáze sestav s nízkou prioritou nebo data analýz. Často jsou náklady na zajištění obnovení po havárii na úrovni systému nebo aplikací na několika lokalitách mnohem vyšší, než je hodnota dat. V případech, kdy je krátkodobá hodnota dat nízká a potřeba přístupu k datům může být zpožděna bez závažných obchodních dopadů, pokud dochází k nadměrnému selhání nebo zotavení po havárii lokality, zvažte použití jednoduchých procesů zálohování a obnovení pro zotavení po havárii, pokud to úspory nákladů vyžadují.

Pochopení vlivu a tolerance výpadků pomůže udělat ta správná rozhodnutí, která zajistí vhodný návrh architektury pro Operations Manager a úroveň složitosti a nákladů podpory obnovení po havárii. Kromě toho zvažte rozsah ztráty dat monitorování, který it organizace může tolerovat, aniž by to mělo obchodní důsledky. To se nejlépe popisuje dvěma pojmy: plánovaná doba obnovení (RTO) a cíl bodu obnovení (RPO).

Dvě nejběžnější konfigurace návrhu obnovení po havárii pro Operations Manager jsou tyto:

• Vytvoření duplicitní skupiny pro správu nasazené do sekundárního datacentra, která duplikuje škálování a konfiguraci primární skupiny pro správu.
• Nasazení dalších serverů do sekundárního datacentra pro podporu provozní databáze a databáze datového skladu. Servery pro správu se nasadí v konfiguraci nejnižší úrovně provozu, takže se nebudou podílet na skupině pro správu, dokud se nemusí udělat akce obnovení.

Nasazení duplicitní skupiny pro správu je možné v případě, že neexistuje žádná tolerance k výpadkům. jedná se však o nejsložitější možnost. Konfigurace mezi oběma musí být konzistentní, aby při přeškrtání nebyl žádný rozdíl v tom, co je monitorováno, upozorňováno nebo hlášeno, prezentováno a nakonec eskalováno. Integrace s jinými monitorovacími platformami nebo platformami ITSM, jako je System Center – Service Manager, Remedy nebo ServiceNow, bude také potřeba, aby byla nakonfigurovaná v aktivním nebo pasivním stavu, aby nedocházelo ke zdvojování incidentů, položek konfigurace atd. Pro agenty se nastaví multihoming mezi oběma skupinami pro správu, takže bude docházet k duplikaci dat.

Následující diagram znázorňuje ukázku takového scénáře návrhu.

Pokud okamžité obnovení není pro vaše nasazení Nástroje Operations Manager nezbytné a chcete se vyhnout složitosti duplicitní skupiny pro správu, můžete alternativně nasadit další komponenty skupiny pro správu v sekundárním datovém centru, aby se zachovaly funkce vaší skupiny pro správu. Přinejmenším zvažte možnost implementovat skupinu dostupnosti AlwaysOn SQL Serveru 2014 nebo 2016, aby bylo možné poskytovat obnovení provozní databáze a databáze datového skladu mezi dvěma a více datacentry. V primárním datacentru je nasazená instance clusteru s podporou převzetí služeb při selhání a dvěma uzly, v sekundárním datacentru je pak samostatný SQL Server, který je součástí jediného clusteru Windows Server Failover Cluster (WSFC). Sekundární replikace skupiny dostupnosti AlwaysOn by byla na samostatné instanci, která není FCI. To ukazuje následující diagram.

V tomto příkladu byste museli nasadit jeden nebo více serverů Windows se stejnou konfigurací hardwaru a názvem počítače a znovu nainstalovat roli serveru pro správu pomocí parametru /Recover . Tady je ukázkový skript:

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

Další informace najdete v tématu instalace nástroje Operations Manager z příkazového řádku.

Během této doby budou agenti shromážděná data (výstrahy, události, výkon atd.) zařadit do fronty, dokud nebudou moct obnovit komunikaci se serverem pro správu ve skupině pro správu. Díky tomuto přístupu je možné se vyhnout instalaci nových instancí SQL Serveru a obnovení databází z poslední známé funkční zálohy. V tomto scénáři obnovení ale pravděpodobně dojde k delšímu zpoždění při návratu do provozuschopného stavu, protože budete muset nasadit další role potřebné k obnovení minimálních funkcí monitorování. Pokud takový přístup není přijatelný, můžete v sekundárním datacentru nasadit servery pro správu pro pohotovostní obnovení. Odeberte je jako členy tří primárních fondů prostředků – fond zdrojů všech serverů pro správu, oznámení a přiřazení AD. To zahrnuje také jakýkoli vlastní fond zdrojů, který může zahrnovat servery pro správu hostované v primárním datacentru a musí i nadále fungovat jako součást plánu obnovení. Služby System Center Data Access, System Center Configuration Management a Microsoft Monitoring Agent by se měly zastavit a nastavit jako ručně spouštěné nebo úplně zakázané. Spouštět by se měly jedině ve scénářích obnovení po havárii.

Pokud server pro správu podporuje integraci (prostřednictvím konektoru hostovaného přímo na serveru pro správu nebo z jiného produktu System Center, jako je VMM, Orchestrator nebo Service Manager), bude potřeba tuto integraci naplánovat pomocí ručního nebo automatického postupu obnovení v závislosti na konfiguraci integrace a posloupnosti kroků obnovení. Tím se zajistí, že se zachytí všechny ostatní závislosti na serveru pro správu a naplánují se na dobu, kdy je potřeba implementovat plán zotavení po havárii.

Pokud jedna lokalita přejde do režimu offline, server pro správu v jiné lokalitě převezme služby agenta. Musí to ale povolit konfigurace převzetí služeb při selhání agenta. Překonfigurujte agenty Windows tak, aby ukládali do mezipaměti jenom servery pro správu v primárním datacentru, které by je měly spravovat, aby se jim zabránilo v pokusu o převzetí služeb při selhání serverem pro správu v sekundárním datacentru, což by zpozdilo pouze obnovení a generování sestav. Toho lze dosáhnout, pokud ručně nasadíte agenta automatizovaným způsobem pomocí skriptu (například jazyka VBScript nebo ještě lépe PowerShellu), který se má předem nakonfigurovat během instalace, nebo po nasazení, pokud odešlete agenta z konzoly nástroje, a to znovu pomocí skriptované metody spravované pomocí podnikového řešení pro správu konfigurace.

Jako alternativní možnost obnovení po havárii se Operations Manager dá nasadit do virtuálních počítačů Azure. Díky tomu zůstane skupina pro správu v provozu. Bude také nutné nasadit SQL Server na virtuální počítač v Azure, a ne v hybridní konfiguraci, protože latence mezi serverem pro správu a SQL Server, které hostují databáze Operations Manageru, negativně ovlivní výkon skupiny pro správu.

Zvažte rozsah monitorování, topologii sítě a síťové připojení k Microsoft Azure (tj. vpn typu site-to-site nebo ExpressRoute), body integrace (tj. řešení ITSM, jiné produkty System Center, doplňky třetích částí atd.), přístup ke konzole, zákonné nebo relevantní zákony nebo zásady atd., aby bylo možné správně navrhovat tento scénář v rámci Azure IaaS nebo jiných poskytovatelů veřejného cloudu.