IP-Adressen für Arbeitslasten bereitstellen

Erstellen Sie zusätzliche Subnetze in der internen VPC (Virtual Private Cloud) oder der Standard-VPC Ihrer Organisation, um die Anforderungen an Ihr internes Netzwerk zu erfüllen. Fügen Sie beispielsweise VPC-Subnetze hinzu, damit Ihre internen Arbeitslasten wie VMs und Container genügend IP-Adressen haben.

Auf dieser Seite werden verschiedene Aufgaben beschrieben, die nicht in der angegebenen Reihenfolge ausgeführt werden müssen:

• Zonales Zweig-Subnetz für Arbeitslasten erstellen: Diese Aufgabe ist nützlich, um die vorhandenen internen IP-Adressen Ihrer Zone weiter zu organisieren oder Arbeitslasten zuzuweisen.
• Blatt-Subnetz für eine einzelne Arbeitslast erstellen: Diese Aufgabe ist nützlich, wenn Sie eine neue Arbeitslast haben, für die noch keine IP-Adresse verwendet wird.
• Zonales Subnetz aus globalem IP-Adressbereich zuweisen: Diese Aufgabe ist nützlich, wenn in Ihrer Zone nicht mehr genügend interner IP-Adressraum vorhanden ist.
• Globales Stamm-Subnetz ohne Zonen-Zuweisung aufteilen: Diese Aufgabe ist nützlich, um die internen IP-Adressen auf dem globalen API-Server weiter zu organisieren, bevor sie einer Zone zugewiesen werden.
• Neues globales Subnetz für den Netzwerk-Root-Bereich hinzufügen: Diese Aufgabe ist nützlich, wenn Ihre Standard-VPC nicht mehr genügend globalen internen IP-Adressraum hat, um ihn Ihren Zonen zuzuweisen.

Eine Übersicht über Subnetze und ihre Konzepte, bevor Sie die Aufgaben auf dieser Seite ausführen, finden Sie unter Subnetze und IP-Adressen.

Dieses Dokument richtet sich an Plattformadministratoren und Anwendungsoperatoren, die für die Verwaltung des Netzwerkverkehrs für ihre Organisation verantwortlich sind. Weitere Informationen finden Sie unter Dokumentation zu Zielgruppen für GDC mit Air Gap.

Hinweise

Bitten Sie Ihren Organisations-IAM-Administrator, Ihnen die IAM-Rolle „Subnet Org Admin“ (subnet-org-admin) zuzuweisen, um die Berechtigung zum Erstellen von Subnetzen zu erhalten. Diese Rolle ist nicht an einen Namespace gebunden.

Zonales Zweigsubnetz für Arbeitslasten erstellen

Wenn Sie IP-Adressen in Ihrer zonenbasierten Standard-VPC weiter unterteilen möchten, können Sie ein zonenbasiertes internes Subnetz aus dem vorhandenen zonenbasierten Stamm-Subnetz der Zone erstellen. Sie müssen diesen Subnetztyp im Namespace platform erstellen.

Wenn im übergeordneten zonalen Stamm-Subnetz nicht genügend IP-Adressen verfügbar sind, weisen Sie ein weiteres zonales Subnetz aus dem globalen IP-Adressbereich zu, bevor Sie fortfahren.

