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 impostare 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 VPC diversi. 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 VPC, sottoreti e gruppi di sottoreti di database, consulta prima VPC Amazon e Amazon Aurora. Puoi seguire i tutorial in quella sezione per creare questo tipo di risorse nella console AWS e capire come si integrano tra loro.

Poiché la procedura prevede il passaggio da RDS a EC2 e viceversa, gli esempi utilizzano i comandi AWS dell’interfaccia 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 le informazioni sul VPC, sulle sottoreti, sul gruppo di sottoreti di database e sulle AZ utilizzate 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, verifica quali AZ utilizza il cluster originale per l’archiviazione. Come spiegato in Archiviazione Amazon Aurora, l’archiviazione per ogni cluster Aurora è associata esattamente a tre AZ. 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 l’archiviazione per il cluster Aurora utilizza sempre tre AZ.

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 queste AZ, è necessario creare sottoreti associate ad almeno due di tali AZ e quindi creare un gruppo di sottoreti di database contenente queste 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 delle AZ a cui sono associate le sottoreti.

L’esempio seguente mostra come trovare il gruppo di sottoreti di database del cluster originale e quindi lavorare a ritroso sulle AZ corrispondenti. 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 dell’interfaccia 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 gli ID 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

Puoi utilizzare questa procedura per comprendere le AZ utilizzate per le istanze database nel cluster originale. In questo modo, puoi configurare esattamente le stesse AZ per le istanze database 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 database sono distribuite su un massimo di tre AZ.

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. Potresti eseguire tale operazione per configurare le istanze database nel nuovo cluster configurato esattamente per le stesse AZ del cluster originale.

Fase 5: verificare i VPC che puoi utilizzare per il clone

Se intendi creare il clone in un VPC diverso dall’originale, puoi ottenere un elenco degli ID 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 VPC per il tuo account, esegui il comando dell’interfaccia CLI riportato di seguito.

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

Di seguito è riportato l’output di esempio del comando describe-vpcs precedente. L’output mostra che nell’account AWS corrente sono presenti quattro VPC 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 nel nuovo VPC sia presente un numero sufficiente di sottoreti e che le sottoreti siano associate alle AZ corrette del cluster originale.

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 ad AZ specifiche o un nuovo gruppo di sottoreti di database.

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 quante AZ sono associate all’archiviazione del cluster originale e alle sottoreti nel VPC di destinazione. Per creare correttamente il clone, devono esserci due o tre AZ in comune. Se hai meno di due AZ in comune, torna a Fase 1: creare le sottoreti per il clone. Crea una, due o tre nuove sottoreti associate alle AZ che sono associate all’archiviazione del cluster originale.

Scegli le sottoreti nel VPC di destinazione associate alle stesse AZ dell’archiviazione Aurora nel cluster originale. Idealmente, scegli tre AZ. In questo modo avrai la massima flessibilità per distribuire le istanze database del clone su più AZ per un’elevata disponibilità delle risorse di calcolo.

Esegui un comando simile al seguente per creare il nuovo gruppo di sottoreti di database. Sostituisci gli ID delle tue sottoreti nell’elenco. Se specifichi gli ID di sottorete utilizzando variabili di ambiente, presta attenzione a citare l’elenco dei parametri --subnet-ids in modo da preservare le virgolette doppie intorno agli ID.

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 appurato che è disponibile la configurazione corretta di VPC, sottoreti, AZ e gruppi di sottoreti per l’utilizzo del nuovo cluster, puoi eseguire l’operazione di clonazione vera e propria. 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à mostrati in questo esempio consentono a ciascuna istanza Serverless v2 nel cluster di scalare tra 2 e 32 unità di capacità Aurora (ACU). 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 database, l’archiviazione Aurora per il cluster di origine e il clone è associata a tre AZ. L’esempio seguente elenca le AZ associate sia al cluster originale che al clone, per entrambi i comandi restore-db-cluster-to-point-in-time degli 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 AZ si sovrappongono tra ogni coppia di cluster originali e cloni, entrambi i cluster possono accedere alla stessa archiviazione 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 è comoda, soprattutto per i sistemi di sviluppo e test, perché non è necessario tenere traccia degli ID di sottorete o delle AZ mentre aggiungi nuove istanze al clone.

In alternativa, puoi specificare la AZ quando crei un’istanza database Aurora per il clone. La AZ che specifichi deve appartenere al set di AZ associate al clone. Se il gruppo di sottoreti di database che utilizzi per il clone contiene solo due sottoreti, puoi scegliere solo tra le AZ associate a queste due sottoreti. Questa scelta offre flessibilità e resilienza per sistemi ad alta disponibilità, perché puoi assicurarti che l’istanza di scrittura e l’istanza di lettura in standby si trovino in AZ diverse. Altrimenti, se aggiungi altre istanze di lettura al cluster, puoi assicurarti che siano distribuite su tre AZ. In questo modo, anche nell’improbabile eventualità di un problema con una AZ, avrai comunque un’istanza di scrittura e un’altra istanza di lettura in altre due AZ.

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, puoi includere l’opzione --availability-zone e specificare una delle AZ associate alle sottoreti nel gruppo di sottoreti in questione. Tale AZ deve inoltre essere una delle AZ 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 disponi di sottoreti pubbliche mappate a tutte le AZ del cluster originale, ora devi verificare di disporre di un numero sufficiente di sottoreti private per un cluster Aurora e che tali sottoreti siano associate alle stesse AZ utilizzate per l’archiviazione Aurora nel cluster originale. Analogamente ad altri casi d’uso di clonazione, puoi creare il gruppo di sottoreti di database per il clone con tre o due sottoreti private associate alle AZ richieste. 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.

Esempio end-to-end di creazione di un clone tra 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 ad AZ specifiche, un gruppo di sicurezza VPC e un nuovo gruppo di sottoreti di database. 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 dell’interfaccia CLI per clonare un cluster di database Aurora da un VPC a un altro. Alcuni campi non rilevanti per gli esempi non vengono visualizzati nell’output del comando.

Innanzitutto, occorre controllare gli ID dei VPC di origine e di destinazione. 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 di AZ per l’archiviazione Aurora, è necessario controllare le AZ utilizzate 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

Occorre assicurarsi che esistano sottoreti che corrispondono alle AZ utilizzate dal cluster originale: us-east-1c, us-east-1d e 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',
    }
}

In questo esempio viene confermato che esistono sottoreti mappate alle AZ necessarie 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 di database Aurora nel VPC, devi disporre di un gruppo di sottoreti di database con sottoreti mappate alle AZ utilizzate per l’archiviazione Aurora. Quando crei un cluster standard, puoi utilizzare qualsiasi set di tre AZ. Quando esegui la clonazione di un cluster esistente, il gruppo di sottoreti deve corrispondere ad almeno due delle tre AZ utilizzate 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’opzione --db-subnet-group-name associa il clone al set corretto di sottoreti mappate al set corretto di AZ del cluster originale.

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

Nell’esempio seguente viene confermato che l’archiviazione Aurora nel clone utilizza lo stesso set di AZ del 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.