Überwachung im Rechenzentrum: Wie wir die alte BMS durch eine neue ersetzt haben. Teil 2

Im ersten Teil haben wir erklärt, warum wir beschlossen haben, unser altes BMS-System in unseren Rechenzentren gegen ein neues auszutauschen. Und nicht einfach auszutauschen, sondern es von Grund auf neu nach unseren Anforderungen zu entwickeln. Im zweiten Teil erzählen wir, wie wir das gemacht haben.

Marktanalyse

Unter Berücksichtigung der in ersten Teils beschriebenen Wünsche und der Entscheidung, auf eine Aktualisierung des bestehenden Systems zu verzichten, haben wir ein Lastenheft zur Suche nach einer Lösung auf dem Markt erstellt und mehrere große Unternehmen angeschrieben, die sich ausschließlich mit der Erstellung industrieller SCADA-Systeme beschäftigen. 

Die ersten Antworten von ihnen zeigten, dass die Marktführer im Bereich Monitoring überwiegend weiterhin auf physischen Servern arbeiten, obwohl der Migrationsprozess in die Cloud in diesem Segment bereits begonnen hat. Was die Hochverfügbarkeit virtueller Maschinen angeht – diese Option wurde von niemandem unterstützt. Darüber hinaus hatte man das Gefühl, dass keiner der bemerkenswerten Entwickler auf dem Markt sogar das Verständnis für die Notwendigkeit von Hochverfügbarkeiten demonstriert hat: "Die Cloud fällt schließlich nicht aus" war die am häufigsten gegebene Antwort. Tatsächlich wurde uns angeboten, das Monitoring des Rechenzentrums in einer Cloud zu platzieren, die sich physisch in demselben Rechenzentrum befindet.

Hier ist es notwendig, einen kleinen Einschub zum Auswahlprozess des Auftragnehmers zu machen. Der Preis spielt natürlich eine Rolle, aber während jedes Ausschreibungsverfahrens für die Umsetzung eines komplexen Projekts, in der Dialogphase mit den Anbietern, beginnt man zu spüren, welcher der Kandidaten mehr interessiert und in der Lage ist, das Projekt umzusetzen. 

Das ist besonders bei komplexen Projekten auffällig. 

Anhand der Art der Rückfragen zum Lastenheft kann man die Auftragnehmer in solche unterteilen, die einfach nur daran interessiert sind, zu verkaufen (der Standarddruck eines Vertriebsmitarbeiters ist spürbar) und solche, die daran interessiert sind, ein Produkt zu entwickeln, indem sie den Kunden hören und verstehen, konstruktive Änderungen am Lastenheft noch vor der endgültigen Auswahl einbringen (trotz des realen Risikos, ein fremdes Lastenheft zu verbessern und den Auftrag zu verlieren), und letztlich einfach bereit sind, eine professionelle Herausforderung anzunehmen und ein gutes Produkt zu erstellen.

All dies führte dazu, dass wir unsere Aufmerksamkeit auf einen relativ kleinen lokalen Entwickler – die Unternehmensgruppe „Sanline“ – lenkten, die sofort auf die meisten unserer Anforderungen einging und bereit war, all unsere Bedürfnisse in Bezug auf das neue BMS umzusetzen. 

Risiken

Während die großen Akteure versuchten zu verstehen, was wir wollten, und eine langsame Korrespondenz mit Fachleuten der Pre-Sales-Ebene führten, organisierte ein lokaler Entwickler ein Treffen in unserem Büro mit seiner technischen Mannschaft. Bei diesem Treffen zeigte der Auftragnehmer erneut den Wunsch, am Projekt teilzunehmen und erklärte vor allem, wie das erforderliche System umgesetzt werden würde.    

Vor dem Treffen sahen wir zwei Risiken im Umgang mit einem Team, das nicht über die Ressourcen eines großen nationalen oder internationalen Unternehmens verfügte:

1. Die Fachkräfte könnten ihre Möglichkeiten überschätzen und am Ende einfach versagen, beispielsweise indem sie komplexe Software verwenden oder nicht umsetzbare Reservierungsalgorithmen entwerfen.
2. Nach der Umsetzung des Projekts könnte das Projektteam auseinanderfallen und damit wäre die Produktunterstützung gefährdet.

