Het realiseren van applicatie-consistente backups is complexer dan ooit. Reden is dat moderne cloud-native apps uit tal van microservices bestaan die verspreid worden opgeslagen, om de veerkracht te vergroten. Voor het populaire Kubernetes, waarmee gecontaineriseerde applicaties zijn te orkestreren, automatiseren en beheren, is deze consistentie nog belangrijker, maar ook lastiger te realiseren. Dat verdient een uitleg.
Applicatieconsistente backups maken houdt in dat je een complete applicatie in de huidige toestand vastlegt. Het probleem is dat moderne applicaties, en met name cloud-native applicaties, zijn verspreid over virtuele machines, containers en clouddiensten. Het maken van een backup van de afzonderlijke componenten is niet toereikend om de complete applicatie te beschermen. De enige manier om voor een bruikbare backup te zorgen is door alle applicatiecomponenten op precies hetzelfde moment vast te leggen.
Uitdagingen in Kubernetes-omgevingen
Bij Kubernetes is het maken van applicatieconsistente backups nog ingewikkelder. Daar zijn twee redenen voor: vluchtigheid en statelessness.
Om met het eerste te beginnen: containers hebben een vluchtig karakter. Je hebt niet te maken met slechts één container. De applicatieservice is de som van alle draaiende containers. Tijdens normale bedrijfsprocessen worden er afzonderlijke container-instances in het leven geroepen die later weer verdwijnen. Dit wordt veroorzaakt door het opvoeren of reduceren van de capaciteit (het toevoegen of verwijderen van replica’s) en gebeurtenissen op de host (zoals storingen en clusteraangelegenheden). We kunnen de containers zelf dus niet gebruiken om een backup te maken van een complete applicatie. Daarvoor moeten we een beroep doen op het onderliggende Kubernetes-platform en inzicht verwerven in de taxonomie van de applicatie. We moeten de kennis van Kubernetes van de applicatie gebruiken voor het vastleggen van de container-images, de configuratie van de applicatie en de toestand en persistente opslag daarvan.
Maar er is ook goed nieuws: de taxonomie van applicaties ligt opgeslagen in de kern van Kubernetes. Met behulp van Deployments, ReplicaSets en Pods kun je Kubernetes vertellen hoe je applicatie er precies uitziet. En Kubernetes kan met behulp van Services, Ingress, ConfigMaps, Secrets en een aantal andere objecttypen applicaties herleiden tot hun afzonderlijke componenten. Dit overzicht van componenten kunnen we gebruiken voor het waarborgen van applicatieconsistentie. De desired state-aanpak van Kubernetes, waarbij je definieert hoe je wilt dat je applicaties eruitzien, komt daarbij goed van pas. De volledige taxonomie van een applicatie is beschikbaar in de vorm van kant-en-klare code. Kubernetes scheidt de basis-images van de container, de configuratie en toestand van de applicaties, alle secrets en de persistent storage netjes van elkaar.
Daarmee zijn we aangekomen bij de tweede belangrijke factor die applicatieconsistentie in Kubernetes-omgevingen in de weg zit: containers zijn stateless, en dat resulteert in fragmentatie van persistente data. Kubernetes brengt keurig een scheiding aan tussen de runtime van de applicatie (de container-image), de configuratie van de applicatie (ConfigMaps, de persistente toestand op schijf) en de data van de applicatie (persistente volumes). Als je een backup wilt maken van een complete applicatie in de huidige toestand, moet je dus meer dan alleen de container-images vastleggen. Je zult gelijktijdig bescherming moeten bieden voor aanvullende Kubernetes-objecten (zoals ConfigMaps, Secrets en Services) en de persistente data in omgevingen op locatie, in block storage-omgevingen in de cloud, in file stores en in object stores. Dit leidt onvermijdelijk tot fragmentatie van data in heterogene storage-services en opslaglocaties zoals availability zones in de cloud en datacenters op locatie. En het is nou niet bepaald makkelijk om bij te houden welke data waar (en hoe) is opgeslagen. Dit draagt bij aan de complexiteit van applicatieconsistente back-ups.
Applicatieconsistentie waarborgen in Kubernetes
Gelukkig zijn er manieren om de hierboven beschreven problemen het hoofd te bieden. Het eerste stukje van de puzzel is om de state op één locatie onder te brengen. Daarvoor kun je een beroep doen op de Kubernetes yaml. Die kun je gebruiken als single source of truth (en wijzigingsgeschiedenis) voor de anatomie van een applicatie. Met een dergelijke mate van overzicht op de toestand van je applicatielandschap kun je de data daarbinnen op juiste en volledige wijze beschermen. Je weet immers alles wat je over de applicatie moet weten om back-ups te maken van alle onderdelen waaruit die is opgebouwd. Dat betekent dat je in één klap de volledige applicatie kunt beschermen, compleet met de metadata, toestand, configuratie en persistente data voor hetzelfde tijdstip. En het betekent bovendien dat je alles als één consistent en samenhangend geheel kunt herstellen, samen met alle objecten en metadata zoals ConfigMaps, StatefulSets, Services en Deployments.
Het tweede stukje van de puzzel is om verder te kijken dan het maken van snapshots of backups met behulp van agents. Vanwege de complexiteit van cloud-native applicaties biedt één snapshot van al deze zaken geen consistente point-in-time bescherming. En de snapshot kan dus ook geen herstel garanderen. Zeker niet als applicaties gebruikmaken van heterogene storage-services, aangezien er sprake is van verschillen in de onderliggende snapshottechnologieën van elke service. Om een complete applicatie op consistente wijze te beschermen heb je een gedetailleerdere aanpak nodig. Met journaling kun je een applicatie en alle persistente data tot op de seconde nauwkeurig herstellen naar elk gewenst tijdstip in het verleden. Voldoet het geselecteerde herstelpunt niet aan de eisen? Dan kun je het simpelweg verwijderen en een ander herstelpunt selecteren. Meer komt er niet bij kijken. Journaling biedt het voordeel van write-order fidelity voor persistente volumes. Dit waarborgt dat alle wijzigingen van de complete applicatie in dezelfde volgorde worden beschermd, ongeacht de microservices-architectuur die wordt gebruikt. Dit biedt de consistente databescherming waar applicaties in productieomgevingen om vragen, en wel van seconde tot seconde.
Laat de complexiteit je er niet van weerhouden om de infrastructuur van je organisatie te moderniseren met Kubernetes. Het monster van applicatieconsistentie is te temmen. Het vereist de toestand van een applicatie op één locatie in combinatie met continue databescherming op basis van journaling-technologie. Hiermee kun je stappen maken in het kader van digitale transformatie, zonder dat dit ten koste gaat van de bescherming van je data.
