Delen via

Hoge beschikbaarheid en herstel na noodgevallen

  • Artikel

Belangrijk

Deze versie van Operations Manager heeft het einde van de ondersteuning bereikt. U wordt aangeraden een upgrade uit te voeren naar Operations Manager 2022.

System Center: Operations Manager-servers en -functies kunnen mogelijk mislukken, wat van invloed is op de functionaliteit van Operations Manager. De hoeveelheid gegevens en functionaliteit die verloren gaan bij uitval, varieert per scenario. Dit is afhankelijk van de rol van de mislukte functie en de tijd die nodig is om de mislukte functie te herstellen.

Hoge beschikbaarheid

Aan de behoefte aan maximale beschikbaarheid wordt tegemoetgekomen door redundantie in te bouwen in de beheergroep voor de operationele en datawarehouse-databases van Operations Manager, de gateway- en beheerservers, en specifieke werkbelastingen. Deze workloads omvatten netwerkapparaatbewaking, platformoverschrijdende bewaking en beheergroepspecifieke workloads die eerder werden beheerd door de hoofdbeheerserver.

De configuratie van meerdere servers en één beheergroep kan gebruikmaken van SQL Server AlwaysOn voor hoge beschikbaarheid en servicecontinuïteit van de Operations Manager-databases. Fouttolerantie voor beheerservers wordt geboden door ten minste twee beheerservers te hebben en door de resourcegroepen te gebruiken voor het bewaken van UNIX-servers, Linux-servers en netwerkapparaten. Windows-servers op basis van agents kunnen worden geconfigureerd met een primaire en secundaire beheerserver om agentcommunicatie om te leiden als een beheerserver uitvalt.

De RMS-emulator kan ook worden verplaatst naar een andere beheerserver, mocht de beheerserver die als host fungeert voor de RMS-emulator niet meer beschikbaar zijn.

Operations-consoleverbindingen kunnen maximaal beschikbaar worden gemaakt door hoge beschikbaarheid te configureren voor de Data Access Services. Dit kan worden gedaan door Microsoft Network Load Balancing (NLB) te installeren of door een op hardware gebaseerde load balancers of DNS-alias te gebruiken. Een of meer beheerservers worden toegevoegd als leden van de NLB-pool en wanneer u een van de console opent, verwijst u naar de virtuele naam die is geregistreerd in DNS, van de beheerservers met gelijke taakverdeling.

Notitie

Een netwerk Load Balancer wordt niet ondersteund voor de Operations Manager-webconsoleserver.

Meerdere gatewayservers kunnen buiten de grens van een vertrouwensrelatie worden geïmplementeerd om te voorzien in redundante paden voor agents die buiten die grens van een vertrouwensrelatie liggen. Net zoals een failover van agents mogelijk is tussen een primaire beheerserver en een of meer secundaire beheerservers, is een failover ook mogelijk tussen gatewayservers. Daarnaast kunnen meerdere gatewayservers worden gebruikt om de werklast van het beheren van zonder agents beheerde computers en beheerde netwerkapparaten te verdelen.

Naast het voorzien in redundantie via agent-gateway-failover, kunnen gatewayservers ook worden geconfigureerd voor failovers tussen beheerservers in een beheergroep als er meerdere beheerservers beschikbaar zijn.

Hoewel SQL Server Reporting Services ondersteuning biedt voor een uitschaalmodel waarmee u meerdere rapportserverexemplaren kunt uitvoeren die één rapportserverdatabase delen, wordt dit niet ondersteund met Operations Manager. Operations Manager-rapportage installeert een aangepaste beveiligingsextensie als onderdeel van de installatie van de front-endonderdelen, die niet kan worden gerepliceerd in de webfarm.

Herstel na noodgeval

Herstel na noodgeval heeft betrekking op maatregelen die zijn genomen om ervoor te zorgen dat bewerkingen kunnen worden hervat als er een catastrofale fout optreedt (bijvoorbeeld verlies van het hele datacenter dat als host fungeert voor de primaire infrastructuur). Het is een belangrijk element waarmee rekening moet worden gehouden bij elke implementatie en de beslissingen die worden genomen bij het plannen van herstel na noodgevallen, zijn van invloed op de manier waarop Operations Manager proactieve bewaking en rapportage van de prestaties en beschikbaarheid van uw kritieke IT-services kan blijven ondersteunen. In deze sectie wordt de nadruk gelegd op de aanbevolen strategie voor tolerantie en herstel na noodgevallen, en welke stappen moeten worden genomen voor een soepel herstel.

