Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Clonazione tra VPC con Amazon Aurora

Supponiamo di voler imporre controlli degli accessi alla rete differenti sul cluster originale e sul clone. Ad esempio, è possibile utilizzare la clonazione per creare una copia di un cluster Aurora di produzione in un VPC diverso per lo sviluppo e il test. In alternativa, potresti creare un clone nell’ambito di una migrazione da sottoreti pubbliche a sottoreti private, per migliorare la sicurezza del database.

Le sezioni seguenti mostrano come configurare la configurazione di rete per il clone in modo che il cluster originale e il clone possano entrambi accedere agli stessi nodi di archiviazione Aurora, anche da sottoreti diverse o diverse. VPCs La verifica preventiva delle risorse di rete può evitare errori durante la clonazione che potrebbero essere difficili da diagnosticare.

Se non conosci il modo in cui Aurora interagisce con le sottoreti e i VPCs gruppi di sottoreti DB, consulta prima. VPC Amazon e Amazon Aurora Puoi seguire i tutorial in quella sezione per creare questo tipo di risorse nella AWS console e capire come si integrano tra loro.

Poiché i passaggi prevedono il passaggio tra i servizi RDS ed EC2, gli esempi utilizzano i comandi AWS CLI per aiutarti a capire come automatizzare tali operazioni e salvare l'output.

Prima di iniziare

Prima di iniziare a configurare un clone tra VPC, assicurati di disporre delle seguenti risorse:

Raccolta delle informazioni sull’ambiente di rete

Con la clonazione tra VPC, l’ambiente di rete può avere differenze sostanziali tra il cluster originale e il relativo clone. Prima di creare il clone, raccogli e registra informazioni sul VPC, sulle sottoreti, sul gruppo di sottoreti DB AZs e sull'utilizzo nel cluster originale. In questo modo, puoi ridurre al minimo la possibilità di incorrere in problemi. Se si verifica un problema di rete, non sarà necessario interrompere alcuna attività di risoluzione dei problemi per cercare informazioni diagnostiche. Le sezioni seguenti mostrano esempi dell’interfaccia CLI per raccogliere questo tipo di informazioni. È possibile salvare i dettagli nel formato più comodo da consultare durante la creazione del clone e la risoluzione dei problemi.

Fase 1: verificare le zone di disponibilità del cluster originale

Prima di creare il clone, verificate quale tipo di archiviazione viene utilizzato AZs dal cluster originale. Come spiegato inArchiviazione Amazon Aurora, lo storage per ogni cluster Aurora è associato esattamente a tre. AZs Poiché Cluster database Amazon Aurora sfrutta la separazione tra calcolo e archiviazione, questa regola è valida indipendentemente dal numero di istanze presenti nel cluster.

Ad esempio, puoi eseguire un comando dell’interfaccia CLI come il seguente, sostituendo il nome del tuo cluster con my_cluster. Nell’esempio seguente viene generato un elenco ordinato alfabeticamente in base al nome della AZ.

aws rds describe-db-clusters \
  --db-cluster-identifier my_cluster \
  --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' \
  --output text

Di seguito è riportato l’output di esempio del comando describe-db-clusters precedente. Dimostra che lo storage per il cluster Aurora ne utilizza sempre tre. AZs

us-east-1c
us-east-1d
us-east-1e

Per creare un clone in un ambiente di rete che non dispone di tutte le risorse necessarie per connettersi a tali sottoreti AZs, è necessario creare sottoreti associate ad almeno due di queste e quindi creare un gruppo di sottoreti DB contenente queste AZs due o tre sottoreti. Negli esempi seguenti viene mostrato come fare.

Fase 2: verificare il gruppo di sottoreti di database del cluster originale

Se desideri utilizzare per il clone lo stesso numero di sottoreti del cluster originale, puoi ottenere il numero di sottoreti dal gruppo di sottoreti di database del cluster originale. Un gruppo di sottoreti di database Aurora contiene almeno due sottoreti, ciascuna associata a una AZ diversa. Prendi nota a quali AZs sottoreti sono associate.

