Interne Bereiche – Übersicht

Mit internen Bereichen können Sie Blöcke interner IP-Adressen reservieren und angeben, wie diese Adressen verwendet werden können. Mit internen Bereichen können Sie die VPC-Netzwerktopologie (Virtual Private Cloud) verwalten, wenn Netzwerke mit Funktionen wie VPC-Netzwerk-Peering, Freigegebene VPC, Cloud VPN und Cloud Interconnect immer komplexer werden.

Spezifikationen

  • Eine interne Bereichsressource stellt einen internen IPv4- oder IPv6-CIDR-Block dar, der aus einem VPC-Netzwerk zugewiesen wird.
  • Wenn Sie einen internen Bereich reservieren, können Sie Folgendes konfigurieren:
    • Ob der Bereich von Ressourcen im VPC-Netzwerk verwendet werden kann Google Cloud oder für die externe Nutzung reserviert ist.
    • Wie der Bereich verwendet werden kann, wenn VPC-Netzwerk-Peering konfiguriert ist
    • Ob sich der Bereich mit Subnetzen oder Routen im übergeordneten VPC-Netzwerk überschneiden kann.
    • Ob der Adressblock oder das Überlappungsverhalten des Bereichs geändert werden kann.
  • Standardmäßig können Sie keinen internen Bereich reservieren, der IP-Adressen enthält, die von anderen Google Cloud Ressourcen im VPC-Netzwerk des Bereichs verwendet werden.
  • Wenn Sie eine Überschneidung mit Subnetzen, Routen oder beiden zulassen, können Sie interne Bereiche mit CIDR-Blöcken erstellen, die sich mit dem IP-Adressbereich der angegebenen Ressourcentypen überschneiden.
  • Sie können keine Google Cloud Ressourcen erstellen, die IP-Adressen aus einem vorhandenen internen Bereich verwenden, es sei denn, Sie ordnen die Ressource explizit dem internen Bereich zu (für Subnetze) oder lassen Überschneidungen zu (für Routen).
  • Wenn ein interner Bereich unveränderlich ist, können Sie nur die Beschreibung des Bereichs ändern. Wenn der Bereich veränderbar ist (Standardeinstellung), können Sie den CIDR-Block, das Überschneidungsverhalten und die Beschreibung des Bereichs ändern. Die Unveränderlichkeit kann nach dem Erstellen des Bereichs nicht mehr geändert werden.

Angenommen, Sie haben einen veränderbaren internen Bereich für 10.0.0.0/24 ohne Überschneidung angegeben.

Wenn Sie versuchen, ein Subnetz im selben VPC-Netzwerk zu erstellen, das den Bereich 10.0.0.0/25 verwendet, schlägt die Erstellung des Subnetzes fehl, es sei denn, Sie verknüpfen das Subnetz mit dem internen Bereich.

Wenn Sie versuchen, eine Route im selben VPC-Netzwerk zu erstellen, das den Bereich 10.0.0.0/25 verwendet, schlägt die Erstellung der Route fehl, es sei denn, Sie aktualisieren den internen Bereich, indem Sie die Eigenschaft overlaps auf OVERLAP_ROUTE_RANGE festlegen.

Peering-Typen

Der Peering-Typ eines internen Bereichs gibt das Verhalten des Bereichs in Bezug auf VPC-Netzwerk-Peering an. Der Peering-Typ kann einer der folgenden sein:

  • FOR_SELF: Der interne Bereich kann nur in dem VPC-Netzwerk verwendet werden, in dem er erstellt wurde. Der Bereich ist über das zugehörige VPC-Netzwerk und die Peers dieses VPC-Netzwerks zugänglich. Peers von Peer-Netzwerke können diesen Bereich jedoch nicht verwenden. Dies ist die Standardeinstellung.

  • FOR_PEER: Der interne Bereich kann nur mit Ressourcen in Peer-Netzwerken verknüpft werden. Mit dem Bereich können keine Ressource im übergeordneten VPC-Netzwerk des Bereichs verknüpft werden, Ressourcen in Peer-Netzwerken jedoch schon.

  • NOT_SHARED: Der interne Bereich kann nur mit Ressourcen in dem Netzwerk verknüpft werden, in dem der Bereich erstellt wurde, ohne den Bereich für seine Peers freizugeben. Ein Peering-Netzwerk kann den internen Bereich nicht in einer Weise verwenden, die für das übergeordnete VPC-Netzwerk sichtbar ist. Ein Peering-Netzwerk kann denselben Bereich verwenden, wenn der Peering-Typ in beiden Netzwerken NOT_SHARED ist.

Nutzungstypen

