Herleid uw downtime tot het minimum met een multidatacenter concept
Leg uw bedrijfskritische activiteiten in goede handen 2 Als het voor uw omzet cruciaal is dat uw servers continu beschikbaar zijn, dan vraagt u aan uw hostingprovider een high availability oplossing. U baat bijvoorbeeld een webwinkel uit en verliest elke minuut dat uw webserver niet functioneert omzet en klanten, of u biedt een online handelsplatform aan waarbij elke seconde telt. Dan kiest u maar beter voor een multidatacenter concept: twee datacenters die als één logisch netwerk functioneren en zo uw beschikbaarheid optimaliseren: Door die verspreiding over twee locaties garandeert u de beschikbaarheid van uw internetdienst. Als er zich een panne voordoet in het ene datacenter, blijven uw servers nog altijd in het tweede datacenter draaien. In deze whitepaper bespreken we de technologie die dat mogelijk maakt en leggen we uit waarop u moet letten bij het kiezen van een multidatacenter oplossing.
Een traditioneel multidatacenter concept gebaseerd op DNS Traditioneel werkt een multidatacenter concept op basis van DNS (Domain Name System), het netwerkprotocol dat gebruikt wordt om namen van computers (domeinnamen) naar IP-adressen om te zetten. Men laat de domeinnaam www.example.com dan bijvoorbeeld naar IP-adres 1 van een webserver in het eerste datacenter verwijzen. Als dat datacenter met een panne te maken krijgt, laat men dezelfde domeinnaam naar IP-adres 2 van een identieke webserver in het tweede datacenter verwijzen. Vanaf dat moment worden alle aanvragen van clients voor de webserver naar het tweede datacenter omgeleid. Omdat DNS-gegevens doorgaans niet zo frequent veranderen, gebruikt DNS echter caching: een computer die het IP-adres achter een domeinnaam opvraagt, krijgt daarbij ook een TTL-waarde (time to live) die aangeeft hoe lang dat adres minstens geldig is. Die waarde ligt tussen enkele minuten en enkele dagen. Als de computer dan binnen die tijd nog eens het adres nodig heeft dat bij die domeinnaam hoort, haalt hij dat adres uit een lokale cache. Op die manier wordt vermeden dat de DNS-servers constant overbelast worden met overbodige aanvragen. Als u www.example.com wilt laten verwijzen naar de webserver in het tweede datacenter op het moment dat het eerste datacenter niet meer bereikbaar is, stelt u op voorhand de TTL van www. example.com in op bijvoorbeeld vijf minuten. Bezoekers van uw website vragen dan elke vijf minuten opnieuw het IP-adres van uw webserver op. Op het moment dat het eerste datacenter niet meer bereikbaar is, laat u uw domeinnaam verwijzen naar het IP-adres 2 van uw identieke webserver in het tweede datacenter. Na vijf minuten heeft in theorie elke DNS-server in de hele wereld dit nieuwe IP-adres toegekend aan de domeinnaam www.example. com, waardoor bezoekers op de tweede webserver terechtkomen. 3
DNS biedt niet voldoende garanties 4 Een multidatacenter concept met gebruik van DNS werkt in veel gevallen, maar heeft enkele belangrijke nadelen: De aanpak werkt niet betrouwbaar In theorie is uw webserver na vijf minuten terug bereikbaar via het tweede datacenter, maar in de praktijk houden sommige internetproviders geen rekening met een TTL die korter dan enkele uren is. Daardoor zullen sommige bezoekers uw website wel al na vijf minuten opnieuw kunnen bereiken via het tweede datacenter en andere nog niet. Dit is dus geen betrouwbare multidatacenteroplossing. U belast de DNSinfrastructuur Een downtime van vijf minuten is te lang Een lagere TTL dan vijf minuten is om allerlei redenen niet haalbaar. Bij een multidatacenter concept met DNS moet u in het beste geval dus rekenen op een downtime van vijf minuten, wat voor heel wat toepassingen nog te lang is. Hoewel een op DNS gebaseerde multidatacenter concept nog door veel hostingproviders gebruikt wordt, is Unitt daarvan in 2009 afgestapt. In de plaats daarvan hebben we gekozen voor een technologie die sneller schakelen tussen twee datacenters mogelijk maakt. Met zo n korte TTL maakt u eigenlijk misbruik van het DNSprotocol, want het is niet ontworpen voor dit soort situaties. Met een TTL van 5 minuten gebeuren er dagelijks heel wat overbodige aanvragen bij de DNS-servers, wat ook de reden is waarom enkele internetproviders dit niet graag zien: u belast er immers de DNSinfrastructuur mee.
Een multidatacenter gebaseerd op BGP: bijna 100% bereikbaarheid BGP (Border Gateway Protocol) is het protocol dat gebruikt wordt om netwerkverkeer tussen verschillende providers te kunnen routeren: BGP-routers vertellen elkaar welke IP-adres bereiken via hun bereikbaar zijn. Op die manier kan dan voor elke bezoeker van uw website automatisch op elk moment het snelst beschikbare pad naar het datacenter bepaald worden. Het BGP-protocol is - in combinatie met een load balancer - een logischere manier om tussen twee datacenters te schakelen dan DNS. In elk datacenter draait u dan een identieke webserver achter een load balancer. Als bezoekers uw website via het IP-adres van uw webserver willen bereiken, geven ze het publieke IP-adres van de load balancer in. Die controleert continu welke van de twee redundant uitgevoerde webservers bereikbaar is en stuurt de netwerkpakketjes naar de bereikbare server of servers door. Door het correct inzetten van de load balancer en de BGP-router zal er altijd een pad zijn om de server te bereiken. Als één datacenter uitvalt, merkt de router op dat de loadbalancer via het ene pad niet meer bereikbaar is en neemt de andere route. Tegelijk houdt de load balancer op met netwerkverkeer te sturen naar de webserver die niet meer responsief is naar de onderliggende webserver. Is de panne voorbij, dan stuurt de load balancer opnieuw netwerkverkeer naar de webserver. Dit alles gebeurt volledig transparant voor de bezoekers, die niets merken van het uitgevallen datacenter. Het lijkt voor hen alsof de webserver de hele tijd gewoon werkt. Uw website blijft daardoor bijna 100% bereikbaar voor de buitenwereld: downtime kan zo goed als uitgeschakeld worden. 5
Welke uptimegaranties zijn technologisch mogelijk? 6 Dankzij de op BGP gebaseerde multidatacentertechnologie kunt u de hoogste beschikbaarheid bereiken voor uw servers. Welke garanties precies mogelijk zijn, hangt echter sterk af van wat er in de datacenters gebeurt en hoe ver de datacenters uit elkaar liggen. Het voordeel van Unitt is dat u voor een relatief lage meerkost uw serverinfrastructuur voor één datacenter kunt laten ombouwen naar onze multidatacenterinfrastructuur. Wij nemen het beheer ervan uit handen, zodat u zich kunt focussen op uw applicaties zonder zich om de uptime van de infrastructuur te moeten bekommeren. Welke redundantie biedt het datacenter? Een datacenter kan verschillende gradaties in uptime aanbieden, afhankelijk van de gradatie van aanwezige redundantie. Gebruikt u slechts één datacenter zonder speciale maatregelen, dan zal bij een panne uw server uitvallen of onbereikbaar zijn. Met een slimme binnenarchitectuur (multiroom) kan dat echter vermeden worden. Zo kan het datacenter opgebouwd worden uit twee volledig onafhankelijk functionerende zalen. Als er dan in één zaal bijvoorbeeld brand uitbreekt, blijft de andere zaal nog werken en kan voor uw server overgeschakeld worden naar een server in de tweede zaal. Voor een grootschaliger ramp die het volledige datacenter treft, is echter een tweede datacenter op een andere locatie nodig (een multidatacenter). Uiteraard kan elk datacenter in een multidatacenter concept ook een multi-roomuitvoering hebben. Mirrort u de gegevens synchroon of asynchroon? Bij een ramp in een datacenter is het niet alleen belangrijk dat uw servers bereikbaar blijven, maar ook dat u zo weinig mogelijk gegevens verliest. Daarom synchroniseert u in veel toepassingen maar beter de storage in elk datacenter met elkaar (mirroring). Elke keer uw webserver in één datacenter gegevens wegschrijft naar de storage, moeten diezelfde gegevens ook in het andere datacenter weggeschreven worden. Dat kan synchroon of asynchroon gebeuren. Bij synchrone mirroring worden de gegevens gelijktijdig binnen het eerste datacenter weggeschreven en naar het tweede datacenter gestuurd. De toepassing wacht tot de gegevens in beide datacenters zijn weggeschreven. De netwerkverbinding naar het tweede datacenter introduceert extra vertraging in de toepassing, maar gegevensverlies is uitgesloten. Bij asynchrone mirroring worden de gegevens ook naar het tweede datacenter gestuurd, maar wacht de toepassing hier niet op. De toepassing werkt dus sneller, maar er is kans op gegevensverlies bij een ramp in het eerste datacenter. De keuze tussen beide technologieën is sterk afhankelijk van de type applicatie die men wilt gaan spreiden over 2 datacenters (hoe gevoelig is de impact van de vertraging die optreedt bij synchrone replicatie) en de business requirements: hoeveel data kan men zich permitteren te verliezen en hoe snel moet het 2de datacenter beschikbaar zijn bij een panne.
7 Hoeveel downtime kunt u aan? Met een op BGP gebaseerd multidatacenter kunt u bijna 100% beschikbaarheid voor uw servers verkrijgen: bij een ramp in het ene datacenter draaien uw servers dan in enkele seconden in het andere datacenter. Wat technologisch mogelijk is, is daarom echter nog niet altijd economisch haalbaar. Begin daarom altijd met een businessimpactanalyse uit te voeren, waarin u een risicoanalyse maakt van wat er mis kan lopen en wat de gevolgen voor uw organisatie zijn. Daarna kunt u de volgende parameters bepalen waaraan de oplossing van uw hostingprovider moet voldoen: Hoe lang mag een onderbreking van uw toepassing duren? Het antwoord op deze vraag wordt uitgedrukt in de RTO (recovery time objective), waarmee u aanduidt na hoeveel tijd de toepassing terug operationeel moet zijn om uw businesscontinuïteit niet in gevaar te brengen. Let op: zorg dat uw hostingprovider en u hetzelfde verstaan onder de RTO. Stel dat een hostingprovider met een DNS-gebaseerd multidatacenter bijvoorbeeld de RTO definieert als de tijd dat het duurt om een vervangserver in het tweede datacenter op te starten. Als die server niet in diezelfde tijd bereikbaar is door de onbetrouwbaarheid van DNS, is die in uw ogen niet operationeel: u bent er immers niets mee dat de server draait als bezoekers van uw website ze niet kunnen bereiken. Hoeveel gegevens mag u verliezen als een datacenter uitvalt? Het antwoord op deze vraag wordt uitgedrukt in de RPO (recovery point objective), waarmee u de maximumperiode vóór de uitval bepaalt waarvan u de gegevens mag verliezen om uw business continuïteit niet in gevaar te brengen. Let op dat u duidelijke afspraken maakt met uw hostingprovider over wanneer de klok begint te lopen na een ramp. Zowel RTO als RPO worden uitgedrukt in tijdseenheden. Welke RTO en RPO haalbaar zijn, hangt af van de technologie die u gebruikt. Vooral storage is een bepalende factor. De volgende RTO en RPO zijn doorgaans te bereiken met synchrone en asynchrone mirroring: RTO RPO synchroon enkele seconden 0 asynchroon 15-90 minuten 15-30 minuten Dit zijn theoretische waardes. In de praktijk moet u bepaalde technologische keuzes maken om die te behalen. De kosten om bovenstaande RTO en RPO te bereiken met die keuzes, zet u dan tegenover het verlies dat uw organisatie maakt door zo lang downtime te hebben of gegevens te verliezen. Afhankelijk van uw toepassing kan dat verlies eenvoudig te berekenen zijn. Een webwinkel heeft bijvoorbeeld cijfers over de gemiddelde omzet per minuut en kan daaruit berekenen wat een aanvaardbaar niveau van downtime is.
Over Unitt Unitt ontwikkelt en beheert zakelijke hostingdiensten met diepgaande kennis van de modernste technologieën. Het biedt daarbij een oplossing voor de meest veeleisende applicaties en websites, dankzij harde garanties op serviceniveau. Unitt maakt onderdeel uit van de Intelligent-groep waartoe ook Combell behoort. Voorheen was Unitt ook gekend als Combell Solutions. Met 24/7 ondersteuning in de taal van de klant en direct contact met de engineers die de infrastructuur beheren, onderscheidt zij zich van de markt. Unitt laat zich vooral opmerken in vier productgroepen: business critical applications, high traffic websites, e-commerce en SaaS-platformen. Alle producten worden gebouwd met de nieuwste hoogwaardig technologische componenten. http://www.unitt.com 8