L'esempio seguente mostra come trovare il gruppo di sottoreti DB del cluster originale e quindi tornare al gruppo corrispondente. AZs Sostituisci il nome del cluster con my_cluster nel primo comando. Sostituire il nome del gruppo di sottoreti di database con my_subnet nel secondo comando.

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

L’output di esempio potrebbe essere simile al seguente, per un cluster con un gruppo di sottoreti di database contenente due sottoreti. In questo caso, two-subnets è un nome specificato durante la creazione del gruppo di sottoreti di database.

two-subnets

us-east-1d
us-east-1c

L’output potrebbe essere simile al seguente, per un cluster con un gruppo di sottoreti di database contenente tre sottoreti.

three-subnets

us-east-1f
us-east-1d
us-east-1c

Fase 3: verificare le sottoreti del cluster originale

Se hai bisogno di maggiori dettagli sulle sottoreti nel cluster originale, esegui comandi AWS CLI simili ai seguenti. Puoi esaminare gli attributi delle sottoreti come gli intervalli di indirizzi IP, il proprietario e così via. In questo modo, puoi determinare se utilizzare sottoreti diverse nello stesso VPC o creare sottoreti con caratteristiche simili in un VPC diverso.

Trova la sottorete IDs di tutte le sottoreti disponibili nel tuo VPC.

aws ec2 describe-subnets --filters Name=vpc-id,Values=my_vpc \
  --query '*[].[SubnetId]' --output text

Trova le sottoreti utilizzate nel gruppo di sottoreti di database.

aws rds describe-db-subnet-groups --db-subnet-group-name my_subnet_group \
  --query '*[].Subnets[].[SubnetIdentifier]' --output text

Quindi specifica le sottoreti che desideri esaminare in un elenco, come nel comando seguente. Sostituisci i nomi delle tue sottoreti con my_subnet_1 e così via.

aws ec2 describe-subnets \
  --subnet-ids '["my_subnet_1","my_subnet2","my_subnet3"]'

L’esempio seguente mostra l’output parziale del comando describe-subnets. L’output mostra alcuni degli attributi importanti che puoi vedere per ogni sottorete, come la AZ associata e il VPC di cui fa parte.

