Hybride miljøer, hvor en del af databaseinfrastrukturen er placeret on-prem, og noget af det er placeret i en offentlig sky, er ikke ualmindeligt. Der kan være forskellige grunde til at bruge en sådan opsætning - skalerbarhed, fleksibilitet, høj tilgængelighed, katastrofegendannelse. Hvordan implementerer man denne opsætning på en ordentlig måde? Dette kan være udfordrende, da du skal overveje flere brikker i et puslespil, der skal passe sammen. Denne blog er beregnet til at give dig lidt indsigt i, hvordan sådan en opsætning kan se ud.
Forbindelse
Vi går ikke i detaljer her, fordi der er mange måder at konfigurere forbindelse mellem din lokale opsætning og den offentlige sky. Det vil afhænge af den infrastruktur, du har på plads, den offentlige sky, du vil bruge, og mange andre faktorer. En række muligheder kan starte med BGP-aktiverede routere, gennem hardware-VPN, software-VPN, der ender på SSH-tunneler som en måde at midlertidigt forbinde dit netværk til instanserne i en offentlig sky. Hvad der er vigtigt, uanset hvad du skal gøre, bør det endelige resultat være fuld og gennemsigtig forbindelse fra dit lokale netværk til de instanser, der er placeret i den offentlige sky.
Overvejelser om høj tilgængelighed
MySQL-replikering er en fantastisk måde at bygge meget tilgængelige systemer på, men den kommer med betydelige begrænsninger. Det vigtigste at overveje er forfatteren - du kan kun have ét sted at sende dine tekster til - mesteren. Uanset hvordan du vil designe hele miljøet, skal du nøje overveje placeringen af mesteren. Mest sandsynligt ønsker du, at det skal være en del af miljøet, som indeholder applikationsværterne. Lad os overveje følgende opsætning:
Vi har en on-prem opsætning med tre MySQL-noder og to ekstra slaver placeret i den offentlige sky, der fungerer som et katastrofegendannelsesmiddel for virksomheden, er det helt klart, at den skrivbare node skal placeres sammen med applikationsværterne i den private del af skyen. Vi ønsker at holde latensen så lav som muligt for de forbindelser, der betyder mest.
Denne form for design fokuserer på tilgængeligheden af databaserne - hvis noderne placeret på prem ikke vil være tilgængelige, kan applikationsværter muligvis oprette forbindelse til den eksterne del af opsætningen - databasenoder placeret i den offentlige sky. Ideelt set ville du bruge en slags proxy til dette - ProxySQL er en af løsningerne, der kan spore topologien og omkonfigurere efter behov baseret på den eksisterende replikeringskæde.
Hvis du vil overveje mere af en aktiv-aktiv opsætning, hvor du har applikationsknudepunkter på tværs af både private og offentlige, er du nødt til at indgå nogle kompromiser, da skrivningerne skal overføres over WAN, fra den offentlige til den private sky (eller omvendt, hvis din primære placering, hvor du opererer i den offentlige sky).
Igen, ProxySQL er den foretrukne proxy. Hvad der er fantastisk, ProxySQL kan konfigureres som en ProxySQL-klynge, hvilket sikrer, at de konfigurationsændringer, der er introduceret i den ene node, vil blive replikeret på tværs af resterende ProxySQL-noder.
Fejlhåndtering
Lad os overveje et par fejlscenarier. Før noget skal vi huske på, at MySQL asynkron replikering ikke er klyngebevidst, derfor er netværksopdelingen noget, der skal håndteres manuelt - det vil være op til brugeren at træffe beslutningen og trække kontakten for at fremme en af slaverne i det miljø, der er til rådighed. Det er også op til brugeren at sikre, at miljøet, der har mistet netværksforbindelsen, vil opføre sig, som det skal, og det vil ikke fortsætte med at fungere.
Hvis den private del af skyen bliver utilgængelig, som vi nævnte tidligere, vil manuel handling være påkrævet for at fremme en af slaverne til at blive en ny mester. Derefter vil alle resterende webapplikationsservere, der er placeret i den offentlige sky, ved hjælp af lokal ProxySQL, få deres trafik omdirigeret til den nye master og alle resterende slaver. På den anden side, da vi mistede tre ud af fem MySQL-noder, ønsker vi at skalere den offentlige cloud-opsætning ud - ClusterControl kan hjælpe dig med effektivt at tilføje yderligere noder til din klynge.
Et andet scenario kan være, at forfatteren er gået ned, mens forbindelsen mellem vores lokale opsætning og den offentlige sky fungerer fint.
I et sådant scenarie ønsker vi at fremme en af slaverne til at blive en ny mester. Afhængigt af kravene kan vi også ønske, at den nye master skal fremmes mellem noder i en given del af miljøet. ClusterControl har mulighed for at hvidliste eller sortliste noderne til failover, hvilket sikrer, at du har fuld kontrol over failover-processen, og at du kan vælge, hvilke noder der skal betragtes som kandidater til en ny master og i hvilken rækkefølge.
Vi håber, at denne blog gav dig en idé om, hvordan hybrid cloud-opsætningen til MySQL-replikering fungerer, og hvordan den kan beskytte dig i tilfælde af database- eller netværksfejl.