​De mist die cloud heet en de uitdaging voor integratoren

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 om daar 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, is een aantal 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 applicatielandschap 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.

Doordat er in de afgelopen jaren veel aandacht was voor ontwikkelingen als sourcing en virtualisatie zijn de eerste twee punten al langer onderwerp van gesprek. Organisaties zijn met deze ontwikkelingen aan de slag gegaan en hebben oplossingen doorgevoerd. Voor het derde punt, het applicatielandschap, was hierdoor vaak weinig aandacht. Daardoor ontbreekt een duidelijke visie op dit terrein bij veel organisaties en zien zij nu de noodzaak om in te spelen op andere ontwikkelingen. Het applicatielandschap komt als potentieel knelpunt bovendrijven, waarin verbeteringen nodig zijn.

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?

Disaster Recovery, een zee aan mogelijkheden

ICT-organisaties voelen vanuit directie, klanten of wet- en regelgeving een sterke druk om hogere garanties voor beschikbaarheid af te geven. Een goed Disaster Recovery (DR) plan is dus noodzakelijk. Maar het ontbreken van inzicht in het applicatielandschap is ook funest voor het hebben van een goed DR plan.

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 moeten, als er iets gebeurt, gerepliceerd 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:

Applicatiereplicatie;
Storage replicatie;
Virtuele serverreplicatie.

Applicatiereplicatie

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 ondersteunt, 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 storage systeem of delen daarvan te repliceren naar een ander storage systeem. Dit wordt vaak gebruikt voor DR oplossingen waarbij de primaire opslag wordt gerepliceerd naar een secundair systeem op een andere locatie. Storage replicatie moet niet verward worden met back-up, aangezien hier alleen de laatste versie van de data beschikbaar is (en geen historie).

Afhankelijk van de RPO- en 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 de replicatie-interval en de benodigde bandbreedte.

Virtuele serverreplicatie

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 storage systemen die van verschillende types of makelij zijn. Replicatie vindt plaats binnen de vSphere client, zodat er geen additionele beheer tooling 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 sterk af van de aanwezige applicaties en de onderliggende ICT-infrastructuur. Moet DR binnen of buiten de eigen infrastructuur plaatsvinden? Welke inrichting is per geval de beste keuze? Gelukkig zijn er veel gereedschappen om tot een goede oplossing te komen, maar hoe die gereedschappen ingezet moeten worden is in elke situatie weer een studie op zich.

Voor een ICT-organisatie zijn deze onderwerpen geen dagelijkse kost. Voor een integrator is dat wel het geval. Het zijn nou eenmaal onderwerpen die een goede onderlinge samenwerking en communicatie vragen.

Deze blogpost is geschreven door Laurens Berning, Manager Sales Support bij Imtech ICT Communication Solutions.

[Afbeelding via Brian Smithson Flickr CC]