Hybride omgevingen, waar een deel van de database-infrastructuur zich op locatie bevindt en een deel in een openbare cloud, zijn niet ongewoon. Er kunnen verschillende redenen zijn om een dergelijke configuratie te gebruiken:schaalbaarheid, flexibiliteit, hoge beschikbaarheid, noodherstel. Hoe implementeer je deze setup op een goede manier? Dit kan een uitdaging zijn, omdat je verschillende puzzelstukjes moet overwegen die in elkaar moeten passen. Deze blog is bedoeld om je inzicht te geven in hoe zo'n opstelling eruit kan zien.
Connectiviteit
We gaan hier niet in op details, omdat er veel manieren zijn om een verbinding tot stand te brengen tussen uw installatie op locatie en de openbare cloud. Het hangt af van de infrastructuur die u heeft, de openbare cloud die u wilt gebruiken en vele andere factoren. Een reeks opties kan beginnen met BGP-compatibele routers, via hardware VPN, software VPN eindigend op SSH-tunnels als een manier om uw netwerk tijdelijk te verbinden met de instanties in een openbare cloud. Wat belangrijk is, wat u ook gaat doen, het uiteindelijke resultaat moet een volledige en transparante connectiviteit zijn van uw on-premises netwerk naar de instanties in de openbare cloud.
Overwegingen voor hoge beschikbaarheid
MySQL-replicatie is een geweldige manier om systemen met hoge beschikbaarheid te bouwen, maar er zijn aanzienlijke beperkingen. Het belangrijkste om te overwegen is de schrijver - u kunt maar één plaats hebben om uw schrijven naar toe te sturen - de meester. Hoe je de hele omgeving ook wilt ontwerpen, je moet goed nadenken over de plaatsing van de master. Hoogstwaarschijnlijk wilt u dat het deel uitmaakt van de omgeving, die de hosts van de toepassing bevat. Laten we de volgende opstelling eens bekijken:
We hebben een installatie op locatie met drie MySQL-knooppunten en twee extra slaves zich in de openbare cloud bevindt en voor het bedrijf fungeert als een noodherstelmiddel, is het vrij duidelijk dat het beschrijfbare knooppunt moet worden samengebracht met de applicatiehosts in het privégedeelte van de cloud. We willen de latentie zo laag mogelijk houden voor de verbindingen die er het meest toe doen.
Dit soort ontwerp is gericht op de beschikbaarheid van de databases - als de knooppunten op prem niet beschikbaar zijn, kunnen applicatiehosts mogelijk verbinding maken met het externe deel van de installatie - databaseknooppunten in de publieke cloud. In het ideale geval zou u hiervoor een soort proxy gebruiken - ProxySQL is een van de oplossingen die de topologie kan volgen en indien nodig opnieuw kan configureren op basis van de bestaande replicatieketen.
Als je meer een actief-actief setup wilt overwegen waarbij je applicatienodes zowel privé als publiek hebt, moet je een aantal compromissen sluiten omdat de schrijfbewerkingen via het WAN moeten worden overgedragen, van de openbare naar de privécloud (of vice versa, als uw hoofdlocatie waar u actief bent in de openbare cloud).
Nogmaals, ProxySQL is de voorkeursproxy. Wat geweldig is, ProxySQL kan worden geconfigureerd als een ProxySQL-cluster, zodat de configuratiewijzigingen die in het ene knooppunt zijn aangebracht, worden gerepliceerd naar de resterende ProxySQL-knooppunten.
Foutafhandeling
Laten we een paar faalscenario's bekijken. Voor alles moeten we in gedachten houden dat asynchrone MySQL-replicatie niet clusterbewust is, daarom is de netwerksplitsing iets dat handmatig moet worden afgehandeld - het is aan de gebruiker om de beslissing te nemen en de schakelaar over te halen om een van de de slaven in de omgeving die beschikbaar is. Het is ook aan de gebruiker om ervoor te zorgen dat de omgeving, die de netwerkverbinding heeft verloren, zich naar behoren zal gedragen en niet zal blijven werken.
Als het privégedeelte van de cloud niet meer beschikbaar is, zoals we eerder vermeldden, is handmatige actie vereist om een van de slaven te promoveren tot een nieuwe master. Vervolgens wordt het verkeer van alle resterende webtoepassingsservers in de openbare cloud, met behulp van lokale ProxySQL, omgeleid naar de nieuwe master en alle resterende slaven. Aan de andere kant, aangezien we drie van de vijf MySQL-knooppunten zijn kwijtgeraakt, willen we de openbare cloudconfiguratie uitbreiden - ClusterControl kan u helpen bij het efficiënt toevoegen van extra knooppunten aan uw cluster.
Een ander scenario kan zijn dat de schrijver is gecrasht terwijl de verbinding tussen onze on-premises installatie en de openbare cloud prima werkt.
In zo'n scenario willen we een van de slaves promoveren om een nieuwe master te worden. Afhankelijk van de vereisten, willen we misschien ook dat de nieuwe master wordt gepromoot tussen knooppunten in een bepaald deel van de omgeving. ClusterControl heeft de mogelijkheid om de knooppunten voor de failover op de witte of zwarte lijst te zetten, zodat u volledige controle heeft over het failoverproces en dat u kunt kiezen welke knooppunten als kandidaten voor een nieuwe master moeten worden beschouwd en in welke volgorde.
We hopen dat deze blog je enig idee heeft gegeven over hoe de hybride cloudconfiguratie voor MySQL-replicatie werkt en hoe deze je kan beschermen in geval van database- of netwerkstoringen.