MongoDB
 sql >> Datenbank >  >> NoSQL >> MongoDB

So optimieren Sie die Leistung von ClusterControl und seinen Komponenten

Überwachung und Verwaltung sind für jede Produktionsumgebung von entscheidender Bedeutung, da die Leistung zählt. Langsame Benutzeroberflächen, die verzögern oder nicht reagieren, verzögerte Warnungen und Zeitüberschreitungen von Cluster-Jobs, wenn dem Server die Ressourcen ausgehen, sind alles Dinge, die Probleme verursachen können. Es gibt Möglichkeiten, die Leistung von ClusterControl zu verbessern, insbesondere wenn Sie mehrere Cluster verwalten und jeder Cluster mehrere Knoten enthält. Dieser Blog enthält einige Tuning-Tipps. Die hier ausgearbeiteten Punkte basieren auf unserer Erfahrung im Umgang mit Leistungsproblemen, die von unseren Benutzern und Kunden gemeldet wurden.

Zur Einführung besteht ClusterControl aus mehreren Hauptkomponenten - einer Webanwendung (Frontend) auf Basis von PHP und einer Reihe von daemonisierten Prozessen (Backend). Diese nutzen eine MySQL/MariaDB-Datenbank für die dauerhafte Speicherung. Sie steuern Ihren Cluster effektiv über die Webanwendung, die in eine Reihe von Prozessaufrufen übersetzt wird, die von den Backend-Prozessen ausgeführt werden, um Ihre Datenbankcluster zu verwalten und zu überwachen.

MySQL-Datenbank

ClusterControl-Komponenten verlassen sich auf eine MySQL- oder MariaDB-Datenbank als persistenten Speicher für die Überwachung der von den verwalteten Knoten gesammelten Daten und aller ClusterControl-Metadaten (z. B. welche Jobs sich in der Warteschlange befinden, Backup-Zeitpläne, Backup-Status, etc.). Standardmäßig installiert das Installationsskript jede Version, die aus dem Standard-Repository des Betriebssystems stammt. Das Folgende ist die MySQL/MariaDB-Version, die vom Installer installiert wird:

  • 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

Das Installationsskript würde zu Beginn der Installationsphase einige grundlegende Anpassungen vornehmen, wie z. B. die Konfiguration des Datenverzeichnisses, des MySQL-Ports, des Benutzers und der Größe des InnoDB-Pufferpools. Das Tuning ist jedoch möglicherweise nicht geeignet, wenn Sie weitere Cluster/Knoten importiert oder erstellt haben. Mit einer erhöhten Anzahl von zu überwachenden und zu verwaltenden Knoten würde ClusterControl mehr Ressourcen verbrauchen, und die Datenbankschicht ist normalerweise der erste Engpass, auf den Benutzer stoßen. Möglicherweise ist eine weitere Optimierung erforderlich, um die eingehende Last einzudämmen.

ClusterControl ist intelligent genug, um jede Leistungsanomalie zu erkennen, indem es die folgenden Zeilen in cmon_X.log schreibt (wobei X die Cluster-ID ist):

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

Das obige bedeutet einfach, dass es 220 ms (Summenwert) dauerte, um 70 Werte für die Komponente „diskstat“ zu laden, wobei die meiste Verarbeitungszeit in der SQL-Verarbeitungsphase stattfand, und 0 ms, um die SQL-Ergebnismenge zu analysieren Daraus lässt sich schließen, dass die SQL-Schicht die meiste Verarbeitungszeit in Anspruch nahm, als ClusterControl versuchte, den Datensatz abzufragen.

Wir glauben, dass die meisten von ClusterControl ausgeführten SQL-Abfragen richtig für eine einzelne MySQL-Instanz optimiert sind und die richtige Indizierung verwenden. Einfach gesagt, wenn Sie etwas wie das Obige regelmäßig in der Protokolldatei sehen, sind einige Verbesserungen an der Datenbankschicht angebracht, wie in den folgenden Abschnitten gezeigt wird.

InnoDB-Pufferpoolgröße optimieren

Die Pufferpoolgröße ist eine wichtige Komponente und muss im Voraus konfiguriert werden, um die MySQL-Leistung zu verbessern. Es ermöglicht, dass die MySQL-Verarbeitung im Speicher stattfindet, anstatt auf die Festplatte zu gelangen. Eine einfache Faustregel besteht darin, die InnoDB-Trefferquote zu überprüfen und im Abschnitt BUFFER POOL AND MEMORY nach der folgenden Zeile zu suchen:

Buffer pool hit rate 986 / 1000

Die Trefferquote von 986/1000 zeigt an, dass von 1000 Zeilenlesevorgängen die Zeile im RAM 986 Mal gelesen werden konnte. Die verbleibenden 14 Mal musste es die Datenzeile von der Festplatte lesen. Einfach gesagt, 1000/1000 ist der beste Wert, den wir hier zu erreichen versuchen, was bedeutet, dass die häufig aufgerufenen Daten vollständig in den Arbeitsspeicher passen.