• Erstellen Sie in einem Terminalfenster das neue zonale Subnetz auf dem Management API-Server:

  kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG apply -f - <<EOF
  apiVersion: ipam.gdc.goog/v1
  kind: Subnet
  metadata:
    labels:
      ipam.gdc.goog/vpc: default-vpc
    name: SUBNET_NAME
    namespace: platform
  spec:
    ipv4Request:
      prefixLength: CIDR_PREFIX_LENGTH
    networkSpec:
      enableGateway: true
      enableVLANID: false
    parentReference:
      name: PARENT_SUBNET_NAME
      namespace: platform
    type: Branch
  EOF
  

  Ersetzen Sie Folgendes:

  • MANAGEMENT_API_SERVER_KUBECONFIG: der Pfad zur kubeconfig-Datei Ihres Management-API-Servers. Weitere Informationen finden Sie unter Zonale Management-API-Serverressourcen.

  • SUBNET_NAME: der Name Ihres neuen Netzwerk-Subnetzes.

  • CIDR_PREFIX_LENGTH: die Präfixlänge für Ihr neues Subnetz, z. B. 27. In diesem Feld wird dynamisch der nächste verfügbare IP-Adressbereich dieser Größe aus dem übergeordneten Subnetz zugewiesen. Verwenden Sie das Feld prefixLength, wenn Sie sich nur für die Größe des Subnetzes und nicht für den spezifischen IP-Adressbereich interessieren.

    So weisen Sie stattdessen einen bestimmten IP-Adressbereich zu:

    1. Entfernen Sie die Zeile prefixLength: CIDR_PREFIX_LENGTH.
    2. Fügen Sie stattdessen eine cidr: "YOUR_CIDR_BLOCK"-Zeile ein, z. B. cidr: "10.0.10.0/27".

    Verwenden Sie das Feld cidr, wenn Sie einen strengen IP-Plan einhalten und einen genauen, vorhersehbaren IP-Adressbereich zuweisen müssen. Dieser Bereich muss ein gültiges und verfügbares Subnetz innerhalb des übergeordneten Subnetzes sein.

  • PARENT_SUBNET_NAME: der Name des übergeordneten Subnetzes, z. B. default-vpc-zone0-cidr. Das übergeordnete Subnetz ist in der Regel ein zonales Stamm-Subnetz in der Standard-VPC.

  Weitere Informationen finden Sie in der API-Referenzdokumentation zur Ressource Subnet.

  Sie können Ihre zonalen Subnetze weiter unterteilen oder ein Leaf-Subnetz erstellen, um einer internen Arbeitslast direkt eine einzelne IP-Adresse zuzuweisen.

Blattsubnetz für einen einzelnen Arbeitslast erstellen

Wenn Sie eine einzelne IP-Adresse für Ihre Arbeitslast zuweisen möchten, müssen Sie ein Leaf-Subnetz erstellen. Dieses untergeordnete Subnetz muss den Feldwert type: Leaf haben und sich im selben Projekt-Namespace wie Ihre Arbeitslastressource, z. B. eine VM oder ein Container, befinden.

Ihr Leaf-Subnetz muss mit dem prefixLength-Wert 32 konfiguriert werden, da nur eine einzelne IP-Adresse zugewiesen werden soll. Der Wert parentReference verweist auf ein zuvor zugewiesenes Subnetz, z. B. das übergeordnete zonale Subnetz, das Sie in Zonales Branch-Subnetz für Arbeitslasten erstellen erstellt haben.

• Erstellen Sie in einem Terminalfenster das untergeordnete Subnetz auf dem Management-API-Server:

  kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG apply -f - <<EOF
  apiVersion: ipam.gdc.goog/v1
  kind: Subnet
  metadata:
    labels:
      ipam.gdc.goog/vpc: default-vpc
    name: SUBNET_NAME
    namespace: PROJECT_NAMESPACE
  spec:
    ipv4Request:
      prefixLength: 32
    parentReference:
      name: PARENT_SUBNET
      namespace: PARENT_NAMESPACE
    type: Leaf
  EOF
  

  Ersetzen Sie Folgendes:

  • MANAGEMENT_API_SERVER_KUBECONFIG: der Pfad zur kubeconfig-Datei Ihres Management-API-Servers. Weitere Informationen finden Sie unter Zonale Management-API-Serverressourcen.
  • SUBNET_NAME: Der Name für das untergeordnete Subnetz.
  • PROJECT_NAMESPACE: der Projekt-Namespace, der Ihrem Projekt entspricht, in dem sich Ihre Arbeitslasten befinden.
  • PARENT_SUBNET: der Name des übergeordneten Subnetzes, aus dem dieses untergeordnete Subnetz seine IP-Adresse bezieht.
  • PARENT_NAMESPACE: der Namespace PROJECT_NAMESPACE oder platform.

Ihre individuelle IP-Adresse kann jetzt von Ihren internen Arbeitslasten wie VMs und Containern verwendet werden. Weitere Informationen zum Konfigurieren der IP-Adresse für Ihre Arbeitslasten finden Sie unter VM mit statischer oder dynamischer IP-Adresse erstellen oder Internen Load-Balancer für Containerarbeitslasten konfigurieren.

Zonales Subnetz aus globalem IP-Adressbereich zuweisen

