Hög tillgänglighet och haveriberedskap

Viktigt

Den här versionen av Operations Manager har nått slutet av supporten. Vi rekommenderar att du uppgraderar till Operations Manager 2022.

System Center – Operations Manager-servrar och -funktioner kan eventuellt misslyckas, vilket påverkar Operations Manager-funktionerna. Mängden data och funktioner som försvinner skiljer sig mellan olika felscenarier. Det beror på rollen för den misslyckade funktionen och hur lång tid det tar att återställa den misslyckade funktionen.

Hög tillgänglighet

Hög tillgänglighet uppnås genom redundans som byggs in i hanteringsgruppen för Operations Managers operativa (använda) databas och informationslagerdatabas, gateway- och hanteringsservrarna och specifika arbetsbelastningar. Dessa arbetsbelastningar omfattar övervakning av nätverksenheter, plattformsoberoende övervakning och hanteringsgruppsspecifika arbetsbelastningar som tidigare hanterades av rothanteringsservern.

Konfigurationen av flera servrar, en enda hanteringsgrupp, kan använda SQL Server AlwaysOn för att tillhandahålla hög tillgänglighet och tjänstkontinuitet för Operations Manager-databaserna. Feltolerans för hanteringsservern tillhandahålls genom att ha minst två hanteringsservrar och genom att använda resurspoolerna för övervakning av UNIX-servrar, Linux-servrar och nätverksenheter. Agentbaserade Windows-servrar kan konfigureras med en primär och sekundär hanteringsserver för att omdirigera agentkommunikation om en hanteringsserver misslyckas.

RMS-emulatorn kan också flyttas till en annan hanteringsserver om hanteringsservern som är värd för RMS-emulatorn blir otillgänglig.

Driftkonsolanslutningar kan göras mycket tillgängliga genom att konfigurera hög tillgänglighet för Data Access Services. Detta kan göras genom att installera Microsoft Network Load Balancing (NLB) eller med hjälp av en maskinvarubaserad lastbalanserare eller DNS-alias. En eller flera hanteringsservrar läggs till som medlemmar i NLB-poolen och när du öppnar konsolen refererar du till det virtuella namnet som är registrerat i DNS för de belastningsutjämningshanteringsservrarna.

Anteckning

Ett nätverk Load Balancer stöds inte för Operations Manager-webbkonsolservern.

Du kan distribuera flera gateway-servrar över en förtroendegräns för att ge redundanta sökvägar för agenter som ligger utanför den aktuella förtroendegränsen. Precis som agenter växlar över mellan en primär hanteringsserver och en eller flera sekundära hanteringsservrar, kan de växla över mellan gateway-servrar. Dessutom kan flera gateway-servrar användas om du vill fördela arbetsbelastningen för hantering av datorer utan agenter och hanterade nätverksenheter.

Förutom att tillhandahålla redundans via agent- och gatewayväxling, kan gateway-servrar konfigureras för att växla över mellan hanteringsservrarna i en hanteringsgrupp om flera hanteringsservrar finns tillgängliga.

Även om SQL Server Reporting Services stöder en utskalningsdistributionsmodell som gör att du kan köra flera rapportserverinstanser som delar en enda rapportserverdatabas, stöds den inte med Operations Manager. Operations Manager Reporting installerar ett anpassat säkerhetstillägg som en del av konfigurationen av klientdelskomponenterna, som inte kan replikeras i webbgruppen.

Haveriberedskap

Haveriberedskap avser åtgärder som vidtas för att säkerställa att åtgärder kan återupptas om ett oåterkalleligt fel uppstår (till exempel förlust av hela datacentret som är värd för den primära infrastrukturen). Det är ett viktigt element som måste beaktas i alla distributioner och de beslut som fattas i planeringen för haveriberedskap påverkar hur Operations Manager kommer att kunna fortsätta att stödja proaktiv övervakning och rapportering av prestanda och tillgänglighet för dina kritiska IT-tjänster. I det här avsnittet fokuserar vi på den rekommenderade strategin för haveriberedskap och återhämtning och de steg som bör vidtas för att säkerställa en smidig återställning.

Även om HA- och DR-lösningar ger skydd mot systemfel eller systemförlust bör de inte förlita sig på skydd mot oavsiktlig, oavsiktlig eller skadlig dataförlust eller skada. I dessa fall kan säkerhetskopiera kopierade eller fördröjda replikeringskopior behöva användas för återställningsåtgärder. I många fall är en återställningsåtgärd den lämpligaste formen av DR. Ett exempel på detta kan vara analysdata eller en rapporteringsdatabas med låg prioritet. I många fall uppväger kostnaden för att aktivera DR för flera platser på system- eller programnivå värdet av informationen. I de fall då datavärdet på kort sikt är lågt och behovet av att komma åt data kan fördröjas utan allvarliga affärseffekter om ett fel eller plats-DR är överdrivet bör du överväga att använda enkla säkerhetskopierings- och återställningsprocesser för dr om kostnadsbesparingarna motiverar det.

Genom att lära dig mer om toleransen och effekterna vid ett driftavbrott kan du fatta bättre beslut när du utformar Operations Manager-arkitekturen och planerar för komplexitetsnivån och kostnaden som krävs för att ge stöd för haveriberedskap. Tänk också på omfattningen av övervakning av dataförluster som IT-organisationen kan tolerera utan att orsaka affärskonsekvenser. Detta beskrivs bäst med hjälp av två termer: mål för återställningstid (RTO) och mål för återställningspunkt (RPO).

De två vanligaste designkonfigurationerna för haveriberedskap med Operations Manager är:

