Vysoká dostupnost a zotavení po havárii

Servery a funkce nástroje System Center – Operations Manager můžou potenciálně selhat, což má vliv na funkčnost nástroje Operations Manager. Množství dat a funkcí ztracených během selhání se v jednotlivých scénářích selhání liší. Závisí na roli funkce, která selhává, a na době potřebnou k obnovení funkce, která selhává.

Vysoká dostupnost

Požadavky na vysokou dostupnost se řeší vytvořením redundance do skupiny pro správu pro provozní databáze a databáze datového skladu Operations Manageru, brány a servery pro správu a konkrétní úlohy. Mezi tyto úlohy patří monitorování síťových zařízení, monitorování napříč platformami a úlohy specifické pro skupinu pro správu, které byly dříve spravovány kořenovým serverem pro správu.

Několik serverů, konfigurace 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 proti chybám serveru pro správu je poskytována alespoň dvěma servery pro správu a pomocí fondů zdrojů pro monitorování serverů UNIX, serverů Linux a síťových zařízení. Servery s Windows založené na agentech je možné nakonfigurovat s primárním a sekundárním serverem pro správu, aby přesměroval komunikaci agenta, pokud server pro správu selže.

Emulátor služby RMS je možné přesunout také na jiný server pro správu, pokud server pro správu hostující emulátor služby RMS přestane být dostupný.

Připojení konzoly Operations Console je možné zpřístupnit tak, že nakonfigurujete vysokou dostupnost pro službu Data Access Services. Můžete to provést instalací služby Vyrovnávání zatížení sítě microsoftu (NLB) 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 nlB a při otevření konzoly odkazujete na virtuální název zaregistrovaný v DNS serverů pro správu s vyrovnáváním zatížení.

Poznámka:

Nástroj pro vyrovnávání zatížení sítě není pro server webové konzoly Operations Manageru podporovaný.

K zajištění redundantních cest pro agenty, kteří leží přes tuto hranici důvěryhodnosti, je možné nasadit několik serverů brány. Stejně jako agenti můžou převzít služby při selhání mezi primárním serverem pro správu a jedním nebo více sekundárními servery pro správu, mohou také převzít služby při selhání mezi servery brány. K distribuci úloh správy počítačů spravovaných bez agentů a spravovaných síťových zařízení je navíc možné použít několik serverů brány.

Kromě zajištění redundance prostřednictvím převzetí služeb při selhání brány agenta je možné servery brány nakonfigurovat tak, aby převzaly služby při selhání mezi servery pro správu ve skupině pro správu, pokud je k dispozici více serverů pro správu.

Služba SQL Server Reporting Services sice podporuje model nasazení se škálováním na více instancí, které umožňují spouštět více instancí serveru sestav, které sdílejí jednu databázi serveru sestav, ale nástroj Operations Manager nepodporuje. Generování sestav nástroje Operations Manager nainstaluje vlastní rozšíření zabezpečení jako součást instalace front-endových komponent, které se nedají replikovat napříč webovou farmou.

Zotavení po havárii

Zotavení po havárii souvisí s opatřeními přijatými k zajištění obnovení operací v případě závažného selhání (například ztráty celého datového centra, které je hostitelem primární infrastruktury). Jde o důležitý prvek, který je třeba vzít v úvahu při každém nasazení, a rozhodnutí učiněná při plánování obnovy po havárii ovlivňují, jak bude systém Operations Manager schopen nadále podporovat proaktivní monitorování a vykazování výkonu a dostupnosti kritických služeb IT. Tato část se zaměří na doporučenou strategii zotavení po havárii a odolnosti a na to, jaké kroky by měly být podniknuty k zajištění hladké obnovy.

I když řešení pro vysokou dostupnost a zotavení po havárii poskytují ochranu před selháním systému nebo ztrátou systému, neměli by se spoléhat na ochranu před náhodným, nezamýšleným nebo škodlivými ztrátami nebo poškozením dat. V těchto případech může být nutné pro operace obnovení použít záložní kopie nebo zpožděné kopie replikace. V mnoha případech je operace obnovení nejvhodnější formou zotavení po havárii. Jedním z příkladů může být databáze sestav s nízkou prioritou nebo data analýzy. V mnoha případech náklady na povolení zotavení po havárii ve více lokalitách na úrovni systému nebo aplikace výrazně převáží hodnotu dat. V případech, kdy je krátkodobá hodnota dat nízká a nutnost přístupu k datům může být zpožděna bez závažného obchodního dopadu, pokud dojde 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 úspora nákladů zaručuje.

Pochopení dopadu a tolerance výpadků pomůže řídit rozhodnutí, která je potřeba pochopit, aby bylo možné správně navrhnout architekturu pro Operations Manager a úroveň složitosti a nákladů vyžadovaných pro podporu zotavení po havárii. Zvažte také rozsah ztráty dat monitorování, kterou může IT organizace tolerovat, aniž by to způsobilo obchodní důsledky. Nejlépe je popsáno ve dvou termínech: cíl doby obnovení (RTO) a cíl bodu obnovení (RPO).

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

