Störung: Anbindungsprobleme

Es gibt aktuell eine Störung, die Server-Eye betrifft. Es gibt aktuell Störungen, die die Anbindung unseres Rechenzentrums betreffen. Es kann zu Problemen bei den Verbindungen, der Installation, den Mail Round Trip Sensoren und dem Aufrufen des OCCs kommen, da die Verbindungen zur Server-Eye Cloud eingeschränkt sind. Unsere Entwicklung und Servertechnik arbeitet intensiv, um die Störung schnellstmöglich zu beheben. Wir informieren Sie sobald es Neuigkeiten gibt.

Bei Fragen wenden Sie sich bitte direkt an unsere Supporthotline unter 06881 / 93629-77 oder per Mail an support@server-eye.de

Update: 17.07. - 19 Uhr

Die Störung der Anbindung und die damit folgenden Probleme sind seit etwa 17:15 Uhr behoben. Unsere Systeme sind seitdem wieder stabil und verarbeiten alle einkommenden Werte normal.
Die genaue Ursache ist noch nicht gefunden. In der Rekonstruktion der Ereignisse sind wir zuversichtlich die Ursache innerhalb der laufenden Woche zu finden und zu beheben.

Update: 18.07. - 15 Uhr

Durch die Störung der Anbindung des Rechenzentrums haben wir kurzfristig Veränderungen an unseren Backend Services durchgeführt, um die aufgestauten Nachrichten der angebundenen Systeme besser verarbeiten zu können. Diese Änderungen hatten zur Folge, dass die Installation neuer Systeme nicht immer möglich war. Mittlerweile steht auch die Installation wieder zur Verfügung.

Update: 20.07. - 14:30 Uhr

In den letzten Tagen haben uns vereinzelt Tickets erreicht, dass weiterhin Verbindungsprobleme zu unseren Servern bestehen. Nach ausgiebiger Prüfung unseres Backends hat sich herausgestellt, dass die immer noch nicht verbundenen Windows Systeme erst wieder online kommen, wenn sie komplett neugestartet werden. Auf dieses Verhalten haben wir leider keinen Einfluss.

Zusätzlich haben wir den Ausfall vom 17.07. weiter analysiert. Durch das letzte Server-Eye Update im Juni wurde die Sicherheit der Anbindung der OCC Connectoren stark erhöht. Hierzu haben wir neue Authentifizierungsserver eingesetzt. Durch den kurzen Ausfall der Anbindung des Rechenzentrums wurden diese Authentifizierungsserver so stark überlastet, dass fast keine Verbindung mehr möglich war. In Reaktion darauf haben wir am 17.07. sofort die Anzahl der Authentifizierungsserver verdoppelt. Im Laufe der letzten beiden Tage haben wir zusätzliche Server in Betrieb genommen, wodurch wir nun die Kapazität der Authentifizierungsserver verdreifacht haben.

Die Analyse des Ausfalls vom 17.07. ist für uns damit abgeschlossen. Alle gefundenen Schwachstellen wurden behoben.


OCC Startseite im normalen Theme

Das Online Control Center im neuen Design

Vor etwas mehr als drei Jahren haben wir das Online Control Center, oder OCC, technologisch auf komplett neue Füße gestellt. In dieser Zeit sind einige nützliche Funktionen hinzugekommen, wie zum Beispiel gefilterte Ansichten und das Patch Management.

In den letzten Wochen hat ein Teil unseres Teams daran gearbeitet auch das Look and Feel zu verbessern. In drei Jahren fällt einiges an Staub an und dieser sollte endlich verschwinden!
Die Optik des OCCs wurde komplett aufgefrischt und an aktuelle Designstandards angepasst. Material Design und mobile first sind dabei nur zwei der vielen Buzzwords.

 

Anpassungen für farbenblinde Menschen

Etwa 9% aller Männern sind farbenblind. Gerade in einem Berufsfeld wie unserem eine sehr große Personengruppe. Aus diesem Grund haben wir uns entschieden ein spezielles Theme für farbenblinde Menschen zur Verfügung zu stellen. Mittels einer speziellen Testsoftware konnten unseren Designer ein Gefühl dafür bekommen wie das OCC für Menschen mit verschiedenen Arten der Farbenblindheit wirkt. Diese Informationen haben wir analysiert und ein Theme entworfen, welches für die meisten farbenblinden Menschen ausreichend Kontrast und Differenzierung zwischen den Farben bietet.

