Überwachung im Rechenzentrum: So haben wir das alte BMS durch das neue ersetzt. Teil 2

Im ersten Teil haben wir erläutert, warum wir uns entschieden haben, unser altes BMS-System in unseren Rechenzentren durch ein neues zu ersetzen. Und nicht einfach nur zu ersetzen, sondern es von Grund auf neu zu entwickeln, um unseren Anforderungen gerecht zu werden. Im zweiten Teil berichten wir darüber, wie wir dies umgesetzt haben.

Marktanalyse

Unter Berücksichtigung der in dem ersten Teil ausgedrückten Wünsche und der Entscheidung, auf ein Update des bestehenden Systems zu verzichten, haben wir ein Lastenheft erstellt, um eine Lösung auf dem Markt zu finden, und Anfragen an mehrere große Unternehmen gesendet, die sich ausschließlich auf die Entwicklung industrieller SCADA-Systeme spezialisiert haben. 

Die ersten Antworten von ihnen zeigten, dass die Marktführer im Bereich der Überwachungssysteme überwiegend weiterhin auf physischen Servern arbeiten, obwohl der Prozess der Migration in die Cloud in diesem Segment bereits begonnen hat. Was das Backup von virtuellen Maschinen anbelangt – diese Option wurde von niemandem unterstützt. Darüber hinaus hatte man den Eindruck, dass kein namhafter Entwickler auf dem Markt auch nur ein Verständnis für die Notwendigkeit von Backup-Lösungen demonstrierte: „Die Cloud fällt doch nicht aus“ war die häufigste Antwort. Tatsächlich wurde uns angeboten, die Überwachung des Rechenzentrums in einer Cloud zu platzieren, die sich physisch im selben Rechenzentrum befindet.

Hier ist es wichtig, einen kurzen Exkurs zum Auswahlprozess für Auftragnehmer zu machen. Der Preis ist natürlich wichtig, aber während eines Ausschreibungsverfahrens für die Umsetzung eines komplexen Projekts spürt man im Dialog mit den Anbietern, welcher der Kandidaten wirklich interessiert und in der Lage ist, das Projekt umzusetzen. 

Das ist besonders bei komplexen Projekten deutlich zu erkennen. 

Anhand der Art der klärenden Fragen zum Lastenheft kann man die Auftragnehmer in zwei Gruppen unterteilen: diejenigen, die einfach verkaufen wollen (man spürt den Standarddruck des Vertriebsleiters) und diejenigen, die wirklich daran interessiert sind, ein Produkt zu entwickeln. Diese hören zu, verstehen den Auftraggeber, bringen konstruktive Änderungen am Lastenheft bereits vor der endgültigen Auswahl ein (trotz des tatsächlichen Risikos, die Vorgaben eines anderen zu verbessern und die Ausschreibung zu verlieren) und sind letztendlich bereit, sich der professionellen Herausforderung zu stellen und ein gutes Produkt zu liefern.

All dies führte dazu, dass wir die relativ kleine lokale Entwicklergruppe „Sanline“ ins Auge fassten, die auf die meisten unserer Anforderungen sofort reagierte und bereit war, alle Bedürfnisse in Bezug auf das neue BMS zu erfüllen. 

Risiken

Während die großen Akteure versuchten zu verstehen, was wir wollten, und einen langsamen Austausch mit Pre-Sales-Spezialisten führten, vereinbarte ein lokaler Entwickler ein Treffen in unserem Büro mit seinem technischen Team. Bei diesem Treffen zeigte der Auftragnehmer erneut sein Interesse an dem Projekt und erklärte vor allem, wie das benötigte System realisiert werden würde.    

Vor dem Treffen identifizierten wir zwei Risiken bei der Zusammenarbeit mit einem Team, das nicht die Rückendeckung eines großen nationalen oder internationalen Unternehmens hat:

1. Die Spezialisten könnten ihre Fähigkeiten überschätzen und letztlich scheitern, beispielsweise indem sie komplexe Software verwenden oder unerfüllbare Reservierungsalgorithmen entwerfen.
2. Nach der Umsetzung des Projekts könnte das Projektteam auseinanderfallen, wodurch die Unterstützung des Produkts gefährdet wäre.

Um diese Risiken zu minimieren, haben wir unsere eigenen Entwicklungsspezialisten zu dem Treffen eingeladen. Die Mitarbeiter des potenziellen Auftragnehmers wurden sorgfältig befragt, um zu klären, auf welcher Basis das System aufgebaut ist, wie die Sicherung umgesetzt werden soll und zu weiteren Fragen, in denen wir als Betriebsdienst nicht ausreichend kompetent sind.

