Get best of the week

Informationen zum 1C-Servercluster

Ein Cluster ist eine Art paralleles
oder verteiltes System, das:
1. aus mehreren miteinander verbundenen
Computern besteht;
2. Als einzelne,
einheitliche Computerressource verwendet

Gregory F. Pfister, „Auf der Suche nach Clustern“.

Gegeben: Es gibt eine Geschäftsanwendung (z. B. ein ERP-System), mit der Tausende (möglicherweise Zehntausende) Benutzer gleichzeitig arbeiten.

Es ist notwendig:
  1. Machen Sie die Anwendung skalierbar, sodass es mit zunehmender Anzahl von Benutzern aufgrund der Zunahme der Hardwareressourcen möglich ist, die erforderliche Anwendungsleistung bereitzustellen.
  2. Machen Sie die Anwendung resistent gegen Ausfall von Systemkomponenten (sowohl Software als auch Hardware), Verbindungsverlust zwischen Komponenten und andere mögliche Probleme.
  3. Verwenden Sie die Systemressourcen so effizient wie möglich und bieten Sie die gewünschte Anwendungsleistung.
  4. Vereinfachen Sie die Bereitstellung und Verwaltung des Systems.

Um diese Probleme zu lösen, verwenden wir die Clusterarchitektur in der 1C: Enterprise-Plattform.

Wir haben das gewünschte Ergebnis nicht sofort erreicht.

In diesem Artikel werden wir darüber sprechen, welche Art von Clustern es gibt, wie wir den für uns geeigneten Clustertyp ausgewählt haben und wie sich unser Cluster von Version zu Version entwickelt hat und welche Ansätze es uns ermöglichten, schließlich ein System zu erstellen, das Zehntausende von gleichzeitigen Benutzern bedient.

Bild

Wie Gregory Pfister, der Autor des Epigraphs zu diesem Artikel, in seinem Buch „Auf der Suche nach Clustern“ schrieb, wurde der Cluster nicht von einem bestimmten Hersteller von Hardware oder Software erfunden, sondern von Kunden, denen die Leistung eines Computers fehlte oder die Redundanz benötigten. Dies geschah laut Pfister bereits in den 60er Jahren des letzten Jahrhunderts.
Unterscheiden Sie traditionell die folgenden Haupttypen von Clustern:

  1. Failover-Cluster (HA, Hochverfügbarkeitscluster)
  2. Lastausgleichscluster (LBC)
  3. Computercluster (High Performance Computing Cluster, HPC)
  4. (grid) , . grid- , . grid- HPC-, .

Um unsere Probleme zu lösen (Beständigkeit gegen Ausfall von Systemkomponenten und effizienter Einsatz von Ressourcen), mussten wir die Funktionalität eines ausfallsicheren Clusters und eines Clusters mit Lastausgleich kombinieren. Wir sind nicht sofort zu dieser Entscheidung gekommen, sondern haben sie schrittweise weiterentwickelt.

Für diejenigen, die nicht auf dem neuesten Stand sind, werde ich kurz erläutern, wie 1C-Geschäftsanwendungen angeordnet sind. Hierbei handelt es sich um Anwendungen, die in einer fachorientierten Sprache verfasst und für die Automatisierung von Buchhaltungsgeschäftsaufgaben "geschärft" wurden. Um Anwendungen auszuführen, die in dieser Sprache geschrieben sind, muss eine Laufzeit der 1C: Enterprise-Plattform auf dem Computer installiert sein.

1C: Enterprise 8.0


Die erste Version des 1C-Anwendungsservers (noch kein Cluster) wurde in Plattformversion 8.0 veröffentlicht. Zuvor arbeitete 1C in der Client-Server-Version, die Daten wurden in einer Datei DBMS oder MS SQL gespeichert und die Geschäftslogik arbeitete ausschließlich auf dem Client. In Version 8.0 wurde auf die dreistufige Architektur "Client - Anwendungsserver - DBMS" umgestellt.