{
    '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',
            ...

Fase 4: verificare le zone di disponibilità delle istanze database nel cluster originale

È possibile utilizzare questa procedura per comprendere le istanze DB AZs utilizzate nel cluster originale. In questo modo, puoi configurare esattamente lo stesso AZs per le istanze DB nel clone. Inoltre, puoi utilizzare più o meno istanze database nel clone a seconda che il clone venga utilizzato per la produzione, lo sviluppo e il test e così via.

Per ogni istanza del cluster originale, esegui un comando come quello riportato di seguito. Verifica che l’istanza abbia terminato la creazione e che si trovi prima nello stato Available. Sostituisci l’identificatore dell’istanza con my_instance.

aws rds describe-db-instances --db-instance-identifier my_instance \
  --query '*[].AvailabilityZone' --output text

L’esempio seguente mostra l’output dell’esecuzione del comando describe-db-instances precedente. Il cluster Aurora dispone di quattro istanze database. Pertanto, il comando deve essere eseguito quattro volte, sostituendo ogni volta un identificatore di istanza database diverso. L'output mostra come tali istanze DB sono distribuite su un massimo di tre. AZs

us-east-1a
us-east-1c
us-east-1d
us-east-1a

Dopo aver creato il clone e avervi aggiunto delle istanze database, puoi specificare gli stessi nomi delle AZ nei comandi create-db-instance. È possibile farlo per configurare le istanze DB nel nuovo cluster configurato esattamente AZs come nel cluster originale.

Passaggio 5: verifica VPCs che puoi utilizzare per il clone

Se intendi creare il clone in un VPC diverso da quello originale, puoi ottenere un elenco dei IDs VPC disponibili per il tuo account. Puoi eseguire questa fase anche se è necessario creare eventuali sottoreti aggiuntive nello stesso VPC del cluster originale. Quando esegui il comando per creare una sottorete, devi specificare l’ID VPC come parametro.

Per elencare tutti i VPCs dati del tuo account, esegui il seguente comando CLI:

aws ec2 describe-vpcs --query '*[].[VpcId]' --output text

Di seguito è riportato l’output di esempio del comando describe-vpcs precedente. L'output dimostra che ce ne sono quattro VPCs nell' AWS account corrente che possono essere utilizzati come origine o destinazione per la clonazione tra VPC.

vpc-fd111111
vpc-2222e2cd2a222f22e
vpc-33333333a33333d33
vpc-4ae4d4de4a4444dad

Come destinazione del clone puoi utilizzare lo stesso VPC o un VPC diverso. Se il cluster originale e il clone si trovano nello stesso VPC, puoi riutilizzare lo stesso gruppo di sottoreti di database per il clone. Puoi anche creare un gruppo di sottoreti di database. Ad esempio, il nuovo gruppo di sottoreti di database potrebbe utilizzare sottoreti private, mentre il gruppo di sottoreti di database del cluster originale potrebbe utilizzare sottoreti pubbliche. Se crei il clone in un VPC diverso, assicurati che ci siano abbastanza sottoreti nel nuovo VPC e che le sottoreti siano associate al diritto del cluster originale. AZs

Creazione di risorse di rete per il clone

Se durante la raccolta delle informazioni di rete hai scoperto che per il clone sono necessarie risorse di rete aggiuntive, puoi creare tali risorse prima di provare a configurare il clone. Ad esempio, potrebbe essere necessario creare più sottoreti, sottoreti associate a sottoreti specifiche o un nuovo gruppo di sottoreti DB. AZs

Fase 1: creare le sottoreti per il clone

Se devi creare nuove sottoreti per il clone, esegui un comando simile al seguente. Potresti dover eseguire questa operazione quando crei il clone in un VPC diverso o quando apporti altre modifiche alla rete, ad esempio l’utilizzo di sottoreti private anziché di sottoreti pubbliche.

AWS genera automaticamente l'ID della sottorete. Sostituisci il nome del VPC del clone con my_vpc. Scegli l’intervallo di indirizzi per l’opzione --cidr-block al fine di consentire almeno 16 indirizzi IP nell’intervallo. Puoi includere qualsiasi altra proprietà che desideri specificare. Esegui il comando aws ec2 create-subnet help per visualizzare tutte le scelte.

aws ec2 create-subnet --vpc-id my_vpc \
  --availability-zone AZ_name --cidr-block IP_range

L’esempio seguente mostra alcuni attributi importanti di una sottorete appena creata.

{
    'Subnet': {
        'AvailabilityZone': 'us-east-1b',
        'AvailableIpAddressCount': 59,
        'CidrBlock': '10.0.0.64/26',
        'State': 'available',
        'SubnetId': 'subnet-44b4a44f4e44db444',
        'VpcId': 'vpc-555fc5df555e555dc',
        ...
        }
}

Fase 2: creare il gruppo di sottoreti di database per il clone

Se stai creando il clone in un VPC diverso o un diverso set di sottoreti all’interno dello stesso VPC, devi creare un nuovo gruppo di sottoreti di database e specificarlo durante la creazione del clone.

Assicurati di conoscere tutti i seguenti dettagli. Puoi trovarli tutti nell’output degli esempi precedenti.

Verifica quanti AZs sono entrambi associati allo storage del cluster originale e associati alle sottoreti nel VPC di destinazione. Per creare correttamente il clone, devono esserci due o tre elementi in comune. AZs Se ne avete meno di due AZs in comune, tornate aFase 1: creare le sottoreti per il clone. Crea una, due o tre nuove sottoreti associate all'archiviazione AZs associata al cluster originale.

Scegli le sottoreti nel VPC di destinazione che sono associate allo stesso storage Aurora AZs nel cluster originale. Idealmente, scegline tre. AZs In questo modo avrai la massima flessibilità per distribuire le istanze DB del clone su più istanze AZs per un'elevata disponibilità delle risorse di elaborazione.

Esegui un comando simile al seguente per creare il nuovo gruppo di sottoreti di database. Sostituisci le tue IDs sottoreti nell'elenco. Se specificate la sottorete IDs utilizzando variabili di ambiente, fate attenzione a citare l'elenco dei --subnet-ids parametri in modo da conservare le virgolette doppie intorno a. IDs

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'

L’esempio seguente mostra l’output parziale del comando 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'
        ]
    }
}

