Het implementeren van een databasecluster is geen rocket science - er zijn veel how-to's om dat te doen. Maar hoe weet u dat wat u zojuist hebt geïmplementeerd, klaar is voor productie? Handmatige implementaties kunnen ook vervelend en repetitief zijn. Afhankelijk van het aantal knooppunten in het cluster, kunnen de implementatiestappen tijdrovend en foutgevoelig zijn. Configuratiebeheertools zoals Puppet, Chef en Ansible zijn populair bij het implementeren van infrastructuur, maar voor stateful databaseclusters moet u aanzienlijke scripts uitvoeren om de implementatie van de hele database HA-stack af te handelen. Bovendien moet de gekozen sjabloon/module/kookboek/rol zorgvuldig worden getest voordat u deze kunt vertrouwen als onderdeel van uw infrastructuurautomatisering. Versiewijzigingen vereisen dat de scripts opnieuw worden bijgewerkt en getest.
Het goede nieuws is dat ClusterControl de implementatie van de hele stack automatiseert - en nog gratis ook! We hebben duizenden productieclusters geïmplementeerd en nemen een aantal voorzorgsmaatregelen om ervoor te zorgen dat ze klaar zijn voor productie. Verschillende topologieën worden ondersteund, van master-slave-replicatie tot Galera-, NDB- en InnoDB-cluster, met daarbovenop verschillende databaseproxy's.
Een high-availability stack, geïmplementeerd via ClusterControl, bestaat uit drie lagen:
- Databaselaag (bijv. Galera-cluster)
- Omgekeerde proxy-laag (bijv. HAProxy of ProxySQL)
- Bewaarde laag, die, met gebruik van Virtual IP, zorgt voor een hoge beschikbaarheid van de proxylaag
In deze blog laten we u zien hoe u een Galera-cluster van productiekwaliteit kunt implementeren, compleet met load balancers voor een installatie met hoge beschikbaarheid. De complete setup bestaat uit 6 hosts:
- 1 host - ClusterControl (implementatie, monitoring, beheerserver)
- 3 hosts - MySQL Galera-cluster
- 2 hosts - Reverse proxy's fungeren als load balancers voor het cluster.
Het volgende diagram illustreert ons eindresultaat zodra de implementatie is voltooid:
Vereisten
ClusterControl moet zich op een onafhankelijk knooppunt bevinden dat geen deel uitmaakt van het cluster. Download ClusterControl en de pagina genereert een unieke licentie voor u en toont de stappen om ClusterControl te installeren:
$ wget -O install-cc https://severalnines.com/scripts/install-cc
$ chmod +x install-cc
$ ./install-cc # as root or sudo userVolg de instructies waar u wordt begeleid bij het instellen van de MySQL-server, het MySQL-rootwachtwoord op het ClusterControl-knooppunt, het cmon-wachtwoord voor het gebruik van ClusterControl enzovoort. U zou de volgende regel moeten krijgen zodra de installatie is voltooid:
Determining network interfaces. This may take a couple of minutes. Do NOT press any key.
Public/external IP => http://{public_IP}/clustercontrol
Installation successful. If you want to uninstall ClusterControl then run install-cc --uninstall.Genereer vervolgens op de ClusterControl-server een SSH-sleutel die we later zullen gebruiken om de wachtwoordloze SSH in te stellen. U kunt elke gebruiker in het systeem gebruiken, maar deze moet de mogelijkheid hebben om supergebruikersbewerkingen (sudoer) uit te voeren. In dit voorbeeld hebben we de rootgebruiker gekozen:
$ whoami
root
$ ssh-keygen -t rsaStel wachtwoordloze SSH in op alle nodes die u wilt bewaken/beheren via ClusterControl. In dit geval zullen we dit instellen op alle knooppunten in de stapel (inclusief ClusterControl-knooppunt zelf). Voer op het ClusterControl-knooppunt de volgende opdrachten uit en geef het root-wachtwoord op wanneer daarom wordt gevraagd:
$ ssh-copy-id [email protected] # clustercontrol
$ ssh-copy-id [email protected] # galera1
$ ssh-copy-id [email protected] # galera2
$ ssh-copy-id [email protected] # galera3
$ ssh-copy-id [email protected] # proxy1
$ ssh-copy-id [email protected] # proxy2U kunt vervolgens controleren of het werkt door de volgende opdracht uit te voeren op het ClusterControl-knooppunt:
$ ssh [email protected] "ls /root"Zorg ervoor dat u het resultaat van de bovenstaande opdracht kunt zien zonder dat u een wachtwoord hoeft in te voeren.
Het cluster implementeren
ClusterControl ondersteunt alle leveranciers van Galera Cluster (Codership, Percona en MariaDB). Er zijn enkele kleine verschillen die van invloed kunnen zijn op uw beslissing om de leverancier te kiezen. Als je meer wilt weten over de verschillen tussen beide, bekijk dan onze vorige blogpost - Galera Cluster Comparison - Codership vs Percona vs MariaDB.
Voor productie-implementatie is een Galera-cluster met drie knooppunten het minimum dat u zou moeten hebben. U kunt het later altijd uitschalen zodra het cluster is geïmplementeerd, handmatig of via ClusterControl. We openen onze ClusterControl-gebruikersinterface op https://192.168.55.160/clustercontrol en maken de eerste admin-gebruiker aan. Ga dan naar het hoofdmenu en klik op Deploy -> MySQL Galera en u krijgt het volgende dialoogvenster te zien:
Er zijn twee stappen, de eerste is de "Algemene &SSH-instellingen". Hier moeten we de SSH-gebruiker configureren die ClusterControl moet gebruiken om verbinding te maken met de databaseknooppunten, samen met het pad naar de SSH-sleutel (zoals gegenereerd in het gedeelte Vereisten) en de SSH-poort van de databaseknooppunten. ClusterControl gaat ervan uit dat alle databaseknooppunten zijn geconfigureerd met dezelfde SSH-gebruiker, -sleutel en -poort. Geef het cluster vervolgens een naam, in dit geval gebruiken we "MySQL Galera Cluster 5.7". Deze waarde kan later worden gewijzigd. Selecteer vervolgens de opties om ClusterControl opdracht te geven de vereiste software te installeren, de firewall uit te schakelen en ook de beveiligingsverbeteringsmodule op de betreffende Linux-distributie uit te schakelen. Het wordt aanbevolen om deze allemaal in te schakelen om het potentieel van een succesvolle implementatie te maximaliseren.
Klik op Doorgaan en u krijgt het volgende dialoogvenster te zien:
In de volgende stap moeten we de databaseservers configureren - leverancier, versie, datadir, poort, enz. - die vrij duidelijk zijn. "Configuratiesjabloon" is de sjabloonbestandsnaam onder /usr/share/cmon/templates van het ClusterControl-knooppunt. "Repository" is hoe ClusterControl de repository op het databaseknooppunt moet configureren. Standaard gebruikt het de repository van de leverancier en installeert het de nieuwste versie die door de repository wordt geleverd. In sommige gevallen kan de gebruiker echter een reeds bestaande repository hebben die wordt gespiegeld vanuit de originele repository vanwege een beperking van het beveiligingsbeleid. Niettemin ondersteunt ClusterControl de meeste ervan, zoals beschreven in de gebruikershandleiding, onder Repository.
Voeg ten slotte het IP-adres of de hostnaam toe (moet een geldige FQDN zijn) van de databaseknooppunten. U ziet een groen vinkje aan de linkerkant van het knooppunt, wat aangeeft dat ClusterControl verbinding kon maken met het knooppunt via SSH zonder wachtwoord. Je bent nu klaar om te gaan. Klik op Implementeren om de implementatie te starten. Dit kan 15 tot 20 minuten duren. U kunt de voortgang van de implementatie volgen onder Activiteit (bovenste menu) -> Taken -> Cluster maken :
Zodra de implementatie is voltooid, kan onze architectuur op dit moment als volgt worden geïllustreerd:
De Load Balancers inzetten
In Galera Cluster zijn alle knooppunten gelijk - elk knooppunt heeft dezelfde rol en dezelfde dataset. Daarom is er geen failover binnen het cluster als een knoop punt uitvalt. Alleen de toepassingszijde vereist een failover om de niet-operationele knooppunten over te slaan terwijl het cluster is gepartitioneerd. Daarom wordt het ten zeerste aanbevolen om load balancers bovenop een Galera-cluster te plaatsen om:
- Verenig de meerdere database-eindpunten tot één enkel eindpunt (load balancer-host of virtueel IP-adres als eindpunt).
- Baliseer de databaseverbindingen tussen de backend-databaseservers.
- Voer gezondheidscontroles uit en stuur de databaseverbindingen alleen door naar gezonde knooppunten.
- Redirect/herschrijf/blokkeer aanstootgevende (slecht geschreven) query's voordat ze de databaseservers bereiken.
Er zijn drie hoofdkeuzes van reverse proxy's voor Galera Cluster - HAProxy, MariaDB MaxScale of ProxySQL - ze kunnen allemaal automatisch worden geïnstalleerd en geconfigureerd door ClusterControl. In deze implementatie hebben we ProxySQL gekozen omdat het al het bovenstaande controleert en het MySQL-protocol van de backend-servers begrijpt.
In deze architectuur willen we twee ProxySQL-servers gebruiken om single-point-of-failure (SPOF) naar de databaselaag te elimineren, die aan elkaar wordt gekoppeld met behulp van een zwevend virtueel IP-adres. We zullen dit in de volgende sectie uitleggen. Het ene knooppunt fungeert als de actieve proxy en het andere als hot-standby. Het knooppunt dat op een bepaald moment het virtuele IP-adres bevat, is het actieve knooppunt.
Om de eerste ProxySQL-server te implementeren, gaat u naar het clusteractiemenu (rechterkant van de overzichtsbalk) en klikt u op Load Balancer toevoegen -> ProxySQL -> ProxySQL implementeren en je zult het volgende zien:
Nogmaals, de meeste velden spreken voor zich. In de sectie "Databasegebruiker" fungeert ProxySQL als een gateway waarmee uw toepassing verbinding maakt met de database. De toepassing authenticeert zich tegen ProxySQL, daarom moet u alle gebruikers van alle backend MySQL-knooppunten, samen met hun wachtwoorden, toevoegen aan ProxySQL. Vanuit ClusterControl kunt u ofwel een nieuwe gebruiker maken die door de toepassing moet worden gebruikt - u kunt beslissen over de naam, het wachtwoord, de toegang tot welke databases worden verleend en welke MySQL-rechten die gebruiker heeft. Een dergelijke gebruiker wordt zowel aan de MySQL- als aan de ProxySQL-kant gemaakt. Tweede optie, meer geschikt voor bestaande infrastructuren, is om de bestaande databasegebruikers te gebruiken. U moet een gebruikersnaam en wachtwoord doorgeven, en een dergelijke gebruiker wordt alleen op ProxySQL aangemaakt.
De laatste sectie, "Impliciete transactie", zal ClusterControl ProxySQL configureren om al het verkeer naar de master te sturen als we de transactie starten met SET autocommit=0. Anders, als u BEGIN of START TRANSACTIE gebruikt om een transactie aan te maken, zal ClusterControl de lees-/schrijfsplitsing configureren in de queryregels. Dit is om ervoor te zorgen dat ProxySQL transacties correct afhandelt. Als je geen idee hebt hoe je applicatie dit doet, kun je het laatste kiezen.
Herhaal dezelfde configuratie voor het tweede ProxySQL-knooppunt, behalve de waarde "Serveradres" die 192.168.55.182 is. Als u klaar bent, worden beide knooppunten vermeld onder het tabblad "Knooppunten" -> ProxySQL, waar u ze rechtstreeks vanuit de gebruikersinterface kunt controleren en beheren:
Op dit moment ziet onze architectuur er nu als volgt uit:
Als je meer wilt weten over ProxySQL, bekijk dan deze tutorial - Database Load Balancing voor MySQL en MariaDB met ProxySQL - Tutorial.
Het virtuele IP-adres implementeren
Het laatste deel is het virtuele IP-adres. Zonder dit zouden onze load balancers (reverse proxy's) de zwakke schakel zijn, omdat ze een single-point of failure zouden zijn - tenzij de toepassing de mogelijkheid heeft om mislukte databaseverbindingen automatisch om te leiden naar een andere load balancer. Desalniettemin is het een goede gewoonte om ze allebei te verenigen met behulp van een virtueel IP-adres en het verbindingseindpunt met de databaselaag te vereenvoudigen.
Van ClusterControl UI -> Load Balancer toevoegen -> Keepalive -> Keepalive implementeren en selecteer de twee ProxySQL-hosts die we hebben geïmplementeerd:
Geef ook het virtuele IP-adres en de netwerkinterface op om het IP-adres te binden. De netwerkinterface moet op beide ProxySQL-knooppunten aanwezig zijn. Eenmaal geïmplementeerd, zou u de volgende groene vinkjes moeten zien in de overzichtsbalk van het cluster:
Op dit punt kan onze architectuur als volgt worden geïllustreerd:
Ons databasecluster is nu klaar voor productiegebruik. U kunt uw bestaande database erin importeren of een nieuwe nieuwe database maken. U kunt de functie Schema's en gebruikersbeheer gebruiken als de proeflicentie niet is verlopen.
Om te begrijpen hoe ClusterControl Keepalive configureert, lees je deze blogpost, Hoe ClusterControl Virtual IP configureert en wat je kunt verwachten tijdens failover.
Verbinding maken met het databasecluster
Vanuit het oogpunt van de toepassing en de klant moeten ze verbinding maken met 192.168.55.180 op poort 6033, het virtuele IP-adres dat boven op de load balancers zweeft. De configuratie van de Wordpress-database ziet er bijvoorbeeld ongeveer zo uit:
/** The name of the database for WordPress */
define( 'DB_NAME', 'wp_myblog' );
/** MySQL database username */
define( 'DB_USER', 'wp_myblog' );
/** MySQL database password */
define( 'DB_PASSWORD', 'mysecr3t' );
/** MySQL hostname - virtual IP address with ProxySQL load-balanced port*/
define( 'DB_HOST', '192.168.55.180:6033' );Als u rechtstreeks toegang wilt krijgen tot het databasecluster en de load balancer wilt omzeilen, kunt u gewoon verbinding maken met poort 3306 van de databasehosts. Dit is meestal vereist door het DBA-personeel voor administratie, beheer en probleemoplossing. Met ClusterControl kunnen de meeste van deze bewerkingen rechtstreeks vanuit de gebruikersinterface worden uitgevoerd.
Laatste gedachten
Zoals hierboven weergegeven, is het implementeren van een databasecluster niet langer een moeilijke taak. Eenmaal geïmplementeerd, is er een volledige reeks gratis bewakingsfuncties en commerciële functies voor back-upbeheer, failover/herstel en andere. Snelle implementatie van verschillende typen cluster-/replicatietopologieën kan handig zijn bij het evalueren van databaseoplossingen met hoge beschikbaarheid en hoe deze passen in uw specifieke omgeving.