***hubspost stuff below

Att testa backuper är nödvändigt men varför inte automatisera det jobbiga arbetet och dessutom spara pengar? 

Att företag tar backup på sina data är inte så konstigt. Däremot kan det tyckas underligt att återställning av backuperna inte testas fullt så ofta. När testade du din backup senast? Förvånansvärt ofta sker det att en skarp återställning inte lyckats p.g.a. något som hade upptäckts om testerna av återställningen skett med regelbundenhet. Detta gäller även för de företag som kör SAN-replikering för att replikera data som ett skydd. Replikering tillför redundans men inte någon höjd säkerhet mot andra incidenter än diskkrascher eftersom ett fel på primära siten då garanterat replikerats till den sekundära siten. Man MÅSTE testa replikerad data kontinuerligt för att inte t.ex. en trasig start sektor ska förstöra dagen när man ska starta upp en VM från DR siten. 

Programvarorna och IT-miljöerna uppdateras i dag så ofta att det är omöjligt att manuellt hinna göra dessa tester med en granularitet som täcker förändringsfrekvensen. En VM som är igång kan ha ett fel som gör att den kraschar vid en omstart men det märks inte förrän den måste startas om.

Lösningen är att automatisera testerna av katastrofåterställning så långt det är möjligt och då inte nöja sig med att verifiera att en VM startar och VMware-Tools svarar på anrop utan även testa på applikationsnivå. Ett exempel kan vara att webservern inte bara startar utan även svarar på anrop med en korrekt sida som svar.

En produkt som kan erbjuda den här funktionaliteten och mycket mer är PHD Virtual ReliableDR som är specifikt framtagen för att automatisera DR testerna på applikationsnivå, samt på ett tydligt sätt visa och kontinuerligt mäta hur väl man uppfyller kraven på Recovery Time Objective (RTO) och Recovery Point Objective (RPO). 

Översikt arkitektur

 

Bilden ovan visar en exempelarkitektur för RDR, där vi har en primär och en sekundär site. Den sekundära siten är tänkt att ta över driften från den primära siten i händelse av ett stillestånd. 

VMar replikeras från primär till sekundär site för att kunna starta och testa dessa på den sekundära siten. Replikeringen kan ske via mjukvarureplikering eller SAN-replikering.

ReliableDR installeras i en VM på DR siten där vi även skapar en ”Recovery Sandbox”. Denna Recovery Sandbox är en ”bubbla” med ett eget nätverk som normalt inte är kopplat till det fysiska nätverket. 


Definiera företagets IT-Tjänster samt RPO/RTO

Under tiden installationen pågår passar det bra att ta fram sin dokumentation över hur företagets olika IT-tjänster hänger i hop och samverkar. För ni har väl en?

Denna dokumentation bör nämligen utgöra grunden för hur man sätter upp sina RDR jobb. Den utgör grunden för hur man ska gruppera VM i sina jobb och hur ofta dessa jobb bör köra replikeringen för att följa RPO. RTO återkommer vi till lite senare.


Konfigurera jobb med applikationstester

Skapa ett jobb och samla de VM som igår i respektive tjänst. Sätt upp en schedulering för hur ofta det ska köras baserat på befintlig RPO. Fundera på vilka applikationstester som ska göras. Den första replikeringen tar sin tid eftersom alla data behöver flyttas men de efterföljande utnyttjar CBT och går betydligt snabbare.

När man kör ett jobb replikeras först data till DR sidan. Efter replikeringen startas VM upp i bubblan, i den ordning man önskar och de applikationstester man specificerat gås igenom i tur och ordning för alla ingående VM. Det här gör att inverkan på primära sidan är obetydlig.

För att inte behöva ha med t.ex. en Active Directory server i alla jobb finns en funktion som heter Continious Dependency som innebär att vi kan hålla en server startad inne i vår nätverksbubbla för andra jobb att utnyttja.

 

I ReliableDR ingår massor med färdiga testscript och man kan givetvis även lägga till sina egna.

 

Certified Recovery Point (CRP)

När alla tester för ett jobb har lyckats så rullas VMarna tillbaka till läget innan start och detta läge sparas som en CRP för de VMar som ingick i jobbet. Man kan givetvis spara flera sådana CRP per VM. Om någon test inte lyckas så blir man meddelad via e-mail eller SNMP att något gått fel. Sedan kan man i detalj undersöka exakt vad som gick fel under testen via en överskådlig logg. 

Hela idén med produkten är att man ska sätta upp den och kunna lämna den ifred tills man får ett larm om att något slutat fungera. 

När man senare behöver göra en återställning av någon eller alla de VMar som ingick i det här jobbet så kan man välja att återställa till en av dessa CRP punkter eller om man är modig till vad som råkar finnas på DR sitens SAN om man nu använder SAN-replikering. 

 

RTO är nu kollad för den här IT-tjänsten

Eftersom dessa tester av miljön körs schedulerat och vi mäter hur lång tid det tar kan man med stor säkerhet säga hur lång tid återställning tar av en viss tjänst. DVS vi har tagit fram en siffra på RTO för en viss tjänst och vi kan dessutom bevisa att den är rimlig.


Systemkrav

Läs mer om systemkraven på denna sida.
 

VMware Licens

Vad det är för version eller licenstyp på VMware hypervisorn på primär respektive sekundär site spelar ingen roll så länge det inte är gratisversionen där Storage API är avstängt. 

Ett tips är att ha den senaste versionen av Hypervisor på DR sidan eftersom det annars kan bli problem med maskinvaruversionen när du ska återställa en VM.

Man behöver givetvis administratörsrättigheter för installationen och tillgång till en Chrome eller Firefox av senaste version. (IE är ej supporterat)

ReliableDR använder enbart port 902 och 443 för sin kommunikation. 


Testa själv?

ReliableDR finns som utvärderingsversion och går att ladda ner här.

 

Frågor och support?

ARJ Distribution AB är nordisk distributör av PHD Virtuals produkter och tillhandahåller även support.

Kontakta oss om ni har några frågor.

 

 

Joomla25 Appliance - Powered by TurnKey Linux