Um diese Risiken zu minimieren, luden wir unsere eigenen Entwicklungsspezialisten zum Treffen ein. Die Mitarbeiter des potenziellen Auftragnehmers wurden gründlich zu den Grundlagen des Systems befragt, wie die Reservierung geplant wird und zu anderen Fragen, in denen wir als Betriebsabteilung nicht ausreichend kompetent sind.

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

Das erste Risiko haben wir bewältigt. Das zweite haben wir ausgeschlossen, indem wir vom Auftragnehmer die Bestätigung erhalten haben, uns die Quellcodes des Systems und der Dokumentation zu übergeben, sowie indem wir die Programmiersprache Python wählten, die unseren Fachleuten gut bekannt ist. Das garantierte uns die Möglichkeit, das System eigenständig ohne irgendwelche Schwierigkeiten und lange Schulungszeiten für die Mitarbeiter zu unterstützen, falls der Entwicklungsunternehmer den Markt verlässt.

Ein zusätzlicher Vorteil der Plattform war, dass sie in Docker-Containern implementiert wurde: In dieser Umgebung funktionieren sowohl das Kernel, die Web-Oberfläche als auch die Datenbank des Produkts. Dieser Ansatz bietet zahlreiche Vorteile, einschließlich der vorinstallierten Einstellungen für die höchste Geschwindigkeit bei der Bereitstellung der Lösung im Vergleich zum "Klassischen" und der einfachen Integration neuer Geräte in das System. Das Prinzip "alles zusammen" vereinfacht die Implementierung des Systems erheblich: Es genügt, das System zu entpacken, und man kann es sofort nutzen. 

Mit dieser Lösung ist es einfacher, Systemkopien zu erstellen, und man kann sie in einer separaten Umgebung verbessern und aktualisieren, ohne den Betrieb der Lösung insgesamt anzuhalten.  

Nachdem beide Risiken minimiert worden waren, stellte der Auftragnehmer das Angebot bereit. Darin wurden alle für uns wichtigsten Parameter des BMS-Systems ausgearbeitet.

Reservierung

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

Kein Hardware, keine Server und all die mit diesem Bereitstellungsmodell verbundenen Unannehmlichkeiten und Risiken – die Cloud-Lösung ermöglichte es uns, sie für immer loszuwerden. Es wurde beschlossen, dass das System in unserer Cloud an zwei Standorten der Rechenzentren in Sankt Petersburg und Moskau betrieben wird. Dies sind zwei voll funktionsfähige Systeme, die im Active-Standby-Modus mit Zugang für alle autorisierten Fachkräfte arbeiten. 

Die beiden Systeme sichern sich gegenseitig ab und gewährleisten vollständige Redundanz sowohl in der Rechenleistung als auch in den Datenübertragungskanälen. Es wurden auch zusätzliche Sicherheitsmaßnahmen eingerichtet, einschließlich der Daten- und Kanal-Backups, der Backup-Systeme, virtuellen Maschinen insgesamt und einem separaten Backup der Datenbank einmal im Monat (die wertvollste Ressource für zukünftiges Management und Analyse). 

Es sei darauf hingewiesen, dass die Reservierung als Option des BMS-Systems speziell auf unsere Anfrage hin entwickelt wurde. Das Reservierungsschema sah folgendermaßen aus:

Bestellen

Ein entscheidender Punkt für den effektiven Betrieb des BMS-Systems ist der technische Support. 

Hier ist alles einfach: Das neue System würde uns in diesem Punkt 35.000 Rubel im Monat für SLA "Reaktion innerhalb von 8 Stunden" kosten, also 35.000 x 12 / 80 = 5.250 $ pro Jahr. Im ersten Jahr kostenlos. 

Zum Vergleich: Die Unterstützung des alten BMS vom Anbieter kostete jährlich 18.000 Dollar, wobei sich der Betrag für jedes neu hinzugefügte Gerät erhöhte! Dabei stellte das Unternehmen keinen dedizierten Manager zur Verfügung; die gesamte Kommunikation erfolgte über den Vertriebsmanager, der an uns als potenziellen Käufer interessiert war, mit entsprechendem Fokus auf die Bearbeitung der Anfragen. 

