Planung und Architektur von IP-Adressen

Eine effektive IP-Adressplanung trägt dazu bei, zukünftige Netzwerkunterbrechungen für Ihre Arbeitslasten und Dienste zu minimieren, wenn diese skaliert werden.

Dieses Dokument richtet sich an Netzwerkadministratoren in der Gruppe der Plattformadministratoren, die für die Planung der IP-Adressbereiche für eine Organisation verantwortlich sind. Weitere Informationen finden Sie unter Zielgruppen für die GDC-Dokumentation mit Air Gap.

Vorteile einer sorgfältigen IP-Adressplanung

Eine sorgfältige IP-Adressplanung bietet folgende Vorteile:

  • Isolation: Richtige Netzwerksegmentierung zwischen verschiedenen Organisationen und zwischen Verwaltungs- und Datenebenen.
  • Skalierbarkeit: Ausreichender IP-Adressraum für aktuelle und zukünftige Arbeitslasten und Dienste, einschließlich administrativer Dienste, denen nach der Bereitstellung einer Organisation kein zusätzlicher IP-Adressraum zugewiesen werden kann.
  • Konnektivität: Korrektes Routing und Erreichbarkeit für alle Komponenten im GDC-Universum mit Air Gap und bei Bedarf für externe Netzwerke.
  • Compliance: Einhaltung bestimmter Netzwerkadressierungsschemas oder Einschränkungen, die von Ihrer Umgebung vorgeschrieben werden.

Die GDC-Architektur verwendet VRF-Instanzen (Virtual Routing and Forwarding) , um Netzwerkisolation und -segmentierung zu erreichen. Für eine erfolgreiche Planung ist es wichtig zu wissen, welche IP-Adressräume Sie verwalten und welche ausschließlich Ihrem IO gehören.

Planungsprozess

Bevor der IO Ihre Organisation bereitstellt, müssen Sie die IP-Adressarchitektur für Ihre Organisation festlegen. Der IO führt Sie durch diese Schritte.

Der allgemeine Prozess für die Planung und Bereitstellung der Netzwerk-IP-Adressen einer Organisation sieht so aus:

  1. CIDR-Bereiche definieren: Bestimmen Sie gemeinsam mit Ihrem Netzwerkteam geeignete sich nicht überschneidende CIDR-Blöcke für Ihre Standard-VPC, Infrastruktur-VPC, Ihr Admin-Netzwerk Segment und Ihr Datennetzwerksegment.

  2. CIDR-Bereiche für den IO bereitstellen: Geben Sie diese CIDR-Blöcke dem IO als Teil des Fragebogens zur Aufnahme von Organisationen (Organization Intake Questionnaire, OIQ) an, wenn Sie eine neue Organisation anfordern. Der IO verwendet die CIDR-Blöcke, um die erforderlichen globalen Subnetze auf den entsprechenden API-Servern zu konfigurieren.

Nachdem der IO Ihre Organisation bereitgestellt hat, sind Sie für die Verwaltung bestimmter IP-Adressräume innerhalb der Organisation verantwortlich, hauptsächlich für die Bereitstellung von Arbeitslasten und die Bereitstellung externer Dienste.

Weitere Informationen zur Planung der IP-Adressarchitektur finden Sie im Abschnitt Überlegungen zur IP-Adressarchitektur in diesem Dokument.

Weitere Informationen zu den einzelnen Netzwerken und zur Auswahl der CIDR-Bereiche für die einzelnen Netzwerke finden Sie im Abschnitt Überlegungen zu IP-Adressen für eine Organisation in diesem Dokument.

Überlegungen zur IP-Adressarchitektur

Um eine dauerhafte IP-Adressarchitektur bereitzustellen, die sich an die sich ändernden Netzwerkanforderungen Ihrer Organisation anpassen kann, sollten Sie die folgenden IP-Adresseigenschaften in GDC berücksichtigen:

  • Überlappende und nicht überlappende IP-Adressen:
    • VPC-Netzwerke (Virtual Private Cloud) können sich zwischen verschiedenen Organisationen überschneiden, müssen aber innerhalb einer Organisation in allen Zonen eindeutig sein und sich von allen Netzwerken unterscheiden, mit denen sie ein Peering durchführen.
    • Externe Netzwerksegmente können sich zwischen verschiedenen Organisationen überschneiden, wenn diese Organisationen separate Interconnects verwenden. Wenn sie einen Interconnect gemeinsam nutzen, müssen die IP-Adressen innerhalb der gleichen Organisation in allen Zonen eindeutig sein und sich von allen Netzwerken unterscheiden, mit denen sie ein Peering durchführen.
  • Mindestgrößen für CIDR-Blöcke: Halten Sie die für jedes Netzwerksegment angegebenen Mindestlängen für CIDR-Präfixe ein, um ausreichend Adressraum für Systemkomponenten und zukünftiges Wachstum zuzuweisen.
  • RFC 1918 bevorzugen: Während in den meisten verwalteten Netzwerken öffentliche IP-Adressen verwendet werden können, werden für interne GDC-Netzwerke mit Air Gap in der Regel private RFC 1918-Adressen empfohlen, wenn die Zone keine Verbindung zum Internet hat.
  • Genauigkeit des OIQ: Die Informationen, die Sie Ihrem IO im OIQ zur Verfügung stellen, sind entscheidend. Falsche oder schlecht geplante IP-Adressbereiche können zu erheblichen Problemen bei der Bereitstellung führen.
  • Mehrere Zonen: VPCs von Organisationen und externe Netzwerksegmente erstrecken sich über eine globale Organisation, erfordern aber eindeutige IP-Adresszuweisungen für jede Zone, die sich innerhalb dieser globalen Organisation nicht überschneiden. Verwenden Sie globale Subnetze, um eindeutige IP-Adressbereiche für jede Zone für eine bestimmte Organisation zuzuweisen.

