Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Informazioni sui deployment blu/verde in Cloud SQL

MySQL | PostgreSQL | SQL Server

Questo documento fornisce una panoramica dei deployment blu/verdi di Cloud SQL, che consentono di eseguire aggiornamenti del database, come upgrade delle versioni principali e modifiche hardware, riducendo al minimo i tempi di inattività.

Intent di deployment e casi d'uso

Puoi creare un deployment blu/verde con o senza l'intenzione di eseguire un upgrade della versione principale:

Crea con intento (upgrade alla versione principale): esegue l'upgrade del motore del database a una versione principale più recente. Durante la creazione del deployment, Cloud SQL esegue l'API di controllo preliminare dell'upgrade alla versione principale per verificare la compatibilità prima di procedere con il flusso di lavoro di upgrade.
Crea senza intento (modifiche alla configurazione o all'hardware): esegue il staging delle modifiche alla versione corrente del database. I casi d'uso includono la modifica dei tipi di macchina (scalabilità di CPU/RAM), il test dei flag di database o la valutazione delle modifiche allo spazio di archiviazione senza eseguire l'upgrade della versione del motore.

Come funzionano i deployment blu/verde

I deployment blu/verde di Cloud SQL forniscono un workflow automatizzato organizzando le modifiche in un ambiente secondario gestione temporanea prima di passare al traffico live.

Durante un deployment blu/verde, Cloud SQL crea un ambiente di gestione temporanea (verde) separato che rispecchia l'ambiente di produzione esistente (blu). Il servizio mantiene la replica logica continua dal blu al verde. Puoi testare a fondo la compatibilità e le prestazioni dell'applicazione nell'ambiente verde senza influire sul traffico di produzione. Quando è tutto pronto, attivi un passaggio rapido che assegna l'ambiente verde allo stato di lettura e scrittura di produzione con tempi di inattività minimi dell'applicazione (in genere in secondi).

Componenti di un deployment blu/verde

Un deployment blu/verde è costituito dai seguenti componenti:

Ambiente blu (origine): l'ambiente di produzione esistente che gestisce attivamente il traffico dell'applicazione. È costituita dall'istanza di lettura e scrittura dell'origine e da qualsiasi configurazione associata.
Ambiente verde (target): un ambiente di staging gestione temporanea e isolato creato da Cloud SQL come clone dell'ambiente blu. L'ambiente verde incorpora le modifiche richieste (ad esempio una versione del database più recente) e rimane sincronizzato con l'ambiente blu utilizzando la replica continua. Cloud SQL assegna automaticamente un nome all'istanza di staging verde utilizzando il pattern BLUE_INSTANCE_NAME-green-UNIQUE_ID (dove BLUE_INSTANCE_NAME viene troncato a un massimo di 48 caratteri e UNIQUE_ID è un identificatore esadecimale di 8 caratteri).
Switchover:il processo pianificato e avviato dall'utente di conversione dell'ambiente verde nella nuova istanza di produzione in lettura e scrittura. Durante il cambio, Cloud SQL scambia gli endpoint di connessione in modo che le applicazioni si connettano all'ambiente verde con un breve calo della connessione (in genere in secondi). Il tempo di inattività previsto durante il cambio varia in base alla versione di Cloud SQL:
- Versione Cloud SQL Enterprise Plus:il tempo di inattività del cambio di ruolo è in genere inferiore al secondo.
- Cloud SQL Enterprise:il tempo di inattività del cambio di ruolo è in genere inferiore a 60 secondi, a seconda del workload e del ritardo di replica.
A differenza di un failover non pianificato (che viene attivato automaticamente durante un'interruzione), un cambio di ruolo è un'operazione controllata utilizzata per la gestione delle modifiche pianificate.
Eliminazione:il processo di rimozione della risorsa di deployment blu/verde. Il comportamento di eliminazione varia a seconda che sia stato eseguito o meno lo switchover:
- Prima del trasferimento: l'eliminazione del deployment rimuove l'istanza di staging verde e la risorsa di deployment. La tua istanza di produzione blu non è interessata e continua a gestire il traffico.
- Dopo il trasferimento: l'eliminazione del deployment rimuove i metadati del deployment. Per impostazione predefinita, vengono conservate sia l'istanza convertita (verde) sia l'istanza blu. Se vuoi, puoi eliminare l'istanza blu per evitare addebiti continui.

Ciclo di vita e stati del deployment

Un deployment blu/verde passa attraverso quattro fasi distinte del ciclo di vita:

Creazione e gestione temporanea (PROVISIONING): quando richiedi un deployment blu/verde, Cloud SQL esegue il provisioning di un'istanza target verde temporanea che clona l'ambiente di produzione blu. In caso di upgrade della versione principale, Cloud SQL esegue anche l'API di controllo preliminare dell'upgrade della versione principale per convalidare la compatibilità del database prima di procedere con il flusso di lavoro di upgrade. Cloud SQL applica l'upgrade o la modifica della configurazione richiesti all'ambiente verde e avvia la replica logica continua da blu a verde.
Verifica di staging (SWITCHOVER_READY o SWITCHOVER_NOT_READY): al termine della replica iniziale, il deployment entra in SWITCHOVER_READY (o SWITCHOVER_NOT_READY se la replica è interrotta o se si verificano errori). Il blu continua a gestire il traffico di produzione live. Ti connetti a Green per eseguire test di convalida, verificare la compatibilità delle applicazioni e testare le prestazioni delle query.
Esecuzione del cambio (SWITCHOVER_IN_PROGRESS o SWITCHOVER_COMPLETED): quando attivi il cambio, Cloud SQL esegue controlli preliminari di sicurezza, scambia gli endpoint di connessione e imposta l'istanza verde come istanza di lettura e scrittura di produzione attiva (SWITCHOVER_COMPLETED) e la transizione dell'istanza blu a un'istanza di lettura e scrittura autonoma. Le operazioni di lettura e scrittura attive vengono indirizzate esclusivamente all'istanza verde e la replica logica da blu a verde viene terminata. Per saperne di più, consulta Eseguire un failover del deployment blu/verde.
Eliminazione (DELETING): al termine del test o dopo aver verificato le operazioni di produzione, elimina la risorsa di deployment. Il comportamento di eliminazione varia a seconda dello stato del deployment:
- Prima del trasferimento (annullamento): se decidi di non procedere con l'implementazione o se si verificano problemi di verifica, l'eliminazione dell'implementazione rimuove l'istanza di staging verde ed elimina i metadati dell'implementazione. L'istanza di produzione blu originale rimane invariata e continua a gestire il traffico senza interruzioni.
- Dopo il trasferimento (pulizia): al termine del trasferimento e dopo aver verificato le operazioni sulla nuova istanza di produzione, l'eliminazione del deployment rimuove i metadati del deployment. Per impostazione predefinita, sia la nuova istanza di produzione (verde) sia l'istanza blu vengono conservate come istanze di lettura e scrittura autonome. Puoi specificare facoltativamente il flag --delete-old-source per eliminare definitivamente l'istanza blu e interrompere l'addebito dei costi.
Per saperne di più, consulta la sezione Elimina un deployment blue-green.

Stati delle risorse di deployment

Quando esamini un deployment blu/verde, il campo state indica lo stato attuale del ciclo di vita:

PROVISIONING: il deployment è in fase di creazione. Per gli upgrade della versione principale, Cloud SQL esegue l'API di controllo preliminare per convalidare la compatibilità prima di procedere. Cloud SQL esegue il provisioning dell'ambiente verde, applica gli upgrade richiesti e configura la replica logica continua.
SWITCHOVER_READY:l'ambiente verde viene sottoposto al provisioning, la replica logica da blu a verde è integra e il deployment è pronto per il failover.
SWITCHOVER_NOT_READY: il deployment è stato eseguito, ma non è possibile avviare il cambio. Ciò si verifica se la replica logica è interrotta o arrestata, se la replica iniziale non è stata completata o se un nodo accoppiato ha riscontrato un errore.
SWITCHOVER_IN_PROGRESS: è in corso un'operazione di switchover. Cloud SQL scambia gli endpoint di connessione e converte l'istanza verde nell'istanza di produzione attiva di lettura e scrittura.
SWITCHOVER_COMPLETED: l'operazione di switchover è stata completata correttamente. L'istanza verde è ora l'istanza di produzione attiva di lettura e scrittura e l'istanza blu viene mantenuta come istanza di lettura e scrittura autonoma.
DELETING: il deployment è in fase di eliminazione. Se l'eliminazione avviene prima del cambio, Cloud SQL rimuove l'istanza di staging verde ed elimina i metadati di deployment. Se l'eliminazione avviene dopo il trasferimento, Cloud SQL rimuove i metadati del deployment ed elimina facoltativamente l'istanza blu se viene specificato il flag --delete-old-source.
STATE_UNSPECIFIED: lo stato del deployment è sconosciuto.

Stati e preparazione del cambio

La preparazione al cambio dipende dall'integrità della replica e dallo stato del nodo per proteggere il database di produzione da perdita di dati o tempi di inattività prolungati:

Stato e ritardo della replica:se la replica logica tra blu e verde è interrotta, in pausa o non riesce, lo stato del deployment passa a SWITCHOVER_NOT_READY. L'output di deployment state e describe non segnala il ritardo di replica e Cloud SQL non valuta il ritardo di replica come precontrollo per determinare lo stato del deployment. Tuttavia, l'operazione di switchover non riesce se il ritardo di replica è troppo elevato quando viene avviato lo switchover. Per garantire un cambio riuscito, assicurati che il ritardo di replica sia minimo prima di iniziare il cambio. Puoi monitorare il ritardo di replica in Cloud Monitoring (controllando metriche come replica_lag nell' elenco delle metriche Cloud SQL) o direttamente nell'istanza verde. Per saperne di più, consulta Monitora il ritardo della replica.
Stato del nodo accoppiato:in deploymentMappings, ogni nodo accoppiato segnala il proprio stato (ad esempio PROVISIONED, UPGRADED, UPGRADE_FAILED, SWITCHOVER_IN_PROGRESS, SWITCHOVER_SUCCEEDED o SWITCHOVER_FAILED). Se un nodo accoppiato rileva un errore (UPGRADE_FAILED o SWITCHOVER_FAILED), lo stato generale del deployment passa a SWITCHOVER_NOT_READY. Se un failover non riesce, il routing rimane sull'istanza blu senza perdita di dati.
Risoluzione dei problemi relativi all'idoneità al cambio:se il deployment segnala SWITCHOVER_NOT_READY, controlla il campo errorDetail per diagnosticare la replica o gli errori dei nodi. Prima di avviare il failover, assicurati che il ritardo di replica sia minimo e verifica che le operazioni DDL batch attive o le transazioni di scrittura a esecuzione prolungata sull'istanza blu siano completate.

Limitazioni

Prima di utilizzare i deployment blu/verde, esamina le seguenti limitazioni:

Motori e versioni supportati:le istanze Cloud SQL per MySQL su MySQL 5.7 e versioni successive sono supportate per la gestione temporanea della configurazione (creazione senza intent). Gli upgrade delle versioni principali di destinazione (creati con intento) sono supportati da MySQL 8.0 a 8.4. MySQL 8.0.18 non è supportato per i deployment blu/verde.
Motori di database non supportati:Cloud SQL per PostgreSQL e Cloud SQL per SQL Server non sono supportati.
Istanze con repliche di lettura:i deployment blu/verde non supportano le istanze con repliche di lettura.
Configurazioni di rete non supportate:i deployment blue-green non supportano le configurazioni in uscita di Private Service Connect.
Autenticazione del gruppo IAM: i deployment blue-green non sono compatibili con MySQL autenticazione del gruppo IAM e possono causare errori di switchover.
Requisito dell'architettura di rete: le istanze Cloud SQL devono utilizzare la nuova architettura di rete. Le istanze che utilizzano la vecchia architettura di rete non sono supportate.
Requisito di logging binario:le istanze MySQL devono avere backup automatici e logging binario abilitati per supportare la replica logica continua nell'ambiente verde.
Requisito della versione di manutenzione:l'istanza di origine blu deve eseguire l'ultima versione di manutenzione prima di creare un deployment blu/verde. Per controllare o aggiornare la versione di manutenzione dell'istanza, consulta Esegui la manutenzione self-service.
Disponibilità delle risorse:il provisioning delle istanze durante i flussi di lavoro di deployment blu/verde, inclusa la creazione dell'istanza di staging verde e dell'istanza blu dopo il cambio, può essere influenzato dai vincoli delle risorse di calcolo nella regione o nella zona selezionata.
Interruzioni impreviste e failover: il passaggio al deployment blu/verde è un'operazione pianificata che richiede un'istanza di origine blu RUNNING integra. L'istanza di staging verde funge da replica di lettura specializzata; come le repliche di lettura standard, l'istanza verde non può essere utilizzata come destinazione di failover durante un'interruzione non pianificata dell'istanza di origine. Per il recupero automatico dalle interruzioni, configura l'istanza per l'alta affidabilità o utilizza una replica di ripristino di emergenza (RE).

Fatturazione e prezzi

Non sono previsti costi aggiuntivi per l'utilizzo dei deployment blu/verde. Tuttavia, poiché durante il deployment viene eseguito il provisioning di un ambiente verde parallelo completo, ti vengono addebitate le tariffe standard per le istanze blu e verdi per l'intera durata di esistenza di entrambi gli ambienti.

Per evitare addebiti inutili, elimina il deployment e le istanze associate:

Prima del passaggio: se annulli il deployment, eliminalo per rimuovere l'istanza di staging verde e interrompere gli addebiti.
Dopo il cambio:elimina il deployment e specifica il flag --delete-old-source per eliminare definitivamente l'istanza blu dopo aver verificato la nuova istanza di produzione. Se non elimini l'istanza blu, continuerai a ricevere fatture per entrambe le istanze.