Share via

Voraussetzungen für die Bereitstellung von Mandantenworkloads

  • Artikel

Dieser Leitfaden erläutert die Voraussetzungen für das Erstellen von:

  • Virtuelle Computer (VMs) für Workloads für virtuelle Netzwerkfunktionen (Virtual Network Function, VNF).
  • Bereitstellungen von Nexus Kubernetes-Clustern für Workloads für cloudnative Netzwerkfunktionen (Cloud-Native Network Function, CNF).

Diagramm des Bereitstellungsflows einer Mandantenworkload.

Netzwerkvoraussetzungen

Sie müssen basierend auf Ihren Workloadanforderungen verschiedene Netzwerke erstellen. Die folgende Liste der Überlegungen ist nicht erschöpfend. Wenden Sie sich an die entsprechenden Supportteams, um Hilfe zu erhalten.

  • Bestimmen Sie die Netzwerktypen, die Sie zur Unterstützung Ihrer Workloads benötigen:
    • Ein Layer 3 (L3)-Netzwerk erfordert eine VLAN- und Subnetzzuweisung. Das Subnetz muss groß genug sein, um die IP-Zuweisung für jede der VMs zu unterstützen. Die Plattform reserviert die ersten drei verwendbaren IP-Adressen für den internen Gebrauch. Wenn Sie beispielsweise sechs VMs unterstützen möchten, ist die minimale CIDR-Größe für Ihr Subnetz /28 (14 verwendbare Adressen – 3 reservierte Adressen = 11 Adressen verfügbar).
    • Ein Layer 2 (L2)-Netzwerk erfordert nur eine einzelne VLAN-Zuweisung.
    • Ein gebündeltes Netzwerk erfordert die Zuweisung mehrerer VLANs.
  • Bestimmen Sie, wie viele Netzwerke jedes Typs Sie benötigen.
  • Bestimmen Sie die MTU-Größe jedes Ihrer Netzwerke (maximal 9000).
  • Ermitteln Sie die BGP-Peeringinformationen für jedes Netzwerk und, ob die Netzwerke miteinander kommunizieren müssen. Sie sollten Netzwerke, die miteinander kommunizieren müssen, in derselben L3-Isolationsdomäne gruppieren, da jede L3-Isolationsdomäne mehrere L3-Netzwerke unterstützen kann.
  • Die Plattform stellt einen Proxy bereit, damit Ihre VM andere externe Endpunkte erreichen kann. Zum Erstellen einer cloudservicesnetwork-Instanz müssen die Endpunkte als Proxy erstellt werden, sammeln Sie also die Liste der Endpunkte. Sie können die Liste der Endpunkte nach der Netzwerkerstellung ändern.

Erstellen von Isolationsdomänen

Die Isolationsdomänen ermöglichen die Kommunikation zwischen Workloads, die in demselben Rack (rackinterne Kommunikation) oder in unterschiedlichen Racks (rackübergreifende Kommunikation) gehostet werden. Weitere Details zum Erstellen von Isolationsdomänen finden Sie hier.

Erstellen von Netzwerken für Mandanten-Workloads

In den folgenden Abschnitten wird beschrieben, wie Sie diese Netzwerke erstellen:

  • Layer-2-Netzwerk
  • Layer-3-Netzwerk
  • Trunknetzwerk

Erstellen eines L2-Netzwerks

Erstellen Sie für Ihre Workloads ein L2-Netzwerk falls notwendig. Sie können diese Anweisungen für jedes erforderliche L2-Netzwerk wiederholen.

Erfassen Sie die Ressourcen-ID der von Ihnen erstellten L2-Isolationsdomäne, um das VLAN für dieses Netzwerk zu konfigurieren.

  az networkcloud l2network create --name "<YourL2NetworkName>" \
    --resource-group "<YourResourceGroupName>" \
    --subscription "<YourSubscription>" \
    --extended-location name="<ClusterCustomLocationId>" type="CustomLocation" \
    --location "<ClusterAzureRegion>" \
    --l2-isolation-domain-id "<YourL2IsolationDomainId>"

Erstellen eines L3-Netzwerks

Erstellen Sie für Ihre Workloads ein L3-Netzwerk falls notwendig. Wiederholen Sie die Anweisungen für jedes erforderliche L3-Netzwerk.