Ihr könnt unter Meine Einstellungen - Ansicht am Seitenende das Theme wechseln.

Wir hoffen euch hiermit euer tägliches Arbeiten erleichtern zu können und freuen uns über jegliches Feedback an support@server-eye.de.

OCC Startseite im Theme für farbenblinde Menschen

Dunkles Theme

Da wir sowieso gerade dabei waren das OCC zu überarbeiten, und das Theme für farbenblinde Menschen in Arbeit war, haben wir uns kurzerhand dazu entschlossen ein Dark Theme umzusetzen. Für jeden, der es ein bisschen dunkler mag, gibt es jetzt auch die passende Ansicht im Online Control Center ;)

OCC Startseite im dunklen Theme

 

Responsive

Das Buzzword schlechthin. Responsive oder mobile first, mit einem der beiden wirbt jeder. Das OCC ist schon seit dem ersten Release in 2015 mobil nutzbar, wurde allerdings nie speziell dafür angepasst. Unser Team hat sich im Zuge des Redesigns jede einzelne Ansicht des OCC angesehen und spezielle Anpassungen für mobile Geräte vorgenommen. Die Menüstruktur funktioniert nun mobil besser, Tabellen passen sich der Bildschirmgröße an und vieles mehr.

Aufgrund der Größe der Umstellung und der Vielzahl an Endgeräten freuen wir uns auch hier über Feedback an support@server-eye.de.

 

Generelle Anpassungen

Am auffälligsten sind wohl die Anpassungen der Startseite des OCC. Die Boxen haben ein komplettes Redesign verpasst bekommen. Außerdem wurde die Sidebar komplett umstrukturiert, um die Bedienung intuitiver zu gestalten. Euch werden an vielen Stellen immer wieder Kleinigkeiten auffallen. Das komplette Changelog findet ihr hier.

Bei den vielen Kleinigkeiten wird es allerdings nicht bleiben. Die Arbeit, die jetzt getan wurde, stellt die Basis für weitere Veränderungen bereit. Im Laufe des Jahres werden wir immer wieder bestehende Ansichten subtil verbessern, oder komplett neue Ansichten umsetzen, und auch die drei Themes und mobilen Anpassungen weiter ausbauen.

Aber erstmal wünschen wir euch viel Spaß im neuen, frischen OCC und einen guten Start in die Woche!


Neuerungen in der Server-Eye Netzwerkstruktur

Mit dem neuesten Update Juni/2018 nehmen wir einige Änderungen in der Netzwerkstruktur zwischen OCC Connector und Sensorhub vor. Außerdem gibt es Verbesserungen falls ein OCC Connector ausfällt und die Sensorhubs sich direkt zur Cloud verbinden.

 

Wie sieht die Kommunikation vor dem Update aus?

Die Sensorhubs finden den OCC Connector per UPnP. Wurde ein passender OCC Connector gefunden baut der Sensorhub eine Verbindung zum OCC Connector auf. Ebenso versucht sich der OCC Connector zum Sensorhub zu verbinden. Dieser bidirektionale Ablauf erfordert netzintern automatische Anpassungen an der Windows Firewall. Außerdem verschlüsseln wir die Daten mit Hilfe verschiedener Windowsfunktionen. Diese Funktionen können allerdings durch Windowsupdates und andere Systemveränderungen kurzzeitig inkorrekte Daten liefern und sind somit nicht mehr lesbar oder entschlüsselbar.

Um diese beiden möglichen Fehlerquellen zu entfernen haben wir einige Änderungen umgesetzt.

 

Wie verändert sich die Kommunikation?

Der Sensorhub sucht weiterhin seinen OCC Connector per UPnP. Bei erfolgreicher Verbindungen werden alle notwendigen Daten gespeichert. Startet ein Sensorhub neu, und der ursprüngliche OCC Connector ist weiterhin verfügbar, wird sofort eine Verbindung ohne Einsatz von UPnP hergestellt.

Die Kommunikation vom OCC Connector zum Sensorhub fällt komplett weg. Es gibt somit nur noch eine unidirektionale Verbindung vom Sensorhub zum OCC Connector. Dabei gehen keine Features verloren.

