Jouw online infrastructuur beschermen tegen omvangrijke systeemonderbrekingen: het begint hier

Veel bedrijven zijn afhankelijk van een 24/7 online aanwezigheid, maar hebben hun infrastructuurplatform nog niet ingericht om bescherming te bieden tegen downtime als gevolg van systeemuitval, een cyberaanval of een natuurramp. Het onderstaande stuk biedt advies aan organisaties die van start willen gaan met hun disaster recovery-traject.

De meest effectieve manier om bescherming te bieden tegen downtime is het inrichten van een platform waarmee de business kan reageren op externe storingen die buiten zijn invloedssfeer vallen. Dan valt onder meer te denken aan het uitvallen van een virtuele server, een storing in de onderliggende hardware of uitval van het complete datacenter.

Met het oog op deze risico’s is het belangrijk voor organisaties om een effectieve (en goed geteste) strategie voor disaster recovery (DR) toe te passen binnen hun bedrijfscontinuïteitsplan. Een gedegen DR-strategie biedt een oplossing voor twee belangrijke vraagstukken: het zo snel mogelijk herstellen van de IT-infrastructuur en het minimaliseren van gegevensverlies wanneer het noodlot toeslaat.

Een effectieve DR-strategie moet voorzien in maatregelen die storingen voorkomen en verhelpen. En het is belangrijk om ervoor te zorgen dat deze strategie niet te ingewikkeld is. Complexiteit vergroot namelijk de kans op onvoorziene storingen wanneer er in het geval van een failover van de standaardinfrastructuur wordt overgeschakeld naar de DR-infrastructuur.

Het opzetten van failovers naar een high availability IT-infrastructuur in het datacenter en real-time replicatie van applicatieservers en data naar een alternatieve datacenterlocatie kan bijdragen aan de broodnodige bescherming van workloads en een sneller herstel van bedrijfskritische functies en diensten.

Het is cruciaal om niet op hetzelfde paard te wedden door in één datacenter alle bedrijfskritische workloads af te laten handelen. Een mogelijke oplossing is om servers en databases te repliceren naar een afzonderlijke serverinfrastructuur. Dit zou idealiter een secundaire datacenterlocatie moeten zijn die volledig onafhankelijk is van de primaire datacenterlocatie. Voor optimaal resultaat zou de replicatie van de server of data in vrijwel real time moeten plaatsvinden. Daarmee worden alle wijzigingen binnen de server gerepliceerd, zodat er geen kans bestaat dat er waardevolle wijzigingen verloren gaan zodra er zich een incident voordoet.

Er zijn diverse tools verkrijgbaar die dit mogelijk maken, van software voor de replicatie van locale servers tot replicatie naar een storage area network (SAN). Het is belangrijk om hierbij op te merken dat de beste manier om een consistente replicatie van databases te waarborgen is om geen gebruik te maken van replicatie van servers of storage-omgevingen. Maak in plaats daarvan gebruik van de beschikbare databasetools om databases consistent en gesynchroniseerd te houden.

Voorkom single points of failure

Maar ook als je je infrastructuur volledig redundant maakt door gebruik te maken van verschillende datacenters of availability zones kan er sprake blijven van andere single points of failure, zoals het netwerk. Als beide datacentra gebruikmaken van hetzelfde netwerk en daarin een forse storing optreedt, is de kans groot dat beide datacenters daar hinder van ondervinden. Dit zou ook van invloed kunnen zijn op de failover van je publieke IP-adressen van de primaire naar de secundaire locatie.

Om dit soort scenario’s te voorkomen is het zinvol om gebruik te maken van een secundair datacenter met een netwerk dat onafhankelijk is van je (primaire) hostingprovider. Als je huidige hostingprovider geen onafhankelijk secundair datacenter kan aanbieden, zou je op zoek moeten gaan naar een andere hostingprovider voor de secundaire DR-locatie.

Dit zorgt er weliswaar voor dat het netwerk niet langer een single point of failure vormt, maar brengt weer een nieuw probleem met zich mee. Als je een netwerkonafhankelijk DR-platform inricht door gebruik te maken van verschillende hostingproviders, kunnen de publieke IP-adressen die van de hostingprovider worden ontvangen namelijk niet worden gebruikt in de DR-omgeving die door de andere provider wordt gehost.

Gelukkig bestaat er een simpele oplossing voor dit probleem: wijzig de relevante DNS-vermeldingen (A-records) door de IP-adressen van de DR-omgeving toe te voegen. Daarop worden de gewijzigde DNS-records aan het internet vrijgegeven in de tijd die nodig is om over te stappen naar de DR-omgeving, waarmee de toegang tot het platform wordt hersteld.

Bedrijven zonder de middelen, tijd of zin om zelf een eigen DR-platform te ontwerpen en implementeren kunnen een beroep doen op een infrastructure-as-a-service (IaaS)-provider die disaster-recovery-as-a-service (DRaaS)-mogelijkheden aanbiedt. Die kunnen voorzien in de betrouwbaarheid en herstelmogelijkheden die nodig zijn om verstoring van bedrijfsprocessen te voorkomen.

IaaS-providers maken het mogelijk om de kans op gegevensverlies te minimaliseren door gebruik te maken van verschillende datacenters in uiteenlopende geografische regio’s. Daarmee kan de continuïteit van diensten zelfs op peil worden gehouden als er binnen één regio sprake is van downtime, een storing, een cyberaanval of een natuurramp. Binnen IaaS gehoste datacenters kunnen ook verschillende beveiligingslagen worden ingericht om de toegang tot data in te perken, bescherming te bieden tegen fysieke aanvallen en servers veilig te houden voor indringers.

Het ontwerpen en implementeren van een DR-platform hoeft niet ingewikkeld te zijn en vraagt al evenmin om uitgebreide netwerkkennis. Door het regelmatig testen van je DR-platform en ervoor te zorgen dat je niet afhankelijk bent van slechts één hostingprovider kun je er beter op vertrouwen dat de online aanwezigheid van je organisatie bestand is tegen downtime, storingen, natuurrampen en cyberaanvallen.

Peter Lonis is Pre-Sales Solution Engineer bij Leaseweb,