Der Nutzungstyp einer internen Bereichsressource gibt an, ob der zugewiesene CIDR-Block anderen Google Cloud Ressourcen im übergeordneten VPC-Netzwerk zugeordnet werden kann. Der Nutzungstyp für einen internen Bereich kann einer der folgenden sein:

  • FOR_VPC: Der Bereich kann anderen Google Cloud Ressourcen im übergeordneten VPC-Netzwerk zugeordnet werden. Dies ist die Standardeinstellung.

  • EXTERNAL_TO_VPC: Der Bereich kann keinem anderenGoogle Cloud Ressourcen im übergeordneten VPC-Netzwerk zugeordnet werden.

  • FOR_MIGRATION: Der Bereich kann zum Migrieren eines Subnetzbereichs verwendet werden, auch von einem VPC-Netzwerk mit Peering zu einem anderen.

IPv4-Subnetzbereiche migrieren

Wenn Sie einen CIDR-Bereich von einem Subnetz in ein anderes migrieren möchten, müssen Sie das Subnetz löschen und dann neu erstellen. Normalerweise wird der CIDR-Bereich eines gelöschten Subnetzes freigegeben und kann von einer anderen Ressource verwendet werden. Wenn Sie den CIDR-Bereich während einer Migration reservieren möchten, nachdem das ursprüngliche Subnetz gelöscht, aber das neue Subnetz noch nicht erstellt wurde, können Sie einen internen IPv4-Bereich mit dem FOR_MIGRATION-Nutzungstyp reservieren.

Ein interner Bereich für die Migration gibt einen CIDR-Bereich, ein Quell- und ein Zielsubnetz an.

  • Der IPv4-CIDR-Bereich muss mit dem Bereich des Quell-Subnetzes übereinstimmen oder ihn enthalten.
  • Die Quell- und Zielsubnetze können sich im selben Projekt oder in verschiedenen Projekten befinden.
  • Das Quellsubnetz muss sich im selben Projekt wie die Ressource für den internen Bereich befinden.
  • Das Zielsubnetz muss zum Zeitpunkt der Erstellung des internen Bereichs nicht vorhanden sein.

Wenn Sie das Quellsubnetz löschen, kann der CIDR-Bereich nur einem Subnetz zugewiesen werden, das mit dem Zielsubnetz übereinstimmt.

Nachdem Sie das Subnetz migriert haben, können Sie den internen Bereich löschen.

Interne Bereiche mit dem Nutzungstyp FOR_MIGRATION müssen den Peering-Typ FOR_SELF haben.

Beispielanwendungsfälle

In der folgenden Tabelle werden Anwendungsfälle für interne Bereiche mit verschiedenen Kombinationen von Nutzung und Peering beschrieben. Interne IPv6-Bereiche haben spezifische Nutzungs- und Peeringanforderungen und unterstützen nicht alle hier aufgeführten Anwendungsfälle.

Zweck Nutzungstyp Peering-Typ IP-Version
Reservieren Sie einen Bereich nur für die Verwendung innerhalb des VPC-Netzwerk des Bereichs. FOR_VPC NOT_SHARED IPv4
Reservieren Sie einen Bereich speziell für Peer-VPC-Netzwerke, damit er nicht von Ressourcen im lokalen VPC-Netzwerk verwendet werden kann. FOR_VPC FOR_PEER IPv4
Sie können einen Bereich für die Verwendung außerhalb des VPC-Netzwerks des Bereichs reservieren, um zu verhindern, dass Ressourcen im VPC-Netzwerk des Bereichs diese IP-Adressen verwenden. Verhindern Sie bei IPv6-Bereichen die automatische Zuweisung der IP-Adressen des Bereichs an neue Subnetze, die nur IPv6 oder Dual-Stack verwenden. EXTERNAL_TO_VPC FOR_SELF IPv4 oder IPv6
Sie können einen Bereich nur für die lokale Nutzung reservieren, um zu verhindern, dass Ressourcen im VPC-Netzwerk des Bereichs diese IP-Adressen verwenden. EXTERNAL_TO_VPC NOT_SHARED IPv4
Reservieren Sie einen Bereich vorübergehend, um ein Subnetz von einem VPC-Netzwerk in ein anderes zu migrieren. FOR_MIGRATION FOR_SELF IPv4

Strategien zur IPv4-Adresszuweisung

Wenn Sie einen internen IPv4-Bereich reservieren, können Sie entweder einen CIDR-Block angeben oder von Google Cloud einen automatisch zuweisen lassen. Für die automatische Zuweisung geben Sie eine Präfixlänge und optionale Ziel-CIDR-Blöcke an. Google Cloudberücksichtigt vorhandene IP‑Adresszuweisungen und weist dem internen Bereich einen freien CIDR‑Block der ausgewählten Größe aus den Ziel- oder Standard-CIDR‑Blöcken zu.

