Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Cross-VPC Klonen mit Amazon Aurora Angenommen, Sie möchten für den ursprünglichen Cluster und den Klon unterschiedliche Netzwerkzugriffskontrollen festlegen. Sie können beispielsweise durch Klonen eine Kopie eines Aurora-Produktionsclusters in einer anderen VPC für Entwicklung und Tests erstellen. Oder Sie können einen Klon als Teil einer Migration von öffentlichen Subnetzen zu privaten Subnetzen erstellen, um die Datenbanksicherheit zu erhöhen. In den folgenden Abschnitten wird gezeigt, wie die Netzwerkkonfiguration für den Klon so eingerichtet wird, dass der ursprüngliche Cluster und der Klon beide auf dieselben Aurora-Speicherknoten zugreifen können, auch von unterschiedlichen Subnetzen oder unterschiedlichen VPCs aus. Durch die vorherige Überprüfung der Netzwerkressourcen können Fehler beim Klonen vermieden werden, die möglicherweise schwer zu diagnostizieren sind. Wenn Sie nicht wissen, wie Aurora mit VPCs, Subnetzen und DB-Subnetzgruppen interagiert, informieren Sie sich zunächst unter [Amazon VPC und Amazon Aurora](USER_VPC.md). Sie können die Tutorials in diesem Abschnitt durcharbeiten, um diese Art von Ressourcen in der AWS Konsole zu erstellen und zu verstehen, wie sie zusammenpassen. Da die Schritte das Umschalten zwischen den RDS- und EC2-Diensten beinhalten, verwenden die Beispiele AWS CLI-Befehle, um Ihnen zu helfen, zu verstehen, wie Sie solche Operationen automatisieren und die Ausgabe speichern können. **Topics** + [Bevor Sie beginnen](#before-you-begin) + [Sammeln von Informationen über die Netzwerkumgebung](#gathering-information-about-the-network-environment) + [Erstellen von Netzwerkressourcen für den Klon](#creating-network-resources-for-the-clone) + [Erstellen eines Aurora-Klons mit neuen Netzwerkeinstellungen](#creating-an-aurora-clone-with-new-network-settings) + [Verschieben eines Clusters aus öffentlichen Subnetzen in private](#moving-a-cluster-from-public-subnets-to-private-ones) + [End-to-end Beispiel für die Erstellung eines vPC-übergreifenden Klons](#end-to-end-example-of-creating-a-cross-vpc-clone) ## Bevor Sie beginnen Stellen Sie vor dem Einrichten eines VPC-übergreifenden Klons sicher, dass Sie über die folgenden Ressourcen verfügen: + ein Aurora-DB-Cluster, der als Quelle für das Klonen verwendet werden soll. Wenn Sie zum ersten Mal einen Aurora-DB-Cluster erstellen, lesen Sie die Tutorials unter [Erste Schritte mit Amazon Aurora](CHAP_GettingStartedAurora.md), um einen Cluster mit der MySQL- oder der PostgreSQL-Datenbank-Engine einzurichten. + eine zweite VPC, wenn Sie beabsichtigen, einen VPC-übergreifenden Klon zu erstellen. Wenn Sie keine VPC haben, die Sie für den Klon verwenden können, finden Sie weitere Informationen unter [Tutorial: Erstellen einer VPC zur Verwendung mit einem DB-Cluster (nur IPv4)](CHAP_Tutorials.WebServerDB.CreateVPC.md) oder [Tutorial: Erstellen einer VPC zur Verwendung mit einer DB–einem DB-Cluster (Dual-Stack-Modus)](CHAP_Tutorials.CreateVPCDualStack.md). ## Sammeln von Informationen über die Netzwerkumgebung Beim VPC-übergreifenden Klonen kann sich die Netzwerkumgebung zwischen dem ursprünglichen Cluster und seinem Klon erheblich unterscheiden. Bevor Sie den Klon erstellen, sollten Sie Informationen über die VPC, die Subnetze, die DB-Subnetzgruppe und die AZs sammeln und aufzeichnen, die im ursprünglichen Cluster verwendet wurden. Auf diese Weise können Sie die Wahrscheinlichkeit von Problemen minimieren. Wenn ein Netzwerkproblem auftritt, müssen Sie die Aktivitäten zur Problembehandlung nicht unterbrechen, um nach Diagnoseinformationen zu suchen. Die folgenden Abschnitte zeigen CLI-Beispiele zum Sammeln dieser Art von Informationen. Sie können die Details in einem beliebigen Format speichern, auf das Sie bei der Erstellung des Klons und bei der Problembehandlung schnell zugreifen können. + [Schritt 1: Überprüfen der Availability Zones des ursprünglichen Clusters](#cross-vpc-cloning-check-original-azs) + [Schritt 2: Überprüfen der DB-Subnetzgruppe des ursprünglichen Clusters](#cross-vpc-cloning-check-original-subnet-group) + [Schritt 3: Überprüfen der Subnetze des ursprünglichen Clusters](#cross-vpc-cloning-check-original-subnets) + [Schritt 4: Überprüfen Sie der Availability Zones der DB-Instances im ursprünglichen Cluster](#cross-vpc-cloning-check-original-instance-azs) + [Schritt 5: Überprüfen der VPCs, die für den Klon verwendet werden können](#cross-vpc-cloning-check-vpcs) ### Schritt 1: Überprüfen der Availability Zones des ursprünglichen Clusters Bevor Sie den Klon erstellen, überprüfen Sie, welche AZs der ursprüngliche Cluster für seinen Speicher verwendet. Wie unter [Amazon Aurora-Speicher](Aurora.Overview.StorageReliability.md) erklärt, ist der Speicher für jeden Aurora-Cluster genau drei AZs zugeordnet. Da [Amazon-Aurora-DB-Cluster](Aurora.Overview.md) die Trennung zwischen Rechenleistung und Speicher nutzt, gilt diese Regel unabhängig davon, wie viele Instances in dem Cluster enthalten sind. Führen Sie beispielsweise einen CLI-Befehl wie den folgenden aus und ersetzen Sie `{{my_cluster}}` durch den Namen Ihres Clusters. Im folgenden Beispiel wird eine alphabetisch nach dem AZ-Namen sortierte Liste erstellt. ``` aws rds describe-db-clusters \ --db-cluster-identifier {{my_cluster}} \ --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' \ --output text ``` Das folgende Beispiel zeigt eine Beispielausgabe für den vorhergehenden `describe-db-clusters`-Befehl. Es zeigt, dass der Speicher für den Aurora-Cluster immer drei AZs verwendet. ``` us-east-1c us-east-1d us-east-1e ``` Um einen Klon in einer Netzwerkumgebung zu erstellen, die nicht über alle Ressourcen verfügt, um eine Verbindung zu diesen AZs herzustellen, müssen Sie Subnetze erstellen, die mindestens zwei dieser AZs zugeordnet sind. Danach erstellen Sie eine DB-Subnetzgruppe, die diese zwei oder drei Subnetze enthält. In den nachstehenden Beispielen wird die Vorgehensweise dazu veranschaulicht. ### Schritt 2: Überprüfen der DB-Subnetzgruppe des ursprünglichen Clusters Wenn Sie dieselbe Anzahl von Subnetzen für den Klon wie im ursprünglichen Cluster verwenden möchten, können Sie die Anzahl der Subnetze aus der DB-Subnetzgruppe des ursprünglichen Clusters abrufen. Eine Aurora-DB-Subnetzgruppe enthält mindestens zwei Subnetze, die jeweils einer anderen AZ zugeordnet sind. Notieren Sie sich, welchen AZs die Subnetze zugeordnet sind. Das folgende Beispiel zeigt, wie Sie die DB-Subnetzgruppe des ursprünglichen Clusters finden und dann rückwärts zu den entsprechenden AZs arbeiten. Ersetzen Sie `{{my_cluster}}` im ersten Befehl durch den Namen Ihres Clusters. Geben Sie im zweiten Befehl für `{{my_subnet}}` den Namen der DB-Subnetzgruppe an. ``` aws rds describe-db-clusters --db-cluster-identifier {{my_cluster}} \ --query '*[].DBSubnetGroup' --output text aws rds describe-db-subnet-groups --db-subnet-group-name {{my_subnet_group}} \ --query '*[].Subnets[].[SubnetAvailabilityZone.Name]' --output text ``` Die Beispielausgabe könnte für einen Cluster mit einer DB-Subnetzgruppe, die zwei Subnetze enthält, in etwa wie folgt aussehen. In diesem Fall ist `two-subnets` ein Name, der bei der Erstellung der DB-Subnetzgruppe angegeben wurde. ``` two-subnets us-east-1d us-east-1c ``` Für einen Cluster, bei dem die DB-Subnetzgruppe drei Subnetze enthält, könnte die Ausgabe wie folgt aussehen. ``` three-subnets us-east-1f us-east-1d us-east-1c ``` ### Schritt 3: Überprüfen der Subnetze des ursprünglichen Clusters Wenn Sie weitere Informationen zu den Subnetzen im ursprünglichen Cluster benötigen, führen Sie AWS CLI-Befehle aus, die den folgenden ähneln. Sie können die Subnetzattribute wie IP-Adressbereiche, Besitzer usw. untersuchen. Auf diese Weise können Sie bestimmen, ob Sie verschiedene Subnetze in derselben VPC verwenden oder Subnetze mit ähnlichen Eigenschaften in einer anderen VPC erstellen möchten. Suchen Sie die Subnetz-IDs aller Subnetze, die in Ihrer VPC verfügbar sind. ``` aws ec2 describe-subnets --filters Name=vpc-id,Values={{my_vpc}} \ --query '*[].[SubnetId]' --output text ``` Suchen Sie die genauen Subnetze, die in Ihrer DB-Subnetzgruppe verwendet werden. ``` aws rds describe-db-subnet-groups --db-subnet-group-name {{my_subnet_group}} \ --query '*[].Subnets[].[SubnetIdentifier]' --output text ``` Geben Sie dann die Subnetze, die Sie untersuchen möchten, in einer Liste an, wie im folgenden Befehl. Geben Sie die Namen Ihrer Subnetze für `{{my_subnet_1}}` usw. ein. ``` aws ec2 describe-subnets \ --subnet-ids '["{{my_subnet_1}}","{{my_subnet2}}","{{my_subnet3}}"]' ``` Das folgende Beispiel zeigt die teilweise Ausgabe eines solchen `describe-subnets`-Befehls. Die Ausgabe zeigt einige der wichtigen Attribute, die Sie für jedes Subnetz sehen können, z. B. die zugehörige AZ und die VPC, zu der es gehört. ``` { 'Subnets': [ { 'AvailabilityZone': 'us-east-1d', 'AvailableIpAddressCount': 54, 'CidrBlock': '10.0.0.64/26', 'State': 'available', 'SubnetId': 'subnet-000a0bca00e0b0000', 'VpcId': 'vpc-3f3c3fc3333b3ffb3', ... }, { 'AvailabilityZone': 'us-east-1c', 'AvailableIpAddressCount': 55, 'CidrBlock': '10.0.0.0/26', 'State': 'available', 'SubnetId': 'subnet-4b4dbfe4d4a4fd4c4', 'VpcId': 'vpc-3f3c3fc3333b3ffb3', ... ``` ### Schritt 4: Überprüfen Sie der Availability Zones der DB-Instances im ursprünglichen Cluster Sie können dieses Verfahren verwenden, um nachzuvollziehen, welche AZs für die DB-Instances im ursprünglichen Cluster verwendet werden. Auf diese Weise können Sie exakt dieselben AZs für die DB-Instances im Klon einrichten. Sie können auch mehr oder weniger DB-Instances im Klon verwenden, je nachdem, ob der Klon für Produktion, Entwicklung und Tests verwendet wird usw. Führen Sie für jede Instance im ursprünglichen Cluster einen Befehl wie den folgenden aus. Stellen Sie sicher, dass die Instance den Erstellungsvorgang abgeschlossen hat und sich im Status `Available` befindet. Geben Sie die Instance-ID für `{{my_instance}}` ein. ``` aws rds describe-db-instances --db-instance-identifier {{my_instance}} \ --query '*[].AvailabilityZone' --output text ``` Das folgende Beispiel zeigt die Ausgabe nach dem Ausführen des `describe-db-instances`-Befehls. Der Aurora-Cluster hat vier Datenbank-Instances. Daher führen wir den Befehl viermal aus und geben dabei jedes Mal eine andere DB-Instance-ID an. Die Ausgabe zeigt, wie diese DB-Instances auf maximal drei AZs verteilt sind. ``` us-east-1a us-east-1c us-east-1d us-east-1a ``` Wenn der Klon erstellt wurde und Sie ihm DB-Instances hinzufügen, können Sie dieselben AZ-Namen in den `create-db-instance`-Befehlen angeben. Sie können dies tun, um DB-Instances im neuen Cluster einzurichten, die für genau dieselben AZs wie im ursprünglichen Cluster konfiguriert sind. ### Schritt 5: Überprüfen der VPCs, die für den Klon verwendet werden können Wenn Sie beabsichtigen, den Klon in einer anderen VPC als der ursprünglichen zu erstellen, können Sie eine Liste der für Ihr Konto verfügbaren VPC-IDs abrufen. Sie können diesen Schritt auch ausführen, wenn Sie zusätzliche Subnetze in derselben VPC wie der ursprüngliche Cluster erstellen müssen. Wenn Sie den Befehl zum Erstellen eines Subnetzes ausführen, geben Sie die VPC-ID als Parameter an. Führen Sie den folgenden CLI-Befehl aus, um alle VPCs für Ihr Konto aufzuführen: ``` aws ec2 describe-vpcs --query '*[].[VpcId]' --output text ``` Das folgende Beispiel zeigt eine Beispielausgabe für den vorhergehenden `describe-vpcs`-Befehl. Die Ausgabe zeigt, dass das aktuelle AWS Konto vier VPCs enthält, die als Quelle oder Ziel für das VPC-übergreifende Klonen verwendet werden können. ``` vpc-fd111111 vpc-2222e2cd2a222f22e vpc-33333333a33333d33 vpc-4ae4d4de4a4444dad ``` Sie können dieselbe VPC als Ziel für den Klon oder eine andere VPC verwenden. Wenn sich der ursprüngliche Cluster und der Klon in derselben VPC befinden, können Sie dieselbe DB-Subnetzgruppe für den Klon wiederverwenden. Sie können auch eine andere DB-Subnetzgruppe erstellen. Beispielsweise könnte die neue DB-Subnetzgruppe private Subnetze verwenden, während die DB-Subnetzgruppe des ursprünglichen Clusters öffentliche Subnetze verwenden könnte. Wenn Sie den Klon in einer anderen VPC erstellen, stellen Sie sicher, dass in der neuen VPC genügend Subnetze vorhanden sind und dass die Subnetze den richtigen AZs aus dem ursprünglichen Cluster zugeordnet sind. ## Erstellen von Netzwerkressourcen für den Klon Wenn Sie beim Sammeln der Netzwerkinformationen festgestellt haben, dass zusätzliche Netzwerkressourcen für den Klon benötigt werden, können Sie diese Ressourcen erstellen, bevor Sie versuchen, den Klon einzurichten. Beispielsweise müssen Sie möglicherweise mehr Subnetze, bestimmten AZs zugeordnete Subnetze oder eine neue DB-Subnetzgruppe erstellen. + [Schritt 1: Erstellen der Subnetze für den Klon](#cross-vpc-cloning-create-clone-subnets) + [Schritt 2: Erstellen der DB-Subnetzgruppe für den Klon](#cross-vpc-cloning-create-subnet-group) ### Schritt 1: Erstellen der Subnetze für den Klon Wenn Sie neue Subnetze für den Klon erstellen müssen, führen Sie einen Befehl wie den folgenden aus. Möglicherweise müssen Sie dies tun, wenn Sie den Klon in einer anderen VPC erstellen oder wenn Sie eine andere Netzwerkänderung vornehmen und z. B. private Subnetze anstelle von öffentlichen Subnetzen verwenden. AWS generiert automatisch die ID des Subnetzes. Geben Sie den Namen der VPC des Klons für `{{my_vpc}}` ein. Wählen Sie den Adressbereich für die `--cidr-block`-Option so aus, dass mindestens 16 IP-Adressen in dem Bereich zugelassen werden. Sie können alle anderen Eigenschaften einbeziehen, die Sie angeben möchten. Führen Sie den Befehl `aws ec2 create-subnet help` aus, um alle Auswahlmöglichkeiten zu sehen. ``` aws ec2 create-subnet --vpc-id {{my_vpc}} \ --availability-zone {{AZ_name}} --cidr-block {{IP_range}} ``` Das folgende Beispiel zeigt einige wichtige Attribute eines neu erstellten Subnetzes. ``` { 'Subnet': { 'AvailabilityZone': 'us-east-1b', 'AvailableIpAddressCount': 59, 'CidrBlock': '10.0.0.64/26', 'State': 'available', 'SubnetId': 'subnet-44b4a44f4e44db444', 'VpcId': 'vpc-555fc5df555e555dc', ... } } ``` ### Schritt 2: Erstellen der DB-Subnetzgruppe für den Klon Wenn Sie den Klon in einer anderen VPC oder eine andere Gruppe von Subnetzen innerhalb derselben VPC erstellen, erstellen Sie eine neue DB-Subnetzgruppe und geben sie bei der Erstellung des Klons an. Stellen Sie sicher, dass Ihnen alle folgenden Details bekannt sind. Sie können all diese Informationen in der Ausgabe der vorherigen Beispiele finden. 1. VPC des ursprünglichen Clusters. Detaillierte Anweisungen finden Sie unter [Schritt 3: Überprüfen der Subnetze des ursprünglichen Clusters](#cross-vpc-cloning-check-original-subnets). 1. VPC des Klons, wenn Sie ihn in einer anderen VPC erstellen. Detaillierte Anweisungen finden Sie unter [Schritt 5: Überprüfen der VPCs, die für den Klon verwendet werden können](#cross-vpc-cloning-check-vpcs). 1. drei AZs, die dem Aurora-Speicher für den ursprünglichen Cluster zugeordnet sind. Detaillierte Anweisungen finden Sie unter [Schritt 1: Überprüfen der Availability Zones des ursprünglichen Clusters](#cross-vpc-cloning-check-original-azs). 1. zwei oder drei AZs, die der DB-Subnetzgruppe für den ursprünglichen Cluster zugeordnet sind. Detaillierte Anweisungen finden Sie unter [Schritt 2: Überprüfen der DB-Subnetzgruppe des ursprünglichen Clusters](#cross-vpc-cloning-check-original-subnet-group). 1. die Subnetz-IDs und zugehörigen AZs aller Subnetze in der VPC, die Sie für den Klon verwenden möchten. Verwenden Sie denselben `describe-subnets`-Befehl wie in [Schritt 3: Überprüfen der Subnetze des ursprünglichen Clusters](#cross-vpc-cloning-check-original-subnets) und ersetzen Sie dabei die VPC-ID der Ziel-VPC. Prüfen Sie, wie viele AZs sowohl dem Speicher des ursprünglichen Clusters als auch den Subnetzen in der Ziel-VPC zugeordnet sind. Um den Klon erfolgreich zu erstellen, müssen sie zwei oder drei AZs gemeinsam haben. Wenn weniger als zwei gemeinsam verwendete AZs vorhanden sind, gehen Sie zurück zu [Schritt 1: Erstellen der Subnetze für den Klon](#cross-vpc-cloning-create-clone-subnets). Erstellen Sie ein, zwei oder drei neue Subnetze, die den AZs zugeordnet sind, die dem Speicher des ursprünglichen Clusters zugeordnet sind. Wählen Sie Subnetze in der Ziel-VPC aus, die denselben AZs zugeordnet sind wie der Aurora-Speicher im ursprünglichen Cluster. Wählen Sie idealerweise drei AZs aus. Auf diese Weise haben Sie die größte Flexibilität, um die DB-Instances des Klons auf mehrere AZs zu verteilen und so eine hohe Verfügbarkeit der Rechenressourcen zu gewährleisten. Führen Sie einen ähnlichen Befehl wie den folgenden aus, um die neue DB-Subnetzgruppe zu erstellen. Ersetzen Sie die IDs Ihrer Subnetze in der Liste. Wenn Sie die Subnetz-IDs mithilfe von Umgebungsvariablen angeben, achten Sie darauf, die `--subnet-ids`-Parameterliste so in Anführungszeichen zu setzen, dass die IDs weiter in doppelten Anführungszeichen stehen. ``` aws rds create-db-subnet-group --db-subnet-group-name {{my_subnet_group}} \ --subnet-ids '["{{my_subnet_1}}","{{my_subnet_2}}","{{my_subnet3}}"]' \ --db-subnet-group-description 'DB subnet group with 3 subnets for clone' ``` Das folgende Beispiel zeigt teilweise die Ausgabe des Befehls `create-db-subnet-group`. ``` { 'DBSubnetGroup': { 'DBSubnetGroupName': '{{my_subnet_group}}', 'DBSubnetGroupDescription': 'DB subnet group with 3 subnets for clone', 'VpcId': 'vpc-555fc5df555e555dc', 'SubnetGroupStatus': 'Complete', 'Subnets': [ { 'SubnetIdentifier': '{{my_subnet_1}}', 'SubnetAvailabilityZone': { 'Name': 'us-east-1c' }, 'SubnetStatus': 'Active' }, { 'SubnetIdentifier': '{{my_subnet_2}}', 'SubnetAvailabilityZone': { 'Name': 'us-east-1d' }, 'SubnetStatus': 'Active' } ... ], 'SupportedNetworkTypes': [ 'IPV4' ] } } ``` Zu diesem Zeitpunkt haben Sie den Klon noch nicht erstellt. Sie haben alle relevanten VPC- und Subnetzressourcen erstellt, sodass Sie beim Erstellen des Klons die entsprechenden Parameter für die Befehle `restore-db-cluster-to-point-in-time` und `create-db-instance` angeben können. ## Erstellen eines Aurora-Klons mit neuen Netzwerkeinstellungen Sobald Sie sichergestellt haben, dass die richtige Konfiguration von VPCs, Subnetzen, AZs und Subnetzgruppen für den neuen Cluster vorhanden ist, können Sie den eigentlichen Klonvorgang durchführen. In den folgenden CLI-Beispielen werden die Optionen wie `--db-subnet-group-name`, `--availability-zone` und `--vpc-security-group-ids` hervorgehoben, die Sie in den Befehlen zum Einrichten des Klons und seiner DB-Instances angeben. + [Schritt 1: Angeben der DB-Subnetzgruppe für den Klon](#cross-vpc-cloning-specify-clone-subnet-group) + [Schritt 2: Angeben der Netzwerkeinstellungen für Instances im Klon](#cross-vpc-cloning-configure-clone-instance-network) + [Schritt 3: Herstellen der Konnektivität zwischen einem Clientsystem und einem Klon](#cross-vpc-cloning-connect-to-clone) ### Schritt 1: Angeben der DB-Subnetzgruppe für den Klon Wenn Sie den Klon erstellen, können Sie die richtigen VPC-, Subnetz- und AZ-Einstellungen konfigurieren, indem Sie eine DB-Subnetzgruppe angeben. Verwenden Sie die Befehle in den vorherigen Beispielen, um alle Beziehungen und Zuordnungen zu überprüfen, die zur DB-Subnetzgruppe gehören. Die folgenden Befehle veranschaulichen beispielsweise das Klonen eines ursprünglichen Clusters in einen Klon. Im ersten Beispiel ist der Quellcluster mit zwei Subnetzen und der Klon mit drei Subnetzen verknüpft. Das zweite Beispiel zeigt den umgekehrten Fall, nämlich das Klonen von einem Cluster mit drei Subnetzen zu einem Cluster mit zwei Subnetzen. ``` aws rds restore-db-cluster-to-point-in-time \ --source-db-cluster-identifier cluster-with-3-subnets \ --db-cluster-identifier cluster-cloned-to-2-subnets \ --restore-type copy-on-write --use-latest-restorable-time \ --db-subnet-group-name two-subnets ``` Wenn Sie Aurora serverless Instances im Clone verwenden möchten, fügen Sie bei der Erstellung des Clones eine `--serverless-v2-scaling-configuration` Option hinzu, wie in der Abbildung gezeigt. Auf diese Weise können Sie die `db.serverless`-Klasse verwenden, wenn Sie DB-Instances im Klon erstellen. Sie können den Klon auch später ändern, um dieses Attribut für die Skalierungskonfiguration hinzuzufügen. Die Kapazitätszahlen in diesem Beispiel ermöglichen es jeder Aurora serverless Instance im Cluster, zwischen 2 und 32 Aurora Capacity Units (ACUs) zu skalieren. Informationen zu dieser Aurora serverless Funktion und zur Auswahl des Kapazitätsbereichs finden Sie unter[Verwenden von Aurora serverless](aurora-serverless-v2.md). ``` aws rds restore-db-cluster-to-point-in-time \ --source-db-cluster-identifier cluster-with-2-subnets \ --db-cluster-identifier cluster-cloned-to-3-subnets \ --restore-type copy-on-write --use-latest-restorable-time \ --db-subnet-group-name three-subnets \ --serverless-v2-scaling-configuration 'MinCapacity=2,MaxCapacity=32' ``` Unabhängig von der Anzahl der von den DB-Instances verwendeten Subnetze ist der Aurora-Speicher für den Quell-Cluster und den Klon drei AZs zugeordnet. Das folgende Beispiel listet die AZs auf, die sowohl dem ursprünglichen Cluster als auch dem Klon zugeordnet sind, und zwar für beide `restore-db-cluster-to-point-in-time`-Befehle in den vorherigen Beispielen. ``` aws rds describe-db-clusters --db-cluster-identifier cluster-with-3-subnets \ --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' --output text us-east-1c us-east-1d us-east-1f aws rds describe-db-clusters --db-cluster-identifier cluster-cloned-to-2-subnets \ --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' --output text us-east-1c us-east-1d us-east-1f aws rds describe-db-clusters --db-cluster-identifier cluster-with-2-subnets \ --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' --output text us-east-1a us-east-1c us-east-1d aws rds describe-db-clusters --db-cluster-identifier cluster-cloned-to-3-subnets \ --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' --output text us-east-1a us-east-1c us-east-1d ``` Da sich mindestens zwei der AZs zwischen jedem Paar aus Original- und Kloncluster überschneiden, können beide Cluster auf denselben zugrunde liegenden Aurora-Speicher zugreifen. ### Schritt 2: Angeben der Netzwerkeinstellungen für Instances im Klon Wenn Sie DB-Instances im Klon erstellen, erben diese standardmäßig die DB-Subnetzgruppe vom Cluster selbst. Auf diese Weise weist Aurora jede Instance automatisch einem bestimmten Subnetz zu und erstellt sie in der AZ, die dem Subnetz zugeordnet ist. Diese Wahl ist besonders für Entwicklungs- und Testsysteme praktisch, da Sie beim Hinzufügen neuer Instances zum Klon nicht die Subnetz-IDs oder AZs im Auge behalten müssen. Als Alternative können Sie die AZ angeben, wenn Sie eine Aurora-DB-Instance für den Klon erstellen. Die AZ, die Sie angeben, muss aus der Gruppe von AZs stammen, die dem Klon zugeordnet sind. Wenn die DB-Subnetzgruppe, die Sie für den Klon verwenden, nur zwei Subnetze enthält, können Sie nur aus den AZs auswählen, die diesen beiden Subnetzen zugeordnet sind. Diese Wahl bietet Flexibilität und Resilienz für Systeme mit hoher Verfügbarkeit, da Sie sicherstellen können, dass sich die Writer-Instance und die Standby-Reader-Instance in unterschiedlichen AZs befinden. Oder wenn Sie dem Cluster weitere Reader hinzufügen, können Sie sicherstellen, dass diese auf drei AZs verteilt sind. Auf diese Weise haben Sie selbst im seltenen Fall eines AZ-Ausfalls immer noch eine Writer-Instance und eine weitere Reader-Instance in zwei anderen AZs. Das folgende Beispiel fügt einem geklonten Aurora-PostgreSQL-Cluster, der eine benutzerdefinierte DB-Subnetzgruppe verwendet, eine bereitgestellte DB-Instance hinzu. ``` aws rds create-db-instance --db-cluster-identifier {{my_aurora_postgresql_clone}} \ --db-instance-identifier {{my_postgres_instance}} \ --db-subnet-group-name {{my_new_subnet}} \ --engine aurora-postgresql \ --db-instance-class db.t4g.medium ``` Das folgende Beispiel zeigt die teilweise Ausgabe eines solchen Befehls. ``` { 'DBInstanceIdentifier': '{{my_postgres_instance}}', 'DBClusterIdentifier': '{{my_aurora_postgresql_clone}}', 'DBInstanceClass': 'db.t4g.medium', 'DBInstanceStatus': 'creating' ... } ``` Das folgende Beispiel fügt einem Aurora MySQL-Klon, der eine benutzerdefinierte Aurora serverless DB-Subnetzgruppe verwendet, eine DB-Instance hinzu. Um Aurora serverless Instances verwenden zu können, stellen Sie sicher, dass Sie die `--serverless-v2-scaling-configuration` Option für den `restore-db-cluster-to-point-in-time` Befehl angeben, wie in den vorherigen Beispielen gezeigt. ``` aws rds create-db-instance --db-cluster-identifier {{my_aurora_mysql_clone}} \ --db-instance-identifier {{my_mysql_instance}} \ --db-subnet-group-name {{my_other_new_subnet}} \ --engine aurora-mysql \ --db-instance-class db.serverless ``` Das folgende Beispiel zeigt die teilweise Ausgabe eines solchen Befehls. ``` { 'DBInstanceIdentifier': '{{my_mysql_instance}}', 'DBClusterIdentifier': '{{my_aurora_mysql_clone}}', 'DBInstanceClass': 'db.serverless', 'DBInstanceStatus': 'creating' ... } ``` ### Schritt 3: Herstellen der Konnektivität zwischen einem Clientsystem und einem Klon Wenn Sie bereits von einem Clientsystem aus eine Verbindung zu einem Aurora-Cluster herstellen, sollten Sie dieselbe Art von Konnektivität für einen neuen Klon zulassen. Beispielsweise können Sie über eine Amazon-Cloud9-Instance oder EC2-Instance eine Verbindung mit dem ursprünglichen Cluster herstellen. Um Verbindungen von denselben oder neuen Clientsystemen, die Sie in der Ziel-VPC erstellen, zuzulassen, richten Sie äquivalente DB-Subnetzgruppen und VPC-Sicherheitsgruppen wie in der VPC ein. Geben Sie dann die Subnetzgruppe und die Sicherheitsgruppen an, wenn Sie den Klon erstellen. In den folgenden Beispielen wird ein Aurora serverless Clone eingerichtet. Diese Konfiguration basiert auf der Kombination von `--engine-mode provisioned` und `--serverless-v2-scaling-configuration` bei der Erstellung des DB-Clusters und dann `--db-instance-class db.serverless` bei der Erstellung der einzelnen DB-Instances im Cluster. Der Engine-Modus `provisioned` ist die Standardeinstellung, sodass Sie diese Option auch weglassen können, wenn Sie dies bevorzugen. ``` aws rds restore-db-cluster-to-point-in-time \ --source-db-cluster-identifier serverless-sql-postgres\ --db-cluster-identifier serverless-sql-postgres-clone \ --db-subnet-group-name 'default-vpc-1234' \ --vpc-security-group-ids 'sg-4567' \ --serverless-v2-scaling-configuration 'MinCapacity=0.5,MaxCapacity=16' \ --restore-type copy-on-write \ --use-latest-restorable-time ``` Geben Sie dann beim Erstellen der DB-Instances im Klon dieselbe `--db-subnet-group-name`-Option an. Optional können Sie die `--availability-zone`-Option einschließen und eine der AZs angeben, die den Subnetzen in dieser Subnetzgruppe zugeordnet sind. Diese AZ muss auch eine der AZs sein, die dem ursprünglichen Cluster zugeordnet sind. ``` aws rds create-db-instance \ --db-cluster-identifier serverless-sql-postgres-clone \ --db-instance-identifier serverless-sql-postgres-clone-instance \ --db-instance-class db.serverless \ --db-subnet-group-name 'default-vpc-987zyx654' \ --availability-zone 'us-east-1c' \ --engine aurora-postgresql ``` ## Verschieben eines Clusters aus öffentlichen Subnetzen in private Mithilfe des Klonens können Sie einen Cluster zwischen öffentlichen und privaten Subnetzen migrieren. Sie können dies tun, wenn Sie Ihrer Anwendung zusätzliche Sicherheitsebenen hinzufügen, bevor Sie sie in der Produktion einsetzen. In diesem Beispiel sollten Sie die privaten Subnetze und das NAT-Gateway bereits eingerichtet haben, bevor Sie den Klonvorgang mit Aurora starten. Für die Schritte, an denen Aurora beteiligt ist, können Sie dieselben allgemeinen Schritte wie in den vorherigen Beispielen für [Sammeln von Informationen über die Netzwerkumgebung](#gathering-information-about-the-network-environment) und [Erstellen eines Aurora-Klons mit neuen Netzwerkeinstellungen](#creating-an-aurora-clone-with-new-network-settings) befolgen. Der Hauptunterschied besteht darin, dass Sie, selbst wenn Sie über öffentliche Subnetze verfügen, die allen AZs des ursprünglichen Clusters zugeordnet sind, jetzt überprüfen müssen, ob Sie über genügend private Subnetze für einen Aurora-Cluster verfügen. Außerdem müssen diese Subnetze allen AZs zugeordnet sein, die für Aurora-Speicher im ursprünglichen Cluster verwendet werden. Ähnlich wie bei anderen Anwendungsfällen des Klonens können Sie die DB-Subnetzgruppe für den Klon entweder mit drei oder zwei privaten Subnetzen erstellen, die den erforderlichen AZs zugeordnet sind. Wenn Sie jedoch zwei private Subnetze in der DB-Subnetzgruppe verwenden, benötigen Sie ein drittes privates Subnetz, das der dritten AZ zugeordnet ist, die für Aurora-Speicher im ursprünglichen Cluster verwendet wird. Anhand dieser Checkliste können Sie überprüfen, ob alle Voraussetzungen für diese Art von Klonvorgang erfüllt sind. + Notieren Sie die drei AZs, die dem ursprünglichen Cluster zugeordnet sind. Detaillierte Anweisungen finden Sie unter [Schritt 1: Überprüfen der Availability Zones des ursprünglichen Clusters](#cross-vpc-cloning-check-original-azs). + Notieren Sie die drei oder zwei AZs, die den öffentlichen Subnetzen in der DB-Subnetzgruppe für den ursprünglichen Cluster zugeordnet sind. Detaillierte Anweisungen finden Sie unter [Schritt 3: Überprüfen der Subnetze des ursprünglichen Clusters](#cross-vpc-cloning-check-original-subnets). + Erstellen Sie private Subnetze, die allen drei AZs zugeordnet sind, die dem ursprünglichen Cluster zugeordnet sind. Führen Sie außerdem alle anderen Schritte zur Netzwerkeinrichtung durch, z. B. die Einrichtung eines NAT-Gateways, um mit den privaten Subnetzen kommunizieren zu können. Eine ausführliche Anleitung finden Sie unter [Erstellen eines Subnetzes](https://docs.aws.amazon.com/vpc/latest/userguide/create-subnets.html) im *Benutzerhandbuch für Amazon Virtual Private Cloud*. + Erstellen Sie eine neue DB-Subnetzgruppe, die drei oder zwei der privaten Subnetze enthält, die den AZs aus dem ersten Punkt zugeordnet sind. Detaillierte Anweisungen finden Sie unter [Schritt 2: Erstellen der DB-Subnetzgruppe für den Klon](#cross-vpc-cloning-create-subnet-group). Wenn alle Voraussetzungen erfüllt sind, können Sie die Datenbankaktivität auf dem ursprünglichen Cluster pausieren, während Sie den Klon erstellen, und Ihre Anwendung auf die Verwendung des Klons umstellen. Nachdem der Klon erstellt wurde und Sie sich vergewissert haben, dass eine Verbindung dazu hergestellt werden kann, Sie Ihren Anwendungscode ausführen können usw., können Sie die Verwendung des ursprünglichen Clusters einstellen. ## End-to-end Beispiel für die Erstellung eines vPC-übergreifenden Klons Beim Erstellen eines Klons in einer anderen VPC als dem Original werden dieselben allgemeinen Schritte wie in den vorherigen Beispielen ausgeführt. Da die VPC-ID eine Eigenschaft der Subnetze ist, geben Sie die VPC-ID nicht als Parameter an, wenn Sie einen der RDS-CLI-Befehle ausführen. Der Hauptunterschied besteht darin, dass Sie mit größerer Wahrscheinlichkeit neue Subnetze, neue Subnetze, die bestimmten AZs zugeordnet sind, eine VPC-Sicherheitsgruppe und eine neue DB-Subnetzgruppe erstellen müssen. Dies gilt insbesondere, wenn dies der erste Aurora-Cluster ist, den Sie in dieser VPC erstellen. Anhand dieser Checkliste können Sie überprüfen, ob alle Voraussetzungen für diese Art von Klonvorgang erfüllt sind. + Notieren Sie die drei AZs, die dem ursprünglichen Cluster zugeordnet sind. Detaillierte Anweisungen finden Sie unter [Schritt 1: Überprüfen der Availability Zones des ursprünglichen Clusters](#cross-vpc-cloning-check-original-azs). + Notieren Sie die drei oder zwei AZs, die den Subnetzen in der DB-Subnetzgruppe für den ursprünglichen Cluster zugeordnet sind. Detaillierte Anweisungen finden Sie unter [Schritt 2: Überprüfen der DB-Subnetzgruppe des ursprünglichen Clusters](#cross-vpc-cloning-check-original-subnet-group). + Erstellen Sie Subnetze, die allen drei AZs zugeordnet sind, die dem ursprünglichen Cluster zugeordnet sind. Detaillierte Anweisungen finden Sie unter [Schritt 1: Erstellen der Subnetze für den Klon](#cross-vpc-cloning-create-clone-subnets). + Führen Sie weitere Schritte für die Netzwerkeinrichtung, z. B. die Einrichtung einer VPC-Sicherheitsgruppe, für Clientsysteme, Anwendungsserver usw. aus, um mit den DB-Instances im Klon kommunizieren zu können. Detaillierte Anweisungen finden Sie unter [Zugriffskontrolle mit Sicherheitsgruppen](Overview.RDSSecurityGroups.md). + Erstellen Sie eine neue DB-Subnetzgruppe, die drei oder zwei der Subnetze enthält, die den AZs aus dem ersten Punkt zugeordnet sind. Detaillierte Anweisungen finden Sie unter [Schritt 2: Erstellen der DB-Subnetzgruppe für den Klon](#cross-vpc-cloning-create-subnet-group). Wenn alle Voraussetzungen erfüllt sind, können Sie die Datenbankaktivität auf dem ursprünglichen Cluster pausieren, während Sie den Klon erstellen, und Ihre Anwendung auf die Verwendung des Klons umstellen. Nachdem der Klon erstellt wurde und Sie sich vergewissert haben, dass eine Verbindung dazu hergestellt werden kann, Sie Ihren Anwendungscode ausführen können usw., können Sie entscheiden, ob sowohl der ursprüngliche Cluster als auch die Klone ausgeführt werden sollen, oder die Ausführung des ursprünglichen Clusters einstellen. Die folgenden Linux-Beispiele zeigen die Reihenfolge der AWS CLI-Operationen zum Klonen eines Aurora-DB-Clusters von einer VPC auf eine andere. Einige Felder, die für die Beispiele nicht relevant sind, werden in der Befehlsausgabe nicht angezeigt. Zunächst überprüfen wir die IDs der Quell- und Ziel-VPCs. Der beschreibende Name, den Sie einer VPC bei ihrer Erstellung zuweisen, wird in den VPC-Metadaten als Tag dargestellt. ``` $ aws ec2 describe-vpcs --query '*[].[VpcId,Tags]' [ [ 'vpc-0f0c0fc0000b0ffb0', [ { 'Key': 'Name', 'Value': 'clone-vpc-source' } ] ], [ 'vpc-9e99d9f99a999bd99', [ { 'Key': 'Name', 'Value': 'clone-vpc-dest' } ] ] ] ``` Der ursprüngliche Cluster ist bereits in der Quell-VPC vorhanden. Um den Klon mit demselben Satz von AZs für den Aurora-Speicher einzurichten, überprüfen wir die AZs, die vom ursprünglichen Cluster verwendet werden. ``` $ aws rds describe-db-clusters --db-cluster-identifier original-cluster \ --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' --output text us-east-1c us-east-1d us-east-1f ``` Wir stellen sicher, dass Subnetze vorhanden sind, die den vom ursprünglichen Cluster verwendeten AZs entsprechen: `us-east-1c`, `us-east-1d` und `us-east-1f`. ``` $ aws ec2 create-subnet --vpc-id vpc-9e99d9f99a999bd99 \ --availability-zone us-east-1c --cidr-block 10.0.0.128/28 { 'Subnet': { 'AvailabilityZone': 'us-east-1c', 'SubnetId': 'subnet-3333a33be3ef3e333', 'VpcId': 'vpc-9e99d9f99a999bd99', } } $ aws ec2 create-subnet --vpc-id vpc-9e99d9f99a999bd99 \ --availability-zone us-east-1d --cidr-block 10.0.0.160/28 { 'Subnet': { 'AvailabilityZone': 'us-east-1d', 'SubnetId': 'subnet-4eeb444cd44b4d444', 'VpcId': 'vpc-9e99d9f99a999bd99', } } $ aws ec2 create-subnet --vpc-id vpc-9e99d9f99a999bd99 \ --availability-zone us-east-1f --cidr-block 10.0.0.224/28 { 'Subnet': { 'AvailabilityZone': 'us-east-1f', 'SubnetId': 'subnet-66eea6666fb66d66c', 'VpcId': 'vpc-9e99d9f99a999bd99', } } ``` Dieses Beispiel bestätigt, dass es Subnetze gibt, die den erforderlichen AZs in der Ziel-VPC zugeordnet sind. ``` aws ec2 describe-subnets --query 'sort_by(*[] | [?VpcId == `vpc-9e99d9f99a999bd99`] | [].{SubnetId:SubnetId,VpcId:VpcId,AvailabilityZone:AvailabilityZone}, &AvailabilityZone)' --output table --------------------------------------------------------------------------- | DescribeSubnets | +------------------+----------------------------+-------------------------+ | AvailabilityZone | SubnetId | VpcId | +------------------+----------------------------+-------------------------+ | us-east-1a | subnet-000ff0e00000c0aea | vpc-9e99d9f99a999bd99 | | us-east-1b | subnet-1111d111111ca11b1 | vpc-9e99d9f99a999bd99 | | us-east-1c | subnet-3333a33be3ef3e333 | vpc-9e99d9f99a999bd99 | | us-east-1d | subnet-4eeb444cd44b4d444 | vpc-9e99d9f99a999bd99 | | us-east-1f | subnet-66eea6666fb66d66c | vpc-9e99d9f99a999bd99 | +------------------+----------------------------+-------------------------+ ``` Bevor Sie einen Aurora-DB-Cluster in der VPC erstellen, benötigen Sie eine DB-Subnetzgruppe mit Subnetzen, die den für Aurora-Speicher verwendeten AZs zugeordnet sind. Wenn Sie einen regulären Cluster erstellen, können Sie einen beliebigen Satz von drei AZs verwenden. Wenn Sie einen vorhandenen Cluster klonen, muss die Subnetzgruppe mit mindestens zwei der drei AZs übereinstimmen, die für Aurora-Speicher verwendet werden. ``` $ aws rds create-db-subnet-group \ --db-subnet-group-name subnet-group-in-other-vpc \ --subnet-ids '["subnet-3333a33be3ef3e333","subnet-4eeb444cd44b4d444","subnet-66eea6666fb66d66c"]' \ --db-subnet-group-description 'DB subnet group with 3 subnets: subnet-3333a33be3ef3e333,subnet-4eeb444cd44b4d444,subnet-66eea6666fb66d66c' { 'DBSubnetGroup': { 'DBSubnetGroupName': 'subnet-group-in-other-vpc', 'DBSubnetGroupDescription': 'DB subnet group with 3 subnets: subnet-3333a33be3ef3e333,subnet-4eeb444cd44b4d444,subnet-66eea6666fb66d66c', 'VpcId': 'vpc-9e99d9f99a999bd99', 'SubnetGroupStatus': 'Complete', 'Subnets': [ { 'SubnetIdentifier': 'subnet-4eeb444cd44b4d444', 'SubnetAvailabilityZone': { 'Name': 'us-east-1d' } }, { 'SubnetIdentifier': 'subnet-3333a33be3ef3e333', 'SubnetAvailabilityZone': { 'Name': 'us-east-1c' } }, { 'SubnetIdentifier': 'subnet-66eea6666fb66d66c', 'SubnetAvailabilityZone': { 'Name': 'us-east-1f' } } ] } } ``` Jetzt sind die Subnetze und die DB-Subnetzgruppe eingerichtet. Das folgende Beispiel zeigt `restore-db-cluster-to-point-in-time`, womit der Cluster geklont wird. Die `--db-subnet-group-name`-Option ordnet den Klon dem richtigen Satz von Subnetzen zu, die wiederum dem richtigen Satz von AZs aus dem ursprünglichen Cluster zugeordnet sind. ``` $ aws rds restore-db-cluster-to-point-in-time \ --source-db-cluster-identifier original-cluster \ --db-cluster-identifier clone-in-other-vpc \ --restore-type copy-on-write --use-latest-restorable-time \ --db-subnet-group-name subnet-group-in-other-vpc { 'DBClusterIdentifier': 'clone-in-other-vpc', 'DBSubnetGroup': 'subnet-group-in-other-vpc', 'Engine': 'aurora-postgresql', 'EngineVersion': '15.4', 'Status': 'creating', 'Endpoint': 'clone-in-other-vpc.cluster-c0abcdef.us-east-1.rds.amazonaws.com' } ``` Im folgenden Beispiel wird bestätigt, dass der Aurora-Speicher im Klon denselben Satz von AZs wie im ursprünglichen Cluster verwendet. ``` $ aws rds describe-db-clusters --db-cluster-identifier clone-in-other-vpc \ --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' --output text us-east-1c us-east-1d us-east-1f ``` Nun können Sie DB-Instances für den Klon erstellen. Stellen Sie sicher, dass die jeder Instance zugeordnete VPC-Sicherheitsgruppe Verbindungen aus den IP-Adressbereichen zulässt, die Sie für die EC2-Instances, Anwendungsserver usw. in der Ziel-VPC verwenden.