• Skapa en duplicerad hanteringsgrupp som distribueras till ditt sekundära datacenter som dupliceras i skala och konfiguration av den primära hanteringsgruppen.
• Distribuera ytterligare servrar i ett sekundärt datacenter för drift- och informationslagerdatabaserna, med hanteringsservrar som distribueras i en konfiguration för kallt vänteläge och som inte är delaktiga i hanteringsgruppen förrän återställningsåtgärder behöver utföras.

Att distribuera en duplicerad hanteringsgrupp är ett alternativ när det inte finns någon tolerans för stilleståndstid. Det är dock det mest komplexa alternativet. Konfigurationen mellan båda måste vara konsekvent så att det inte finns någon skillnad i vad som övervakas, aviseras eller rapporteras, presenteras och slutligen eskaleras när du skär ned. Integrering med andra övervakningsplattformar eller ITSM-plattformar som System Center – Service Manager, Remedy eller ServiceNow måste också finnas och eventuellt konfigureras i ett aktivt/passivt tillstånd för att undvika duplicering av incidenter, konfigurationsobjekt och så vidare. Agenterna konfigureras som multihomed mellan de båda hanteringsgrupperna så att data dupliceras.

Följande diagram är ett exempel på det här designscenariot.

Om omedelbar återställning inte behövs för din Operations Manager-distribution och du vill undvika komplexiteten i en duplicerad hanteringsgrupp kan du också distribuera ytterligare hanteringsgruppskomponenter i ditt sekundära datacenter för att behålla funktionerna i hanteringsgruppen. Du bör åtminstone överväga att implementera en Always On-tillgänglighetsgrupp för SQL Server 2014 eller 2016 för att tillhandahålla återställning av drift- och informationslagerdatabaserna mellan två eller flera datacenter, där en redundansklusterinstans (FCI) med två noder distribueras i det primära datacentret, och en fristående SQL Server i det sekundära datacentret som en del av ett enskilt Windows Server-redundanskluster (WSFC). Den sekundära repliken för Always On-tillgänglighetsgruppen finns på den fristående instansen (inte FCI-instansen), som du ser i följande diagram.

I det här exemplet måste du distribuera en eller flera Windows-servrar med samma maskinvarukonfiguration och datornamn och installera om hanteringsserverrollen med parametern /Recover . Här är ett exempel:

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

Mer information finns i installera Operations Manager från kommandotolken.

Under den här tiden köar agenter de data som samlas in (aviseringar, händelser, prestanda och så vidare) tills de kan återuppta kommunikationen med en hanteringsserver i hanteringsgruppen. Med den här metoden undviker du att behöva installera nya instanser av SQL Server och att återställa databaser från din senaste lämpliga säkerhetskopia. I det här återställningsscenariot kommer det dock sannolikt att bli en längre fördröjning när du återgår till ett driftbart tillstånd eftersom du måste distribuera de andra roller som krävs för att återuppta minsta övervakningsfunktionalitet. Om den här metoden inte är acceptabel kan du distribuera hanteringsservrar i det sekundära datacentret för återställning i vänteläge. Ta bort dem som medlemmar i de tre primära resurspoolerna – Resurspool för alla hanteringsservrar, meddelanden och AD-tilldelning. Detta omfattar även alla anpassade resurspooler, som kan innehålla hanteringsservrar som finns i det primära datacentret och som måste fortsätta att fungera som en del av återställningsplanen. Tjänsterna System Center Data Access, System Center Configuration Management och Microsoft Monitoring Agent bör stoppas, konfigureras som inaktiverade eller med inställningen Manuellt och endast startas i ett katastrofåterställningsscenario.

Om en hanteringsserver stöder integrering (via en anslutningsapp som finns direkt på hanteringsservern eller från en annan System Center-produkt som VMM, Orchestrator eller Service Manager) måste detta planeras med manuella eller automatiska återställningssteg beroende på integreringskonfigurationen och sekvensen med återställningssteg. Detta säkerställer att alla andra beroenden på hanteringsservern samlas in och planeras för när haveriberedskapsplanen måste implementeras.

Om en plats kopplar från växlar agenten över till hanteringsservern på en annan plats, förutsatt att agentens redundanskonfiguration medger detta. Konfigurera om Windows-agenterna så att de endast cachelagrar hanteringsservrar i ditt primära datacenter som ska hantera dem för att förhindra att de försöker redundansväxlara till en hanteringsserver i det sekundära datacentret, vilket bara skulle fördröja återställningen och rapporteringen. Detta kan åstadkommas om du manuellt distribuerar agenten på ett automatiserat sätt med ett skript (till exempel VBScript eller ännu bättre, PowerShell) för att förkonfigurera under installationen eller efter distributionen om du skickar agenten från -konsolen, igen med hjälp av en skriptbaserad metod som hanteras med din företagskonfigurationshanteringslösning.

Operations Manager kan distribueras på virtuella Azure-datorer som ett alternativt haveriberedskapsalternativ för att upprätthålla hanteringsgruppens kontinuitet. Du måste också distribuera SQL Server på en virtuell dator i Azure och inte i en hybridkonfiguration, eftersom svarstiden mellan en hanteringsserver och SQL Server som är värd för Operations Manager-databaserna påverkar hanteringsgruppens prestanda negativt.

Överväg övervakningsomfånget, nätverkstopologin och nätverksanslutningen till Microsoft Azure (det vill säga plats-till-plats-VPN eller ExpressRoute), integreringsplatser (det vill säga ITSM-lösningar, andra System Center-produkter, tillägg från tredje delen och så vidare), konsolåtkomst, regelmässiga eller relevanta lagar eller principer och så vidare för att kunna utforma det här scenariot korrekt i Azure IaaS eller andra offentliga molnleverantörer.