Freigeben über


Grundlegendes zur Unterstützung für getrennte Geräteupdates (Vorschau)

Das MCC-Modul (Microsoft Connected Cache) für IoT Edge-Geräte aktiviert Device Update-Funktionen für nicht verbundene Geräte hinter Gateways. In einem transparenten Gatewayszenario kann mindestens ein Gerät Nachrichten über ein einziges Gatewaygerät weiterleiten, das die Verbindung zu Azure IoT Hub aufrechterhält. In diesen Fällen haben die untergeordneten Geräte möglicherweise keine Internetverbindung oder es ist ihnen nicht gestattet, Inhalte aus dem Internet herunterzuladen. Das MCC-Modul stellt Device Update for IoT Hub-Kund*innen die Funktionen eines intelligenten netzwerkinternen Cache zur Verfügung. Der Cache ermöglicht imagebasierte und paketbasierte Updates von Linux-basierten Geräten hinter einem IoT Edge-Gateway (auch als Downstream-IoT-Geräte bezeichnet). Der Cache trägt auch dazu bei, die für Updates verwendete Bandbreite zu reduzieren.

Hinweis

Diese Informationen beziehen sich auf eine Previewfunktion, die für frühe Tests und den Einsatz in einer Produktionsumgebung verfügbar ist. Dieses Feature wird vollständig unterstützt, befindet sich aber weiterhin in der aktiven Entwicklung und kann erheblich geändert werden, bis es allgemein verfügbar wird.

Wenn Sie mit IoT Edge-Gateways nicht vertraut sind, lesen Sie die Informationen unter Verwendung eines IoT Edge-Geräts als Gateway.

Was ist Microsoft Connected Cache?

Microsoft Connected Cache ist ein intelligenter, transparenter Cache für Inhalte, die für Device Update for IoT Hub veröffentlicht wurden, und kann angepasst werden, um auch Inhalte aus anderen Quellen wie Paketrepositorys zwischenzuspeichern. Microsoft Connected Cache ist ein Cold-Cache, der durch Clientanforderungen für genau die vom Übermittlungsoptimierungsclient angeforderten Dateibereiche aufgewärmt wird und keinen Inhalt vorab aussendet. Das folgende Diagramm und die Schritt-für-Schritt-Beschreibung erläutern, wie Microsoft Connected Cache innerhalb der Device Update-Infrastruktur funktioniert.

Hinweis

Dieser Ablauf geht davon aus, dass das IoT Edge-Gateway über eine Internetverbindung verfügt. Für das nachgelagerte IoT Edge-Gateway-Szenario (verschachtelte Kante) kann das Content Delivery Network (CDN) als MCC angesehen werden, das auf dem übergeordneten IoT Edge-Gateway gehostet wird.

Diagramm, das veranschaulicht, wie das Microsoft Connected Cache-Modul die Aktualisierung getrennter Geräte ermöglicht

  1. Microsoft Connected Cache wird als IoT Edge-Modul auf dem lokalen Gatewayserver bereitgestellt.

  2. Device Update for IoT Hub-Clients sind so konfiguriert, dass sie Inhalte von Microsoft Connected Cache entweder aufgrund des GatewayHostName-Attributs der Geräteverbindungszeichenfolge für IoT-Leaf-Geräte oder des parent_hostname-Satzes in config.toml für untergeordnete IoT Edge-Geräte herunterladen.

  3. Device Update for IoT Hub-Clients erhalten Downloadbefehle für Updateinhalte vom Device Update-Dienst und fordern Updateinhalte von Microsoft Connected Cache statt vom CDN an. Microsoft Connected Cache lauscht standardmäßig auf HTTP-Port 80, und der Übermittlungsoptimierungsclient stellt die Inhaltsanforderung auf Port 80, sodass das übergeordnete Element so konfiguriert werden muss, dass es auf diesem Port lauscht. Derzeit wird nur das HTTP-Protokoll unterstützt.

  4. Der Microsoft Connected Cache-Server lädt Inhalte vom CDN herunter, speist seinen lokalen Cache, der auf der Festplatte gespeichert ist, und übermittelt die Inhalte an den Geräteaktualisierungsclient.

    Hinweis

    Bei Verwendung von paketbasierten Updates wird der Microsoft Connected Cache-Server vom Administrator mit dem erforderlichen Pakethostnamen konfiguriert.

  5. Nachfolgende Anforderungen von anderen Device Update-Clients für denselben Updateinhalt kommen jetzt aus dem Cache, und Microsoft Connected Cache sendet keine Anforderungen an das CDN für denselben Inhalt.