Ein Beispiel für eine IP-Adressarchitektur finden Sie im folgenden Diagramm:

Ihre Interconnects in Ihrem Universum bestimmen, wie Sie Ihre IP-Adressarchitektur einrichten.

In diesem Diagramm gibt es zwei verschiedene Interconnects, die sich über ein Universum mit mehreren Zonen erstrecken: einen Dedicated Interconnect und einen Shared Interconnect. In diesem Universum sind mehrere Organisationen definiert. Organisation 1 befindet sich in einem Dedicated Interconnect, sodass sich die externen Subnetze mit anderen Organisationen im Universum überschneiden können. Die Organisationen im Shared Interconnect können jedoch keine überlappenden externen Subnetze haben, da sie sich alle im selben Interconnect befinden.

Jede Organisation definiert die VPC-Netzwerke und externen Netzwerksegmente. In diesem Beispiel werden Anycast-IP-Adressen verwendet, um Traffic zwischen den zonenbasierten externen Netzwerksegmenten weiterzuleiten, sodass der Dienst der nächstgelegenen oder leistungsstärksten Zone die Netzwerkanfrage verarbeitet. Weitere Informationen zu Anycast-IP-Adressen finden Sie unter IP-Adressen in GDC.

Überlegungen zu IP-Adressen für eine Organisation

Prüfen Sie jedes Netzwerk und seine Funktion in Ihrer Organisation, bevor Sie den OIQ zum Definieren von CIDR-Bereichen ausfüllen:

  • Standard-VPC: Host für interne IP-Adressen für interne Arbeitslasten. Sie können diesem Netzwerk zusätzliche IP-Adressen zuweisen, nachdem Ihre Organisation bereitgestellt wurde.
  • Infrastruktur-VPC: Host für interne IP-Adressen für GDC-Dienste mit Air Gap von Google. Sie können diesem Netzwerk nach der Bereitstellung Ihrer Organisation keine zusätzlichen IP-Adressen zuweisen.
  • Admin-Netzwerksegment: Host für externe IP Adressen für administrative Dienste. Sie können diesem Netzwerk nach der Bereitstellung Ihrer Organisation keine zusätzlichen IP-Adressen zuweisen.
  • Datennetzwerksegment: Host für externe IP Adressen für externe Dienste. Sie können diesem Netzwerk zusätzliche IP-Adressen zuweisen, nachdem Ihre Organisation bereitgestellt wurde.

Weitere Informationen zu Netzwerkbeschreibungen und den verwendeten IP-Adressen finden Sie unter Netzwerke in GDC.

VPC-Netzwerke

Bereiten Sie die folgenden Informationen für jeden VPC-Netzwerktyp vor, um sie Ihrem IO für die Bereitstellung Ihrer IP-Adressräume in den VPC-Netzwerken Ihrer Organisation zur Verfügung zu stellen.

Standard-VPC

Sie stellen Ihre internen Arbeitslasten wie virtuelle Maschinen (VMs) und Container über die Standard-VPC bereit und verwalten sie.

IP-Adressen in der Standard-VPC müssen sich von anderen VPCs in allen Zonen Ihres Universums und von allen IP-Adressen von Peering-Netzwerken unterscheiden. IP-Adressen in dieser VPC können sich zwischen verschiedenen Organisationen überschneiden und können RFC 1918 private IP-Adressen oder öffentliche IP-Adressen sein. Sie können zusätzliche Standard-VPC-Subnetze erstellen, nachdem die Organisation bereitgestellt wurde.

Beachten Sie die folgenden Informationen, wenn Sie mit Ihrem IO am IP-Adressbereich der Standard-VPC-Root arbeiten. Die entsprechenden OIQ-Felder und der globale Root-Subnetzname sind feste Werte und können nicht geändert werden.

  • OIQ-Feld: defaultVPCCIDR
  • Globaler Root-Subnetzname: default-vpc-root-cidr
  • Globaler API-Server: Globale Organisation
  • Mindestgröße des Subnetzes: /16 für jede Zone
  • Empfohlene Größe des Subnetzes: /16 für jede Zone

