Hoe de prestaties van ClusterControl en zijn componenten te optimaliseren

Bewaking en beheer zijn van cruciaal belang voor elke productieomgeving, omdat prestaties ertoe doen. Trage gebruikersinterfaces die achterblijven of niet reageren, vertraagde waarschuwingen en time-outs van clustertaken wanneer de server geen bronnen meer heeft, zijn allemaal dingen die problemen kunnen veroorzaken. Er zijn manieren om de prestaties van ClusterControl te verbeteren, vooral als u meerdere clusters beheert en elk cluster meerdere knooppunten bevat. In deze blog vind je enkele tuningtips. De punten die hier worden uitgewerkt, zijn samengesteld op basis van onze ervaring met prestatieproblemen die zijn gemeld door onze gebruikers en klanten.

ClusterControl bestaat ter introductie uit een aantal hoofdcomponenten:een webapplicatie (frontend) op basis van PHP en een aantal gedemoniseerde processen (backend). Deze maken gebruik van een MySQL/MariaDB-database voor permanente opslag. U bestuurt uw cluster effectief vanuit de webtoepassing, wat wordt vertaald naar een reeks procesaanroepen die worden uitgevoerd door de backend-processen om uw databaseclusters te beheren en te bewaken.

MySQL-database

ClusterControl-componenten vertrouwen op een MySQL- of MariaDB-database als de permanente opslag voor het bewaken van gegevens die zijn verzameld van de beheerde knooppunten en alle ClusterControl-metadata (bijv. welke taken er in de wachtrij staan, back-upschema's, back-upstatussen, enzovoort.). Standaard installeert het installatiescript elke versie die door de standaardrepository van het besturingssysteem wordt geleverd. Het volgende is de MySQL/MariaDB-versie die door het installatieprogramma wordt geïnstalleerd:

• CentOS/Redhat 6 - MySQL 5.1

• CentOS/Redhat 7 - MariaDB 5.5

• Ubuntu 18.04 (Bionic) - MySQL 5.7

• Ubuntu 16.04 (Xenial) - MySQL 5.7

• Ubuntu 14.04 (Trusty) - MySQL 5.5

• Debian 9 (Stretch) - MySQL 5.5

• Debian 8 (Jessie) - MySQL 5.5

• Debian 7 (Wheezy) - MySQL 5.5

Het installatiescript zou wat basisaanpassingen doen, zoals het configureren van de datadir-locatie, MySQL-poort, gebruiker en de grootte van de InnoDB-bufferpool aan het begin van de installatiefase. De afstemming is echter mogelijk niet geschikt als u meer clusters/knooppunten hebt geïmporteerd of gemaakt. Met een groter aantal knooppunten dat moet worden bewaakt en beheerd, zou ClusterControl meer bronnen gebruiken, en de databaselaag is vaak het eerste knelpunt dat gebruikers tegenkomen. Er kan wat meer afstemming nodig zijn om de inkomende lading te bevatten.

ClusterControl is slim genoeg om prestatieafwijkingen te detecteren door de volgende regels in cmon_X.log te schrijven (waarbij X de cluster-ID is):

2018-11-28 01:30:00 : (INFO) CmonSheetManager at 0x3839af0 loaded 70 values for key 'diskstat' between 2018-11-23 01:30:00 - 2018-11-28 01:30:0
0.
2018-11-28 01:30:00 : (INFO) SQL processing: 220.0000ms
2018-11-28 01:30:00 : (INFO) Parsing       : 0.0000ms
2018-11-28 01:30:00 : (INFO) Sum           : 220.0000ms

Het bovenstaande betekent eenvoudigweg dat het 220 ms (somwaarde) kostte om 70 waarden te laden voor component "diskstat", waarbij de meeste verwerkingstijd plaatsvond in de SQL-verwerkingsfase en 0 ms om de SQL-resultatenset te ontleden Dit concludeert dat de SQL-laag de meeste verwerkingstijd in beslag nam toen ClusterControl probeerde de dataset te doorzoeken.

We zijn van mening dat de meeste SQL-query's die door ClusterControl worden uitgevoerd, correct zijn geoptimaliseerd voor een enkele MySQL-instantie en de juiste indexering gebruiken. Simpel gezegd, als je zoiets als het bovenstaande regelmatig in het logbestand ziet verschijnen, zijn enkele verbeteringen aan de databaselaag op zijn plaats, zoals weergegeven in de volgende secties.

InnoDB-bufferpoolgrootte afstemmen

De grootte van de bufferpool is een belangrijk onderdeel en moet vooraf worden geconfigureerd om de MySQL-prestaties te verbeteren. Hierdoor kan MySQL-verwerking in het geheugen plaatsvinden in plaats van de schijf te raken. Een eenvoudige vuistregel is om de hitratio van InnoDB te controleren en de volgende regel te zoeken in de sectie BUFFER POOL EN GEHEUGEN:

Buffer pool hit rate 986 / 1000

De hitrate van 986 / 1000 geeft aan dat van de 1000 rij-lezingen, het de rij in RAM 986 keer kon lezen. De overige 14 keer moest het de rij met gegevens van schijf lezen. Simpel gezegd, 1000 / 1000 is de beste waarde die we hier proberen te bereiken, wat betekent dat de veelgebruikte gegevens volledig in het RAM passen.

Het verhogen van de innodb_buffer_pool_size waarde zal veel helpen om meer ruimte te creëren voor MySQL om aan te werken. Zorg er echter van tevoren voor dat u over voldoende RAM-bronnen beschikt. ClusterControl wijst standaard 50% van het RAM-geheugen toe aan de bufferpool. Als de host is toegewezen aan ClusterControl, kunt u deze zelfs naar een hogere waarde, zoals 70%, pushen, op voorwaarde dat u ten minste 2 GB RAM overhoudt voor de OS-processen en caches. Als je niet zoveel kunt toewijzen, is het vergroten van het RAM-geheugen de enige oplossing.

Het wijzigen van deze waarde vereist een MySQL-herstart (ouder dan MySQL 5.7.5), dus de juiste volgorde voor het opnieuw opstarten van de service is:

1. Wijzig de innodb_buffer_pool_size waarde in my.cnf.
2. Stop de CMON-service.
3. Herstart MySQL/MariaDB-service.
4. Start de CMON-service.

Of start de host gewoon opnieuw op als u zich een langere downtime kunt veroorloven.

Max_connections afstemmen

Standaard zal het installatiescript de max_connections-waarde tot 512 configureren. Dit is vrij hoog, hoewel verstandig, aangezien ClusterControl in totaal nauwelijks 200 verbindingen bereikt, tenzij de MySQL-server wordt gedeeld met andere applicaties of u tientallen MySQL-knooppunten hebt die worden gecontroleerd door ClusterControl (we hebben het over 30 knooppunten en meer).

Een hoge max_connections-waarde verspilt bronnen en het aanpassen van de waarde heeft invloed op het maximale geheugen dat is geconfigureerd voor MySQL. Als het groter is dan het systeem-RAM, bestaat de kans dat het MySQL Server-proces wordt beëindigd met een OOM-uitzondering, als alle verbindingen worden gebruikt.

Om dit te controleren, zoekt u gewoon naar de mySQL-status van max_used_connections. Het volgende is het maximale aantal verbindingen ooit bereikt door MySQL op een ClusterControl-knooppunt dat 2 clusters bewaakt met in totaal 6 MySQL-knooppunten:

mysql> SHOW STATUS like 'max_used_connections';
+----------------------+-------+
| Variable_name        | Value |
+----------------------+-------+
| Max_used_connections | 43    |
+----------------------+-------+

Een goede waarde om te beginnen is Max_used_connections x 2, en verhoog deze geleidelijk als de waarde constant groeit. Het wijzigen van de variabele max_connections kan dynamisch worden gedaan via de instructie SET GLOBAL.

MySQL-socketbestand gebruiken

Standaard configureert het installatiescript automatisch de volgende hostwaarde in alle ClusterControl-databaseconfiguratiebestanden:

Het bovenstaande dwingt de MySQL-client om verbinding te maken via TCP-netwerken, net zoals verbinding maken met een externe MySQL-host, hoewel ClusterControl op dezelfde server draait als de MySQL-server. We hebben het met opzet op deze manier geconfigureerd om het installatieproces te vereenvoudigen, aangezien bijna elk OS-platform het MySQL-socketbestand op een andere manier configureert, wat het aantal mislukte installaties aanzienlijk vermindert.

Het wijzigen van de waarde naar "localhost" dwingt de client om in plaats daarvan het MySQL Unix-socketbestand te gebruiken:

Op Unix-gebaseerde systemen behandelen MySQL-programma's de hostnaam localhost speciaal, op een manier die waarschijnlijk anders is dan wat u verwacht in vergelijking met andere netwerkgebaseerde programma's. Voor verbindingen met localhost proberen MySQL-programma's verbinding te maken met de lokale server met behulp van een Unix-socketbestand. Dit gebeurt zelfs als een --port of -P optie wordt gegeven om een ​​poortnummer op te geven.

Het gebruik van het MySQL UNIX-socketbestand is veel veiliger en zal de netwerkoverhead afsnijden. Het wordt altijd aanbevolen via TCP. U moet er echter voor zorgen dat het socketbestand correct is geconfigureerd. Het moet bestaan ​​op de volgende richtlijnen in my.cnf en alle MySQL-optiebestanden op het ClusterControl-knooppunt, bijvoorbeeld:

[mysqld]
socket=/var/lib/mysql/mysql.sock

[client]
socket=/var/lib/mysql/mysql.sock

[mysql]
socket=/var/lib/mysql/mysql.sock

[mysqldump]
socket=/var/lib/mysql/mysql.sock

Het wijzigen van het socketbestand vereist ook een herstart van MySQL en CMON. Als u de "localhost" gebruikt, kunt u enkele extra configuratie-opties toevoegen, zoals skip-networking=1, om te voorkomen dat externe verbindingen worden geaccepteerd. Onze ClusterControl Docker-image gebruikt deze benadering om een ​​beperking in docker-proxy te overwinnen bij het binden op poorten.

OpenSSH met SSSD

ClusterControl gebruikt het SSH-protocol als het belangrijkste communicatiekanaal voor het beheren en bewaken van externe knooppunten. De standaard OpenSSH-configuraties zijn behoorlijk behoorlijk en zouden in de meeste gevallen moeten werken. In sommige omgevingen waar SSH is geïntegreerd met andere beveiligingsverbeteringstools zoals SElinux of System Security Services Daemon (SSSD), kan dit echter een aanzienlijke impact hebben op de SSH-prestaties.

We hebben veel gevallen gezien waarin een steeds groter aantal SSH-verbindingen tot stand werd gebracht met elk van de beheerde knooppunten en uiteindelijk, zowel de ClusterControl-server als alle beheerde knooppunten, hun systeemgeheugen maximaal benutten met SSH-verbindingen. In sommige gevallen kan alleen een normale volledige herstart van het systeem 's nachts op de ClusterControl-server het probleem oplossen.

Als u uw infrastructuur uitvoert met System Security Services Daemon (SSSD), is het raadzaam om de volgende regel in de OpenSSH-clientconfiguratie op /etc/ssh/ssh_config op het ClusterControl-knooppunt te plaatsen:

#ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h

Het bovenstaande slaat het gebruik van SSSD over om de hostsleutel te beheren, die in plaats daarvan door de OpenSSH-client zal worden afgehandeld.

Vanaf ClusterControl 1.7.0 heeft u de mogelijkheid om een ​​op agenten gebaseerde monitoringtool te gebruiken met Prometheus. Met agentgebaseerde monitoring gebruikt ClusterControl geen SSH om hoststatistieken te testen, wat in sommige omgevingen buitensporig kan zijn.

Bestandssysteem en partitionering

De ClusterControl-controller schrijft bijna elke seconde voor elk cluster een nieuw item in zijn logbestand. Voor degenen die willen profiteren van deze sequentiële schrijfacties op schijf en kosten willen besparen, kunt u hiervoor een spindelschijf gebruiken. Wijzig de volgende regel binnen alle cmon_X.cnf:

logfile=/new/partition/log/cmon_X.log

Vervang X door de cluster-ID en start de CMON-service opnieuw om de wijzigingen toe te passen.

Als u ClusterControl als back-uprepository gebruikt, is het raadzaam om voldoende schijfruimte toe te wijzen aan een aparte partitie anders dan de rootpartitie. Het wordt beter als de partitie zich op een netwerk- of geclusterd bestandssysteem bevindt voor eenvoudige montage met de beoogde knooppunten bij het uitvoeren van herstelbewerkingen. We hebben gevallen gezien waarin de gemaakte back-ups alle schijfruimte van de hoofdpartitie opslokten, wat uiteindelijk gevolgen had voor ClusterControl en zijn componenten.

Blijf op de hoogte

ClusterControl heeft een korte releasecyclus - elk kwartaal minstens één nieuwe grote release plus wekelijkse onderhoudspatches (meestal bugfixes - indien aanwezig). De reden is dat ClusterControl meerdere databaseleveranciers en -versies, besturingssystemen en hardwareplatforms ondersteunt. Er worden vaak nieuwe dingen geïntroduceerd en oude dingen worden afgeschaft. ClusterControl moet gelijke tred houden met alle veranderingen die door applicatieleveranciers worden geïntroduceerd en elke keer de best-practice volgen.

We raden gebruikers aan om altijd de nieuwste versie van ClusterControl te gebruiken (upgraden is eenvoudig) samen met de nieuwste webbrowser (gebouwd en getest op Google Chrome en Mozilla Firefox), aangezien we zeer waarschijnlijk profiteren van de nieuwe functies die beschikbaar zijn in de nieuwste versie.

Laatste gedachten

Als u vragen heeft of problemen of traagheidsproblemen ondervindt bij het gebruik van ClusterControl, neem dan contact met ons op via ons ondersteuningskanaal. Suggesties en feedback zijn zeer welkom.

Veel plezier met afstemmen!