Zu einem bestimmten Zeitpunkt erschien eine Aufgabe - ein vorhandenes und aktiv im Produktionsprojekt arbeitendes Projekt auf die Arbeit in einem Servercluster zu übertragen. Weil Das Projekt wurde auf Basis von 1C-Bitrix entwickelt. Es wurde beschlossen, einen Cluster mit "1C-Bitrix: Webumgebung" zu erstellen. Der Zweck dieser Veranstaltung ist es, schweren Belastungen durch den Zustrom von Site-Besuchern standzuhalten und in Zukunft horizontal schneller skalieren zu können.
Wenn wir auf die Website des Anbieters gehen, werden wir Folgendes sehen:
„1C-Bitrix: Webumgebung“ - Linux wird für die schnelle und einfache Installation der gesamten Software verwendet, die für den Betrieb von 1C-Bitrix-Produkten und -Lösungen auf den Linux-Plattformen CentOS 6 (i386, x86_64) und CentOS 7 (x86_64) erforderlich ist. Die Installation muss auf einem „sauberen“ CentOS ohne einen bereits installierten Webserver erfolgen.
Die Struktur von "1C-Bitrix: Webumgebung" - Linux umfasst: MySQL-Server, httpd, PHP, Nginx, NodeJS Push-Server, Memcached, Stunnel, Catdoc, XPDF, Munin, Nagios, Sphinx.
Tatsächlich enthält dieses Softwarepaket eine konfigurierte LAMP, ein Bedienfeld für den Konsolenserver sowie zusätzliche Pakete, die für den Betrieb einiger 1C-Bitrix-Module erforderlich sind. Die gesamte Software wird unter Berücksichtigung der Funktionen von 1C-Bitrix konfiguriert, nämlich:
- notwendige Erweiterungen installiert (gd, zip, socket, mbstring)
- Unterstützung für kurze Tags aktiviert
- Die erforderlichen Werte werden für die Parameter memory_limit, max_input_vars, abgesicherter Modus, opcache.validate_timestamps, opcache.revalidate_freq, mbstring.func_overload, default_charset, display_errors usw. festgelegt.
- Stellen Sie die gleiche Zeitzone für die Datenbank, PHP und auf dem Server selbst ein
- usw.
Dies ermöglicht in den meisten Fällen, keine Serverkonfiguration und -optimierung vorzunehmen.
Wir hatten also 2 App-Server (nennen wir sie app01 und app01), 2 DB-Server (db01, db02), 1 Server für das Caching (cache01, verstehen Sie). Genauer gesagt bestand die Idee darin, die Clusterstruktur auf ähnliche Weise zu implementieren. Im Rahmen dieses Plans wurden 5 Server empfangen, auf denen die neuesten Centos7-Versionen installiert waren (leider sind Debian, Ubuntu, Fedora, Rhel usw. nicht geeignet), außer für OS wurde nichts anderes auf den Servern installiert.
Weil Wenn wir einen Cluster zusammenstellen, muss bestimmt werden, welcher der Server der Hauptserver sein wird. Aufgrund der Besonderheiten beim Ausgleichen von Anforderungen an die Anwendung enthält einer der Server, auf denen httpd funktioniert, auch Nginx. Er akzeptiert auch alle eingehenden Anforderungen und leitet die Anforderung dann an einen der verfügbaren Webknoten weiter. Wir haben den Hauptserver app01 gewählt.
Weitere Arbeiten verliefen nach folgendem Plan:
1. Installieren Sie bitrixenv
Die Installation impliziert keine übernatürlichen Linux-Kenntnisse oder -Verwaltung. Wir gehen über ssh zu jedem Server und führen die folgenden Befehle aus:
cd ~ wget http://repos.1c-bitrix.ru/yum/bitrix-env.sh chmod +x bitrix-env.sh ./bitrix-env.sh
Bitrixenv muss auf allen Servern installiert sein, deren Verwendung im Cluster geplant ist. Auch wenn der Server nur als zwischengespeicherte Instanz funktioniert, ist bitrixenv notwendig, weil Mit dieser Option können Sie den gesamten Cluster vom Hauptserver aus verwalten.
2. Konfigurieren Sie bitrixenv
Weil Wenn wir diesen gesamten Zoo als Cluster verwenden, können wir die Server über das Umgebungsmenü in App01 konfigurieren. Gehen Sie dazu über ssh zum Server und führen Sie die Datei /root/menu.sh aus. Beim ersten Start müssen Sie ein Kennwort für den Bitrix-Benutzer festlegen (ein ähnlicher Vorgang muss auf allen Servern ausgeführt werden, auf denen der Start der Site geplant ist):
Tatsächlich ist dies der Benutzer, unter dem die Anwendung arbeiten wird. Danach sehen wir ein Bildschirmangebot zum Erstellen eines Serverpools:
Hier müssen wir den ersten Menüpunkt auswählen. Beim Erstellen der Umgebung wird der Name des aktuellen Servers abgefragt. Anschließend geben wir app01 an:
Nachdem der Pool erstellt wurde, kehren wir zum ersten Bildschirm der Umgebung zurück. Diesmal sind jedoch noch viel mehr Punkte verfügbar:
Im Allgemeinen ist die Umgebung bereit und Sie können sie verwenden. Wenn wir keinen Cluster brauchen, könnten wir hier enden, aber wir werden weiter gehen.
Jetzt müssen wir alle verfügbaren Server zum erstellten Pool hinzufügen. Verwenden Sie dazu den ersten Menüpunkt und sehen Sie sich die folgenden Optionen an:
Wählen Sie erneut den ersten Menüpunkt aus und geben Sie die IP-Adresse des neuen Servers, seinen Namen im Cluster (dieselbe App02, db01, db02, cache01) und das Root-Passwort des verbundenen Servers an. Daher fügen wir jeden verfügbaren Server einzeln hinzu. Nachdem alle Server im Cluster registriert sind, sollte diese Liste auf dem Hauptbildschirm der Umgebung angezeigt werden:
Das Festlegen der Serverrollen für den Moment wird auf den nächsten Schritt verschoben.
3. Projektübertragung
Weil Da unsere Anwendung zunächst auf einem einzelnen Server ausgeführt wird, das Skalierungs- und Clusterverwaltungsmodul deaktiviert ist, wird die Datenbank nicht repliziert. Die Übertragung selbst ist nichts Übernatürliches - sie hat die Bitrix gepackt und Ordner hochgeladen, den Datenbankspeicherauszug entfernt.
Nachdem die Archive und Dumps fertig sind, gehen Sie zu app01 und ziehen Sie den Projektcode durch das Git in den Standardordner der Site in bitrixenv - / home / bitrix / www. Laden Sie die Archive und Dumps der Datenbank mit wget oder curl herunter, entpacken Sie die Archive und laden Sie sie hoch Dump in die Datenbank auf App01, Cron-Einträge übertragen.
Wenn Ihre Anwendung zusätzliche Software verwendet, ist es Zeit, diese zu installieren und zu konfigurieren. In unserem Fall wurden Supervisord und RabbitMQ installiert und konfiguriert als Die Anwendung arbeitete mit Warteschlangen.
Es gibt eine kleine, aber wichtige Nuance. Beim Übertragen eines Standorts auf einen Cluster müssen die Skalierungs- und Clustermodule auf dem Standort deaktiviert sein und die Poolserver sind nicht an der Umgebung des Clusters beteiligt, auf den die Übertragung geplant ist. Cluster-Server sollten erst in den Vorgang einbezogen werden, nachdem der Standort verschoben und auf dem Hauptserver bereitgestellt wurde. Andernfalls kann die Site die Cluster-Server nicht korrekt ermitteln.
4. Aktivieren des Clusterbetriebs
Nachdem die Anwendung auf app01 portiert wurde und wir die Richtigkeit ihrer Arbeit überprüft haben, ist es Zeit, das Interessanteste zu tun - die Skalierung. Zuerst müssen Sie die Scale- und Cluster-Module im 1C-Bitrix-Administrationsbereich installieren. Während der Installation muss nichts Besonderes getan werden, alle Arbeiten gehen weiter.
Sobald die Module installiert sind, gehen Sie zur ssh-Verbindung mit dem Hauptserver, und dies ist app01, und öffnen Sie das Bitrixenv-Menü (liegt /root/menu.sh hier). Bevor Sie mit der weiteren Konfiguration fortfahren, müssen Sie einen wichtigen Punkt herausfinden: bitrixenv verwendet das Konzept der „Serverrolle“. Es spielt keine Rolle, wie der Server im Pool heißt, denn Jeder Server enthält die gesamte Software, die im bitrixenv-Paket enthalten ist. Wir können ihm jederzeit eine oder mehrere Rollen zuweisen und sie daraus entfernen oder gegen andere austauschen. Die Hauptrollen sind mgmt (Balancer, d. H. Nginx), Web (d. H. Http / apache), mysql_master und mysql_slave (DB-Instanz, Slave wird angezeigt, wenn wir mit der Replikation beginnen), memcached (Server mit memcached). Das allgemeine Bild ist jetzt klar und wir haben beschlossen, mit einem zwischengespeicherten Server zu beginnen. Gehen Sie dazu zum Absatz
4. Configure memcahed servers > 1. Configure memcached service
und wir sehen eine Anfrage nach dem Namen des Servers, der als zwischengespeicherter Server fungiert. Wir haben bereits einen cache01-Server dafür vorbereitet, daher sehen wir uns die Liste der verfügbaren Server an. Wenn cache01 in der Liste enthalten ist, gibt es keine Installationsprobleme, und wir können dem Server die ausgewählte Rolle zuweisen.
Wir geben den Namen cache01 ein und sehen, dass die Aufgabe zum Festlegen der Rolle in der Warteschlange steht. Wir warten auf den Abschluss der Hintergrundarbeiten und sehen einen Server, der für die Arbeit mit der von uns benötigten Rolle bereit ist.
Es ist Zeit, einen zweiten App-Server hinzuzufügen. Gehen Sie dazu den Weg entlang
8. Manage web nodes in the pool > 1. Create web role on server,
Hier müssen wir den Servernamen und die Synchronisationsmethode zwischen dem Haupt- und dem neuen Webknoten angeben. Basierend auf der Bitrixenv-Dokumentation und den vorläufigen Tests war es für unser Projekt ausreichend, die erste Option auszuwählen (Kopieren des Projekts und Einrichten der Knotenkonfigurationen in einem Schritt). Nachdem die Hintergrundarbeit beendet ist, sollten wir so etwas im Hauptmenü sehen:
Beachten Sie, dass in der Spalte Rollen gegenüber dem app02-Server die Webrolle angegeben ist.
Es bleibt die Datenbank zu bearbeiten, ihre Konfiguration nimmt die meiste Zeit in Anspruch. Zunächst erkläre ich kurz, wie MySQL-Rollen im Kontext von Bitrixenv verteilt sind. Standardmäßig befindet sich die Master-Version der Datenbank auf dem Hauptserver des Clusters. In unserem Fall war es erforderlich, die Datenbank auf einen separaten Server zu übertragen und einen weiteren Server mit einer Slave-Version der Datenbank hinzuzufügen. In bitrixenv können Sie nicht einfach den Master von einem Server auf einen anderen übertragen.
Die Reihenfolge ist wie folgt:
- Wir geben die Rolle von mysql_slave an den Server weiter, auf den wir die Datenbank übertragen möchten
- Auf dem Zielserver ändern wir die Rolle von mysql_slave in die Rolle von mysql_master (automatisch wechselt der alte mysql_master in den mysql_slave-Modus).
- Löschen Sie die Rolle mysql_slave auf dem ursprünglichen Server, dem früheren Master
- ...
- GEWINN !!!
Wir sind dieser Logik folgendermaßen gefolgt:
Ging zu
3. Configure MySQL servers > 4. Create MySQL slave
Wir haben den Server angegeben, dem wir die Rolle mysql_slave - db01 zuweisen möchten. Wir warten auf den Abschluss der Hintergrundarbeiten und sehen folgendes Ergebnis:
Ok, jetzt gehen wir zu
3. Configure MySQL servers > 5. Change MySQL master
Geben Sie app01 an und warten Sie. Als Ergebnis sollten Sie ungefähr Folgendes sehen:
Langsam und unweigerlich näherten wir uns der Installation der letzten Rolle - mysql_slave. Dazu ist es notwendig, die Schritte zu wiederholen, mit denen wir eine solche Rolle für db01 festlegen, aber db02 bereits anzugeben.
Schließlich sind alle Server verbunden und konfiguriert.
5. Tuning-Leistung
Nachdem der Cluster bereit ist, gibt es einige Funktionen in der Anwendungskonfiguration, die eine zusätzliche Optimierung ermöglichen:
- Wir pumpen Arbeit mit Sitzungen. Hier ausführlich beschrieben. Kurz gesagt: Wechseln Sie den Sitzungsspeicher in memcached.
- Löschen Sie die Dateien /bitrix/php_interface/after_connect_d7.php und /bitrix/php_interface/after_connect.php, weil Befehle von ihnen brechen die Cluster-Pipeline ab (wenn bitrixenv nicht verwendet wird, ist es besser, sie zu verlassen).
- Wir erhöhen die durch memcached zugewiesene Speichermenge und setzen den Prozentsatz der Nutzung von Servern mit der memcached-Rolle auf 100%.
- Deaktivieren Sie PHP-Module: apcu, ldap
- Deaktivieren Sie die Busmodule "Komprimierung" und "Webanalyse" (falls möglich).
- Verwenden Sie einen lokalen Cache. Weitere Details werden hier beschrieben. In unserem Fall gab es keinen Anstieg, aber die Idee ist interessant. Die Lösung bietet mehrere Funktionen:
- Die Anzahl der zwischengespeicherten Instanzen sollte der Anzahl der Webknoten entsprechen.
- Um den zusammengesetzten Cache von nginx direkt aus dem lokal gespeicherten Cache zurückzugeben, müssen Sie sich in die nginx-Konfiguration vertiefen, dies funktioniert nicht sofort.
- Verschieben Sie die Ausführung aller Agenten nach cron.
Schlussfolgerungen
Im Rahmen dieses Artikels haben wir die Reihenfolge der Schritte untersucht, die zum Konfigurieren eines Cluster von Servern auf der Basis von Bitrixenv erforderlich sind, sowie einige mögliche Fallstricke. Basierend auf den Ergebnissen der Arbeit mit bitrixenv und dem Cluster darauf können wir die Vor- und Nachteile dieses Ansatzes hervorheben:
Vorteile bitrixenv
- Installationszeit
Die Installation und Grundeinstellung dauert weniger als 30 Minuten. Es ist nicht erforderlich, LAMP-Elemente zu konfigurieren (sowohl die Integration dieser Dienste untereinander als auch für die korrekte Arbeit von Projekten unter 1C-Bitrix). - Dienste zur Beschleunigung der Website
Installierte und konfigurierte Dienste, mit denen Sie schnelleres Caching über Memcached als über Dateien organisieren, mithilfe der Sphinx-Engine und der Funktionalität von Videoanrufen und Chats auf dem Unternehmensportal suchen können (Nginx Push & Pull-Modul). Darüber hinaus ist nginx in der Umgebung so konfiguriert, dass beim Aktivieren der entsprechenden Optionen auf der Site und im Menü bitrixenv der Cache mit nginx direkt von memcached gesendet wird (unter Umgehung von httpd und php). - Clustering
Die Möglichkeit, die Datenbankreplikation zu aktivieren, ohne die MySQL-Einstellungen auszuwählen. Verbinden einer beliebigen Anzahl von Webknoten, die automatisch miteinander synchronisiert werden, und zwischengespeicherten Knoten. Verwaltung des Lastausgleichs auf Web- und Memcached-Knoten sowohl über das Bitrixenv-Menü als auch über das Admin-Panel des Projekts unter 1C-Bitrix. Das Hinzufügen neuer Server und Rollen zu diesen führt nicht zu einem einfachen Projekt (außer vielleicht für die Rollen von Datenbankservern).
Nachteile bitrixenv
- Der Balancer befindet sich immer beim Hauptwebknoten
Weil Wir hatten bereits einen eigenen Balancer. Wir waren mit der Tatsache konfrontiert, dass es unmöglich ist, den in Bitrixenv eingebauten Balancer aufzugeben. Es ist unmöglich einzuschließen Platzieren Sie es getrennt vom Hauptwebknoten. - Viel zusätzliche Software für einige Rollen
Weil Da jeder Server im Pool die Vollversion der Umgebung enthält, stellt sich heraus, dass die Datenbankknoten httpd, memcached, sphinx sind, auch wenn sie nicht verwendet werden. Ebenso finden Sie MySQL auf einem Server, der sich nur mit Caching befasst. In diesem Fall kann MySQL jedoch im Menü der Umgebung oder im Admin-Bereich der Site gestoppt werden. - PHP arbeitet im Apache2-Handler-Modus
Es gibt keine Möglichkeit, PHP im Fcgi-Modus sicher zu aktivieren, ganz zu schweigen vom Nginx + PHP-Fpm-Modus. Es wird auch nicht funktionieren, die PHP-Version zu ändern, ohne mit einem Tamburin zu tanzen.
Quellen:
www.1c-bitrix.ru/products/env
dev.1c-bitrix.ru/community/blogs/rns/hidden-features-of-work-with-sessions.php
dev.1c-bitrix.ru/community/blogs/rns/the-use-of-local-caches-in-the-cluster.php
dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=32&INDEX=Y
dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=37&INDEX=Y