Überwachung im Rechenzentrum: Wie wir das alte BMS auf das neue umgestellt haben. Teil 2

Im ersten Teil haben wir darüber gesprochen, warum wir uns entschieden haben, das alte BMS-System in unseren Rechenzentren durch ein neues zu ersetzen. Und nicht nur verändern, sondern ganz nach Ihren Anforderungen weiterentwickeln. Im zweiten Teil erzählen wir Ihnen, wie wir es gemacht haben.

Marktanalyse

Unter Berücksichtigung der in der erste Teil Aufgrund unserer Wünsche und der Entscheidung, die Aktualisierung des bestehenden Systems abzulehnen, verfassten wir eine technische Spezifikation, um eine Lösung auf dem Markt zu finden, und stellten Anfragen bei mehreren großen Unternehmen, die sich ausschließlich mit der Entwicklung industrieller SCADA-Systeme befassen. 

Die allerersten Rückmeldungen von ihnen zeigten, dass die Marktführer im Bereich Überwachungssysteme weiterhin hauptsächlich an Hardware-Servern arbeiten, obwohl der Prozess der Migration in die Cloud in diesem Segment bereits begonnen hat. Was die Reservierung virtueller Maschinen betrifft, wurde diese Option von niemandem unterstützt. Darüber hinaus herrschte das Gefühl, dass keiner der auf dem Markt sichtbaren Entwickler überhaupt Verständnis für die Notwendigkeit von Redundanz zeigte: „Die Cloud fällt nicht“, lautete die häufigste Antwort. Tatsächlich wurde uns angeboten, die Rechenzentrumsüberwachung in einer Cloud zu platzieren, die sich physisch im selben Rechenzentrum befindet.

Hier müssen wir einen kleinen Exkurs über den Prozess der Auswahl eines Auftragnehmers machen. Natürlich spielt der Preis eine Rolle, aber bei jeder Ausschreibung für die Umsetzung eines komplexen Projekts beginnt man in der Phase des Dialogs mit den Lieferanten zu spüren, welcher der Kandidaten mehr Interesse und Fähigkeit zur Umsetzung hat. 

Dies macht sich insbesondere bei komplexen Projekten bemerkbar. 

Aufgrund der Art der Klärung von Fragen zu den technischen Spezifikationen können Auftragnehmer in diejenigen unterteilt werden, die nur am Verkauf interessiert sind (der übliche Druck eines Vertriebsleiters ist zu spüren) und diejenigen, die daran interessiert sind, ein Produkt zu entwickeln, den Kunden gehört und verstanden zu haben und konstruktiv zu gestalten Sie nehmen bereits vor der endgültigen Entscheidung Änderungen an den technischen Spezifikationen vor (auch trotz des realen Risikos, die technischen Spezifikationen eines anderen zu verbessern und die Ausschreibung zu verlieren), am Ende sind sie einfach bereit, eine berufliche Herausforderung anzunehmen und ein gutes Produkt herzustellen.

All dies veranlasste uns, unsere Aufmerksamkeit auf einen relativ kleinen lokalen Entwickler zu richten – die Sunline-Unternehmensgruppe, die sofort auf die meisten unserer Anforderungen reagierte und bereit war, alle Anforderungen bezüglich des neuen BMS umzusetzen. 

Risiken

Während die Großen versuchten zu verstehen, was wir wollten, und gemächlich mit uns unter Beteiligung von Spezialisten auf Vorverkaufsebene korrespondierten, vereinbarte der örtliche Entwickler ein Treffen in unserem Büro, an dem sein technisches Team teilnahm. Bei diesem Treffen bekundete der Auftragnehmer erneut seinen Wunsch, sich an dem Projekt zu beteiligen, und erläuterte vor allem, wie das erforderliche System implementiert werden soll.    

Vor dem Treffen sahen wir zwei Risiken bei der Zusammenarbeit mit einem Team, das nicht über die Ressourcen eines großen nationalen oder internationalen Unternehmens verfügt:

1. Spezialisten könnten ihre Fähigkeiten überschätzen und deshalb einfach nicht damit klarkommen, indem sie beispielsweise komplexe Software verwenden oder undurchführbare Reservierungsalgorithmen entwickeln.
2. Nach Abschluss des Projekts kann es sein, dass das Projektteam auseinanderfällt und somit der Produktsupport gefährdet ist.