Für weniger Geld erhielten wir eine umfassende Produktunterstützung mit einem Account-Manager, der an der Produktentwicklung beteiligt war, einer einzigen Anlaufstelle usw. Die Unterstützung wurde erheblich flexibler – dank des direkten Zugriffs auf die Entwickler für schnelle Anpassungen in allen Aspekten des Systembetriebs, Integration über API usw.

Updates

Im zugesandten Angebot der neuen BMS sind alle Updates im Supportpreis enthalten, d.h. sie erfordern keine zusätzliche Bezahlung. Ausnahmen bilden die Entwicklung zusätzlicher Funktionen, die über das im Lastenheft angegebene Maß hinausgehen. 

Das alte System sah Zahlungen sowohl für die Aktualisierung der integrierten kostenlosen Software (wie Java) als auch für Fehlerbehebungen vor. Darauf konnte man nicht verzichten; ohne Updates lief das System insgesamt „langsam“, da es auf alten Versionen interner Komponenten basierte.

Und natürlich konnte die Software nicht ohne den Kauf eines Supportpakets aktualisiert werden.

Flexibler Ansatz

Ein weiteres wichtiges Anliegen betraf die Benutzeroberfläche. Wir wollten den Zugriff darauf über einen Webbrowser von jedem Ort aus ermöglichen, ohne dass ein Ingenieur vor Ort im Rechenzentrum sein musste. Außerdem strebten wir die Schaffung einer animierten Benutzeroberfläche an, um die Dynamik der Infrastruktur für die wartenden Ingenieure anschaulicher zu machen. 

In der neuen System musste auch die Unterstützung von Formeln zur Berechnung der Arbeit virtueller Sensoren in Ingenieursystemen gewährleistet sein – beispielsweise zur optimalen Verteilung elektrischer Leistungen auf die Server mit der Ausrüstung. Dafür mussten alle gewohnten mathematischen Operationen vorhanden sein, die auf die Messwerte der Sensoren anwendbar sind. 

Außerdem war ein Zugang zur SQL-Datenbank erforderlich, um die benötigten Daten über den Betrieb der Geräte abzurufen – insbesondere alle Protokolle zur Überwachung von zweitausend Geräten und zweitausend virtuellen Sensoren, die etwa zwanzigtausend Variablen generieren. 

Benötigt wurde auch ein Modul zur Erfassung der Geräte im Rack, das eine grafische Darstellung der Anordnung der Geräte in jeder Einheit bietet, mit einer Zusammenstellung des Gesamtgewichts der Hardware, einer Gerätedatenbank und detaillierten Informationen zu jedem Element. 

Abstimmung des Lastenhefts und Unterzeichnung des Vertrags

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

Die Wahl wurde getroffen.

Nach der Auswahl des Auftragnehmers begannen die Juristen mit dem Vertragsentwurf, während die technischen Teams beider Seiten das Lastenheft verfeinerten. Wie bekannt ist, ist ein detailliertes und gut formuliertes Lastenheft die Basis für den Erfolg aller Arbeiten. Je mehr Konkretes im Lastenheft steht, desto weniger Enttäuschungen wie "aber so wollten wir es nicht".

Ich nenne zwei Beispiele für den Detaillierungsgrad der Anforderungen im Lastenheft:

1. Die Betriebs-IT-Räuber haben die Befugnis, neue Geräte in die BMS einzufügen, meist handelt es sich um PDUs. In der alten BMS war dies die Administratoren-Ebene, die es unter anderem ermöglichte, die Einstellungen aller Gerätevorgaben zu ändern, und eine Trennung der Funktionen war nicht möglich. Das war für uns nicht akzeptabel. In der vorhandenen Basisversion der neuen Plattform war das Schema ähnlich. Wir haben im Lastenheft sofort angegeben, dass wir diese Rollen teilen möchten: Die Einstellungen soll nur ein autorisierter Mitarbeiter ändern dürfen, aber die Betriebs-IT-Räuber müssen weiterhin die Möglichkeit haben, Geräte hinzuzufügen. Dieses Schema wurde zur Umsetzung angenommen.
2.  In jedem Standard-BMS gibt es drei typische Kategorien von Benachrichtigungen: ROT – sofort reagieren, GELB – beobachten, BLAU – „Information“. Wir haben traditionell „blaue“ Benachrichtigungen zur Überwachung von Überschreitungen gewerblicher Parameter verwendet, wie z. B. das Überschreiten des maximalen Leistungsgrenzwerts eines Kundenracks. Diese Art von Benachrichtigungen war in unserem Fall für die Manager gedacht und daher für den operativen Dienst uninteressant, führte aber in der alten BMS regelmäßig zu einer Überfüllung der Liste aktiver Vorfälle, was die tägliche Arbeit störte. Die Logik und Farbdifferenzierung der Benachrichtigungen fanden wir gelungen und behielten sie bei, jedoch haben wir im Lastenheft ausdrücklich festgelegt, dass die „blauen“ Benachrichtigungen, ohne die Aufsichtskräfte abzulenken, geräuschlos in einen separaten Abschnitt „fallen“ sollten, wo sie von den kommerziellen Spezialisten bearbeitet werden.

Mit ähnlicher Detailgenauigkeit wurden die Formate zur Erstellung von Grafiken und Berichten, die Umrisse der Schnittstellen, die Liste der zu überwachenden Geräte und viele weitere Dinge festgelegt. 

Es war eine wirklich kreative Arbeit von drei Arbeitsgruppen – dem Auftraggeber, der seine Anforderungen und Bedingungen diktierte; technischen Spezialisten beider Seiten, deren Aufgabe es war, diese Bedingungen in technische Dokumentation umzuwandeln; und dem Team von Programmierern des Auftragnehmers, die die Anforderungen des Auftraggebers gemäß der entwickelten technischen Dokumentation umsetzten… Letztlich passten wir einige unserer nicht grundlegenden Anforderungen an die Funktionalität der bereits bestehenden Plattform an, während der Auftragnehmer sich verpflichtete, andere Anforderungen für uns zu ergänzen. 

Parallelarbeit von zwei Systemen

Die Zeit für die Umsetzung war gekommen. In der Praxis bedeutete dies, dass wir dem Auftragnehmer die Möglichkeit geben, einen Prototyp des BMS in unserer virtuellen Cloud zu implementieren und Netzwerkzugang zu allen Geräten zu ermöglichen, die überwacht werden müssen.

Zu diesem Zeitpunkt war das neue System jedoch noch nicht betriebsbereit. In dieser Phase war es für uns wichtig, die Überwachung im alten System aufrechtzuerhalten und gleichzeitig den Zugang zu den Geräten im neuen System zu ermöglichen. Es ist unmöglich, ein System vernünftig zu gestalten, ohne die Geräte zu sehen, die zudem nicht von der Überwachung des alten Systems getrennt werden können. 

Obehalten die Geräte die gleichzeitige Abfrage durch zwei Systeme, war ohne reale Tests nicht eindeutig. Es bestand die Möglichkeit, dass eine doppelte gleichzeitige Abfrage zu häufigen Antwortausfällen der Geräte führt und wir eine Vielzahl von Fehlern aufgrund der Nichterreichbarkeit der Geräte erhalten, was wiederum die Funktion des alten Überwachungssystems blockiert.

Die Netzwerkabteilung hat virtuelle Routen vom Prototyp der neuen BMS, die in der Cloud bereitgestellt wurde, zu den Geräten gelegt, und wir erhielten folgende Ergebnisse: 

• Geräte, die über das SNMP-Protokoll angeschlossen sind, fielen praktisch nicht aufgrund von gleichzeitigen Anfragen aus, 
• Geräte, die über Gateways mit modbas-TCP-Protokollen 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 entstand, in dem bereits bekannte Geräte erscheinen, jedoch in einer anderen Benutzeroberfläche – bequem, schnell und sogar mit dem Telefon zugänglich.

Was letztendlich entstanden ist, werden wir im dritten Teil unseres Artikels erzählen.

Quelle: habr.com