Das Erhöhen des Werts innodb_buffer_pool_size wird viel dazu beitragen, mehr Platz für MySQL zu schaffen. Stellen Sie jedoch vorher sicher, dass Sie über ausreichende RAM-Ressourcen verfügen. Standardmäßig weist ClusterControl dem Pufferpool 50 % des Arbeitsspeichers zu. Wenn der Host für ClusterControl dediziert ist, können Sie ihn sogar auf einen höheren Wert wie 70 % erhöhen, vorausgesetzt, Sie sparen mindestens 2 GB RAM für die Betriebssystemprozesse und Caches. Wenn Sie nicht so viel zuweisen können, ist die Erhöhung des Arbeitsspeichers die einzige Lösung.

Das Ändern dieses Werts erfordert einen MySQL-Neustart (älter als MySQL 5.7.5), daher lautet die korrekte Reihenfolge für den Dienstneustart:

  1. Ändern Sie den Wert innodb_buffer_pool_size in my.cnf.
  2. Beenden Sie den CMON-Dienst.
  3. Starten Sie den MySQL/MariaDB-Dienst neu.
  4. Starten Sie den CMON-Dienst.

Oder starten Sie den Host einfach neu, wenn Sie sich eine längere Ausfallzeit leisten können.

max_connections optimieren

Standardmäßig konfiguriert das Installationsskript max_connections einen Wert von bis zu 512. Dies ist ziemlich hoch, aber vernünftig, da ClusterControl insgesamt kaum 200 Verbindungen erreicht, es sei denn, der MySQL-Server wird mit anderen Anwendungen geteilt oder Sie haben Dutzende von MySQL-Knoten, die von ClusterControl überwacht werden (wir sprechen von 30 Knoten und mehr).

Ein hoher max_connections-Wert verschwendet Ressourcen und eine Anpassung des Werts wirkt sich auf den für MySQL konfigurierten maximalen Arbeitsspeicher aus. Wenn es größer als der System-RAM ist, besteht die Möglichkeit, dass der MySQL Server-Prozess mit einer OOM-Ausnahme beendet wird, wenn alle Verbindungen verwendet werden.

Um dies zu überprüfen, suchen Sie einfach nach dem MySQL-Status max_used_connections. Das Folgende sind die maximalen Verbindungen, die jemals von MySQL auf einem ClusterControl-Knoten erreicht wurden, der 2 Cluster mit insgesamt 6 MySQL-Knoten überwacht:

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

Ein guter Anfangswert ist Max_used_connections x 2, und erhöhen Sie ihn schrittweise, wenn der Wert stetig wächst. Die Änderung der max_connections-Variablen kann dynamisch über die SET GLOBAL-Anweisung erfolgen.

MySQL-Socket-Datei verwenden

Standardmäßig konfiguriert das Installationsskript automatisch den folgenden Hostwert in allen Konfigurationsdateien der ClusterControl-Datenbank:

Konfigurationsdatei Wert
/etc/cmon.cnf mysql_hostname=127.0.0.1
/etc/cmon.d/cmon_X.cnf (X ist die Cluster-ID) mysql_hostname=127.0.0.1
/var/www/html/clustercontrol/bootstrap.php define('DB_HOST', '127.0.0.1');
/var/www/html/cmonapi/config/database.php define('DB_HOST', '127.0.0.1');

Das Obige zwingt den MySQL-Client, sich über ein TCP-Netzwerk zu verbinden, genau wie eine Verbindung zu einem Remote-MySQL-Host, obwohl ClusterControl auf demselben Server wie der MySQL-Server läuft. Wir haben es absichtlich so konfiguriert, um den Installationsprozess zu vereinfachen, da fast jede Betriebssystemplattform die MySQL-Socket-Datei anders vorkonfiguriert, was die Installationsfehlerrate erheblich reduziert.

Wenn Sie den Wert auf „localhost“ ändern, wird der Client gezwungen, stattdessen die MySQL-Unix-Socket-Datei zu verwenden:

Konfigurationsdatei Wert
/etc/cmon.cnf mysql_hostname=localhost
/etc/cmon.d/cmon_X.cnf (X ist die Cluster-ID) mysql_hostname=localhost
/var/www/html/clustercontrol/bootstrap.php define('DB_HOST', 'localhost');
/var/www/html/cmonapi/config/database.php define('DB_HOST', 'localhost');

Auf Unix-basierten Systemen behandeln MySQL-Programme den Hostnamen localhost besonders, auf eine Weise, die sich wahrscheinlich von dem unterscheidet, was Sie im Vergleich zu anderen netzwerkbasierten Programmen erwarten. Bei Verbindungen zu localhost versuchen MySQL-Programme, mithilfe einer Unix-Socket-Datei eine Verbindung zum lokalen Server herzustellen. Dies tritt auch dann auf, wenn eine --port- oder -P-Option angegeben wird, um eine Portnummer anzugeben.

Die Verwendung der MySQL-UNIX-Socket-Datei ist viel sicherer und reduziert den Netzwerk-Overhead. Es wird immer über TCP empfohlen. Sie müssen jedoch sicherstellen, dass die Socket-Datei richtig konfiguriert ist. Es muss in den folgenden Anweisungen in my.cnf und allen MySQL-Optionsdateien auf dem ClusterControl-Knoten vorhanden sein, zum Beispiel:

[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

Das Ändern der Socket-Datei erfordert auch einen Neustart von MySQL und CMON. Wenn Sie „localhost“ verwenden, können Sie einige zusätzliche Konfigurationsoptionen wie skip-networking=1 hinzufügen, um das Akzeptieren von Remote-Verbindungen zu verhindern. Unser ClusterControl-Docker-Image verwendet diesen Ansatz, um eine Einschränkung im Docker-Proxy beim Binden an Ports zu überwinden.

OpenSSH mit SSSD

ClusterControl verwendet das SSH-Protokoll als Hauptkommunikationskanal, um entfernte Knoten zu verwalten und zu überwachen. Die standardmäßigen OpenSSH-Konfigurationen sind ziemlich anständig und sollten in den meisten Fällen funktionieren. In einigen Umgebungen, in denen SSH jedoch mit anderen Tools zur Verbesserung der Sicherheit wie SElinux oder System Security Services Daemon (SSSD) integriert ist, kann dies erhebliche Auswirkungen auf die SSH-Leistung haben.

Wir haben viele Fälle gesehen, in denen eine ständig wachsende Anzahl von SSH-Verbindungen zu jedem der verwalteten Knoten aufgebaut wurden und schließlich sowohl der ClusterControl-Server als auch alle verwalteten Knoten ihren Systemspeicher mit SSH-Verbindungen ausgeschöpft haben. In einigen Fällen konnte nur ein normaler nächtlicher vollständiger Systemneustart auf dem ClusterControl-Server das Problem lösen.

Wenn Sie Ihre Infrastruktur mit System Security Services Daemon (SSSD) betreiben, wird empfohlen, die folgende Zeile in der OpenSSH-Clientkonfiguration unter /etc/ssh/ssh_config auf dem ClusterControl-Knoten zu kommentieren:

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

Das Obige überspringt die Verwendung von SSSD zur Verwaltung des Hostschlüssels, der stattdessen vom OpenSSH-Client verwaltet wird.

Ab ClusterControl 1.7.0 haben Sie die Möglichkeit, ein agentenbasiertes Überwachungstool mit Prometheus zu verwenden. Bei der agentenbasierten Überwachung verwendet ClusterControl kein SSH zum Abtasten von Hostmetriken, was in manchen Umgebungen übermäßig sein kann.

Dateisystem und Partitionierung

Der ClusterControl-Controller schreibt fast jede Sekunde für jeden Cluster einen neuen Eintrag in seine Protokolldatei. Für diejenigen, die diese sequentiellen Schreibvorgänge auf der Festplatte nutzen und Kosten sparen möchten, können Sie für diesen Zweck eine Spindeldiskette verwenden. Ändern Sie die folgende Zeile in allen cmon_X.cnf:

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

Ersetzen Sie X durch die Cluster-ID und starten Sie den CMON-Dienst neu, um die Änderungen zu übernehmen.

Wenn Sie ClusterControl als Backup-Repository verwenden, wird empfohlen, ausreichend Speicherplatz auf einer anderen Partition als der Root-Partition zuzuweisen. Es wird besser, wenn sich die Partition auf einem Netzwerk- oder Cluster-Dateisystem befindet, damit sie bei der Wiederherstellungsoperation einfach mit den Zielknoten gemountet werden kann. Wir haben Fälle gesehen, in denen die erstellten Backups den gesamten Speicherplatz der Hauptpartition verbrauchten, was sich schließlich auf ClusterControl und seine Komponenten auswirkte.

Bleiben Sie auf dem Laufenden

ClusterControl hat einen kurzen Veröffentlichungszyklus - mindestens eine neue Hauptversion pro Quartal plus wöchentliche Wartungspatches (hauptsächlich Fehlerbehebungen - falls vorhanden). Der Grund dafür ist, dass ClusterControl mehrere Datenbankanbieter und -versionen, Betriebssysteme und Hardwareplattformen unterstützt. Es werden oft neue Dinge eingeführt und alte Dinge von dem, was bereitgestellt wird, als veraltet markiert. ClusterControl muss mit allen Änderungen Schritt halten, die von Anwendungsanbietern eingeführt werden, und jedes Mal den Best Practices folgen.

Wir empfehlen Benutzern, immer die neueste Version von ClusterControl (Upgrade ist einfach) zusammen mit dem neuesten Webbrowser (erstellt und getestet auf Google Chrome und Mozilla Firefox) zu verwenden, da wir dies sehr wahrscheinlich nutzen werden die neuen Funktionen, die in der neuesten Version verfügbar sind.

Abschließende Gedanken

Wenn Sie Fragen haben oder auf Probleme oder Langsamkeitsprobleme bei der Verwendung von ClusterControl stoßen, kontaktieren Sie uns bitte über unseren Support-Kanal. Anregungen und Feedback sind sehr willkommen.

Viel Spaß beim Stimmen!