A questo punto, non hai ancora creato il clone. Sono state create tutte le risorse di VPC e sottorete pertinenti in modo da poter specificare i parametri appropriati per i comandi restore-db-cluster-to-point-in-time e create-db-instance durante la creazione del clone.

Creazione di un clone Aurora con nuove impostazioni di rete

Dopo aver verificato che sia disponibile la configurazione corretta di VPCs sottoreti e gruppi di sottoreti per l'utilizzo del nuovo cluster AZs, è possibile eseguire l'operazione di clonazione effettiva. I seguenti esempi CLI evidenziano le opzioni come --db-subnet-group-name, --availability-zone e --vpc-security-group-ids che specifichi nei comandi per configurare il clone e le relative istanze database.

Fase 1: specificare il gruppo di sottoreti di database per il clone

Quando crei il clone, puoi configurare tutte le impostazioni corrette per VPC, sottoreti e AZ specificando un gruppo di sottoreti di database. Utilizza i comandi degli esempi precedenti per verificare tutte le relazioni e le mappature che entrano nel gruppo di sottoreti di database.

Ad esempio, i comandi seguenti mostrano la clonazione di un cluster originale in un clone. Nel primo esempio, il cluster di origine è associato a due sottoreti e il clone è associato a tre sottoreti. Il secondo esempio mostra il caso opposto, ossia la clonazione da un cluster con tre sottoreti a un cluster con due sottoreti.

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

Se intendi utilizzare istanze Aurora Serverless v2 nel clone, includi un’opzione --serverless-v2-scaling-configuration quando crei il clone, come mostrato. In questo modo, puoi utilizzare la classe db.serverless durante la creazione di istanze database nel clone. Puoi anche modificare il clone in un secondo momento per aggiungere questo attributo di configurazione del dimensionamento. I numeri di capacità in questo esempio consentono a ciascuna istanza Serverless v2 nel cluster di scalare tra 2 e 32 unità di capacità Aurora (). ACUs Per informazioni sulla funzionalità di Aurora Serverless v2 e su come scegliere l’intervallo di capacità, consulta Uso di Aurora Serverless v2.

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'

Indipendentemente dal numero di sottoreti utilizzate dalle istanze DB, lo storage Aurora per il cluster di origine e il clone è associato a tre. AZs L'esempio seguente elenca i AZs comandi associati sia al cluster originale che al clone, per entrambi i comandi degli restore-db-cluster-to-point-in-time esempi precedenti.

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

Poiché almeno due dei cluster AZs si sovrappongono tra ogni coppia di cluster originali e cloni, entrambi i cluster possono accedere allo stesso storage Aurora sottostante.

Fase 2: specificare le impostazioni di rete per le istanze nel clone

Quando crei istanze database nel clone, per impostazione predefinita queste ereditano il gruppo di sottoreti di database dal cluster stesso. In questo modo, Aurora assegna automaticamente ogni istanza a una specifica sottorete e la crea nella AZ associata alla sottorete. Questa scelta è utile, soprattutto per i sistemi di sviluppo e test, perché non è necessario tenere traccia della sottorete IDs o AZs durante l'aggiunta di nuove istanze al clone.

In alternativa, puoi specificare la AZ quando crei un’istanza database Aurora per il clone. L'AZ che specificate deve appartenere all'insieme di AZs quelli associati al clone. Se il gruppo di sottoreti DB che usi per il clone contiene solo due sottoreti, puoi scegliere solo tra quelle AZs associate a quelle due sottoreti. Questa scelta offre flessibilità e resilienza per sistemi ad alta disponibilità, perché potete assicurarvi che l'istanza writer e l'istanza standby reader siano diverse. AZs Oppure, se aggiungi altri lettori al cluster, puoi assicurarti che siano distribuiti su tre. AZs In questo modo, anche nel raro caso di errore di AZ, avrete comunque un'istanza Writer e un'altra istanza Reader in altre due AZs.