Um diese Risiken zu minimieren, haben wir unsere eigenen Entwicklungsspezialisten zu dem Treffen eingeladen. Die Mitarbeiter des potenziellen Auftragnehmers wurden ausführlich befragt, worauf das System basiert, wie die Redundanz umgesetzt werden soll und zu anderen Themen, in denen wir als Betriebsdienst nicht kompetent genug sind.

Das Urteil fiel positiv aus: Die Architektur der bestehenden BMS-Plattform ist modern, einfach und zuverlässig, verbesserungswürdig, das vorgeschlagene Redundanz- und Synchronisationsschema ist logisch und praktikabel. 

Das erste Risiko wurde bewältigt. Der zweite wurde ausgeschlossen, nachdem der Auftragnehmer die Bestätigung erhalten hatte, dass er bereit sei, den Quellcode des Systems und die Dokumentation an uns zu übertragen, und indem er sich auch für die Programmiersprache Python entschieden habe, die unseren Spezialisten gut bekannt sei. Dies garantierte uns die Möglichkeit, das System problemlos selbst warten zu können und eine lange Einarbeitungszeit der Mitarbeiter für den Fall eines Marktaustritts der Entwicklungsfirma.

Ein weiterer Vorteil der Plattform bestand darin, dass sie in Docker-Containern implementiert wurde: Der Kernel, das Webinterface und die Produktdatenbank funktionieren in dieser Umgebung. Dieser Ansatz bietet viele Vorteile, einschließlich voreingestellter Einstellungen für die höchste Bereitstellungsgeschwindigkeit der Lösung im Vergleich zum „klassischen“ und der einfachen Hinzufügung neuer Geräte zum System. Das „Alles zusammen“-Prinzip vereinfacht die Implementierung des Systems weitestgehend: Einfach das System auspacken und schon kann es sofort genutzt werden. 

Mit dieser Lösung ist es einfacher, Kopien des Systems zu erstellen und es in einer separaten Umgebung zu verbessern und Upgrades durchzuführen, ohne den Betrieb der Lösung als Ganzes zu unterbrechen.  

Nachdem beide Risiken minimiert waren, stellte der Auftragnehmer den CP zur Verfügung. Es deckte für uns alle wichtigen Parameter des BMS-Systems ab.

Reservierung

Das neue BMS-System musste in der Cloud auf einer virtuellen Maschine liegen. 

Keine Hardware, keine Server und alle mit diesem Bereitstellungsmodell verbundenen Unannehmlichkeiten und Risiken – die Cloud-Lösung ermöglichte es uns, sie für immer loszuwerden. Es wurde beschlossen, das System in unserer Cloud an zwei Rechenzentrumsstandorten in St. Petersburg und Moskau zu betreiben. Hierbei handelt es sich um zwei voll funktionsfähige Systeme, die im aktiven Standby-Modus arbeiten und Zugriff auf alle autorisierten Spezialisten haben. 

Die beiden Systeme sichern sich gegenseitig ab und bieten die volle Reserve sowohl an Rechenleistung als auch an Datenübertragungskanälen. Außerdem wurden zusätzliche Sicherheitsmaßnahmen konfiguriert, darunter die Sicherung von Daten und Kanälen, Systemen und virtuellen Maschinen im Allgemeinen sowie eine separate Datenbanksicherung einmal im Monat (die wertvollste Ressource im Hinblick auf Verwaltung und Analyse). 

Beachten Sie, dass Redundanz als Option in der BMS-Lösung speziell für unsere Anfrage entwickelt wurde. Das Reservierungsschema selbst sah folgendermaßen aus:

Unterstützen

Der wichtigste Punkt für den effektiven Betrieb einer BMS-Lösung ist der technische Support. 

Hier ist alles einfach: Ein neues System würde uns nach diesem Indikator 35 Rubel kosten. pro Monat für das SLA „Antwort innerhalb von 000 Stunden“, also 8 x 35 / 000 = 12 $ pro Jahr. Das erste Jahr ist kostenlos. 

Zum Vergleich: Die Wartung des alten BMS vom Hersteller kostete 18 US-Dollar pro Jahr, wobei sich der Betrag für jedes neue Gerät erhöhte! Gleichzeitig stellte das Unternehmen keinen eigenen Manager zur Verfügung; die gesamte Interaktion erfolgte über einen Vertriebsleiter, der sich für uns als potenziellen Käufer interessiert und entsprechend viel Wert auf die Bearbeitung von Anfragen legt. 