• Vytvoření duplicitní skupiny pro správu nasazené v sekundárním datovém centru, která svým rozsahem a konfigurací kopíruje primární skupinu pro správu.
• Nasazení dalších serverů v sekundárním datovém centru pro podporu provozní databáze a databáze datového skladu, přičemž servery pro správu jsou nasazeny v pohotovostní konfiguraci a nejsou zapojeny do skupiny pro správu, dokud není třeba provést akce obnovy.

Nasazení duplicitní skupiny pro správu je možnost, pokud neexistuje žádná tolerance pro výpadky; jedná se ale o nejsložitější možnost. Konfigurace mezi oběma musí být konzistentní, takže když dojde k poklesu, není žá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, musí existovat také a případně nakonfigurovaná v aktivním/pasivním stavu, aby se zabránilo duplikaci incidentů, položek konfigurace atd. Agenti budou multihomední mezi oběma skupinami pro správu, takže budou duplikovat data.

Následující diagram je příkladem tohoto scénáře návrhu.

Pokud pro nasazení Operations Manageru není potřeba okamžité obnovení a chcete se vyhnout složitosti duplicitní skupiny pro správu, můžete případně do sekundárního datacentra nasadit další komponenty skupiny pro správu, abyste zachovali funkčnost skupiny pro správu. Minimálně zvažte implementaci skupiny dostupnosti AlwaysOn pro SQL Server 2014 nebo 2016, která zajišťuje obnovení databází provozního a datového skladu mezi dvěma nebo více datovými centry, kde je instance clusteru s podporou převzetí služeb při selhání se dvěma uzly (FCI) nasazena v primárním datovém centru a samostatný SQL Server v sekundárním datacentru jako součást jednoho clusteru s podporou převzetí služeb při selhání Windows Serveru (WSFC). Sekundární replika skupiny dostupnosti AlwaysOn by byla v samostatné instanci jiné než FCI, jak je znázorněno v následujícím diagramu.

V tomto příkladu byste museli nasadit jeden nebo více serverů s Windows se stejnou konfigurací hardwaru a názvem počítače a přeinstalovat 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 agenti zařadí data shromážděná do fronty (výstrahy, události, výkon atd.), dokud nebudou moct pokračovat v komunikaci se serverem pro správu ve skupině pro správu. Tento přístup zabraňuje instalaci nových instancí SQL Serveru a obnovení databází z poslední známé dobré zálohy. V tomto scénáři obnovení ale pravděpodobně dojde k delšímu zpoždění v návratu do operovatelného stavu, protože budete muset nasadit další role nezbytné k obnovení minimálních funkcí monitorování. Pokud tento přístup není přijatelný, můžete servery pro správu nasadit do sekundárního datového centra pro pohotovostní obnovení. Odeberte je jako členy tří primárních fondů zdrojů – Fond zdrojů všech serverů pro správu, oznámení a přiřazení AD. Patří sem také jakýkoli vlastní fond zdrojů, který může zahrnovat servery pro správu hostované v primárním datacentru a které musí nadále fungovat jako součást plánu obnovení. Služby System Center Data Access, System Center Configuration Management a Microsoft Monitoring Agent by měly být zastaveny a nastaveny na ruční nebo zakázání a spouštěné pouze ve scénáři zotavení 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 naplánovat ruční nebo automatické kroky obnovení v závislosti na konfiguraci integrace a posloupnosti kroků obnovení. Tím se zajistí, že se zachytí a naplánuje jakákoli jiná závislost na serveru pro správu, kdy je potřeba implementovat plán zotavení po havárii.

Pokud jedna lokalita přejde do offline režimu, agent převezme služby při selhání serveru pro správu v jiné lokalitě za předpokladu, že to konfigurace převzetí služeb při selhání agenta umožňuje. Překonfigurujte agenty Windows tak, aby ukládaly do mezipaměti pouze servery pro správu v primárním datovém centru, které by je měly spravovat, aby se jim zabránilo v pokusu o převzetí služeb při selhání na server pro správu v sekundárním datovém centru, což by zpozdilo pouze obnovení a generování sestav. Toho lze dosáhnout, pokud agenta ručně nasadíte automatizovaným způsobem pomocí skriptu (například VBScriptu nebo ještě lepšího, PowerShellu), který se má předkonfigurovat během instalace nebo po nasazení, pokud nasdílíte agenta z konzoly, znovu pomocí skriptované metody spravované pomocí podnikového řešení pro správu konfigurace.

Operations Manager je možné nasadit na virtuální počítače Azure jako alternativní možnost zotavení po havárii, aby se zachovala kontinuita skupiny pro správu. Bude nutné také 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 Serverem hostujícím 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), integrační body (tj. řešení ITSM, další produkty System Center, doplňky třetích částí atd.), přístup ke konzole, regulační 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.