Zusätzlich verschlüsseln wir die gesendeten Daten nicht mehr selbst. Wir setzen in Zukunft eine 2048 bit starke SSL Verschlüsselung ein, welche nativ von Windows gehostet wird.

 

Was geschieht, wenn ein OCC Connector ausfällt?

Fällt ein OCC Connector aus verbinden sich alle Sensorhubs nach etwa fünf Minuten selbständig in die Cloud. Alle Funktionen sind weiterhin nutzbar, für den Benutzer im OCC besteht kein Unterschied zwischen einem Sensorhub mit Verbindung zum OCC Connector oder einem Sensorhub mit Direktverbindung.

 

Technische Voraussetzungen

Vorbereitend zum Update sollten alle Systeme auf mindestens .NET 4.6.1 gepatched werden. Außerdem wird der OCC Connector, wie schon öfters informiert, nur noch ab Windows 2008 unterstützt und aktualisiert.

Alle Sensorhubs müssen über eine funktionierende Namensauflösung verfügen. Proxyserver sollten so konfiguriert sein, dass der Benutzer "Local System" im Netzwerk HTTPS Anfragen durchführen darf. Darüber hinaus empfiehlt es sich den Internetzugriff für alle Sensorhubs auf *.server-eye.de freizugeben. Dies ist allerdings kein Muss.

 

Fazit

Alle diese Änderungen sorgen für mehr Stabilität im Installationsprozess und der täglichen Funktionalität des Server-Eye Clients. Außerdem ermöglichen wir so auf einfach Art und Weise die Integration von Laptops oder externen PCs als Sensorhubs in einem Firmennetzwerk.

Zum Beispiel kann ein System im Firmennetzwerk mit Server-Eye installiert und an den korrekten OCC Connector angehangen werden. Wird es danach in eine Außenstelle gebracht und per VPN angebunden versucht es eine Verbindung zum ursprünglichen OCC Connector herzustellen. Ist dies nicht möglich verbindet sich das Gerät selbst in die Cloud. UPnP ist nicht mehr zwingend erforderlich.

Das Update wird im Laufe des Juni 2018 für alle Systeme freigegeben.


Störung: Latenzen und Verarbeitungsverzögerungen

Seit der vergangenen Woche hat unserer Rechenzentrum mit Wartungsarbeiten und zusätzlichen Ausfällen zweier Upstreamprovider zu kämpfen. Bisher gab es keine Stellungnahme unsererseits, da bis auf zeitweise längere Ladezeiten des OCC, für unsere Kunden keine Konsequenzen entstanden sind. Die erhöhten Latenzen zu uns fanden täglich in einem Zeitraum von etwa zehn bis 20 Minuten statt. Alle anderen Schwankungen und Spitzen konnten durch die Ausfallsicherheit unseres Clusters und erprobte Ausfallkonzepte abgefangen werden.

Heute Mittag gab es eine erneute Störung der Upstreamprovider. Diese dauerte etwa 20 Minuten und hat zu etwa 30.000 korrupter Verbindungen pro Minute auf unsere Backend Services geführt. Einer unserer Clusterknoten war dadurch mit etwa der doppelten Anzahl Verbindungen pro Minute konfrontiert als gewöhnlich, wovon über die Hälfte korrupt waren. Dies führte bei uns zum Eintreten mehrerer Alarmierungsszenarien.

In diesem Ausfall hat ein Background Thread begonnen unbemerkt inkorrekt zu arbeiten. Vereinfacht gesagt hat der Thread zuverlässig seine eigentliche Aufgabe und sein Ziel erfüllt, allerdings den Weg zum Ziel nicht mehr zu 100% sauber bearbeitet. Dies hat dazu geführt, dass heute Nacht zwischen 01:37 Uhr und 02:42 Uhr eingegangene Nachrichten teilweise zerstört und nicht als Alarm verarbeitet wurden.

Da alle Metriken des Background Threads in Ordnung waren können wir nicht genau bestimmen wie viele Nachrichten in diesem Zeitraum betroffen waren.

