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 soluzione Blue/Green Neptune per eseguire aggiornamenti blu-verdi
Gli aggiornamenti del motore Amazon Neptune possono prevedere tempi di inattività delle applicazioni perché il database non è disponibile durante l'installazione e la verifica degli aggiornamenti. Questo vale indipendentemente dal fatto che vengano avviati manualmente o automaticamente.
Neptune offre Blue/Green una soluzione di distribuzione che è possibile eseguire utilizzando CloudFormation uno stack e che riduce notevolmente tali tempi di inattività. Crea un ambiente di gestione temporanea verde sincronizzato con l'ambiente di produzione blu. È quindi possibile aggiornare l'ambiente di gestione temporanea per eseguire un aggiornamento della versione secondaria o principale del motore, una modifica del modello dei dati del grafo o un aggiornamento del sistema operativo e testare il risultato. Infine, puoi effettuare rapidamente lo switchover all'ambiente di produzione, con tempi di inattività minimi.
La soluzione Blue/Green Neptune attraversa due fasi, come illustrato in questo diagramma:
![\[Diagramma di flusso generale della strategia di implementazione blu-verde\]](http://docs.aws.amazon.com/it_it/neptune/latest/userguide/images/BG-flow.png)
**La fase 1 crea un cluster database verde identico al cluster di produzione**
La soluzione crea un cluster DB con un identificatore di blue/green distribuzione univoco e con la stessa topologia di cluster del cluster di produzione. Ovvero ha lo stesso numero e dimensioni di istanze database, gli stessi gruppi di parametri e tutte le stesse configurazioni del cluster database di produzione (blu), tranne per il fatto che è stato aggiornato alla versione del motore di destinazione specificata, che deve essere successiva alla versione del motore corrente (blu). È possibile specificare una versione secondaria e una versione principale del motore per la destinazione. Se necessario, la soluzione eseguirà tutti gli aggiornamenti intermedi al fine di raggiungere la versione del motore di destinazione specificata. Questo nuovo cluster diventa l'ambiente di gestione temporanea verde.
**La fase 2 configura la sincronizzazione continua dei dati**
Dopo che l'ambiente verde è stato completamente preparato, la soluzione imposta la replica continua tra il cluster di origine (blu) e il cluster di destinazione (verde) utilizzando i flussi Neptune. Quando la differenza di replica tra di essi raggiunge lo zero, l'ambiente di gestione temporanea è pronto per il test. A quel punto è necessario sospendere la scrittura sul cluster blu per evitare ulteriori ritardi di replica.
La versione del motore di destinazione potrebbe includere nuove funzionalità o dipendenze che influiscono sulle applicazioni. Controlla la pagina di rilascio del motore di destinazione e le pagine dei rilasci del motore intermedi nella sezione [Rilasci del motore](engine-releases.md) per informazioni su cosa è cambiato rispetto alla versione corrente del motore. È consigliabile eseguire test di integrazione o verificare manualmente le applicazioni nel cluster verde prima di promuoverle all'ambiente di produzione.
Dopo aver testato e valutato le modifiche nel cluster verde, è sufficiente cambiare l'endpoint del database nelle applicazioni dal cluster blu a quello verde.
Dopo il passaggio al digitale, la Blue/Green soluzione Neptune non elimina il vecchio ambiente di produzione blu. Potrai continuare ad accedervi per ulteriori convalide e test, se necessario. Vengono addebitate le spese di fatturazione standard per le relative istanze fino a quando non le elimini. La Blue/Green soluzione utilizza anche altri AWS servizi, i cui costi vengono fatturati a prezzi normali. Le informazioni relative all'eliminazione della soluzione quando non è più necessaria sono riportate nella [sezione Pulizia](neptune-BG-cleanup.md)
## Prerequisiti per l'esecuzione dello stack Neptune Blue/Green
Prima di lanciare lo stack Neptune: Blue/Green
+ Assicurati di [abilitare i flussi Neptune](streams-using.md) nel cluster di produzione (blu).
+ Tutte le istanze del cluster blu devono essere nello stato **disponibile**. Puoi controllare gli stati delle istanze nella console [Neptune](https://console.aws.amazon.com/neptune) o utilizzando l'API. [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/neptune/describe-db-instances.html)
+ Tutte le istanze devono inoltre essere sincronizzate con il [gruppo di parametri del cluster database](parameter-groups.md).
+ La soluzione Blue/Green Neptune richiede un endpoint VPC DynamoDB nel VPC in cui si trova il cluster blu. Consulta [Utilizzo di endpoint Amazon VPC per accedere a DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/network-isolation.html#vpc-endpoints-dynamodb).
+ Esegui la soluzione quando il carico di lavoro di scrittura sul cluster database di produzione blu è il più leggero possibile. Evita, ad esempio, di eseguire la soluzione nel corso di un caricamento in blocco o quando è probabile che si verifichi un numero elevato di operazioni di scrittura per qualsiasi altro motivo.
# Utilizzo di un CloudFormation modello per eseguire la soluzione Neptune Blue/Green
È possibile utilizzare AWS CloudFormation per distribuire la soluzione Neptune Blue/Green . Il CloudFormation modello crea un'istanza Amazon EC2 nello stesso VPC del database Blue Source Neptune, installa lì la soluzione e la esegue. [Puoi monitorarne l'avanzamento nei CloudWatch log, come spiegato in Monitoraggio dell'avanzamento.](neptune-BG-monitoring.md)
Puoi utilizzare questi collegamenti per esaminare il modello di soluzione o selezionare il pulsante **Launch Stack** per avviarlo nella CloudFormation console:
| | | |
| --- |--- |--- |
| [Visualizzazione](https://aws-neptune-customer-samples-us-east-1.s3.amazonaws.com/neptune-bg/bg.yaml) | [Visualizzazione in Designer](https://console.aws.amazon.com/cloudformation/designer/home?templateURL=https://aws-neptune-customer-samples-us-east-1.s3.amazonaws.com/neptune-bg/bg.yaml) | [https://console.aws.amazon.com/cloudformation/home?region=us-east-1#/stacks/new?stackName=NeptuneBG&templateURL=https://aws-neptune-customer-samples-us-east-1.s3.amazonaws.com/neptune-bg/bg.yaml](https://console.aws.amazon.com/cloudformation/home?region=us-east-1#/stacks/new?stackName=NeptuneBG&templateURL=https://aws-neptune-customer-samples-us-east-1.s3.amazonaws.com/neptune-bg/bg.yaml) |
Nella console, scegli la AWS regione in cui desideri eseguire la soluzione dal menu a discesa nella parte superiore destra della finestra.
Imposta i parametri dello stack come segue:
+ **`DeploymentID`**— Un identificatore unico per ogni distribuzione di Neptune Blue/Green .
Viene utilizzato come identificatore del cluster database verde e come prefisso per assegnare i nomi alle nuove risorse create durante l'implementazione.
+ **`NeptuneSourceClusterId`**: identificatore del cluster database blu da aggiornare.
+ **`NeptuneTargetClusterVersion:`**: [versione del motore Neptune](engine-releases.md) a cui si desidera aggiornare il cluster database blu.
Questo valore deve essere maggiore rispetto a quello della versione del motore corrente del cluster database blu.
+ **`DeploymentMode`**: indica se si tratta di una nuova implementazione o di un tentativo di riprendere un'implementazione precedente. Se utilizzi lo stesso `DeploymentID` di un'implementazione precedente, imposta `DeploymentMode` su `resume`.
I valori validi sono `new` (predefinito) e `resume`.
+ **`GraphQueryType`**: tipo di dati del grafo per il database.
I valori validi sono `propertygraph` (predefinito) e `rdf`.
+ **`SubnetId`**: ID di sottorete dello stesso VPC in cui si trova il cluster database blu. Consulta [Connessione a un cluster database Neptune da un'istanza Amazon EC2 nello stesso VPC](get-started-connect-ec2-same-vpc.md).
Specifica l'ID di una sottorete pubblica per stabilire una connessione SSH all'istanza tramite [EC2 Connect](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Connect-using-EC2-Instance-Connect.html).
+ **`InstanceSecurityGroup`**: gruppo di sicurezza per l'istanza Amazon EC2.
Il gruppo di sicurezza deve avere accesso al cluster database blu e devi poter accedere all'istanza tramite SSH. Per informazioni, consulta [Creare un gruppo di sicurezza tramite la console VPC](get-started-vpc.md#security-vpc-security-group).
Attendi che lo stack sia completo. Al termine, la soluzione verrà avviata. È quindi possibile monitorare il processo di distribuzione utilizzando CloudWatch i log come descritto nella sezione successiva.
# Monitoraggio dello stato di avanzamento dell'implementazione di Neptune Blue/Green
Puoi monitorare l'avanzamento della soluzione Blue/Green Neptune accedendo alla console e guardando [CloudWatch i](https://console.aws.amazon.com/cloudwatch/) log nel gruppo di log. `/aws/neptune/(Neptune Blue/Green deployment ID)` CloudWatch Puoi trovare un link ai CloudWatch log negli output dello stack della soluzione: CloudFormation
![\[Schermata dell'output dello stack Blue/Green CloudFormation\]](http://docs.aws.amazon.com/it_it/neptune/latest/userguide/images/BG-stack-output.png)
Se hai specificato una sottorete pubblica come parametro dello stack, puoi anche accedere tramite SSH all'istanza Amazon EC2 creata come parte dello stack e fare riferimento al file di log in `/var/log/cloud-init-output.log`.
Il registro mostra le azioni intraprese dalla soluzione Blue/Green Neptune, come mostrato in questa schermata:
![\[Schermata della schermata di registro di Neptune Blue/Green\]](http://docs.aws.amazon.com/it_it/neptune/latest/userguide/images/BG-log-screenshot.png)
I messaggi del file di log mostrano lo stato di sincronizzazione tra i cluster blu e verde:
![\[Schermata dei messaggi di registro della soluzione Blue/Green Neptune\]](http://docs.aws.amazon.com/it_it/neptune/latest/userguide/images/BG-log-messages.png)
Il processo di sincronizzazione verifica il ritardo di replica calcolando la differenza tra lo stream più recente `eventID` sul cluster blu e il checkpoint di replica presente nella tabella dei checkpoint di DynamoDB creata dallo stack di replica. Neptune-to-Neptune Utilizzando questi messaggi, è possibile monitorare la differenza di replica corrente.
# Passaggio dal cluster blu di produzione al cluster verde aggiornato
Prima di promuovere il cluster verde all'ambiente di produzione, assicurati che la differenza di commit tra il cluster blu e il cluster verde sia pari a zero, quindi disabilita tutto il traffico di scrittura sul cluster blu. Se si continua a scrivere sul cluster blu durante il passaggio dell'endpoint del database al cluster verde potrebbe verificarsi un danneggiamento dei dati causato dalla scrittura di dati parziali su entrambi i cluster. Potrebbe non essere ancora il momento di disabilitare il traffico di lettura.
Se hai abilitato l'autenticazione IAM nel cluster di origine (blu), assicurati di aggiornare tutte le policy IAM utilizzate nelle tue applicazioni affinché puntino al cluster verde (per un esempio di tale policy, consulta [policy di accesso senza restrizioni](iam-data-access-examples.md#iam-auth-data-policy-example-general)).
Dopo aver disabilitato il traffico di scrittura, attendi che termini la replica, quindi abilita il traffico di scrittura sul cluster verde (ma non sul cluster blu). Passa anche il traffico di lettura dal cluster blu a quello verde.
# Pulizia dopo il completamento della soluzione di Blue/Green Neptune
Dopo aver promosso il cluster di staging (verde) alla produzione, pulisci le risorse create dalla soluzione Neptune Blue/Green :
+ Elimina l'istanza Amazon EC2 creata per eseguire la soluzione.
+ Elimina i CloudFormation modelli per la replica [basata su Neptune Streams](streams-consumer-setup.md) che ha mantenuto il cluster verde sincronizzato con il cluster blu. Quello principale ha il nome dello stack che hai specificato in precedenza e uno è costituito dall'ID di implementazione seguito da "-replication", ovvero `(DeploymentID)-replication`.
L'eliminazione dei CloudFormation modelli non elimina i cluster stessi. Dopo aver verificato che il cluster verde funzioni come previsto, puoi facoltativamente acquisire uno snapshot prima di eliminare manualmente il cluster blu.
# Le migliori pratiche della soluzione Blue/Green Neptune
+ Prima di procedere con lo switchover del cluster verde all'ambiente di produzione, è consigliabile verificarne accuratamente il corretto funzionamento. Verifica la coerenza dei dati e la configurazione del database. È possibile che alcune delle nuove versioni del motore richiedano anche aggiornamenti del client. Controlla le note di rilascio della versione del motore prima di effettuare l'aggiornamento. Vale la pena testare tutto questo in ambienti di sviluppo, test e preproduzione prima di iniziare un blue/green aggiornamento in produzione.
+ È preferibile effettuare il passaggio dal server blu a quello verde durante la finestra di manutenzione.
+ Per garantire che tutto funzioni correttamente dopo l'aggiornamento e la sincronizzazione, è consigliabile conservare il cluster originale per un certo periodo di tempo prima di eliminarlo. Potrebbe rivelarsi utile in caso di problemi imprevisti.
+ Evita operazioni di scrittura pesanti come carichi di massa durante l'esecuzione della soluzione Blue/Green Neptune, poiché possono causare ritardi di replica che introducono tempi di inattività significativi. Idealmente, il tempo che intercorre tra la disattivazione delle scritture sul cluster blu e l'attivazione per il cluster verde è di pochi istanti.
# Risoluzione dei problemi relativi alla soluzione Neptune Blue/Green
Le seguenti informazioni evidenziano i problemi che possono insorgere durante il processo di distribuzione della Blue/Green soluzione, come i conflitti con i cluster esistenti, la necessità di abilitare i flussi di Neptune, le operazioni di caricamento in blocco in corso e i requisiti di compatibilità delle versioni. Risolvendo questi potenziali problemi, è possibile garantire un'implementazione fluida e di successo della soluzione Blue/Green Neptune.
**Errori generati dalla soluzione Neptune Blue/Green**
+ **`Cluster with id = (blue_green_deployment_id) already exists`**— Esiste un cluster esistente con identificatore. *(blue\$1green\$1deployment\$1id)*
Fornisci un nuovo ID di distribuzione o imposta la modalità di distribuzione `resume` se il cluster è stato creato in una precedente esecuzione di Blue/Green Neptune.
+ **`Streams should be enabled on the source Cluster for Blue Green Deployment`**: abilita i [flussi Neptune](streams-using-enabling.md) nel cluster blu (origine).
+ **`No Bulkload should be in progress on source cluster: (cluster_id)`**— La soluzione Blue/Green Neptune termina se rileva un carico di massa in corso.
Questo per garantire che il processo di sincronizzazione possa recuperare il ritardo con le scritture effettuate. Evita o annulla qualsiasi operazione di caricamento in blocco in corso prima di avviare la soluzione Neptune Blue/Green .
+ **`Blue Green deployment requires instances to be in sync with db cluster parameter group`**: qualsiasi modifica al gruppo di parametri del cluster deve essere sincronizzata in tutto il cluster database. Per informazioni, consulta [Gruppi di parametri di Amazon Neptune](parameter-groups.md).
+ **`Invalid target engine version for Blue Green Deployment`**: il rilascio del motore di destinazione deve essere elencato come attivo in [Rilasci del motore per Amazon Neptune](engine-releases.md) e deve essere successivo al rilascio corrente del motore del cluster di origine (blu).