HA/DR och Continuous Availability 2014-10-13 Henrik Grönberg Technical Director henrik.gronberg@load.se
Vad är en katastrof? All typ av störning som orsakar allvarligt avbrott i företagets verksamhet. 2
Skitväder
HA, DR och Continuous Availability High Availability Disaster Recovery Continuous Availability När 99,99% inte är gott nog
Effekter av en katastrof Hur står det till med DR planeringen? Enbart 50% av företagen har en riktig och genomtänkt DR plan Hälften av företagen som råkar ut för en katastrof förlorar marknadsandelar och konkurrenskraft 43% av företagen som förlorar data går i konkurs Kostnaden för stillestånd varierar mellan några hundratusen upp till många miljoner per timma
En Gartner studie visar 50% planerar för: Naturkatastrofer Terroristattacker Elavbrott Brand Virusattacker Mindre än 50% planerar för: Denial-of-service attacker Pandemier Fel hos Service Providers Utslagning av datahall under lång tid (>1 vecka). Mer än 50% har inte testat sina planer under senaste året. Nästan ingen har någonsin gjort en versamhetsövergripande test.
Bristande kommunikation Verksamheten: IT är en kostnad Förstår inte riskerna Förstår inte DR Tror att skyddet är bra Så liten risk Inget businesscase IT: Vi får inget gehör De förstår inte Jag har tröttnat Vem ska göra det? Dålig på att förklara Visar inget businesscase När en katastrof väl sker är ledningen ofta förvånad att det kunde ske och att påverkan blev så stor
Vad kostar det? Vinst per år Antal timmar = Kostnad/h Sjunkande aktiekurs Förlorade kunder Dåligt rykte (sociala medier ) Skadestånd Förlorade tillstånd DR/CA är ingen IT uppgift det är en genomgripande process som berör hela verksamheten och skall drivas av ledningen.
Hur börjar jag? Bygg businesscase visa risker/kostnad, få ledningen att förstå Vilka risker finns? Vad är troligt? Risk vs kostnad Investera i projekt för att eliminera eller minimera riskerna Investera i att minska effekterna av katastrof
Risk Assessment Typ av risk Sannolikhet (S) Påverkan (P) Brand i datahall 3 4 12 Regional jordbävning 1 5 5 Hårdvarufel i server 4 3 12 Admininstratör raderar data 4 5 20 Administratör raderar data 4 3 12 Bussolycka när IT avdelningen åker på kickoff 3 5 15 Värde S*P Motåtgärd Sannolikhet (S1) efter motåtgärd Dubblering av datahall med spegling av server+lagring Flytt av backupkopior (tape) till site 300km bort. Avtal med leverantör om hårdvara för DR Påverkan (P1) efter motåtgärd Värde S1*P1 efter motåtgärd 1 2 2 1 4 4 Kluster för applikationen 4 1 4 Backup var 24:e timma Risk för förlust av 23h data 4 3 12 Flashcopy av data varannan timma 4 2 6 Personalen fördelas över två bussar och åker annan rutt 2 4 8 Summa 68 36
Scope Vilka risker ska vi skydda oss mot? Få andra insynsvinklar (ej IT) Tänk stort/brett (inte bara IT)! Vi pratar Continuous Availability inte enbart DR Vad är det absolut viktigaste att skydda? Vilka teknologier finns/behövs? Rangordna system kritiskt, viktigt, mindre viktigt Lägg krutet på kritiskt till att börja med Kom ihåg att analysera beroenden!
Verksamhetens viktigaste tillgång - data Större del av affärsverksamheten online Fler applikationer & mer data Ökande kostnad när data är otillgängligt Ett ökande glapp Möjlighet att leverera med befintlig teknik Mer komplexa system Kortare tid för recovery Kräver ett nytt tänk kring backup
Kostnad / Värde Positionering av Recovery teknologi efter behov Recovery från disk image Recovery från tape (Fysisk el. Virtuell) BC Tier 7 Kluster (applikation/os) med automatiserad failover (ej nödvändigtvis automatisk failover) BC Tier 6 Realtidsreplikering av data, standby server/lagring BC Tier 5 Applikation/Databas replikering med log rollback BC Tier 4 Snapshot för Backup/Restore BC Tier 3 Virtuell tape med spegling BC Tier 2 - Hot Site, Restore från Tape (fysisk el. Virtuell) Min. 1-4 Hr.. 4-8 Hr.. 8-12 Hr.. 12-16 Hr.. 24 Hr.. Days BC Tier 1 Restore från Tape (fys. el. Virtuell) Recovery Time Objective (RTO) Målet: Balansera recovery tid och kostnad Virtualisering Cloud
Processer Hårdvarufel Påverkas verksamheten? Nej Laga felet Ja Ta fram beslutstöd Definiera vad som är katastrof När och för vad deklareras katastrof? Vem tar beslutet? Vilka skall meddelas? - Kunder, partners, ledning, myndigheter Vem/vilka behövs? Mer än 2h att fixa? Ja Failover Nej Laga felet Olika processer beroende på typ av katastrof!
Organisationen, eller ja människorna Hur ser din DR organisation ut? Identifiera nyckelpersoner Vem gör vad? Och när? Koordinering? Ansvarsområden? Dokumenterad plan och körschema Om nyckelpersoner saknas? Semester/sjukdom/omkommen Kräver återstart att man fysiskt kan ta sig till DR site? Kan personalen ta sig till DR site? Om inte? Kan personal (inte bara IT) arbeta hemifrån? Remote access? Öva, Öva och Öva. Människor gör fel! Oftare under stress Räkna med att det tar längre tid än vad man tror. Räkna med att saker inte kommer fungera som planerat. Förvänta dig det oväntade! Kan saker förberedas vid en stundande katastrof? Kan leverantörer hjälpa till?
Continuous Availability är iterativt Strategi och Vision Organisation Processer Applikationer och data Teknologi Datahallar/faciliteter DR/CA strategi Detta är en iterativ process! Strategin måste ändras vid: Utbyte/ändring av system/infrastruktur Nya applikationer Vid personalförändringar Efter en katastrof Nya hot? Företagsledning byts = andra prioriteringar Stor tillväxt ökad omsättning = större påverkan vid stillestånd = OK med/krav på bättre DR Ny billigare teknologi tillgänglig Företaget får tillgång till ny lokation Ändrad inriktning på verksamhet Branschförändring gör IT viktigare Ändringar i övergripande IT strategi
Ett fall från verkligheten Orkanen Katrina Iväg och tillbaka igen
Oreck Corporation Grundat 1963 av David Oreck Tillverkar dammsugare för industri och hushåll 1.500 anställda Kör IBM System i för sina affärssystem samt Intel/vmware/win för allt annat Huvudkontor i New Orleans Tillverkning & Distribution i Long Beach
Lokal kontra regional katastrof New Orleans Long Beach
Tidslinje Fredag 26/8 Förberedelser påbörjas Backuper Nedstängning av Long Beach Lördag 27/8 AS/400 stängs ner Katastrof deklarerad hos IBM Tape:ar flygs ut från området Söndag 28/8 Evakuering Måndag 29/8 Katrina comes to town Tisdag 30/8 Utvärdering och beslut New Orleans ok, men ingen kommunikation/el Long Beach lättare skador men området totalförstört Torsdag 1/9 - Beslut att flytta till IBM BCRS i Dallas Fredag 2/9 IT till viss del operativt i Dallas Måndag 5/9 Alla HK/IT funktioner igång i Dallas Måndag 12/9 Tillverkning återstartas i Long Beach LONG BEACH, Miss., Jan. 12 Ten days after Hurricane Katrina tore through town, the Oreck Corporation reopened the storm-damaged plant where it assembled its widely advertised vacuum cleaners. It hauled in generators to make electricity, imported trailers to house its workers and was hailed as a local hero for putting people back to work so fast. But now, 16 months later, Oreck which had employed almost 500 people at the factory is throwing in the towel and moving its manufacturing to Tennessee. The company says it cannot get enough insurance to cover its plant here, and cannot hire enough skilled workers to replace those who never returned after the storm, mostly because they had nowhere to live. Fredag 7/10 Verksamheten stängs ner i Dallas Måndag 10/10 HK/IT operativt i New Orleans
Oreck CIO om Lessons learned Business Continuity är INTE en IT funktion Business Continuity är ett tankesätt, inte en övning en gång om året Människorna är det viktigaste Var ska de arbeta? Hur ska de ta sig dit? Vilka kommer vi behöva och när? Hur gör vi med familjerna? Hur gör vi med mat, sängar, toaletter, duschar? Business Continuity planering måste involvera dina affärspartners Ta fram en plan för att stänga ner din verksamhet under en LÅNG TID Lita inte på kontraktskrivning testa, testa och testa igen
Vad IBM lärt sig från Katrina och WTC katastroferna Lyckad recovery kräver hög grad av automatisering Nyckelpersoner med kritisk kunskap kanske inte är tillgängliga När människor utför DR procedurer görs det ofta misstag En regional katastrof kommer ge än mer utmaningar för DR planen. Grundläggande infrastruktur kan vara otillgänglig eller förstörd Kommunikation är begränsad eller helt utslagen Personal kan inte ta sig till DR site El, transporter, byggnader kan vara på verkade En katastrof kan orsaka att många företag vill ha hjälp samtidigt av lokala/regionala räddningsresurser (brandkår/pumpföretag/transport/service Providers) Dessa företag jobbar ofta efter principen först i kön först hjälp basis En regional katastrof kan snabbt fylla upp Service Providers faciliteter Service Providers har ofta kontrakt som anger att kunden måste flytta ut inom en viss tidsperiod, exv. 30 dagar.
Vad IBM lärt sig från Katrina och WTC katastroferna DR planer behöver inkludera hela verksamheten Regelbundna Enterprise-level katastrofövningar är ett krav. IT recovery planen måste länka till hela verksamhetens DR plan. En tydlig befälskedja för att utföra DR planen måste vara publicerad och hela organisationen införstådd med den. IT s DR plan måste adressera verksamhetens krav IT s bedömda tid för återställning av kritiska applikationer måste matcha verksamhetens krav. DR planen måste inkludera en prioriteringslista för återställning av verksamhetsprocesser och associerade IT applikationer/system. DR planen måste vara användbar DR planen måste vara up-to-date och länkad till Change Management procedurer. Planen måste vara åtkomstbar även om el, kommunikation och access till byggnaden saknas. Planen måste kunna utföras av andra än specifika nyckelpersoner = Mycket väldokumenterad!
24