Verschillende soorten replicatie
Om maar meteen met de deur in huis te vallen: er zijn drie fundamentele vormen van datareplicatie. Zo kunnen disk-blokken gerepliceerd worden (block based replication, bijvoorbeeld bij Redundant Arrays of Inexpensive Disks – RAID), kunnen er records gerepliceerd worden (bij databases) of volledige files gerepliceerd worden (denk aan bijvoorbeeld AWS S3 buckets, Google’s Cloud Storage of Microsoft Azure Blob storage). Alle drie hebben hun sterke en zwakke kanten en daarmee specifieke toepassingsgebieden.
In “Cloud Speak” hebben we het dan over “Patterns and Anti-Patterns“. Hierbij zijn de “Patterns” de juist toegepaste replicatie types en de “Anti-Pattrens” onjuist toegepaste replicatie types in een specifiek geval.
Block based storage
Block based storage komen we vaak tegen in de wereld van Storage Area Networks (SAN’s). Dit zorgt ervoor dat data op meerdere disks komt te staan en het uitvallen van een disk niet tot dataverlies leidt to data verlies. Het is een heel efficiënte vorm van datareplicatie omdat alleen gewijzigde blokken gerepliceerd worden. Dit in tegenstelling tot het repliceren van het complete bestand. Niet alleen bij SAN’s komen we dit tegen. Zo is er ook open source software om block based replicatie te doen (eventueel over een netwerk), zoals o.a. DRBD.
Block based replication wordt meestal toegepast met als doel redundantie (van disks bijvoorbeeld) te realiseren. Wanneer het geen replicatie is tussen lokale disks, maar er naar een andere disk op een andere locatie gerepliceerd wordt, gaat het niet alleen om disk redundantie, maar ook om de beschikbaarheid van de data. De (fysieke) locatie van de data is dan als Single Point of Failure (SPoF) uitgesloten.
Maar ook zo’n oplossing kent zijn grenzen. Wordt data aan één kant verwijderd, dan gebeurt dat ook aan de andere kant. Daar beschermt het dus niet tegen. Het is geen disaster recovery (DR). Een off site back-up is dat bijvoorbeeld wel.
Recordgebaseerde replicatie
Recordgebaseerde replicatie wordt toegepast bij databases. Databases kennen bijvoorbeeld leesacties en schrijfacties op records. Bij replicatie worden alleen schrijf-acties gerepliceerd, de leesacties veranderen immers niets. De schrijfacties worden aan de andere kant opnieuw gedaan zodat beide databases weer gelijk zijn. Vaak is de gerepliceerde database een “Alleen lezen” database (ook wel “Slave” genoemd). De gerepliceerde (slave) database kan bijvoorbeeld prima gebruikt worden om backups van te maken. Er is dan geen performance impact op de “primaire” of “Master” database.
Replicatie wordt hier dus ook gebruikt om de beschikbaarheid te vergroten (en is er geen sprake van DR). De back-up die van de “Slave” database gemaakt wordt is wel een DR-maatregel. De gerepliceerde schrijfacties kunnen in een re-do log file geplaatst worden (Oracle technologie). Deze re-do log files worden dan vaak ook in de back-up meegenomen. Met de combinatie van back-up van de database en de re-do log files kan een “Point-in-Time restore” worden uitgevoerd.
Databases hebben legio mogelijkheden om te repliceren. Bijvoorbeeld MySQL / MariaDB bieden uitgebreide mogelijkheden hiertoe. In het bovenstaande voorbeeld werd de database replica niet gebruikt voor productie. Het wordt gebruikt om een back-up van te maken en het heeft ook geen eindgebruikers. Maar voor lees-acties kunnen beide databases (“Master” en “Slave”) gebruikt worden, zolang wijzigingen alleen naar de “Master” geschreven worden.
In het algemeen heeft een database 10 keer zoveel lees-acties als schrijf-acties. Een “Master” met 9 “Slaves” kan dus een manier zijn om de totale performance van het gehele systeem te verhogen. Maar hoewel de performance dan hoger is, is de “Master” nog steeds een Single Point of Failure (SPoF). Een van de replica’s kan master worden, maar dat kost tijd en levert dus downtime op voor schrijf-acties.
“Master”-“Master” setup
ACID
Een term die bij databases wordt gebruikt, is ACID (Atomicity, Consistency, Isolation & Durability). Dit zijn kenmerken van een database waarmee de juistheid en compleetheid van data gegarandeerd wordt. Het ‘Atomicity’ kenmerk stelt dat database bewerkingen ondeelbaar zijn en dus juist of helemaal niet doorgevoerd en opgeslagen worden. Het voorkomt dat bewerkingen half doorgevoerd worden en dat er data mist of corrupt raakt.
Een andere mogelijkheid is een “Master-Master” setup te bouwen. Hierbij kunnen beide “Master” databases schrijf-acties ontvangen en repliceren deze naar de andere “Master”. Er moet voorkomen worden dat records met hetzelfde recordnummer geschreven worden. Daarom wordt gekozen de ene “Master” de even inserts te laten doen en de andere “Master” de oneven inserts. Beide databases zijn met lokale performance te gebruiken – ook wanneer ze ver uit elkaar staan. Deze systematiek kan naar believen verder uitgebreid worden, bijvoorbeeld met een 3 “Master” setup (zie de figuur). De beschikbaarheid van de data gaat hiermee omhoog evenals de performance. Maar een DROP TABLE (tabel verwijderen) wordt naar alle masters gerepliceerd en dus is het geen DR.
Nog een laatste opmerking over de multi “Master” setup. Wanneer de databases ver van elkaar verwijderd zijn, is er sprake van een hogere lantency bij de replicatie. Beide databases kunnen lokaal met uitstekende performance gebruikt worden. Het is een goede setup voor active-active (ook wel multi-region) designs. Replicatie kan hierbij “Achterlopen” (denk dan aan de RPO, zie sectie over RPO en RTO).
File based replicatie
In cloudomgevingen is het (op simpele wijze) repliceren van files een basisvoorziening. Dit bestond al voor de cloud (Ceph bijvoorbeeld), maar de cloud heeft het wel populair gemaakt. Tegenwoordig weet iedereen wat een AWS S3 bucket is. Met file gebaseerde replicatie worden files op meerdere storage systemen (en vaak ook locaties) opgeslagen.
Zodra een file verandert, wordt een volledig nieuwe versie van de file (of object) gemaakt, dit wordt ook wel “Copy-on-Write” genoemd. Het gevolg hiervan is dat als een file (of object) verandert, alle kopieën gelijk gemaakt moeten worden. Dit kost hierdoor tijd en daarmee spreek men wel over “Eventually Consistent” storage.
De file (het object) kan van iedere locatie gelezen worden (nadat het consistent is geworden). Dit levert een hoge performance op. Versiebeheer is ook (relatief) eenvoudig, na een “Copy-on-Write” wordt de oude versie niet verwijderd.
Nadeel van het “Copy-on-Write” principe is dat wanneer slechts 1 bit van een file veranderd wordt, het gehele file opnieuw geschreven moet worden. Het opslaan van een database file op een object store (zoals S3) is dan ook niet efficiënt. Iedere record change leidt tot een nieuwe kopie van het complete database bestand.
De performance hiervan is dan ook slecht, het is een zogenaamd “Anti-Pattern“. Gesteld kan worden dat object storage (file based replicatie) dus zowel de performance ten goede komt (in de juiste situaties, de “Patterns”) net als de beschikbaarheid (availbility). Het kan ook DR bieden, mits versiebeheer ingeschakeld is.
Een laatste voordeel van een dergelijke opslagtechniek is dat ze vrijwel onbeperkt schaalbaar is qua opslag capaciteit. Het werkt juist doordat het zo eenvoudig is.
Maar kan een object storage file systeem gekoppeld (gemount) worden?
Blokgebaseerde bestandssystemen kunnen gekoppeld (gemount) worden “In” of “Aan” een computer. Het wordt daarmee gezien als lokale storage ook al is het dat niet. Dit is niet gebruikelijk met object storage. Het heeft een Application Programming Interface (API) die gebruikt kan worden. Lees, schrijf, create en delete acties kunnen middels deze API uitgevoerd worden. Toch is het – als je dat echt wil – wel mogelijk een object store te koppelen (mounten). De performance van een dergelijke oplossing is laag vooral vanwege het “Copy-on-Write” principe. De object store gedraagt zich fundamenteel anders dan lokale storage en dat heeft niet veel toepassingen (Patterns).
RTO en RPO
Bij het design van een omgeving wordt vastgesteld welke RTO en RPO behaald moeten worden. De Recovery Point Objective (RPO) is het maximale data verlies dat een omgeving mag hebben. Recovery Time Objective (RTO) is feitelijk de maximale down time, maar je kan het ook zien als de beschikbaarheid van de omgeving. Deze waarden worden vaak tijdens een Business Impact Analyse (BIA) vast gesteld.
De RTO wordt bereikt door alle maatregelen die getroffen zijn om de beschikbaarheid te kunnen garanderen of te herstellen. De RPO wordt vooral bepaald door de latency van de datareplicatie en de back-up / restore (DR). Maar wanneer er een netwerk storing optreedt voordat data volledig gerepliceerd is, hoeveel data is dan verloren gegaan?
Welke hoeveelheid dataverlies is eigenlijk acceptabel? RPO is dus een complex onderwerp, want hoe weet je welke data nog wel gerepliceerd is tijdens een storing en welke niet? Hoe bepaal je welke van de twee zijdes de correcte data bevat als ze niet meer in sync zijn?
Dit wordt ook wel de data “GAP” genoemd. Hiermee raken we aan het onderwerp van synchrone en a-synchrone datareplicatie. Meer hierover in de sectie “Timing”.
Welke data is nu correct nadat we een replicatie storing hebben gehad?
Bij een database kan de “Time Stamp” gebruik worden. Het laatste correct weggeschreven record is de laatste data die goed is, alles daarna is fout. Voorwaarde is dat beide kanten de juiste tijd hebben. Bij Block gebaseerde replicatie wordt iets gebruikt dat “Fencing” genoemd wordt. “Fencing” wordt gebruikt om te bepalen welke (storage) zijde de waarheid bevat.
En back-up dan?
Je kan je – terecht – afvragen of back-up / restore een datareplicatie techniek is. Dat is vast een discussie waard. In de meeste gevallen wordt een back-up / restore echter niet gezien als een replicatie techniek. Een back-up / restore gaat eerder over retentie en recovery.
Het maakt een point-in-timekopie van de data (inclusief fouten). Data replicatie is eerder een techniek die gebruikt wordt om “Business Continuity” te garanderen. Verwarrend is dat object storage ook gebruikt kan worden voor de opslag van backups. Het is hoog beschikbaar en ondersteunt versiebeheer. Deze discussie is lastig te beslechten. De kernvraag is dan ook: wat moet er bereikt worden?
En Off site backups dan?
Object store biedt goede opties voor het opslaan van backups. Want niet alleen ondersteund het versiebeheer, het geeft ook de mogelijkheid om van andere regio’s gebruik te maken. Hiermee komen we dicht bij het idee van off site backups.
Granulariteit
De 3 replicatie technologieën hebben allen hun voor- en nadelen, hun “Patterns & anti-Patterns”. Een groot verschil tussen deze technieken is wel de granulatriteit. De kleinste replicatie eenheid is block based replicatie. Het gaat dan bijvoorbeeld om blokken van 4 kilobytes. Records zijn meestal veel groter en files zijn vaak nog vele malen groter.
Topologie
Het artikel raakte eerder al aan “One-way” replicatie en “Two-way” replicatie. Dit wordt ook wel de topologie van de replicatie genoemd.
Deduplicatie
Wanneer de opslag van files geanalyseerd wordt dan valt op dat vaak dezelfde bestanden / files vaker opgeslagen worden. Dat is jammer, want met replicatie worden toch al meerdere kopieën bewaard. Kopieën van kopieën zijn onnodig en kostbaar. Sommige opslagsystemen halen deze dubbelingen eruit zonder dat je dat als eindgebruiker merkt. Dit wordt deducplicatie genoemd. Deduplicatie bespaard opslag capaciteit en dus kosten.
Compressie
Als toevoeging op deduplicatie kunnen data en files ook gecomprimeerd worden. Hierbij maken we bestanden / files kleiner door middel van compressie en besparen zo op opslag capaciteit. Het grootste voordeel behaal je door deduplicatie en compressie te combineren. Beiden vragen echter ook rekenkracht (overhead) en voegen dus (al is het theoretisch) latency toe.
Encryptie
Een onderwerp dat regelmatig langskomt, is encryptie. De meeste cloudproviders en hyperscalers bieden dit “Out of the Box” aan. Dit kan toegepast worden op lokale (block) gebaseerde opslag, op databases en op object gebaseerde opslag. Het is een goed idee om encryptie toe te passen, het is makkelijk en kost vrijwel niets.
Het beschermt je echter niet tegen de cloud provide / hyperscaler zelf. Zij kunnen gewoon bij de encryptiesleutels. Moet dat voorkomen worden, dan zal een bedrijf of organisatie zelf haar encryptiesleutels moeten beheren. Dat is te doen, maar integreert niet zo fijn in de cloud omgeving.
Bijvoorbeeld met een Hardware Security Module (HSM). Dit beschermt dan wel tegen de cloud provider / hypescaler en tegen informatie verzoeken van overheden en geheime diensten. Het is dus belangrijk in de discussie rond datasoevereiniteit. Deze encryptie van opgeslagen data wordt ook wel encryptie van “Data at Rest” genoemd.
Naast encryptie van “Data at Rest” kennen we encryptie van “Data in Transfer“, het netwerkverkeer. Beiden zijn encryptie, beiden beschermen tegen andere risico’s.
Caching
Een onderwerp dat hier genoemd moet worden, is caching. Caching – in het algemeen – is de benadering waarbij veel gevraagde data op snelle disk (SSD), memory of geografisch dichtbij wordt geplaatst. Hierdoor kan deze data heel snel aangeleverd worden. Ook operating systemen zoals Linux, OSX en Windows kennen zoiets. Databases kennen ook cache. Hiermee kunnen veel opgevraagde records snel verstuurd worden. Bijvoorbeeld handig voor sessie-informatie die veelvuldig gevraagd wordt. Cache is een datareplicatie onderwerp om dat het enerzijds replicatie kan versnellen en anderzijds replicatie kan verstoren. Hier weiden we niet verder uit over dit onderwerp, maar je gaat dan bijvoorbeeld in op onderwerpen als “Cache hits”, “Cache misses” en “Flushing Cache”.
Timing
Een ander interessant aspect van datareplicatie moet nog in meer detail besproken worden: de tijdsvertraging (latency). Dit is van belang bij replicatie. Dit kwam eerder aan bod bij de RTO en RPO. De fysieke afstand tussen de storage die we repliceren bepaalt welke tijd er nodig is om die data te repliceren.
Pas wanneer data aan beide kanten compleet is weggeschreven is de data veilig. Wanneer de afstand groot is begint dit een rol te spelen. Bij synchrone replicatie wordt pas een bevestiging gegeven als beide zijden geschreven hebben. Vanwege de afstand moet een eindgebruiker dan langer wachten.
Bij echt grote afstanden kan dit vervolgens een probleem worden. Er kan dan beter gekozen worden voor asynchrone replicatie. Hierbij kan de eindgebruiker verder wanneer de data lokaal is weggeschreven. Daarna wordt de data nog gerepliceerd. Dit is goed nieuws voor de performance, maar minder goed voor data veiligheid.
Want het kan dus voorkomen dat de data nog niet volledig is gerepliceerd en er zich een verstoring voordoet. De storage is dan niet meer hetzelfde. Welke zijde heeft nu gelijk als er bidirectionele replicatie werd toegepast? Hier zijn natuurlijk wel oplossingen voor, maar die vallen buiten de scope van dit artikel.
Datasoevereiniteit
En waarom was dit allemaal zo belangrijk voor datasoevereiniteit? In het licht van de datasoevereiniteit zouden bedrijven en organisaties kunnen overwegen data op meerder plekken op te slaan. Bijvoorbeeld om zeker te zijn van de (geo)locatie van de data (Data Residiency). Ook bieden verschillende technieken de mogelijkheid tot DR van data.
Dit is iets dat datasoevereiniteit zeker raakt. De beschreven technieken zijn dus van belang om dergelijke doelstellingen te verwezenlijken. En omdat geen enkele techniek alle problemen oplost en situaties van elkaar verschillen, zijn alle technieken zinvol om kennis van te hebben en ze “Meester” te zijn. Misschien moet je zelfs een combinatie van technieken gebruik kan / moet worden.
Hoewel het geen replicatie technologie betreft, moet open source software (OSS) hier toch genoemd worden. Omdat datasoevereiniteit gaat om in “Control” te komen van data, heeft de software die gebruikt wordt daar een grote impact op. De beste manier om controle te behouden (of opnieuw te verkrijgen) is controle te behouden over de software die gebruikt wordt.
OSS is dan de beste keuze die gemaakt kan worden. Interessant detail is overigens dat alle cloudproviders en hyperscalers OSS gebruiken. Soms gaan ze zo ver dat ze OSS een nieuwe naam geven en het als een eigen product in de markt te zetten. Dat is overigens legaal.
Zelfs al wordt de hernoemde versie gebruikt, men kan altijd terug naar de OSS variant en daarmee blijft data toegankelijk.
Nog een voordeel van het gebruik van OSS is dat het de beste garantie is om open standaarden te gebruiken. OSS kan niet anders dan open standaarden gebruiken en dat garandeert de toegankelijkheid tot de data.
Samenvattend kan gesteld worden dat het begrip van “Patterns and Anti-Patterns” en het beheersen van de technologeen van datareplicatie hoogstwaarschijnlijk noodzakelijk zijn om datasoevereiniteit te bereiken. datasoevereiniteit is het mitigeren van geopolitieke risico’s in data opslag. Deze technieken gaan je daarbij helpen.
Hoe SUE cloudomgevingen beveiligt, lees je op de pagina Cloud Security. In de gids cloud security staat hoe je de cloud veilig inricht en veilig houdt.
