Sådan slipper du godt fra tyveri, strømsvigt og hardwarefejl i datacenteret
Strømafbrydelser, overgravede kabler, ram-fejl og tyveri i datacenteret.
Listen over banale fejl og fadæser, der kan få oppetiden hos hostingleverandøren til at bevæge sig ned under 100 procent, er lang. Og den er også velkendt for de fleste, der får hostet serverkapacitet og tjenester ude i byen.
Men det er faktisk ikke umuligt at få højere oppetid end det, nogen hostingleverandør i praksis kan levere, hvis man tager sig sine forholdsregler.
Det fortalte to driftsansvarlige hos konsulentvirksomheden Ange Optimization, Hans Schou og Ole Tange, under konferencen Open Source Days 2010.
De har gennemgået en række af de scenarier, der typisk resulterer i nedetid for hostingleverandørernes kunder.
»Der er masser af eksempler på, at man som kunde hos en hostingleverandør ikke får 100 procent oppetid,« siger Ole Tange.
Det omfatter blandt andet flere hændelser, som Version2 tidligere har berettet om.
To hostingcentre, to lande, to elnet Et eksempel var indbruddet i hostingleverandøren Nianets datacenter i Taastrup sidste år. Her brød to personer ind i bygningen og forlod få minutter efter stedet med hardware til en samlet indkøbspris på omkring en halv million kroner.
Det efterfølgende nedbrud resulterede i, at JP/Politikens Hus var faretruende tæt på at miste en avis, hvilket ikke er sket siden 2000.
For nylig oplevede en anden hostingleverandør, Netgroup, at et centralt køleanlæg i ét af virksomhedens datacentre fejlede, hvilket i en periode på en time til halvanden sendte temperaturen op på den anden side af 40 grader Celcius.
Servere hos én af kunderne, Aller, begyndte at lukke ned på grund af varmen, hvilket gav en nedetid på 10-15 minutter på hardwarehjemmesiden edbpriser.dk.
Og det er blot to eksempler i en lang række, der har fået Hans Schou og Ole Tange til at udarbejde deres egen regel, To-to-to-test, som kan bruges som en vejledning til at opnå højere oppetid.
Reglen går kort fortalt ud på at sikre sig, at man får hostet sine løsninger i to hostingcentre i to forskellige lande på to forskellige elnet. Og derudover sørge for løbende at teste det beredskab, der bare skal sidde på rygraden, når uheldet er ude.
»Det er blevet så billigt at kunne holde sig til den regel, at der ikke længere er nogen økonomisk grund til ikke at gøre det. Mange er ikke opmærksomme på det endnu, men tror, at en leverandør kan holde alt, hvad han lover,« siger Ole Tange.
De to forskellige hostingcentre skal ifølge Hans Schou og Ole Tange være adskilt både geografisk og juridisk. Derved kan de tilfælde undgås, hvor eksempelvis en brand i ét datacenter breder sig til et andet, fordi de fysisk ligger placeret lige opad hinanden. Ved at holde centrene juridisk adskilt sikrer man sig, at politiet ikke automatisk kan beslaglægge servere i begge hostingcentre.
»Den forholdsregel er ikke til for at modarbejde politiet, men derimod for at arbejde med kunden,« siger Ole Tange, hvor kunden i det konkrete tilfælde for eksempel er brugerne af edbpriser.dk.
Den juridiske adskillelse sker mest oplagt ved at placere udstyret hos hostingcentre i to forskellige lande. Derved kunne for eksempel danske Myupload.dk, der to gange sidste år fik konfiskeret sin server i Holland af politiet på grund af kontroversielt indhold på serveren, have holdt sig kørende alligevel. Myupload.dk fik serveren tilbage efter få dage i politiets varetægt.
Test beredskabet jævnligt Ved samtidig at holde de to hostingcentre adskilt af to forskellige elnet sikrer man sig mod de tilfælde, hvor store strømafbrydelser mørklægger hele landsdele. For eksempel blev strømmen på Sjælland, der er forbundet til elnettet i Sverige, afbrudt i tre timer i 2003 på grund af en fejl på Oskarshamn atomkraftværk i Sverige.
Hans Schou og Ole Tange opfordrer samtidig til, at man undersøger antallet af servicemeddelelser, inden man vælger en hostingleverandør.
»Det er uundgåeligt, at der sker fejl, og når de opstår, skal man kunne regne med, at leverandøren informerer kunden så hurtigt som muligt. Hvis man ikke kan se, at leverandøren tidligere har udsendt servicemeddelelser til kunderne, skal man regne med, at man får brug for sit beredskab oftere,« siger Ole Tange.
Begge driftsansvarlige opfordrer til, at man jævnligt tester sit beredskab for at være klar, når uheldet er ude.
Præsentationen fra Hans Schou og Ole Tange (.odp-format, åbnes med Openoffice)
Kommentarer (22)
Hvis man har sin applikation kørende to steder, så er der jo et lille problem med at holde data synkrone, hvis det er transaktionsdata. (banktransaktioner f.eks)
Ligeledes skal man jo bestemme sig for om et center skal understøtte fuld funktionalitet og kapacitet, for i så fald vil ens hostingpris fordobles, noget de fleste kan mærke.
Nu er jeg bestemt ikke modstander af tocenterdrift, men at tro at det er enkelt er nok lidt farligt.
-
0 -
0
Så mangler vi bare en funktion i HTTP protokollen, så browseren selv kan finde ud af at bruge den alternative IP adresse når den primære ikke svarer.
SMTP har det. Men det bedste du kan få med HTTP er round robin, og så er du jo kun 50% nede når det ene center fejler. Det er ikke godt nok.
Dertil kommer problemer med synkronisation af data.
Det er ikke prisen som afholder os fra at vælge en sådan løsning!
-
0
-
0
SMTP har det. Men det bedste du kan få med HTTP er round robin
Følg med i næste uge, hvor vi implementerer HTTP over SMTP. Tænk over det - en browser i dit mailprogram! Det har selv Microsoft ikke fundet på endnu (emacs har det selvfølgelig).
-
0
-
0
Der findes allerede løsninger på dette, eksempelvis baseret på DNS, hvor der simpelt hen returneres en A-record, som peger på det datacenter, hvor trafikken skal sendes hen.
-
0
-
0
Er det ikke ca. det DNS gør, hvor du har flere A records?
Se f.eks. [1], hvor google.com har 6 A records?
[1] http://network-tools.com/default.asp?prog=dnsrec&host=google.com
[edit] You were faster Jens Fallesen ;)
-
0
-
0
er en god måde at teste sin restore på når man ender i en splitbrain med brugere der taster transaktioner ind i hver sin database som mener den bestemmer.
-
0
-
0
Er det ikke ca. det DNS gør, hvor du har flere A records?
Som jeg har forstået det, returnerer DNS bare den enkelte A record i round robin, uden hensyntagen til, om den enkelte IP-adresse rent faktisk svarer [1]. Det er der ikke meget failover ved.
-
0
-
0
Joe men først skal man jo vælge hvilken af baserne man vil restore, her f.eks terningkast godt.
-
0
-
0
Kommunedata har i mange år kørt med paralelle terrorsikre data centraler, med duplikering af strøm, net, vand, whatever og med lidt OLTP eller lignende og lidt fornuftig internetsetup er den vel hjemme. Der burde ikke være noget nyt i det her.
-
0
-
0
Jens, det er fint, men fail over skal gerne ske automatisk.
Det er netop sådan, disse løsninger fungerer. I stedet for en traditionel DNS-server har man en enhed, som holder øje med serverne og svarer tilbage med en passende A-record. Der er naturligvis en sådan enhed placeret i hvert datacenter.
Hvis begge sites er i drift, og der ikke er grund til at foretrække det ene site frem for det andet, kan man give forskellige klienter hver sin A-record for at fordele trafikken, hvilket eventuelt kan være baseret på målt round trip time til DNS-klienten fra hvert datacenter.
-
0
-
0
Det er jo interessant nok. Hvilket software kan lave dette trick?
Der er grænser for hvor lave timeouts man kan køre med DNS og stadig regne med at diverse DNS caches respekterer det. Hvor hurtig failover tid får man i praksis?
-
0
-
0
Tilføjelsen af flere enheder (redundans) giver også problemstillinger. Fx kan logikken der styrer redundansen gå ned, og så kan tilgangen til data faktisk blive endnu mere kompleks en ellers.
En rigtig god backup, OG en god plan for hvordan den skal komme hurtigt i drift er et billigt og effektivt værn mod større mængder nedetid. Men der kan selvfølgeligt være brug for multi site services alligevel.
/Eske
-
0
-
0
Nej der er principielt intet nyt i at køre to datacentre, men det er absolut ikke en discount infrastruktur (og forøvrigt virker de fleste Enterprise Disaster Procedure ikke i praksis).
At køre to helt separate datacentre giver for mig kun mening for en SMA hvis transaktionerne er primært read-only.
Hvem får forøvrigt 100% oppetid i den virkelige verden? Alle de systemer som jeg kender falder på røven engang imellem pga applikationsfejl, infrastrukturfejl eller operatørfejl.
-
0
-
0
Hej Baldur, jeg kender ikke lige noget software der kan (men det findes jo sikkert). Et godt alternativ er en F5 Global Traffic Manager, som har en hel del flødeskum ovenpå - fungerer forøvrigt fint sammen med VMware SRM.
-
0
-
0
(og forøvrigt virker de fleste Enterprise Disaster Procedure ikke i praksis).
Det er jeg nok ikke helt enig i, tænker du på noget specielt?
I øvrigt er det altid bedre at have et beredskab end intet beredskab.
Beredskabet består af:
- Organisation
- Infrastruktur
- Planer
- Test
-
0
-
0
@Morten: Helt enig i at enhver plan er bedre end slet inten plan, men specielt testfasen er et svagt punkt i mange steder. Personligt mener jeg ikke at en årlig DR øvelse med 3 måneders forberedelse har den store værdi (udover at markere testen som gennemført for revisionen).
Min forventning til et totalt udfald af et større datacenter vil være 1-2 ugers partiel nedetid og inkonsistente applikationer. En af de applikationer som jeg tidligere har arbejdet med havde en DR plan på 200 punkter som skulle udføres af 5 forskellige teams i 2 tidszoner.
Ikke dermed sagt at der ikke findes installationer hvor der er styr på DR. En af mine kunder svinger deres applikationer mellem deres datacentre hver anden weekend. Operationen tager et par timer og der er ingen nedetid.
-
0
-
0
Og det er vigtigt at teste rigtigt.
Ikke dermed sagt at der ikke findes installationer hvor der er styr på DR. En af mine kunder svinger deres applikationer mellem deres datacentre hver anden weekend. Operationen tager et par timer og der er ingen nedetid.
Problemet er bare at det "kun" viser at de kan køre i eet center. Det beviser ikke at de kan svinge ved en uforudset hændelse.
Nu kunne jeg godt bruge mange linier på at skrive om continuity test - noget der ligger mit hjerte ret nært, men man skal altid huske at en continuity tests design er en afvejning mellem realismen af testen og cost (udgifter, nedetid, risiko for nedetid, datatab etc)
Den ultimative continuity test forudsætter et parallelt univers!
Men det uagtet bør man løbende vurdere og forbedre sine continuity tests.
-
0
-
0
De behøver ikke at teste uforudsete hændelser - det sørger den virkelige verden for :-) Når man har rutine i proceduren og forventning til at den virker er det naturligvis en banal operation at reetablere driften i det andet center. Den eneste forskel er at det koster utilgængelighed for kunderne.
-
0
-
0
Desværre ikke, erfaringen viser at der er pokker til forskel på en planlagt flytning af systemerne og så den måde det opfører sig på hvis halvdelen af konfigurationen pludselig forsvinder.
Så hvis man vil have en rimelig ide om hvordan det vil gå, så skal man nok overveje at trække stikket in imellem.
-
0
-
0
brodtgaard:~/t$ host google.com
google.com has address 74.125.77.104
google.com has address 74.125.77.99
google.com has address 74.125.77.147
google.com mail is handled by 200 google.com.s9a2.psmtp.com.
google.com mail is handled by 400 google.com.s9b2.psmtp.com.
google.com mail is handled by 100 google.com.s9a1.psmtp.com.
google.com mail is handled by 300 google.com.s9b1.psmtp.com.
brodtgaard:~/t$ host google.com
google.com has address 74.125.77.147
google.com has address 74.125.77.99
google.com has address 74.125.77.104
google.com mail is handled by 300 google.com.s9b1.psmtp.com.
google.com mail is handled by 200 google.com.s9a2.psmtp.com.
google.com mail is handled by 400 google.com.s9b2.psmtp.com.
google.com mail is handled by 100 google.com.s9a1.psmtp.com.
brodtgaard:~/t$ host google.com
google.com has address 74.125.77.104
google.com has address 74.125.77.147
google.com has address 74.125.77.99
google.com mail is handled by 100 google.com.s9a1.psmtp.com.
google.com mail is handled by 300 google.com.s9b1.psmtp.com.
google.com mail is handled by 200 google.com.s9a2.psmtp.com.
google.com mail is handled by 400 google.com.s9b2.psmtp.com.
brodtgaard:~/t$ host google.com
google.com has address 74.125.77.99
google.com has address 74.125.77.104
google.com has address 74.125.77.147
google.com mail is handled by 400 google.com.s9b2.psmtp.com.
google.com mail is handled by 100 google.com.s9a1.psmtp.com.
google.com mail is handled by 300 google.com.s9b1.psmtp.com.
google.com mail is handled by 200 google.com.s9a2.psmtp.com.
Så en klient kunne godt udnytte at den har flere muligheder.
-
0
-
0
Så en klient kunne godt udnytte at den har flere muligheder.
Men det gør klienterne ikke. Din web-browser vælger en tilfældig af disse adresser, og hvis lige netop den server er nede, så får du en fejl. Browseren prøver ikke igen med en af de andre adresser.
Mail-serverne er derimod lavet anderledes. De går videre til den næste på listen, hvis den første server er nede.
Det er derfor det er en mangel i HTTP protokollen, at de ikke har skrevet ind, at klienterne skal prøve næste IP adresse på listen.
-
0
-
0