Erforderlich:

  • Der resourceID-Wert der L3-Isolationsdomäne, die Sie erstellt haben, um das VLAN für dieses Netzwerk zu konfigurieren.
  • Der ipv4-connected-prefix-Wert, der mit dem i-pv4-connected-prefix-Wert übereinstimmen muss, der sich in der L3-Isolationsdomäne befindet.
  • Der ipv6-connected-prefix-Wert, der mit dem i-pv6-connected-prefix-Wert übereinstimmen muss, der sich in der L3-Isolationsdomäne befindet.
  • Der ip-allocation-type-Wert, der IPv4, IPv6 oder DualStack (Standard) sein kann.
  • Der vlan-Wert, der mit dem übereinstimmen muss, was sich in der L3-Isolationsdomäne befindet.
  az networkcloud l3network create --name "<YourL3NetworkName>" \
    --resource-group "<YourResourceGroupName>" \
    --subscription "<YourSubscription>" \
    --extended-location name="<ClusterCustomLocationId>" type="CustomLocation" \
    --location "<ClusterAzureRegion>" \
    --ip-allocation-type "<YourNetworkIpAllocation>" \
    --ipv4-connected-prefix "<YourNetworkIpv4Prefix>" \
    --ipv6-connected-prefix "<YourNetworkIpv6Prefix>" \
    --l3-isolation-domain-id "<YourL3IsolationDomainId>" \
    --vlan <YourNetworkVlan>

Erstellen eines Trunknetzwerks

Erstellen Sie ein Trunknetzwerk, wenn nötig, für Ihre VM. Wiederholen Sie die Anweisungen für jedes erforderliche gebündelte Netzwerk.

Erfassen Sie die resourceId-Werte der zuvor von Ihnen erstellten L2- und L3-Isolationsdomänen, um die VLANs für dieses Netzwerk zu konfigurieren. Sie können so viele L2- und L3-Isolationsdomänen einschließen wie notwendig.

  az networkcloud trunkednetwork create --name "<YourTrunkedNetworkName>" \
    --resource-group "<YourResourceGroupName>" \
    --subscription "<YourSubscription>" \
    --extended-location name="<ClusterCustomLocationId>" type="CustomLocation" \
    --location "<ClusterAzureRegion>" \
    --interface-name "<YourNetworkInterfaceName>" \
    --isolation-domain-ids \
      "<YourL3IsolationDomainId1>" \
      "<YourL3IsolationDomainId2>" \
      "<YourL2IsolationDomainId1>" \
      "<YourL2IsolationDomainId2>" \
      "<YourL3IsolationDomainId3>" \
    --vlans <YourVlanList>

Erstellen eines Clouddienstnetzwerks

Um einen virtuellen Operator Nexus-Computer (VM) oder einen Operator Nexus Kubernetes-Cluster zu erstellen, müssen Sie über ein Clouddienstnetzwerk verfügen. Ohne dieses Netzwerk können Sie keinen virtuellen Computer oder Cluster erstellen.

Während das Clouddienstnetzwerk automatisch Zugriff auf wichtige Plattformendpunkte ermöglicht, müssen Sie andere hinzufügen, z. B. docker.io, wenn Ihre Anwendung sie benötigt. Das Konfigurieren des Clouddienst-Netzwerkproxys ist ein wichtiger Schritt bei der Sicherstellung einer erfolgreichen Verbindung zu Ihren gewünschten Endpunkten. Um dies zu erreichen, können Sie die Ausgangsendpunkte während der ersten Erstellung oder als Update mithilfe des --additional-egress-endpoints-Parameters zum Netzwerk der Clouddienste hinzufügen. Wildcards für die URL-Endpunkte mögen zwar praktisch erscheinen, sind aber aus Sicherheitsgründen nicht zu empfehlen. Wenn Sie z. B. den Proxy so konfigurieren möchten, dass Bildabzug aus einem beliebigen Repository, das aus docker.io gehostet wird, zugelassen wird, können Sie .docker.io als Endpunkt angeben.

Die Endpunkte für den Ausgang müssen die in RFC 1034, RFC 1035 und RFC 1123 beschriebenen Domänennamenstrukturen und Hostnamenspezifikationen erfüllen. Gültige Domainnamen enthalten alphanumerische Zeichen, Bindestriche (nicht am Anfang oder Ende) und können durch Punkte getrennte Unterdomänen enthalten. Die Endpunkte können ein einzelner FQDN oder eine Unterdomäne (Domänenpräfix mit einem .) sein. Im Folgenden sind einige Beispiele aufgeführt, um kompatible Benennungskonventionen für Domänen und Hostnamen zu veranschaulichen.

  • contoso.com: Die Basisdomäne, die als Domäne der zweiten Ebene unter der Domäne „.com“ der obersten Ebene dient.
  • sales.contoso.com: Eine Unterdomäne von contoso.com, die als Domäne der dritten Ebene unter der Domäne „.com“ der obersten Ebene dient.
  • web-server-1.contoso.com: Ein Hostname für einen bestimmten Webserver, wobei Bindestriche verwendet werden, um die Wörter und die Zahl zu trennen.
  • api.v1.contoso.com: Integriert zwei Unterdomänen (v1 und api) über der Basisdomäne contoso.com.
  • .api.contoso.com: Ein Platzhalter für jede Unterdomäne unter api.contoso.com, die mehrere Domänen der dritten Ebene abdeckt.
  az networkcloud cloudservicesnetwork create --name "<YourCloudServicesNetworkName>" \
    --resource-group "<YourResourceGroupName >" \
    --subscription "<YourSubscription>" \
    --extended-location name="<ClusterCustomLocationId >" type="CustomLocation" \
    --location "<ClusterAzureRegion>" \
    --additional-egress-endpoints "[{\"category\":\"<YourCategory >\",\"endpoints\":[{\"<domainName1 >\":\"< endpoint1 >\",\"port\":<portnumber1 >}]}]"

