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à.
# Utilizzo della replica tra regioni di Neptune Streams per il ripristino di emergenza
Neptune offre due modi per implementare le funzionalità di failover tra regioni:
+ Copia e ripristino di snapshot tra regioni
+ Utilizzo di Neptune Streams per replicare i dati tra due cluster in due regioni diverse.
La copia e il ripristino di snapshot tra regioni presentano il sovraccarico operativo più basso per il ripristino di un cluster Neptune in una regione diversa. Tuttavia, la copia di uno snapshot tra regioni può richiedere tempi di trasferimento dei dati significativi, poiché uno snapshot è un backup completo del cluster Neptune. Di conseguenza, la copia e il ripristino di snapshot tra regioni possono essere utilizzati per scenari che richiedono solo un obiettivo del punto di ripristino (RPO) di ore e un obiettivo del tempo di ripristino (RTO) di ore.
L'obiettivo del punto di ripristino (RPO) viene misurato in base al tempo che intercorre tra i backup. Definisce la quantità di dati che possono andare persi tra il momento in cui è stato eseguito l'ultimo backup e il momento in cui il database viene ripristinato.
L'obiettivo del tempo di ripristino (RTO) viene misurato in base al tempo necessario per eseguire un'operazione di ripristino. Questo è il tempo impiegato dal cluster database per eseguire il failover su un database ripristinato dopo che si è verificato un errore.
Neptune Streams offre un modo per mantenere sempre sincronizzato un cluster Neptune di backup con il cluster di produzione primario. Se si verifica un errore, il database esegue il failover sul cluster di backup. Ciò riduce gli obiettivi RPO e RTO a pochi minuti, poiché i dati vengono costantemente copiati nel cluster di backup, che è immediatamente disponibile come destinazione di failover in qualsiasi momento.
Lo svantaggio dell'utilizzo di Neptune Streams in questo modo è che sia il sovraccarico operativo necessario per mantenere i componenti di replica, sia il costo di avere sempre un secondo cluster database Neptune online possono essere significativi.
# Configurazione della Neptune-to-Neptune replica
Il cluster database di produzione primario risiede in un VPC di una determinata regione di origine. Sono tre gli elementi principali che è necessario replicare o emulare in una regione di ripristino diversa ai fini del ripristino di emergenza:
+ I dati archiviati nel cluster.
+ La configurazione del cluster primario. Ad esempio, se utilizza l'autenticazione IAM, se è crittografato, i parametri del cluster database, i parametri delle istanze, le dimensioni delle istanze e così via.
+ La topologia di rete utilizzata, inclusi il VPC di destinazione, i relativi gruppi di sicurezza e così via.
È possibile utilizzare la APIs gestione di Neptune come la seguente per raccogliere tali informazioni:
+ [`DescribeDBClusters`](api-clusters.md#DescribeDBClusters)
+ [`DescribeDBInstances`](api-instances.md#DescribeDBInstances)
+ [`DescribeDBClusterParameters`](api-parameters.md#DescribeDBClusterParameters)
+ [`DescribeDBParameters`](api-parameters.md#DescribeDBParameters)
+ [https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeVpcs.html](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeVpcs.html)
Con le informazioni raccolte, è possibile utilizzare la seguente procedura per configurare un cluster di backup in una regione diversa, sul quale il cluster di produzione può eseguire il failover in caso di errore.
## Abilita i flussi di Neptune
È possibile usare [Modificare DBCluster ParameterGroup](api-parameters.md#ModifyDBClusterParameterGroup) per impostare il parametro `neptune_streams` su 1. Quindi, riavviare tutte le istanze del cluster database in modo che la modifica abbia effetto.
È consigliabile eseguire almeno un'operazione di aggiunta o aggiornamento sul cluster database di origine dopo aver abilitato Neptune Streams. In questo modo il flusso di modifiche viene popolato con punti dati a cui è possibile fare riferimento in seguito quando si risincronizza il cluster di produzione con il cluster di backup.
## Crea un nuovo VPC nella regione in cui desideri configurare il cluster di backup
Prima di creare un nuovo cluster database Neptune in una regione diversa dal cluster primario, è necessario stabilire un nuovo VPC nella regione di destinazione per ospitare il cluster. La connettività tra i cluster primari e di backup viene stabilita tramite il peering VPC, che utilizza il traffico tra sottoreti private in diversi modi. VPCs Tuttavia, per stabilire il peering VPC tra due VPCs, non devono avere blocchi CIDR o spazi di indirizzi IP sovrapposti. Ciò significa che non è possibile usare il VPC predefinito in entrambe le regioni, perché il blocco CIDR per un VPC predefinito è sempre lo stesso (`172.31.0.0/16`).
È possibile utilizzare un VPC esistente nella regione di destinazione, purché soddisfi le seguenti condizioni:
+ Non deve avere un blocco CIDR che si sovrappone al blocco CIDR del VPC in cui si trova il cluster primario.
+ Non deve essere già connesso tramite peering con un altro VPC con lo stesso blocco CIDR del VPC in cui si trova il cluster primario.
Se non è disponibile un VPC adatto nella regione di destinazione, creane uno utilizzando l'API [https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateVpc.html](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateVpc.html) di Amazon EC2.
## Crea un'istantanea del cluster primario e ripristinala nella regione di backup di destinazione
Creare ora un nuovo cluster Neptune in un VPC appropriato nella regione di backup di destinazione che è una copia del cluster di produzione:
**Creare una copia del cluster di produzione nella regione di backup**
1. Nella regione di backup di destinazione, ricreare i parametri e i gruppi di parametri utilizzati dal cluster database di produzione. A tale scopo, è possibile utilizzare [`CreateDBClusterParameterGroup`](api-parameters.md#CreateDBClusterParameterGroup), [`CreateDBParameterGroup`](api-parameters.md#CreateDBParameterGroup), [`ModifyDBClusterParameterGroup`](api-parameters.md#ModifyDBClusterParameterGroup) e [`ModifyDBParameterGroup`](api-parameters.md#ModifyDBParameterGroup).
Tieni presente che [`CopyDBClusterParameterGroup`](api-parameters.md#CopyDBClusterParameterGroup)attualmente [`CopyDBParameterGroup`](api-parameters.md#CopyDBParameterGroup) APIs non supportano la copia tra regioni.
1. Utilizzare [`CreateDBClusterSnapshot`](api-snapshots.md#CreateDBClusterSnapshot) per creare uno snapshot del cluster di produzione nel VPC della regione di produzione.
1. Utilizzare [`CopyDBClusterSnapshot`](api-snapshots.md#CopyDBClusterSnapshot) per copiare lo snapshot nel VPC della regione di backup di destinazione.
1. Utilizzare [`RestoreDBClusterFromSnapshot`](api-snapshots.md#RestoreDBClusterFromSnapshot) per creare un nuovo cluster database nel VPC della regione di backup di destinazione utilizzando lo snapshot copiato. Utilizzare le impostazioni e i parametri di configurazione copiati dal cluster di produzione primario.
1. Il nuovo cluster Neptune ora esiste ma non contiene istanze. [`CreateDBInstance`](api-instances.md#CreateDBInstance)Utilizzatelo per creare una nuova primary/writer istanza con lo stesso tipo e le stesse dimensioni dell'istanza writer del cluster di produzione. A questo punto non è necessario creare repliche di lettura aggiuntive, a meno che l'istanza di backup non venga utilizzata per eseguire il servizio di lettura I/O nell'area di destinazione prima del failover.
## Stabilisci il peering VPC tra il VPC del cluster primario e il VPC del nuovo cluster di backup
Configurando il peering VPC, si consente al VPC del cluster primario di comunicare con il VPC del cluster di backup come se si trattasse di un'unica rete privata. Per questa opzione, effettua la procedura riportata di seguito.
1. Dal VPC del cluster di produzione, chiamare l'API [https://docs.aws.amazon.com/AWSEC2/latest/APIReference/CreateVpcPeeringConnection.html](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/CreateVpcPeeringConnection.html) per stabilire la connessione peering.
1. Dal VPC del cluster di backup di destinazione, chiamare l'API [https://docs.aws.amazon.com/AWSEC2/latest/APIReference/AcceptVpcPeeringConnection.html](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/AcceptVpcPeeringConnection.html) per accettare la connessione peering.
1. Dal VPC del cluster di produzione, utilizzare l'API [https://docs.aws.amazon.com/AWSEC2/latest/APIReference/CreateRoute.html](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/CreateRoute.html) per aggiungere una route alla tabella di routing del VPC che reindirizza tutto il traffico al blocco CIDR del VPC di destinazione in modo che utilizzi l'elenco dei prefissi di peering VPC.
1. Analogamente, dal VPC del cluster di backup di destinazione, utilizzare l'API [https://docs.aws.amazon.com/AWSEC2/latest/APIReference/CreateRoute.html](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/CreateRoute.html) per aggiungere una route alla tabella di routing del VPC che instrada il traffico al VPC del cluster primario.
## Configurare l'infrastruttura di replica di Neptune Streams
Ora che entrambi i cluster sono stati implementati e la comunicazione di rete tra le due regioni è stata stabilita, utilizza il modello [Neptune-to-Neptune CloudFormation per implementare la funzione Lambda consumer Neptune](streams-consumer-setup.md) Streams con l'infrastruttura aggiuntiva che supporta la replica dei dati. Eseguire questa operazione nel VPC del cluster di produzione primario.
I parametri CloudFormation che dovrai fornire per questo stack sono:
+ **`NeptuneStreamEndpoint`**: endpoint del flusso per il cluster primario, in formato URL. Ad esempio: `https://(cluster name):8182/pg/stream`.
+ **`QueryEngine`**: deve essere `gremlin`, `sparql` o `openCypher`.
+ **`RouteTableIds`**: consente di aggiungere route sia per un endpoint VPC DynamoDB che per un endpoint VPC di monitoraggio.
Anche i due parametri aggiuntivi, vale a dire `CreateMonitoringEndpoint` e `CreateDynamoDBEndpoint`, devono essere impostati su true se non sono già presenti nel VPC del cluster primario. Se esistono già, assicurati che siano impostati su false o la CloudFormation creazione avrà esito negativo.
+ **`SecurityGroupIds`**: specifica il gruppo di sicurezza utilizzato dal consumer Lambda per comunicare con l'endpoint del flusso Neptune del cluster primario.
Nel cluster di backup di destinazione, collegare un gruppo di sicurezza che consenta il traffico proveniente da questo gruppo di sicurezza.
+ **`SubnetIds`**: elenco di ID di sottorete nel VPC del cluster primario che possono essere utilizzati dal consumer Lambda per comunicare con il cluster primario.
+ **`TargetNeptuneClusterEndpoint`**: endpoint (solo nome host) del cluster di backup di destinazione.
+ **`TargetAWSRegion`**— La AWS regione del cluster di backup di destinazione, ad esempio`us-east-1`). È necessario fornire questo parametro solo quando la AWS regione del cluster di backup di destinazione è diversa dalla regione del cluster di origine Neptune, come nel caso della replica tra regioni. Se le regioni di origine e di destinazione coincidono, questo parametro è facoltativo.
Nota che se il `TargetAWSRegion` valore non è una [AWS regione valida supportata da Neptune](limits.md#limits-regions), il processo fallisce.
+ **`VPC`**: ID del VPC del cluster primario.
Tutti gli altri parametri possono essere lasciati con i valori predefiniti.
Una volta distribuito il CloudFormation modello, Neptune inizierà a replicare tutte le modifiche dal cluster primario al cluster di backup. È possibile monitorare questa replica nei CloudWatch log generati dalla funzione consumer Lambda.
# Altre considerazioni
+ Se è necessario utilizzare l'autenticazione IAM tra il cluster primario e il cluster di backup, è possibile configurarla anche quando si richiama il modello. CloudFormation
+ Se nel cluster primario è abilitata la crittografia dei dati inattivi, considerare come gestire le chiavi KMS associate quando si copia lo snapshot nella regione di destinazione e come associare una nuova chiave KMS nella regione di destinazione.
+ Una best practice consiste nell'utilizzare il DNS CNAMEs davanti agli endpoint Neptune utilizzati nelle applicazioni. Quindi, se è necessario eseguire manualmente il failover sul cluster di backup di destinazione, questi CNAMEs possono essere modificati in modo che puntino agli endpoint dell'istanza del cluster di destinazione. and/or