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 nicht überschneidende IPv4 CIDR-Blöcke aufweisen, 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 hinzu. 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 durch 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 das 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 mit anderen Subnetzen im VCN nicht überschneiden. Beispiel: 172.16.1.0/24. Mit IPv4-Adressen und 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 weisen immer /64 auf.
Subnetze fungieren als eine Konfigurationseinheit: Alle Instanzen in einem anderen Subnetz verwenden dieselbe Routentabelle sowie Sicherheitslisten und DHCP-Optionen. Weitere Informationen finden Sie unter Standardkomponenten, die ein VCN enthalten.
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.
Sie können sich jede Compute-Instanz als in einem Subnetz befinden. 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, die sich also in einer bestimmten Availability-Domain befinden mussten. Jetzt können Subnetze AD-spezifisch oder regional sein. Sie wählen den Typ beim Erstellen des Subnetzes aus. Beide Arten von Subnetzen können in demselben VCN vorhanden sein. Im folgenden Diagramm sind die Subnetze 1 bis 3 AD-spezifisch und Subnetz 4 regional.
Abgesehen vom Entfernen des AD-Constraints verhalten sich regionale Subnetze genauso wie AD-spezifische Subnetze. Es wird empfohlen, regionale Subnetze zu verwenden, da sie flexibler sind. Sie machen es einfacher, ein VCN effizient in Subnetze zu unterteilen, während sie gleichzeitig für Availability-Domainausfälle konzipiert sind.
Wenn Sie eine Ressource wie eine Compute-Instanz erstellen, entscheiden Sie, in welcher Availability-Domain sich die Ressource befindet. Vom Standpunkt des virtuellen Netzwerks aus müssen Sie auch entscheiden, in welchem VCN und Subnetz sich die Instanz befindet. Sie können entweder ein regionales 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. Regionale Subnetze beinhalten mögliche API-Änderungen. Weitere Informationen finden Sie im Versionshinweis für regionale Subnetze.
Limits für VCN und Subnetz
|
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 beim Arbeiten mit Oracle Cloud Infrastructure-Ressourcen ist das Erstellen eines VCN mit einem oder mehreren Subnetzen. Sie können in der Konsole ganz einfach mit einem einfachen VCN und einigen zugehörigen Ressourcen beginnen, die es Ihnen ermöglichen, eine Verbindung zu einer Instanz herzustellen und diese herzustellen. 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 du nicht sicher bist, welches Compartment du verwenden sollst, konsultiere den Mandantenadministrator.
Sie kann 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 kann optional eine Routentabelle für das zu verwendende Subnetz angegeben werden. Andernfalls verwendet das Subnetz die Standardroutentabelle des Cloud-Netzwerks. Sie können jederzeit ändern, welche Routentabelle das Subnetz verwenden soll.
Darüber hinaus können Sie optional eine oder mehrere Sicherheitslisten für das zu verwendende Subnetz angeben (maximal fünf). 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. Wenn Sie die Konsole verwenden, können Sie mit dem Prozess "Alle löschen" sicherstellen, 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 verwenden zu können, muss ein Administrator Mitglied einer Gruppe sein, der von einem Mandantenadministrator Sicherheitszugriff in einer Policy erteilt wurde. Dieser Zugriff ist unabhängig davon erforderlich, 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 Mandantenadministrator, welcher Zugriffstyp Ihnen erteilt wurde und in welchem Compartment Ihr Zugriff funktioniert.
Für Administratoren: Weitere Informationen finden Sie unter IAM-Policys für Networking.
Sicherheitszonen
Sicherheitszonen stellen sicher, dass Cloud-Ressourcen den Oracle-Sicherheitsgrundsätzen 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 die 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.