Het woord ‘cloud’ wordt de laatste jaren in verschillende varianten gebruikt in relatie tot ICT. We praten over PaaS, SaaS, IaaS, Private Cloud, Publieke Cloud, Hybride Cloud. Het is een uitdaging voor integratoren als Axians om daar samen met onze klanten de juiste invulling aan te geven.
Is elke organisatie klaar voor een switch naar de Cloud? Nee, zeker niet. Om op een goede manier gebruik te kunnen maken van Cloud-modellen zijn een paar randvoorwaarden essentieel:
1. De ICT-organisatie is er klaar voor. Er is een duidelijke definitie van rollen. Daarbij is er aandacht voor medewerkers die architectuur bewaken en die regie kunnen voeren.
2. De ICT-infrastructuur is voldoende flexibel en transparant. Hoe beter dit is geregeld, hoe makkelijker het wordt om een koppeling met externe resources te realiseren.
3. Het applicatie landschap is inzichtelijk, met name de onderlinge koppelingen en afhankelijkheden. Hoe complexer en onoverzichtelijker, hoe lastiger het is om een koppeling te maken met externe resources. Ook kan het dan heel moeilijk zijn om een duidelijke vastleggen van verantwoordelijkheden tussen functioneel beheer en externe dienstverlener te maken. De eerste twee punten zijn al langer onderwerp van gesprek. Het applicatielandschap is nog wel eens onderbelicht. Een duidelijke visie op dit terrein ontbreekt bij veel organisaties.
Een goed inzicht in het bestaande applicatielandschap en de onderliggende afhankelijkheden is lang niet altijd aanwezig.
- Welke bedrijfsprocessen worden ondersteund? Welke waarde hebben de applicaties voor deze processen?
- Waar liggen de verantwoordelijkheden? Welke SLA’s gelden er per service of applicatie?
- Welke afhankelijkheden zijn er met andere applicaties, onderliggende systemen of bedrijven?
De mist die Cloud heet
Het ontbreken van dit inzicht is ook funest voor het hebben van een goed Disaster Recovery plan. Dit is een onderwerp waar veel ICT-organisaties mee worstelen. Wij krijgen steeds vaker de vraag hierover mee te denken. ICT organisaties krijgen vanuit hun directie, hun klanten of wet- en regelgeving een sterke push om hogere garanties voor beschikbaarheid af te kunnen geven. Om in deze behoefte te kunnen voorzien heeft Axians zelf een Disaster Recovery dienst (DR services) ontwikkeld. Om een goede DR service te kunnen bieden is een duidelijk beeld van het applicatielandschap en de onderlinge afhankelijkheden van groot belang. Applicaties en data zullen gerepliceerd moeten worden naar een uitwijklocatie, waar de applicaties in de juiste volgorde moeten worden opgebracht en de data beschikbaar gemaakt moet worden. Maar welke manier van repliceren is dan de beste? Dat is per case verschillend. We onderscheiden replicatie op een aantal niveaus:
- Applicatie replicatie;
- Storage replicatie;
- Virtuele Server replicatie.
Applicatie replicatie
Hierbij vindt de replicatie plaats op basis van gereedschappen die in de applicatie of database aanwezig zijn. Er zijn goede voorbeelden waarbij een grote mate van betrouwbaarheid van de replicatie wordt gerealiseerd. Grondige kennis van de applicatie of database is wel een voorwaarde. Als er een fail-over moet plaatsvinden zonder verstoring van de dienstverlening, dan moet de bovenliggende applicatie dit wel ondersteunen. Indien de bovenliggende applicatie dit niet ondersteund, dan moeten er handmatig applicatieverwijzingen zoals bijvoorbeeld ODBC-koppelingen aangepast worden. Voorbeelden van deze replicatie zijn Database Availability Group (DAG) bij Exchange Server, database mirroring of log shipping in het geval van SQL Server of een Microsoft Active Directory replicatie.
Storage replicatie
Met behulp van storagereplicatie is het mogelijk om een volledig storagesysteem of delen daarvan te repliceren naar een ander storagesysteem. Dit wordt vaak gebruikt voor disaster recovery-oplossingen waarbij de primaire opslag wordt gerepliceerd naar een secundair systeem op een andere locatie. Storagereplicatie moet niet verward worden met back-up aangezien hier alleen de laatste versie van de data beschikbaar is (geen historie). Afhankelijk van de RPO/RTO-eisen van een organisatie kan replicatie synchroon of asynchroon gedaan worden. Synchrone replicatie stelt hoge eisen aan de tussenliggende infrastructuur qua bandbreedte en latency, maar er is geen dataverlies in het geval van een calamiteit. Asynchrone replicatie stelt minder hoge eisen aan het storagesysteem en de benodigde infrastructuur maar in het geval van een calamiteit is er wel enig dataverlies. Het toegestane dataverlies (RPO) is bepalend voor het replicatie interval en de benodigde bandbreedte.
Virtuele server replicatie
Vanaf versie 5.5 van VMware vSphere is er de mogelijkheid om gebruik te maken van vSphere Replication. Hiermee kan replicatie worden opgezet tussen twee storagesystemen die van verschillende types of makelij zijn. Replicatie vindt plaats binnen de vSphere client, zodat er geen additionele beheertooling nodig is. De klant kan kiezen voor een passende RPO, van 15 minuten tot 24 uur. Het grote voordeel van deze oplossing is dat vSphere Replication gebruikt kan worden met verschillende types storage en protocollen. vSphere Replication maakt gebruik van Microsoft Volume Shadow Copy Service (VSS), zodat er een consistente VM ontstaat in de uitwijklocatie.
Disaster Recovery, de toegevoegde waarde van een specialist
Wat het beste is voor een organisatie hangt dus sterk af van de aanwezige applicaties en de onderliggende ICT-infrastructuur. Wilt u Disaster Recovery binnen of buiten uw eigen infrastructuur? Welke inrichting is voor u de beste keuze? Gelukkig zijn er veel gereedschappen om tot een goede oplossing te komen, maar hoe die gereedschappen ingezet moeten worden in uw situatie is weer een studie op zich. Voor een ICT-organisatie zijn deze onderwerpen geen dagelijkse kost. Voor Axians is dat wel zo. Het zijn onderwerpen die een goede onderlinge samenwerking en communicatie vragen en daar krijgen we als architecten energie van!
Erik Scholten, Solutions Architect bij Axians
