{"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\/news\/iot-tuman-i-oblaka-pogovorim-pro-tehnologii","title":{"rendered":"IoT, Nebel und Clouds: Sprechen wir \u00fcber Technologien?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"IoT,
\n
\nDie Entwicklung der Technologien im Bereich Software und Hardware, das Auftreten neuer Kommunikationsprotokolle haben zur Erweiterung des Internet der Dinge (IoT) gef\u00fchrt. Die Anzahl der Ger\u00e4te w\u00e4chst von Tag zu Tag und sie generieren riesige Datenmengen. Daher entsteht der Bedarf nach einer benutzerfreundlichen Systemarchitektur, die in der Lage ist, diese Daten zu verarbeiten, zu speichern und zu \u00fcbertragen.<\/p>\n

Derzeit werden f\u00fcr diese Zwecke Cloud-Dienste verwendet. Die immer beliebter werdende Fog-Computing-Paradigma kann jedoch die Cloud-L\u00f6sungen erg\u00e4nzen, indem sie die IoT-Infrastruktur skalierbar und optimiert. <\/i><\/a><\/noindex><\/p>\n

Die \u201eClouds\u201c k\u00f6nnen die meisten IoT-Anfragen abdecken. Zum Beispiel bieten sie Monitoring-Dienste, die schnelle Verarbeitung beliebiger Datenmengen, die von Ger\u00e4ten generiert werden, sowie deren Visualisierung. Fog-Computing hingegen ist bei der L\u00f6sung von Echtzeitanforderungen effektiver. Es bietet eine schnelle Reaktion auf Anfragen und minimiert die Verz\u00f6gerung bei der Datenverarbeitung. Das hei\u00dft, Fog erg\u00e4nzt die \u201eClouds\u201c und erweitert deren M\u00f6glichkeiten.<\/p>\n

Die Hauptfrage ist jedoch eine andere: Wie sollte all dies im Kontext von IoT zusammenarbeiten? Welche Kommunikationsprotokolle werden bei der Arbeit in einem vereinten System IoT-Fog-Cloud am effektivsten sein?<\/p>\n

Trotz der scheinbaren Dominanz von HTTP wird in IoT-, Fog- und Cloud-Systemen eine Vielzahl anderer L\u00f6sungen verwendet. Dies erkl\u00e4rt sich daraus, dass IoT funktionale M\u00f6glichkeiten vielf\u00e4ltiger Sensorsysteme mit Sicherheit, Kompatibilit\u00e4t und anderen Anforderungen, die von Nutzern gestellt werden, kombinieren muss.<\/p>\n

Es gibt jedoch kein einheitliches Verst\u00e4ndnis \u00fcber die Referenzarchitektur und den Kommunikationsstandard. Daher ist die Schaffung eines neuen Protokolls oder die Anpassung eines bestehenden an spezifische IoT-Anforderungen eine der wichtigsten Herausforderungen f\u00fcr die IT-Community.<\/p>\n

Welche Protokolle werden derzeit verwendet und was k\u00f6nnen sie anbieten? Lassen Sie uns das kl\u00e4ren. Aber zun\u00e4chst sollten wir die Prinzipien des \u00d6kosystems besprechen, in dem Clouds, Fog und das Internet der Dinge interagieren.<\/p>\n

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

\nSie haben sicher bemerkt, wie viel M\u00fche darauf verwendet wird, die Vorteile und Nutzen eines rationalen und koordinierten Managements von IoT, Clouds und Fog zu untersuchen. Falls nicht, hier sind gleich drei Initiativen zur Standardisierung: OpenFog Consortium<\/a><\/noindex>, Edge Computing Consortium<\/a><\/noindex> und mF2C H2020 EU-Projekt<\/a><\/noindex>. <\/p>\n

Wenn zuvor nur 2 Ebenen betrachtet wurden, die Cloud und die Endger\u00e4te, f\u00fchrt die vorgeschlagene Architektur eine neue Ebene ein \u2013 die Fog-Computing. Die Fog-Ebene kann in mehrere Unterebenen unterteilt werden, abh\u00e4ngig von der Spezifikation der 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 Rechenressourcen, um Aufgaben zu l\u00f6sen, die eine geringe Latenz erfordern. In demselben System sind die Clouds daf\u00fcr verantwortlich, Aufgaben zu l\u00f6sen, die gro\u00dfe Rechenressourcen oder Speicherplatz f\u00fcr Daten erfordern.<\/p>\n

\"IoT,
\n
\nSmartphones, Smartwatches und andere Gadgets k\u00f6nnen ebenfalls Teil des IoT sein. Solche Ger\u00e4te verwenden in der Regel propriet\u00e4re Kommunikationsprotokolle von gro\u00dfen Herstellern. Die generierten IoT-Daten werden \u00fcber das REST HTTP-Protokoll an die Fog-Ebene \u00fcbertragen, welches Flexibilit\u00e4t und funktionale Kompatibilit\u00e4t bei der Erstellung von RESTful-Services gew\u00e4hrleistet. Dies ist wichtig im Hinblick auf die Notwendigkeit, die Abw\u00e4rtskompatibilit\u00e4t mit der bestehenden Computerinfrastruktur sicherzustellen, die auf lokalen Computern, Servern oder Serverclustern l\u00e4uft. Lokale Ressourcen, die als \u201eFog-Knoten\u201c bezeichnet werden, filtern die empfangenen Daten und verarbeiten sie lokal oder leiten sie zur weiteren Verarbeitung in die Cloud weiter.<\/p>\n

Clouds unterst\u00fctzen verschiedene Kommunikationsprotokolle, darunter am h\u00e4ufigsten AMQP und REST HTTP. Da HTTP allgemein bekannt ist und auf das Internet ausgelegt ist, k\u00f6nnte die Frage aufkommen: \u201eSollte man es nicht f\u00fcr die Arbeit mit IoT und Fog verwenden?\u201c. Dieses Protokoll hat jedoch Leistungsprobleme. Dazu sp\u00e4ter mehr.<\/p>\n

Insgesamt gibt es 2 Modelle von Kommunikationsprotokollen, die f\u00fcr unser System geeignet sind. Dies sind Anfrage-Antwort und Ver\u00f6ffentlichung-Abonnement. Das erste Modell ist bekannter, insbesondere in der Server-Client-Architektur. Der Client fordert Informationen vom Server an, und dieser erh\u00e4lt die Anfrage, verarbeitet sie und sendet eine Antwort zur\u00fcck. Nach diesem Modell arbeiten die Protokolle REST HTTP und CoAP.<\/p>\n

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

\"IoT,
\n
\nDas Modell sieht drei Beteiligte vor: den Publisher (Datenquelle), den Broker (Dispatcher) und den Subscriber (Empf\u00e4nger). Hier muss der Client, der als Subscriber fungiert, keine Informationen vom Server anfordern. Statt Anfragen zu senden, 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. Und der Publisher ver\u00f6ffentlicht, wenn ein Ereignis zu einem bestimmten Thema eintritt, dieses Thema beim Broker, der die Daten zum abonnierten Thema an den Subscriber sendet.<\/p>\n

Im Grunde basiert diese Architektur auf Ereignissen. Und dieses Interaktionsmodell ist f\u00fcr Anwendungen im IoT, in der Cloud und im Fog von Interesse, da es Skalierbarkeit erm\u00f6glicht und die Beziehung zwischen verschiedenen Ger\u00e4ten vereinfacht, die dynamische \"viele-zu-viele\"-Verbindung und asynchrone Kommunikation unterst\u00fctzt. Zu den bekanntesten standardisierten Messaging-Protokollen, die das \"Publish-Subscribe\"-Modell verwenden, geh\u00f6ren MQTT, AMQP und DDS.<\/p>\n

Offensichtlich hat das \"Publish-Subscribe\"-Modell viele Vorteile:<\/p>\n