Das Urteil war positiv: Die Architektur der bereits bestehenden BMS-Plattform ist modern, einfach und zuverlässig, kann weiterentwickelt werden, und das vorgeschlagene Schema für Backup und Synchronisation ist logisch und funktionsfähig. 

Das erste Risiko wurde bewältigt. Das zweite wurde ausgeschlossen, indem wir vom Auftragnehmer die Bestätigung erhielten, dass er bereit ist, uns den Quellcode des Systems sowie die Dokumentation zu übergeben, und durch die Wahl der Programmiersprache Python, die unseren Spezialisten gut vertraut ist. Dies gewährleistete uns die Möglichkeit, das System eigenständig zu unterstützen, ohne Schwierigkeiten und einen langen Ausbildungszeitraum für die Mitarbeiter im Falle des Abgangs des Entwicklungsunternehmens vom Markt.

Ein zusätzlicher Vorteil der Plattform war, dass sie in Docker-Containern implementiert wurde: In dieser Umgebung funktionieren das Kernsystem, die Weboberfläche und die Datenbank des Produkts. Dieser Ansatz bietet zahlreiche Vorteile, einschließlich der vorab konfigurierten Einstellungen für eine besonders schnelle Bereitstellung der Lösung im Vergleich zu traditionellen Ansätzen und der einfachen Integration neuer Geräte in das System. Das Prinzip "alles zusammen" vereinfacht die Implementierung des Systems erheblich: Es ist ausreichend, das System zu entpacken, und schon kann es in Betrieb genommen werden. 

Mit dieser Lösung wird es einfacher, Systemkopien zu erstellen, und sie kann in einer separaten Umgebung verbessert und upgegradet werden, ohne den Betrieb der Gesamtanwendung zu unterbrechen.  

Nachdem beide Risiken minimiert wurden, stellte der Auftragnehmer ein Angebot bereit. In diesem wurden alle für uns wichtigen Parameter des BMS-Systems detailliert ausgearbeitet.

Redundanz

Das neue BMS-System sollte in der Cloud auf einer virtuellen Maschine betrieben werden. 

Keine Hardware, keine Server und all die damit verbundenen Unannehmlichkeiten und Risiken dieser Bereitstellungsmodelle – die Cloud-Lösung hat es uns ermöglicht, diese für immer loszuwerden. Es wurde entschieden, dass das System in unserer Cloud an zwei Standorten der Rechenzentren in Sankt Petersburg und Moskau betrieben wird. Dies sind zwei vollständig funktionsfähige Systeme, die im Active-Standby-Modus arbeiten und für alle autorisierten Fachkräfte zugänglich sind. 

Die beiden Systeme sichern sich gegenseitig ab und gewährleisten vollständige Redundanz sowohl in Bezug auf die Rechenleistung als auch auf die Datenübertragungswege. Außerdem wurden zusätzliche Sicherheitsmaßnahmen eingerichtet, einschließlich der Sicherung von Daten und Kommunikationskanälen sowie von Systemen und virtuellen Maschinen insgesamt, sowie einer separaten Datenbanksicherung einmal im Monat (die wertvollste Ressource für das Management und die Analyse auf lange Sicht). 

Es ist erwähnenswert, dass die Sicherung als Option für die BMS-Lösung speziell nach unserem Wunsch entwickelt wurde. Das Sicherungsschema sah folgendermaßen aus:

Support

Ein entscheidender Punkt für die effektive Nutzung der BMS-Lösung ist der technische Support. 

Hier ist alles einfach: Ein neues System würde uns in dieser Hinsicht 35.000 Rubel pro Monat für SLA „Reaktion innerhalb von 8 Stunden“ kosten, das sind also 35.000 x 12 / 80 = 5.250 $ pro Jahr. Das erste Jahr – kostenlos. 

Im Vergleich dazu kostete die Unterstützung der alten BMS vom Anbieter 18.000 $ pro Jahr, wobei die Summe für jedes neue hinzugefügte Gerät anstieg! Gleichzeitig stellte das Unternehmen keinen eigenen Manager zur Verfügung; die gesamte Interaktion erfolgte über den Verkaufsleiter, der uns als potenziellen Käufer mit entsprechendem Fokus auf die Bearbeitung von Anfragen betrachtete. 