L’esempio seguente aggiunge un’istanza database con provisioning a un cluster Aurora PostgreSQL clonato che utilizza un gruppo di sottoreti di database personalizzato.

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

L’esempio seguente mostra l’output parziale del comando.

{
  'DBInstanceIdentifier': 'my_postgres_instance',
  'DBClusterIdentifier': 'my_aurora_postgresql_clone',
  'DBInstanceClass': 'db.t4g.medium',
  'DBInstanceStatus': 'creating'
  ...
}

L’esempio seguente aggiunge un’istanza database Aurora Serverless v2 a un clone Aurora MySQL che utilizza un gruppo di sottoreti di database personalizzato. Per poter utilizzare le istanze Serverless v2, assicurati di specificare l’opzione --serverless-v2-scaling-configuration per il comando restore-db-cluster-to-point-in-time, come mostrato negli esempi precedenti.

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

L’esempio seguente mostra l’output parziale del comando.

{
  'DBInstanceIdentifier': 'my_mysql_instance',
  'DBClusterIdentifier': 'my_aurora_mysql_clone',
  'DBInstanceClass': 'db.serverless',
  'DBInstanceStatus': 'creating'
  ...
}

Fase 3: stabilire la connettività da un sistema client a un clone

Se ti stai già connettendo a un cluster Aurora da un sistema client, potresti voler consentire lo stesso tipo di connettività a un nuovo clone. Ad esempio, potresti connetterti al cluster originale da un’istanza Amazon Cloud9 o da un’istanza EC2. Per consentire connessioni dagli stessi sistemi client o dai sistemi nuovi che hai creato nel VPC di destinazione, devi configurare gruppi di sottoreti di database e gruppi di sicurezza VPC equivalenti a quelli del VPC. Specifica quindi il gruppo di sottoreti e i gruppi di sicurezza quando crei il clone.

I seguenti esempi mostrano la configurazione di un clone Aurora Serverless v2. Tale configurazione si basa sulla combinazione di --engine-mode provisioned e --serverless-v2-scaling-configuration durante la creazione del cluster di database e quindi di --db-instance-class db.serverless durante la creazione di ogni istanza database nel cluster. La modalità motore provisioned è l’impostazione predefinita, quindi puoi omettere questa opzione se preferisci.

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

Quando crei le istanze database nel clone, specifica la stessa opzione --db-subnet-group-name. Facoltativamente, è possibile includere l'--availability-zoneopzione e specificare una delle sottoreti AZs associate alle sottoreti in quel gruppo di sottoreti. Tale AZ deve inoltre essere una delle aree AZs associate al cluster originale.

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

Spostamento di un cluster da sottoreti pubbliche a sottoreti private

Puoi utilizzare la clonazione per eseguire la migrazione di un cluster tra sottoreti pubbliche e private. Puoi eseguire questa operazione aggiungendo ulteriori livelli di sicurezza all’applicazione prima di distribuirla in produzione. Per questo esempio, dovresti aver già configurato le sottoreti private e il gateway NAT prima di iniziare il processo di clonazione con Aurora.

Per le fasi che coinvolgono Aurora, puoi seguire la stessa procedura generica degli esempi precedenti per Raccolta delle informazioni sull’ambiente di rete e Creazione di un clone Aurora con nuove impostazioni di rete. La differenza principale è che, anche se disponete di sottoreti pubbliche che mappano tutte le AZs sottoreti del cluster originale, ora è necessario verificare di disporre di un numero sufficiente di sottoreti private per un cluster Aurora e che tali sottoreti siano associate a tutte le sottoreti utilizzate per l'archiviazione Aurora nel cluster originale. AZs Analogamente ad altri casi d'uso della clonazione, è possibile creare il gruppo di sottoreti DB per il clone con tre o due sottoreti private associate a quanto richiesto AZs. Tuttavia, se utilizzi due sottoreti private nel gruppo di sottoreti di database, devi disporre di una terza sottorete privata associata alla terza AZ utilizzata per l’archiviazione Aurora nel cluster originale.

Puoi consultare questa lista di controllo per verificare che siano soddisfatti tutti i requisiti per eseguire questo tipo di operazione di clonazione.

