I den tidigare bloggen i serien diskuterade vi fördelarna och nackdelarna med att använda Galera Cluster för att skapa geodistribuerade kluster. I det här inlägget kommer vi att designa ett Galera-baserat geodistribuerat kluster och vi kommer att visa hur du kan distribuera alla nödvändiga delar med ClusterControl.
Designa ett geodistribuerat Galera-kluster
Vi börjar med att förklara miljön vi vill bygga. Vi kommer att använda tre fjärrdatacenter, anslutna via Wide Area Network (WAN). Varje datacenter kommer att ta emot skrivningar från lokala applikationsservrar. Läsningen kommer också att vara endast lokal. Detta är avsett att undvika onödig trafik som korsar WAN.
För den här installationen är anslutningen på plats och säker, men vi kommer inte att beskriva exakt hur detta kan uppnås. Det finns många metoder för att säkra anslutningen från proprietära hårdvaru- och mjukvarulösningar via OpenVPN och slutar på SSH-tunnlar.
Vi kommer att använda ProxySQL som en lastbalanserare. ProxySQL kommer att distribueras lokalt i varje datacenter. Det kommer också att dirigera trafik endast till de lokala noderna. Fjärrnoder kan alltid läggas till manuellt och vi kommer att förklara fall där detta kan vara en bra lösning. Applikationen kan konfigureras för att ansluta till en av de lokala ProxySQL-noderna med hjälp av round-robin-algoritm. Vi kan lika gärna använda Keepalved och Virtual IP för att dirigera trafiken mot den enda ProxySQL-noden, så länge som en enda ProxySQL-nod skulle kunna hantera all trafik.
En annan möjlig lösning är att samlokalisera ProxySQL med applikationsnoder och konfigurera applikationen att ansluta till proxyn på den lokala värden. Detta tillvägagångssätt fungerar ganska bra under antagandet att det är osannolikt att ProxySQL inte kommer att vara tillgänglig men applikationen skulle fungera ok på samma nod. Det vi ser är vanligtvis nodfel eller nätverksfel, vilket skulle påverka både ProxySQL och applikation samtidigt.
Diagrammet ovan visar versionen av miljön, där ProxySQL är samlokaliserat på samma nod som applikationen. ProxySQL är konfigurerat för att fördela arbetsbelastningen över alla Galera-noder i det lokala datacentret. En av dessa noder skulle väljas som en nod att skicka skrivningarna till medan SELECT:er skulle distribueras över alla noder. Att ha en dedikerad skribentnod i ett datacenter hjälper till att minska antalet möjliga certifieringskonflikter, vilket vanligtvis leder till bättre prestanda. För att minska detta ytterligare skulle vi behöva börja skicka trafiken över WAN-anslutningen, vilket inte är idealiskt eftersom bandbreddsutnyttjandet skulle öka avsevärt. Just nu, med segment på plats, skickas bara två kopior av skrivuppsättningen över datacenter - en per DC.
Det största problemet med Galera Cluster geodistribuerade distributioner är latens. Detta är något du alltid måste testa innan du lanserar miljön. Är jag ok med engagemanget? Vid varje commit måste certifiering ske så skrivuppsättningar måste skickas och certifieras på alla noder i klustret, inklusive fjärranslutna. Det kan vara så att den höga fördröjningen kommer att anse att installationen är olämplig för din applikation. I så fall kan du hitta flera Galera-kluster anslutna via asynkron replikering mer lämpliga. Detta skulle dock vara ett ämne för ett annat blogginlägg.
Distribuera ett geodistribuerat Galera-kluster med ClusterControl
För att förtydliga saker och ting kommer vi att visa här hur en implementering kan se ut. Vi kommer inte att använda faktiska multi-DC-installationer, allt kommer att distribueras i ett lokalt labb. Vi antar att latensen är acceptabel och att hela installationen är genomförbar. Det som är bra med ClusterControl är att det är infrastrukturagnostiskt. Det bryr sig inte om noderna är nära varandra, placerade i samma datacenter eller om noderna är fördelade över flera molnleverantörer. Så länge det finns SSH-anslutning från ClusterControl-instansen till alla noder ser distributionsprocessen exakt likadan ut. Det är därför vi kan visa det för dig steg för steg med hjälp av lokalt labb.
Installera ClusterControl
Först måste du installera ClusterControl. Du kan ladda ner det gratis. Efter registrering bör du komma åt sidan med guide för att ladda ner och installera ClusterControl. Det är lika enkelt som att köra ett skalskript. När du har installerat ClusterControl kommer du att få ett formulär för att skapa en administrativ användare:
När du har fyllt i den kommer du att presenteras med en välkomstskärm och åtkomst till distributionsguider:
Vi fortsätter att implementera. Detta öppnar en distributionsguide:
Vi kommer att välja MySQL Galera. Vi måste skicka SSH-anslutningsdetaljer - antingen root-användare eller sudo-användare stöds. I nästa steg ska vi definiera servrar i klustret.
Vi kommer att distribuera tre noder i ett av datacentren. Då kommer vi att kunna utöka klustret och konfigurera nya noder i olika segment. Just nu behöver vi bara klicka på "Deploy" och se ClusterControl distribuera Galera-klustret.
Våra tre första noder är igång, vi kan nu fortsätta med att lägga till ytterligare noder i andra datacenter.
Du kan göra det från åtgärdsmenyn, som visas på skärmdumpen ovan .
Här kan vi lägga till ytterligare noder, en i taget. Vad som är viktigt, du bör ändra Galera-segmentet till icke-noll (0 används för de första tre noderna).
Efter ett tag har vi alla nio noder, fördelade på tre segment.
Nu måste vi distribuera proxylager. Vi kommer att använda ProxySQL för det. Du kan distribuera den i ClusterControl via Manage -> Load Balancer:
Detta öppnar ett distributionsfält:
Först måste vi bestämma var ProxySQL ska distribueras. Vi kommer att använda befintliga Galera-noder men du kan skriva vad som helst i fältet så det är fullt möjligt att distribuera ProxySQL ovanpå applikationsnoderna. Dessutom måste du skicka åtkomstuppgifter för administratörs- och övervakningsanvändaren.
Då måste vi antingen välja en av befintliga användare i MySQL eller skapa en just nu. Vi vill också säkerställa att ProxySQL är konfigurerad för att använda Galera-noder som endast finns i samma datacenter.
När du har en ProxySQL redo i datacentret kan du använda den som en källa för konfigurationen:
Detta måste upprepas för varje applikationsserver som du har i alla datacenter . Sedan måste applikationen konfigureras för att ansluta till den lokala ProxySQL-instansen, helst över Unix-uttaget. Detta kommer med bästa prestanda och lägsta latens.
När den senaste ProxySQL har distribuerats är vår miljö redo. Applikationsnoder ansluter till lokal ProxySQL. Varje ProxySQL är konfigurerad att fungera med Galera-noder i samma datacenter:
Slutsats
Vi hoppas att den här tvådelade serien hjälpte dig att förstå styrkorna och svagheterna hos geodistribuerade Galera-kluster och hur ClusterControl gör det mycket enkelt att distribuera och hantera ett sådant kluster.