Uruchamianie istniejących modułów usługi IoT Edge z urządzeń FPGA usługi Azure Stack Edge Pro na urządzeniu z procesorem GPU Usługi Azure Stack Edge Pro

Artykuł
10/26/2023

DOTYCZY: Tak dla jednostki SKU procesora GPU Pro Azure Stack Edge Pro — GPU Tak dla jednostki SKU Pro R Azure Stack Edge Pro R

Uwaga

Zdecydowanie zalecamy wdrożenie najnowszej wersji usługi IoT Edge na maszynie wirtualnej z systemem Linux. Zarządzana usługa IoT Edge w usłudze Azure Stack Edge używa starszej wersji środowiska uruchomieniowego usługi IoT Edge, która nie ma najnowszych funkcji i poprawek. Aby uzyskać instrukcje, zobacz jak wdrożyć maszynę wirtualną z systemem Ubuntu. Aby uzyskać więcej informacji na temat innych obsługiwanych dystrybucji systemu Linux, które mogą uruchamiać usługę IoT Edge, zobacz Obsługiwane systemy usługi Azure IoT Edge — aparaty kontenerów.

Ten artykuł zawiera szczegółowe informacje o zmianach wymaganych w module usługi IoT Edge opartym na platformie Docker, który działa na fpGA usługi Azure Stack Edge Pro, aby mógł działać na platformie IoT Edge opartej na platformie Kubernetes na urządzeniu GPU Usługi Azure Stack Edge Pro.

Informacje o implementacji usługi IoT Edge

Implementacja usługi IoT Edge różni się na urządzeniach FPGA usługi Azure Stack Edge Pro, a na urządzeniach z procesorem GPU Usługi Azure Stack Edge Pro. W przypadku urządzeń z procesorem GPU platforma Kubernetes jest używana jako platforma hostingowa dla usługi IoT Edge. Usługa IoT Edge na urządzeniach FPGA korzysta z platformy docker. Model aplikacji oparty na platformie Docker usługi IoT Edge jest automatycznie tłumaczony na natywny model aplikacji kubernetes. Jednak niektóre zmiany mogą być nadal potrzebne, ponieważ obsługiwany jest tylko niewielki podzbiór modelu aplikacji Kubernetes.

W przypadku migrowania obciążeń z urządzenia FPGA do urządzenia z procesorem GPU należy wprowadzić zmiany w istniejących modułach usługi IoT Edge, aby działały pomyślnie na platformie Kubernetes. Może być konieczne określenie wymagań dotyczących magazynu, sieci, użycia zasobów i serwera proxy sieci Web.

Storage

Podczas określania magazynu dla modułów usługi IoT Edge należy wziąć pod uwagę następujące informacje.

Magazyn dla kontenerów na platformie Kubernetes jest określany przy użyciu instalacji woluminów.
Wdrożenie na platformie Kubernetes nie może mieć powiązań dotyczących kojarzenia trwałych ścieżek magazynu ani hostów.
- W przypadku magazynu trwałego należy użyć z Mounts typem volume.
- W przypadku ścieżek hostów użyj typu Mounts bind.
W przypadku usługi IoT Edge na platformie Kubernetes powiązanie za pośrednictwem Mounts działa tylko dla katalogu, a nie dla pliku.

Przykład — magazyn za pośrednictwem instalacji woluminów

W przypadku usługi IoT Edge na platformie Docker powiązania ścieżki hosta są używane do mapowania udziałów na urządzeniu na ścieżki wewnątrz kontenera. Poniżej przedstawiono opcje tworzenia kontenera używane na urządzeniach FPGA:

{
  "HostConfig": 
  {
   "Binds": 
    [
     "<Host storage path for Edge local share>:<Module storage path>"
    ]
   }
}

W przypadku ścieżek hostów usługi IoT Edge na platformie Kubernetes pokazano przykład użycia Mounts z typem bind :

{
    "HostConfig": {
        "Mounts": [
            {
                "Target": "<Module storage path>",
                "Source": "<Host storage path>",
                "Type": "bind"
            }
        ]
    }
}