Für weniger Geld erhielten wir umfassenden Produktsupport mit einem Account-Manager, der an der Produktentwicklung beteiligt war, einer zentralen Anlaufstelle usw. Der Support wurde erheblich flexibler – dank des direkten Zugangs zu den Entwicklern für zeitnahe Anpassungen in allen Aspekten des Systembetriebs, der Integration über API usw.

Updates

Nach dem vorgeschlagenen Kostenvoranschlag sind alle Updates in den Support-Kosten der neuen BMS enthalten, d.h. sie erfordern keine zusätzliche Zahlung. Ausgenommen sind die Entwicklung zusätzlicher Funktionen, die über das im Pflichtenheft angegebene hinausgehen. 

Das alte System sah Zahlungen sowohl für Updates der eingebauten kostenlosen Software (wie z.B. Java) als auch für Fehlerbehebungen vor. Daran konnten wir nicht vorbeikommen; ohne Updates funktionierte das System insgesamt „träge“ aufgrund der veralteten Versionen interner Komponenten.

Und selbstverständlich war es nicht möglich, die Software zu aktualisieren, ohne ein Support-Paket zu kaufen.

Flexibler Ansatz

Ein weiteres grundlegendes Anliegen betraf die Benutzeroberfläche. Wir wollten den Zugriff über einen Webbrowser von jedem Ort aus ermöglichen, ohne dass ein Ingenieur vor Ort im Rechenzentrum anwesend sein muss. Darüber hinaus strebten wir die Entwicklung einer animierten Benutzeroberfläche an, um die Dynamik der Infrastruktur besser verständlich für die wartenden Ingenieure zu machen. 

In dem neuen System war es auch notwendig, Unterstützung für Formeln zur Berechnung der Arbeit von virtuellen Sensoren in Ingenieursystemen bereitzustellen – beispielsweise für die optimale Verteilung der elektrischen Leistung auf die Serverracks. Dafür müssen alle gängigen mathematischen Operationen an den Sensordaten zur Verfügung stehen. 

Darüber hinaus war der Zugriff auf eine SQL-Datenbank erforderlich, um die benötigten Informationen über den Betrieb der Geräte abzurufen – insbesondere alle Aufzeichnungen zur Überwachung von zweitausend Geräten und zweitausend virtuellen Sensoren, die etwa 20.000 Variablen erzeugen. 

Ein Modul zur Erfassung des Gerätebestands im Rack war ebenfalls notwendig, das eine grafische Darstellung der Geräteanordnung in jeder Einheit bietet, die das Gesamtgewicht der Hardware berechnet und eine Bibliothek von Geräten sowie detaillierte Informationen zu jedem Element führt. 

Abstimmung des Lastenhefts und Unterzeichnung des Vertrags

Zu dem Zeitpunkt, als es notwendig war, mit der Arbeit an dem neuen System zu beginnen, war die Kommunikation mit den "großen" Unternehmen noch weit entfernt von einer Diskussion über die Kosten ihrer Angebote. Daher haben wir das erhaltene Angebot mit den Kosten für die Aktualisierung des alten BMS verglichen (siehe den ersten Teil), und das Ergebnis war preislich attraktiver und entsprach unseren Anforderungen.

Die Entscheidung wurde getroffen.

Nachdem der Auftragnehmer ausgewählt war, begannen die Juristen mit der Erstellung des Vertrags, während die technischen Teams beider Seiten das Pflichtenheft verfeinerten. Wie bekannt ist, ist ein detailliertes und gut formuliertes Pflichtenheft die Grundlage für den Erfolg aller Arbeiten. Je konkreter das Pflichtenheft ist, desto weniger Enttäuschungen gibt es wie "aber wir wollten das nicht so".

Ich werde zwei Beispiele für den Detaillierungsgrad der Anforderungen im Pflichtenheft anführen:

1. Die zuständigen Rechenzentrumsmitarbeiter sind befugt, neue Geräte in das BMS hinzuzufügen, in der Regel handelt es sich dabei um PDUs. In der alten BMS war dies auf der Ebene des "Administrators" möglich, wodurch man unter anderem die Einstellungen aller Geräte ändern konnte. Eine Trennung der Funktionen war nicht möglich, was uns nicht zufriedenstellte. In der bestehenden Basisversion der neuen Plattform war das Schema ähnlich. Wir haben in den Anforderungen von Anfang an klargestellt, dass wir diese Rollen trennen möchten: Einstellungen sollen nur von autorisierten Mitarbeitern geändert werden dürfen, während die zuständigen Mitarbeiter weiterhin Geräte hinzufügen können. Dieses Schema wurde zur Umsetzung angenommen.
2.  In jedem Standard-Betriebsmanagementsystem (BMS) gibt es drei Hauptkategorien von Benachrichtigungen: ROT – sofortige Reaktion erforderlich, GELB – kann beobachtet werden, BLAU – „Information“. Wir haben traditionell „blaue“ Benachrichtigungen zur Überwachung von Überschreitungen geschäftlicher Parameter verwendet, wie beispielsweise das Überschreiten des Leistungsgrenzwerts eines Kunden-Racks. Dieser Benachrichtigungstyp war in unserem Fall für die Manager gedacht und daher für den operativen Dienst nicht von Interesse. Allerdings hat er in der alten BMS regelmäßig die Liste aktiver Vorfälle verstopft und die Betriebsabläufe gestört. Die Logik und die farbliche Unterscheidung der Benachrichtigungen haben wir als gelungen erachtet und beibehalten. Im Pflichtenheft haben wir jedoch ausdrücklich festgelegt, dass die „blauen“ Benachrichtigungen lautlos in einen separaten Bereich „fallen“, ohne die Bereitschaftsdienste abzulenken, wo sich die Fachleute um sie kümmern werden.

In ähnlicher Detailtiefe wurden die Formate für die Erstellung von Diagrammen und die Ausgabe von Berichten, die Umrisse der Benutzeroberflächen sowie die Liste der Geräte, die überwacht werden sollten, und viele weitere Dinge festgelegt. 

Das war wirklich eine kreative Zusammenarbeit von drei Arbeitsgruppen: dem Bestellservice, der seine Anforderungen und Bedingungen vorgab; den technischen Experten auf beiden Seiten, die diese Anforderungen in technische Dokumentationen umsetzten; sowie dem Programmierteam des Auftragnehmers, das die Anforderungen des Kunden gemäß der erstellten technischen Dokumentation implementierte. Letztendlich haben wir einige unserer nicht entscheidenden Anforderungen an die Funktionalität der bereits bestehenden Plattform angepasst, während der Auftragnehmer sich verpflichtete, einige Anforderungen für uns zu ergänzen. 

Parallelbetrieb von zwei Systemen

Es ist Zeit für die Umsetzung. Praktisch bedeutete dies, dass wir dem Auftragnehmer die Möglichkeit geben, einen Prototyp des BMS in unserer virtuellen Cloud bereitzustellen und Netzwerkzugang zu allen Geräten bereitstellen, die überwacht werden müssen.

Das neue System war jedoch noch nicht betriebsbereit. In dieser Phase war es wichtig, die Überwachung im alten System aufrechtzuerhalten und gleichzeitig den Zugriff auf die Geräte im neuen System zu ermöglichen. Es ist nicht möglich, ein System richtig aufzubauen, ohne die Geräte sehen zu können, die gleichzeitig nicht von der Überwachung des alten Systems getrennt werden können. 

Ob die Geräte eine gleichzeitige Abfrage durch zwei Systeme verkraften würden, war ohne reale Tests nicht offensichtlich. Es bestand die Möglichkeit, dass die doppelte gleichzeitige Abfrage zu häufigen Antwortausfällen von Geräten führen würde, wodurch wir zahlreiche Fehler bezüglich der Nichterreichbarkeit der Geräte erhielten, was wiederum die Funktionalität des alten Überwachungssystems blockieren würde.

Die Netzabteilung hat virtuelle Routen vom Prototyp der neuen BMS, die in der Cloud implementiert ist, zu den Geräten eingerichtet, und wir haben folgende Ergebnisse erhalten: 

• Geräte, die über das SNMP-Protokoll angeschlossen sind, fielen aufgrund der gleichzeitigen Zugriffe praktisch nicht aus. 
• Geräte, die über Gateways mit dem Modbus-TCP-Protokoll verbunden sind, hatten Probleme, die durch eine sinnvolle Reduzierung der Abfragefrequenz gelöst wurden.  

Und dann beobachteten wir, wie vor unseren Augen ein neues System entsteht, in dem bereits bekannte Geräte, jedoch mit einer anderen Benutzeroberfläche – benutzerfreundlich, schnell und sogar vom Handy aus zugänglich – auftauchen.

Wie das Endergebnis aussieht, werden wir im dritten Teil unseres Artikels erläutern.

Quelle: habr.com