Hoewel hoge beschikbaarheids- en herstelproblemen oplossingen bescherming bieden tegen systeemfouten of systeemverlies, mogen ze niet worden gebruikt voor bescherming tegen onbedoeld, onbedoeld of schadelijk gegevensverlies of beschadiging. In deze gevallen moeten mogelijk back-ups van gekopieerde of achterstallige replicatiekopieën worden gebruikt voor herstelbewerkingen. In veel gevallen is een herstelbewerking de meest geschikte vorm van HN. Een voorbeeld hiervan is een rapportagedatabase of analysegegevens van lage prioriteit. In veel gevallen wegen de kosten voor het inschakelen van multisite-HN op systeem- of toepassingsniveau ruimschoots op tegen de waarde van de gegevens. In gevallen waarin de waarde van de gegevens op korte termijn laag is en de noodzaak om toegang te krijgen tot de gegevens kan worden uitgesteld zonder ernstige bedrijfsimpact als een storing of noodherstel op de site overmatig is, kunt u overwegen om eenvoudige back-up- en herstelprocessen voor herstel na noodgeval te gebruiken als de kostenbesparingen dit rechtvaardigen.

Kennis van de impact en tolerantie voor uitvaltijd is nuttig bij het nemen van beslissingen voor het op juiste wijze ontwerpen van de architectuur voor Operations Manager en de mate van complexiteit en de kosten die voor de ondersteuning van herstel na noodgevallen zijn vereist. Houd ook rekening met de mate van bewaking van gegevensverlies die de IT-organisatie kan tolereren zonder bedrijfsgevolgen te veroorzaken. Dit kan het beste in twee termen worden beschreven: beoogde hersteltijd en beoogd herstelpunt.

De twee meestvoorkomende ontwerpconfiguraties voor herstel na noodgevallen voor Operations Manager zijn:

  • Een dubbele beheergroep maken die is geïmplementeerd in uw secundaire datacenter, waarmee de primaire beheergroep in schaal en configuratie wordt gedupliceerd.
  • Het implementeren van aanvullende servers in een secundair datacenter ter ondersteuning van de operationele en datawarehouse-database, waarbij beheerservers worden geïmplementeerd in een koude stand-by-configuratie, en die niet in de beheergroep deelnemen voordat er herstelacties moeten worden uitgevoerd.

Het implementeren van een dubbele beheergroep is een optie wanneer er geen tolerantie voor downtime is; Dit is echter de meest complexe optie. De configuratie tussen beide moet consistent zijn, zodat er geen verschil is in wat er wordt bewaakt, gewaarschuwd of gerapporteerd, gepresenteerd en uiteindelijk geëscaleerd. Integratie met andere bewakingsplatforms of ITSM-platforms zoals System Center - Service Manager, Remedy of ServiceNow moet ook bestaan en mogelijk zijn geconfigureerd in een actieve/passieve status om duplicatie van incidenten, configuratie-items, enzovoort te voorkomen. Agenten worden gemulti-homed voor beide beheergroepen, zodat de gegevens worden gedupliceerd.

In onderstaand diagram ziet u een voorbeeld van dit ontwerpscenario.

Diagram van dubbele MG's.

Als onmiddellijk herstel niet nodig is voor uw Operations Manager-implementatie en u de complexiteit van een dubbele beheergroep wilt vermijden, kunt u ook extra beheergroeponderdelen implementeren in uw secundaire datacenter om de functionaliteit van uw beheergroep te behouden. Ga minimaal uit van de implementatie van een SQL Server 2014 of 2016 AlwaysOn-beschikbaarheidsgroep om herstel te kunnen bieden van de operationele en datawarehouse-database voor twee of meer datacenters, waarbij een failovercluster-exemplaar (FCI) met twee knooppunten in het primaire datacenter wordt geïmplementeerd en een zelfstandige SQL-server in het secundaire datacenter als onderdeel van één Windows Server Failover Cluster (WSFC). De secundaire replica voor de AlwaysOn-beschikbaarheidsgroep is in dat geval het zelfstandige, niet-FCI-exemplaar, zoals weergegeven in het onderstaande diagram.