Wir prüfen wie wir dies in Zukunft messen und überwachen können. Zusätzlich stehen wir in regem Kontakt mit unserem Rechenzentrum, um über die aktuellen Ausfälle im Upstream informiert zu bleiben. Bei Fragen wenden Sie sich bitte an support@server-eye.de

 


Störung: Verarbeitung Alarmmeldungen *Update 08.12.*

Durch eine Störung in unserem Datenbankcluster kam es heute, 30.11.2018, zwischen 17 Uhr und 19:30 Uhr zu Verzögerungen in der Verarbeitung von Alarmmeldungen.

Seit 19:30 Uhr steht der Datenbankcluster wieder mit voller Performance zur Verfügung und arbeitet korrekt.

Durch die verzögerte Verarbeitung im Störungszeitraum kann es vereinzelt vorgekommen sein, dass sehr kurz anliegende Alarme nicht gemeldet wurden. Trotz einer mehrschichtigen Sicherungsstruktur lies sich dies leider nicht vermeiden. Wir werden prüfen wie dies in Zukunft komplett vermieden werden kann.

Falls Sie weitere Fragen haben wenden Sie sich bitte an support@server-eye.de.

 

 

 

***Update 01.12.***

Wenn eine Datenbank schon mal Probleme hat schlägt sie natürlich auch gerne mehrmals zu. Gestern Abend waren alle Messwerte wieder im normalen Bereich und keine Problem für den verbleibenden Datenbankcluster in Sicht, während eine Node weiter im Recovery Modus lag.

Allerdings haben verschiedene Nachtläufe und das Erstellen der Monatsberichte den verbleibenden Cluster ins Schwanken gebracht. Wir konnten die Systemstabilität  gegen 09:30 Uhr wieder komplett herstellen und entschuldigen uns für entstandene Fehlalarme von Systemen.

***Update 08.12.***

Unser Datenbankcluster wurde mittlerweile wieder komplett aufgebaut und läuft mit gewohnter Performance. Die Störungen bezüglich heruntergefahrener System oder Problemen bei der Integration neuer Systeme sollten damit gelöst sein.


Störung Anbindung Rechenzentrum *Update 10.08.2017*

Gegen 14:51 Uhr gab es, laut unseren Messungen in verschiedenen Rechenzentren, Schwankungen in der Internet Anbindung. Unser Haupt-Rechenzentrum hatte Probleme diese Schwankungen auszugleichen, wodurch bis etwa 15:12 Uhr die Anbindung offline war.

Mittlerweile sind alle Services von Server-Eye wieder verfügbar, Alarmmeldungen gingen keine verloren.
Die genaue Ursache wird uns noch vom Rechenzentrum mitgeteilt.

rz_20170808

 

Update 10.08.2017 - 11:45 Uhr

Unser Rechenzentrum hat uns soeben informiert, dass ein zentraler Knotenpunkt in Frankfurt durch Arbeiten an der Mittelspannungsversorgung von der Stromversorgung abgeschnitten wurde. Dadurch fiel ein komplettes Stockwerk mit mehreren Brandabschnitten aus. Unser Rechenzentrum arbeitet nun daran die Netztopologie zu verändern, um die Ausfallsicherheit zu erhöhen.


DNS-Probleme

Durch Probleme unserer DNS-Server kam es heute zwischen 15:30 Uhr und 15:55 Uhr zu nicht zugestellten TANSS Tickets, fehlerhaften Mail-Round-Trips und anderen kaputten Anfragen von Server-Eye zu externen Servern.

Diese Fehlerhaften Anfragen haben wiederum Lastspitzen auf unseren Firewalls verursacht, wodurch teilweise auch kein Aufruf des OCC und ähnlichen Webservern bei uns möglich war.

Die genaue Ursache der DNS Probleme und deren Auswirkungen befindet sich noch in der Analyse, alle Systeme funktionieren allerdings mittlerweile wieder wie gewohnt und ohne Verzögerungen.


Verbindungsprobleme Patch Management

Seit gestern kommt es vor allem in den Morgen- und Mittagsstunden zu Verbindungsproblemen im Patch Management. Auch das Neu-Anlegen von Managed Antivirus Installation ist davon betroffen.

Das Problem ist bekannt und wir arbeiten seit gestern an einer nachhaltigen Lösung.

