Cloud Edge Computing: Hinter dem Rechenzentrum¶

EINE TIEFERE ERKUNDUNG DER EDGE-COMPUTING-ÜBERLEGUNGEN¶

Der „Edge“ im Edge Computing bezieht sich auf die Randbereiche einer Verwaltungsdomäne, möglichst nahe bei diskreten Datenquellen oder Endbenutzern. Dieses Konzept gilt für Telekommunikationsnetze, für große Unternehmen mit verteilten Standorten wie dem Einzelhandel oder für andere Anwendungen, insbesondere im Zusammenhang mit IoT.

Eine der Eigenschaften von Edge Computing besteht darin, dass die Anwendung stark mit der Kantenposition verknüpft ist. Bei Telekommunikationsdiensten würde sich „der Rand“ auf einen Punkt in der Nähe des Endbenutzers beziehen, der jedoch vom Anbieter kontrolliert wird und möglicherweise einige Elemente von Workloads auf Endbenutzergeräten ausführen kann. Für große Unternehmen ist „der Rand“ der Punkt, an dem die Anwendung, der Dienst oder die Arbeitslast verwendet wird (z. B. ein Einzelhandelsgeschäft oder eine Fabrik). Für die Zwecke dieser Definition ist die Kante kein Endgerät mit extrem begrenzter Kapazität zum Unterstützen selbst einer minimalen Cloud-Architektur, wie etwa eines IoT oder einer Sensorvorrichtung. Dies ist eine wichtige Überlegung, da viele Diskussionen über Edge Computing diese Unterscheidung nicht machen.

Edge Computing ähnelt der Datencenter-Datenverarbeitung:

• Es enthält Rechen-, Speicher- und Netzwerkressourcen.
• Ihre Ressourcen können von vielen Benutzern und vielen Anwendungen gemeinsam genutzt werden.
• Es profitiert von der Virtualisierung und Abstraktion des Ressourcenpools.
• Es profitiert von der Möglichkeit, Standardhardware zu nutzen.
• Es verwendet APIs zur Unterstützung der Interoperabilität.

Edge Computing unterscheidet sich von der Datenverarbeitung in großen Rechenzentren dadurch, dass

• Edge-Sites sind so nah wie möglich an die Endbenutzer. Sie verbessern die Erfahrung bei hohen Latenzzeiten und unzuverlässigen Verbindungen.
• Benötigt möglicherweise spezielle Hardware, z. B. GPU / FPGA-Plattformen für AR/VR-Funktionalität.
• Edge kann auf eine große Anzahl von Sites skaliert werden, die an verschiedenen Orten verteilt sind.
• Der Standort einer Edge-Site und die Identität der Access-Links, die sie beendet, sind signifikant. Eine Anwendung, die in der Nähe ihrer Benutzer ausgeführt werden muss, muss sich im rechten Teil der Kante befinden. Es ist üblich, dass der Anwendungsort bei Edge Computing eine Rolle spielt.
• Der gesamte Pool von Websites kann als dynamisch angesehen werden. Aufgrund ihrer physischen Trennung werden Edge-Sites in einigen Fällen miteinander und der Core mit WAN-Verbindungen verbunden sein. Edge-Sites werden dem Infrastrukturpool im Laufe der Zeit beitreten und ihn verlassen.
• Edge-Sites sind remote und potenziell unbemannt und müssen daher remote verwaltet werden. Tools müssen den intermittierenden Netzwerkzugriff auf die Site unterstützen.
• Edge unterstützt große Unterschiede in der Site-Größe und Skalierung, von der Datencenter-Skalierung bis hin zu einem einzelnen Gerät.
• Edge-Sites können Ressourcenbeschränkungen aufweisen. Das Hinzufügen von Kapazität zu einer vorhandenen Site ist aufgrund von Platz- oder Leistungsanforderungen eingeschränkt.
• Für einige Anwendungsfälle ist eine massenhafte Mandantenfähigkeit erforderlich.
• Die Isolierung von Edge-Computing von Datencenter-Clouds kann erforderlich sein, um sicherzustellen, dass sich Kompromisse in der Domäne „externe Cloud“ nicht auf Services auswirken.