Server 1C in Plattform 8.0 war COM +Ein Server, der Anwendungscode in 1C ausführen kann. Durch die Verwendung von COM + konnten wir einen vorgefertigten Transport durchführen, sodass Clientanwendungen über das Netzwerk mit dem Server kommunizieren konnten. Viele Dinge in der Architektur sowohl der Client-Server-Interaktion als auch der Anwendungsobjekte, die dem 1C-Entwickler zur Verfügung stehen, wurden unter Berücksichtigung der Verwendung von COM + entwickelt. Zu diesem Zeitpunkt war keine Fehlertoleranz in die Architektur integriert, und ein Serverabsturz führte dazu, dass alle Clients heruntergefahren wurden. Wenn die Serveranwendung abstürzte, hob COM + sie auf, als der erste Client darauf zugegriffen hatte, und die Clients begannen ihre Arbeit von Anfang an - von der Verbindung zum Server. Zu diesem Zeitpunkt wurden alle Kunden von einem Prozess bedient.
Bild

1C: Enterprise 8.1


In der nächsten Version wollten wir:

  • Bieten Sie unseren Kunden Fehlertoleranz, damit Unfälle und Fehler einiger Benutzer nicht zu Unfällen und Fehlern anderer Benutzer führen.
  • Befreien Sie sich von der COM + -Technologie. COM + funktionierte nur unter Windows, und zu diesem Zeitpunkt wurde die Möglichkeit, unter Linux zu arbeiten, bereits relevant.

Gleichzeitig wollten wir keine neue Version der Plattform von Grund auf neu entwickeln - dies wäre zu ressourcenintensiv. Wir wollten unsere Errungenschaften maximal nutzen und die Kompatibilität mit Anwendungen gewährleisten, die für Version 8.0 entwickelt wurden.

In Version 8.1 erschien also der erste Cluster. Wir haben unser Protokoll für Remoteprozeduraufrufe (zusätzlich zu TCP) implementiert, das anscheinend für den Endverbraucher-Client fast wie COM + aussah (d. H. Wir mussten den für Client-Server-Aufrufe verantwortlichen Code praktisch nicht neu schreiben). Gleichzeitig haben wir den in der C ++ - Plattform implementierten Server unabhängig gemacht und können sowohl unter Windows als auch unter Linux arbeiten.

Die monolithische Serverversion 8.0 wurde durch drei Arten von Prozessen ersetzt - einen Arbeitsprozess, der Clients bedient, und zwei Dienstprozesse, die den Betrieb des Clusters unterstützen:

  • rphost ist ein Workflow, der Kunden bedient und Anwendungscode ausführt. Ein Cluster kann mehr als einen Workflow haben, verschiedene Workflows können auf verschiedenen physischen Servern ausgeführt werden - aufgrund dieser Skalierbarkeit wird erreicht.
  • ragent - ein Server-Agent-Prozess, der alle anderen Prozesstypen startet, sowie eine führende Liste von Clustern auf diesem Server.
  • rmngr ist ein Cluster-Manager, der den Betrieb des gesamten Clusters steuert (der Anwendungscode funktioniert jedoch nicht darauf).

Unter dem Schnitt befindet sich das Operationsdiagramm dieser drei Prozesse im Cluster.
image

Während der Sitzung arbeitete der Client mit einem Workflow. Der Ausfall des Workflows bedeutete für alle Clients, denen dieser Prozess diente. Die Sitzung wurde abnormal beendet. Die übrigen Kunden arbeiteten weiter.
Bild

1C: Enterprise 8.2


