{"id":38375,"date":"2019-10-31T22:23:21","date_gmt":"2019-10-31T19:23:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/iot-tuman-i-oblaka-pogovorim-pro-tehnologii\/"},"modified":"2019-10-31T22:23:21","modified_gmt":"2019-10-31T19:23:21","slug":"iot-tuman-i-oblaka-pogovorim-pro-tehnologii","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/iot-tuman-i-oblaka-pogovorim-pro-tehnologii","title":{"rendered":"IoT, Fog und Clouds: Sprechen wir \u00fcber Technologien?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"IoT,
\n
\nDie Entwicklung von Software- und Hardware-Technologien sowie das Auftauchen neuer Kommunikationsprotokolle haben zu einer Expansion des Internets der Dinge (IoT) gef\u00fchrt. Die Anzahl der Ger\u00e4te w\u00e4chst t\u00e4glich und sie erzeugen enorme Datenmengen. Daher ist ein benutzerfreundliches Systemarchitektur erforderlich, das diese Daten verarbeiten, speichern und \u00fcbertragen kann.<\/p>\n

Derzeit werden daf\u00fcr Cloud-Dienste genutzt. Doch das immer beliebter werdende Paradigma des Fog Computing kann Cloud-L\u00f6sungen erg\u00e4nzen, indem es die IoT-Infrastruktur skaliert und optimiert. <\/i><\/a><\/noindex><\/p>\n

Clouds k\u00f6nnen die meisten Anforderungen des IoT abdecken. Zum Beispiel bieten sie Monitoring-Dienste, eine schnelle Verarbeitung beliebiger Datenmengen, die von Ger\u00e4ten erzeugt werden, sowie deren Visualisierung. Fog Computing hingegen ist effektiver bei der L\u00f6sung von Echtzeitanforderungen. Es sorgt f\u00fcr schnelle Reaktionszeiten auf Anfragen und minimale Verz\u00f6gerungen bei der Datenverarbeitung. Das hei\u00dft, Fog erg\u00e4nzt die Clouds und erweitert deren M\u00f6glichkeiten.<\/p>\n

Die entscheidende Frage ist jedoch eine andere: Wie soll all dies im Kontext des IoT interagieren? Welche Kommunikationsprotokolle sind am effektivsten f\u00fcr eine integrierte IoT-Fog-Cloud-Systemarchitektur?<\/p>\n

Trotz der scheinbaren Dominanz von HTTP gibt es in IoT-, Fog- und Cloud-Systemen eine Vielzahl anderer L\u00f6sungen. Dies liegt daran, dass IoT die Funktionalit\u00e4ten unterschiedlicher Ger\u00e4tesensoren mit Sicherheit, Kompatibilit\u00e4t und weiteren Anforderungen der Nutzer kombinieren muss.<\/p>\n

Es existiert jedoch kein einheitliches Verst\u00e4ndnis \u00fcber eine Referenzarchitektur und Kommunikationsstandards. Daher ist die Entwicklung eines neuen Protokolls oder die Anpassung bestehender Protokolle an spezifische IoT-Anforderungen eine der dringendsten Herausforderungen f\u00fcr die IT-Community.<\/p>\n

Welche Protokolle werden derzeit verwendet, und was k\u00f6nnen sie bieten? Lassen Sie uns das genauer betrachten. Doch zuerst wollen wir die Prinzipien des \u00d6kosystems diskutieren, in dem Clouds, Fog und das Internet der Dinge zusammenarbeiten.<\/p>\n

Die IoT Fog-to-Cloud (F2C) Architektur<\/h3>\n

\nSie haben sicher schon festgestellt, wie viel Aufwand in die Erforschung der Vorteile und Nutzen flie\u00dft, die mit einem rationalen und koordinierten Management von IoT, Cloud und Fog verbunden sind. Falls nicht, hier sind gleich drei Standardisierungsinitiativen: OpenFog Konsortium<\/a><\/noindex>, Edge Computing Konsortium<\/a><\/noindex> und mF2C H2020 EU-Projekt<\/a><\/noindex>. <\/p>\n

W\u00e4hrend fr\u00fcher nur zwei Ebenen betrachtet wurden, n\u00e4mlich Clouds und Endger\u00e4te, f\u00fchrt die vorgeschlagene Architektur eine neue Ebene ein \u2013 das Fog Computing. Diese Fog-Ebene kann in mehrere Unterebenen unterteilt werden, abh\u00e4ngig von den spezifischen Ressourcen oder einer Reihe von Richtlinien, die die Nutzung verschiedener Ger\u00e4te in diesen Unterebenen definieren.<\/p>\n

Wie k\u00f6nnte diese Abstraktion aussehen? Hier ist ein typisches IoT-Fog-Cloud-\u00d6kosystem. IoT-Ger\u00e4te senden Daten an leistungsf\u00e4higere Server und Recheneinheiten, um Aufgaben zu l\u00f6sen, die eine niedrige Latenz erfordern. In diesem System sind die Clouds daf\u00fcr verantwortlich, Aufgaben zu bearbeiten, die einen hohen Bedarf an Rechenressourcen oder Speicherplatz erfordern.<\/p>\n

\"IoT,
\n
\nSmartphones, Smartwatches und andere Gadgets k\u00f6nnen ebenfalls Teil des IoT sein. Allerdings verwenden solche Ger\u00e4te in der Regel propriet\u00e4re Kommunikationsprotokolle von gro\u00dfen Entwicklern. Die generierten IoT-Daten werden \u00fcber das REST HTTP-Protokoll auf die Fog-Ebene \u00fcbertragen, welches Flexibilit\u00e4t und funktionale Kompatibilit\u00e4t bei der Erstellung von RESTful-Diensten bietet. Dies ist wichtig, um die R\u00fcckw\u00e4rtskompatibilit\u00e4t mit der bestehenden Recheninfrastruktur, die auf lokalen Computern, Servern oder Server-Clustern l\u00e4uft, sicherzustellen. Lokale Ressourcen, die als \u201eFog-Knoten\u201c bezeichnet werden, filtern die empfangenen Daten und verarbeiten sie lokal oder leiten sie zur weiteren Berechnung in die Cloud weiter.<\/p>\n

Clouds unterst\u00fctzen verschiedene Kommunikationsprotokolle, darunter h\u00e4ufig AMQP und REST HTTP. Da HTTP allgemein bekannt und f\u00fcr das Internet optimiert ist, k\u00f6nnte die Frage aufkommen: \u201eSollten wir es nicht f\u00fcr die Arbeit mit IoT und Fog verwenden?\u201c. Allerdings hat dieses Protokoll Leistungsprobleme. Dar\u00fcber mehr sp\u00e4ter.<\/p>\n

Insgesamt gibt es zwei Modelle von Kommunikationsprotokollen, die f\u00fcr unser System geeignet sind: das Anforderungs-Antwort-Modell und das Publish-Subscribe-Modell. Das erste Modell ist insbesondere in der Client-Server-Architektur weit verbreitet. Der Client fordert Informationen vom Server an, der den Antrag erh\u00e4lt, verarbeitet und eine Antwort zur\u00fccksendet. Protokolle wie REST HTTP und CoAP arbeiten nach diesem Modell.<\/p>\n

Das zweite Modell entstand aus der Notwendigkeit, eine asynchrone, verteilte und schwache Verbindung zwischen Datenquellen, die Informationen generieren, und den Empf\u00e4ngern dieser Daten zu gew\u00e4hrleisten.<\/p>\n

\"IoT,
\n
\nDas Modell ber\u00fccksichtigt drei Akteure: den Publisher (Datenquelle), den Broker (Dispatcher) und den Subscriber (Empf\u00e4nger). Hier muss der Client, der als Subscriber agiert, keine Informationen vom Server anfordern. Stattdessen abonniert er bestimmte Ereignisse im System \u00fcber den Broker, der f\u00fcr die Filterung aller eingehenden Nachrichten und deren Weiterleitung zwischen Publishern und Subscribern verantwortlich ist. Wenn ein Ereignis zu einem bestimmten Thema auftritt, ver\u00f6ffentlicht der Publisher es beim Broker, der die angeforderten Daten an den Subscriber sendet.<\/p>\n

Im Wesentlichen basiert diese Architektur auf einem Ereignismodell. Dieses Interaktionsmodell ist besonders interessant f\u00fcr Anwendungen im IoT, in der Cloud und im Edge Computing, da es Skalierbarkeit erm\u00f6glicht und die Verbindung zwischen verschiedenen Ger\u00e4ten vereinfacht, eine dynamische \"Viele-zu-Viele\"-Kommunikation sowie asynchrone Interaktionen unterst\u00fctzt. Zu den bekanntesten standardisierten Messaging-Protokollen, die das \"Publish-Subscribe\"-Modell verwenden, z\u00e4hlen MQTT, AMQP und DDS.<\/p>\n

Offensichtlich bietet das \"Publish-Subscribe\"-Modell zahlreiche Vorteile:<\/p>\n