Unterstützung des industriellen IoT (IIoT) mit übergeordneten/untergeordneten Hosting-Szenarien

IIoT-Szenarien (Industrial IoT) umfassen häufig mehrere Ebenen von IoT Edge-Gateways, wobei nur die oberste Ebene Zugriff auf das Internet hat. In diesem Szenario hostet jedes Gateway einen Microsoft Connected Cache-Dienst, der für das Anfordern von Updateinhalten vom übergeordneten Gateway konfiguriert ist.

Wenn ein untergeordnetes (oder nachgelagertes) IoT Edge-Gateway eine Anforderung für den Updateinhalt vom übergeordneten Gateway sendet, wird diese Anforderung für so viele Ebenen wie nötig wiederholt, bevor sie das oberste IoT Edge-Gateway erreicht, das einen Microsoft Connected Cache-Server mit Internetzugriff hostet. Vom mit dem Internet verbundenen Server wird der Inhalt vom CDN angefordert, woraufhin der Inhalt zurück an das untergeordnete IoT Edge-Gateway gesendet wird, das den Inhalt ursprünglich angefordert hat. Der Inhalt wird auf jeder Ebene auf dem Datenträger gespeichert.

Fordern Sie Zugriff auf die Vorschau an

Das Microsoft Connected Cache IoT Edge-Modul wird als Vorschau für Kunden veröffentlicht, die Lösungen mit Device Update for IoT Hub bereitstellen. Der Zugriff auf die Vorschau erfolgt auf Einladung. Fordern Sie den Zugriff auf die Microsoft Connected Cache-Vorschau für das Geräteupdate for IoT Hub an, und geben Sie die angeforderten Informationen an, wenn Sie Zugriff auf das Modul wünschen.

Konfiguration des Microsoft Connected Cache-Moduls

Microsoft Connected Cache wird als IoT Edge-Modul für Azure IoT Edge-Gateways bereitgestellt. So wie andere IoT Edge-Module werden Umgebungsvariablen und Containererstellungsoptionen zum Konfigurieren von MCC-Modulen verwendet. In diesem Abschnitt werden die Umgebungsvariablen und Optionen zum Erstellen von Containern definiert, die für die erfolgreiche Bereitstellung des MCC-Moduls zur Verwendung durch Device Update for IoT Hub erforderlich sind.

Es gibt keine Benennungsanforderung für das Microsoft Connected Cache-Modul, da keine anderen Modul- oder Dienstinteraktionen auf dem Namen des MCC-Moduls für die Kommunikation basieren. Außerdem ist die über- und untergeordnete Beziehung der Microsoft Connected Cache-Server von diesem Modulnamen nicht abhängig, sondern vom FQDN oder der IP-Adresse des IoT Edge-Gateways.

Modulumgebungsvariablen

Die Umgebungsvariablen des Microsoft Connected Cache-Moduls werden für die Übergabe von grundlegenden Informationen zur Modulkennung und funktionalen Moduleinstellungen an den Container verwendet.

Variablenname Wertformat Beschreibung
CUSTOMER_ID GUID der Azure-Abonnement-ID Erforderlich

Dieser Wert ist die Kunden-ID, die eine sichere Authentifizierung des Cacheknotens für Übermittlungsoptimierungsdienste bietet.
CACHE_NODE_ID GUID der Cacheknoten-ID Erforderlich

Identifiziert eindeutig den MCC-Knoten für Übermittlungsoptimierungsdienste.
CUSTOMER_KEY GUID des Kundenschlüssels Erforderlich

