Vor kurzem hat VTB einige der Hardware- und Softwarekomponenten des Workflow-Systems geändert. Die Änderungen waren zu bedeutend, um ohne umfassende Lasttests weiterarbeiten zu können: Jedes Problem mit dem Document Support System (LMS) ist mit enormen Verlusten behaftet.
Intertrust-Spezialisten testeten VTB SDO auf Huawei-Geräten - einem Komplex aus Serverfarm, Datennetz und Speicher, der auf Solid-State-Laufwerken basiert. Für Tests haben wir eine Umgebung erstellt, die reale Szenarien mit der maximal möglichen Last reproduziert. Ergebnisse und Schlussfolgerungen - unter dem Schnitt.
Warum brauchen wir ein Workflow-System in einer Bank und warum testen wir es?
LMS in VTB ist ein komplexes Softwarepaket, an das alle wichtigen Verwaltungsprozesse gebunden sind. Das System bietet allgemeine Dokumentationsdienste, elektronische Interaktion und Analyse. Eine gut organisierte Verbreitung von Dokumenten beschleunigt Managemententscheidungen, macht das Verfahren für ihre Annahme transparent und kontrolliert, verbessert die Qualität des Managements und verbessert die Wettbewerbsfähigkeit der Bank.
Das LMS sollte eine klare Umsetzung der Entscheidungen in Übereinstimmung mit den festgelegten Vorschriften sicherstellen. Dies erfordert hohe Leistung, Fehlertoleranz und flexible Skalierung. Das System stellt hohe Anforderungen an die Zugriffskontrolle, das Volumen gleichzeitig verarbeiteter Dokumente und die Anzahl der Benutzer. Jetzt gibt es 65.000 von ihnen in VTB SDO, und diese Zahl wächst weiter.
Das System entwickelt sich ständig weiter: Die Architektur verändert sich, veraltete Technologien werden durch moderne ersetzt. Und vor kurzem wurden einige der Systemkomponenten durch importunabhängige ohne proprietäre Software ersetzt. Wird die neue SDO-Architektur, die auf der CompanyMedia-Software und dem Huawei-Hardwarekomplex basiert, die erhöhte Last bewältigen? Beantworten Sie diese Frage eindeutig, ohne auf eine ähnliche Situation in der Realität zu warten, war dies nur mit Hilfe von Stresstests möglich.
Zusätzlich zum Testen des neuen Softwareprodukts auf Stressresistenz hatten wir folgende Aufgaben:
- Bestimmen der genauen Parameter der horizontalen und vertikalen Dimensionierung von Servern für das Banklastprofil;
- Komponenten unter Hochlastbedingungen auf Fehlertoleranz prüfen;
- den Entropiekoeffizienten der Intercluster-Wechselwirkung mit der horizontalen Skalierung zu identifizieren;
- Versuchen Sie, Leseanforderungen zu skalieren, wenn Sie den Plattform-Balancer verwenden.
- Bestimmen des horizontalen Skalierungsfaktors aller Knoten und Komponenten des Systems;
- Bestimmen der maximal möglichen Hardwareparameter von Servern für verschiedene Funktionszwecke (vertikale Skalierung);
- das Lastprofil der Anwendung auf der technischen Infrastruktur zu untersuchen, die Ergebnisse für die Planung der Entwicklung des Informationssystems zu approximieren;
- Untersuchen Sie die Auswirkungen der Anwendungsdatenkonsolidierung auf ein einzelnes Datenspeichersystem auf die Ressourcenoptimierung, um die Zuverlässigkeit und Leistung zu verbessern.
Methodik und Ausrüstung
Lasttests von elektronischen Dokumentenmanagementsystemen werden häufig nach vereinfachten Szenarien durchgeführt. Sie simulieren das schnelle Auffinden und Öffnen von Dokumentenkarten, die nicht mit anderen Dateien verknüpft sind und keinen Lebenszyklusverlauf haben. In diesem Fall berücksichtigt in der Regel niemand Zugriffsrechte und andere ressourcenintensive Faktoren, die für reale Bedingungen charakteristisch sind.
Oft werden diese geschiedenen Tests von Lösungsanbietern durchgeführt. Es ist verständlich: Es ist wichtig, dass ein Anbieter einem potenziellen Kunden die hohe Leistung und Geschwindigkeit des Systems demonstriert. Es ist nicht überraschend, dass vereinfachte Testmodelle Antwortzeiten des Aufzeichnungssystems anzeigen, selbst wenn die Anzahl der Benutzer und Dokumente erheblich zunimmt.
Wir mussten die tatsächlichen Betriebsbedingungen reproduzieren. Daher haben wir zu Beginn einen Monat lang Statistiken gesammelt: Wir haben Benutzeraktivitäten aufgezeichnet und die Hintergrundarbeit aller Dienste beobachtet. Die in das LMS integrierten Überwachungssysteme wurden in dieser Angelegenheit zu einer großen Hilfe. Die Mitarbeiter der Bank halfen bei der Korrektur der resultierenden Daten zu den Dokumentenflüssen, während wir Anpassungen für das prognostizierte Wachstum der Ströme vornahmen.
Das Ergebnis war eine Testmethode, mit deren Hilfe die im System ablaufenden Prozesse unter Berücksichtigung aller realen Belastungen simuliert werden konnten. Auf dem Prüfstand haben wir - einzeln und in verschiedenen Kombinationen - die häufigsten Geschäftsvorgänge sowie die zeitaufwändigsten Anfragen reproduziert. Während der Leistungsprüfung wurden alle Komponenten einer Belastung ausgesetzt. Es wurden Vorgänge ausgeführt, um Benutzerzugriffsrechte auf Systemobjekte zu berechnen, Dokumente mit einer komplexen verzweigten Hierarchie und einer großen Anzahl von Links zu öffnen, das System zu durchsuchen usw.
Lasttestprofil:
- registrierte Benutzer: 65 Tausend mit einer Zunahme von bis zu 150 Tausend;
- Häufigkeit der Benutzeranmeldungen (Authentifizierungen): 50.000 pro Stunde;
- Benutzer, die gleichzeitig im System arbeiten: 10 Tausend;
- registrierte Dokumente: 10 Millionen pro Jahr;
- Volumen der Dateianhänge: 1 TB pro Jahr;
- Genehmigungsverfahren für Dokumente: 1,5 Millionen pro Jahr;
- Visa der Vertragsparteien: 7,5 Millionen pro Jahr;
- Beschlüsse und Anweisungen: 15 Millionen pro Jahr;
- Berichte über Resolutionen und Anweisungen: 15 Millionen pro Jahr;
- Benutzeraufgaben: 18 Millionen pro Jahr.
Diese Anwendungen wurden auf einem einzigen Speichersystem Huawei OceanStor Dorado 6000 V3 mit 117 SSD-Laufwerken mit jeweils 3,6 TB konsolidiert. Das nutzbare Gesamtvolumen beträgt mehr als 300 TB. Das modulare Serversystem des Huawei E9000 wurde mit Rechenleistung ausgestattet, und die Daten wurden über das Netzwerk übertragen, basierend auf Switches der Rechenzentrumsebene der Huawei CE-Serie. Während des Tests haben wir rund um die Uhr alle Indikatoren des Systems beobachtet. Alle Ergebnisse, einschließlich historischer Daten, wurden in Form von Grafiken und Tabellen für die nachfolgende Analyse aufgezeichnet.
Lasttest Hardware-Infrastruktur-Server
Aufgrund der hohen Leistung des Huawei OceanStor Dorado 6000 V3-Speichersystems überstiegen Verzögerungen bei der Ausführung von Benutzeranforderungen selten 1 ms. Diese Geschwindigkeit des Festplattensubsystems der Anwendung hat uns zu weiteren Untersuchungen inspiriert. Durch die Analyse historischer Daten haben wir beschlossen, die Auswirkungen verschiedener Arten von Workloads auf die technische Infrastruktur zu bestimmen. Die erzielten Ergebnisse ermöglichen es uns, die Entwicklung des Systems flexibel und genau gemäß den Anforderungen an die Hardwareplattform zu planen.
In Bezug auf die Skalierung haben wir Folgendes überprüft:
- Grenze der vertikalen Skalierung des Anwendungsservers (CMJ) , Kritikalitätsressourcen: Anzahl der Kerne und Häufigkeit, RAM-Größe;
- Unterstützung der horizontalen Skalierung des Anwendungsservers (CMJ) durch Duplizieren funktionsidentischer Dienste und Ausgleich zwischen diesen;
- Grenzen der vertikalen und horizontalen Skalierung des Client-Servers (Web-GUI) ;
- Grenzen der vertikalen Skalierung des Dateispeichers (FS) , Kritikalitätsressourcen: Netzwerkbandbreite, Festplattengeschwindigkeit;
- Unterstützung für die horizontale Skalierung des Dateispeichers (FS) aufgrund des verteilten Dateisystems - CEPH, GLUSTERFS;
- Grenzen der vertikalen Skalierung der Datenbank (PostgreSQL) , Ressourcen nach dem Grad der Kritikalität: RAM-Kapazität, Festplattengeschwindigkeit, Anzahl der Kerne und Häufigkeit;
- Unterstützung der horizontalen Datenbankskalierung (PostgreSQL) : Skalierung der Leselast auf Slave-Servern, Skalierung der Schreiblast nach dem Prinzip der Aufteilung in Funktionsmodule;
- Grenzen der vertikalen und horizontalen Skalierung des Nachrichtenbrokers (Apache Artemis) ;
- Grenzen der vertikalen und horizontalen Skalierung des Suchservers (Apache Solr) .
Probleme und Lösungen
Eine der Hauptaufgaben bestand darin, mögliche Probleme mit der Leistung des LMS zu identifizieren. Während der Arbeit wurden die folgenden Engpässe identifiziert und Wege gefunden, diese zu beheben.
Sperrt die synchrone Protokollierung. Protokollierungsvorgänge in der Standard-WildFly-Konfiguration werden synchron ausgeführt und beeinträchtigen die Leistung erheblich. Es wurde beschlossen, zu einem asynchronen Logger zu wechseln und gleichzeitig nicht auf eine Festplatte, sondern auf das ELK-Log-Aggregationssystem zu schreiben.
Initialisierung unnötiger Sitzungen bei der Arbeit mit einem Data Warehouse. Jeder Thread, der zweimal Daten vom Repository empfangen hat, hat eine Sitzung zur Authentifizierung im SSO-Modus initialisiert. Dieser Vorgang ist ressourcenintensiv und verlängert die Ausführungszeit der Benutzeranforderung erheblich und verringert auch den Gesamtdurchsatz des Servers.
Wird beim Arbeiten mit Anwendungs-Cache-Objekten gesperrt. Die Anwendung verwendete ziemlich starke reentrantLock-Sperren (Java 7), was sich negativ auf die Ausführungsgeschwindigkeit von Abfragen auswirkte. Die Art der Sperre wurde in stampedLock geändert, wodurch der Zeitaufwand für die Arbeit mit Cache-Objekten erheblich reduziert wurde.
Danach haben wir erneut Lasttests gestartet, um die durchschnittliche Zeit typischer Vorgänge im LMS-System mit relationalem Speicher im Bankprofil zu ermitteln. Wir haben folgende Ergebnisse erhalten:
- Benutzerberechtigung im System - 400 ms;
- Anzeige des Fortschritts im Durchschnitt - 2,5 s;
- Erstellung einer Registrierungs- und Kontrollkarte - 1,4 s;
- Registrierung und Registrierung der Kontrollkarte - 600 ms;
- Erstellung einer Resolution - 1 p.
Schlussfolgerungen
Stresstests haben nicht nur Probleme identifiziert, sondern auch einige unserer Annahmen bestätigt.
- Das System funktioniert unter der Linux-Betriebssystemfamilie viel besser.
- Die erklärten Grundsätze zur Gewährleistung der Fehlertoleranz gelten auf der Ebene jeder Komponente in einem "heißen" Modus.
- Eine Schlüsselkomponente - der Geschäftslogikdienst (Akzeptieren von Benutzeranforderungen) - verfügt über eine horizontale Spiegelung und eine nahezu lineare Skalierung des Durchsatzes mit zunehmender Anzahl von Instanzen.
- Optimale Dimensionierung des Geschäftslogikdienstes für 1200 gleichzeitige Benutzer - 8 vCPU für den Dienst und 1,5 vCPU für das DBMS.
- Die Konsolidierung von Anwendungsdaten auf einem einzelnen Speichersystem erhöht die Produktivität und Zuverlässigkeit erheblich und erhöht die Skalierbarkeit.
Gerne beantworten wir Ihre Fragen in den Kommentaren - vielleicht möchten Sie mehr über einige Aspekte des Testens erfahren.