Wenn in Ihrer Zone nicht genügend IP-Adressen für Ihre Arbeitslasten aus dem vorhandenen IP-Adressbereich des zonalen Stamm-Subnetzes verfügbar sind, können Sie zusätzliche IP-Adressen aus dem globalen IP-Adress-Stammbereich zuweisen.

Führen Sie die folgenden Schritte für das Standard-VPC-Netzwerk im Namespace platform aus, um ein zonales Subnetz aus dem globalen IP-Adressbereich zuzuweisen:

1. Beschreiben Sie in einem Terminalfenster alle Stamm-Subnetze der Standard-VPC und prüfen Sie die verfügbaren CIDR-Blöcke:

   kubectl --kubeconfig GLOBAL_API_SERVER_KUBECONFIG describe subnets --namespace platform \
       -l ipam.gdc.goog/vpc=default-vpc,ipam.gdc.goog/usage=network-root-range
   

   Ersetzen Sie GLOBAL_API_SERVER_KUBECONFIG durch den Pfad zur kubeconfig-Datei des globalen API-Servers. Weitere Informationen finden Sie unter Globale API-Serverressourcen. Die Labels sind konstant und müssen gleich bleiben.

   Die Ausgabe sieht etwa so aus:

   Name:         default-vpc-root-cidr
   Namespace:    platform
   Labels:       ipam.gdc.goog/allocation-preference=default
                 ipam.gdc.goog/subnet-group=default-vpc-root-group
                 ipam.gdc.goog/usage=network-root-range
                 ipam.gdc.goog/vpc=default-vpc
   Annotations:  <none>
   API Version:  ipam.global.gdc.goog/v1
   Kind:         Subnet
   Metadata:
     Creation Timestamp:  2025-06-18T23:05:38Z
     Finalizers:
       global-subnet-finalizer
     Generation:        1
     Resource Version:  439434
     UID:               5ed1c51a-b5ee-473e-a185-8e065a87ae8f
   Spec:
     ipv4Request:
       Cidr:                10.252.0.0/14
     Propagation Strategy:  None
     Type:                  Root
   Status:
     Children Refs:
       Name:       default-vpc-zone1-root-cidr
       Namespace:  platform
       Type:       SingleSubnet
     Conditions:
       Last Transition Time:  2025-06-18T23:05:38Z
       Message:               IP allocation finished successfully
       Observed Generation:   1
       Reason:                AllocationSucceeded
       Status:                True
       Type:                  Ready
     ipv4Allocation:
       Available CIDRs:
         10.254.0.0/15
         10.253.0.0/16
       Cidr:  10.252.0.0/14
   Events:    <none>
   

   Notieren Sie sich die Status.ipv4Allocation.Available CIDRs-Werte. Diese Werte sind die verfügbaren CIDR-Blöcke, auf die im nächsten Schritt verwiesen wird. In der vorherigen Ausgabe sind die CIDR-Bereiche 10.254.0.0/15 und 10.253.0.0/16 verfügbar. In der Ausgabe werden möglicherweise mehrere Subnetze angezeigt. Notieren Sie sich alle verfügbaren CIDR-Blöcke und ihre Quellsubnetze.

2. Vergleichen Sie den größten verfügbaren CIDR-Block aus dem vorherigen Schritt mit der Größe des für Ihre Zone erforderlichen CIDR-Blocks. Wenn der größte verfügbare CIDR-Block nicht groß genug ist, um Ihr neues Subnetz zuzuweisen, fügen Sie ein neues globales Subnetz für den Netzwerk-Root-Bereich hinzu, bevor Sie fortfahren. Notieren Sie sich das übergeordnete Subnetz, aus dem Sie den CIDR-Block für Ihr neues Subnetz beziehen möchten.

   Wenn Sie beispielsweise einen /13-CIDR-Block benötigen, die verfügbaren CIDRs aber nur /15 und /16 enthalten, müssen Sie einen neuen globalen Subnetz-Netzwerkstammbereich hinzufügen. Wenn Sie ein /15-Subnetz benötigen, können Sie ein neues zonales Subnetz aus dem vorhandenen /15-CIDR-Block zuweisen.

