Freigeben über

Voraussetzungen für die Bereitstellung von Mandantenarbeitslasten

In diesem Handbuch werden die Voraussetzungen für die Erstellung erläutert:

  • Virtuelle Computer (VMs) für VNF-Workloads (Virtual Network Function).
  • Nexus Kubernetes-Clusterbereitstellungen für Cloud-native Netzwerkfunktionen (CNF)-Workloads.

Diagramm des Bereitstellungsablaufs für die Arbeitslast eines Mandanten.

Netzwerkvoraussetzungen

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

  • Ermitteln Sie die Typen von Netzwerken, die Sie zur Unterstützung Ihrer Workloads benötigen:
    • Für ein L3-Netzwerk (Layer 3) ist eine VLAN- und Subnetzzuordnung erforderlich. Das Subnetz muss groß genug sein, um die IP-Zuweisung zu jedem der virtuellen Computer zu unterstützen. Die Plattform behält sich die ersten drei verwendbaren IP-Adressen für die interne Nutzung vor. Um z. B. sechs VMs zu unterstützen, lautet der minimale CIDR für Ihr Subnetz /28 (14 verwendbare Adressen – 3 reserviert = 11 verfügbar).
    • Für ein L2-Netzwerk (Layer 2) ist nur eine einzelne VLAN-Zuordnung erforderlich.
    • Für ein trunkiertes Netzwerk ist die Zuweisung mehrerer VLANs erforderlich.
  • Bestimmen Sie, wie viele Netzwerke jedes Typs Sie benötigen.
  • Ermitteln Sie die MTU-Größe jedes Ihrer Netzwerke (maximal 9.000).
  • Ermitteln Sie die BGP-Peeringinformationen für jedes Netzwerk und ob die Netzwerke miteinander kommunizieren müssen. Sie sollten Netzwerke gruppieren, die miteinander in derselben L3-Isolationsdomäne kommunizieren müssen, da jede L3-Isolationsdomäne mehrere L3-Netzwerke unterstützen kann.
  • Die Plattform bietet einen Proxy, mit dem Ihre VM andere externe Endpunkte erreichen kann. Zum Erstellen einer cloudservicesnetwork Instanz müssen die Endpunkte durch einen Proxy geleitet werden, daher muss die Liste der Endpunkte erfasst werden. 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 (Intra-Rack-Kommunikation) oder unterschiedlichen Racks (Inter-Rack-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
  • Bündelnetzwerk

Erstellen eines L2-Netzwerks

Erstellen Sie bei Bedarf ein L2-Netzwerk für Ihre Workloads. Sie können die Anweisungen für jedes erforderliche L2-Netzwerk wiederholen.

Sammeln Sie die Ressourcen-ID der L2-Isolationsdomäne, die Sie erstellt haben, 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 bei Bedarf ein L3-Netzwerk für Ihre Workloads. Wiederholen Sie die Anweisungen für jedes erforderliche L3-Netzwerk.

Sie benötigen:

  • 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 muss mit dem i-pv4-connected-prefix Wert in der L3-Isolationsdomäne übereinstimmen.
  • Der ipv6-connected-prefix Wert muss mit dem i-pv6-connected-prefix Wert übereinstimmen, der sich in der L3-Isolationsdomäne befindet.
  • Der ip-allocation-type Wert, der sein IPv4kann, IPv6oder DualStack (Standard).
  • Der vlan Wert, der mit dem in der L3-Isolationsdomäne übereinstimmen muss.
  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 trunkierten Netzwerks

Erstellen Sie bei Bedarf ein trunkiertes Netzwerk für Ihren virtuellen Computer. Wiederholen Sie die Vorgaben für jedes erforderliche Trunknetz.

Sammeln Sie die resourceId Werte der L2- und L3-Isolationsdomänen, die Sie zuvor erstellt haben, um die VLANs für dieses Netzwerk zu konfigurieren. Sie können beliebig viele L2- und L3-Isolationsdomänen einschließen.

  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 Clouddienstenetzwerks

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

Während das Clouddienste-Netzwerk 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 Clouddienste-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. Während Wildcards für die URL-Endpunkte möglicherweise praktisch erscheinen, wird sie aus Sicherheitsgründen nicht empfohlen. 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 als Endpunkt angeben .docker.io .

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 Domänennamen umfassen alphanumerische Zeichen, Bindestriche (nicht am Anfang oder Ende) und können Unterdomänen durch Punkte getrennt haben. 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 der .com obersten Ebene dient.
  • sales.contoso.com: Eine Unterdomäne von contoso.com, die als Domäne der dritten Ebene unter der domäne der .com 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 api.contoso.com, die mehrere Domänen der dritten Ebene abdeckt.

Bereitstellungen mit mehreren Speichergeräten unterstützen die Auswahl der Speicher-Appliance, die verwendet werden soll, um gemeinsam genutzten Dateisystemspeicher für containerisierte Workloads bereitzustellen. Das CSN verwaltet den freigegebenen Speicherdienst, der den freigegebenen Dateisystemspeicher ermöglicht. Sie können die Speicheranwendung nur auswählen, wenn Sie das CSN erstellen. Alle nachfolgenden Versuche, die Konfiguration zu ändern, haben keine Auswirkungen. Der Name der Speicheranwendung muss mit dem Azure Resource Manager-Namen einer Speicher-Appliance übereinstimmen, die von Ihrem Nexus-Cluster verwaltet wird. Wenn kein Name der Speicheranwendung angegeben wird oder die Konfiguration nicht mit einer Speicher-Appliance in der Nexus-Instanz übereinstimmt, verwendet Azure Operator Nexus standardmäßig die erste Speicher-Appliance.

  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 >}]}]"
    --tags "storageApplianceName": "<YourStorageApplianceName>""