Infrastruktur-VPC

Sie stellen keine Arbeitslasten direkt in der Infrastruktur-VPC bereit, müssen aber den IP-Adressbereich für die Verwendung durch die vom System verwalteten GDC-Dienste mit Air Gap angeben.

IP-Adressen in der Infrastruktur-VPC müssen sich von anderen VPCs in allen Zonen Ihres Universums und von allen IP-Adressen von Peering-Netzwerken unterscheiden. IP-Adressen in dieser VPC können sich zwischen verschiedenen Organisationen überschneiden und können private RFC 1918-IP-Adressen oder öffentliche IP-Adressen sein. Sie können nach der Bereitstellung der Organisation keine zusätzlichen Infrastruktur-VPC-Subnetze erstellen.

Beachten Sie die folgenden Informationen, wenn Sie mit Ihrem IO am IP-Adressbereich der Infrastruktur-VPC-Root arbeiten. Die entsprechenden OIQ-Felder und der globale Root-Subnetzname sind feste Werte und können nicht geändert werden.

  • OIQ-Feld: infraVPCCIDR
  • Globaler Root-Subnetzname: infra-vpc-root-cidr
  • Globaler API-Server: Globaler Root
  • Mindestgröße des Subnetzes: /16 für jede Zone
  • Empfohlene Größe des Subnetzes: /16 für jede Zone

Externe Netzwerksegmente

Bereiten Sie die folgenden Informationen für jeden externen Netzwerksegmenttyp vor, um sie Ihrem IO für die Bereitstellung Ihrer IP-Adressräume in den externen Netzwerken Ihrer Organisation zur Verfügung zu stellen.

Admin-Netzwerksegment

Sie stellen keine externen Dienste direkt im Admin-Netzwerksegment bereit, müssen aber den IP-Adressbereich für die Verwendung durch die administrativen Dienste angeben, die in Ihrer Organisation ausgeführt werden, z. B. die GDC-Konsole und Verwaltungs-APIs. Sie können diesem Netzwerk nach der Bereitstellung Ihrer Organisation keine zusätzlichen IP-Adressen zuweisen.

IP-Adressen im Admin-Netzwerksegment können sich zwischen verschiedenen Organisationen überschneiden, wenn diese Organisationen separate Interconnect-Anhangsgruppen verwenden. Wenn sie eine Anhangsgruppe gemeinsam nutzen, müssen die IP-Adressen innerhalb der gleichen Organisation in allen Zonen eindeutig sein und sich von allen Netzwerken unterscheiden, mit denen sie ein Peering durchführen. Sie können nach der Bereitstellung der Organisation keine zusätzlichen Admin-Netzwerksegment-Subnetze erstellen.

Beachten Sie die folgenden Informationen, wenn Sie mit Ihrem IO am IP-Adressbereich der Admin-Netzwerksegment-Root arbeiten. Die entsprechenden OIQ-Felder und der globale Root-Subnetzname sind feste Werte und können nicht geändert werden.

  • OIQ-Feld: orgAdminExternalCIDR
  • Globaler Root-Subnetzname: admin-external-root-cidr
  • Globaler API-Server: Globaler Root
  • Mindestgröße des Subnetzes: /26 für jede Zone
  • Empfohlene Größe des Subnetzes: /26 für jede Zone

Datennetzwerksegment

Sie stellen Ihre externen Dienste, die außerhalb Ihrer Organisation ausgeführt werden, z. B. Egress-NAT (Network Address Translation) und externe Load-Balancer, im Datennetzwerksegment bereit und verwalten sie. Sie können diesem Netzwerk zusätzliche IP-Adressen zuweisen, nachdem Ihre Organisation bereitgestellt wurde.

IP-Adressen im Datennetzwerksegment können sich zwischen verschiedenen Organisationen überschneiden, wenn diese Organisationen separate Interconnect-Anhangsgruppen verwenden. Wenn sie eine Anhangsgruppe gemeinsam nutzen, müssen die IP-Adressen innerhalb der gleichen Organisation in allen Zonen eindeutig sein und sich von allen Netzwerken unterscheiden, mit denen sie ein Peering durchführen. Sie können zusätzliche Datennetzwerksegment-Subnetze erstellen, nachdem die Organisation bereitgestellt wurde.

Beachten Sie die folgenden Informationen, wenn Sie mit Ihrem IO am IP-Adressbereich der Datennetzwerksegment-Root arbeiten. Die entsprechenden OIQ-Felder und der globale Root-Subnetzname sind feste Werte und können nicht geändert werden.

  • OIQ-Feld: orgDataExternalCIDR
  • Globaler Root-Subnetzname: data-external-root-cidr
  • Globaler API-Server: Globaler Root
  • Mindestgröße des Subnetzes: /26 für jede Zone
  • Empfohlene Größe des Subnetzes: /23 für jede Zone

Nächste Schritte