VCNs und Subnetze - Überblick
Erfahren Sie mehr über virtuelle Cloud-Netzwerke (VCNs) und Subnetze in OCI.
Dieses Thema behandelt virtuelle Cloud-Netzwerke (VCNs) und die darin enthaltenen Subnetze. In diesem Thema werden die Begriffe virtuelles Cloud-Netzwerk, VCN und Cloud-Netzwerk synonym verwendet. In der Konsole wird der Begriff Virtuelles Cloud-Netzwerk verwendet, während die API die Kurzform VCN verwendet.
Ein VCN ist ein softwaredefiniertes Netzwerk, das Sie in den Data Centern in Oracle Cloud Infrastructure in einer bestimmten Region einrichten. Ein Subnetz ist eine Unterteilung eines VCN. Einen Überblick über VCNs, zulässige Größe, Standard-VCN-Komponenten und Szenarios für die Verwendung eines VCN finden Sie unter Networking - Überblick.
Ein VCN kann mehrere sich nicht überschneidende IPv4-CIDR-Blöcke enthalten, die Sie nach dem Erstellen des VCN ändern können. Unabhängig von der Anzahl der CIDR-Blöcke können Sie maximal 64.000 private IPs im VCN erstellen. Ein VCN kann optional für IPv6 aktiviert werden, und Oracle weist ein /56-Präfix zu. Sie können auch ein BYOIP-IPv6-Präfix importieren und einem vorhandenen VCN zuweisen oder ein neues VCN mit einem BYOIP- oder ULA-IPv6-Präfix erstellen.
Sie können ein VCN privat mit einem anderen VCN verbinden, sodass der Traffic nicht über das Internet geleitet wird. Die CIDRs für die beiden VCNs dürfen sich nicht überschneiden. Weitere Informationen finden Sie unter Zugriff auf andere VCNs: Peering. Ein Beispiel für ein erweitertes Routingszenario, das ein Peering mehrerer VCNs umfasst, finden Sie unter Transitrouting in einem Hub-VCN.
Jedes Subnetz in einem VCN besteht aus einem zusammenhängenden Bereich von IPv4-Adressen und optional IPv6-Adressen, die sich nicht mit anderen Subnetzen im VCN überschneiden. Beispiel: 172.16.1.0/24. Mit IPv4-Adressen sowie IPv6-Adressen sind die ersten beiden und die letzte Adresse im CIDR des Subnetzes vom Networking-Service reserviert. Sie können die Größe des Subnetzes nach der Erstellung ändern. IPv6-fähige Subnetze sind immer /64.
Subnetze fungieren als eine Konfigurationseinheit: Alle Instanzen in einem bestimmten Subnetz verwenden dieselbe Routentabelle sowie dieselben Sicherheitslisten und DHCP-Optionen. Weitere Informationen finden Sie unter Standardkomponenten Ihres VCN.
Subnetze können öffentlich oder privat sein (siehe Öffentliche und private Subnetze im Vergleich). Die Auswahl von "Öffentlich" oder "Privat" erfolgt beim Erstellen des Subnetzes. Sie können sie später nicht ändern.
Jede Compute-Instanz befindet sich in einem Subnetz. Genauer gesagt ist jedoch jede Instanz an eine virtuelle Netzwerkkarte (VNIC) angehängt, die sich wiederum im Subnetz befindet und dieser Instanz eine Netzwerkverbindung ermöglicht.
Die IPv6-Adressierung wird für alle kommerziellen und Regierungsregionen unterstützt. Weitere Informationen finden Sie unter IPv6-Adressen.
Regionale Subnetze
Ursprünglich waren Subnetze für die Abdeckung von nur einer Availability-Domain (AD) in einer Region konzipiert. Dabei handelte es sich ausschließlich um AD-spezifische Subnetze, weshalb die zugehörigen Ressourcen in einer bestimmten Availability-Domain gespeichert sein mussten. Jetzt können Subnetze AD-spezifisch oder regional sein. Sie wählen den Typ beim Erstellen des Subnetzes. Beide Arten von Subnetzen können in demselben VCN vorhanden sein. Im folgenden Diagramm sind die Subnetze 1-3 AD-spezifisch und Subnetz 4 regional.
Abgesehen vom Entfernen des AD-Constraints verhalten sich regionale Subnetze genauso wie AD-spezifische Subnetze. Oracle empfiehlt die Verwendung von regionalen Subnetzen, da sie flexibler sind. Sie erleichtern die effiziente Aufteilung des VCN in Subnetze, während sie gleichzeitig vorbeugend für etwaige Availability-Domain-Ausfälle konzipiert sind.
Wenn Sie eine Ressource wie eine Compute-Instanz erstellen, wählen Sie aus, in welcher Availability-Domain sich die Ressource befindet. Vom Standpunkt des virtuellen Netzwerks aus müssen Sie auch wählen, in welchem VCN und Subnetz sich die Instanz befinden wird. Sie können entweder ein regionales Subnetz oder ein AD-spezifisches Subnetz auswählen, das der für die Instanz gewählten AD entspricht.
Wenn jemand in Ihrer Organisation ein regionales Subnetz implementiert, müssen Sie möglicherweise jeden Clientcode aktualisieren, der mit Subnetzen des Networking-Service und privaten IPs arbeitet. Es können wichtige Änderungen hinsichtlich der API vorliegen. Weitere Informationen finden Sie im Versionshinweis für regionale Subnetze.
Limits für VCNs und Subnetze
|
Ressource |
Geltungsbereich |
Oracle Universal Credits |
Pay-as-you-go oder Testversion |
|---|---|---|---|
| VCN | Region | 50 | 10 |
| Subnetze | VCN | 300 | 300 |
| IPv4-CIDRs | VCN | 5 | 5 |
| IPv6-Präfixe | VCN | 5 | 5 |
| IPv4-CIDRs | Subnetz | 1 | 1 |
| IPv6-Präfixe | Subnetz | 3* | 3* |
| Von Oracle zugewiesenes IPv6-Präfix | Subnetz | 1 | 1 |
| * Das Limit für diese Ressource kann auf maximal fünf erhöht werden. | |||
Mit VCNs und Subnetzen arbeiten
Eine der ersten Aufgaben, die Sie bei der Arbeit mit Oracle Cloud Infrastructure-Ressourcen ausführen, ist das Erstellen eines VCN mit einem oder mehreren Subnetzen. Sie können in der Konsole mit einem einfachen VCN und einigen zugehörigen Ressourcen beginnen, mit denen Sie ganz leicht eine Verbindung zu einer Instanz herstellen und die Instanz starten können. Siehe Tutorial - Erste Linux-Instanz starten oder Tutorial - Erste Windows-Instanz starten.
Zum Zwecke der Zugriffskontrolle müssen Sie beim Erstellen eines VCN oder Subnetzes das Compartment angeben, in dem die Ressource gespeichert werden soll. Wenn Sie nicht sicher sind, welches Compartment verwendet werden soll, wenden Sie sich an den Administrator in Ihrer Organisation.
Sie können dem VCN und den zugehörigen Subnetzen optional aussagekräftige Namen zuweisen. Die Namen müssen nicht eindeutig sein, und Sie können sie später ändern. Oracle weist jeder Ressource automatisch eine eindeutige ID zu, die als Oracle Cloud-ID (OCID) bezeichnet wird. Weitere Informationen finden Sie unter Ressourcen-IDs.
Sie können auch ein DNS-Label für das VCN und jedes Subnetz hinzufügen. Dies ist erforderlich, wenn die Instanzen die Internet- und VCN-Resolver-Funktion für DNS im VCN verwenden sollen. Weitere Informationen finden Sie unter DNS im virtuellen Cloud-Netzwerk.
Beim Erstellen eines Subnetzes können Sie optional eine Routentabelle für das zu verwendende Subnetz angeben. Andernfalls verwendet das Subnetz die Standardroutentabelle des Cloud-Netzwerks. Sie können jederzeit ändern, welche Routentabelle das Subnetz verwenden soll.
Außerdem können Sie optional eine oder mehrere Sicherheitslisten (maximal fünf) für das zu verwendende Subnetz angeben. Wenn Sie keine Angabe machen, verwendet das Subnetz die Standardsicherheitsliste des Cloud-Netzwerks. Sie können jederzeit ändern, welche Sicherheitsliste das Subnetz verwenden soll. Beachten Sie, dass die Sicherheitsregeln auf Instanzebene durchgesetzt werden, auch wenn die Liste auf Subnetzebene verknüpft ist. Netzwerksicherheitsgruppen bieten eine Alternative zu Sicherheitslisten. Sie ermöglichen es Ihnen, ein Set von Sicherheitsregeln auf ein Set von Ressourcen mit demselben Sicherheitsstatus anstatt auf alle Ressourcen in einem bestimmten Subnetz anzuwenden.
Optional können Sie ein Set von DHCP-Optionen für das zu verwendende Subnetz angeben. Alle Instanzen im Subnetz erhalten die in diesem Set von DHCP-Optionen angegebene Konfiguration. Wenn Sie kein Optionenset angeben, verwendet das Subnetz das Standardset von DHCP-Optionen des Cloud-Netzwerks. Sie können jederzeit ändern, welches Set von DHCP-Optionen das Subnetz verwenden soll.
Um ein Subnetz zu löschen, darf es keine Ressourcen enthalten (keine Instanzen, Load Balancer, OCI-Datenbanksysteme oder verwaiste Mountziele). Weitere Informationen finden Sie unter Subnetze oder VCNs löschen.
Um ein VCN löschen zu können, dürfen die dazugehörigen Subnetze keine Ressourcen enthalten. Außerdem dürfen an das VCN keine Gateways angehängt sein. In der Konsole können Sie den Prozess "Alle löschen" verwenden, nachdem Sie sichergestellt haben, dass die Subnetze leer sind. Siehe VCN löschen.
In den Servicelimits finden Sie eine Liste der jeweiligen Limits sowie Anweisungen dazu, wie Sie eine Erhöhung beantragen.
Erforderliche IAM Policy
Um Oracle Cloud Infrastructure zu verwenden, muss Ihnen ein Administrator in einer Policy Sicherheitszugriff erteilen. Dieser Zugriff ist erforderlich, unabhängig davon, ob Sie die Konsole oder die REST-API mit einem SDK, einer CLI oder einem anderen Tool verwenden. Wenn Sie eine Nachricht erhalten, dass Sie keine Berechtigung haben oder nicht autorisiert sind, fragen Sie den Administrator, welcher Zugriffstyp Ihnen erteilt wurde und in welchem Compartment Sie arbeiten sollen.
Für Administratoren: Weitere Informationen finden Sie unter IAM-Policys für Networking.
Sicherheitszonen
Sicherheitszonen stellen sicher, dass Ihre Cloud-Ressourcen den Sicherheitsrichtlinien von Oracle entsprechen. Wenn ein Vorgang für eine Ressource in einem Sicherheitszonen-Compartment eine Policy für diese Sicherheitszone verletzt, wird der Vorgang abgelehnt.
Die folgenden Sicherheitszonen-Policys beeinflussen Ihre Fähigkeit, VCNs und Subnetze zu verwalten:
- Subnetze in einer Sicherheitszone können nicht öffentlich sein. Alle Subnetze müssen privat sein.
- Sie können ein Subnetz aus einer Sicherheitszone nicht in ein Standard-Compartment verschieben.