In Version 8.2 wollten wir, dass 1C-Anwendungen nicht nur im nativen (ausführbaren) Client, sondern auch im Browser ausgeführt werden können (ohne den Anwendungscode zu ändern). Insbesondere in dieser Hinsicht bestand die Aufgabe darin, den aktuellen Status der Anwendung von der aktuellen Verbindung mit dem rphost-Workflow zu entkoppeln und zustandslos zu machen. Als Ergebnis entstand das Konzept einer Sitzung und von Sitzungsdaten, die außerhalb des Workflows gespeichert werden mussten (weil sie zustandslos waren). Es wurde ein Sitzungsdatendienst entwickelt, der Sitzungsinformationen speichert und zwischenspeichert. Es wurden auch andere Dienste angezeigt - ein Dienst für verwaltete Transaktionssperren, ein Volltextsuchdienst usw.

Diese Version führte auch einige wichtige Innovationen ein - verbesserte Fehlertoleranz, Lastausgleich und ein Cluster-Redundanzmechanismus.

Fehlertoleranz


Da der Arbeitsprozess zustandslos wurde und alle für die Arbeit erforderlichen Daten außerhalb der aktuellen Client-Workflow-Verbindung gespeichert wurden, wechselte der Client im Falle eines Workflow-Absturzes beim nächsten Zugriff auf den Server zu einem anderen "Live" -Workflow. In den meisten Fällen war ein solcher Wechsel für den Client unsichtbar.

Der Mechanismus funktioniert so. Wenn der Aufruf des Clients an den Workflow aus irgendeinem Grund nicht bis zum Ende abgeschlossen werden konnte, kann der Client-Teil nach einem Anruffehler diesen Aufruf wiederholen, indem die Verbindung zu demselben oder einem anderen Workflow wiederhergestellt wird. Sie können einen Anruf jedoch nicht immer wiederholen. Wiederholen des Anrufs bedeutet, dass wir den Anruf an den Server gesendet haben, aber das Ergebnis nicht erhalten haben. Wir versuchen, den Anruf zu wiederholen, während wir den zweiten Anruf tätigen. Wir bewerten, was das Ergebnis des vorherigen Anrufs auf dem Server war (Informationen dazu sind auf dem Server in den Sitzungsdaten gespeichert), denn wenn der Anruf Zeit hatte, dort zu "erben" (Schließen Sie die Transaktion, speichern Sie die Sitzungsdaten usw.) - es ist einfach unmöglich, es zu wiederholen, es führt zu Dateninkonsistenzen. Wenn der Anruf nicht wiederholt werden kann, erhält der Client eine Nachricht über einen nicht behebbaren Fehler.und die Client-Anwendung muss neu gestartet werden. Wenn Sie es nicht geschafft haben, den Anruf zu "erben" (und dies ist die häufigste Situation, da viele Anrufe keine Daten ändern, z. B. Berichte, Anzeigen von Daten in einem Formular usw., und diejenigen, die Daten ändern, keine Transaktion haben oder bis eine Änderung der Sitzungsdaten an den Manager gesendet wurde (es gibt keine Spur des Anrufs), kann dies ohne das Risiko einer Dateninkonsistenz wiederholt werden. Wenn der Workflow abgestürzt ist oder eine Netzwerkverbindung unterbrochen wurde, wird ein solcher Aufruf wiederholt, und diese „Katastrophe“ für die Clientanwendung tritt völlig unbemerkt auf.Diese Änderungsdaten - bis die Transaktion festgeschrieben wird oder bis die Änderung der Sitzungsdaten an den Manager gesendet wird - es gibt keine Spur des Anrufs) - können ohne das Risiko einer Dateninkonsistenz wiederholt werden. Wenn der Workflow abgestürzt ist oder eine Netzwerkverbindung unterbrochen wurde, wird ein solcher Aufruf wiederholt, und diese „Katastrophe“ für die Clientanwendung tritt völlig unbemerkt auf.Diese Änderungsdaten - bis die Transaktion festgeschrieben oder die Änderung der Sitzungsdaten an den Manager gesendet wird (es gibt keine Spur des Anrufs) - können ohne das Risiko einer Dateninkonsistenz wiederholt werden. Wenn der Workflow abgestürzt ist oder eine Netzwerkverbindung unterbrochen wurde, wird ein solcher Aufruf wiederholt, und diese „Katastrophe“ für die Clientanwendung tritt völlig unbemerkt auf.

