Disaster Recovery in IoT-Systemen
Auf alles vorbreitet
Veröffentlicht in Ausgabe 12/2023 - PRAXIS
Das Disaster Recovery (DR) hat im Unterschied zum Backup und Restore nicht nur die Wiederherstellung der Daten, sondern aller Ressourcen eines IT-Systems im Fokus. Das Internet of Things (IoT) stellt dabei eine besondere Umgebung dar, die sich durch eine Vielzahl unterschiedlicher Ressourcen auszeichnet: IoT-Endgeräte, Edge-Server, Netzwerkverbindungen sowie Verarbeitungs- und Speicherressourcen im Backend (Bild 1). Jede dieser Ressourcen kann Opfer eines katastrophalen Ereignisses werden.
Viele mögliche Schadensereignisse
IoT-Endgeräte in Form von Sensoren und Aktoren befinden sich oft in wenig geschützten Umgebungen und Überflutungen, Stürme oder elektromagnetische Impulse bringen sie zum Ausfall. Hinzu kommt die Verwundbarkeit durch Angriffe. IT-Verantwortliche müssen sich daher Gedanken machen, wie sie ausgefallene Geräte zum Beispiel durch das Vorhalten von Austauschgeräten ersetzen können. Bei geographisch ausgedehnten Schadensereignissen mit einer Vielzahl betroffener Devices kann sich ein zeitnaher Tausch jedoch als undurchführbar erweisen. Daher ist auch auf der höher gelegenen Ebene des Business Continuity Managements einzuplanen, wie sich trotz des Ausfalls von Sensoren und Aktoren Geschäftsprozesse temporär aufrechterhalten lassen.
Netzwerkverbindungen sind eine weitere Quelle von Ausfällen. Für das Anbinden von Endgeräten kommen häufig Funknetze zum Einsatz. Diese können ebenfalls einer Vielzahl von Schadensereignissen ausgesetzt sein. Ein Lösungsansatz ist das Verwenden redundanter Funktechnologien wie etwa WLAN und Mobilfunk. Bei hochwertigen Endgeräten kann die Ausstattung mit mehreren Funktechnologien wirtschaftlich vertretbar sein, bei kostengünstigen Sensoren ist dies jedoch in der Regel nicht der Fall.
Das Disaster Recovery (DR) hat im Unterschied zum Backup und Restore nicht nur die Wiederherstellung der Daten, sondern aller Ressourcen eines IT-Systems im Fokus. Das Internet of Things (IoT) stellt dabei eine besondere Umgebung dar, die sich durch eine Vielzahl unterschiedlicher Ressourcen auszeichnet: IoT-Endgeräte, Edge-Server, Netzwerkverbindungen sowie Verarbeitungs- und Speicherressourcen im Backend (Bild 1). Jede dieser Ressourcen kann Opfer eines katastrophalen Ereignisses werden.
Viele mögliche Schadensereignisse
IoT-Endgeräte in Form von Sensoren und Aktoren befinden sich oft in wenig geschützten Umgebungen und Überflutungen, Stürme oder elektromagnetische Impulse bringen sie zum Ausfall. Hinzu kommt die Verwundbarkeit durch Angriffe. IT-Verantwortliche müssen sich daher Gedanken machen, wie sie ausgefallene Geräte zum Beispiel durch das Vorhalten von Austauschgeräten ersetzen können. Bei geographisch ausgedehnten Schadensereignissen mit einer Vielzahl betroffener Devices kann sich ein zeitnaher Tausch jedoch als undurchführbar erweisen. Daher ist auch auf der höher gelegenen Ebene des Business Continuity Managements einzuplanen, wie sich trotz des Ausfalls von Sensoren und Aktoren Geschäftsprozesse temporär aufrechterhalten lassen.
Netzwerkverbindungen sind eine weitere Quelle von Ausfällen. Für das Anbinden von Endgeräten kommen häufig Funknetze zum Einsatz. Diese können ebenfalls einer Vielzahl von Schadensereignissen ausgesetzt sein. Ein Lösungsansatz ist das Verwenden redundanter Funktechnologien wie etwa WLAN und Mobilfunk. Bei hochwertigen Endgeräten kann die Ausstattung mit mehreren Funktechnologien wirtschaftlich vertretbar sein, bei kostengünstigen Sensoren ist dies jedoch in der Regel nicht der Fall.
Edge-Server stehen in räumlicher Nähe zu den Endgeräten und fungieren als Kommunikationsgateways oder führen Applikationen zur lokalen Verarbeitung und Speicherung von IoT-Daten aus. Sie können schnelle Reaktionszeiten garantieren und zudem das Datenvolumen, das an das Backend geschickt werden muss, verringern. Bei Edge-Servern finden sich ähnliche Recovery-Mechanismen wie im Backend: Vorhalten von Standby-Servern, Datenreplikation, Backup und Restore et cetera. Die Wahlfreiheit bei der Platzierung von Standby-Serveoch durch die Anforderung eingeschränkt, dass Edge-Server qua Definition in der Nähe der Endgeräte installiert werden müssen. Recovery-Mechanismen für das Backend diskutieren wir später noch ausführlicher, dazu müssen wir zunächst die typische Architektur eines IoT-Backends betrachten.
Bedeutung der Daten – Speed- und Batch-Layer
IoT-Backends basieren häufig auf der sogenannten Lambda-Architektur [1], deren ideale Struktur Bild 2 darstellt. Das wesentliche Merkmal ist die Auftrennung in zwei Verarbeitungspfade: Speed-Layer und Batch-Layer. Alle empfangenen Nachrichten werden gleichzeitig an Speed- und Batch-Layer weitergeleitet.
Das IoT-Cloudgateway bildet die Schnittstelle zwischen Backend und der Welt der IoT-Endgeräte und Edge-Server. Es realisiert die beidseitige sichere Kommunikation mit der Endgerätewelt mittels standardisierter IoT-Protokollstacks. Für jedes verbundene Device hält das Gateway Stamm- und Authentifizierungsdaten bereit. Es beinhaltet zudem in der Regel Funktionen zur Filterung und Anreicherung der empfangenen Nachrichten sowie zum Routing an die nachfolgenden Verarbeitungsstufen.
Typische Implementierungen eines solchen Gateways sind beispielsweise "MS Azure IoT Hub" oder "AWS IoT Core". Eine ausführlichere Beschreibung der IoT-Cloudgateways der beiden führenden Cloudprovider findet sich im IT-Administrator 09/2023 [2].
Der Speed-Layer ist in der Lage, die eingehenden Nachrichten in Echtzeit zu verarbeiten und somit Echtzeitsichten auf den Zustand der Dinge in der realen Welt zu generieren. Beispiele dafür sind die Werte eines Sensors laufend über ein Zehn-Minuten-Fenster zu mitteln oder das Vorkommen bestimmter Ereignisse zu zählen. Neben der Datenaggregation über ein laufendes Zeitfenster ist diese Schicht auch in der Lage, Alarme zu genieren und automatische Aktionen anzustoßen, wenn Schwellenwerte überschritten werden. Der Speed-Layer basiert typischerweise auf der Stream-Processing-Technologie, wie sie etwa die Open-Source-Frameworks Apache Flink, Apache Kafka oder Apache Spark liefern.
Der Batch-Layer kann große Datenmengen über längere Zeiträume speichern und diese Daten in periodisch laufenden Batch-Jobs verarbeiten. In diesem Layer erfolgen statistische Auswertungen über längere Zeiträume. Mit den hier gespeicherten Daten lassen sich in industriellen Anwendungen unter anderem Modelle für die vorausschauende Wartung (Predictive Maintenance) trainieren.
Speed- und Batch-Layer unterscheiden sich nicht nur hinsichtlich der Schnelligkeit der Datenverarbeitung, sondern auch hinsichtlich der Qualität der verwendeten Daten. Manchmal treffen Endgeräte-Nachrichten verspätet im Backend ein. Das kann dazu führen, dass solche Informationen in den Berechnungen des Speed-Layers fehlen. Im Batch-Layer ist so etwas unkritisch, da ein Batch-Job, der zum Beispiel alle Nachrichten des Vortages verarbeitet, ohnehin mit Verzögerung startet. Typischerweise sind bis dahin auch die verspäteten Nachrichten eingetroffen.
Zusammengefasst: Der Speed-Layer arbeitet zwar schnell, aber mit möglicherweise unvollständigen Daten und der Batch-Layer arbeitet dagegen zeitverzögert, aber mit vollständigen Daten. Die höhere Qualität der Berechnungsergebnisse im Batch-Layer bedeutet auch, dass die Ergebnisse des Speed-Layers gelöscht werden können, sobald die Ergebnisse des Batch-Layers über denselben Berechnungszeitraum vorliegen.
Die Berechnungsergebnisse von Speed- und Batch-Layer werden im Serving-Layer in Form von Speed- und Batch-Views zur Verfügung gestellt. Der Serving-Layer bietet somit eine einheitliche Sicht auf die Berechnungsergebnisse beider Layer.
Begrifflichkeiten der Notfallplanung
Disaster Recovery (DR) hat die Wiederherstellung der Funktionsfähigkeit eines IT-Systems nach einem katastrophalen Ausfall zum Ziel. Dies beinhaltet nicht nur die Wiederherstellung von Daten, sondern auch von Ressourcen für Datenverarbeitung (Server, Applikationen) und Datenkommunikation. Die wichtigsten Kennzahlen eines DR-Prozesses sind RTO und RPO.Recovery Time Objective (RTO) gibt die maximal tolerierbare Zeitspanne vom Ausfall eines IT-Systems bis zu dessen vollständiger Wiederherstellung an. Da moderne IT-Infrastrukturen modular aufgebaut sind, ist es sinnvoll, RTO nach Diensten beziehungsweise Subsystemen und deren Wichtigkeit zu differenzieren.Recovery Point Objective (RPO) gibt den maximal tolerierbaren Zeitraum an, über den Daten verloren gehen dürfen. In einer einfachen Betrachtung bedeutet das, dass zum Zeitpunkt eines Systemausfalls die letzte intakte Datensicherung nicht älter als das RPO sein darf. Allerdings ist in IoT-Systemen zu beachten, dass auch während der Wiederherstellung weiterhin Daten verloren gehen können. IoT-Endgeräte werden auch während eines Backend-Ausfalls versuchen, weiterhin Daten zu senden. Ohne passende Puffer- und Retry-Mechanismen auf den Endgeräten sind solche Informationen unwiederbringlich verloren.Business Continuity Management (BCM) beschäftigt sich damit, die Geschäftstätigkeit eines Unternehmens auch nach katastrophalen Ereignissen sicherzustellen. BCM betrachtet nicht nur IT-relevante Ereignisse, sondern auch Vorfälle, die Auswirkungen auf die Verfügbarkeit anderer Ressourcen (Gebäude, Personal et cetera) haben. Zum BCM gehört auch die Planung von Ersatzprozessen.
Layer-spezifisches Disaster Recovery
Speed- und Batch-Layer stellen unterschiedliche Anforderungen an das Disaster Recovery. Im Speed-Layer erfolgt die Verarbeitung unter Echtzeitbedingungen. Selbst kurzzeitige Unterbrechungen verursachen Schäden im Geschäftsprozess – beispielsweise wenn das Überschreiten von Schwellenwerten in einer Industrieanlage keinen Alarm auslöst oder wenn das Dispositionsteam in einer Spedition keine aktuelle Übersicht über die Fahrzeugstandorte besitzt. Die Kenngröße RTO kann daher im Speed-Layer abhängig vom abgebildeten Geschäftsprozess im Bereich weniger Minuten liegen. Der Batch-Layer verarbeitet eingehende Nachrichten zeitversetzt, sodass ein deutlich größerer RTO-Wert akzeptabel ist – je nach Anwendung bis zu mehreren Stunden.
Bei der Kenngröße RPO sind die Zusammenhänge komplexer: Gehen beispielsweise in einem Logistikprozess während eines Ausfalls des Speed-Layers die Positionsdaten von Objekten verloren, kann das für die Fortsetzung des Geschäftsprozesses zwar ärgerlich, aber dennoch tolerierbar sein, da die Objekte nach Wiederherstellung des Layers ohnehin neue Positionsdaten senden. Im Batch-Layer muss dagegen allein aus gesetzlichen Gründen ein Geschäftsprozess lückenlos dokumentiert sein. Ein Verlust von Positionsdaten kann daher im Batch-Layer inakzeptabel sein.
Eine Besonderheit von IoT-Systemen ist, dass sich verloren gegangene Daten durch Resynchronisation mit den IoT-Endgeräten wiederherstellen lassen. IoT-Devices halten gesendete Nachrichten typischerweise in einem Puffer und überschreiben diese erst dann, wenn der Puffer belegt ist. Nachrichten, die noch im Puffer der Endgeräte gespeichert sind, kann das Backend zur erneuten Übertragung anfordern. Voraussetzung für diese Art der Wiederherstellung von Daten ist, dass Backend und Endgeräte das Verfahren unterstützen und die fehlenden Daten zeitnah angefragt werden.
IoT-Backend am Beispiel Azure-IoT
Im Folgenden betrachten wir die zuvor beschriebene generische Systemarchitektur anhand eines konkreten Beispiels mit den Diensten der Azure-Cloud. Die Realisierung dieser Architektur ist jedoch auch mit den Diensten anderer Provider wie Amazon Web Services (AWS) möglich.
Azure bietet eine Vielzahl an Diensten für das Speichern und Verarbeiten von IoT-Daten [3]. Eine einfache Umsetzung einer Lambda-Architektur mit Azure-Komponenten zeigt Bild 3. Das Beispiel verwendet lediglich einen Ausschnitt an Diensten, soweit sie für die nachfolgende Diskussion der DR-Mechanismen hilfreich sind. Eine reale Implementierung setzt in der Regel weitere Dienste mit komplexeren Verknüpfungen zwischen den Diensten ein.
Der "Azure IoT Hub" übernimmt die Rolle des im vorangegangenen Abschnitts beschriebenen IoT-Cloudgateways. Der IoT-Hub kann die empfangenen Daten gleichzeitig in Speed- und Batch-Layer einspeisen. Die Streaming-Plattform Azure Stream Analytics bildet das Kernstück des Speed-Layers. Die Berechnungsergebnisse dieses Layers landen in der Azure Cosmos DB, einem Datenbankdienst, der sowohl unstrukturierte als auch semistrukturierte (XML, JSON) Daten speichert.
Im Batch-Layer übernimmt der Dienst "Azure Data Lake Storage" die langfristige Speicherung der empfangenen Nachrichten, sodass sie für statistische Analysen über größere Zeiträume zur Verfügung stehen. Solche Analysen können mithilfe Azure Synapse Analytics ausgeführt werden, einer Plattform mit einer breiten Palette an Werkzeugen für die Analyse großer Datenbestände. Wie schon im Speed-Layer, wandern auch diese Berechnungsergebnisse in die Cosmos DB.
Disaster Recovery im Azure-IoT
Microsoft Azure bietet eine Vielzahl an Mechanismen, um die Verfügbarkeit und Wiederherstellbarkeit von Diensten sicherzustellen. Grundsätzlich ist die Azure-Cloud regional aufgebaut und jede dieser Regionen besteht aus drei voneinander unabhängigen, physisch getrennten Standorten, den sogenannten Verfügbarkeitszonen (availability zones). Jede Zone umfasst ein oder mehrere Rechenzentren. Bild 4 zeigt die Zusammenhänge zwischen Regionen, Zonen und die Arbeit der nachfolgend erläuterten Replikationsmechanismen.
Microsoft unterscheidet folgende Dienstvarianten: zonale, zonenredundante und ständig verfügbare. Zonale Dienste wie zum Beispiel virtuelle Maschinen werden auf Anforderung des Kunden nur in einer bestimmten Zone bereitgestellt. Zonenredundante Services replizieren über alle Zonen einer Region synchron, das heißt, alle Änderungen werden gleichzeitig in alle Zonen geschrieben. Beim Ausfall einer Zone arbeiet der Dienst somit nahtlos ohne Datenverlust weiter. Ständig verfügbare Dienste sind global gegen die Ausfälle von Zonen und Regionen abgesichert. Dazu gehören beispielsweise Entra ID (Azure Active Directory) oder Azure DNS. Alle Azure-Dienste, die wir im zuvor beschriebenen Beispiel verwenden, gehören zu den zonenredundanten. Sie sind demnach mittels synchroner Replikation gegen Ausfälle einzelner Zonen abgesichert.
Um den IoT-Hub-Dienst auch gegen den Ausfall einer gesamten Region abzusichern, gibt es die Möglichkeit, ihn in einer fest zugeordneten Nachbarregion wiederherzustellen. Zu diesem Zweck wird der IoT-Hub laufend asynchron dorthin repliziert. Da diese Replikation asynchron stattfindet, muss der IT-Verantwortliche bei der Wiederherstellung mit Datenverlusten (RPO) in der Größenordnung von null bis fünf Minuten rechnen. Die Wiederherstellungszeit (RTO) liegt im Bereich von wenigen Minuten bis mehreren Stunden – abhängig davon, ob die Wiederherstellung manuell durch den Kunden oder seitens Microsoft erfolgt. Manuelle Wiederherstellungen sind in der Regel schneller, die benötigte Zeit hängt von der Anzahl verwalteter Endgeräte ab. Microsoft nennt als Richtwert 15 Minuten pro 100.000 Endgeräte.
Azure Cosmos DB unterstützt neben der Zonenredundanz auch Hochverfügbarkeitskonfigurationen mittels regionsübergreifender Datenreplikation. Für das Sichern der Cosmos DB gibt es zwei Modi: fortlaufendes Backup und regelmäßiges Backup. Fortlaufende Sicherungen überdecken ein konfigurierbares Zeitintervall von 30 oder sieben Tagen und erlauben es, die Datenbank zu jedem beliebigen Zeitpunkt innerhalb dieses Zeitintervalls wiederherzustellen. Regelmäßige Backups erfolgen in der Standardkonfiguration alle vier Stunden, minimal ist ein Backupintervall von einer Stunde zulässig.
Azure Data Lake unterstützt Zonenredundanz. Bei Speicherdiensten bezeichnet Microsoft dies auch als "Zonenredundanter Speicher" (ZRS). Zum Schutz gegen den Ausfall einer Region lassen sich die Daten zusätzlich asynchron in eine zweite Region replizieren, was Microsoft "Geozonenredundanter Speicher" (GZRS) nennt. Backup und Restore eines Data Lakes ist unter anderem über den Dienst "Azure Data Factory" möglich.
Fazit
Wir haben in diesem Artikel das Disaster Recovery in cloudbasierten IoT-Backends untersucht, die Schlussfolgerungen sind jedoch auch auf andere Anwendungssysteme in der Cloud übertragbar. Im Unterschied zu den monolithischen Systemen der Vergangenheit bestehen moderne IT-Umgebungen aus Subsystemen mit spezialisierten Verarbeitungs- und Speichertechnologien. Dies ermöglicht es, differenzierte Anforderungen an die Notfallwiederherstellung der Subsysteme umzusetzen und sie in der Reihenfolge ihrer Dringlichkeit wiederherzustellen.
Das gezeigte Beispiel verwendet vornehmlich serverlose Clouddienste. Diese entlasten das Betriebsteam in kritischen Situationen, denn es kann die Wiederherstellung von Serverhardware, Betriebssystemen, Middleware und Netzwerk dem Cloudprovider überlassen und sich auf die Wiederherstellung seiner Anwendung konzentrieren.
Die Vielfalt an Clouddiensten sowie die weltweite Verfügbarkeit von Verarbeitungs- und Speicherressourcen eröffnet vielfältige Möglichkeiten zur Konfiguration von ausfallsicheren Systemen und zur Wiederherstellung im Fehlerfall. Allerdings gibt es Clouddienste nicht zum Nulltarif. Erforderlich ist ein striktes Kostenmanagement, damit die konfigurierten Dienste und Wiederherstellungsmechanismen zu den Anforderungen des Geschäftsprozesses passen, aber nicht darüber hinausschießen. Ansonsten wird der IT-Verantwortliche spätestens nach Erhalt der ersten Rechnung feststellen, dass die verwendeten Cloudfeatures und das verfügbare IT-Budget nicht kompatibel sind.
(jp)
Link-Codes
[1] Nathan Marz, James Warren: "Big Data": https://www.manning.com/books/big-data/
[2] Management von IoT-Devices in IT-Administrator 09/23: https://www.it-administrator.de/heftarchiv-article?xv_article=ADMIN_2023_09_044
[3] Azure-Dokumentation: https://learn.microsoft.com/de-de/azure/