Dieser Wert ist der Kundenschlüssel, der eine sichere Authentifizierung des Cacheknotens für Übermittlungsoptimierungsdienste bietet.
STORAGE_N_SIZE_GB (wobei N das Cachelaufwerk ist) Integer Erforderlich

Geben Sie bis zu neun Laufwerke zum Zwischenspeichern von Inhalten und den maximalen Speicherplatz in Gigabyte an, um Inhalte auf jedem Cachelaufwerk zuzuordnen. Die Nummer des Laufwerks muss mit den Bindungswerten des Cachelaufwerks übereinstimmen, die im Wert der Containererstellungsoption „MicrosoftConnectedCacheN“ angegeben werden.

Beispiele:
STORAGE_1_SIZE_GB = 150
STORAGE_2_SIZE_GB = 50

Die Mindestgröße des Caches beträgt 10 GB.
UPSTREAM_HOST FQDN/IP Optional

Dieser Wert kann einen Upstream-MCC-Knoten angeben, der als Proxy fungiert, wenn der Connected Cache-Knoten vom Internet getrennt ist. Diese Einstellung wird zur Unterstützung des geschachtelten IoT-Szenarios verwendet.

Hinweis: MCC lauscht am HTTP-Standardport 80.
UPSTREAM_PROXY FQDN/IP:PORT Optional

Der ausgehende Internetproxy. Dieser Wert könnte auch der OT DMZ-Proxy eines ISA 95-Netzwerks sein.
CACHEABLE_CUSTOM_N_HOST HOST/IP
FQDN
Optional

Erforderlich zur Unterstützung benutzerdefinierter Paketrepositorys. Repositorys können lokal oder im Internet gehostet werden. Es gibt keine Begrenzung für die Anzahl von benutzerdefinierten Hosts, die konfiguriert werden können.

Beispiele:
Name = CACHEABLE_CUSTOM_1_HOST Value = packages.foo.com
Name = CACHEABLE_CUSTOM_2_HOST Value = packages.bar.com
CACHEABLE_CUSTOM_N_CANONICAL Alias Optional

Erforderlich zur Unterstützung benutzerdefinierter Paketrepositorys. Dieser Wert kann als Alias verwendet werden, und er wird vom Cacheserver zum Verweisen auf verschiedene DNS-Namen verwendet. Der Hostname des Repositoryinhalts kann beispielsweise „packages.foo.com“ sein, aber für verschiedene Regionen könnte es ein zusätzliches Präfix geben, das dem Hostnamen hinzugefügt wird, z. B. „westuscdn.packages.foo.com“ und „eastuscdn.packages.foo.com“. Indem Sie den kanonischen Alias festlegen, stellen Sie sicher, dass Inhalte bei Inhalten, die aus demselben Host stammen, aber unterschiedliche CDN-Quellen haben, nicht dupliziert werden. Das Format des kanonischen Werts ist nicht wichtig, muss für den Host aber eindeutig sein. Möglicherweise ist es am einfachsten, den Wert so festzulegen, dass er dem Hostwert entspricht.

Beispiele basierend auf den vorherigen benutzerdefinierten Hostbeispielen:
Name = CACHEABLE_CUSTOM_1_CANONICAL Value = foopackages
Name = CACHEABLE_CUSTOM_2_CANONICAL Value = packages.bar.com
IS_SUMMARY_PUBLIC „true“ oder „false“ Optional

Ermöglicht das Anzeigen des Zusammenfassungsberichts im lokalen Netzwerk oder im Internet. Die Verwendung eines API-Schlüssels (wird später erläutert) ist erforderlich, um den Zusammenfassungsbericht anzuzeigen, wenn der Wert auf TRUE festgelegt ist.
IS_SUMMARY_ACCESS_UNRESTRICTED „true“ oder „false“ Optional

Ermöglicht das Anzeigen von Zusammenfassungsberichten im lokalen Netzwerk oder Internet ohne Verwendung des API-Schlüssels von einem beliebigen Gerät im Netzwerk. Verwenden Sie diese Variable, wenn Sie den Zugriff auf die Anzeige von Zusammenfassungsdaten des Cacheservers über den Browser nicht sperren möchten.