Wir bitten um ein wenig Geduld und werden schnellstmöglich ein Update auf unseren Cloud-Systemen ausrollen.

Danke!


Server-Eye mit Zwei-Faktor-Authentifizierung

Sicherheit nehmen wir sehr ernst. Aus diesem Grund steht ab dem 29.05.2017 auch die Zwei-Faktor-Authentifizierung für dein Server-Eye Account zur Verfügung!

Die Zwei-Faktor-Authentifizierung ist eine optionale Sicherheitsfunktion, die wir vor allem Technikern empfehlen, die sich oft an fremden PCs anmelden. Bei diesen ist die Gefahr besonders groß, dass per Keylogger oder durch andere Tools das Passwort von dritter Stelle mitgelesen wird. Ist die Funktion aktiv wird bei jeder Anmeldung am OCC ein zeitbasierter, 6-stelliger Code abgefragt. Dieser Code wird im Normalfall von einer mobilen App generiert.

 

Zwei-Faktor Anmeldung

 

Jeder Benutzer kann die Sicherheitsoption selbst unter "Meine Einstellungen" aktivieren und deaktivieren. Wie bereits erwähnt wird eine mobile App oder jegliche Anwendung benötigt, welche das TOTP-Protokoll unterstützt. Eine genauere Erklärung und Auflistung findest du hier.

Alle FAQ-Artikel zur Two-Faktor-Authentifizierung haben wir für dich in einer eigenen Kategorie zusammengefasst.


Ausfallsicherheit der Server-Eye Cloud

Am vergangenen Samstag kam es in unserer Cloud zu einem Failover Fall. Eine seit Jahren problemlos funktionierende, überwachte Komponente hat plötzlich den Dienst verweigert und somit Fehlalarme ausgelöst.

Bevor ich auf die genauen Umstände und unsere, teilweise automatischen, Reaktionen dazu eingehe, möchte ich die Gelegenheit nutzen und kurz den Aufbau unserer Cloud erklären.

Der Weg eines Alarms

Der Weg eines Alarms vom Kundensystem durch unsere Cloud und eventuell wieder zu Ihnen per Email zurück ist ein langer Weg durch etwa 15 eigenständige Komponenten.

Aufbau Cloud

In dieser vereinfachten Ansicht sehen wir, dass die Daten Ihrer Kundensysteme und Ihrer eigenen bei uns im Rechenzentrum von einer Firewall angenommen werden. Die Verbindung wird danach direkt von einem Reverse Proxy übernommen, welcher das SSL terminiert und anhand verschiedener Kriterien die nächste Komponente für diese Daten festlegt.

Im Fall einer Alarmierung werden die Daten erst von einer Komponenten aus der Verbindung gelesen und zwischengespeichert. Die nächste Komponente greift dann ein, wertet die Daten aus und speichert sie in der Datenbank. Außerdem legt sie fest, ob ein Benutzer alarmiert werden muss, wie er alarmiert wird und auch wann. Auch das wird in der Datenbank eingetragen und abschließend von einer letzten Komponente ausgeführt.

Fällt eine dieser Komponenten aus steht der komplette Prozess. Um dies zu verhindern haben wir alle Prozesse von Server-Eye redundant ausgelegt. In der Vergangenheit hatten wir alle unsere Komponenten in einem großen virtuellen Cluster mit mehreren Hosts. Komponenten konnten von einem Host auf den anderen geschoben werden, der Storage war ein Cluster Storage, etc. Mit der Zeit haben wir festgestellt, dass durch die komplette Virtualisierungsstruktur weitere Fallstricke und neue Probleme entstehen. Komponenten, die anderen Komponenten CPU Zeit stehlen, Performance Probleme des Netzwerkstorage und den Cluster Storage Services, etc. Unser Szenario mit mehreren 100 Maschinen, die permanent die gleiche Last tragen und kaum Spitzen in der Ressourcenauslastung haben, war einfach nicht ideal für diese Art von Virtualisierung.

Der jetzige Aufbau

Unser Anspruch war es daher das oben gezeigte simple Schaubild mit möglichst hoher Redundanz, Skalierbarkeit und einfacher Verwaltung umzusetzen. Dieses System verwenden wir nun seit etwas mehr als einem Jahr.Aufbaut Cloud mit Pods