Lastverteilung


In unserem Fall hat der Lastausgleich folgende Aufgabe: Ein neuer Client betritt das System (oder ein bereits arbeitender Client führt einen weiteren Anruf durch). Wir müssen auswählen, an welchen Server und an welchen Workflow der Anruf des Clients gesendet werden soll, um dem Client maximale Geschwindigkeit zu bieten.

Dies ist eine Standardaufgabe für einen Cluster mit Lastenausgleich. Es gibt verschiedene typische Algorithmen zum Lösen, zum Beispiel:


Für unseren Cluster haben wir einen Algorithmus gewählt, der im Wesentlichen nahe an der geringsten Antwortzeit liegt. Wir haben einen Mechanismus, der Statistiken über die Leistung von Workflows auf allen Servern im Cluster sammelt. Es führt einen Referenzaufruf für jeden Serverprozess im Cluster durch. Der Referenzaufruf umfasst eine Teilmenge der Funktionen des Festplattensubsystems, des Speichers und des Prozessors und bewertet, wie schnell ein solcher Aufruf erfolgt. Das Ergebnis dieser Messungen, gemittelt über die letzten 10 Minuten, ist ein Kriterium - welcher Server im Cluster ist der produktivste und bevorzugte, um in einem bestimmten Zeitraum Clientverbindungen an ihn zu senden. Client-Anfragen werden so verteilt, dass der produktivste Server besser geladen wird - laden Sie denjenigen, der Glück hat.

Die Anfrage vom neuen Client ist derzeit an den produktivsten Server gerichtet.

Eine Anforderung von einem vorhandenen Client wird in den meisten Fällen an diesen Server und an den Workflow gerichtet, an den die vorherige Anforderung gerichtet war. Ein umfangreicher Datensatz auf dem Server ist einem funktionierenden Client zugeordnet. Die Übertragung zwischen Prozessen (und vor allem zwischen Servern) ist recht teuer (obwohl wir dies auch tun können).

Eine Anforderung von einem vorhandenen Client wird in zwei Fällen an einen anderen Workflow übertragen:

  1. Es gibt keinen Prozess mehr: Der Workflow, mit dem der Client zuvor interagiert hat, ist nicht mehr verfügbar (der Prozess ist abgebrochen, der Server ist nicht mehr verfügbar usw.).
  2. : , , , , . , , – . – (.. ).



Wir haben uns entschlossen, die Ausfallsicherheit des Clusters zu erhöhen, indem wir auf das Aktiv / Passiv- Schema zurückgegriffen haben . Es bestand die Möglichkeit, zwei Cluster zu konfigurieren - Working und Reserve. Wenn der primäre Cluster nicht verfügbar ist (Netzwerkprobleme oder beispielsweise geplante Wartung), werden Clientaufrufe an den Sicherungscluster umgeleitet.

Dieses Design war jedoch ziemlich schwierig zu konfigurieren. Der Administrator musste zwei Servergruppen manuell zu Clustern zusammenstellen und konfigurieren. Manchmal haben Administratoren Fehler gemacht, indem sie widersprüchliche Einstellungen vorgenommen haben Es gab keinen zentralen Mechanismus zum Überprüfen der Einstellungen. Dieser Ansatz erhöhte jedoch die Fehlertoleranz des Systems.
Bild

1C: Enterprise 8.3


In Version 8.3 haben wir den serverseitigen Code, der für die Fehlertoleranz verantwortlich ist, grundlegend neu geschrieben. Wir haben beschlossen, das Aktiv / Passiv-Cluster-Schema aufgrund der Komplexität seiner Konfiguration aufzugeben. Es ist nur noch ein fehlertoleranter Cluster im System vorhanden, der aus einer beliebigen Anzahl von Servern besteht. Dies entspricht eher dem Aktiv / Aktiv- Schema, bei dem Anforderungen für einen ausgefallenen Knoten auf die verbleibenden Arbeitsknoten verteilt werden. Aus diesem Grund ist der Cluster einfacher zu konfigurieren. Eine Reihe von Vorgängen, die die Fehlertoleranz erhöhen und den Lastausgleich verbessern, wurden automatisiert. Von den wichtigen Innovationen:

  • « »: , , . , «» .
  • , , .
  • , , , , , :

