Versionshinweise zu Azure Stack Edge 2105
GILT FÜR:
Azure Stack Edge Pro – GPUAzure Stack Edge Pro 2Azure Stack Edge Pro RAzure Stack Edge Mini R
In den folgenden Versionshinweisen werden schwerwiegende ungelöste und behobene Probleme für das Release 2105 für Azure Stack Edge-Geräte beschrieben. Diese Versionshinweise gelten nur für Geräte vom Typ „Azure Stack Edge Pro – GPU“, „Azure Stack Edge Pro R“ und „Azure Stack Edge Mini R“. Funktionen und Probleme, die nur für ein bestimmtes Modell gelten, werden jeweils entsprechend gekennzeichnet.
Die Versionshinweise werden fortlaufend aktualisiert, und wenn schwerwiegende Probleme festgestellt werden, die eine Problemumgehung erfordern, werden sie hinzugefügt. Lesen Sie vor der Bereitstellung Ihres Geräts die Informationen in den Versionshinweisen sorgfältig durch.
Dieser Artikel bezieht sich auf das Release 2105 von Azure Stack Edge, das der Softwareversionsnummer 2.2.1606.3320 zugeordnet ist. Diese Software kann auf Ihr Gerät angewendet werden, wenn Sie mindestens Azure Stack Edge 2010-Software (2.1.1377.2170) ausführen.
Neuerungen
Im Release 2105 von Azure Stack Edge sind die folgenden neuen Funktionen verfügbar.
Unterstützung der VLAN-Konfiguration (Virtual Local Area Network): In diesem Release kann die VLAN-Konfiguration (Virtual Local Area Network) über eine Verbindung mit der PowerShell-Schnittstelle des Geräts geändert werden. Weitere Informationen finden Sie unter Erstellen von VLAN-Netzwerken auf dem virtuellen Switch.
Unterstützung der IP-Weiterleitung: Ab diesem Release wird die IP-Weiterleitung für Netzwerkschnittstellen unterstützt, die an virtuelle Computer (Virtual Machines, VMs) angefügt sind.
- Mithilfe der IP-Weiterleitung können virtuelle Computer Netzwerkdatenverkehr von einer IP-Adresse empfangen, die keiner der IP-Konfigurationen zugewiesen ist, die einer Netzwerkschnittstelle auf dem virtuellen Computer zugeordnet sind.
- Die IP-Weiterleitung ermöglicht virtuellen Computern auch das Senden von Netzwerkdatenverkehr mit einer anderen Quell-IP-Adresse als der, die den IP-Konfigurationen für die Netzwerkschnittstelle des virtuellen Computers zugewiesen ist.
Weitere Informationen finden Sie unter Aktivieren oder Deaktivieren der IP-Weiterleitung.
Kubernetes-Verbesserungen: In diesem Release wurden mehrere Verbesserungen im Zusammenhang mit Kubernetes vorgenommen.
Die folgenden Kubernetes-Versionsupdates sind verfügbar:
- Kubernetes-Serverversion: v1.20.2
- IoT Edge-Version: 0.1.0-beta14
- Kubernetes-Version mit Azure Arc-Aktivierung: 1.1
Kubernetes mit Azure Arc-Unterstützung bietet jetzt Unterstützung für verschiedene Clouds. Außerdem wurde die Protokollierung verbessert, und die Cmdlet-Umgebung über die PowerShell-Schnittstelle wurde geändert.
Diagnose- und Telemetriekorrekturen wurden vorgenommen.
Die proaktive Protokollsammlung wird für Computeprotokolle verbessert.
Unterstützung für Az-Cmdlets: Ab diesem Release sind die Az-Cmdlets (in der Vorschau) verfügbar, wenn eine Verbindung mit dem lokalen Azure Resource Manager des Geräts hergestellt oder VM-Workloads bereitgestellt werden. Weitere Informationen finden Sie unter Az-Cmdlets.
Aktivieren von PowerShell-Remotesitzungen über HTTP: Ab diesem Release können Sie auf der lokalen Benutzeroberfläche eine PowerShell-Remotesitzung für ein Gerät über HTTP aktivieren. Weitere Informationen finden Sie unter Aktivieren von PowerShell-Remotesitzungen über HTTP für Ihr Gerät.
Im Release 2105 behobene Probleme
In der folgenden Tabelle sind die Probleme aufgelistet, die in vorherigen Releases festgestellt und im aktuellen Release behoben wurden.
| Nein. | Funktion | Problem |
|---|---|---|
| 1. | VM | Ein Fehler bei der DHCP-Leaseverlängerung sollte nicht dazu führen, dass der Netzwerkschnittstellendatensatz entfernt wird. |
| 2. | VM | Verbesserungen der Überwachung, um Probleme mit Sperrungen bei der Bereitstellung von virtuellen Computern zu beheben. |
Bekannte Probleme im Release 2105
Die folgende Tabelle enthält eine Zusammenfassung der bekannten Probleme im Release 2105.
| Nein. | Funktion | Problem | Problemumgehung/Kommentare |
|---|---|---|---|
| 1. | Previewfunktionen | In diesem Release sind die folgenden Features als Vorschauversionen verfügbar: Lokaler Azure Resource Manager, VMs, Cloudverwaltung von VMs, Kubernetes-Cloudverwaltung, Kubernetes mit Azure Arc-Unterstützung, VPN für Azure Stack Edge Pro R und Azure Stack Edge Mini R, Multiprozessdienst (MPS) und Network Function Manager für Azure Stack Edge Pro-GPU. | Diese Funktionen werden in einem späteren Release allgemein verfügbar sein. |
| 2. | Multi-Access Edge Computing-Bereitstellungen (MEC)/Network Function Manager-Bereitstellungen (NFM) | Bei MEC-/NFM-Bereitstellungen vor dem Update 2105 kann in seltenen Fällen das Problem auftreten, dass Datenverkehr von LAN/WAN-VM-NetAdaptern verworfen wird. Auf Ihrem Azure Stack Edge-Gerät sind Port 5 und Port 6 mit der Mellanox-Netzwerkschnittstellenkarte verbunden, die beschleunigten Netzwerkbetrieb ermöglicht. Der beschleunigte Netzwerkbetrieb ermöglicht dem LAN/WAN-Datenverkehr von Port 5 und Port 6, die Hypervisorebene und den virtuellen Switch zu umgehen und den physischen Switch direkt zu erreichen. Sie können den beschleunigten Netzwerkbetrieb deaktivieren, indem Sie das Virtuelle Funktionen (VF)-Gerät auf den LAN/WAN-Netzwerkschnittstellen deaktivieren. Der ganze Netzwerkdatenverkehr von den VMs durchläuft jetzt die Hypervisorebene, die Sicherheitsüberprüfungen durchführt. Wenn Ihre Anwendung Datenverkehr mit einer beliebigen Unicast-Quell-IP-Adresse sendet (dies ist nicht die IP-Adresse für VM NetAdapter), führen die Sicherheitsüberprüfungen dazu, dass der Datenverkehr verworfen wird (da er scheinbar von beliebigen IP-Adressen stammt, die nicht im Vertrag für Virtual Networking Functions angegeben sind). |
Um dieses Problem zu umgehen, können Sie mit Update 2105 warten, bis das nächste Release herauskommt, das eine Lösung für dieses Problem enthält. Alternativ können Sie das Update 2105 auf Ihr Azure Stack Edge-Gerät anwenden und dieselben VNF erneut bereitstellen. Die nach dem Update 2105 bereitgestellten VNFs erfordern keine Korrektur. |
Bekannte Probleme aus vorherigen Releases
Die folgende Tabelle enthält eine Zusammenfassung der bereits aus früheren Releases bekannten Probleme.
| Nein. | Funktion | Problem | Problemumgehung/Kommentare |
|---|---|---|---|
| 1. | Azure Stack Edge Pro + Azure SQL | Zum Erstellen einer SQL-Datenbank ist Administratorzugriff erforderlich. | Gehen Sie anstelle der Schritte 1-2 in Erstellen der SQL-Datenbank wie folgt vor.
|
| 2. | Aktualisieren | Inkrementelle Änderungen an Blobs, die über Aktualisieren wiederhergestellt werden, sind NICHT möglich. | Bei Blobendpunkten können Teilaktualisierungen von Blobs nach dem erneuten Laden dazu führen, dass die Aktualisierungen nicht in die Cloud hochgeladen werden. Dies betrifft beispielsweise eine Sequenz folgender Aktionen:
Problemumgehung: Verwenden Sie Tools wie Robocopy, oder führen Sie reguläre Dateikopiervorgänge über Explorer oder die Befehlszeile durch, um ganze Blobs zu ersetzen. |
| 3. | Drosselung | Wenn während der Drosselung neue Schreibvorgänge auf das Gerät nicht zulässig sind, tritt für Schreibvorgänge des NFS-Clients der Fehler „Zugriff verweigert“ auf. | Der Fehler wird wie folgt angezeigt:hcsuser@ubuntu-vm:~/nfstest$ mkdir testmkdir: Verzeichnis „test“ kann nicht erstellt werden: Zugriff verweigert |
| 4. | Blob Storage-Erfassung | Wenn Sie AzCopy Version 10 für die Erfassung von Blob Storage verwenden, führen Sie AzCopy mit folgendem Argument aus: Azcopy <other arguments> --cap-mbps 2000 |
Wenn diese Grenzwerte für AzCopy nicht angegeben werden, wird möglicherweise eine große Anzahl von Anforderungen an das Gerät gesendet. Dies kann zu Problemen mit dem Dienst führen. |
| 5. | Mehrstufige Speicherkonten | Bei der Verwendung von mehrstufigen Speicherkonten gilt Folgendes:
|
|
| 6. | Verbindung mit NFS-Freigabe | Wenn mehrere Prozesse auf die gleiche Freigabe kopiert werden und das Attribut nolock nicht verwendet wird, werden beim Kopiervorgang möglicherweise Fehler angezeigt. |
Zum Kopieren von Dateien in die NFS-Freigabe muss das Attribut nolock an den mount-Befehl übergeben werden. Beispiel: C:\Users\aseuser mount -o anon \\10.1.1.211\mnt\vms Z:. |
| 7. | Kubernetes-Cluster | Wenn Sie auf Ihrem Gerät, auf dem ein Kubernetes-Cluster ausgeführt wird, ein Update anwenden, werden die virtuellen Kubernetes-Computer neu gestartet. In diesem Fall werden nur Pods, die mit angegebenen Replikaten bereitgestellt werden, nach einem Update automatisch wiederhergestellt. | Wenn Sie einzelne Pods außerhalb eines Replikationscontrollers ohne Angabe einer Replikatgruppe erstellt haben, werden diese Pods nach dem Geräteupdate nicht automatisch wiederhergestellt. Diese Pods müssen wiederhergestellt werden. Eine Replikatgruppe ersetzt Pods, die aus einem bestimmten Grund gelöscht oder beendet werden, z. B. Knotenfehler oder Aktualisierung eines unterbrochenen Knotens. Aus diesem Grund empfiehlt es sich, eine Replikatgruppe auch dann zu verwenden, wenn in der Anwendung nur ein einziger Pod erforderlich ist. |
| 8. | Kubernetes-Cluster | Kubernetes auf Azure Stack Edge Pro wird nur mit Helm v3 oder höher unterstützt. Weitere Informationen finden Sie unter Frequently asked questions: Removal of Tiller (Häufig gestellte Fragen: Entfernen von Tiller). | |
| 9. | Azure Arc-fähiges Kubernetes | In der GA-Version wird Azure Arc-aktiviertes Kubernetes von Version 0.1.18 auf 0.2.9 aktualisiert. Da das Azure Arc-aktivierte Kubernetes-Update auf dem Azure Stack Edge-Gerät nicht unterstützt wird, müssen Sie Azure Arc-aktiviertes Kubernetes neu bereitstellen. | Führen Sie folgende Schritte aus:
|
| 10. | Azure Arc-fähiges Kubernetes | Azure Arc-Bereitstellungen werden nicht unterstützt, wenn auf dem Azure Stack Edge Pro-Gerät ein Webproxy konfiguriert ist. | |
| 11. | Kubernetes | Port 31000 ist für das Kubernetes-Dashboard reserviert. Port 31001 ist für die Edgecontainerregistrierung reserviert. Entsprechend sind die IP-Adressen 172.28.0.1 und 172.28.0.10 in der Standardkonfiguration jeweils für den Kubernetes-Dienst bzw. den Core DNS-Dienst reserviert. | Reservierte IP-Adressen dürfen nicht verwendet werden. |
| 12. | Kubernetes | In Kubernetes sind derzeit keine Lastenausgleichsdienste für mehrere Protokolle zulässig, beispielsweise ein DNS-Dienst, der auf TCP sowie auf UDP lauschen soll. | Zum Umgehen dieser Einschränkung von Kubernetes mit MetalLB können für die gleiche Podauswahl zwei Dienste (einer für TCP, einer für UDP) erstellt werden. Diese Dienste verwenden denselben Freigabeschlüssel und denselben Wert spec.loadBalancerIP und nutzen so die gleiche IP-Adresse gemeinsam. IP-Adressen können auch gemeinsam genutzt werden, wenn Sie über mehr Dienste als verfügbare IP-Adressen verfügen. Weitere Informationen finden Sie unter IP Address Sharing (Freigeben von IP-Adressen). |
| 13. | Kubernetes-Cluster | Vorhandene Marketplace-Module für Azure IoT Edge können Änderungen für die Ausführung in IoT Edge auf Azure Stack Edge-Geräten erfordern. | Weitere Informationen finden Sie unter Ändern von Azure IoT Edge-Modulen vom Marketplace zum Ausführen auf Einem Azure Stack Edge-Gerät. |
| 14. | Kubernetes | Dateibasierte Bindungseinbindungen werden mit Azure IoT Edge in Kubernetes auf dem Azure Stack Edge-Gerät nicht unterstützt. | IoT Edge verwendet eine Übersetzungsebene, um ContainerCreate-Optionen in Kubernetes-Konstrukte zu übersetzen. Bei Erstellung von Binds wird das Verzeichnis hostpath zugeordnet. Daher können dateibasierte Bindungseinbindungen nicht an Pfade in IoT Edge-Containern gebunden werden. Ordnen Sie nach Möglichkeit das übergeordnete Verzeichnis zu. |
| 15. | Kubernetes | Wenn Sie eigene Zertifikate für IoT Edge verwenden und diese Ihrem Azure Stack Edge-Gerät hinzufügen möchten, nachdem die Computeressource auf dem Gerät konfiguriert wurde, werden die neuen Zertifikate nicht übernommen. | Zum Umgehen dieses Problems sollten Sie die Zertifikate hochladen, bevor Sie die Computeressource auf dem Gerät konfigurieren. Wenn die Computeressource bereits konfiguriert ist, stellen Sie eine Verbindung mit der PowerShell-Schnittstelle des Geräts her, und führen Sie IoT Edge-Befehle aus. Starten Sie die Pods iotedged und edgehub neu. |
| 16. | Zertifikate | In bestimmten Fällen kann es einige Sekunden dauern, bis der Zertifikatsstatus in der lokalen Benutzeroberfläche aktualisiert ist. | Dies kann sich in den folgenden Szenarios auf die lokale Benutzeroberfläche auswirken:
|
| 17. | IoT Edge | Über IoT Edge bereitgestellte Module können das Hostnetzwerk nicht verwenden. | |
| 18. | Compute + Kubernetes | Der NTLM-Webproxy wird nicht von Compute/Kubernetes unterstützt. | |
| 19. | Kubernetes und Updates | Bei früheren Softwareversionen, z. B. Release 2008, treten bei einem Update Probleme durch eine Racebedingung auf, die beim Update zum Fehler ClusterConnectionException führen. | Dieses Problem kann vermieden werden, indem die neueren Builds genutzt werden. Falls dieses Problem weiterhin besteht, sollten Sie erneut versuchen, das Upgrade durchzuführen. Anschließend sollte es funktionieren. |
| 20 | Internet Explorer | Wenn erweiterte Sicherheitsfunktionen aktiviert sind, können Sie möglicherweise nicht auf Seiten der lokalen Webbenutzeroberfläche zugreifen. | Deaktivieren Sie die erweiterte Sicherheit, und starten Sie den Browser neu. |
| 21. | Kubernetes-Dashboard | Der HTTPS-Endpunkt für das Kubernetes-Dashboard mit SSL-Zertifikat wird nicht unterstützt. | |
| 22. | Kubernetes | Kubernetes unterstützt für Umgebungsvariablen, die von .NET-Anwendungen verwendet werden, keine Namen mit Doppelpunkt („:“). Dies ist auch erforderlich, damit das IoT Edge-Modul für Event Grid auf Azure Stack Edge-Geräten und in anderen Anwendungen funktioniert. Weitere Informationen finden Sie in der ASP.NET Core-Dokumentation. | Ersetzen Sie „:“ durch einen doppelten Unterstrich. Weitere Informationen finden Sie unter Probleme mit Kubernetes. |
| 23. | Azure Arc und Kubernetes-Cluster | Wenn yamls für Ressourcen aus dem Git-Repository gelöscht werden, werden die entsprechenden Ressourcen standardmäßig nicht aus dem Kubernetes-Cluster entfernt. |
Um das Löschen von Ressourcen zu erlauben, wenn sie aus dem Git-Repository gelöscht werden, legen Sie in Arc OperatorParams --sync-garbage-collection fest. Weitere Informationen finden Sie unter Löschen einer Konfiguration. |
| 24. | NFS | Anwendungen, die auf Ihrem Gerät eingebundene NFS-Freigaben zum Schreiben von Daten verwenden, sollten exklusiven Schreibzugriff verwenden. Dies stellt sicher, dass die Schreibvorgänge auf dem Datenträger erfolgen. | |
| 25. | Computekonfiguration | In Netzwerkkonfigurationen, in denen Gateways, Switches oder Router auf ARP-Anforderungen (Address Resolution Protocol) für Systeme antworten, die nicht im Netzwerk vorhanden sind, tritt bei der Computekonfiguration ein Fehler auf. | |
| 26. | Compute und Kubernetes | Wenn Kubernetes als Erstes auf dem Gerät eingerichtet wird, beansprucht es alle verfügbaren GPUs. Daher ist es nicht möglich, nach dem Einrichten von Kubernetes Azure Resource Manager-VMs mit GPUs zu erstellen. | Wenn Ihr Gerät über zwei GPUs verfügt, können Sie eine VM erstellen, die die GPU verwendet, und dann Kubernetes konfigurieren. In diesem Fall verwendet Kubernetes die verbleibende verfügbare GPU. |
| 27. | Benutzerdefinierte VM-Skripterweiterung | Bei den Windows-VMs, die in einem früheren Release erstellt und auf 2103 aktualisiert wurden, ist ein Problem bekannt. Wenn Sie diesen VMs eine benutzerdefinierte Skripterweiterung hinzufügen, wird der Windows-VM-Gast-Agent (nur Version 2.7.41491.901) beim Update hängen bleiben, was zu einem Timeout bei der Erweiterungsbereitstellung führt. |
Gehen Sie wie folgt vor, um dieses Problem zu umgehen:
|
| 28. | Virtuelle Computer mit GPU | Vor diesem Release wurde der GPU-VM-Lebenszyklus nicht im Updateflow verwaltet. Daher werden GPU-VMs beim Aktualisieren auf Release 2103 nicht automatisch während des Updates angehalten. Sie müssen die GPU-VMs manuell mit einem stop-stayProvisioned-Flag anhalten, bevor Sie Ihr Gerät aktualisieren. Weitere Informationen finden Sie unter Anhalten oder Herunterfahren des virtuellen Computers.Alle GPU-VMs, die vor dem Update ausgeführt werden, werden nach dem Update gestartet. In diesen Fällen werden die Workloads, die auf den VMs ausgeführt werden, nicht ordnungsgemäß beendet. Außerdem können die VMs nach dem Update möglicherweise einen unerwünschten Status aufweisen. Alle GPU-VMs, die über stop-stayProvisioned vor dem Update angehalten werden, werden nach dem Update automatisch gestartet. Wenn Sie die GPU-VMs über das Azure-Portal anhalten, müssen Sie die VM nach dem Geräteupdate manuell starten. |
Wenn Sie GPU-VMs mit Kubernetes ausführen, halten Sie die GPU-VMs direkt vor dem Update an. Wenn die GPU-VMs angehalten werden, übernimmt Kubernetes die GPUs, die ursprünglich von VMs verwendet wurden. Je länger die GPU-VMs sich im angehaltenen Status befinden, desto höher ist die Wahrscheinlichkeit, dass Kubernetes die GPUs übernimmt. |
| 29. | Multiprozessdienst (Multi-Process Service, MPS) | Wenn die Gerätesoftware und der Kubernetes-Cluster aktualisiert werden, wird die MPS-Einstellung für die Workloads nicht beibehalten. | Aktivieren Sie den MPS erneut, und stellen Sie die Workloads erneut bereit, die MPS verwendet haben. |