Nach dem Einrichten des Cloud-Service-Netzwerks können Sie es verwenden, um eine virtuelle Maschine oder einen 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 sicherzustellen, dass das VNF-Image korrekt abgerufen werden kann, stellen Sie sicher, dass die ACR-URL auf der Egress Allow List des Cloud-Dienstnetzwerks steht, das Sie mit Ihrer virtuellen Maschine Operator Nexus verwenden werden.

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

Verwenden des Proxys, um außerhalb des virtuellen Computers zu gelangen

Nachdem Sie Ihre Operator Nexus-VM oder Ihren Operator Nexus-Kubernetes-Cluster mit dem Cloud-Services-Netzwerk erstellt haben, müssen Sie zusätzlich geeignete Umgebungsvariablen innerhalb der VM festlegen, um den Mandantenproxy zu verwenden und um außerhalb der virtuellen Maschine Zugriff zu erhalten. 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 Cloud Services-Netzwerk installiert wird.

Von Bedeutung

Bei der Verwendung eines Proxys ist es auch wichtig, die no_proxy Umgebungsvariable ordnungsgemäß 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 ordnungsgemäß festgelegt ist, können Probleme beim Zugriff auf Dienste auftreten, z. B. der Kubernetes-API-Server oder cluster-IP. Stellen Sie sicher, dass Sie die IP-Adresse oder den Domänennamen des Kubernetes-API-Servers und alle Cluster-IP-Adressen in die no_proxy Variable einschließen.

Nexus Kubernetes Clusterverfügbarkeitszone

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

Wenn Sie beim Erstellen eines Nexus-Kubernetes-Clusters keine Zone angeben, implementiert die Azure Operator Nexus-Plattform automatisch eine Standard-Antiaffinitätsregel, um die virtuelle Maschine über Racks und Bare-Metal-Knoten zu verteilen; dies ist jedoch nicht garantiert. Diese Regel zielt auch darauf ab, die Planung der Cluster-VM auf einem Knoten zu verhindern, der bereits über einen virtuellen Computer aus demselben Cluster verfügt, aber es ist ein Best-Effort-Ansatz und kann keine Garantien leisten.

Um die Liste der verfügbaren Zonen in der 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
  • Last updated on