W przypadku urządzeń z procesorem GPU z usługą IoT Edge na platformie Kubernetes instalowanie woluminów służy do określania magazynu. Aby aprowizować magazyn przy użyciu udziałów, wartością Mounts.Source będzie nazwa udziału SMB lub NFS, który został aprowizowany na urządzeniu z procesorem GPU. To /home/input ścieżka, w której wolumin jest dostępny w kontenerze. Poniżej przedstawiono opcje tworzenia kontenera używane na urządzeniach z procesorem GPU:

{
    "HostConfig": {
        "Mounts": [
        {
            "Target": "/home/input",
            "Source": "<nfs-or-smb-share-name-here>",
            "Type": "volume"
        },
        {
            "Target": "/home/output",
            "Source": "<nfs-or-smb-share-name-here>",
            "Type": "volume"
        }]
    }
}

Sieć

Podczas określania sieci dla modułów usługi IoT Edge należy wziąć pod uwagę następujące informacje.

HostPort specyfikacja jest wymagana do uwidocznienia usługi zarówno wewnątrz, jak i na zewnątrz klastra.
- K8sExperimental opcje ograniczania narażenia usługi tylko na klaster.
Komunikacja między modułami wymaga HostPort specyfikacji i połączenia przy użyciu zamapowanego portu (a nie przy użyciu uwidocznionego portu kontenera).
Sieć hosta działa z dnsPolicy = ClusterFirstWithHostNetprogramem , z tym wszystkimi kontenerami (zwłaszcza edgeHub) nie muszą być również w sieci hosta.
Dodawanie mapowań portów dla protokołu TCP, UDP w tym samym żądaniu nie działa.

Przykład — zewnętrzny dostęp do modułów

W przypadku wszystkich modułów usługi IoT Edge określających powiązania portów adres IP jest przypisywany przy użyciu zewnętrznego zakresu adresów IP usługi Kubernetes określonego w lokalnym interfejsie użytkownika urządzenia. Nie ma żadnych zmian w opcjach tworzenia kontenera między usługą IoT Edge na platformie Docker a usługą IoT Edge na platformie Kubernetes, jak pokazano w poniższym przykładzie.

{
    "HostConfig": {
        "PortBindings": {
            "5000/tcp": [
                {
                    "HostPort": "5000"
                }
            ]
        }
    }
}

Jednak aby wykonać zapytanie dotyczące adresu IP przypisanego do modułu, możesz użyć pulpitu nawigacyjnego platformy Kubernetes zgodnie z opisem w temacie Uzyskiwanie adresu IP dla usług lub modułów.

Alternatywnie możesz nawiązać połączenie z interfejsem programu PowerShell urządzenia i użyć iotedge polecenia listy, aby wyświetlić listę wszystkich modułów uruchomionych na urządzeniu. Dane wyjściowe polecenia będą również wskazywać zewnętrzne adresy IP skojarzone z modułem.

Użycie zasobu

W przypadku konfiguracji usługi IoT Edge opartej na platformie Kubernetes na urządzeniach z procesorem GPU zasoby, takie jak przyspieszanie sprzętowe, pamięć i wymagania dotyczące procesora CPU, są określane inaczej niż na urządzeniach FPGA.

Użycie przyspieszania obliczeniowego

Aby wdrożyć moduły w fpGA, użyj opcji tworzenia kontenera, jak pokazano w następującej konfiguracji:

{
    "HostConfig": {
    "Privileged": true,
    "PortBindings": {
        "50051/tcp": [
        {
            "HostPort": "50051"
        }
        ]
    }
    },
    "k8s-experimental": {
    "resources": {
        "limits": {
        "microsoft.com/fpga_catapult": 2
        },
        "requests": {
        "microsoft.com/fpga_catapult": 2
        }
    }
    },
    "Env": [
    "WIRESERVER_ADDRESS=10.139.218.1"
    ]
}

W przypadku procesora GPU użyj specyfikacji żądań zasobów zamiast powiązań urządzeń, jak pokazano w poniższej minimalnej konfiguracji. Żądasz zasobów firmy Nvidia zamiast katapultowania i nie musisz określać elementu wireserver.

