Med hög tillgänglighet är avgörande i dagens affärsverklighet, är ett av de vanligaste scenarierna för användare att hantera hur man säkerställer att databasen alltid kommer att vara tillgänglig för applikationen.
Varje tjänsteleverantör kommer med en nedärvd risk för tjänstavbrott, därför är ett av stegen som kan vidtas att lita på flera leverantörer för att minska risken och ytterligare redundans.
Montleverantörer är inte annorlunda - de kan misslyckas och du bör planera för detta i förväg. Vilka alternativ finns tillgängliga för MariaDB Cluster? Låt oss ta en titt på det i det här blogginlägget.
MariaDB-databaskluster i multimolnmiljöer
Om SLA som föreslagits av en molntjänstleverantör inte räcker, finns det alltid ett alternativ att skapa en webbplats för katastrofåterställning utanför den leverantören. Tack vare detta kan du alltid byta till en annan leverantör när en av molnleverantörerna upplever någon tjänstförsämring och hålla din databas uppe och tillgänglig.
Ett av problemen som är typiska för konfigurationer med flera moln är nätverkslatensen som är oundviklig om vi pratar om större avstånd eller i allmänhet flera geografiskt åtskilda platser. Ljushastigheten är ganska hög men den är ändlig, varje hopp, varje router lägger också till viss latens i nätverksinfrastrukturen.
MariaDB Cluster fungerar utmärkt på nätverk med låg latens. Det är ett kvorumbaserat kluster där snabb kommunikation mellan alla noder krävs för att hålla verksamheten smidig. Ökning av nätverkslatens kommer att påverka klusteroperationer, särskilt prestandan för skrivningarna. Det finns flera sätt att lösa detta problem.
Först har vi ett alternativ att använda separata kluster anslutna med asynkrona replikeringslänkar. Detta gör att vi nästan kan glömma latens eftersom asynkron replikering är betydligt bättre lämpad att fungera i miljöer med hög latens.
Ett annat alternativ är att, med tanke på nätverk med låg latens mellan datacenter, kan det fortfarande gå alldeles utmärkt att köra ett MariaDB-kluster som spänner över flera datacenter. När allt kommer omkring betyder flera datacenter inte alltid stora avstånd geografiskt - du kan likaväl använda flera leverantörer som finns inom samma storstadsområde, anslutna till snabba nätverk med låg latens. Då kommer vi att prata om latensökning till högst tiotals millisekunder, definitivt inte hundratals. Allt beror på applikationen men en sådan ökning kan vara acceptabel.
Asynkron replikering mellan MariaDB-kluster
Låt oss ta en snabb titt på det asynkrona tillvägagångssättet. Tanken är enkel - två kluster kopplade till varandra med hjälp av asynkron replikering.
Detta kommer med flera begränsningar. Till att börja med måste du bestämma om du vill använda multi-master eller om du bara vill skicka all trafik till ett datacenter. Vi rekommenderar att du håller dig borta från att skriva till både datacenter och använda master - master replikering. Detta kan leda till allvarliga problem om du inte är försiktig.
Om du bestämmer dig för att använda den aktiva - passiva installationen, skulle du förmodligen vilja implementera någon sorts DNS-baserad routing för skrivningar, för att säkerställa att dina applikationsservrar alltid kommer att ansluta till en uppsättning av proxyservrar som finns i det aktiva datacentret. Detta kan uppnås antingen genom att bokstavligen DNS-posten ändras när failover krävs eller så kan det göras genom någon form av tjänsteupptäcktslösning som Consul eller etcd.
Den största nackdelen med miljön som byggs med den asynkrona replikeringen är bristen på förmåga att hantera nätverksuppdelningar mellan datacenter. Detta ärvs från replikeringen - oavsett vad du vill länka till replikeringen (enkla noder, MariaDB-kluster), det finns inget sätt att gå runt det faktum att replikeringen inte är kvorummedveten. Det finns ingen mekanism för att spåra nodernas tillstånd och förstå bilden på hög nivå av hela topologin. Som ett resultat, när länken mellan två datacenter går ner, hamnar du med två separata MariaDB-kluster som inte är anslutna och som båda är redo att acceptera trafik. Det är upp till användaren att definiera vad som ska göras i ett sådant fall. Det är möjligt att implementera ytterligare verktyg som skulle övervaka tillståndet för databaserna utifrån (dvs från det tredje datacentret) och sedan vidta åtgärder (eller inte vidta åtgärder) baserat på den informationen. Det är också möjligt att samlokalisera verktyg som skulle dela infrastrukturen med databaser men som skulle vara klustermedvetna och som kan spåra tillståndet för datacenteranslutningen och användas som sanningskällan för de skript som skulle hantera miljön. Till exempel kan ClusterControl distribueras i ett kluster med tre noder, nod per datacenter, som använder RAFT-protokoll för att säkerställa kvorum. Om en nod förlorade anslutningen till resten av klustret kan det antas att datacentret har upplevt nätverkspartitionering.
Multi-DC MariaDB-kluster
Alternativ till den asynkrona replikeringen kan vara en helt MariaDB-klusterlösning som sträcker sig över flera datacenter.
Som nämndes i början av denna blogg, MariaDB Cluster, precis som alla andra Galera-baserat kluster, kommer att påverkas av den höga latensen. Med det sagt är det helt acceptabelt att köra den i "inte så hög" latensmiljöer och förvänta sig att den beter sig korrekt och ger acceptabel prestanda. Allt beror på nätverkets genomströmning och design, avståndet mellan datacenter och applikationskrav. Ett sådant tillvägagångssätt kommer att fungera utmärkt, särskilt om vi använder segment för att särskilja separata datacenter. Det gör det möjligt för MariaDB Cluster att optimera sin intraklusteranslutning och minska likströmsöverskridande trafik till ett minimum.
Den största fördelen med denna installation är att den förlitar sig på MariaDB Cluster för att hantera fel. Om du använder tre datacenter är du ganska täckt mot situationen med split-brain – så länge det finns en majoritet kommer den att fortsätta att fungera. Det är inte nödvändigt att ha en fullvärdig nod i det tredje datacentret - du kan likaväl använda Galera Arbitrator, en demon som fungerar som en del av klustret men den behöver inte hantera några databasoperationer. Den ansluter till noderna, deltar i kvorumberäkningen och kan användas för att vidarebefordra trafiken om den direkta förbindelsen mellan de två datacentren inte skulle fungera.
I så fall kan hela failover-processen beskrivas som:definiera alla noder i belastningsutjämnarna (alla om datacenter är nära varandra, i andra fall kanske du vill lägga till en viss prioritet för noder som ligger närmare lastbalanseraren) och det är i stort sett allt. MariaDB Cluster noder som utgör majoriteten kommer att vara tillgängliga via vilken proxy som helst.
Distribuera ett MariaDB-kluster med flera moln med ClusterControl
Låt oss ta en titt på två alternativ som du kan använda för att distribuera flera moln MariaDB-kluster med ClusterControl. Tänk på att ClusterControl kräver SSH-anslutning till alla noder som den kommer att hantera så det är upp till dig att säkerställa nätverksanslutning mellan flera datacenter eller molnleverantörer. Så länge anslutningen finns kan vi fortsätta med två metoder.
Distribuera MariaDB-kluster med asynkron replikering
ClusterControl kan hjälpa dig att distribuera två kluster anslutna med asynkron replikering. När du har ett enda MariaDB-kluster utplacerat vill du säkerställa att en av noderna har binära loggar aktiverade. Detta gör att du kan använda den noden som en master för det andra klustret som vi kommer att skapa inom kort.
När den binära loggen har aktiverats kan vi använda Jobbet Skapa slavkluster för att starta distributionsguiden.
Vi kan antingen strömma data direkt från mastern eller så kan du använda en av säkerhetskopiorna för att tillhandahålla data.
Sedan presenteras du med en standard klusterdistributionsguide där du måste passera SSH-anslutningsinformation.
Du kommer att bli ombedd att välja leverantör och version av databaserna också som bad om lösenordet för root-användaren.
Slutligen ombeds du att definiera noder som du vill lägga till i kluster och du är klar.
När den distribueras kommer du att se den på listan över klustren i ClusterControl UI.
Distribuera Multi-Cloud MariaDB Cluster
Som vi nämnde tidigare skulle ett annat alternativ för att distribuera MariaDB Cluster vara att använda separata segment när du lägger till noder i klustret. I ClusterControl-gränssnittet hittar du alternativet "Lägg till nod":
När du använder den kommer du att se följande skärm:
Standardsegmentet är 0 så du vill ändra det till ett annat värde .
Efter att noder har lagts till kan du kontrollera i vilket segment de finns genom att titta på fliken Översikt:
Slutsats
Vi hoppas att den här korta bloggen gav dig en bättre förståelse för de alternativ du har för multimoln MariaDB Cluster-distributioner och hur de kan användas för att säkerställa hög tillgänglighet för din databasinfrastruktur.