Quando tutti i prerequisiti sono soddisfatti, puoi sospendere l’attività del database sul cluster originale mentre crei il clone e cambi l’applicazione per utilizzarlo. Dopo aver creato il clone, verificato di poterti connettere a esso, eseguito il codice dell’applicazione e così via, puoi interrompere l’utilizzo del cluster originale.

End-to-end esempio di creazione di un clone cross-VPC

La creazione di un clone in un VPC diverso da quello originale avviene attraverso la stessa procedura generica mostrata negli esempi precedenti. Poiché l’ID VPC è una proprietà delle sottoreti, in realtà non specifichi l’ID VPC come parametro quando esegui uno dei comandi dell’interfaccia CLI di RDS. La differenza principale è che è più probabile che sia necessario creare nuove sottoreti, nuove sottoreti mappate su specifiche, AZs un gruppo di sicurezza VPC e un nuovo gruppo di sottoreti DB. Questo è particolarmente vero se si tratta del primo cluster Aurora creato in quel VPC.

Puoi consultare questa lista di controllo per verificare che siano soddisfatti tutti i requisiti per eseguire questo tipo di operazione di clonazione.

Quando tutti i prerequisiti sono soddisfatti, puoi sospendere l’attività del database sul cluster originale mentre crei il clone e cambi l’applicazione per utilizzarlo. Dopo aver creato il clone, verificato di poterti connettere a esso, eseguito il codice dell’applicazione e così via, puoi valutare se mantenere attivi sia l’originale che i cloni oppure interrompere l’utilizzo del cluster originale.

I seguenti esempi Linux mostrano la sequenza di operazioni AWS CLI per clonare un cluster Aurora DB da un VPC a un altro. Alcuni campi non rilevanti per gli esempi non vengono visualizzati nell’output del comando.

Innanzitutto, controlliamo l'origine e IDs la destinazione. VPCs Il nome descrittivo che assegni a un VPC quando lo crei è rappresentato come tag nei metadati del VPC.

$ aws ec2 describe-vpcs --query '*[].[VpcId,Tags]'
[
    [
        'vpc-0f0c0fc0000b0ffb0',
        [
            {
                'Key': 'Name',
                'Value': 'clone-vpc-source'
            }
        ]
    ],
    [
        'vpc-9e99d9f99a999bd99',
        [
            {
                'Key': 'Name',
                'Value': 'clone-vpc-dest'
            }
        ]
    ]
]

Il cluster originale esiste già nel VPC di origine. Per configurare il clone utilizzando lo stesso set AZs di storage Aurora, controlliamo quello usato AZs dal cluster originale.

$ 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

Ci assicuriamo che ci siano sottoreti che corrispondano a quelle AZs utilizzate dal cluster originale:us-east-1c, e. us-east-1d 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',
    }
}

Questo esempio conferma che esistono sottoreti mappate al necessario AZs nel VPC di destinazione.

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  |
+------------------+----------------------------+-------------------------+

Prima di creare un cluster Aurora DB nel VPC, è necessario disporre di un gruppo di sottoreti DB con sottoreti mappate a quelle utilizzate per lo storage Aurora. AZs Quando si crea un cluster normale, è possibile utilizzare qualsiasi set di tre. AZs Quando si clona un cluster esistente, il gruppo di sottoreti deve corrispondere ad almeno due dei tre AZs utilizzati per l'archiviazione Aurora.

$ 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' }
            }
        ]
    }
}

Ora le sottoreti e il gruppo di sottoreti di database sono predisposti. L’esempio seguente mostra il restore-db-cluster-to-point-in-time che clona il cluster. L'--db-subnet-group-nameopzione associa il clone al set corretto di sottoreti mappate al set corretto del cluster originale. AZs

$ 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'
}

L'esempio seguente conferma che lo storage Aurora nel clone utilizza lo stesso set di del AZs cluster originale.

$ 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

A questo punto, puoi creare le istanze database per il clone. Assicurati che il gruppo di sicurezza VPC associato a ciascuna istanza consenta le connessioni dagli intervalli di indirizzi IP che utilizzi per le istanze EC2, i server applicativi e così via che si trovano nel VPC di destinazione.