Software & Security Plattformen wiederherstellen

Bild: Moxa
13.06.2014

Korrumpierungen in der Software eines Root-Systems bahnen sich langsam an und können letztlich das Betriebssystem lahmlegen. Derzeit ist noch menschliches Eingreifen nötig, um das System wieder herzustellen. Doch das muss nicht sein: Dies kann auch automatisiert erfolgen.

Je tiefer Industrie-PCs in die Prozessautomation eindringen, desto größer wird die Gefahr des Datenverlusts und der Systemkorrumpierung, insbesondere im Hinblick auf Sicherheitsthemen und die gesamte Systemverfügbarkeit. Mit steigendem Alter eines Betriebssystems bahnen sich kleinere Korrumpierungen den Weg in die Software des Root-Systems und verlangsamen dieses. Schließlich, und das manchmal schnell und plötzlich, werden dann aus kleinen Korrumpierungen große, die das gesamte Betriebssystem lahmlegen. Die ärgerlichsten Probleme sind natürlich jene, die nicht durch dezentrale Fehlersuche und -Behebung und Rekonfiguration behoben werden können: wenn ein Systemadministrator ein stillstehendes System nicht schnell und zuverlässig wieder in Gang bringen kann, ist die effektivste Lösung der schnellstmögliche Austausch des Systems – Hardware oder Software.

Hinzu kommt, dass Computer in der Prozessautomation in den vergangenen Jahren zunehmend als Embedded-Geräte ohne Möglichkeit zur lokalen Änderung oder Eingabe eingesetzt wurden. Keyboards, Mäuse und sogar Monitore sind oftmals nicht vorhanden, sodass auf viele Steuergeräte nur über Netzwerkverbindungen, das Scada oder eine Fernwirkstation zugegriffen werden kann. Die Verwaltung mehrerer Embedded-Computer von einem dezentralen Scada-System aus ist meistens auch für Personen knifflig, die sich mit der Fehlerbehebung bei Desktopsystemen auskennen und mit einem Office-Computer oder Enterprise-Server zurechtkommen. Solche Probleme werden für Administratoren, die Systeme das ganze Jahr rund um die Uhr verfügbar halten müssen, schnell zum lästigen Übel. Vorbeugende Wartung ist deshalb zu einem wichtigen Thema für die Technologien und Gesamtlösungen geworden – Beispiele dafür finden sich in den Systemen von Wind- und Solarparks, im öffentlichen Nahverkehr und viele mehr. Diese Systeme haben Anforderungen, die weit über das hinausgehen, was die übliche Datenrettungssoftware für Systeme, die nicht mehr booten, anbietet.

Bei keiner der derzeit auf dem Markt erhältlichen Lösungen handelt es sich um voll automatisierte Standalone-Systeme, die die komplette Plattform vor einem permanenten System-Crash retten können. Stattdessen haben die bisherigen Angebote im Markt die Software-Lösungen von Anbietern wie Acronis und Ghost oder Open-Source-Lösungen wie Clonezilla nur angepasst und leiden allesamt unter einem grundlegenden Konstruktionsfehler: sie arbeiten im User-Space.

Das bedeutet, dass menschliches Eingreifen zur Wiederherstellung per Fernzugriff notwendig wird, wenn ein Betriebssystem durch Softwarekorrumpierung abstürzt. Während es theoretisch möglich ist, eine Software-Lösung zu konfigurieren, die die Fernverwaltung ermöglicht, erfordert das im Einzelfall eine Menge detailliertes – und kostenintensives – Coding und Zuverlässigkeitsprüfungen. Und dennoch ist es wahrscheinlich, dass sich Bugs einschleichen, und dass das System eine vernetzte Lösung benötigt, die weiterhin menschliche Verwaltung und Überwachung erfordert.

Die Alternative für die effektive Wiederherstellung einer Plattform ist eine Lösung, die sowohl das Betriebssystem neu schreiben kann, wenn es durch Korrumpierung verlangsamt wurde, als auch die Wiederherstellung nach einem kompletten Absturz leisten kann, wenn die Maschine nicht mehr bootet.

Automatisierter Mechanismus

Dafür ist ein automatisierter Mechanismus erforderlich, der mit der Hardwareplattform auf BIOS-Ebene integriert wird; eine Funktion, die die gesamte installierte Software – Betriebssystem, alle Anwendungen und die vollständige Systemkonfiguration – auf Block-Level-Ebene von gespeicherten Kopien neu schreiben kann und dann wieder in den normalen Betrieb bootet. Eine derartige Lösung wäre in der Lage, die gesamte Plattform auf ihren frühesten Konfigurationsstatus zurückzusetzen, was das vollständige Softwaresystem effektiv in seinen ursprünglichen Betriebszustand versetzen würde.

Die folgenden vier Vorgehensweisen für den Re-Write zusammen genommen erlauben es jedem automatisierten Re-Write-Mechanismus, die Effizienz und den Komfort der vorbeugenden Wartung zu maximieren, während alle möglichen Systemausfälle, hervorgerufen durch Software-Korrumpierung, automatisch verhindert werden:

  • automatische Re-Writes zu geplanten Zeiten,

  • vollautomatisierte Wiederherstellung von Systemausfällen oder -Verlangsamung,

  • per Fernzugriff initiierte, automatische Wiederherstellung,

  • manuelle Wiederherstellung, die physisch vor Ort am Gerät initiiert wird.

Wenn Software so stark korrumpiert wird, dass das Betriebssystem nicht mehr bootet, kann die automatische Wiederherstellung nur ausgeführt werden, bevor das Betriebssystem startet. Eine effektive Automatisierung der Plattform-Wiederherstellung muss deshalb – mit der Hard- und Software integriert – starten, bevor das Betriebssystem es tut. Das Gerät muss einen alternativen Speichermechanismus für den Einsatz als zugeordnetes Cache unterstützen, von dem aus das Recovery-Image und Betriebsumfeld gelesen werden, während das BIOS selbst durch Hinzufügen eines Watchdogs erweitert werden muss. Der Watchdog misst die Boot-Zeiten, registriert, wenn die Plattform abstürzt oder wenig Leistung bietet, ruft dann automatisch die Wiederherstellungsumgebung auf und überwacht den gesamten Prozess auf (Nicht-)Erfolg hin.

System-Re-Writes schnell konfigurieren

Möglicherweise das Wichtigste ist, dass Ingenieure in der Lage sein sollten, diese automatischen System-Re-Writes aus dem Betriebssystem heraus schnell und einfach konfigurieren zu können und zwar nur mithilfe von Tags und einem Watchdog-Timer. Nachdem sie präzise festgehalten haben, wie lange der Boot-Prozess dauert, können Administratoren einen Dialog öffnen, um einen Time-Out festzulegen. Immer dann, wenn der Boot-Prozess der Plattform langsamer voranschreitet, als der Time-Out es vorgibt, startet das BIOS automatisch den Wiederherstellungsvorgang und überführt den Boot-Prozess des Systems auf eine alternative Wiederherstellungsplattform auf einem separaten Speicherlaufwerk.

Um akkurate und nicht korrumpierte Re-Writes zu garantieren, muss jedoch noch ein weiteres Konstruktionsmerkmal volle Aufmerksamkeit bekommen: Re-Writes sollten auf Block-Level stattfinden und das System nach Bits statt nach Dateien zurückladen. Auf Block-Level ist Korrumpierung weitaus weniger wahrscheinlich, als auf Datei-Ebene. Bit-Level-Re-Writes können die Korrumpierung des physischen Speichergeräts kompensieren. Nur wenn garantiert jedes Bit erfolgreich neu auf das physische Speichergerät der Plattform – ob Festplatte oder SSD – geschrieben wurde, kann der Wiederherstellungsmechanismus garantieren, dass ein erfolgreicher Wiederherstellungsvorgang stattgefunden hat und dass jedes Datenfragment erfolgreich wieder in seinen ursprünglichen Zustand nach der Erstinstallation zurückversetzt wurde.

Um das vorherrschende Problem der System-Verlangsamung zu bekämpfen, müssen Administratoren in der Lage sein, Re-Writes zu geplanten Zeiten zu konfigurieren. Nach einer Schätzung des Zeitpunkts der Verlangsamung durch den Routineeinsatz kann der Administrator die Wiederherstellung in den Ursprungszustand nach Erstinstallation planen, um die Effizienz der vorbeugenden Wartung drastisch zu verbessern und die Leistung der Netzwerkcomputer immer auf dem frischesten Stand gemäß Erstinstallation zu halten.