{
    "HostConfig": {
    "Privileged": true,
    "PortBindings": {
        "50051/tcp": [
        {
            "HostPort": "50051"
        }
        ]
    }
    },
    "k8s-experimental": {
    "resources": {
        "limits": {
        "nvidia.com/gpu": 2
        }    
    }
}

Użycie pamięci i procesora CPU

Aby ustawić użycie pamięci i procesora CPU, użyj limitów procesora dla modułów w k8s-experimental sekcji .

    "k8s-experimental": {
    "resources": {
        "limits": {
            "memory": "128Mi",
            "cpu": "500m",
            "nvidia.com/gpu": 2
        },
        "requests": {
            "nvidia.com/gpu": 2
        }
}

Specyfikacja pamięci i procesora CPU nie jest konieczna, ale ogólnie dobra praktyka. Jeśli requests nie zostanie określony, wartości ustawione w limitach są używane jako wymagane minimum.

Użycie pamięci udostępnionej dla modułów wymaga również innego sposobu. Można na przykład użyć trybu IPC hosta na potrzeby dostępu do pamięci współużytkowanej między usługą Live Video Analytics i rozwiązaniami wnioskowania zgodnie z opisem w artykule Wdrażanie usługi Live Video Analytics w usłudze Azure Stack Edge.

Serwer proxy sieci Web

Podczas konfigurowania internetowego serwera proxy należy wziąć pod uwagę następujące informacje:

Jeśli w sieci skonfigurowano internetowy serwer proxy, skonfiguruj następujące zmienne środowiskowe dla edgeHub wdrożenia w konfiguracji usługi IoT Edge opartej na platformie Docker na urządzeniach FPGA:

https_proxy : <proxy URL>
UpstreamProtocol : AmqpWs (chyba że internetowy serwer proxy zezwala na Amqp ruch)

W przypadku konfiguracji usługi IoT Edge opartej na platformie Kubernetes na urządzeniach z procesorem GPU należy skonfigurować tę dodatkową zmienną podczas wdrażania:

no_proxy: localhost
Serwer proxy usługi IoT Edge na platformie Kubernetes używa portu 35000 i 35001. Upewnij się, że moduł nie działa na tych portach lub może powodować konflikty portów.

Inne różnice

Strategia wdrażania: może być konieczne zmianę zachowania wdrożenia dla wszystkich aktualizacji modułu. Domyślne zachowanie modułów usługi IoT Edge to aktualizacja stopniowa. To zachowanie uniemożliwia ponowne uruchomienie zaktualizowanego modułu, jeśli moduł korzysta z zasobów, takich jak przyspieszanie sprzętowe lub porty sieciowe. To zachowanie może mieć nieoczekiwane skutki, szczególnie w przypadku obsługi trwałych woluminów na platformie Kubernetes dla urządzeń z procesorem GPU. Aby zastąpić to domyślne zachowanie, możesz określić element Recreate w k8s-experimental sekcji w module.
```
{
  "k8s-experimental": {
    "strategy": {
      "type": "Recreate"
    }
  }
}
```
Nazwy modułów: nazwy modułów powinny być zgodne z konwencjami nazewnictwa platformy Kubernetes. Zmiana nazwy modułów uruchomionych w usłudze IoT Edge przy użyciu platformy Docker może być konieczna po przeniesieniu tych modułów do usługi IoT Edge przy użyciu platformy Kubernetes. Aby uzyskać więcej informacji na temat nazewnictwa, zobacz Konwencje nazewnictwa platformy Kubernetes.
Inne opcje:
- Niektóre opcje tworzenia platformy Docker, które działały na urządzeniach FPGA, nie będą działać w środowisku Kubernetes na urządzeniach z procesorem GPU. Na przykład: , na przykład — EntryPoint.
- Zmienne środowiskowe, takie jak : należy zastąpić elementem __.
- Stan tworzenia kontenera dla zasobnika Kubernetes prowadzi do stanu wycofywania modułu w zasobie usługi IoT Hub. Chociaż zasobnik ma wiele powodów, aby był w tym stanie, typowym powodem jest ściąganie dużego obrazu kontenera przez połączenie o niskiej przepustowości sieci. Gdy zasobnik jest w tym stanie, stan modułu jest wyświetlany jako wycofywanie w usłudze IOT Hub, chociaż moduł dopiero się uruchamia.

Następne kroki

Dowiedz się więcej o sposobie konfigurowania procesora GPU do korzystania z modułu.

Udostępnij za pośrednictwem