Continuïteit van informatiesystemen

Bij informatiebeveiliging draait het om drie belangrijke zaken: vertrouwelijkheid, integriteit en beschikbaarheid. Alle drie moeten deze voldoende zijn gewaarborgd om van een passende informatiebeveiliging te kunnen spreken. Een van de hoofdpunten van het onderdeel beschikbaarheid is continuïteitsmanagement van de informatiesystemen en van dat onderdeel wil ik nu kort laten zien hoe ik dat sinds het begin van deze eeuw heb zien ontwikkelen. In dit artikel ga ik niet in op ontwikkelingen als ‘Sofware as a Service’ of meer recente ontwikkelingen als ‘cloud computing’, maar neem ik de eigen infrastructuur als uitgangspunt. Over die andere ontwikkelingen een andere keer vast nog wel meer.

Extra servers
Rond de eeuwwisseling, dus zo’n 10 jaar geleden, was een eerste stap het verdelen van data over meerdere servers en het dubbel uitvoeren van compenenten in de servers. Als deze maatregelen goed werden uitgevoerd, werd de beschikbaarheid wat hoger, omdat bij een probleem met een server iedereen nog wel verder kon werken. Applicaties die gebruik maakten van de andere servers, bleven dan gewoon werken. Overigens had toen elke bedrijfslocatie vaak nog z’n eigen servers en waren storingen daardoor niet zo veel omvattend. Ook werd ICT toen nog veel minder intensief gebruikt. Bij de organisatie, waar ik werk, was dit in 1999 de eerste stap toen we ons bewust werden, dat we toch wel redelijk afhankelijk aan het worden waren van computers.

Centralisatie
Eigenlijk hoort centralisatie niet thuis in het rijtje maatregelen, dat de continuïteit beter waarborgt. Door centralisatie wordt één locatie namelijk heel kritisch in de infrastructuur en worden de risico’s voor de continuïteit dus groter. Hierbij kun je denken aan de stroomvoorziening, brandveiligheid, maar ook bijv. de afhankelijkheid van de dataverbinding op de centrale locatie. Zo’n centralisatieslag heb ik zelf in 2003 uitgevoerd, omdat dit functioneel grote voordelen op ging leveren bij de implementatie van een ERP-applicatie.

Functioneel en beheerstechnisch gezien heeft centralisatie grote voordelen en door een aantal maatregelen kunnen de risico’s voor de continuïteit natuurlijk wel worden beperkt. Een praktische manier, die ik vaak zie,  is dat de centrale infrastructuur wordt verplaatst van een eigen serverruimte naar een professioneel datacenter, waardoor bijv. stroomvoorziening, brandveiligheid, koeling en dataverbindingen veel beter zijn geregeld, dan in de meeste interne serverruimtes in eigen kantoren.

Hogere beschikbaarheid bij centralisatie
In een gecentraliseerde omgeving is het wel beter mogelijk om een groot deel van de infrastructuur dubbel uit te gaan voeren en hierdoor een hogere beschikbaarheid te waarborgen. Doordat de apparatuur fysiek op
één locatie staat, is de benodigde apparatuur en/of software om hogere beschikbaarheid te regelen ook voor kleinere organisaties redelijk betaalbaar. Vaak wordt in dit stadium ook virtualisatie toegepast. De ruimte waar de apparatuur staat, blijft echter nog steeds net zo kritisch. De kans dat deze ruimte door een calamiteit wordt getroffen is misschien niet zo groot, de gevolgen zijn dat zeker wel.

In dit stadium heb ik zelf twee belangrijke trajecten uitgevoerd: in 2005 het invoeren van een databasecluster en het redundant uitvoeren van dataverbindingen. In 2007 hebben wij het grootste deel van de backend-servers gevirtualiseerd, waardoor aanzienlijk minder hardware nodig was en de beschikbaarheid toch hoger werd. Daarnaast werd door deze virtualisatieslag de recovery bij een eventuele calamiteit veel makkelijker. Na het virtualiseren van een groot deel van de servers hebben wij ook het volledige serverpark verplaatst vanuit een eigen serverruimte naar een professioneel datacenter.

Redundant datacenter of uitwijklocatie
Nog een stap verder in het waarborgen van de continuïteit is het gebruik maken van twee datacenters. Afhankelijk van de locatie van de datacenters en de beschikbare verbindingen tussen de twee datacenters zijn hiervoor twee opties.

Uitwijklocatie
De eerste optie is het opzetten van een uitwijklocatie: een ingerichte infrastructuur in een tweede datacenter, dat alleen wordt gebruikt bij een calamiteit in het eerste. Het voordel hiervan is, dat de verbinding tussen de twee locaties alleen nodig is om de data regelmatig te dupliceren. Het nadeel hiervan is dat de apparatuur op de tweede locatie in principe nooit wordt gebruikt, ofwel een erg hoge verzekeringspremie wordt betaald. Een rekenvoorbeeld: als bij uitval van de hooflocatie nog 80% van de capaciteit moet kunnen worden gebruikt, is totaal 180% nodig (100% productie plus 80% uitwijk). Daarnaast is beheertechnisch het risico best groot, dat de applicatieversies e.d. op de uitwijklocatie achterlopen op de productielocatie.

Redundant datacenter
De gunstigere optie, waarvoor wel een aanzienlijk betere verbinding tussen de datacenters nodig is, is het verdelen van de apparatuur over beide locaties, waarbij alle apparatuur actief wordt gebruikt. Bij uitval van één locatie blijft dan nog de helft van de capaciteit beschikbaar. Als dit te weinig is, hoeft in verhouding minder te worden toegevoegd dan bij de optie van de uitwijklocatie. In hetzelfde rekenvoorbeeld is dan maar 80% nodig op beide locaties, dus totaal 160%. Als beide locaties actief zijn, kan worden geprofiteerd van 160% capacteit, terwijl bij uitval van één locatie nog voldoende overblijft. Uiteraard komt er bij deze optie nog veel meer kijken, maar als ik dat allemaal ga noemen, wordt dit artikel nog drie keer zo lang. Als ik tijd en zin heb, ga ik me daar overigens nog wel een keer aan wagen in een redelijk technisch artikel.

Momenteel ben ik bezig met de uitbreiding van onze infrastructuur naar een tweede datacenter. In een bijna volledig gedigitaliseerde omgeving is dit nodig om voldoende waarborgen te hebben voor de continuïteit van de geautomatiseerde infrastructuur. Overigens zullen wij het grootste deel van de apparatuur in een active/active configuratie verdelen over de twee locaties, maar niet alles. Hoe mooi dit technisch ook mogelijk zou zijn, de kosten moeten nog steeds in redelijke verhouding staan tot de risico’s en dan is niet alles te verdedigen.

Advertenties

Geef een reactie

Vul je gegevens in of klik op een icoon om in te loggen.

WordPress.com logo

Je reageert onder je WordPress.com account. Log uit /  Bijwerken )

Google+ photo

Je reageert onder je Google+ account. Log uit /  Bijwerken )

Twitter-afbeelding

Je reageert onder je Twitter account. Log uit /  Bijwerken )

Facebook foto

Je reageert onder je Facebook account. Log uit /  Bijwerken )

w

Verbinden met %s

%d bloggers liken dit: