Edge-Systeme arbeiten dezentral, müssen aber zentral beherrschbar bleiben. Standardisierung, Remote-Management, Security und Recovery entscheiden darüber, ob verteilte Infrastruktur auch mit vielen Standorten zuverlässig betrieben werden kann – oft ohne eigenes IT-Personal vor Ort.

Ein Edge-System ist schnell aufgestellt. Zehn sind noch überschaubar. Bei 100 oder 500 Standorten wird daraus eine Betriebsaufgabe. Dann müssen Updates verteilt, Konfigurationen vereinheitlicht, Ausfälle erkannt, Zugriffe kontrolliert und lokale Daten geschützt werden. Häufig gibt es vor Ort kein IT-Personal, trotzdem sollen die Systeme möglichst autonom weiterarbeiten und sich zentral überwachen lassen.

Die Systeme arbeiten dezentral, verwalten lassen sollten sie sich trotzdem zentral. Unterschiedliche Hardware-Stände, Konfigurationsfehler, unterbrochene WAN-Verbindungen oder ungepatchte Systeme können aus einzelnen Edge-Installationen schnell schwer beherrschbare Inseln machen. Gleichzeitig wächst mit jedem zusätzlichen Standort die Angriffsfläche und die Frage, was im Fehlerfall wiederhergestellt werden muss.

IT-Verantwortliche müssen deshalb zwei Anforderungen zusammenbringen: Der Edge soll lokal funktionieren, aber zentral steuerbar bleiben. Systeme müssen sich möglichst standardisiert ausrollen, überwachen und aktualisieren lassen. Fällt Hardware aus, sollte zudem klar sein, was einfach neu bereitgestellt werden kann und welche Daten oder Konfigurationen gesichert sein müssen.

Im ersten Teil unserer Edge-Serie ging es darum, welche Workloads überhaupt an den Edge gehören und welche besser im lokalen RZ, Core oder in der Cloud laufen. Ist diese Entscheidung gefallen, beginnt die nächste Aufgabe: Wie lässt sich die verteilte Infrastruktur so betreiben, dass aus vielen kleinen Standorten kein ebenso großes Managementproblem entsteht?

Doc Storage lag mit Edge richtig

Vor rund vier Jahren ging Doc Storage bereits der Frage nach, welche Bedeutung Edge-Computing für Storage bekommen würde. Vieles von dem, was damals absehbar war, ist heute Realität: Verarbeitung und Storage sind näher an Maschinen, Sensoren und andere Datenquellen gerückt. Latenz, wachsende Datenmengen und die Forderung nach einem lokal möglichst autonomen Betrieb haben diese Entwicklung vorangetrieben.

Dabei hat sich Edge weniger zu einer klar abgegrenzten Produktkategorie entwickelt als zu einem Architekturprinzip. Je nach Anwendung reicht die Spanne vom Industrie-PC an der Maschine über einen Server in der Filiale bis zum kleinen Cluster am Produktionsstandort. Entscheidend ist nicht die Bauform, sondern dass Verarbeitung und Datenhaltung näher an die Quelle rücken.

Die Verlagerung schafft allerdings neue Aufgaben. Je mehr Compute und Storage über Produktionsstandorte, Filialen und andere Außenstellen verteilt werden, desto aufwendiger wird ihr Betrieb. Aus der damaligen Frage, ob und warum Daten an den Edge wandern, ist deshalb eine neue geworden: Wie lassen sich all diese verteilten Systeme dauerhaft überwachen, aktualisieren, absichern und im Fehlerfall wiederherstellen?

Edge bleibt verteilt – Überwachung, Updates und Schutz gehören trotzdem in eine zentrale Steuerung. (Grafik: KI-generiert mit DALL-E, speicherguide.de)

Zentral steuern, lokal weiterarbeiten

Ein einzelnes Edge-System lässt sich noch wie ein klassischer Server behandeln. Es wird installiert, konfiguriert und bei Bedarf manuell aktualisiert. Dieses Vorgehen skaliert allerdings schlecht. Wer Dutzende oder Hunderte Produktionsstandorte, Filialen oder Außenstellen betreibt, kann nicht für jedes Software-Update einen Administrator losschicken.

Installation, Konfiguration, Software-Verteilung, Monitoring und Updates müssen deshalb möglichst weitgehend aus der Ferne erfolgen. Neue Edge-Systeme sollten nach festgelegten Vorgaben eingerichtet und anschließend zentral überwacht werden können. Wichtig ist dabei vor allem die Standardisierung. Je mehr Sonderkonfigurationen sich an einzelnen Standorten ansammeln, desto schwieriger werden Support, Fehlersuche und Security.

Das bedeutet nicht, dass jeder Standort identisch aufgebaut sein muss. Eine Produktionslinie stellt andere Anforderungen als eine Filiale oder ein Logistikzentrum. Innerhalb vergleichbarer Standorttypen sollten Hardware, Betriebssystem, Anwendungen und Konfigurationen aber möglichst nach wiederholbaren Vorgaben bereitgestellt werden.

Auch sogenanntes Zero-Touch-Provisioning zielt darauf: Ein neues oder ausgetauschtes Gerät erhält nach dem Anschluss möglichst automatisch die vorgesehene Konfiguration und Software. Im Fehlerfall muss dann nicht ein Spezialist zum Standort fahren und das Ersatzgerät von Hand aufbauen. Edge darf dezentral arbeiten. Der Betrieb sollte möglichst zentral und standardisiert bleiben.