Ein Pod ist ein Virtualisierungshost und stellt alle Komponenten bereit, die Server-Eye benötigt. Er enthält das OCC, API, Verarbeitung der Alarme, etc. Ein Pod bildet somit ein autark funktionierendes Server-Eye ab. Wird ein Pod abgeschaltet oder funktioniert nicht beeinträchtigt dies nicht die anderen Pods. Komponenten müssen und können im Fehlerfall nicht auf einen anderen Pod umziehen. Es gibt keinen Netzwerkstorage mehr. Dies spart uns viel Overhead und Ressourcen ein, die vorher in Cloud Services und ähnliche verschwunden sind.

Die Firewall und der Reverse Proxy sind redundant vor die Pods geschaltet. Durch ein Source Balancing landet Ihr Kunde immer auf dem gleichen Pod. Dies erleichtert uns die Arbeit bei Support Fällen enorm, da zum Beispiel im Hilfebereich des OCC für Sie ersichtlich ist welchen Pod sie nutzen. Mit dieser Information können wir Problemen schneller auf die Spur kommen.

Müssen Wartungsarbeiten oder Updates durchgeführt werden lässt sich im Reverse Proxy einfach der entsprechende Pod abschalten. Die Verbindungen verteilen sich dadurch auf die anderen Pods um und es gibt nur noch sehr wenige Wartungsfenster, die tatsächlich die Funktionalität von Server-Eye beeinträchtigen.

Zusätzlich lassen sich neue Technologien, Komponenten und Verbesserungen nun sehr leicht mit einem kleinen Kundenkreis temporär testen, bevor Sie auf den anderen Pods für alle ausgerollt werden.

Der Failover Fall

Es kann immer passieren, dass eine Komponente ausfällt, zu langsam arbeitet oder etwas unerwartetes passiert. Aus diesem Grund läuft auf jedem Pod ein eigenes Monitoring. Dieses Monitoring ist eine Eigenentwicklung speziell auf unsere Struktur angepasst. Es prüft verschiedene Szenarien, die auf einem Pod zu Problemen führen können und alarmiert immer die Server-Eye falls eines der Szenarien eintritt. Der Reverse Proxy vor den Pods fragt regelmäßig die einzelnen Monitoring Systeme nach Ihrem Status und schaltet den Pod ab, falls der Status nicht zufriedenstellend ist.

Die alarmierten Techniker prüfen die involvierten Komponenten, beheben das Problem und schalten den Pod wieder aktiv. Der Failover Fall wird also voll automatisiert eingeleitet, immer die Server-Eye Techniker informiert und manuell behoben.

Failover Szenarien und dieser Samstag

Wie erwähnt kam es diesen Samstag zu Fehlalarmen. Eine extrem zuverlässig arbeitende Komponente wird bereits seit langem überwacht und wird automatisiert gestartet, falls sie abstürzen sollte. In diesem Fall hat aber das Startscript, welches auch beim Serverstart ausgeführt wird, um die Komponenten zu starten, nicht mehr funktioniert. Dieses Szenario ist nicht über ein weiteres Monitoring abgedeckt. Dadurch griff das Monitoring mit dem Einleiten des Failover Falls erst nach wenigen Minuten, anstatt wie üblich nach ein paar Sekunden, ein. Durch den schnellen manuellen Eingriff konnte der Grund des Ausfalls schnell behoben und die Funktionalität nach kurzer Zeit wieder hergestellt werden.

Ergebnis

Die genauen Details, wieso die Komponente ausgefallen ist, befinden sich noch in der Analyse. Für uns ergibt sich aber vor allem die Erkenntnis, die man im Tagesgeschäft nicht immer wahrhaben möchte. Selbst die sicherste und zuverlässigste Komponente wird irgendwann ausfallen. Auch darauf sollte man vorbereitet sein und es im Idealfall vorher erkennen. Wir werden uns deshalb nochmals unsere Failover Szenarien ansehen und das Monitoring der einzelnen Komponente erweitern. Hätte das Monitoring diesen Fall sofort erkannt, hätten wir eher eingreifen können.

Bei Fragen zu unserer Cloud können Sie sich gerne jederzeit an uns wenden und eventuell hat der Artikel auch Ihnen ein paar Denkanstöße geliefert.