Optionen zum Erstellen eines Modulcontainers

Containererstellungsoptionen bieten Kontrolle über die Einstellungen im Zusammenhang mit dem Speicher und den Ports, der bzw. die vom Microsoft Connected Cache-Modul genutzt werden.

Optionen zum Erstellen eines Beispielcontainers:

{
    "HostConfig": {
        "Binds": [
            "/microsoftConnectedCache1/:/nginx/cache1/"
        ],
        "PortBindings": {
            "8081/tcp": [
                {
                    "HostPort": "80"
                }
            ],
            "5000/tcp": [
                {
                    "HostPort": "5100"
                }
            ]
        }
    }
}

In den folgenden Abschnitten werden die erforderlichen Containererstellungsvariablen aufgeführt, mit denen das MCC-Modul bereitgestellt wird.

HostConfig

Die HostConfig-Parameter sind erforderlich, um den Containerspeicherort dem Speicherort auf dem Datenträger zuzuordnen. Bis zu neun Speicherorte können angegeben werden.

Hinweis

Die Nummer des Laufwerks muss mit den Bindungswerten des Cachelaufwerks übereinstimmen, die im Wert /MicrosoftConnectedCache*N*/:/nginx/cache*N*/ der Umgebungsvariablen STORAGE_N_SIZE_GB Wert angegeben werden.

PortBindings

Die PortBindings-Parameter ordnen Containerports den Ports auf dem Hostgerät zu.

Die erste Portbindung gibt den HTTP-Port des externen Computers an, an dem MCC für Inhaltsanforderungen lauscht. Der Standardhostport ist Port 80. Andere Ports werden zurzeit nicht unterstützt, da der ADU-Client aktuell Anforderungen an Port 80 übermittelt. TCP-Port 8081 ist der interne Containerport, an dem MCC lauscht. Er kann nicht geändert werden.

Die zweite Portbindung stellt sicher, dass der Container nicht am Hostport 5000 lauscht. Das Microsoft Connected Cache-Modul verfügt über einen .NET Core-Dienst, der von der Caching-Engine für verschiedene Funktionen verwendet wird. Zur Unterstützung von Nested Edge darf der HostPort nicht auf „5000“ festgelegt werden, weil das Registrierungsproxymodul bereits an Hostport 5000 lauscht.

Microsoft Connected Cache-Zusammenfassungsbericht

Der Zusammenfassungsbericht ist zurzeit die einzige Möglichkeit für Kunden, das Zwischenspeichern von Daten für die Microsoft Connected Cache-Instanzen anzuzeigen, die auf IoT Edge-Gateways bereitgestellt werden. Der Bericht wird in Intervallen von 15 Sekunden erstellt. Er enthält gemittelte Statistiken für diesen Zeitraum und aggregierte Statistiken für die Lebensdauer des Moduls. Die wichtigsten Statistiken, die der Bericht bereitstellt:

  • hitBytes – Die Summe der übermittelten Bytes, die direkt aus dem Cache stammen.
  • missBytes – Die Summe der übermittelten Bytes, die Microsoft Connected Cache aus dem CDN herunterladen musste, um den Cache anzuzeigen.
  • eggressBytes – Die Summe der „hitBytes“ und „missBytes“ und damit die Gesamtzahl der Bytes, die an Clients übermittelt wurden.
  • hitRatioBytes – Das Verhältnis von „hitBytes“ zu „egressBytes“. Wenn 100 % der in einem Zeitraum übermittelten „eggressBytes“ gleich den „hitBytes“ wären, lautete dieser Wert „1“.

Den Zusammenfassungsbericht finden Sie unter http://<IoT Edge gateway>:5001/summary. Ersetzen Sie <IoT Edge-Gateway> durch die IP-Adresse oder den Hostnamen des IoT Edge-Gateways, auf dem das MCC-Modul gehostet wird.

Nächste Schritte

Erfahren Sie, wie Sie Microsoft Connected Cache auf einzelnen Gateways oder geschachtelten Gateways und IIoT-Gateways implementieren.