Das Konzept des Edge Computing muss sowohl die Edge-Site (z. B. die Computing-, Netzwerk- und Speicherinfrastruktur) als auch die Anwendungen (Workloads), die darauf ausgeführt werden, abdecken. Es ist erwähnenswert, dass alle Anwendungen in einer Edge-Computing-Umgebung potenziell alle oder einige der Funktionen nutzen können, die von Cloud Computing, Blockspeicher, Objektspeicher, virtuellem Netzwerk, Bare-Metal-Systemen oder Containern bereitgestellt werden.

Die wesentlichen Funktionen, die Edge Computing vom Cloud Computing definieren und trennen, sind:

• die Fähigkeit, einen dynamischen Pool von mehreren potenziell weit verteilten Sites zu unterstützen,
• potenziell unzuverlässige Netzwerkverbindungen und
• Die Wahrscheinlichkeit von schwer zu lösenden Ressourcenbeschränkungen an Standorten im gesamten Netzwerk.

ANWENDUNGSFÄLLE¶

Es gibt wahrscheinlich Dutzende von Möglichkeiten, Anwendungsfälle zu charakterisieren, und dieses Papier ist zu kurz, um eine erschöpfende Liste zu liefern. Aber hier sind einige Beispiele, die helfen, das Denken zu klären und Möglichkeiten für die Zusammenarbeit aufzuzeigen.

Vier Hauptkategorien von Workload-Anforderungen, die von einer verteilten Architektur profitieren, sind Analyse, Compliance, Sicherheit und NFV.

SZENARIEN¶

Das Grundmerkmal des Edge-Computing-Paradigmas ist, dass die Infrastruktur näher am Endbenutzer liegt, dass der Umfang der Standortverteilung hoch ist und dass die Edge-Knoten über WAN-Netzwerkverbindungen verbunden sind. Die Analyse einiger Szenarien in zusätzlicher Tiefe hilft uns dabei, die aktuellen Fähigkeiten, die sich auf den Anwendungsfall beziehen, zu bewerten und Schwachstellen und Verbesserungspotenziale aufzuzeigen.

1. Einzelhandel/Finanzen/Remote-Standort „Cloud in a Box“: Edge-Computing-Infrastruktur, die eine Reihe von Anwendungen unterstützt, die auf die jeweilige Branche oder Branche zugeschnitten sind. Die Edge-Computing-Infrastruktur, die häufig von Unternehmen genutzt wird, wird letztendlich zu verteilter Infrastruktur zusammengeführt, um den Hardware-Footprint zu reduzieren, die Bereitstellung an vielen Standorten zu standardisieren, die Flexibilität von Anwendungen am Rand zu ersetzen (und die gleiche Anwendung einheitlich auszuführen) Knoten unabhängig von der Hardware), erhöhen die Ausfallsicherheit und beheben Probleme mit intermittierenden WAN-Verbindungen. Die Zwischenspeicherung von Inhalten oder die Bereitstellung von Rechen-, Speicher- und Netzwerkfunktionen für eigenständige Anwendungen sind naheliegende Anwendungen für Edge Computing in Umgebungen mit eingeschränkter Konnektivität.

2. Mobile Konnektivität: Mobile/drahtlose Netzwerke sind wahrscheinlich ein verbreitetes Umweltelement für Cloud Edge Computing, da mobile Netzwerke weiterhin durch begrenzte und nicht vorhersehbare Bandbreite gekennzeichnet sind, zumindest bis 5G allgemein verfügbar ist. Anwendungen wie Augmented Reality für Fernreparatur und Telemedizin, IoT - Geräte für die Erfassung von Versorgungs -, Wasser -, Gas -, Elektrizitäts - und Gebäudemanagement - Daten, Inventar -, Lieferketten - und Transportlösungen, Smart Cities, Smart - Road - und Remote - Security - Anwendungen werden auf Mobilfunknetz mehr oder weniger stark. Sie alle profitieren von der Fähigkeit von Edge Computing, Arbeitslasten näher an den Endbenutzer zu verlagern.

   