Wenn Sie die automatische Zuweisung verwenden, können Sie die Zuweisungsstrategie angeben, Google Cloud mit der ein freier Block ausgewählt wird. Zuweisungsstrategien sind nur für automatisch zugewiesene interne IPv4-Bereiche verfügbar. In der folgenden Tabelle werden die Zuweisungsstrategien beschrieben, aus denen Sie auswählen können:

Strategie Beschreibung Vor- und Nachteile
RANDOM Zufällig einen freien CIDR-Block zuweisen. Das ist die Standardstrategie.

Die schnellste Methode, um mehrere CIDR-Blöcke mit derselben Präfixlänge gleichzeitig zu reservieren.

Dies kann zu einer Fragmentierung Ihres IP-Adressbereichs führen.
FIRST_AVAILABLE Weisen Sie den freien CIDR-Block mit der numerisch niedrigsten Start-IP-Adresse zu.

Die IP-Bereichszuweisung ist am vorhersehbarsten. Maximiert den verbleibenden zusammenhängenden nicht verwendeten IP-Adressbereich innerhalb Ihrer Ziel-CIDR-Blöcke.

Dies führt zu Konflikten bei der gleichzeitigen Reservierung interner Bereiche und damit zu längeren Zuweisungszeiten.
RANDOM_FIRST_N_AVAILABLE Sie geben eine Zahl, N, an. Google Cloud findet N freie CIDR-Blöcke der angeforderten Präfixlänge und priorisiert Blöcke mit den niedrigsten Start-IP-Adressen. Weisen Sie einen zufälligen CIDR-Block aus diesem Satz zu.

Am besten geeignet, um Konflikte bei gleichzeitigen Zuweisungen zu reduzieren und gleichzeitig den zusammenhängenden nicht verwendeten IP‑Adressbereich beizubehalten.

Sie können die Leistung bei gleichzeitigen Zuweisungen verbessern, indem Sie N erhöhen. Dies kann jedoch zu einer stärkeren Fragmentierung des IP-Adressbereichs führen.

FIRST_SMALLEST_FITTING Die kleinsten freien CIDR-Blöcke (längste Präfixlänge) finden, die die angeforderte Präfixlänge enthalten können. Weisen Sie aus diesem Satz den Block mit der niedrigsten Start-IP-Adresse zu.

Am besten geeignet, um die IP-Adressfragmentierung zu minimieren.

Hier kommt es am häufigsten zu Konflikten bei gleichzeitigen Reservierungen, was zu längeren Zuweisungszeiten führt.

Angenommen, Sie möchten einen /24-CIDR-Block aus dem Zielblock 10.0.0.0/8 reservieren. Innerhalb des Zielblocks sind nur die folgenden IP-Adressbereiche verfügbar: 10.1.0.0/25, 10.2.0.0/16 und 10.3.0.0/23. In der folgenden Liste sind die Blöcke aufgeführt, die für jede Zuordnungsstrategie ausgewählt werden können:

  • RANDOM: Google Cloud bestimmt einen beliebigen verfügbaren /24-Block, z. B. 10.2.179.0/24, nach dem Zufallsprinzip.
  • FIRST_AVAILABLE: Google Cloud findet den niedrigsten verfügbaren /24-Block, also 10.2.0.0/24.
  • RANDOM_FIRST_N_AVAILABLE: Angenommen, Sie geben 3 für N an.Google Cloud erstellt dann einen Satz aus den drei niedrigsten verfügbaren /24-Blöcken: 10.2.0.0/24, 10.2.1.0/24 und 10.2.2.0/24. Aus diesem Satz wähltGoogle Cloud nach dem Zufallsprinzip einen der drei Blöcke aus, z. B. 10.2.2.0/24.
  • FIRST_SMALLEST_FITTING: Google Cloud sucht die kleinsten verfügbaren Blöcke (höchstes Präfix), die das angegebene Präfix von /24 enthalten können. Der kleinste verfügbare Block ist 10.3.0.0/23. Google Cloudweist den niedrigsten Block aus diesem Bereich zu, also 10.3.0.0/24.

Kontingent

Die Anzahl der internen Bereichsressourcen, die Sie in einem einzelnen Projekt erstellen können, ist begrenzt. Weitere Informationen erhalten Sie im Abschnitt zu projektbasierten Kontingenten in der VPC-Dokumentation.

Nächste Schritte