3. Erstellen Sie das neue Subnetz auf dem globalen API-Server:

   kubectl --kubeconfig GLOBAL_API_SERVER_KUBECONFIG apply -f - <<EOF
   apiVersion: ipam.global.gdc.goog/v1
   kind: Subnet
   metadata:
     labels:
       ipam.gdc.goog/vpc: default-vpc
       ipam.gdc.goog/usage: zone-network-root-range
     name: SUBNET_NAME
     namespace: platform
   spec:
     ipv4Request:
       prefixLength: CIDR_PREFIX_LENGTH
     zone: ZONE_NAME
     propagationStrategy: SingleZone
     type: Branch
     parentReference:
       name: PARENT_SUBNET_NAME
       namespace: ORG_NAME
   EOF
   

   Ersetzen Sie Folgendes:

   • GLOBAL_API_SERVER_KUBECONFIG: der Pfad zur kubeconfig-Datei des globalen API-Servers. Weitere Informationen finden Sie unter Globale API-Serverressourcen.
   • SUBNET_NAME: der Name des neuen Subnetzes.
   • CIDR_PREFIX_LENGTH: Die CIDR-Präfixlänge des neuen Subnetzes, das dynamisch zugewiesen wird, z. B. 20. Wenn Sie den CIDR-Block statisch festlegen möchten, ersetzen Sie das Feld prefixLength durch das Feld cidr und legen Sie dann den CIDR-Block fest, z. B. 10.0.10.0/27.
   • ZONE_NAME: die Zone, für die das Subnetz zugewiesen werden soll, z. B. zone1.
   • PARENT_SUBNET_NAME: der Name des übergeordneten Subnetzes, z. B. default-vpc-root-cidr, oder des neuen globalen Subnetzes für den Netzwerk-Root-Bereich, das Sie erstellt haben.
   • ORG_NAME: der Name der Organisation.

   Weitere Informationen finden Sie in der API-Referenzdokumentation zur Ressource Subnet.

4. Prüfen Sie, ob das Subnetz bereit und auf dem globalen API-Server verfügbar ist. Dazu muss der Status Ready vom Typ true sein:

   kubectl --kubeconfig GLOBAL_API_SERVER_KUBECONFIG get subnet --namespace platform \
       SUBNET_NAME --output jsonpath='{.status.conditions[?(@.type=="Ready")].status}'
   

   Die Ausgabe sieht etwa so aus:

   status:
     conditions:
     - lastTransitionTime: "2025-06-06T07:28:48Z"
       message: IP allocation finished successfully
       observedGeneration: 1
       reason: AllocationSucceeded
       status: "True"
       type: Ready
   

5. Prüfen Sie, ob das zonale Subnetz auf dem zonalen Verwaltungs-API-Server erstellt wurde und sein Status vom Typ Ready ist:true

   kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG get subnet --namespace platform \
       SUBNET_NAME --output jsonpath='{.status.conditions[?(@.type=="Ready")].status}'
   

   Ersetzen Sie MANAGEMENT_API_SERVER_KUBECONFIG durch den Pfad zur kubeconfig-Datei Ihres Management-API-Servers. Weitere Informationen finden Sie unter Zonale Management-API-Serverressourcen.

   Die Ausgabe sieht etwa so aus:

   status:
     conditions:
     - lastTransitionTime: "2025-06-06T07:29:34Z"
       message: IP allocation finished successfully
       observedGeneration: 1
       reason: AllocationSucceeded
       status: "True"
       type: Ready
   

   Aus diesem neuen zonalen Subnetz können Sie weitere zonale untergeordnete Subnetze erstellen oder einer internen Arbeitslast direkt eine einzelne IP-Adresse zuweisen.

Globales Stamm-Subnetz ohne Zonen-Zuweisung aufteilen

Wenn Sie ein globales Subnetz weiter unterteilen möchten, ohne es einer Zone zuzuweisen, erstellen Sie ein globales Subnetz und lassen Sie die Weiterleitungsstrategie in der benutzerdefinierten Ressource Subnet weg. Dieser Ansatz ist nützlich, wenn Sie Ihren global zugänglichen IP-Adressbereich weiterhin über das globale Stamm-Subnetz organisieren möchten, ohne die IP-Adressen einer Zone zuzuweisen.

So teilen Sie Ihr globales Stamm-Subnetz im globalen Bereich auf:platform