3. Network-as-a-Service (NaaS): Aufgrund der Notwendigkeit, eine identische Netzwerkdienstanwendungserfahrung in radikal unterschiedlichen Umgebungen zu liefern, benötigt der NaaS-Anwendungsfall sowohl eine kleine Stellfläche seiner verteilten Plattform an den Rändern als auch eine starke zentrale Management-Tools, die unzuverlässige oder eingeschränkte WAN-Netzwerkverbindungen zur Unterstützung der Dienste auf der Kante überschreiten. Die Hauptmerkmale dieses Szenarios sind: kleiner Hardware-Footprint, Verschieben (Ändern von Netzwerkverbindungen) und sich ständig ändernde Arbeitslasten, hybride Standorte von Daten und Anwendungen. Dies ist einer der Fälle, in denen eine Infrastruktur zur Unterstützung von Mikroknoten benötigt wird - kleine Dosierungen von Daten in nicht-traditionellen Paketen (nicht alle 19-Zoll-Racks in einem gekühlten Datencenter). NaaS erfordert Unterstützung für Tausende oder Zehntausende von Knoten am Rand und muss Mesh- und / oder hierarchische Architekturen sowie On-Demand-Sites unterstützen, die bei Bedarf hochgefahren werden und heruntergefahren werden, wenn sie fertig sind. APIs und GUIs müssen geändert werden, um zu reflektieren, dass eine große Anzahl von Rechenknoten unterschiedliche Positionen hat, anstatt im selben Rechenzentrum vorhanden zu sein.

   

4. Universal Customer Premises Equipment (uCPE): Dieses Szenario, das bereits heute eingesetzt wird, erfordert Unterstützung für Hardware-Footprints im Appliance-Umfang und zeichnet sich durch begrenzte Netzwerkverbindungen mit im Allgemeinen stabilen Workloads aus, die eine hohe Verfügbarkeit erfordern. Es erfordert auch eine Methode zur Unterstützung hybrider Speicherorte von Daten und Anwendungen über Hunderte oder Tausende von Knoten hinweg, und die Skalierung bestehender uCPE-Bereitstellungen wird eine neue Anforderung sein.

   Dies gilt insbesondere für NFV-Anwendungen, bei denen unterschiedliche Sites möglicherweise eine andere Gruppe von Anwendungen mit Service-Ketten erfordern oder Sites mit anderen erforderlichen Anwendungen, die noch zusammenarbeiten müssen. Netz- oder hierarchische Architekturen müssen mit lokalisierter Kapazität und der Notwendigkeit, Datenverarbeitung aufgrund von intermittierenden Netzwerkverbindungen zu speichern und weiterzuleiten, unterstützt werden. Selbstheilung und Selbstverwaltung kombiniert mit der Fähigkeit, den Knoten fern zu verwalten, sind ein Muss.

5. Satellite-fähige Kommunikation (SATCOM): Dieses Szenario zeichnet sich durch zahlreiche fähige Endgeräte aus, die oft an die entferntesten und rauen Bedingungen verteilt sind. Gleichzeitig ist es sinnvoll, diese verteilten Plattformen für Hosting-Dienste zu nutzen, insbesondere unter Berücksichtigung der extrem hohen Latenzzeiten, der begrenzten Bandbreite und der Kosten für die Kommunikation über Satellit. Konkrete Beispiele für solche Anwendungsfälle könnten Schiffe sein (von Fischerbooten zu Tankern), Flugzeuge, Bohrinseln, Bergbaubetriebe oder militärische Infrastruktur.

   

HERAUSFORDERUNGEN¶

Obwohl es weltweit bereits zahlreiche Beispiele für den Einsatz von Edge-Systemen gibt, wird eine umfassende Einführung neue Denkweisen erfordern, um neue und bereits bestehende Herausforderungen und Einschränkungen zu lösen.

Wir haben festgestellt, dass die Edge-Computing-Plattform von vornherein viel fehlertoleranter und robuster sein muss als eine herkömmliche cloudbasierte Cloud, sowohl in Bezug auf die Hardware als auch auf die Plattformdienste, die den Anwendungslebenszyklus unterstützen. Wir können nicht davon ausgehen, dass solche Edge Use Cases über die Wartungs- und Supportmöglichkeiten verfügen, die die Standard-Rechenzentrumsinfrastruktur bietet. Zero Touch Provisioning, Automatisierung und autonome Orchestrierung in allen Infrastruktur- und Plattformstacks sind in diesen Szenarien entscheidende Anforderungen.

Aber es gibt noch andere Herausforderungen, die in Betracht gezogen werden müssen.

Zum einen sollten Edge-Resource-Management-Systeme eine Reihe von High-Level-Mechanismen bereitstellen, deren Assemblierung zu einem System führt, das in der Lage ist, eine geo-verteilte IaaS-Infrastruktur basierend auf WAN-Interconnects zu betreiben und zu nutzen. Mit anderen Worten besteht die Herausforderung darin, die IaaS-Kerndienste zu überarbeiten (und bei Bedarf zu erweitern), um mit den oben genannten Randspezifikationen - Netzwerkunterbrechungen/Bandbreite, begrenzte Kapazitäten in Bezug auf Compute und Speicher, unbemannte Implementierungen usw. - fertig zu werden.