Vollautomatisierte Wiederherstellung

Wenn das System zu einem definierten Zeitpunkt nicht bootet, ermöglicht der direkte Zugriff auf einen BIOS-Time-Out-Zähler, einen intelligenten Wiederherstellungsprozess in einer sicheren Umgebung zu starten, von dem aus dann Bit für Bit die gesamte Plattform neu geschrieben wird. Sollte die neue Initialisierung scheitern, versucht Moxas Smart Recovery Bot es solange weiter, bis entweder das System erfolgreich wiederhergestellt wird oder das System kontinuierlich weiter ausfällt, woraufhin der Wiederherstellungsmechanismus dies feststellt und es offline nimmt. Die Anzahl der erneuten Wiederherstellungsversuche konfiguriert der Systemadministrator. Natürlich kann das System bei Bedarf auch die Wiederherstellungsversuche weiterführen. Entsprechend der Präferenzen des Administrators können wiederholte Boot-Fehler auch als Hinweis für kritischen Wartungsbedarf dienen. Während volle Automatisierung hilfreich ist, erfordern manche Situationen doch die Benutzer-gesteuerte Wiederherstellung. Diese lässt sich in zwei Basis-Typen unterteilen: per Fernzugriff über Scada oder aus der Leitstelle initiiert oder durch einen Anwender vor Ort gesteuert. „Fern“-Wiederherstellung schließt nicht nur Vorgänge ein, die aus der Entfernung gestartet werden, sondern auch solche, die vor Ort aus einer lokalen Kontrollstelle erfolgen. Der Mechanismus ist eindeutig: Erkennt der Administrator ein Problem, kann er das Gerät per Mausklick offline nehmen und es auffordern, den automatischen Re-Write zu starten. So kann das Gerät nach Bedarf dezentral gesteuert oder gerettet werden. Darüber hinaus kann der Zustand entfernter Einrichtungen stets bewertet werden, ohne Techniker dorthin senden zu müssen.

Manuelle Wiederherstellung vor Ort

Die manuelle Wiederherstellung findet direkt am Gerät statt. Administratoren, die die automatische Wiederherstellung nutzen, können einen USB-Key erstellen, der automatisch einen vollen System-Re-Write auslöst. Manuelle Recovery-Keys sind optimal für die Anwender-initiierte Wiederherstellung, wenn keine ausgebildeten Ingenieure vor Ort sind. Die manuelle Wiederherstellung funktioniert einfach: nachdem der Wartungsbedarf festgestellt wurde, müssen nur der USB-Key ans Gerät angeschlossen und der Computer neu gestartet werden. Die Wiederherstellung geht automatisch – und sicher – vonstatten, ohne weitere notwendige Interaktion. Sobald der Prozess abgeschlossen ist, wird die Plattform entweder auf ihren frühesten Zustand nach Erstinstallation zurückgesetzt oder ihr permanenter Ausfall bestätigt.
Weitere Informationen zu Moxa finden Sie im Business-Profil auf der Seite 60.

Bildergalerie

  • Abbildung 1: Wenn Software so stark korrumpiert wird, dass das Betriebssystem nicht mehr bootet, kann die automatische Wiederherstellung nur ausgeführt werden, bevor das Betriebssystem startet.

    Abbildung 1: Wenn Software so stark korrumpiert wird, dass das Betriebssystem nicht mehr bootet, kann die automatische Wiederherstellung nur ausgeführt werden, bevor das Betriebssystem startet.

    Bild: Moxa

  • Abbildung 2: Intelligente Wiederherstellungsprozesse starten das System in einer sicheren Umgebung, von der aus die Plattform neu geschrieben wird.

    Abbildung 2: Intelligente Wiederherstellungsprozesse starten das System in einer sicheren Umgebung, von der aus die Plattform neu geschrieben wird.

    Bild: Moxa

  • Abbildung 3: Während die volle Automatisierung hilfreich ist, erfordern manche Situationen dennoch eine Benutzer-gesteuerte Wiederherstellung per Fernzugriff oder aus der Leitstelle heraus.

    Abbildung 3: Während die volle Automatisierung hilfreich ist, erfordern manche Situationen dennoch eine Benutzer-gesteuerte Wiederherstellung per Fernzugriff oder aus der Leitstelle heraus.

    Bild: Moxa

Firmen zu diesem Artikel
Verwandte Artikel