Granskning av tillgänglighet och återhämtningsalternativen för att skydda VMM databas
Gäller för: System Center 2012 SP1 - Virtual Machine Manager, System Center 2012 R2 Virtual Machine Manager, System Center 2012 - Virtual Machine Manager
När du väljer bland alternativen för att skydda VMM-databasen, oavsett om det är i samband med tillgänglighet eller i samband med katastrofåterställning, är en bra idé att granska vad som kan inträffa om VMM-databasen måste ställas "bakåt i tiden" på grund av en felsituation.Det här kan vara nödvändigt med vissa säkerhetskopierings- och återställningsalternativ samt vissa tillgänglighetsalternativ.Användning av SQL Server-tillgänglighetsgrupper i tillgänglighetsläget för asynkront genomförande kan till exempel kräva att du utför en redundansväxling som placerar databasen "bakåt i tiden".
Redundansväxling eller återställningssituationer för databasen som kan kräva återställning "bakåt i tiden"
Som i alla databaser kan, om ett maskinvarufel eller andra problem inträffar, de senaste ändringarna i VMM-databasen gå förlorade.Beroende på vilka tillgänglighets- och återställningsalternativ som finns kan VMM-databasen behöva redundansväxlas vid fel eller återställas från säkerhetskopia om den enda versionen av VMM-databasen som finns kvar är något inaktuell.Kallas ibland att gå "bakåt i tiden" för en databas.
Databasadministratörer undersöker tillgänglighets- och återställningsalternativ med tanke på hur databasen kan återställas, vilket innebär hur nära en exakt tidpunkt den kan tas tillbaka om ett fel inträffar.Det här avsnittet försöker inte beskriva alla för- och nackdelar med olika alternativ för tillgänglighet eller återställning, men två situationer är värda att nämna för VMM-databasen:
Om SQL Server AlwaysOn-tillgänglighetsgrupper används i tillgänglighetsläget för asynkront genomförande kan en framtvingad växling vid fel vara nödvändig.Tillgänglighetsläget för asynkront genomförande innebär att en sekundär replik av databasen kan ligga efter den primära repliken vid någon tidpunkt.Om det vid tidpunkten för en framtvingad redundansväxling är nödvändigt att växla till en sekundär replik som ligger efter, tas VMM-databasen bakåt i tiden.Tillgänglighetsläget för asynkront genomförande beskrivs i detalj i följande avsnitt:
Översikt över AlwaysOn-tillgänglighetsgrupper (SQL Server), i synnerhet sektionen Tillgänglighetslägen i avsnittet
Tillgänglighetslägen (AlwaysOn-tillgänglighetsgrupper), i synnerhet sektionen Tillgänglighetsläge för asynkront genomförande i avsnittet
Vid katastrofåterställning kan det vara nödvändigt att återställa från en säkerhetskopia som togs något före tidpunkten för felet.Naturligtvis beror detta på intervallet mellan säkerhetskopieringar av VMM-databasen (inklusive externa säkerhetskopieringar).Om det är nödvändigt att återställa från en säkerhetskopia som togs före tidpunkten för felet kommer VMM-databasen att tas bakåt i tiden.
Information som kan påverkas om VMM-databasen måste tas bakåt i tiden
Det kan vara praktiskt att granska eventuella effekter som kan uppstå om VMM-databasen måste tas bakåt i tiden.Några exempel:
Behörigheter som ändrades strax innan ett fel inträffade kan återställas efter att VMM-databasen har redundansväxlats eller återställts.
Åtkomst som togs bort strax innan ett fel inträffade kan vara tillgänglig igen efter att VMM-databasen har redundansväxlats eller återställts.
Åtkomst till innehållet i en virtuell hårddisk kan exempelvis vara tillgänglig för användare som annars inte skulle ha åtkomst.
VM-nätverk som togs bort strax innan ett fel inträffade kan vara tillgängliga igen efter att VMM-databasen har redundansväxlats eller återställts.
När du väljer mellan tillgänglighets- och återställningsalternativ för att skydda VMM-databasen, kan det vara praktiskt att granska listan ovan med tanke på just din miljö och dina krav.