1. Beschreiben Sie in einem Terminalfenster alle Stamm-Subnetze der Standard-VPC und prüfen Sie die verfügbaren CIDR-Blöcke:

   kubectl --kubeconfig GLOBAL_API_SERVER_KUBECONFIG describe subnets --namespace platform \
       -l ipam.gdc.goog/vpc=default-vpc,ipam.gdc.goog/usage=network-root-range
   

   Ersetzen Sie GLOBAL_API_SERVER_KUBECONFIG durch den Pfad zur kubeconfig-Datei des globalen API-Servers. Weitere Informationen finden Sie unter Globale API-Serverressourcen. Die Labels sind konstant und müssen gleich bleiben.

   Die Ausgabe sieht etwa so aus:

   Name:         default-vpc-root-cidr
   Namespace:    platform
   Labels:       ipam.gdc.goog/allocation-preference=default
                 ipam.gdc.goog/subnet-group=default-vpc-root-group
                 ipam.gdc.goog/usage=network-root-range
                 ipam.gdc.goog/vpc=default-vpc
   Annotations:  <none>
   API Version:  ipam.global.gdc.goog/v1
   Kind:         Subnet
   Metadata:
     Creation Timestamp:  2025-06-18T23:05:38Z
     Finalizers:
       global-subnet-finalizer
     Generation:        1
     Resource Version:  439434
     UID:               5ed1c51a-b5ee-473e-a185-8e065a87ae8f
   Spec:
     ipv4Request:
       Cidr:                10.252.0.0/14
     Propagation Strategy:  None
     Type:                  Root
   Status:
     Children Refs:
       Name:       default-vpc-zone1-root-cidr
       Namespace:  platform
       Type:       SingleSubnet
     Conditions:
       Last Transition Time:  2025-06-18T23:05:38Z
       Message:               IP allocation finished successfully
       Observed Generation:   1
       Reason:                AllocationSucceeded
       Status:                True
       Type:                  Ready
     ipv4Allocation:
       Available CIDRs:
         10.254.0.0/15
         10.253.0.0/16
       Cidr:  10.252.0.0/14
   Events:    <none>
   

   Notieren Sie sich die Status.ipv4Allocation.Available CIDRs-Werte. Diese Werte sind die verfügbaren CIDR-Blöcke, auf die im nächsten Schritt verwiesen wird. In der vorherigen Ausgabe sind die CIDR-Bereiche 10.254.0.0/15 und 10.253.0.0/16 verfügbar. Je nach Anzahl der Root-Subnetze kann es in der Ausgabe mehrere Subnetze geben. Notieren Sie sich daher alle verfügbaren CIDR-Blöcke und das Subnetz, aus dem der verfügbare CIDR-Block stammt.

2. Vergleichen Sie den größten verfügbaren CIDR-Block aus dem vorherigen Schritt mit der Größe des CIDR-Blocks, der für Ihr neues globales Subnetz erforderlich ist. Wenn der größte verfügbare CIDR-Block nicht groß genug ist, um Ihr neues Subnetz zuzuweisen, fügen Sie ein neues globales Subnetz für den Netzwerk-Root-Bereich hinzu, bevor Sie fortfahren. Notieren Sie sich das übergeordnete Subnetz, aus dem Sie den CIDR-Block für Ihr neues Subnetz beziehen möchten.

   Wenn Sie beispielsweise einen /13-CIDR-Block benötigen, die verfügbaren CIDRs aber nur /15 und /16 enthalten, müssen Sie ein neues globales Subnetz für den Netzwerkstammbereich erstellen. Wenn Sie ein /15-Subnetz benötigen, können Sie das neue globale Subnetz aus dem vorhandenen /15-CIDR-Block zuweisen.