Security beginnt mit Sichtbarkeit

Verteilte Infrastruktur erweitert die Angriffsfläche. Edge-Systeme stehen häufig außerhalb eines klassischen Rechenzentrums, beispielsweise in Produktionshallen, Lagern oder Filialen. Teilweise sind sie physisch leichter zugänglich und gleichzeitig mit Maschinen, lokalen Netzen sowie zentralen IT-Systemen verbunden.

Der erste Schritt klingt banal, ist in großen Umgebungen aber entscheidend: IT-Verantwortliche müssen wissen, welche Systeme überhaupt vorhanden sind, welche Software darauf läuft und welchen Patchstand sie haben. Gerade in Produktionsumgebungen treffen dabei häufig moderne IT-Systeme auf Anlagen mit deutlich längeren Lebenszyklen.

Ebenso wichtig ist es, Abweichungen sichtbar zu machen. Ein unbekanntes Gerät, ein veralteter Softwarestand oder eine ungeplante Verbindung zwischen IT- und OT-Netz sollten nicht erst bei einem Sicherheitsvorfall auffallen.

Hinzu kommt die Verbindung zwischen IT und OT. Nicht jedes Edge-System benötigt Zugriff auf jedes Netz oder jede Anwendung. Sinnvoll ist eine klare Trennung und die gezielte Freigabe der tatsächlich erforderlichen Kommunikationswege. Die praktische Frage lautet daher weniger: Wie sichern wir den gesamten Edge ab? Sondern: Welche Systeme dürfen mit wem sprechen und welche Zugriffe werden wirklich benötigt?

Was sich reproduzieren lässt, wird neu bereitgestellt. Nicht reproduzierbare Daten brauchen Backup und Recovery. (Grafik: KI-generiert mit DALL-E, speicherguide.de)

Was muss am Edge wirklich gesichert werden?

Beim Backup lohnt sich eine Unterscheidung zwischen Infrastruktur und Daten. Ein Edge-System, dessen Betriebssystem, Anwendungen und Konfiguration vollständig automatisiert neu bereitgestellt werden können, muss nicht zwingend als komplettes System gesichert werden. Im Fehlerfall kann es schneller sein, ein Ersatzgerät bereitzustellen und den definierten Zustand neu aufzuspielen.

Anders sieht es bei Informationen aus, die nicht aus einer zentralen Vorlage wiederhergestellt werden können. Dazu zählen beispielsweise Produktions- und Messdaten, lokale Datenbanken, lokal veränderte Konfigurationen, noch nicht synchronisierte Daten, Protokolle oder Anwendungszustände. Sie lassen sich nicht einfach reproduzieren und benötigen deshalb eine klare Backup- und Recovery-Strategie.

Für IT-Verantwortliche ergibt sich daraus eine nützliche Trennung: Reproduzierbare Infrastruktur wird neu bereitgestellt, nicht reproduzierbare Daten werden gesichert. Entscheidend ist, diese Grenze vorher zu kennen. Wer erst nach einem Hardwaredefekt feststellt, dass auf dem Gerät noch nicht übertragene Produktionsdaten lagen, hat kein Recovery-Konzept, sondern ein Problem.

WAN-Ausfälle müssen mitgedacht werden

Ein Edge-System soll häufig gerade deshalb lokal arbeiten, weil zentrale Dienste nicht permanent erreichbar sein müssen. Dieses Prinzip muss auch für das Datenmanagement gelten. Fällt die Verbindung zum zentralen RZ oder zur Cloud aus, muss der Standort weiterarbeiten können, ohne dass neue Daten verloren gehen.

Dafür müssen einige Fragen vorab beantwortet sein: Wie lange soll ein Standort autonom laufen können? Wie viele Daten entstehen in dieser Zeit? Wie viel lokale Kapazität wird benötigt und was passiert, wenn der Speicher vollläuft? Ebenso wichtig ist, wie die Daten nach Wiederherstellung der Verbindung mit zentralen Systemen synchronisiert werden.

Damit hängen Verfügbarkeit und Storage unmittelbar zusammen. Ein Edge-System kann technisch weiterlaufen und trotzdem schlecht geplant sein, wenn seine lokale Kapazität nach zwei Stunden erschöpft ist. Für die Dimensionierung zählt deshalb nicht nur der Normalbetrieb, sondern auch ein realistischer Zeitraum ohne Verbindung zum Core oder zur Cloud.

Vom Technologieversprechen zur Betriebsaufgabe

Die ursprünglichen Argumente für Edge-Computing gelten weiterhin: kurze Reaktionszeiten, weniger Datenverkehr und die Möglichkeit, Daten dort zu verarbeiten, wo sie entstehen. Verändert hat sich vor allem die Größenordnung.

Je mehr Systeme nach außen wandern, desto wichtiger werden Standardisierung, Lifecycle-Management, Security und Recovery. Der einzelne Edge-Server ist selten das eigentliche Problem. Entscheidend ist, ob sich 50 oder 500 davon mit vertretbarem Aufwand betreiben lassen.

Ein gut geplantes Edge-System sollte deshalb möglichst autonom arbeiten, zentral sichtbar bleiben und im Fehlerfall entweder reproduzierbar oder wiederherstellbar sein. Genau dort trennt sich eine interessante Edge-Idee von einer Infrastruktur, die im Alltag tatsächlich funktioniert.