Diagram van eenvoudige configuratie van herstel na noodgeval.

In dit voorbeeld moet u een of meer Windows-servers met dezelfde hardwareconfiguratie en computernaam implementeren en de beheerserverfunctie opnieuw installeren met behulp van de parameter /Recover . Hier volgt een voorbeeld:


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

Zie Operations Manager installeren vanaf de opdrachtprompt voor meer informatie.

Gedurende deze tijd plaatsen agents de verzamelde gegevens (waarschuwingen, gebeurtenissen, prestaties, enzovoort) in de wachtrij totdat ze de communicatie met een beheerserver in de beheergroep kunnen hervatten. Met deze benadering wordt voorkomen dat nieuwe exemplaren van SQL Server moeten worden geïnstalleerd en databases moeten worden hersteld vanuit de laatst bekende, goede back-up. In dit herstelscenario is het echter waarschijnlijk langer om terug te keren naar een actieve status, aangezien u de andere rollen moet implementeren die nodig zijn om de minimale bewakingsfunctionaliteit te hervatten. Als dit niet acceptabel is, kunt u beheerservers implementeren in uw secundaire datacenter voor on-standby herstel. Verwijder deze als leden van de drie primaire resourcegroepen: Resourcegroep alle beheerservers, Meldingen en AD-toewijzing. Dit omvat ook aangepaste resourcegroepen, waaronder beheerservers die worden gehost in het primaire datacenter en die moeten blijven functioneren als onderdeel van het herstelplan. De services System Center Data Access, System Center Configuration Management en Microsoft Monitoring Agent moeten worden gestopt en ingesteld op handmatig of uitschakelen. Start ze alleen bij een scenario van herstel na noodgevallen.

Als een beheerserver integratie ondersteunt (via een connector die rechtstreeks op de beheerserver wordt gehost of vanuit een ander System Center-product zoals VMM, Orchestrator of Service Manager), moet dit worden gepland met handmatige of automatische herstelstappen, afhankelijk van de integratieconfiguratie en de volgorde van herstelstappen. Dit zorgt ervoor dat alle andere afhankelijkheid van de beheerserver wordt vastgelegd en gepland voor wanneer het noodherstelplan moet worden geïmplementeerd.

Afbeelding van de configuratie voor complexe herstel na noodgeval.

Als er één site offline gaat, wordt er een fail-overoverschakeling uitgevoerd naar de beheerserver op een andere site, aangenomen dat de failoverconfiguratie van de agent dit toestaat. Configureer de Windows-agents opnieuw zodat alleen beheerservers in uw primaire datacenter in de cache worden opgeslagen die ze moeten beheren om te voorkomen dat ze een failover uitvoeren naar een beheerserver in het secundaire datacenter, waardoor het herstel en de rapportage alleen worden vertraagd. Dit kan worden bereikt als u de agent handmatig op een geautomatiseerde manier implementeert met een script (bijvoorbeeld VBScript of nog beter, PowerShell) om vooraf te configureren tijdens de installatie of na de implementatie als u de agent vanaf de console pusht, opnieuw met behulp van een scriptmethode die wordt beheerd met uw bedrijfsconfiguratiebeheeroplossing.

Operations Manager kan worden geïmplementeerd op virtuele machines van Azure als een alternatieve methode voor herstel na noodgevallen om de continuïteit van de beheergroep te handhaven. Het is nodig om ook SQL Server te implementeren op een virtuele machine in Azure en niet in een hybride configuratie, omdat de latentie tussen een beheerserver en de SQL Server die als host fungeert voor de Operations Manager-databases een negatieve invloed heeft op de prestaties van de beheergroep.

Overweeg het bewakingsbereik, de netwerktopologie en de netwerkconnectiviteit met Microsoft Azure (dat wil zeggen site-naar-site VPN of ExpressRoute), integratiepunten (dat wil zeggen ITSM-oplossingen, andere System Center-producten, invoegtoepassingen van derden, enzovoort), consoletoegang, wettelijke of relevante wetten of beleidsregels, enzovoort, om dit scenario goed te ontwerpen binnen Azure IaaS of andere openbare cloudproviders.