In den vorherigen Abschnitten haben wir darüber gesprochen, wie wir ein neues Rechenzentrumsüberwachungssystem erstellt und implementiert haben . Infolgedessen verfügen wir über einen leistungsstarken Mechanismus zur Verfolgung und Pflege von Statistiken aller Rechenzentrumsparameter, die sich auf die Verfügbarkeit der Ressourcen auswirken, sowie über Indikatoren für einen unterbrechungsfreien Betrieb.
Die nächste Aufgabe auf dem Weg zur Systementwicklung war die Frage der Anpassung: Wie kann die Arbeit mit dem neuen System bequemer gestaltet werden, und es selbst wäre so informativ wie möglich?
Das Problem hierbei ist, dass Sie mit der Funktionalität des Systems viele Notfallbenachrichtigungen und -signale aktivieren können. Mit solchen Einstellungen müssen die Mitarbeiter ständig darauf reagieren und die entsprechenden Szenarien ausarbeiten.
Eine andere Möglichkeit besteht darin, eine unzureichende Anzahl solcher Benachrichtigungen festzulegen, wodurch das Risiko besteht, dass die Teilnehmer ein wirklich wichtiges Ereignis verpassen.
In diesem Teil werden wir unsere praktischen Erfahrungen beim Aufbau unseres Rechenzentrumsüberwachungssystems teilen.
Ein bisschen Theorie
„Vom SCADA-System gesammelte Variablen sind in Telesignalisierung und Telemetrie unterteilt“ - sie haben mich einmal am Institut unterrichtet. Und tatsächlich hat sich nichts geändert: Telesignaling ist ein StaatGeräte, zum Beispiel "kein Alarm", "es gibt einen Alarm", "offen", "geschlossen" usw.
Und Telemetrie ist, wie Sie vielleicht vermuten, der digitale Wert eines Parameters, zum Beispiel "220 Volt". oder "10 Ampere".
Der vom Benutzer festgelegte Status oder Wert, bei dem eine Meldung (ein Alarm) auf dem Bildschirm angezeigt wird, wird als „Sollwert“ bezeichnet. Sie können eine Verzögerung einstellen, bevor die Meldung angezeigt wird, dh der Alarm wird erst nach X Sekunden auf dem Bildschirm angezeigt (vorausgesetzt, der Notfall wurde nicht früher gestoppt) oder um die Meldung auf dem Bildschirm "einzufrieren" - in diesem Fall den Alarm ist bereits verschwunden, aber die Nachricht darüber wird auf dem Bildschirm für weitere X Sekunden gespeichert.
Unfälle nach Priorität werden normalerweise in drei Haupttypen unterteilt: "Rot", "Gelb" und "Blau". "Rote" Unfälle erfordern sofortiges Handeln der Mitarbeiter, "Gelbe" warnen sie vor etwas, "Blaue" melden meistens unkritische Ereignisse. Zum Beispiel haben wir "blaue" Unfälle aus der Zusammenfassung abgeleitet, die die Teilnehmer sehen, und verwenden sie, um verschiedene kommerzielle Parameter zu überwachen (die die bestellte Kapazität überschreiten). Diese Unfälle werden nur Managern gemeldet und lenken die Begleiter nicht ab.
Um den gleichen Gerätetyp zu konfigurieren, haben Variablen in verschiedenen Geräten mit demselben Namen (z. B. "OutputCurrent") auf allen Geräten im System dieselben Einstellungen. Wenn wir die Einstellung an einem Ort ändern, ändert sie sich überall.
Wenn für ein Gerät individuelle Einstellungen für die gewünschte Variable erforderlich sind, setzen wir ein spezielles Zeichen "Nur für dieses Gerät". Jetzt ist die Variable für ein bestimmtes Gerät individuell geworden, hat eine eigene Einstellung und wirkt sich nicht auf andere gleichnamige Variablen aus.
Zusätzlich haben die Geräte selbst ihre eigenen Werkseinstellungen. Beispielsweise ist die PDU werkseitig so konfiguriert, dass ein Überstromalarm von 32 A erkannt wird. Wenn es ausgelöst wird, benachrichtigt die PDU über die Art des Alarms "Überlastalarm". Und dies ist eine völlig andere Variable, die nichts mit der im BMS konfigurierten Variablen "OutputCurrent" zu tun hat.
Beispiel für werkseitige Standardeinstellungen in einer PDU:
Daher haben wir die Hauptfunktionen zum Einrichten eines Überwachungssystems aufgelistet.
Wie kann man dieses "Klavier" richtig stimmen? Lassen Sie uns die Aufgaben der Reihe nach durchgehen.
Was wir erreichen wollen
Die wichtigste Aufgabe: Jede Alarmmeldung auf der
Die zweite Aufgabe besteht darin, falsche oder nicht informative Nachrichten zu minimieren. Egal wie aufmerksam und verantwortungsbewusst Sie sind, wenn etwas ständig blinkt, blinkt und vor ihren Augen klingelt, werden sie entweder einen echten Unfall verpassen, in einem Meer von Warnungen ertrinken oder den Ton ausschalten - und Infolgedessen verpassen sie auch den Vorfallalarm.
Stufe 1. Ermittlung der notwendigen und unnötigen Variablen für jedes Gerät
In der Regel wird jedes Gerät mit einer sogenannten "Variablenzuordnung" geliefert, auf deren Grundlage vom Inbetriebnehmer ein "Treiber" erstellt wird. Seine Aufgabe ist es, dem Überwachungssystem "anzuzeigen", in welchem Register der empfangenen Daten sich die erforderliche Variable befindet. Beispielsweise enthält Register 1 des Geräteabrufprotokolls Informationen über den Motorbetriebsmodus "System_on_fun" und Register 2 - über den Kompressorbetriebsmodus "Compressor_1".
Die Anzahl der Variablen für ein Gerät beträgt häufig mehr als 100. Der Mitarbeiter, der das System ursprünglich konfiguriert (normalerweise ein IT-Ingenieur), kann nicht selbst entscheiden, was hier wichtig ist und was nicht. In der Regel werden alle Variablen zur Überwachung nach dem Prinzip „Was ist, wenn sie nützlich sind?“ Hinzugefügt.
Dies ist zunächst zulässig - das Betriebspersonal kann die tatsächlichen Werte aller verfügbaren Variablen einsehen und verstehen, was es wirklich benötigt. Wenn Sie das System jedoch längere Zeit in diesem Zustand belassen, treten folgende negative Auswirkungen auf:
- Überflüssige Variablen laden die Betriebsaufgabe des Überwachungssystems und vergrößern das Archiv. Das System ist gezwungen, unnötige Daten zu verarbeiten und zu speichern.
- Je mehr Variablen abgefragt werden, desto höher ist die Wahrscheinlichkeit eines Abruffehlers. Dies gilt insbesondere für Geräte, die über eine Schleife verbunden sind (z. B. über ein Gateway mit dem MODBUS-Protokoll). Dies führt zum Empfang der Zustände "keine Daten (N / A)" oder "Kommunikationsunterbrechung", dh das Gerät fällt regelmäßig aus der Überwachung aus.
- Einige Variablen sind "standardmäßig" überflüssig. Beispielsweise verfügt Ihre Version des Geräts nicht über einen Kompressor oder Drucksensor. Sie sind jedoch im Universaltreiber für die gesamte Modellpalette der Geräte registriert und werden abgefragt, dem Archiv hinzugefügt, das Netzwerk geladen und verarbeitet.
Die Screenshots zeigen einen Teil des Treibercodes. Die Symbole // geben Variablen an, die in der Umfrage ausgeblendet sind. Ebenfalls sichtbar ist eine Liste von Variablen, die dem Benutzer beim Einstellen der Sollwerte im BMS selbst angezeigt werden.
Nach unserer Erfahrung ist es besser, die Werkseinstellungen in den Geräten in der Anfangsphase nicht zu berühren (natürlich, wenn sie Sie nicht bereits über den Unfall informieren). Bei jeder Schulung an einem bestimmten Gerät sollten die Mitarbeiter jedoch an das Vorhandensein von Einstellungen sowohl im Gerät selbst als auch im BMS erinnert werden. In Zukunft wird dies den Teilnehmern helfen, genau zu verstehen, was genau die Ursache für die Alarmmeldung ist.
Überflüssige Variablen im Treiber sollten schrittweise aufgedeckt und vor der Umfrage verborgen werden, und die verbleibenden Variablen sollten in diejenigen unterteilt werden, denen Einstellungen zugewiesen werden sollen, und diejenigen, die ohne Einstellungen nur für nachfolgende Analysen und Statistiken gespeichert werden.
Dies sollte nicht vom Systemeinsteller durchgeführt werden, sondern von einem Mitarbeiter, der die Funktionsweise des vom Überwachungssystem gesteuerten Systems versteht - vorzugsweise vom Chefingenieur oder Chefingenieur.
Stufe 2. Minimierung falscher und nicht informativer Nachrichten
False Positives treten häufig aufgrund von Fehlern bei der Abfrage des Geräts auf. Wenn die Netzwerkkarte des Geräts nicht mit Strom versorgt wird, werden sowohl ein Fehler beim Abrufen als auch ein tatsächlicher Stromausfall als eine Art von Fehler angezeigt - "Kommunikationsunterbrechung".
In diesem Fall ist es erforderlich, das Gerät in kritische (z. B. PDU) und normale (z. B. "SHCHUV" -Lüftungsplatten) zu unterteilen. Bei herkömmlichen Geräten können Sie eine Verzögerung für das Signal "Unterbrechung" einstellen (z. B. 300 Sekunden). Die meisten falschen Unterbrechungen werden dann ignoriert.
Es ist klar, dass eine solche Verzögerung nicht auf kritische Geräte angewendet werden kann. Wenn sie daher ständig zu falschen Fehlern führt, sollten Sie sich mit dem physischen Netzwerk und der Anzahl der abgefragten Variablen befassen. Es ist durchaus möglich, dass viele Geräte an einem Gateway "hängen" und das Netzwerk durch Hinzufügen neuer Gateways segmentiert werden muss.
Nicht informative Unfälle treten am häufigsten bei vorübergehenden Prozessen auf. Sie können nicht als falsch bezeichnet werden - sie existieren tatsächlich, sind jedoch für einen bestimmten Betriebsmodus des Geräts "normal". Das offensichtlichste Beispiel ist der Übergang zu einem Dieselaggregat.
In diesem Fall wird ein Teil des Geräts, das ohne USV "normal" mit Strom versorgt wird, stromlos geschaltet und gibt einen Fehler beim "Trennen" aus, und die USV selbst gibt eine ganze Reihe von Meldungen aus - "kein Strom am Eingang", "kein Strom" bei Bypass "," Stromversorgung von der Batterie "usw. Das Personal erhält sofort Dutzende von Nachrichten.
Um die Anzahl der Nachrichten beim Wechsel zu DGS zu optimieren, sollten Sie:
- eingestellt für „normal“ auftretende Alarme während des Übergangs längere Zeitverzögerungen als die Zeit, zu der die Stromversorgung vom Generator erscheint. Stellen Sie beispielsweise die Verzögerung für das Signal "Abschalten" der Lüftungsblende auf 300 Sekunden ein, wenn die Standardzeit für das Umschalten auf den Dieselgenerator 200 Sekunden beträgt.
Dann erscheint die Stromversorgung der SCHU vor der Sollwertverzögerung und die Situation wird nicht als Notfall erkannt. Gleichzeitig gibt es kritische Geräte, die von der USV mit Strom versorgt werden und immer angeschlossen sein müssen (z. B. PDU) - Meldungen über ihre "Trennung" sollten unverzüglich angezeigt werden.
- Analysieren Sie Meldungen von der USV, wenn Sie auf einen Dieselaggregat umschalten, und teilen Sie sie in "normale" auf, indem Sie ihnen einen "gelben" Typ (z. B. die Aussage, dass am Eingang keine Stromversorgung vorhanden ist) und "abnormal" zuweisen "(" Abschalten des Batterieschalters ", was keine Betriebsart sein sollte), mit der Zuordnung zu dem" roten "Typ.
Gleichzeitig schreiben wir in den Anweisungen an die diensthabenden Beamten separat, dass bei einem Übergang zu einem Dieselaggregat „gelbe“ Unfälle beobachtet und nicht anerkannt werden können (sie verschwinden nach Abschluss eines regulären Übergangs von selbst) ) und „rote“ Unfälle können sofort beseitigt werden (sollten es nicht sein).
Nur auf der Grundlage der Theorie ist es sehr schwierig, die Sollwerte für diesen "vorübergehenden" Prozess gleichzeitig anzupassen. Für eine erfolgreiche Abstimmung müssen die Übergänge zum DGS mehrmals in Echtzeit beobachtet werden.
Zum Beispiel mussten wir 4-5 Übergänge beobachten, um ein akzeptables Setup eines neuen BMS zu erhalten. Um den außerplanmäßigen Übergangsprozess zu analysieren, haben wir den Bildschirm des Überwachungssystems aufgezeichnet, da es wichtig ist, Alarme nicht im Ereignisarchiv zu beobachten, sondern das Auftreten von Alarmen in der Dynamik der Betriebsübersicht zu analysieren.
Schritt 3. Zusätzliche Tipps aus unserer Erfahrung
1. Auf den Bildschirmen der Dienstschicht sollte keine unnötige Anzeige in den Farben der Alarmmeldungen angezeigt werden.
Beispiel aus der Praxis. Ein Rechenzentrum bestellte eine Temperaturflusskarte im Serverraum. Dies ist ein 3D-Modell von Luftströmen mit vielen Temperaturdaten von Sensoren. Das Ergebnis war ein Blick auf die Nordluft mit Luftströmen - irgendwo wurde die Luft grün hervorgehoben, irgendwo - gelb und rot (vom kältesten zum heißesten). Gleichzeitig liegen die Lufttemperaturen überall innerhalb normaler Grenzen, und die Farben werden nur zur Klarheit der Anzeige des Temperaturunterschieds an verschiedenen Punkten verwendet.
Ferner wurde diese "bunte" Ansicht auf einem der Monitore im "Dienstraum" angezeigt. Als Ergebnis stellte sich heraus, dass das für die Prozessanalyse entwickelte Tool vor den Augen der Bediensteten erschien, die "geschärft" wurden, um zum Gerät zu laufen, wenn sie Rot sehen, und sich anstrengen, wenn sie Gelb sehen.
Wahrscheinlich erklärten sie den Teilnehmern, dass auf dem linken Bildschirm "rot / gelb" normal ist und auf dem rechten Bildschirm die gleichen Farben ein Signal zum Handeln sind. Es ist jedoch klar, dass diese Praxis das Risiko menschlicher Fehler sehr ernsthaft erhöht.
Es ist logisch, solche Systeme von den Monitoren im Dienstraum zu entfernen. Sie sollten vom Chefingenieur beobachtet werden, um Trends zu analysieren - beispielsweise nach einigen Änderungen der Parameter der Luftumgebung im Serverraum oder bei der Inbetriebnahme neuer Ausrüstung.
2. Verwenden Sie SMS-Benachrichtigungen mit Vorsicht.
Vor einigen Jahren hatten wir immer noch Angst vor einem schlechten mobilen Internet und verwendeten SMS anstelle von Instant Messenger. Nachdem ich versehentlich die falsche Einstellung vorgenommen hatte, wurde sie auf alle Geräte mit demselben Namen in 100 Geräten angewendet, und meine Kollegen, die die Mailingliste abonniert hatten, erhielten jeweils 100 SMS-Nachrichten. Seitdem haben wir kein SMS-Mailing mehr verwendet.
3. Richten Sie die Duplizierung von Nachrichten über Probleme über den Messenger ein.
Dies kann beispielsweise über Microsoft Teams oder Telegramm erfolgen. Sowohl Sie als auch die diensthabende Person erhalten Nachrichten über Unfälle, während das Telefon Geräusche macht und vibriert (was bei der Arbeit mit dem System über einen Browser nicht der Fall ist).
Und haben Sie keine Angst, dass es viele Nachrichten geben wird. Nach unserer Erfahrung werden am durchschnittlichen Tag eines Rechenzentrums nur wenige Dutzend Nachrichten empfangen, und die Telefone der Mitarbeiter werden nicht geladen. Das heißt, die Ausrüstung des Rechenzentrums und des BMS-Systems kann so konfiguriert werden, dass keine Hunderte von Benachrichtigungen empfangen werden und gleichzeitig nichts Wichtiges übersehen wird.
Um die Anzahl der Nachrichten zu verringern, nehmen Sie in die Mailingliste nur Benachrichtigungen über das Auftreten von "roten" und "gelben" Alarmen auf, dh das erforderliche Minimum, damit Sie immer am Puls der Ereignisse bleiben können.
4. Gruppieren Sie Nachrichten in Messenger.
Während des Übergangs zu einem Dieselaggregat oder aufgrund eines komplexen Unfalls treten Dutzende von aktiven Notfällen auf. Das Telefon vibriert ständig von eingehenden Nachrichten an den Messenger, sodass Sie keinen wichtigen Anruf tätigen oder das Fenster des Überwachungssystems öffnen können.
Sie können die Verteilung so konfigurieren, dass der Messenger eine allgemeine Nachricht mit einer allgemeinen Liste der in letzter Minute aufgetretenen Unfälle empfängt. Diese Einstellung hat keinen Einfluss auf das Auftreten von Alarmen in der BMS-Systemzusammenfassung (Alarme werden unverzüglich in der Zusammenfassung angezeigt). Bei einer Verzögerung von 1 Minute beim Empfang einer Nachricht auf Ihrem Telefon werden Sie nichts verpassen, aber es wird etwas geben viel weniger Nachrichten auf Ihrem Telefon.
5. Markieren Sie die Meldung über den Verbindungsverlust mit dem Server in der Schnittstelle.
Zum Beispiel ging das Internet in den Räumlichkeiten der Teilnehmer verloren. Die Benutzeroberfläche hat keine Verbindung zum Server und daher wird der Alarm nicht in der Zusammenfassung angezeigt. Die schwache Aufschrift „Server ist nicht verfügbar“ wird vom Personal möglicherweise nicht bemerkt. Die Mitarbeiter können das „grüne“ BMS-Feld mit numerischen Parametern anzeigen für eine lange Zeit nicht bewusst, dass es offline befindet.
Der Screenshot zeigt ein Beispiel für einen Hinweis auf den Kommunikationsverlust mit dem BMS-Server, während irrelevante Parameter des Geräts angezeigt werden.
6. Schließen Sie so viele Systeme wie möglich an die Überwachung an.
Beispielsweise arbeitet ein Brandmeldesystem traditionell autonom und sein Bedienfeld hängt am Sicherheitsposten.
Ja, beim "FIRE" -Signal werden die automatischen Algorithmen der Systeme ausgelöst, das Warnsystem wird gestartet, aber der Sicherheitsbeauftragte informiert über das Auftreten der "Fault" - oder "Attention" -Signale in einer diensthabenden Stimme.
Es ist sehr schwierig, ein solches System vollständig an die Überwachung anzuschließen, aber in einem solchen System ist es einfach, drei Relaissignale "Fehler", "Aufmerksamkeit" und "Feuer" zu konfigurieren und sie dann mit "trockenen Kontakten" an das BMS anzuschließen Systemmodul.
Dies reduziert das Risiko des berüchtigten menschlichen Faktors. Ein Beispiel für ein Testsignal "FIRE" im BMS-System des Rechenzentrums, das über "Trockenkontakte" verbunden ist.
Zusammenfassung unserer 4er-Geschichte
Ein Rechenzentrumsüberwachungssystem ist mehr als nur „Augen und Ohren“ für die Überwachung von Rechenzentrums-Engineering-Systemen. Der korrekte Betrieb ermöglicht es, durch die Kontinuität des Standorts ein Höchstmaß an Zuverlässigkeit zu erreichen, und verschafft dem Unternehmen daher einen zusätzlichen Wettbewerbsvorteil.
Nachdem wir einen ziemlich schwierigen und langen Weg zurückgelegt hatten, bekamen wir:
- ein schnelles und stabiles Überwachungssystem, das derzeit mehr als 2.500 Geräte überwacht und etwa 10.000 virtuelle Sensoren berechnet;
- Systemreservierung basierend auf der Cloud-Lösungsplattform Lindatacenter in St. Petersburg und Moskau;
- -, , 1 ;
- , , ;
- , , – .