Loadbalancers zijn een essentieel onderdeel van elke databaseconfiguratie met hoge beschikbaarheid. Ze worden gebruikt om de capaciteit en betrouwbaarheid van uw kritieke systemen en applicaties te vergroten door te voorkomen dat één server overbelast raakt. We praten er veel over op de blog van Verschillendenines, zoals waarom je ze nodig hebt en hoe ze werken. Een van de meest populaire load balancers die beschikbaar is voor MySQL en MariaDB is HAProxy.
Qua functionaliteit is HAProxy niet vergelijkbaar met ProxySQL of MaxScale. HAProxy is echter een snelle, robuuste load balancer die prima werkt in elke omgeving, zolang de toepassing de lees-/schrijfsplitsing kan uitvoeren en SELECT-query's naar één backend kan sturen en alle schrijfbewerkingen en SELECT...FOR UPDATE naar een aparte backend.
Het bijhouden van alle statistieken die beschikbaar worden gesteld door HAProxy is erg belangrijk; je moet de status van je proxy weten, vooral om te weten of je problemen hebt ondervonden.
ClusterControl heeft altijd een HAProxy-statuspagina beschikbaar gesteld die de status van de proxy in realtime toont. Met de nieuwe op Prometheus gebaseerde SCUMM-dashboards (Severalnines ClusterControl Unified Monitoring &Management) is het nu mogelijk om eenvoudig te volgen hoe deze statistieken in de loop van de tijd veranderen.
In deze blogpost worden de verschillende statistieken besproken die worden gepresenteerd in het HAProxy SCUMM-dashboard.
Het HAProxy-dashboard in ClusterControl verkennen
Alle Prometheus- en SCUMM-dashboards zijn standaard uitgeschakeld in ClusterControl. Het is echter slechts een kwestie van één klik om ze voor een bepaald cluster in te zetten. Als u meerdere clusters bewaakt met ClusterControl, kunt u voor elk cluster dezelfde Prometheus-instantie opnieuw gebruiken.
Eenmaal geïmplementeerd, hebt u toegang tot het HAProxy-dashboard. Laten we eens kijken naar de gegevens die beschikbaar zijn in het dashboard:
Het eerste dat u ziet als u naar het HAProxy-dashboard navigeert, is informatie over de staat van uw backends. Houd er rekening mee dat wat u ziet, kan afhangen van het clustertype en hoe u HAProxy hebt geïmplementeerd. In dit geval hebben we een Galera-cluster geïmplementeerd en is HAProxy op een round-robin-manier ingezet. Daarom zie je drie backends voor lezen en drie voor schrijven - zes in totaal. Dit is ook de reden waarom je alle backends ziet gemarkeerd als "Omhoog".
In een scenario met een replicatiecluster zullen de zaken er anders uitzien, aangezien de HAProxy zal worden geïmplementeerd in een lees/schrijf-splitsing, en de scripts zullen slechts één host (master) actief houden in de backend.
Let op, dit is de reden waarom je hieronder twee backend-servers ziet gemarkeerd als "Down":
In de volgende grafiek ziet u de gegevens die door beide zijn verzonden en ontvangen backend (van HAProxy naar de databaseservers) en frontend (tussen HAProxy en clienthosts):
Je kunt ook de verkeersverdeling tussen backends in je HAProxy-configuratie controleren. In dit geval hebben we twee backends en worden de query's verzonden via poort 3308, die fungeert als het round-robin-toegangspunt naar ons Galera-cluster:
Vervolgens kunt u zien hoe het verkeer over alle backend-servers werd verdeeld. In dit scenario - vanwege het round-robin toegangspatroon - waren de gegevens min of meer gelijkmatig verdeeld over alle drie de backend Galera-servers:
Informatie over sessies, inclusief hoeveel sessies zijn geopend van HAProxy naar de backend servers, kunnen ook worden gecontroleerd, zoals te zien is in de volgende grafiek. Je kunt ook bijhouden hoe vaak per seconde een nieuwe sessie naar de backend is geopend en hoe die statistieken er per backendserver uitzien.
De volgende twee grafieken tonen het maximale aantal sessies per backend-server en wanneer verbindingsproblemen verschenen. Dit kan erg handig zijn voor foutopsporingsdoeleinden waarbij u een configuratiefout op uw HAProxy-instantie tegenkomt en verbindingen beginnen te verbreken.
Deze volgende grafiek is potentieel waardevoller omdat hij verschillende meetgegevens toont die verband houden met fouten afhandeling, zoals fouten, verzoekfouten, nieuwe pogingen aan de backend, enz. Er is ook een "Sessies"-grafiek die een overzicht van de sessiestatistieken toont.
Hier kunt u zien dat ClusterControl de verbindingsfouten in realtime bijhoudt, die kan helpen het precieze tijdstip te bepalen waarop de problemen zich begonnen te ontwikkelen.
Ten slotte bekijken we de volgende twee grafieken met betrekking tot verzoeken in de wachtrij . HAProxy plaatst verzoeken in de wachtrij voor de backend als de backendservers oververzadigd zijn. Dit kan bijvoorbeeld wijzen op de overbelaste databaseservers, die geen verkeer meer aankunnen.
Afronden
Door uw HAProxy-load balancer in ClusterControl te implementeren en te bewaken, kunt u uw verbindingen gemakkelijker beheren en bewaken. Een duidelijk inzicht in de prestaties van uw backends, verkeersdistributie, sessiestatistieken, verbindingsfouten en het aantal verzoeken in de wachtrij kan helpen om de beschikbaarheid en schaalbaarheid van elke databaseconfiguratie te garanderen.
ClusterControl maakt het instellen en bewaken van load balancers een fluitje van een cent voor elke databaseconfiguratie. Maakt u nog geen gebruik van ClusterControl? Als u zelf wilt zien hoe eenvoudig het is om uw HAProxy-load balancer te implementeren en te bewaken met ClusterControl, nodigen we u uit voor een gratis proefperiode van 30 dagen van het platform, zonder verplichtingen. Bekijk onze tutorial over MySQL-taakverdeling met HAProxy voor een meer gedetailleerde uitleg over waarom en hoe u HAProxy gebruikt voor taakverdeling.