Adressierungsplan für VPC-Instanz entwerfen
Als erster Schritt beim Konzipieren Ihres IBM Cloud® Virtual Private Cloud wird der Adressierungsplan entworfen.
Ein korrekt entworfener Adressierungsplan dient den beiden folgenden Zielen:
- Erfüllung der Kommunikationsanforderungen für VPC-Instanzen.
- Sicherstellung der Flexibilität in Bezug auf zukünftiges Wachstum.
Dieses Dokument enthält ein Beispiel für den Entwurf des Adressierungsplans für eine drei Tiers umfassende Webanwendung, in der jedes Tier von mehreren Zonen unterstützt wird.
Obwohl jede IBM Cloud VPC in einer bestimmten Region bereitgestellt wird, kann sich die VPC über alle Zonen innerhalb dieser Region erstrecken. IBM Cloud VPC definiert ein Standardadresspräfix für jede Zone. Die Adresspräfixe ermöglichen die Kommunikation zwischen VPC-Instanzen in unterschiedlichen Zonen.
Unabhängig davon, ob die Anwendung vollständig in der Cloud enthalten ist, oder ob Teile der Anwendung an anderen Standorten ausgeführt werden, müssen die gleichen Entwurfsschritte ausgeführt werden.
Wenn Sie VPC-Instanzen erstellen, die Sie mithilfe von IBM Cloud Transit Gateway miteinander verbinden möchten, sollten Sie keine Standard-Adresspräfixe auswählen. Erstellen Sie Ihre VPC-Instanzen mit nicht überlappenden Präfixen für erfolgreiche Konnektivität.
Wenn Sie VPC-Instanzen erstellen, die Sie auch mit Ihrer IBM Cloud Classic-Infrastruktur verbinden möchten, indem Sie IBM Cloud Transit Gateway verwenden, verwenden Sie
keine IP-Adressen in Ihren Instanzen in den Blöcken 10.0.0.0/14, 10.200.0.0/14, 10.198.0.0/15 und 10.254.0.0/16. Vermeiden Sie außerdem IP-Adressen aus Ihren klassischen Infrastruktur-Subnetzen.
Weitere Informationen zum Entwurf Ihrer VPC-Instanzen für die Verwendung mit IBM Cloud Transit Gateway finden Sie unter Planung für IBM Cloud Transit Gateway.
Hinweise und Voraussetzungen zum Entwurf
Beim Entwurf des Adressierungsplans für eine Anwendung sollten Sie primär darauf achten, dass die für die Erstellung von Teilnetzen verwendeten CIDR-Blöcke in einer einzelnen Zone möglichst zusammenhängend bleiben. Hierdurch können diese Komponenten in einem einzigen Adresspräfix zusammengefasst werden können, wodurch Raum für zukünftiges Wachstum geschaffen wird.
Eine weitere Überlegung ist die Anzahl der verfügbaren Adressen, die ein Subnetz für die horizontale Skalierung benötigen könnte. Tabelle 1 enthält die Anzahl der verfügbaren Adressen in einem Teilnetz auf Basis der angegebenen CIDR-Blockgröße:
| CIDR-Blockgröße | Verfügbare Adressen |
|---|---|
| /22 | 1019 |
| /23 | 507 |
| /24 | 251 |
| /25 | 123 |
| /26 | 59 |
| /27 | 27 |
| /28 | 11 |
Basierend auf diesen beiden Überlegungen werden für dieses Beispiel die folgenden Annahmen getroffen:
- Die CIDR-Bereiche von Block
172.16.0.0/12der RFC 1918-Adressen werden für alle Teilnetze verwendet. - Die Präsentationsschicht der Anwendung ist eine dünne Schicht auf einer REST-API. Daher wirkt sich die horizontale Skalierung auf die mittlere Ebene stärker aus, als auf die Darstellungsebene.
Teilnetzgröße aller Tiers ermitteln
Der nächste Schritt besteht darin, die Teilnetzgröße der einzelnen Tiers (in Bezug auf die verfügbaren Adressen) zu bestimmen. Da jedes Tier der Anwendung in jeder Zone vorhanden ist, sind für jede Zone drei Teilnetze erforderlich.
Berücksichtigen Sie die folgenden Informationen, wenn Sie die Teilnetzgröße jeder Schicht planen:
- Die Datenbankschicht (Back-End) benötigt am seltensten eine dynamische Skalierung, sodass diese Teilnetze die kleinsten sind. Diese Teilnetze können also die geringste Anzahl verfügbarer Adressen enthalten.
- In diesem Beispiel wird ein
/27-CIDR-Block verwendet, der 27 Adressen in dieser Schicht zulässt.
- In diesem Beispiel wird ein
- Im mittleren Tier wird die dynamische Skalierung mit der größten Wahrscheinlichkeit benötigt. Daher sind hier die größten Teilnetze zu verwenden. Dies bedeutet, dass in diesem Tier die höchste Anzahl verfügbarer Adressen enthalten sein muss.
- In diesem Beispiel wird ein
/25-CIDR-Block verwendet, der 123 Adressen in dieser Schicht zulässt.
- In diesem Beispiel wird ein
- Das Front-End-Tier befindet sich in Bezug auf die erforderliche Anzahl der Adressen im mittleren Bereich. Es benötigt weniger Adressen als das mittlere Tier, jedoch mehr Adressen als das Datenbanktier.
- In diesem Beispiel wird ein
/26-CIDR-Block verwendet, der 59 Adressen in dieser Schicht zulässt.
- In diesem Beispiel wird ein
Teilnetze kombinieren und Adresspräfixe auswählen
Um für jede Zone ein geeignetes Adresspräfix auswählen zu können, benötigen Sie eine Teilnetzgröße, die hoch genug ist, um alle drei Teilnetze in jedem Tier aufzunehmen und trotzdem genügend Raum für die horizontale Skalierung und zukünftiges Wachstum bereitzustellen.
Ein Adresspräfix des Typs /24 ist das kleinste Präfix, zu dem diese drei Teilnetze kombiniert werden können (27 + 123 + 59). Wählen Sie die nächst größere Teilnetzgröße und nicht die geringste Größe aus. Durch die Zuordnung der
nächst größeren Teilnetzgröße (/23) wird die horizontale Skalierung über die Grenzen hinaus ermöglicht, die zuvor festgelegt wurden, weil dadurch das Hinzufügen neuer Teilnetze zu jeder Schicht über das gleiche Adresspräfix ermöglicht
wird.
Wenn Sie korrekte Teilnetzgröße festgelegt haben, können Sie die Adresspräfixe für jede einzelne Zone zuordnen:
| Zone | Adresspräfix |
|---|---|
| Zone 1 | 172.16.0.0/23 |
| Zone 2 | 172.16.2.0/23 |
| Zone 3 | 172.16.4.0/23 |
Auf dieser Basis können auch die drei Teilnetze in der jeweiligen Zone zugeordnet werden:
| Zone | Tier | Teilnetz-CIDR |
|---|---|---|
| Zone 1 | Mitte | 172.16.0.0/25 |
| Zone 1 | Front | 172.16.1.0/26 |
| Zone 1 | Datenbank | 172.16.1.128/27 |
| Zone 2 | Mitte | 172.16.2.0/25 |
| Zone 2 | Front | 172.16.3.0/26 |
| Zone 2 | Datenbank | 172.16.3.128/27 |
| Zone 3 | Mitte | 172.16.4.0/25 |
| Zone 3 | Front | 172.16.5.0/26 |
| Zone 3 | Datenbank | 172.16.5.128/27 |
Hinweise zur Erweiterung einer vorhandenen Infrastruktur
Wenn Sie die Einrichtung einer VPC-Instanz planen, die über eine vorhandene Infrastruktur hinausreicht, dann können Sie die hier aufgeführten Schritte ausführen, und zwar unabhängig davon, ob es sich um Ihre lokale Infrastruktur, eine weitere VPC-Instanz oder sogar eine weitere Cloud handelt. Beachten Sie hierbei, dass bereits vorhandene Adressbereiche nicht wiederverwendet werden dürfen. Durch die Vermeidung der Wiederverwendung von Adressen können Sie die Nutzung der IBM Cloud VPC-Funktionen optimieren.