Nach dem Einrichten des Clouddienstnetzwerks können Sie es verwenden, um einen virtuellen Computer oder Cluster zu erstellen, der eine Verbindung mit den von Ihnen angegebenen Endpunkten herstellen kann. Denken Sie daran, dass der Proxy nur mit HTTPS funktioniert.

Hinweis

Um zu gewährleisten, dass das VNF-Image korrekt abgerufen werden kann, stellen Sie sicher, dass sich die ACR-URL in der Zulassungsliste des Clouddienste-Netzwerks befindet, das Sie mit Ihrer Operator Nexus-VM verwenden werden.

Wenn Ihr ACR dedizierte Datenendpunkte aktiviert hat, müssen Sie außerdem alle neuen Datenendpunkte der Zulassungsliste für ausgehende Daten hinzufügen. Um alle möglichen Endpunkte für Ihr ACR zu finden, befolgen Sie die Anweisung hier.

Verwendung eines Proxys für den Zugriff auf etwas außerhalb der virtuellen Maschine

Nachdem Sie Ihren Operator Nexus VM oder Operator Nexus Kubernetes-Cluster mit diesem Clouddienstnetzwerk erstellt haben, müssen Sie zusätzlich geeignete Umgebungsvariablen innerhalb der VM festlegen, um Mandantenproxy zu verwenden und außerhalb des virtuellen Computers zu erreichen. Dieser Mandantenproxy ist nützlich, wenn Sie auf Ressourcen außerhalb des virtuellen Computers zugreifen müssen, z. B. das Verwalten von Paketen oder die Installation von Software.

Um den Proxy zu verwenden, müssen Sie die folgenden Umgebungsvariablen festlegen:

export HTTPS_PROXY=http://169.254.0.11:3128
export https_proxy=http://169.254.0.11:3128

Nach dem Festlegen der Proxyumgebungsvariablen kann Ihr virtueller Computer die konfigurierten Ausgangsendpunkte erreichen.

Hinweis

HTTP wird aufgrund von Sicherheitsgründen nicht unterstützt, wenn der Proxy für den Zugriff auf Ressourcen außerhalb des virtuellen Computers verwendet wird. Es ist erforderlich, HTTPS für die sichere Kommunikation zu verwenden, wenn Pakete verwaltet oder Software auf dem Operator Nexus VM oder Operator Nexus Kubernetes-Cluster mit diesem Clouddienstnetzwerk installiert wird.

Wichtig

Bei Verwendung eines Proxys ist es auch wichtig, die Umgebungsvariable no_proxy richtig festzulegen. Diese Variable kann verwendet werden, um Domänen oder IP-Adressen anzugeben, auf die nicht über den Proxy zugegriffen werden soll. Wenn dies nicht richtig festgelegt ist, kann dies Probleme beim Zugriff auf Dienste wie den Kubernetes-API-Server oder die Cluster-IP-Adresse verursachen. Stellen Sie sicher, dass Sie die IP-Adresse oder den Domänennamen des Kubernetes-API-Servers und alle IP-Adressen des Clusters in die Variable no_proxy einschließen.

Verfügbarkeitszone des Nexus Kubernetes-Clusters

Wenn Sie einen Nexus Kubernetes-Cluster erstellen, können Sie den Cluster auf bestimmte Racks planen oder ihn auf mehrere Racks verteilen. Diese Technik kann die Ressourcenverwendung und Fehlertoleranz verbessern.

Wenn Sie beim Erstellen eines Nexus Kubernetes-Clusters keine Zone angeben, implementiert die Azure Operator Nexus-Plattform automatisch eine standardmäßige Anti-Affinitätsregel, um den virtuellen Computer über Racks und Bare-Metal-Knoten zu verteilen und ist nicht garantiert. Diese Regel soll auch verhindern, dass die Cluster-VM auf einem Knoten geplant wird, auf dem sich bereits eine VM aus demselben Cluster befindet, aber es ist ein Best-Effort-Ansatz und kann keine Garantien geben.

Um die Liste der verfügbaren Zonen in der angegebenen Azure Operator Nexus-Instanz abzurufen, können Sie den folgenden Befehl verwenden:

    az networkcloud cluster show \
      --resource-group <Azure Operator Nexus on-premises cluster resource group> \
      --name <Azure Operator Nexus on-premises cluster name> \
      --query computeRackDefinitions[*].availabilityZone