Het is heel gebruikelijk om databases te zien die verspreid zijn over meerdere geografische locaties. Een scenario voor het uitvoeren van dit type installatie is voor noodherstel, waarbij uw standby-datacenter zich op een andere locatie bevindt dan uw hoofddatacenter. Het kan net zo goed nodig zijn dat de databases dichter bij de gebruikers staan.
De belangrijkste uitdaging bij het bereiken van deze opzet is door de database zo te ontwerpen dat de kans op problemen met betrekking tot de netwerkpartitionering wordt verkleind.
MariaDB Cluster kan om verschillende redenen een goede keuze zijn om een dergelijke omgeving te bouwen. We willen ze hier graag bespreken en ook een beetje praten over hoe zo'n omgeving eruit kan zien.
Waarom MariaDB-cluster gebruiken voor geo-gedistribueerde omgevingen?
De eerste reden is dat MariaDB Cluster meerdere schrijvers kan ondersteunen. Dit maakt de schrijfroutering veel gemakkelijker te ontwerpen - u schrijft gewoon naar de lokale MariaDB-knooppunten. Gezien synchrone replicatie heeft latentie natuurlijk invloed op de schrijfprestaties en kunt u zien dat uw schrijfacties langzamer worden als u uw cluster geografisch te ver uitspreidt. Je kunt immers niet om de wetten van de fysica heen en ze zeggen, althans vanaf nu, dat zelfs de lichtsnelheid in glasvezelverbindingen beperkt is. Alle routers die daar bovenop worden toegevoegd, zullen ook de latentie verhogen, al is het maar met een paar milliseconden.
Ten tweede, lag-verwerking in MariaDB Cluster. Asynchrone replicatie is een onderwerp van replicatievertraging - slaven zijn mogelijk niet up-to-date met de gegevens als ze moeite hebben om alle wijzigingen op tijd toe te passen. In MariaDB Cluster is dit anders - flow control is een mechanisme dat bedoeld is om het cluster synchroon te houden. Nou ja, bijna - in sommige randgevallen kun je nog steeds lag waarnemen. We hebben het hier meestal over milliseconden, hooguit een paar seconden, terwijl in de asynchrone replicatie de limiet de limiet is.
Ten derde, segmenten. Standaard gebruikt MariaDB CLuster alle communicatie en elke schrijfset wordt door het knooppunt naar alle andere knooppunten in het cluster verzonden. Dit gedrag kan worden gewijzigd met behulp van segmenten. Met segmenten kunnen gebruikers MariaDB-clusters in verschillende delen splitsen. Elk segment kan meerdere knooppunten bevatten en het kiest een ervan als een relaisknooppunt. Dergelijke knooppunten ontvangen schrijfsets van andere segmenten en distribueren deze opnieuw over MariaDB-knooppunten die lokaal zijn voor het segment. Als gevolg hiervan is het, zoals u in het bovenstaande diagram kunt zien, mogelijk om het replicatieverkeer dat via WAN gaat drie keer te verminderen - slechts twee "replica's" van de replicatiestroom worden via WAN verzonden:één per datacenter vergeleken met één per slave in asynchrone replicatie.
Ten slotte, waar MariaDB Cluster echt uitblinkt, is de afhandeling van de netwerkpartitionering. MariaDB Cluster bewaakt constant de status van de knooppunten in het cluster. Elk knooppunt probeert verbinding te maken met zijn peers en de status van het cluster uit te wisselen. Als een subset van knooppunten niet bereikbaar is, probeert MariaDB de communicatie door te sturen, dus als er een manier is om die knooppunten te bereiken, zullen ze worden bereikt.
Een voorbeeld is te zien in het bovenstaande diagram:DC 1 verloor de connectiviteit met DC2 maar DC2 en DC3 kunnen verbinding maken. In dit geval wordt een van de knooppunten in DC3 gebruikt om gegevens van DC1 naar DC2 door te sturen, zodat de intra-clustercommunicatie kan worden gehandhaafd.
MariaDB kan acties ondernemen op basis van de status van het cluster. Het implementeert quorum - de meerderheid van de knooppunten moet beschikbaar zijn om het cluster te laten werken. Als het knooppunt wordt losgekoppeld van het cluster en geen ander knooppunt kan bereiken, stopt het met werken.
Zoals te zien is in het bovenstaande diagram, is er een gedeeltelijk verlies van de netwerkcommunicatie in DC1 en wordt het getroffen knooppunt uit het cluster verwijderd, zodat de toepassing geen toegang krijgt tot verouderde gegevens.
Dit geldt ook op grotere schaal. De DC1 heeft alle communicatie verbroken. Als gevolg hiervan is het hele datacenter uit het cluster verwijderd en zal geen van de knooppunten het verkeer bedienen. De rest van het cluster behield de meerderheid (6 van de 9 knooppunten zijn beschikbaar) en herconfigureerde zichzelf om de verbinding tussen DC 2 en DC3 te behouden. In het bovenstaande diagram gingen we ervan uit dat de schrijver het knooppunt in DC2 raakt, maar houd er rekening mee dat MariaDB met meerdere schrijvers kan werken.
Geografisch gedistribueerde MariaDB-cluster ontwerpen
We hebben enkele van de functies doorgenomen die MariaDB Cluster geschikt maken voor geo-gedistribueerde omgevingen, laten we ons nu een beetje concentreren op het ontwerp. Laten we eerst uitleggen met welke omgeving we werken. We zullen drie externe datacenters gebruiken, verbonden via Wide Area Network (WAN). Elk datacenter ontvangt schrijfbewerkingen van lokale applicatieservers. Lezingen zullen ook alleen lokaal zijn. Dit is bedoeld om te voorkomen dat onnodig verkeer het WAN oversteekt.
Om deze blog minder ingewikkeld te maken, gaan we niet in op details over hoe de connectiviteit eruit zou moeten zien. We gaan uit van een soort goed geconfigureerde, beveiligde verbinding tussen alle datacenters. VPN of andere tools kunnen worden gebruikt om dat te implementeren.
We zullen MaxScale gebruiken als loadbalancer. MaxScale wordt lokaal geïmplementeerd in elk datacenter. Het zal ook het verkeer alleen naar de lokale knooppunten leiden. Remote nodes kunnen altijd handmatig worden toegevoegd en we zullen gevallen uitleggen waarin dit een goede oplossing kan zijn. Applicaties kunnen worden geconfigureerd om verbinding te maken met een van de lokale MaxScale-knooppunten met behulp van een round-robin-algoritme. We kunnen net zo goed Keepalived en Virtual IP gebruiken om het verkeer naar het enkele MaxScale-knooppunt te leiden, zolang een enkel MaxScale-knooppunt al het verkeer zou kunnen verwerken.
Een andere mogelijke oplossing is om MaxScale samen te brengen met applicatieknooppunten en de applicatie te configureren om verbinding te maken met de proxy op de localhost. Deze aanpak werkt redelijk goed in de veronderstelling dat het onwaarschijnlijk is dat MaxScale niet beschikbaar zal zijn, maar de toepassing zou goed werken op hetzelfde knooppunt. Wat we meestal zien, is ofwel een knooppuntstoring ofwel een netwerkstoring, wat zowel MaxScale als de applicatie tegelijkertijd zou beïnvloeden.
Het bovenstaande diagram toont de versie van de omgeving, waar MaxScale proxy-farms vormt - alle proxy-knooppunten met dezelfde configuratie, load-balanced met behulp van Keepalive, of gewoon round robin van de applicatie over alle MaxScale-knooppunten. MaxScale is geconfigureerd om de werklast te verdelen over alle MariaDB-knooppunten in het lokale datacenter. Een van die knooppunten zou worden gekozen als een knooppunt om de schrijfacties naar te verzenden, terwijl SELECT's over alle knooppunten zouden worden verdeeld. Het hebben van één dedicated writer-node in een datacenter helpt het aantal mogelijke certificeringsconflicten te verminderen, wat doorgaans leidt tot betere prestaties. Om dit nog verder te verminderen, zouden we het verkeer over de WAN-verbinding moeten gaan verzenden, wat niet ideaal is omdat het bandbreedtegebruik aanzienlijk zou toenemen. Op dit moment, met segmenten op hun plaats, worden er slechts twee exemplaren van de schrijfset verzonden over datacenters - één per DC.
Conclusie
Zoals u kunt zien, kan MariaDB Cluster eenvoudig worden gebruikt om geo-gedistribueerde clusters te maken die zelfs over de hele wereld kunnen werken. De beperkende factor is de netwerklatentie. Als het te hoog is, moet u misschien overwegen om afzonderlijke MariaDB-clusters te gebruiken die zijn verbonden via asynchrone replicatie.