Für weniger Geld erhielten wir vollständigen Produktsupport, mit einem Account Manager, der an der Produktentwicklung beteiligt war, mit einem zentralen Einstiegspunkt usw. Der Support wurde viel flexibler – dank des direkten Zugriffs auf Entwickler für zeitnahe Anpassungen an allen Aspekten des Systems, der Integration über API usw.

Updates

Gemäß dem vorgeschlagenen CP im neuen BMS sind alle Updates in den Supportkosten enthalten, d. h. erfordern keine zusätzliche Zahlung. Eine Ausnahme bildet die Entwicklung zusätzlicher Funktionalitäten, die über die Spezifikationen der technischen Spezifikationen hinausgehen. 

Das alte System erforderte eine Zahlung sowohl für Firmware-Updates (z. B. Java) als auch für Fehlerbehebungen. Dies konnte man nicht ablehnen, denn ohne Updates wurde das System insgesamt aufgrund alter Versionen interner Komponenten „verlangsamt“.

Und natürlich war es unmöglich, die Software zu aktualisieren, ohne ein Support-Paket zu kaufen.

Flexibler Ansatz

Eine weitere grundlegende Anforderung betraf die Schnittstelle. Wir wollten den Zugriff darauf über einen Webbrowser von überall aus ermöglichen, ohne dass ein Techniker auf dem Gelände des Rechenzentrums zwingend anwesend sein muss. Darüber hinaus wollten wir eine animierte Benutzeroberfläche erstellen, damit die Dynamik der Infrastruktur für die diensthabenden Ingenieure klarer wird. 

Auch im neuen System war es notwendig, Formeln zur Berechnung des Betriebs virtueller Sensoren in technischen Systemen zu unterstützen – beispielsweise für die optimale Verteilung der elektrischen Energie auf Geräteträger. Dazu müssen Sie über alle üblichen mathematischen Operationen verfügen, die für Sensorindikatoren gelten. 

Als nächstes war der Zugriff auf eine SQL-Datenbank mit der Möglichkeit erforderlich, daraus die notwendigen Daten zum Betrieb der Ausrüstung zu entnehmen – nämlich alle Überwachungsaufzeichnungen von zweitausend Geräten und zweitausend virtuellen Sensoren, die etwa 20 Variablen generieren. 

Außerdem wurde ein Rack-Geräteabrechnungsmodul benötigt, das eine grafische Darstellung der Anordnung der Geräte in jeder Einheit mit Berechnung des Gesamtgewichts der Hardware bereitstellt und eine Gerätebibliothek sowie detaillierte Informationen zu jedem Element verwaltet. 

Genehmigung technischer Spezifikationen und Unterzeichnung einer Vereinbarung

Zu dem Zeitpunkt, als es notwendig war, mit der Arbeit am neuen System zu beginnen, war die Korrespondenz mit „großen“ Unternehmen noch weit davon entfernt, die Kosten ihrer Vorschläge zu besprechen, daher haben wir die erhaltenen CP mit den Kosten für die Aktualisierung des alten BMS verglichen (siehe. der erste Teil) und erwies sich dadurch als preislich attraktiver und entsprach unseren Anforderungen.

Die Wahl wurde getroffen.

Nach der Auswahl eines Auftragnehmers begannen die Anwälte mit der Ausarbeitung einer Vereinbarung, und die technischen Teams beider Seiten begannen mit der Ausarbeitung der technischen Spezifikationen. Wie Sie wissen, sind detaillierte und kompetente technische Spezifikationen die Grundlage für den Erfolg jeder Arbeit. Je genauer die technischen Spezifikationen sind, desto weniger Enttäuschungen wie „Aber das ist nicht das, was wir wollten.“

Ich gebe zwei Beispiele für den Detaillierungsgrad der Anforderungen in den technischen Spezifikationen:

1. Im Dienst stehende Rechenzentren sind befugt, neue Geräte zum BMS hinzuzufügen. In den meisten Fällen handelt es sich dabei um PDUs. Im alten BMS war dies die „Administrator“-Ebene, die auch die Änderung der Variableneinstellungen aller Geräte ermöglichte und eine Trennung der Funktionen nicht möglich war. Das hat uns nicht gepasst. In der bestehenden Basisversion der neuen Plattform war das Schema ähnlich. Wir haben in der Leistungsbeschreibung sofort darauf hingewiesen, dass wir diese Rollen trennen wollen: Nur ein autorisierter Mitarbeiter soll die Einstellungen ändern, die Diensthabenden sollen aber weiterhin Geräte hinzufügen können. Dieses Schema wurde zur Umsetzung angenommen.
2.  In jedem Standard-BMS gibt es drei typische Kategorien von Benachrichtigungen: ROT – muss sofort beantwortet werden, GELB – kann beobachtet werden, BLAU – „informativ“. Traditionell verwenden wir blaue Alarme, um zu überwachen, wann Geschäftsparameter überschritten wurden, beispielsweise wenn das Rack eines Kunden seine Kapazitätsgrenze überschreitet. Diese Art der Benachrichtigung war in unserem Fall für Manager gedacht und für den Betriebsdienst nicht von Interesse, aber im alten BMS verstopfte sie regelmäßig die Liste der aktiven Vorfälle und beeinträchtigte die operative Arbeit. Wir hielten gerade die Logik und die farbliche Differenzierung der Benachrichtigungshosen für gelungen und haben sie beibehalten. In den technischen Spezifikationen wurde jedoch ausdrücklich darauf hingewiesen, dass „blaue“ Benachrichtigungen, ohne die diensthabenden Beamten abzulenken, stillschweigend in einen separaten Bereich „fließen“ sollten, wo sie werden von kaufmännischen Spezialisten bearbeitet.

Mit einem ähnlichen Detaillierungsgrad wurden die Formate für die Erstellung von Diagrammen und die Generierung von Berichten, die Umrisse von Schnittstellen, die Liste der zu überwachenden Geräte und viele andere Dinge vorgeschrieben. 

Dies war eine wirklich kreative Arbeit dreier Arbeitsgruppen – des Kundendienstes, der seine Anforderungen und Bedingungen diktierte; technische Spezialisten auf beiden Seiten, deren Aufgabe es war, diese Bedingungen in technische Dokumentation umzusetzen; Teams von Auftragnehmer-Programmierern, die die Anforderungen des Kunden gemäß der entwickelten technischen Dokumentation umgesetzt haben... Infolgedessen haben wir einige unserer nicht prinzipiellen Anforderungen an die Funktionalität einer vorhandenen Plattform angepasst, und der Auftragnehmer hat sich verpflichtet, etwas für uns hinzuzufügen. 

Parallelbetrieb zweier Systeme

Es ist Zeit für die Umsetzung. In der Praxis bedeutete dies, dass wir dem Auftragnehmer die Möglichkeit geben, einen BMS-Prototyp in unserer virtuellen Cloud bereitzustellen und allen Geräten, die eine Überwachung erfordern, Netzwerkzugriff zu gewähren.

Allerdings war das neue System noch nicht betriebsbereit. Zu diesem Zeitpunkt war es uns wichtig, die Überwachung im alten System aufrechtzuerhalten und gleichzeitig den Zugriff auf die Geräte im neuen System zu ermöglichen. Es ist unmöglich, ein System ordnungsgemäß aufzubauen, ohne darin Geräte zu sehen, die wiederum nicht von der Überwachung durch das alte System ausgeschlossen werden können. 

Ob die Geräte der gleichzeitigen Abfrage durch zwei Systeme standhalten, war ohne echte Tests nicht klar. Es bestand die Möglichkeit, dass doppelte gleichzeitige Abfragen dazu führten, dass die Geräte häufig nicht reagierten und wir viele Fehlermeldungen bezüglich der Nichtverfügbarkeit von Geräten erhielten, was wiederum den Betrieb des alten Überwachungssystems blockieren würde.

Die Netzwerkabteilung führte virtuelle Routen von einem in der Cloud bereitgestellten Prototyp des neuen BMS zu den Geräten durch und wir erhielten die Ergebnisse: 

• Geräte, die über das SNMP-Protokoll verbunden sind, werden praktisch nie aufgrund gleichzeitiger Anfragen getrennt, 
• Bei Geräten, die über Gateways mit Modbas-TCP-Protokollen verbunden waren, gab es Probleme, die durch eine intelligente Reduzierung ihrer Abfragehäufigkeit gelöst wurden.  

Und dann begannen wir zu beobachten, wie vor unseren Augen ein neues System aufgebaut wurde, in dem uns bereits bekannte Geräte auftauchten, aber in einer anderen Oberfläche – bequem, schnell, sogar über ein Telefon zugänglich.

Was am Ende passiert ist, verraten wir Ihnen im dritten Teil unseres Artikels.

Source: habr.com