3. Erstellen Sie das neue Subnetz auf dem globalen API-Server:

   kubectl --kubeconfig GLOBAL_API_SERVER_KUBECONFIG apply -f - <<EOF
   apiVersion: ipam.global.gdc.goog/v1
   kind: Subnet
   metadata:
     labels:
       ipam.gdc.goog/vpc: default-vpc
       ipam.gdc.goog/usage: zone-network-root-range
     name: SUBNET_NAME
     namespace: platform
   spec:
     ipv4Request:
       prefixLength: CIDR_PREFIX_LENGTH
     propagationStrategy: None
     type: Branch
     parentReference:
       name: PARENT_SUBNET_NAME
       namespace: ORG_NAME
   EOF
   

   Ersetzen Sie Folgendes:

   • GLOBAL_API_SERVER_KUBECONFIG: der Pfad zur kubeconfig-Datei des globalen API-Servers. Weitere Informationen finden Sie unter Globale API-Serverressourcen.
   • SUBNET_NAME: der Name des neuen Subnetzes.
   • CIDR_PREFIX_LENGTH: Die CIDR-Präfixlänge des neuen Subnetzes, das dynamisch zugewiesen wird, z. B. 20. Wenn Sie den CIDR-Block statisch festlegen möchten, ersetzen Sie das Feld prefixLength durch das Feld cidr und legen Sie dann den CIDR-Block fest, z. B. 10.0.10.0/27.
   • PARENT_SUBNET_NAME: der Name des übergeordneten Subnetzes, z. B. default-vpc-root-cidr, oder des neuen globalen Subnetzes für den Netzwerk-Root-Bereich, das Sie erstellt haben.
   • ORG_NAME: der Name der Organisation.

   Weitere Informationen finden Sie in der API-Referenzdokumentation zur globalen Ressource Subnet.

4. Prüfen Sie, ob das Subnetz bereit und auf dem globalen API-Server verfügbar ist. Dazu muss der Status Ready vom Typ true sein:

   kubectl --kubeconfig GLOBAL_API_SERVER_KUBECONFIG get subnet --namespace platform \
       SUBNET_NAME --output jsonpath='{.status.conditions[?(@.type=="Ready")].status}'
   

   Die Ausgabe sieht etwa so aus:

   status:
     conditions:
     - lastTransitionTime: "2025-06-06T07:28:48Z"
       message: IP allocation finished successfully
       observedGeneration: 1
       reason: AllocationSucceeded
       status: "True"
       type: Ready
   

Das neue globale Subnetz für Ihre Organisation in der Standard-VPC ist verfügbar. Sie können ein Subnetz für eine bestimmte Zone erstellen.

Neues globales Subnetz für den Netzwerk-Root-Bereich hinzufügen

Globale Subnetze mit dem Label ipam.gdc.goog/usage: network-root-range enthalten den CIDR für alle Zonen des Netzwerks. Wenn das CIDR aufgebraucht ist, müssen Sie im globalen API-Server ein neues Subnetz für den Netzwerk-Root-Bereich erstellen. Bei Bedarf können Sie mehrere globale Stamm-Subnetze erstellen.

So erstellen Sie ein neues Subnetz für den Netzwerk-Root-Bereich:

• Erstellen Sie in einem Terminalfenster das globale Subnetz für den neuen Netzwerk-Root-Bereich für die Standard-VPC im Namespace platform:

  kubectl --kubeconfig GLOBAL_API_SERVER_KUBECONFIG apply -f - <<EOF
  apiVersion: ipam.global.gdc.goog/v1
  kind: Subnet
  metadata:
    labels:
      ipam.gdc.goog/vpc: default-vpc
      ipam.gdc.goog/usage: network-root-range
    name: SUBNET_NAME
    namespace: platform
  spec:
    ipv4Request:
      cidr: NEW_CIDR
    type: Root
  EOF
  

  Ersetzen Sie Folgendes:

  • GLOBAL_API_SERVER_KUBECONFIG: der Pfad zur kubeconfig-Datei des globalen API-Servers. Weitere Informationen finden Sie unter Globale API-Serverressourcen.
  • SUBNET_NAME: der Name des neuen Subnetzes.
  • NEW_CIDR: der neue CIDR-Bereich für das Subnetz. Dieser CIDR darf sich nicht mit einem CIDR in allen vorhandenen Subnetzen mit dem Label ipam.gdc.goog/usage: network-root-range auf demselben globalen API-Server überschneiden.

Dieses neue globale Root-Bereichssubnetz kann innerhalb des globalen API-Servers unterteilt oder einer bestimmten Zone zugewiesen werden.

Nächste Schritte

• Subnetze und IP-Adressen
• Netzwerkübersicht
• Hochverfügbare VM-Anwendung bereitstellen
• Containeranwendung mit hoher Verfügbarkeit bereitstellen