{"id":80952,"date":"2020-05-10T01:42:22","date_gmt":"2020-05-09T23:42:22","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/monitoring-v-czode-kak-my-menyali-staruyu-bms-na-novuyu-chast-2"},"modified":"2020-05-10T01:42:22","modified_gmt":"2020-05-09T23:42:22","slug":"monitoring-v-czode-kak-my-menyali-staruyu-bms-na-novuyu-chast-2","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/monitoring-v-czode-kak-my-menyali-staruyu-bms-na-novuyu-chast-2","title":{"rendered":"\u00dcberwachung im Rechenzentrum: So haben wir das alte BMS durch das neue ersetzt. Teil 2","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"\u00dcberwachung<\/p>\n

Im ersten Teil haben wir erl\u00e4utert, 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\u00fcber, wie wir dies umgesetzt haben.
\n<\/a><\/noindex><\/p>\n

Marktanalyse<\/h2>\n

\nUnter Ber\u00fccksichtigung der in dem ersten Teil<\/a><\/noindex> ausgedr\u00fcckten W\u00fcnsche und der Entscheidung, auf ein Update des bestehenden Systems zu verzichten, haben wir ein Lastenheft erstellt, um eine L\u00f6sung auf dem Markt zu finden, und Anfragen an mehrere gro\u00dfe Unternehmen gesendet, die sich ausschlie\u00dflich auf die Entwicklung industrieller SCADA-Systeme spezialisiert haben.\u00a0<\/p>\n

Die ersten Antworten von ihnen zeigten, dass die Marktf\u00fchrer im Bereich der \u00dcberwachungssysteme \u00fcberwiegend 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 \u2013 diese Option wurde von niemandem unterst\u00fctzt. Dar\u00fcber hinaus hatte man den Eindruck, dass kein namhafter Entwickler auf dem Markt auch nur ein Verst\u00e4ndnis f\u00fcr die Notwendigkeit von Backup-L\u00f6sungen demonstrierte: \u201eDie Cloud f\u00e4llt doch nicht aus\u201c war die h\u00e4ufigste Antwort. Tats\u00e4chlich wurde uns angeboten, die \u00dcberwachung des Rechenzentrums in einer Cloud zu platzieren, die sich physisch im selben Rechenzentrum befindet.<\/p>\n

Hier ist es wichtig, einen kurzen Exkurs zum Auswahlprozess f\u00fcr Auftragnehmer zu machen. Der Preis ist nat\u00fcrlich wichtig, aber w\u00e4hrend eines Ausschreibungsverfahrens f\u00fcr die Umsetzung eines komplexen Projekts sp\u00fcrt man im Dialog mit den Anbietern, welcher der Kandidaten wirklich interessiert und in der Lage ist, das Projekt umzusetzen.\u00a0<\/p>\n

Das ist besonders bei komplexen Projekten deutlich zu erkennen.\u00a0<\/p>\n

Anhand der Art der kl\u00e4renden Fragen zum Lastenheft kann man die Auftragnehmer in zwei Gruppen unterteilen: diejenigen, die einfach verkaufen wollen (man sp\u00fcrt den Standarddruck des Vertriebsleiters) und diejenigen, die wirklich daran interessiert sind, ein Produkt zu entwickeln. Diese h\u00f6ren zu, verstehen den Auftraggeber, bringen konstruktive \u00c4nderungen am Lastenheft bereits vor der endg\u00fcltigen Auswahl ein (trotz des tats\u00e4chlichen 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.<\/p>\n

All dies f\u00fchrte dazu, dass wir die relativ kleine lokale Entwicklergruppe \u201eSanline\u201c ins Auge fassten, die auf die meisten unserer Anforderungen sofort reagierte und bereit war, alle Bed\u00fcrfnisse in Bezug auf das neue BMS zu erf\u00fcllen.\u00a0<\/p>\n

Risiken<\/h2>\n

\nW\u00e4hrend die gro\u00dfen Akteure versuchten zu verstehen, was wir wollten, und einen langsamen Austausch mit Pre-Sales-Spezialisten f\u00fchrten, vereinbarte ein lokaler Entwickler ein Treffen in unserem B\u00fcro mit seinem technischen Team. Bei diesem Treffen zeigte der Auftragnehmer erneut sein Interesse an dem Projekt und erkl\u00e4rte vor allem, wie das ben\u00f6tigte System realisiert werden w\u00fcrde.\u00a0\u00a0\u00a0\u00a0<\/p>\n

Vor dem Treffen identifizierten wir zwei Risiken bei der Zusammenarbeit mit einem Team, das nicht die R\u00fcckendeckung eines gro\u00dfen nationalen oder internationalen Unternehmens hat:<\/p>\n

    \n
  1. Die Spezialisten k\u00f6nnten ihre F\u00e4higkeiten \u00fcbersch\u00e4tzen und letztlich scheitern, beispielsweise indem sie komplexe Software verwenden oder unerf\u00fcllbare Reservierungsalgorithmen entwerfen.<\/li>\n
  2. Nach der Umsetzung des Projekts k\u00f6nnte das Projektteam auseinanderfallen, wodurch die Unterst\u00fctzung des Produkts gef\u00e4hrdet w\u00e4re.<\/li>\n<\/ol>\n

    \nUm diese Risiken zu minimieren, haben wir unsere eigenen Entwicklungsspezialisten zu dem Treffen eingeladen. Die Mitarbeiter des potenziellen Auftragnehmers wurden sorgf\u00e4ltig befragt, um zu kl\u00e4ren, 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.<\/p>\n

    Das Urteil war positiv: Die Architektur der bereits bestehenden BMS-Plattform ist modern, einfach und zuverl\u00e4ssig, kann weiterentwickelt werden, und das vorgeschlagene Schema f\u00fcr Backup und Synchronisation ist logisch und funktionsf\u00e4hig.\u00a0<\/p>\n

    Das erste Risiko wurde bew\u00e4ltigt. Das zweite wurde ausgeschlossen, indem wir vom Auftragnehmer die Best\u00e4tigung erhielten, dass er bereit ist, uns den Quellcode des Systems sowie die Dokumentation zu \u00fcbergeben, und durch die Wahl der Programmiersprache Python, die unseren Spezialisten gut vertraut ist. Dies gew\u00e4hrleistete uns die M\u00f6glichkeit, das System eigenst\u00e4ndig zu unterst\u00fctzen, ohne Schwierigkeiten und einen langen Ausbildungszeitraum f\u00fcr die Mitarbeiter im Falle des Abgangs des Entwicklungsunternehmens vom Markt.<\/p>\n

    Ein zus\u00e4tzlicher Vorteil der Plattform war, dass sie in Docker-Containern implementiert wurde: In dieser Umgebung funktionieren das Kernsystem, die Weboberfl\u00e4che und die Datenbank des Produkts. Dieser Ansatz bietet zahlreiche Vorteile, einschlie\u00dflich der vorab konfigurierten Einstellungen f\u00fcr eine besonders schnelle Bereitstellung der L\u00f6sung im Vergleich zu traditionellen Ans\u00e4tzen und der einfachen Integration neuer Ger\u00e4te 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.\u00a0<\/p>\n

    Mit dieser L\u00f6sung wird es einfacher, Systemkopien zu erstellen, und sie kann in einer separaten Umgebung verbessert und upgegradet werden, ohne den Betrieb der Gesamtanwendung zu unterbrechen.\u00a0\u00a0<\/p>\n

    Nachdem beide Risiken minimiert wurden, stellte der Auftragnehmer ein Angebot bereit. In diesem wurden alle f\u00fcr uns wichtigen Parameter des BMS-Systems detailliert ausgearbeitet.<\/p>\n

    Redundanz<\/h2>\n

    \nDas neue BMS-System sollte in der Cloud auf einer virtuellen Maschine betrieben werden.\u00a0<\/p>\n

    Keine Hardware, keine Server und all die damit verbundenen Unannehmlichkeiten und Risiken dieser Bereitstellungsmodelle \u2013 die Cloud-L\u00f6sung hat es uns erm\u00f6glicht, diese f\u00fcr 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\u00e4ndig funktionsf\u00e4hige Systeme, die im Active-Standby-Modus arbeiten und f\u00fcr alle autorisierten Fachkr\u00e4fte zug\u00e4nglich sind.\u00a0<\/p>\n

    Die beiden Systeme sichern sich gegenseitig ab und gew\u00e4hrleisten vollst\u00e4ndige Redundanz sowohl in Bezug auf die Rechenleistung als auch auf die Daten\u00fcbertragungswege. Au\u00dferdem wurden zus\u00e4tzliche Sicherheitsma\u00dfnahmen eingerichtet, einschlie\u00dflich der Sicherung von Daten und Kommunikationskan\u00e4len sowie von Systemen und virtuellen Maschinen insgesamt, sowie einer separaten Datenbanksicherung einmal im Monat (die wertvollste Ressource f\u00fcr das Management und die Analyse auf lange Sicht).\u00a0<\/p>\n

    Es ist erw\u00e4hnenswert, dass die Sicherung als Option f\u00fcr die BMS-L\u00f6sung speziell nach unserem Wunsch entwickelt wurde. Das Sicherungsschema sah folgenderma\u00dfen aus:<\/p>\n

    \"\u00dcberwachung<\/p>\n

    Support<\/h2>\n

    Ein entscheidender Punkt f\u00fcr die effektive Nutzung der BMS-L\u00f6sung ist der technische Support.\u00a0<\/p>\n

    Hier ist alles einfach: Ein neues System w\u00fcrde uns in dieser Hinsicht 35.000 Rubel pro Monat f\u00fcr SLA \u201eReaktion innerhalb von 8 Stunden\u201c kosten, das sind also 35.000 x 12 \/ 80 = 5.250 $ pro Jahr. Das erste Jahr \u2013 kostenlos.\u00a0<\/p>\n

    Im Vergleich dazu kostete die Unterst\u00fctzung der alten BMS vom Anbieter 18.000 $ pro Jahr, wobei die Summe f\u00fcr jedes neue hinzugef\u00fcgte Ger\u00e4t anstieg! Gleichzeitig stellte das Unternehmen keinen eigenen Manager zur Verf\u00fcgung; die gesamte Interaktion erfolgte \u00fcber den Verkaufsleiter, der uns als potenziellen K\u00e4ufer mit entsprechendem Fokus auf die Bearbeitung von Anfragen betrachtete.\u00a0<\/p>\n

    F\u00fcr 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 \u2013 dank des direkten Zugangs zu den Entwicklern f\u00fcr zeitnahe Anpassungen in allen Aspekten des Systembetriebs, der Integration \u00fcber API usw.<\/p>\n

    Updates<\/h2>\n

    \nNach dem vorgeschlagenen Kostenvoranschlag sind alle Updates in den Support-Kosten der neuen BMS enthalten, d.h. sie erfordern keine zus\u00e4tzliche Zahlung. Ausgenommen sind die Entwicklung zus\u00e4tzlicher Funktionen, die \u00fcber das im Pflichtenheft angegebene hinausgehen.\u00a0<\/p>\n

    Das alte System sah Zahlungen sowohl f\u00fcr Updates der eingebauten kostenlosen Software (wie z.B. Java) als auch f\u00fcr Fehlerbehebungen vor. Daran konnten wir nicht vorbeikommen; ohne Updates funktionierte das System insgesamt \u201etr\u00e4ge\u201c aufgrund der veralteten Versionen interner Komponenten.<\/p>\n

    Und selbstverst\u00e4ndlich war es nicht m\u00f6glich, die Software zu aktualisieren, ohne ein Support-Paket zu kaufen.<\/p>\n

    Flexibler Ansatz<\/h2>\n

    \nEin weiteres grundlegendes Anliegen betraf die Benutzeroberfl\u00e4che. Wir wollten den Zugriff \u00fcber einen Webbrowser von jedem Ort aus erm\u00f6glichen, ohne dass ein Ingenieur vor Ort im Rechenzentrum anwesend sein muss. Dar\u00fcber hinaus strebten wir die Entwicklung einer animierten Benutzeroberfl\u00e4che an, um die Dynamik der Infrastruktur besser verst\u00e4ndlich f\u00fcr die wartenden Ingenieure zu machen.\u00a0<\/p>\n

    In dem neuen System war es auch notwendig, Unterst\u00fctzung f\u00fcr Formeln zur Berechnung der Arbeit von virtuellen Sensoren in Ingenieursystemen bereitzustellen \u2013 beispielsweise f\u00fcr die optimale Verteilung der elektrischen Leistung auf die Serverracks. Daf\u00fcr m\u00fcssen alle g\u00e4ngigen mathematischen Operationen an den Sensordaten zur Verf\u00fcgung stehen.\u00a0<\/p>\n

    Dar\u00fcber hinaus war der Zugriff auf eine SQL-Datenbank erforderlich, um die ben\u00f6tigten Informationen \u00fcber den Betrieb der Ger\u00e4te abzurufen \u2013 insbesondere alle Aufzeichnungen zur \u00dcberwachung von zweitausend Ger\u00e4ten und zweitausend virtuellen Sensoren, die etwa 20.000 Variablen erzeugen.\u00a0<\/p>\n

    Ein Modul zur Erfassung des Ger\u00e4tebestands im Rack war ebenfalls notwendig, das eine grafische Darstellung der Ger\u00e4teanordnung in jeder Einheit bietet, die das Gesamtgewicht der Hardware berechnet und eine Bibliothek von Ger\u00e4ten sowie detaillierte Informationen zu jedem Element f\u00fchrt.\u00a0<\/p>\n

    Abstimmung des Lastenhefts und Unterzeichnung des Vertrags<\/h2>\n

    \nZu dem Zeitpunkt, als es notwendig war, mit der Arbeit an dem neuen System zu beginnen, war die Kommunikation mit den \"gro\u00dfen\" Unternehmen noch weit entfernt von einer Diskussion \u00fcber die Kosten ihrer Angebote. Daher haben wir das erhaltene Angebot mit den Kosten f\u00fcr die Aktualisierung des alten BMS verglichen (siehe den ersten Teil<\/a><\/noindex>), und das Ergebnis war preislich attraktiver und entsprach unseren Anforderungen.<\/p>\n

    Die Entscheidung wurde getroffen.<\/p>\n

    Nachdem der Auftragnehmer ausgew\u00e4hlt war, begannen die Juristen mit der Erstellung des Vertrags, w\u00e4hrend die technischen Teams beider Seiten das Pflichtenheft verfeinerten. Wie bekannt ist, ist ein detailliertes und gut formuliertes Pflichtenheft die Grundlage f\u00fcr den Erfolg aller Arbeiten. Je konkreter das Pflichtenheft ist, desto weniger Entt\u00e4uschungen gibt es wie \"aber wir wollten das nicht so\".<\/p>\n

    Ich werde zwei Beispiele f\u00fcr den Detaillierungsgrad der Anforderungen im Pflichtenheft anf\u00fchren:<\/p>\n

      \n
    1. Die zust\u00e4ndigen Rechenzentrumsmitarbeiter sind befugt, neue Ger\u00e4te in das BMS hinzuzuf\u00fcgen, in der Regel handelt es sich dabei um PDUs. In der alten BMS war dies auf der Ebene des \"Administrators\" m\u00f6glich, wodurch man unter anderem die Einstellungen aller Ger\u00e4te \u00e4ndern konnte. Eine Trennung der Funktionen war nicht m\u00f6glich, was uns nicht zufriedenstellte. In der bestehenden Basisversion der neuen Plattform war das Schema \u00e4hnlich. Wir haben in den Anforderungen von Anfang an klargestellt, dass wir diese Rollen trennen m\u00f6chten: Einstellungen sollen nur von autorisierten Mitarbeitern ge\u00e4ndert werden d\u00fcrfen, w\u00e4hrend die zust\u00e4ndigen Mitarbeiter weiterhin Ger\u00e4te hinzuf\u00fcgen k\u00f6nnen. Dieses Schema wurde zur Umsetzung angenommen.<\/li>\n
    2. \u00a0In jedem Standard-Betriebsmanagementsystem (BMS) gibt es drei Hauptkategorien von Benachrichtigungen: ROT \u2013 sofortige Reaktion erforderlich, GELB \u2013 kann beobachtet werden, BLAU \u2013 \u201eInformation\u201c. Wir haben traditionell \u201eblaue\u201c Benachrichtigungen zur \u00dcberwachung von \u00dcberschreitungen gesch\u00e4ftlicher Parameter verwendet, wie beispielsweise das \u00dcberschreiten des Leistungsgrenzwerts eines Kunden-Racks. Dieser Benachrichtigungstyp war in unserem Fall f\u00fcr die Manager gedacht und daher f\u00fcr den operativen Dienst nicht von Interesse. Allerdings hat er in der alten BMS regelm\u00e4\u00dfig die Liste aktiver Vorf\u00e4lle verstopft und die Betriebsabl\u00e4ufe gest\u00f6rt. Die Logik und die farbliche Unterscheidung der Benachrichtigungen haben wir als gelungen erachtet und beibehalten. Im Pflichtenheft haben wir jedoch ausdr\u00fccklich festgelegt, dass die \u201eblauen\u201c Benachrichtigungen lautlos in einen separaten Bereich \u201efallen\u201c, ohne die Bereitschaftsdienste abzulenken, wo sich die Fachleute um sie k\u00fcmmern werden.<\/li>\n<\/ol>\n

      \nIn \u00e4hnlicher Detailtiefe wurden die Formate f\u00fcr die Erstellung von Diagrammen und die Ausgabe von Berichten, die Umrisse der Benutzeroberfl\u00e4chen sowie die Liste der Ger\u00e4te, die \u00fcberwacht werden sollten, und viele weitere Dinge festgelegt.\u00a0<\/p>\n

      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\u00e4\u00df der erstellten technischen Dokumentation implementierte. Letztendlich haben wir einige unserer nicht entscheidenden Anforderungen an die Funktionalit\u00e4t der bereits bestehenden Plattform angepasst, w\u00e4hrend der Auftragnehmer sich verpflichtete, einige Anforderungen f\u00fcr uns zu erg\u00e4nzen.\u00a0<\/p>\n

      Parallelbetrieb von zwei Systemen<\/h2>\n

      \n\"\u00dcberwachung
      \nEs ist Zeit f\u00fcr die Umsetzung. Praktisch bedeutete dies, dass wir dem Auftragnehmer die M\u00f6glichkeit geben, einen Prototyp des BMS in unserer virtuellen Cloud bereitzustellen und Netzwerkzugang zu allen Ger\u00e4ten bereitstellen, die \u00fcberwacht werden m\u00fcssen.<\/p>\n

      Das neue System war jedoch noch nicht betriebsbereit. In dieser Phase war es wichtig, die \u00dcberwachung im alten System aufrechtzuerhalten und gleichzeitig den Zugriff auf die Ger\u00e4te im neuen System zu erm\u00f6glichen. Es ist nicht m\u00f6glich, ein System richtig aufzubauen, ohne die Ger\u00e4te sehen zu k\u00f6nnen, die gleichzeitig nicht von der \u00dcberwachung des alten Systems getrennt werden k\u00f6nnen.\u00a0<\/p>\n

      Ob die Ger\u00e4te eine gleichzeitige Abfrage durch zwei Systeme verkraften w\u00fcrden, war ohne reale Tests nicht offensichtlich. Es bestand die M\u00f6glichkeit, dass die doppelte gleichzeitige Abfrage zu h\u00e4ufigen Antwortausf\u00e4llen von Ger\u00e4ten f\u00fchren w\u00fcrde, wodurch wir zahlreiche Fehler bez\u00fcglich der Nichterreichbarkeit der Ger\u00e4te erhielten, was wiederum die Funktionalit\u00e4t des alten \u00dcberwachungssystems blockieren w\u00fcrde.<\/p>\n

      Die Netzabteilung hat virtuelle Routen vom Prototyp der neuen BMS, die in der Cloud implementiert ist, zu den Ger\u00e4ten eingerichtet, und wir haben folgende Ergebnisse erhalten:\u00a0<\/p>\n