Bild

Bild

Die Hauptidee dieser Entwicklungen besteht darin, die Arbeit des Administrators zu vereinfachen und ihm zu ermöglichen, den Cluster auf der ihm vertrauten Ebene auf Serverebene zu konfigurieren, ohne darunter zu fallen, und den Grad der „manuellen Steuerung“ der Clusterarbeit zu minimieren, wodurch der Cluster Mechanismen zur Lösung der meisten Arbeitsaufgaben und möglichen Probleme erhält. auf Autopilot. "

Bild

Drei Glieder der Fehlertoleranz


Wie Sie wissen, können Probleme auftreten, wenn sich die Komponenten des Systems gegenseitig verursachen, selbst wenn die Komponenten des Systems separat zuverlässig sind. Wir wollten die Anzahl der für die Systemleistung kritischen Stellen minimieren. Eine wichtige zusätzliche Überlegung war die Minimierung von Änderungen der angewandten Mechanismen in der Plattform und der Ausschluss von Änderungen der angewandten Lösungen. In Version 8.3 gab es 3 Links zur Gewährleistung der Fehlertoleranz „an den Gelenken“:

Bild
  1. , HTTP(S), -. - -. , HTTP -, ( HTTP) libcurl .
  2. , .
  3. - . 1, - . - . , . , – . - (, , , ) – .
  4. , rmngr. 20 ( ) — , .. . 1: .



Dank des Fehlertoleranzmechanismus können auf der 1C: Enterprise-Plattform erstellte Anwendungen verschiedene Arten von Ausfällen von Produktionsservern im Cluster erfolgreich überstehen, während die meisten Clients weiterhin ohne Neustart arbeiten.

Es gibt Situationen, in denen wir den Anruf nicht wiederholen können oder ein Serverabsturz die Plattform zu einem sehr unglücklichen Zeitpunkt erfasst, z. B. mitten in einer Transaktion, und es nicht klar ist, was mit ihnen zu tun ist. Wir versuchen, ein statistisch gutes Client-Überleben sicherzustellen, wenn Server in den Cluster fallen. In der Regel beträgt der durchschnittliche Verlust von Clients aufgrund eines Serverausfalls einige Prozent. In diesem Fall können alle "verlorenen" Clients nach dem Neustart der Clientanwendung im Cluster weiterarbeiten.

Die Zuverlässigkeit des 1C-Serverclusters in Version 8.3 hat erheblich zugenommen. Es ist seit langem nicht ungewöhnlich, 1C-Produkte einzuführen, bei denen die Anzahl der gleichzeitig arbeitenden Benutzer mehrere Tausend erreicht. Es gibt Implementierungen, bei denen sowohl 5.000 als auch 10.000 Benutzer gleichzeitig arbeiten - beispielsweise die Einführung in Beeline , bei der die Anwendung 1C: Trade Management alle Beeline-Verkaufsstellen in Russland bedient, oder die Implementierung von Business Lines im Frachtunternehmen Hier dient die Anwendung, die von den Entwicklern der IT-Abteilung von Business Lines auf der 1C: Enterprise-Plattform unabhängig erstellt wurde, dem gesamten Zyklus des Frachttransports. Unsere internen Clusterlasttests simulieren den gleichzeitigen Betrieb von bis zu 20.000 Benutzern.

Abschließend möchte ich kurz auflisten, was in unserem Cluster noch nützlich ist (die Liste ist unvollständig):

  • , . , , .
  • – , , , ( – , ..) . , , (, ) , ERP, , ERP.
  • – , (, , ..). , , , , , .

More articles:


All Articles