Einige vorhersehbare Bedürfnisse umfassen:

• Ein Manager für virtuelle Maschinen/Container/Bare-Metal, der für die Verwaltung des Lebenszyklus von Maschinen/Containern zuständig ist (Konfiguration, Planung, Bereitstellung, Suspend/Resume und Shutdown).
• Ein Abbild-Manager, der für Vorlagendateien zuständig ist (u.a. virtuelle Maschinen- /Container-Abbilder).
• Ein Netzwerkmanager, der für die Bereitstellung der Konnektivität zur Infrastruktur verantwortlich ist: virtuelle Netzwerke und externer Zugriff für Benutzer.
• Ein Speichermanager, der Speicherdienste für Edge-Anwendungen bereitstellt.
• Administrative Tools, die Benutzerschnittstellen für den Betrieb und die Nutzung der verteilten Infrastruktur bereitstellen.

Diese Bedürfnisse sind relativ offensichtlich und könnten wahrscheinlich durch Nutzung und Anpassung bestehender Projekte erreicht werden. Andere Anforderungen an Edge Computing sind jedoch schwieriger. Diese umfassen, sind aber nicht beschränkt auf:

• Adressierung der Speicherwartezeit über WAN-Verbindungen.
• Verstärkte Sicherheit am Rand - überwacht die physische Integrität und Anwendungsintegrität jedes Standorts und bietet die Möglichkeit, bei Bedarf selbst Korrekturmaßnahmen zu ergreifen.
• Überwachung der Ressourcennutzung über alle Knoten gleichzeitig.
• Orchestrierungs-Tools, die viele Edge-Sites und Workloads verwalten und koordinieren, was möglicherweise zu einer Peering-Kontrollebene oder „selbstorganisierenden Edge“ führt.
• Die Orchestrierung einer Föderation von Edge-Plattformen (oder Cloud-of-Clouds) muss erforscht und in die IaaS-Kerndienste eingeführt werden.
  • Automatische Edge-Commission / De-Commissioning-Operationen, einschließlich der anfänglichen Software-Bereitstellung und Upgrades der Komponenten des Ressourcenverwaltungssystems.
  • Automatisierte Daten- und Workload-Relationen - Lastenausgleich über geografisch verteilte Hardware.
• Im „Kern“ der Infrastruktur sollte eine gewisse Form der Synchronisation des Abstraktionszustands erforderlich sein, um diskontinuierliche Netzwerkverbindungen zu bewältigen.
• Neue Möglichkeiten zum Umgang mit Netzwerkpartitionierungsproblemen aufgrund eingeschränkter Konnektivität - Bewältigung von kurzen Verbindungsabbrüchen und langen Verbindungsabbrüchen gleichermaßen.
• Werkzeuge zur Verwaltung der Edge-Anwendungszyklen, einschließlich:
  • Die Definition von erweiterten Platzierungsbedingungen, um den Latenzanforderungen von Anwendungskomponenten gerecht zu werden.
  • Die Bereitstellung/Planung von Anwendungen, um Platzierungsanforderungen zu erfüllen (Erstplatzierung).
  • Daten und Workload-Relokationen nach internen/externen Ereignissen (Mobilitäts-Anwendungsfälle, Fehler, Leistungsaspekte usw.).
• Integrationsstandort-Awareness: Nicht alle Edge-Implementierungen benötigen dieselbe Anwendung im selben Moment. Standort- und Nachfragebewusstsein sind wahrscheinlich.
• Diskrete Hardware mit begrenzten Ressourcen und begrenzter Erweiterbarkeit am Remote-Standort muss berücksichtigt werden, wenn sowohl die Gesamtarchitektur auf Makroebene als auch die Verwaltungstools entworfen werden. Das Konzept, Remote-Ressourcen auf Abruf von anderen Standorten zu beziehen, entweder von Nachbarn über ein Mesh-Netzwerk oder von Kernelementen in einem hierarchischen Netzwerk, bedeutet, dass Fluktuationen in der lokalen Nachfrage ohne Ineffizienz bei Hardwarebereitstellungen erreicht werden können.