Esegui la migrazione da AWS a Google Cloud: esegui la migrazione da Amazon RDS per SQL Server a Cloud SQL per SQL Server

Last reviewed 2024-06-28 UTC

Google Cloud fornisce strumenti, prodotti, indicazioni e servizi professionali per eseguire la migrazione da Amazon Relational Database Service (RDS) a Cloud SQL per SQL Server.

Questo documento è rivolto agli amministratori di cloud e database che vogliono pianificare, implementare e convalidare un progetto di migrazione del database. È destinato anche ai decisori che stanno valutando l'opportunità di eseguire la migrazione e vogliono un esempio di come potrebbe essere una migrazione.

Questo documento si concentra su una migrazione di database omogenea, ovvero una migrazione in cui i database di origine e di destinazione utilizzano la stessa tecnologia di database. L'origine è Amazon RDS per SQL Server e la destinazione è Cloud SQL per SQL Server.

Questo documento fa parte di una serie in più parti sulla migrazione da AWS aGoogle Cloud che include i seguenti documenti:

• Inizia
• Esegui la migrazione da Amazon EC2 a Compute Engine
• Esegui la migrazione da Amazon S3 a Cloud Storage
• Esegui la migrazione da Amazon EKS a GKE
• Esegui la migrazione da Amazon RDS e Amazon Aurora per MySQL a Cloud SQL per MySQL
• Esegui la migrazione da Amazon RDS e Amazon Aurora per PostgreSQL a Cloud SQL per PostgreSQL e AlloyDB per PostgreSQL
• Esegui la migrazione da Amazon RDS per SQL Server a Cloud SQL per SQL Server (questo documento)
• Esegui la migrazione da AWS Lambda a Cloud Run

Per questa migrazione a Google Cloud, ti consigliamo di seguire il framework di migrazione descritto in Esegui la migrazione a Google Cloud: inizia.

Il seguente diagramma illustra il percorso di migrazione.

Potresti eseguire la migrazione dal tuo ambiente di origine a Google Cloud in una serie di iterazioni, ad esempio eseguendo prima la migrazione di alcuni workload e poi di altri. Per ogni singola iterazione della migrazione, segui le fasi del framework di migrazione generale:

1. Valuta e scopri i tuoi workload e i tuoi dati.
2. Pianifica e crea una base su Google Cloud.
3. Esegui la migrazione dei tuoi workload e dei tuoi dati su Google Cloud.
4. Ottimizza il tuo ambiente Google Cloud .

Per ulteriori informazioni sulle fasi di questo framework, consulta Esegui la migrazione a Google Cloud: inizia.

Per progettare un piano di migrazione efficace, ti consigliamo di convalidare ogni passaggio del piano e di assicurarti di avere una strategia di rollback. Per convalidare il tuo piano di migrazione, consulta Esegui la migrazione a Google Cloud: best practice per la convalida di un piano di migrazione.

Valuta l'ambiente di origine

Nella fase di valutazione, determini i requisiti e le dipendenze per eseguire la migrazione dell'ambiente di origine a Google Cloud.

La fase di valutazione è fondamentale per il successo della migrazione. Devi acquisire una conoscenza approfondita dei workload di cui vuoi eseguire la migrazione, dei loro requisiti, delle loro dipendenze e del tuo ambiente attuale. Devi comprendere il tuo punto di partenza per pianificare ed eseguire correttamente una migrazione a Google Cloud.

La fase di valutazione prevede le seguenti attività:

1. Crea un inventario completo dei tuoi workload.
2. Cataloga i workload in base alle loro proprietà e dipendenze.
3. Forma e istruisci i tuoi team su Google Cloud.
4. Crea esperimenti e proof of concept su Google Cloud.
5. Calcola il costo totale di proprietà (TCO) dell'ambiente di destinazione.
6. Scegli la strategia di migrazione per i tuoi workload.
7. Scegli gli strumenti di migrazione.
8. Definisci il piano e la cronologia della migrazione.
9. Convalida il piano di migrazione.

Per ulteriori informazioni sulla fase di valutazione e su queste attività, consulta Esegui la migrazione a Google Cloud: valuta e scopri i tuoi workload. Le sezioni seguenti si basano sulle informazioni contenute in questo documento.

La fase di valutazione del database ti aiuta a scegliere le dimensioni e le specifiche dell'istanza del database Cloud SQL di destinazione che corrisponde all'origine per esigenze di prestazioni simili. Presta particolare attenzione alle dimensioni del disco e al throughput, alle IOPS e al numero di vCPU. Le migrazioni potrebbero avere difficoltà o non riuscire a causa di un dimensionamento errato dell'istanza del database di destinazione. Un dimensionamento errato può comportare tempi di migrazione lunghi, problemi di prestazioni del database, errori del database e problemi di prestazioni dell'applicazione. Quando scegli l'istanza Cloud SQL, tieni presente che le prestazioni del disco si basano sulle dimensioni del disco e sul numero di vCPU.

Le sezioni seguenti si basano su Migra a Google Cloud: valuta e scopri i tuoi workload e integrano le informazioni contenute in quel documento.

Crea un inventario delle tue istanze Amazon RDS

Per definire l'ambito della migrazione, crea un inventario e raccogli informazioni sulle tue istanze Amazon RDS. Idealmente, il processo dovrebbe essere automatizzato, perché gli approcci manuali sono soggetti a errori e possono portare a ipotesi errate.

Amazon RDS e Cloud SQL potrebbero non avere funzionalità, specifiche delle istanze o operazioni simili. Alcune funzionalità potrebbero essere implementate in modo diverso o non essere disponibili. Le aree di differenza potrebbero includere infrastruttura, archiviazione, autenticazione e sicurezza, replica, backup, alta affidabilità, modello di capacità delle risorse e integrazioni ed estensioni di funzionalità specifiche del motore del database. A seconda del tipo di motore del database, delle dimensioni dell'istanza e dell'architettura, esistono anche differenze nei valori predefiniti delle impostazioni dei parametri del database.

Il benchmarking può aiutarti a comprendere meglio i workload di cui eseguire la migrazione e a definire l'architettura corretta dell'ambiente di destinazione della migrazione. Raccogliere informazioni sulle prestazioni è importante per stimare le esigenze di prestazioni dell'ambiente di destinazione Google Cloud . I concetti e gli strumenti di benchmarking sono descritti in dettaglio nella fase Esegui test e convalida del processo di migrazione, ma si applicano anche alla fase di creazione dell'inventario.

Strumenti per i test

Per una valutazione iniziale della tua infrastruttura attuale, ti consigliamo di utilizzare Google Cloud Migration Center insieme ad altri strumenti specializzati di valutazione dei database, come migVisor e Database Migration Assessment Tool (DMA).

Con Migration Center, puoi eseguire una valutazione completa del panorama delle tue applicazioni e dei tuoi database, inclusa l'idoneità tecnica per una migrazione del database a Google Cloud. Riceverai suggerimenti su dimensioni e configurazione per ogni database di origine e creerai un report sul costo totale di proprietà (TCO) per server e database.

Per ulteriori informazioni sulla valutazione dell'ambiente AWS utilizzando Migration Center, consulta Importa dati da altri cloud provider.

Oltre a Migration Center, puoi utilizzare lo strumento specializzato migVisor. migVisor supporta una varietà di motori del database ed è particolarmente adatto per le migrazioni eterogenee. Per un'introduzione a migVisor, consulta la panoramica di migVisor.

migVisor può identificare artefatti e funzionalità di database proprietari incompatibili che possono causare l'impostazione predefinita della migrazione e può indicare soluzioni alternative. migVisor può anche consigliare una soluzione Google Cloud target, tra cui il dimensionamento e l'architettura iniziali.

L'output della valutazione del database migVisor fornisce quanto segue:

• Rilevamento e analisi completi dei deployment di database attuali.
• Report dettagliato sulla complessità della migrazione, basato sulle funzionalità proprietarie utilizzate dal tuo database.
• Report finanziario con dettagli sui risparmi sui costi dopo la migrazione, sui costi di migrazione e sul nuovo budget operativo.
• Piano di migrazione in fasi per spostare i database e le applicazioni associate con un'interruzione minima dell'attività.

Per alcuni esempi di output di valutazione, consulta migVisor - Strumento di valutazione della migrazione al cloud.

Tieni presente che migVisor aumenta temporaneamente l'utilizzo del server di database. In genere, questo carico aggiuntivo è inferiore al 3% e può essere eseguito durante le ore non di punta.

L'output della valutazione di migVisor ti aiuta a creare un inventario completo delle tue istanze RDS. Il report include proprietà generiche (versione ed edizione del motore del database, CPU e dimensioni della memoria), nonché dettagli sulla topologia del database, sulle policy di backup, sulle impostazioni dei parametri e sulle personalizzazioni speciali in uso.

Se preferisci utilizzare strumenti open source, puoi utilizzare gli script di raccolta dati con (o al posto di) gli strumenti menzionati. Questi script possono aiutarti a raccogliere informazioni dettagliate (su workload, funzionalità, oggetti del database e codice del database) e a creare l'inventario del database. Inoltre, gli script di solito forniscono una valutazione dettagliata della migrazione del database, inclusa una stima dell'impegno richiesto.

Ti consigliamo lo strumento open source DMA, creato dagli ingegneri di Google. Offre una valutazione completa e accurata del database, incluse le funzionalità in uso, la logica del database e gli oggetti del database (tra cui schemi, tabelle, viste, funzioni, trigger e stored procedure).

Per utilizzare DMA, scarica gli script di raccolta per il tuo motore del database dal repository Git e segui le istruzioni. Invia i file di output a Google Cloud per l'analisi. Google Cloud crea e fornisce una lettura della valutazione del database e indica i passaggi successivi del percorso di migrazione.

Identifica e documenta l'ambito della migrazione e il tempo di inattività accettabile

In questa fase, documenterai le informazioni essenziali che influenzeranno la tua strategia di migrazione e gli strumenti. A questo punto, dovresti essere in grado di rispondere alle seguenti domande:

• I tuoi database sono più grandi di 5 TB?
• Nel tuo database sono presenti tabelle di grandi dimensioni? Sono più grandi di 16 TB?
• Dove si trovano i database (regioni e zone) e qual è la loro vicinanza alle applicazioni?
• Con quale frequenza cambiano i dati?
• Qual è il tuo modello di coerenza dei dati?
• Quali sono le opzioni per i database di destinazione?
• Qual è il livello di compatibilità tra i database di origine e di destinazione?
• I dati devono risiedere in alcune località fisiche?
• Esistono dati che possono essere compressi e archiviati o dati che non richiedono affatto la migrazione?

Per definire l'ambito della migrazione, decidi quali dati conservare e quali migrare. La migrazione di tutti i database potrebbe richiedere molto tempo e impegno. Alcuni dati potrebbero rimanere nei backup del database di origine. Ad esempio, le vecchie tabelle di logging o i dati di archiviazione potrebbero non essere necessari. In alternativa, potresti decidere di spostare i dati dopo il processo di migrazione, a seconda della strategia e degli strumenti.

Stabilisci delle baseline per la migrazione dei dati che ti aiutino a confrontare e valutare i risultati e gli impatti. Queste baseline sono punti di riferimento che rappresentano lo stato dei dati prima e dopo la migrazione e ti aiutano a prendere decisioni. È importante eseguire misurazioni nell'ambiente di origine che possano aiutarti a valutare l'esito della migrazione dei dati. Queste misurazioni includono:

• Le dimensioni e la struttura dei dati.
• La completezza e la coerenza dei dati.
• La durata e le prestazioni delle transazioni e dei processi aziendali più importanti.

Determina il tempo di inattività che puoi permetterti. Quali sono gli impatti aziendali dei tempi di inattività? Esistono periodi di bassa attività del database, durante i quali un numero inferiore di utenti è interessato dal tempo di inattività? In caso affermativo, quanto durano questi periodi e quando si verificano? Valuta la possibilità di avere un tempo di inattività parziale solo per la scrittura, mentre le richieste di sola lettura vengono comunque gestite.

Valuta il processo di deployment e amministrazione

Dopo aver creato gli inventari, valuta i processi operativi e di deployment del tuo database per determinare come adattarli per facilitare la migrazione. Questi processi sono fondamentali per la preparazione e la manutenzione dell'ambiente di produzione.

Pensa a come completi le seguenti attività:

• Definisci e applica policy di sicurezza per le tue istanze: ad esempio, potresti dover sostituire i gruppi di sicurezza di Amazon. Puoi utilizzare i ruoli Google IAM, le regole firewall VPC e i Controlli di servizio VPC per controllare l'accesso alle tue istanze Cloud SQL e limitare i dati all'interno di un VPC. Se prevedi di utilizzare l'autenticazione Windows con Cloud SQL per SQL Server, devi eseguire il deployment di Managed Microsoft AD e connetterti alla tua infrastruttura Active Directory esistente.
• Applica patch e configura le istanze: potrebbe essere necessario aggiornare gli strumenti di deployment esistenti. Ad esempio, potresti utilizzare impostazioni di configurazione personalizzate nei gruppi di parametri o nei gruppi di opzioni di Amazon. Potrebbe essere necessario adattare gli strumenti di provisioning per utilizzare Google Cloud Storage o Secret Manager per leggere questi elenchi di configurazione personalizzati.
• Gestisci l'infrastruttura di monitoraggio e avvisi: le categorie di metriche per le istanze di database di origine Amazon forniscono osservabilità durante il processo di migrazione. Le categorie di metriche potrebbero includere Amazon CloudWatch, Performance Insights, Monitoraggio avanzato ed elenchi di processi del sistema operativo.

Completa la valutazione

Dopo aver creato gli inventari dal tuo ambiente Amazon RDS, completa il resto delle attività della fase di valutazione, come descritto in Esegui la migrazione a Google Cloud: valuta e scopri i tuoi workload.

Pianifica e crea le tue basi

Nella fase di pianificazione e creazione, esegui il provisioning e la configurazione dell'infrastruttura per:

• Supporta i tuoi workload nel tuo ambiente Google Cloud .
• Collega l'ambiente di origine e l'ambiente Google Cloud per completare la migrazione.

La fase di pianificazione e creazione è composta dalle seguenti attività:

1. Creare una gerarchia delle risorse.
2. Configura Identity and Access Management (IAM) di Google Cloud.
3. Configura la fatturazione.
4. Configura la connettività di rete.
5. Rafforza la sicurezza.
6. Configura logging, monitoraggio e avvisi.

Per saperne di più su ciascuna di queste attività, consulta Esegui la migrazione a Google Cloud: pianifica e crea le tue basi.

Monitoraggio e avvisi

Utilizza Cloud Monitoring di Google, che include dashboard predefinite per diversi prodotti Google Cloud , tra cui una dashboard di monitoraggio di Cloud SQL. In alternativa, puoi valutare l'utilizzo di soluzioni di monitoraggio di terze parti integrate conGoogle Cloud, come Datadog e Splunk. Per saperne di più, consulta Informazioni sull'osservabilità del database.

Esegui la migrazione delle istanze Amazon RDS per SQL Server a Cloud SQL per SQL Server

Per eseguire la migrazione delle istanze, segui questi passaggi:

1. Scegli la strategia di migrazione: replica continua o manutenzione programmata.

2. Scegli gli strumenti di migrazione in base alla strategia e ai requisiti scelti.

3. Definisci il piano e la cronologia di migrazione per ogni migrazione di database, incluse le attività di preparazione ed esecuzione.

4. Definisci le attività di preparazione che devono essere eseguite per garantire il corretto funzionamento dello strumento di migrazione.

5. Definisci le attività di esecuzione, che includono le attività di lavoro che implementano la migrazione.

6. Definisci scenari di riserva per ogni attività di esecuzione.

7. Esegui test e convalida, che possono essere eseguiti in un ambiente di gestione temporanea separato.

8. Esegui la migrazione.

9. Esegui il cutover di produzione.

10. Eseguire la pulizia dell'ambiente di origine e configurare l'istanza target.

11. Eseguire l'ottimizzazione.

Ogni fase è descritta nelle sezioni seguenti.

Scegli la strategia di migrazione

In questa fase, hai informazioni sufficienti per valutare e selezionare una delle seguenti strategie di migrazione più adatta al tuo caso d'uso per ogni database:

• Manutenzione programmata (chiamata anche migrazione una tantum o migrazione big bang): questo approccio è ideale se puoi permetterti un tempo di inattività. Questa opzione ha costi e complessità relativamente inferiori, perché i workload e i servizi non richiedono un refactoring significativo. Tuttavia, se la migrazione non va a buon fine prima del completamento, devi riavviare il processo, il che prolunga il tempo di inattività.

• Replica continua (chiamata anche migrazione online o migrazione graduale): per i database mission-critical, questa opzione offre un rischio inferiore di perdita di dati e tempi di inattività prossimi allo zero. Le attività sono suddivise in più parti, quindi, se si verifica un errore, il rollback e la ripetizione richiedono meno tempo. Tuttavia, la configurazione è più complessa e richiede più pianificazione e tempo. È inoltre necessario un ulteriore sforzo per rifattorizzare le applicazioni che si connettono alle istanze del database. Valuta una delle seguenti varianti:

  • Utilizzando l'approccio Y (scrittura e lettura), che è una forma di migrazione parallela, i dati vengono duplicati sia nell'istanza di origine sia in quella di destinazione durante la migrazione.
  • Utilizzando un microservizio di accesso ai dati, che riduce lo sforzo di rifattorizzazione richiesto dall'approccio Y (scrittura e lettura).

Per saperne di più sulle strategie di migrazione dei dati, consulta Valutazione degli approcci alla migrazione dei dati.

Il seguente diagramma mostra un diagramma di flusso basato su domande di esempio che potresti porti quando decidi la strategia di migrazione per un singolo database:

Il diagramma di flusso precedente mostra i seguenti punti decisionali:

• Puoi permetterti tempi di inattività?

  • In caso contrario, adotta la strategia di migrazione con replica continua.
  • In caso affermativo, vai al punto decisionale successivo.

• Puoi permetterti il tempo di inattività rappresentato dalla finestra di cutover durante la migrazione dei dati? La finestra di cutover rappresenta il tempo necessario per eseguire un backup del database, trasferirlo in Cloud SQL, ripristinarlo e quindi cambiare le applicazioni.

  • In caso contrario, adotta la strategia di migrazione con replica continua.
  • In caso affermativo, adotta la strategia di migrazione per la manutenzione pianificata.

Le strategie potrebbero variare per database diversi, anche se si trovano sulla stessa istanza. Una combinazione di strategie può produrre risultati ottimali. Ad esempio, esegui la migrazione di database di piccole dimensioni e utilizzati di rado utilizzando l'approccio della manutenzione pianificata, ma utilizza la replica continua per i database mission-critical in cui i tempi di inattività sono costosi.

In genere, una migrazione viene considerata completata quando avviene il passaggio dall'istanza di origine iniziale all'istanza target. Qualsiasi replica (se utilizzata) viene interrotta e tutte le operazioni di lettura e scrittura vengono eseguite sull'istanza target. Il passaggio quando entrambe le istanze sono sincronizzate significa che non si verifica alcuna perdita di dati e che il tempo di inattività è minimo.

Per saperne di più sulle strategie e sui deployment di migrazione dei dati, consulta Classificazione delle migrazioni dei database.

Riduci al minimo i tempi di inattività e gli impatti correlati alla migrazione

Le configurazioni di migrazione che non prevedono tempi di inattività delle applicazioni richiedono una configurazione più complessa. Trova il giusto equilibrio tra la complessità della configurazione e i tempi di inattività pianificati durante gli orari di apertura con traffico ridotto.

Ogni strategia di migrazione presenta un compromesso e un impatto associato al processo di migrazione. Ad esempio, i processi di replica comportano un carico aggiuntivo sulle istanze di origine e le applicazioni potrebbero essere interessate da un ritardo di replica. Le applicazioni (e i clienti) potrebbero dover attendere durante il tempo di inattività dell'applicazione, almeno per la durata del ritardo di replica, prima di utilizzare il nuovo database. In pratica, i seguenti fattori potrebbero aumentare i tempi di inattività:

• Il completamento delle query del database può richiedere alcuni secondi. Al momento della migrazione, le query in corso potrebbero essere interrotte.
• Il riempimento della cache potrebbe richiedere del tempo se il database è di grandi dimensioni o ha una memoria buffer sostanziale.
• Le applicazioni arrestate nell'origine e riavviate in Google Cloud potrebbero presentare un piccolo ritardo fino a quando non viene stabilita la connessione all'istanza del database Google Cloud.
• I percorsi di rete verso le applicazioni devono essere modificati. A seconda di come sono configurate le voci DNS, l'operazione potrebbe richiedere un po' di tempo. Quando aggiorni i record DNS, riduci il TTL prima della migrazione.

Le seguenti pratiche comuni possono contribuire a ridurre al minimo i tempi di inattività e l'impatto:

• Trova un periodo di tempo in cui il tempo di inattività avrebbe un impatto minimo sui tuoi workload. Ad esempio, al di fuori del normale orario di apertura, durante i fine settimana o in altri periodi di manutenzione pianificati.
• Identifica le parti dei tuoi workload che possono essere sottoposte a migrazione e cutover di produzione in fasi diverse. Le tue applicazioni potrebbero avere componenti diversi che possono essere isolati, adattati e migrati senza alcun impatto. Ad esempio, frontend, moduli CRM, servizi di backend e piattaforme di reporting. Questi moduli potrebbero avere i propri database, di cui è possibile pianificare la migrazione prima o dopo nel processo.
• Se puoi permetterti una certa latenza sul database di destinazione, valuta la possibilità di implementare una migrazione graduale. Utilizza trasferimenti di dati incrementali e in batch e adatta parte dei tuoi workload per lavorare con i dati obsoleti nell'istanza di destinazione.
• Valuta la possibilità di rifattorizzare le tue applicazioni per ridurre al minimo l'impatto della migrazione. Ad esempio, adatta le tue applicazioni per scrivere sia nei database di origine che in quelli di destinazione e, di conseguenza, implementa una replica a livello di applicazione.

Scegli gli strumenti di migrazione

Il fattore più importante per una migrazione riuscita è la scelta dello strumento di migrazione giusto. Una volta decisa la strategia di migrazione, esamina e scegli lo strumento di migrazione.

Sono disponibili molti strumenti, ognuno ottimizzato per determinati casi d'uso di migrazione. I casi d'uso possono includere:

• Strategia di migrazione (manutenzione pianificata o replica continua).
• Motori del database di origine e di destinazione e versioni dei motori.
• Ambienti in cui si trovano le istanze di origine e le istanze target.
• Dimensioni del database. Più grande è il database, più tempo è necessario per eseguire la migrazione del backup iniziale.
• Frequenza delle modifiche al database.
• Disponibilità a utilizzare servizi gestiti per la migrazione.

Per garantire una migrazione e un cutover senza interruzioni, puoi utilizzare pattern di deployment delle applicazioni, orchestrazione dell'infrastruttura e applicazioni di migrazione personalizzate. Tuttavia, strumenti specializzati chiamati servizi di migrazione gestiti possono facilitare il processo di spostamento di dati, applicazioni o persino intere infrastrutture da un ambiente all'altro. Eseguono l'estrazione dei dati dai database di origine, li trasportano in modo sicuro ai database di destinazione e, facoltativamente, possono modificarli durante il transito. Con queste funzionalità, incapsulano la logica complessa della migrazione e offrono funzionalità di monitoraggio della migrazione.

I servizi di migrazione gestiti offrono i seguenti vantaggi:

• Riduci al minimo i tempi di inattività: i servizi utilizzano le funzionalità di replica integrate dei motori di database, se disponibili, ed eseguono la promozione della replica.

• Garantire l'integrità e la sicurezza dei dati: i dati vengono trasferiti in modo sicuro e affidabile dal database di origine a quello di destinazione.

• Offrire un'esperienza di migrazione coerente: diverse tecniche e pattern di migrazione possono essere consolidati in un'interfaccia comune e coerente utilizzando i file eseguibili di migrazione del database, che puoi gestire e monitorare.

• Offri modelli di migrazione resilienti e collaudati: le migrazioni dei database sono eventi rari ma critici. Per evitare errori da principianti e problemi con le soluzioni esistenti, puoi utilizzare gli strumenti di esperti con esperienza, anziché creare una soluzione personalizzata.

• Ottimizza i costi: i servizi di migrazione gestiti possono essere più convenienti rispetto al provisioning di server e risorse aggiuntivi per soluzioni di migrazione personalizzate.

Le sezioni successive descrivono i suggerimenti per lo strumento di migrazione, che dipendono dalla strategia di migrazione scelta.

Strumenti per le migrazioni per manutenzione pianificata

Le sezioni seguenti descrivono gli strumenti che possono essere utilizzati per le migrazioni una tantum, insieme alle relative limitazioni e best practice.

Backup del motore del database integrati

Quando è accettabile un tempo di inattività significativo e i database di origine sono relativamente statici, puoi utilizzare le funzionalità di backup e ripristino integrate del motore del database.

La configurazione e la sincronizzazione richiedono un certo impegno, soprattutto per un numero elevato di database, ma i backup del motore del database sono in genere facilmente disponibili e semplici da utilizzare. Questo approccio è adatto a qualsiasi dimensione del database ed è solitamente più efficace di altri strumenti per le istanze di grandi dimensioni.

I backup del motore del database presentano le seguenti limitazioni generali:

• I backup possono essere soggetti a errori, in particolare se eseguiti manualmente.
• I dati non sono protetti se i backup non vengono gestiti correttamente.
• I backup non dispongono di funzionalità di monitoraggio adeguate.

Se scegli questo approccio, tieni conto delle seguenti limitazioni e best practice:

• Per i backup di database di dimensioni superiori a 5 TB, utilizza un backup sottoposto a striping (un backup di più file).
• Quando utilizzi un backup sottoposto a striping, non puoi eseguire il backup o il ripristino da più di 10 file di backup contemporaneamente.
• Devi eseguire il backup in un bucket Amazon S3 nella stessa regione Amazon dell'istanza del database di origine.
• I backup non includono gli accessi, le autorizzazioni e i ruoli del server SQL Server, perché si trovano a livello di istanza. Per trasferire questo tipo di dati dall'istanza di origine all'istanza target, utilizza script PowerShell o strumenti come DBAtools.

Per informazioni dettagliate su limitazioni e best practice, consulta Best practice per l'importazione e l'esportazione dei dati con Cloud SQL per SQL Server e Problemi noti di Cloud SQL per SQL Server.

Altri approcci per le migrazioni per manutenzione pianificata

L'utilizzo di altri approcci potrebbe offrire un maggiore controllo e una maggiore flessibilità nel processo di migrazione per la manutenzione pianificata.

Ad esempio, utilizzando file flat per esportare e importare i dati (o utilizzando script personalizzati), puoi:

• Eseguire trasformazioni, controlli o altre operazioni sui dati durante la migrazione. Ad esempio, convalide, aggregazione o normalizzazione e denormalizzazione dei dati di origine.
• Scegli le strutture di cui vuoi eseguire la migrazione e quelle che vuoi lasciare indietro. Potresti decidere di estrarre solo un sottoinsieme delle tue tabelle in file flat per l'importazione.
• Scegli di filtrare i dati in base a dominio, origine, età o altri criteri personalizzati. Ad esempio, potresti escludere i dati che raggiungono una soglia di età e archiviarli in file o nel backup finale del database di origine prima della migrazione.
• Rifattorizza le strutture del database e sincronizza i tempi di inattività con quelli della migrazione.
• Consolidare più istanze o database in un'unica istanza o database per ridurre i costi operativi e semplificare i problemi di scalabilità. Ad esempio, potresti voler cambiare il tuo approccio passando da un'istanza, un database o uno schema per cliente a una singola struttura di database ottimizzata per la multitenancy.

Altri approcci includono:

• Utilizza file CSV o JSON: con questo approccio, estrai i dati del database nei file e poi li importi nelle istanze target.

  • Sebbene sia generalmente più lento, questo metodo ti aiuta a eseguire la migrazione di un sottoinsieme di tabelle (o di dati all'interno di una determinata tabella).
  • I formati CSV e JSON sono supportati da molti strumenti.
  • Se automatizzi il processo, hai la possibilità di passare a una migrazione con replica continua in batch.

• Utilizza l'Import and Export Wizard di SQL Server di Microsoft: questo strumento utilizza SQL Server Integration Services (SSIS) e consente di importare dati da varie origini, come altri motori di database o file flat.

• Utilizza la procedura guidata Genera e pubblica script di SQL Server e l'utilità bcp: questo strumento fa parte di Microsoft SQL Server Management Studio.

  • Questo approccio ti consente di creare script per l'intero schema del database o solo per parti di questo.
  • L'utilità bcp consente di creare script per i dati ed esportarli in file.

• Utilizza la replica degli snapshot se l'origine utilizza Amazon RDS Standard:

  • Con questo approccio, ripristini il backup SQL Server dell'istanza RDS in un'altra istanza autonoma di SQL Server su Compute Engine. Quindi, utilizza la replica di snapshot per eseguire la migrazione a Cloud SQL per SQL Server.
  • La generazione di snapshot mantiene i blocchi sulle tabelle di origine, il che potrebbe influire sui workload.
  • La replica degli snapshot potrebbe introdurre carichi aggiuntivi sul server Amazon RDS.
  • Tuttavia, puoi scegliere quali oggetti migrare o replicare, il che offre flessibilità.
  • Per maggiori dettagli, consulta Migrazione dei dati da SQL Server 2017 a Cloud SQL per SQL Server utilizzando la replica di snapshot.

Strumenti per le migrazioni con replica continua

Il seguente diagramma mostra un diagramma di flusso con domande che possono aiutarti a scegliere lo strumento di migrazione per un singolo database, quando utilizzi una strategia di migrazione con replica continua:

Il diagramma di flusso precedente mostra i seguenti punti decisionali:

• Preferisci utilizzare servizi di migrazione gestiti?

  • In caso affermativo, vai alla decisione successiva. Se puoi permetterti un tempo di inattività minimo e non hai bisogno della trasformazione dei dati o della sincronizzazione in tempo reale, ti consigliamo Database Migration Service. In caso contrario, esplora le opzioni di terze parti.
  • In caso contrario, vai alla decisione successiva. Se la replica integrata del motore del database è supportata, ti consigliamo di utilizzarla. In caso contrario, ti consigliamo di esplorare altre opzioni di migrazione.

• Puoi permetterti un tempo di inattività minimo ed eseguire la migrazione senza trasformazione dei dati o sincronizzazione in tempo reale?

  • In caso affermativo, ti consigliamo Database Migration Service.
  • In caso contrario, esplora le opzioni di terze parti.

• È supportata la replica integrata specifica del motore del database?

  • In questo caso, ti consigliamo di utilizzare la replica integrata.
  • In caso contrario, ti consigliamo di esplorare altre opzioni di migrazione.

Le sezioni seguenti descrivono gli strumenti che possono essere utilizzati per le migrazioni con replica continua, insieme alle relative limitazioni e best practice.

Database Migration Service per la migrazione con replica continua

Database Migration Service supporta le migrazioni omogenee a Cloud SQL per SQL Server quando l'origine è Amazon RDS.

Database Migration Service è uno strumento semplice ed economico. Consigliamo Database Migration Service per le situazioni con le seguenti circostanze:

• Puoi permetterti tempi di inattività minimi.
• Non hai bisogno della sincronizzazione in tempo reale.
• Non è necessario eseguire trasformazioni dei dati durante la migrazione.

Se scegli questo strumento, tieni presente le seguenti limitazioni e best practice:

• La durata del tempo di inattività dipende dalla frequenza dei backup del log delle transazioni.
• I backup non includono gli accessi, le autorizzazioni o i ruoli del server SQL Server, perché si trovano a livello di istanza. Crea uno script dall'istanza di origine, quindi trasferiscilo all'istanza target utilizzando script PowerShell o strumenti come DBAtools.

Per un elenco completo delle limitazioni, consulta Limitazioni note.

Replica integrata del motore del database

Cloud SQL supporta la replica per SQL Server. Tuttavia, Amazon RDS for SQL Server Standard può essere solo un sottoscrittore. La replica integrata da Amazon RDS Standard non è disponibile. Solo Amazon RDS Custom per SQL Server può essere configurato come publisher integrato.

Per un elenco delle funzionalità supportate e non supportate su Amazon RDS, consulta Amazon RDS per Microsoft SQL Server.

Altri approcci per la migrazione con replica continua

Altri approcci di migrazione con replica continua includono:

• Rifattorizza le tue applicazioni per eseguire Y (scrittura e lettura) o utilizza un microservizio di accesso ai dati.

  • La replica continua viene eseguita dalle tue applicazioni.
  • L'attività di migrazione si concentra sul refactoring o sullo sviluppo di strumenti che si connettono alle istanze del database.
  • Le applicazioni di lettura vengono quindi rifattorizzate e sottoposte a deployment gradualmente per utilizzare l'istanza target.

• Implementa funzioni che eseguono periodicamente query sui dati nell'istanza di origine, filtrano solo i nuovi dati e li scrivono in file CSV, JSON o Parquet.

  • Questi file vengono archiviati in un bucket Google Cloud Storage.
  • I file possono essere scritti immediatamente nell'istanza di database di destinazione utilizzando Cloud Run Functions.
  • Le funzionalità di Change Data Capture (CDC) possono aiutarti a ottenere una migrazione con replica quasi in tempo reale.
  • Puoi eseguire lo streaming di CDC in un data lake Amazon S3 in formato Parquet utilizzando AWS Database Migration Service (AWS DMS).
  • Puoi avere un'implementazione personalizzata per leggere i file e scrivere i relativi contenuti in Cloud SQL.

Strumenti di terze parti per le migrazioni con replica continua

In alcuni casi, potrebbe essere meglio utilizzare uno strumento di terze parti per la maggior parte dei motori di database. Ad esempio, se preferisci utilizzare un servizio di migrazione gestito e devi assicurarti che il database di destinazione sia sempre sincronizzato quasi in tempo reale con l'origine o se hai bisogno di trasformazioni più complesse come la pulizia, la ristrutturazione e l'adattamento dei dati durante il processo di migrazione.

Se decidi di utilizzare uno strumento di terze parti, scegli uno dei seguenti consigli, che puoi utilizzare per la maggior parte dei motori di database.

Striim è una piattaforma in-memory end-to-end per la raccolta, il filtro, la trasformazione, l'arricchimento, l'aggregazione, l'analisi e la distribuzione dei dati in tempo reale:

• Vantaggi:

  • Gestisce grandi volumi di dati e migrazioni complesse.
  • Change Data Capture integrato per SQL Server.
  • Modelli di connessione preconfigurati e pipeline no-code.
  • In grado di gestire database di grandi dimensioni mission-critical che operano con un carico transazionale elevato.
  • Consegna "exactly-once".

• Svantaggi:

  • Non open source.
  • Può diventare costoso, soprattutto per le migrazioni lunghe.
  • Alcune limitazioni nella propagazione delle operazioni DDL (Data Definition Language). Per saperne di più, consulta Operazioni DDL supportate e Note e limitazioni sull'evoluzione dello schema.

Per saperne di più su Striim, consulta Esecuzione di Striim in Google Cloud.

Debezium è una piattaforma distribuita open source per CDC e può trasmettere in streaming le modifiche ai dati agli iscritti esterni:

• Vantaggi:

  • Open source.
  • Forte assistenza dalla community.
  • Convenienza.
  • Controllo granulare su righe, tabelle o database.
  • Specializzato nell'acquisizione delle modifiche in tempo reale dai log delle transazioni del database.

• Svantaggi:

  • Richiede un'esperienza specifica con Kafka e ZooKeeper.
  • Distribuzione "at-least-once" delle modifiche ai dati, il che significa che devi gestire i duplicati.
  • Configurazione manuale del monitoraggio utilizzando Grafana e Prometheus.
  • Nessun supporto per la replica batch incrementale.

Per saperne di più sulle migrazioni di Debezium, consulta Replica dei dati quasi in tempo reale utilizzando Debezium.

Fivetran è una piattaforma di spostamento dei dati automatizzato per spostare i dati da e verso piattaforme di dati cloud.

• Vantaggi:

  • Modelli di connessione preconfigurati e pipeline no-code.
  • Propaga eventuali modifiche allo schema dal database di origine a quello di destinazione.
  • Consegna "exactly-once" delle modifiche ai dati, il che significa che non è necessario gestire i duplicati.

• Svantaggi:

  • Non open source.
  • Il supporto per la trasformazione di dati complessi è limitato.

Definisci il piano e la cronologia della migrazione

Per una migrazione del database e un cutover di produzione di successo, ti consigliamo di preparare un piano di migrazione completo e ben definito. Per ridurre l'impatto sulla tua attività, ti consigliamo di creare un elenco di tutte le attività necessarie.

La definizione dell'ambito della migrazione rivela le attività di lavoro che devi svolgere prima, durante e dopo il processo di migrazione del database. Ad esempio, se decidi di non eseguire la migrazione di determinate tabelle da un database, potresti aver bisogno di attività pre-migrazione o post-migrazione per implementare questo filtro. Inoltre, ti assicuri che la migrazione del database non influisca sull'accordo sul livello del servizio (SLA) esistente e sul piano di continuità aziendale.

Ti consigliamo di includere nella documentazione di pianificazione della migrazione i seguenti documenti:

• Documento di progettazione tecnica (TDD)
• Matrice RACI
• Timeline (ad esempio un piano T-Minus)

Le migrazioni dei database sono un processo iterativo e le prime migrazioni sono spesso più lente di quelle successive. In genere, le migrazioni ben pianificate vengono eseguite senza problemi, ma possono comunque verificarsi problemi imprevisti. Ti consigliamo di avere sempre un piano di rollback. Come best practice, segui le indicazioni riportate in Esegui la migrazione a Google Cloud: best practice per la convalida di un piano di migrazione.

TDD

Il TDD documenta tutte le decisioni tecniche da prendere per il progetto. Includi quanto segue nel TDD:

• Requisiti aziendali e criticità
• Recovery Time Objective (RTO)
• Recovery Point Objective (RPO)
• Dettagli della migrazione del database
• Stime dell'impegno per la migrazione
• Suggerimenti per la convalida della migrazione

Matrice RACI

Alcuni progetti di migrazione richiedono una matrice RACI, un documento di gestione dei progetti comune che definisce quali individui o gruppi sono responsabili delle attività e dei risultati finali all'interno del progetto di migrazione.

Cronologia

Prepara una cronologia per ogni database di cui eseguire la migrazione. Includi tutte le attività di lavoro che devono essere eseguite, le date di inizio definite e le date di fine stimate.

Per ogni ambiente di migrazione, ti consigliamo di creare un piano T-minus. Un piano T-minus è strutturato come un programma di conto alla rovescia ed elenca tutte le attività necessarie per completare il progetto di migrazione, insieme ai gruppi responsabili e alla durata stimata.

La cronologia deve tenere conto non solo dell'esecuzione delle attività di preparazione pre-migrazione, ma anche delle attività di convalida, controllo o test che si verificano dopo il trasferimento dei dati.

La durata delle attività di migrazione dipende in genere dalle dimensioni del database, ma ci sono anche altri aspetti da considerare, come la complessità della logica di business, l'utilizzo delle applicazioni e la disponibilità del team.

Un piano T-Minus potrebbe essere simile al seguente:

Data	Fase	Categoria	Tasks	Ruolo	T-minus	Stato
1/11/2023	Pre-migrazione	Valutazione	Crea report di valutazione	Team di Discovery	-21	Completa
7/11/2023	Pre-migrazione	Preparazione della destinazione	Progetta l'ambiente di destinazione come descritto nel documento di progettazione	Team di migrazione	-14	Completa
15/11/2023	Pre-migrazione	Governance aziendale	Data di migrazione e approvazione T-Minus	Leadership	-6	Completa
18/11/2023	Migrazione	Configura DMS	Crea profili di connessione	Cloud Migration Engineer	-3	Completa
19/11/2023	Migrazione	Configura DMS	Crea e avvia i job di migrazione	Cloud Migration Engineer	-2	Non avviato
19/11/2023	Migrazione	Monitora DMS	Monitora i job DMS e le modifiche DDL nell'istanza di origine	Cloud Migration Engineer	-2	Non avviato
21/11/2023	Migrazione	Esegui il cutover di DMS	Promuovi la replica DMS	Cloud Migration Engineer	0	Non avviato
21/11/2023	Migrazione	Convalida della migrazione	Convalida della migrazione del database	Team di migrazione	0	Non avviato
21/11/2023	Migrazione	Test dell'applicazione	Esegui test di funzionalità e prestazioni	Team di migrazione	0	Non avviato
22/11/2023	Migrazione	Governance aziendale	Convalida della migrazione: GO o NO GO	Team di migrazione	1	Non avviato
23/11/2023	Dopo la migrazione	Convalida il monitoraggio	Configura il monitoraggio	Team dell'infrastruttura	2	Non avviato
25/11/2023	Dopo la migrazione	Sicurezza	Rimuovi l'account utente DMS	Team di sicurezza	4	Non avviato

Migrazioni di più database

Se hai più database di cui eseguire la migrazione, il piano di migrazione deve contenere attività per tutte le migrazioni.

Ti consigliamo di iniziare il processo eseguendo la migrazione di un database più piccolo, idealmente non mission-critical. Questo approccio può aiutarti ad acquisire conoscenze e fiducia nel processo di migrazione e negli strumenti. Puoi anche rilevare eventuali difetti del processo nelle prime fasi della pianificazione complessiva della migrazione.

Se devi eseguire la migrazione di più database, le tempistiche possono essere parallelizzate. Ad esempio, per velocizzare il processo di migrazione, puoi scegliere di eseguire la migrazione di un gruppo di database piccoli, statici o meno critici per l'attività contemporaneamente, come mostrato nel seguente diagramma.

Nell'esempio mostrato nel diagramma, i database 1-4 sono un gruppo di piccoli database di cui viene eseguita la migrazione contemporaneamente.

Definisci le attività di preparazione

Le attività di preparazione sono tutte le attività che devi completare per soddisfare i prerequisiti della migrazione. Se non completi le attività di preparazione, la migrazione non può essere eseguita o il database di cui è stata eseguita la migrazione potrebbe essere inutilizzabile.

Le attività di preparazione possono essere classificate come segue:

• Preparativi e prerequisiti per l'istanza Amazon RDS
• Preparazione e prerequisiti del database di origine
• Configurazione di Cloud SQL
• Configurazione specifica per la migrazione

Preparazione e prerequisiti dell'istanza Amazon RDS

Considera le seguenti attività comuni di configurazione e prerequisiti:

• A seconda del percorso di migrazione, potrebbe essere necessario consentire le connessioni remote alle istanze RDS. Se l'istanza RDS è configurata per essere privata nel VPC, deve esistere una connettività RFC 1918 privata tra Amazon e Google Cloud.

• Potresti dover configurare un nuovo gruppo di sicurezza per consentire le connessioni remote sulle porte richieste.

  • Per impostazione predefinita, in AWS l'accesso alla rete è disattivato per le istanze di database.
  • Puoi specificare regole in un gruppo di sicurezza che consentono l'accesso da un intervallo di indirizzi IP, una porta o un gruppo di sicurezza. Le stesse regole si applicano a tutte le istanze di database associate a quel gruppo di sicurezza.

• Per la replica continua (modifiche in streaming tramite CDC), devi utilizzare un'istanza RDS completa e non una replica di lettura, con CDC abilitato. Per maggiori dettagli, consulta Utilizzo di Change Data Capture con SQL Server.

• Se utilizzi strumenti di terze parti, in genere sono necessarie impostazioni e configurazioni preliminari prima di utilizzare lo strumento. Consulta la documentazione dello strumento di terze parti.

Preparazione e prerequisiti del database di origine

• Assicurati che il database di origine disponga di spazio di archiviazione buffer e memoria disponibili durante le operazioni di migrazione. Ad esempio, se utilizzi file di backup dei log delle transazioni, monitora l'utilizzo dello spazio di archiviazione e assicurati di avere spazio di archiviazione aggiuntivo per il buffer.
• Documenta le impostazioni dei parametri del database e applicale all'istanza target prima di eseguire i test e la convalida della migrazione.

• Esegui misurazioni di riferimento sull'ambiente di origine in uso in produzione. Considera quanto segue:

  • Misura le dimensioni dei dati e le prestazioni del workload. Quanto tempo richiedono in media le query o le transazioni importanti? Quanto tempo durante i periodi di picco?
  • Documenta le misurazioni di riferimento per un confronto successivo, in modo da decidere se la fedeltà della migrazione del database è soddisfacente. Decidi se puoi cambiare i workload di produzione e dismettere l'ambiente di origine o se ne hai ancora bisogno per scopi di fallback.

Configurazione di Cloud SQL

Scegli con attenzione le dimensioni e le specifiche dell'istanza di database Cloud SQL di destinazione in modo che corrispondano all'origine per esigenze di prestazioni simili. Presta particolare attenzione alle dimensioni e al throughput del disco, alle IOPS e al numero di vCPU. Un dimensionamento errato può comportare tempi di migrazione lunghi, problemi di prestazioni del database, errori del database e problemi di prestazioni delle applicazioni.

Assicurati che la destinazione sia quella corretta. È importante notare che le opzioni di configurazione di Amazon RDS potrebbero variare rispetto a quelle di Cloud SQL. Nel caso in cui Cloud SQL non soddisfi i tuoi requisiti, prendi in considerazione opzioni che includono database su Compute Engine.

Prima di creare le istanze Cloud SQL, devi confermare le seguenti proprietà e i seguenti requisiti, perché non possono essere modificati in un secondo momento senza ricrearle.

• Scegli attentamente il progetto e la regione delle istanze Cloud SQL di destinazione. Non è possibile eseguire la migrazione delle istanze Cloud SQL tra progetti e regioni Google Cloud senza trasferimento di dati.

• Esegui la migrazione a una versione principale corrispondente su Cloud SQL. Ad esempio, se l'origine utilizza SQL Server 15.0, esegui la migrazione a Cloud SQL per SQL Server 15.0. Se le versioni sono diverse, l'impostazione del livello di compatibilità deve essere la stessa per garantire le stesse funzionalità del motore.

• Replica le informazioni utente separatamente se utilizzi i backup integrati del motore del database o Database Migration Service. Per maggiori dettagli, consulta le limitazioni nella sezione Backup specifici del motore del database.

• Esamina i flag di configurazione specifici del motore del database e confronta i valori delle istanze di origine e dell'istanza target. Assicurati di comprenderne l'impatto e se devono essere uguali o meno. Ad esempio, ti consigliamo di confrontare i valori nella vista sys.configurations del database di origine con i valori nell'istanza Cloud SQL. Tieni presente che non tutti i flag devono essere uguali e non tutte le modifiche ai flag sono consentite su un'istanza Cloud SQL.

Per saperne di più sulla configurazione di Cloud SQL, consulta quanto segue:

• Best practice generali per SQL Server
• Opzioni di configurazione delle istanze per SQL Server
• Flag specifici del motore del database per SQL Server

Configurazione specifica per la migrazione

Se utilizzi l'esportazione e l'importazione di file per eseguire la migrazione o se utilizzi lo strumento di migrazione di Database Migration Service, devi creare un bucket Cloud Storage. Il bucket archivia i file di backup del database e dei log delle transazioni. Per ulteriori informazioni sull'utilizzo di Database Migration Service, consulta Archivia i file di backup in un bucket Cloud Storage.

Se utilizzi la replica, devi assicurarti che la replica Cloud SQL abbia accesso al database primario. Questa operazione può essere eseguita tramite le opzioni di connettività documentate.

A seconda dello scenario e della criticità, potrebbe essere necessario implementare uno scenario di fallback, che di solito include l'inversione della direzione della replica. In questo caso, potresti aver bisogno di un meccanismo di replica aggiuntivo da Cloud SQL alla tua istanza Amazon di origine.

Per la maggior parte degli strumenti di terze parti, devi eseguire il provisioning di risorse specifiche per la migrazione. Ad esempio, per Striim, devi utilizzare Google Cloud Marketplace per iniziare. Poi, per configurare l'ambiente di migrazione in Striim, puoi utilizzare Flow Designer per creare e modificare le applicazioni oppure puoi selezionare un modello preesistente. Le applicazioni possono anche essere programmate utilizzando il linguaggio di programmazione Tungsten Query Language (TQL). Utilizzando una dashboard di convalida dei dati, puoi ottenere una rappresentazione visiva dei dati gestiti dalla tua applicazione Striim.

Puoi dismettere le risorse che connettono il tuo ambiente Amazon e Google Cloud al termine della migrazione e della convalida.

Definisci le attività di esecuzione

Le attività di esecuzione implementano il lavoro di migrazione vero e proprio. Le attività dipendono dallo strumento di migrazione scelto, come descritto nelle sottosezioni seguenti.

Backup del motore del database integrati

Per ulteriori informazioni e istruzioni sui backup specifici del database, consulta Importa i dati da un file BAK in Cloud SQL per SQL Server ed Esportazione dei dati da RDS per SQL Server. Per saperne di più su come automatizzare i caricamenti dei file di log delle transazioni, consulta Pianifica i caricamenti dei file di log delle transazioni per Amazon RDS.

Job di migrazione di Database Migration Service

Definisci e configura i job di migrazione in Database Migration Service per eseguire la migrazione dei dati da un'istanza di origine al database di destinazione. I job di migrazione si connettono all'istanza del database di origine tramite profili di connessione definiti dall'utente.

Testa tutti i prerequisiti per assicurarti che il job possa essere eseguito correttamente. Scegli un momento in cui i tuoi workload possono permettersi un breve tempo di inattività per la migrazione e il cutover di produzione.

Il processo di migrazione prevede in genere le seguenti attività:

• Esporta un backup completo del database di origine, quindi caricalo in un bucket Cloud Storage.
• Esegui un backup dei file di log delle transazioni, quindi caricalo nello stesso bucket Cloud Storage. Per saperne di più su come automatizzare questa procedura, consulta Pianifica i caricamenti dei file di log delle transazioni per Amazon RDS.
• In Database Migration Service, monitori l'elaborazione dei backup dei log delle transazioni.
• Interrompi la scrittura nel database di origine.
• Attendi la sincronizzazione dell'origine e della destinazione, ovvero l'elaborazione del backup finale del log delle transazioni.
• Interrompi la replica in corso e promuovi il job di migrazione.Con la promozione di un job di migrazione, l'istanza Cloud SQL di destinazione viene disconnessa dall'istanza del database di origine e poi promossa a istanza principale.
• Esegui il deployment delle applicazioni che puntano al nuovo database di destinazione.

Per una procedura dettagliata di configurazione della migrazione, consulta Esegui la migrazione dei database SQL Server a Cloud SQL per SQL Server.

Replica integrata del motore del database

Se utilizzi Amazon RDS Standard, potresti dover prima eseguire la migrazione alla versione Amazon RDS Custom e poi la replica in Cloud SQL.

Cloud SQL supporta la replica per SQL Server. Per saperne di più sulla replica da un server esterno, consulta Migrazione dei dati da SQL Server 2017 a Cloud SQL per SQL Server utilizzando la replica di snapshot.

Strumenti di terze parti

Definisci le attività di esecuzione per lo strumento di terze parti che hai scelto. Ad esempio, se decidi di utilizzare Striim, devi creare app nel tuo spazio dei nomi e configurare il lettore CDC per connetterti all'istanza Amazon. Per maggiori dettagli, consulta la sezione sulla configurazione di SQL Server nella documentazione di Striim.

Definisci gli scenari di riserva

Definisci attività di riserva per ogni attività di esecuzione della migrazione, per proteggerti da problemi imprevisti che potrebbero verificarsi durante il processo di migrazione. Le attività di riserva di solito dipendono dalla strategia di migrazione e dagli strumenti utilizzati.

Il fallback potrebbe richiedere un impegno significativo. Come best practice, non eseguire il cutover di produzione finché i risultati dei test non sono soddisfacenti. Sia la migrazione del database sia lo scenario di fallback devono essere testati correttamente per evitare un'interruzione grave.

Definisci i criteri di successo e assegna un intervallo di tempo a tutte le attività di esecuzione della migrazione. Eseguire un dry run della migrazione aiuta a raccogliere informazioni sui tempi previsti per ogni attività. Ad esempio, per una migrazione di manutenzione pianificata, puoi permetterti il tempo di inattività rappresentato dalla finestra di cutover. Tuttavia, è importante pianificare l'azione successiva nel caso in cui il job di migrazione una tantum o il ripristino del backup non vada a buon fine. A seconda del tempo trascorso del tempo di inattività pianificato, potresti dover posticipare la migrazione se l'attività di migrazione non termina nel tempo previsto.

Un piano di riserva di solito si riferisce al rollback della migrazione dopo l'esecuzione del cutover di produzione, se si verificano problemi nell'istanza target. Se implementi un piano di riserva, ricorda che deve essere trattato come una migrazione completa del database, inclusi la pianificazione e i test.

Se scegli di non avere un piano di riserva, assicurati di comprendere le possibili conseguenze. Non avere un piano di riserva può aggiungere un impegno imprevisto e causare interruzioni evitabili nel processo di migrazione.

Sebbene il fallback sia l'ultima risorsa e la maggior parte delle migrazioni di database non lo utilizzi, ti consigliamo di avere sempre una strategia di fallback.

Fallback semplice

In questa strategia di fallback, le applicazioni vengono riportate all'istanza del database di origine originale. Adotta questa strategia se puoi permetterti un tempo di inattività durante il fallback o se non hai bisogno di eseguire il commit delle transazioni sul nuovo sistema di destinazione.

Se hai bisogno di tutti i dati scritti nel database di destinazione e puoi permetterti un po' di tempo di inattività, puoi valutare di interrompere le scritture nell'istanza del database di destinazione, eseguire backup integrati e ripristinarli nell'istanza di origine, quindi ricollegare le applicazioni all'istanza del database di origine iniziale. A seconda della natura del workload e della quantità di dati scritti nell'istanza del database di destinazione, potresti inserirlo nel sistema di database di origine iniziale in un secondo momento, soprattutto se i workload non dipendono da un momento specifico di creazione dei record o da vincoli di ordinamento temporale.

Inverti la replica

In questa strategia, replichi le scritture che si verificano nel nuovo database di destinazione dopo il cutover di produzione nel database di origine iniziale. In questo modo, mantieni l'origine originale sincronizzata con il nuovo database di destinazione e le scritture vengono eseguite sulla nuova istanza del database di destinazione. Lo svantaggio principale è che non puoi testare il flusso di replica fino a quando non esegui il cutover all'istanza del database di destinazione, pertanto non consente i test end-to-end e ha un breve periodo di assenza di fallback.

Scegli questo approccio quando puoi ancora conservare l'istanza di origine per un po' di tempo ed esegui la migrazione utilizzando la migrazione con replica continua.

Replica in avanti

Questa strategia è una variante della replica inversa. Replichi le scritture sul nuovo database di destinazione in una terza istanza di database di tua scelta. Puoi indirizzare le tue applicazioni a questo terzo database, che si connette al server ed esegue query di sola lettura mentre il server non è disponibile. Puoi utilizzare qualsiasi meccanismo di replica, a seconda delle tue esigenze. Il vantaggio di questo approccio è che può essere testato completamente dall'inizio alla fine.

Adotta questo approccio quando vuoi avere sempre una copertura di riserva o quando devi eliminare il database di origine iniziale subito dopo il cutover di produzione.

Scritture duplicate

Se scegli una strategia di migrazione dei microservizi Y (scrittura e lettura) o di accesso ai dati, questo piano di riserva è già impostato. Questa strategia è più complessa, perché devi rifattorizzare le applicazioni o sviluppare strumenti per sviluppatori che si connettono alle istanze del database.

Le tue applicazioni scrivono sia nelle istanze del database di origine iniziale sia in quelle del database di destinazione, il che ti consente di eseguire un cutover di produzione graduale fino a quando non utilizzi solo le istanze del database di destinazione. In caso di problemi, ricolleghi le tue applicazioni all'origine iniziale senza tempi di inattività. Puoi eliminare l'origine iniziale e il meccanismo di scrittura duplicato quando ritieni che la migrazione sia stata eseguita senza problemi.

Consigliamo questo approccio quando è fondamentale non avere tempi di inattività durante la migrazione, avere un piano di riserva affidabile e quando hai tempo e risorse per eseguire il refactoring dell'applicazione.

Esegui test e convalida

Gli obiettivi di questo passaggio sono testare e convalidare quanto segue:

• Migrazione dei dati nel database riuscita.
• Integrazione con le applicazioni esistenti dopo il passaggio all'utilizzo della nuova istanza target.

Definisci i fattori chiave di successo, che sono soggettivi per la tua migrazione. Ecco alcuni esempi di fattori soggettivi:

• Quali dati migrare. Per alcuni workload, potrebbe non essere necessario eseguire la migrazione di tutti i dati. Potresti non voler eseguire la migrazione di dati già aggregati, ridondanti, archiviati o vecchi. Potresti archiviare i dati in un bucket Cloud Storage come backup.
• Una percentuale accettabile di perdita di dati. Ciò vale in particolare per i dati utilizzati per i workload di analisi, in cui la perdita di parte dei dati non influisce sulle tendenze generali o sulle prestazioni dei workload.
• Criteri di qualità e quantità dei dati, che puoi applicare all'ambiente di origine e confrontare con l'ambiente di destinazione dopo la migrazione.
• Criteri di rendimento. Alcune transazioni aziendali potrebbero essere più lente nell'ambiente di destinazione, ma il tempo di elaborazione rientra comunque nelle aspettative definite.

Le configurazioni di archiviazione nell'ambiente di origine potrebbero non essere mappate direttamente alle destinazioni dell'ambienteGoogle Cloud . Ad esempio, le configurazioni dei volumi SSD per uso generico (gp2 e gp3) con prestazioni di burst IOPS o SSD IOPS sottoposte a provisioning. Per confrontare e dimensionare correttamente le istanze target, esegui il benchmark delle istanze di origine, sia nella fase di valutazione che in quella di convalida.

Nel processo di benchmarking, applichi sequenze di operazioni simili a quelle di produzione alle istanze del database. Durante questo periodo, acquisisci ed elabori le metriche per misurare e confrontare le prestazioni relative dei sistemi di origine e di destinazione.

Per le configurazioni convenzionali basate su server, utilizza le misurazioni pertinenti osservate durante i picchi di carico. Per i modelli di capacità delle risorse flessibili come Aurora Serverless, valuta la possibilità di esaminare i dati delle metriche storiche per osservare le tue esigenze di scalabilità.

I seguenti strumenti possono essere utilizzati per i test, la convalida e il benchmarking del database:

• HammerDB: uno strumento open source per il benchmarking e il test di carico dei database. Supporta workload transazionali e analitici complessi, basati su standard di settore, su più motori di database (sia TPROC-C che TPROC-H). HammerDB dispone di una documentazione dettagliata e di un'ampia community di utenti. Puoi condividere e confrontare i risultati tra diversi motori del database e configurazioni di archiviazione. Per saperne di più, consulta Test di carico di SQL Server tramite HammerDB e Esegui il benchmark delle prestazioni di Amazon RDS SQL Server utilizzando HammerDB.
• Strumento di benchmark DBT2: benchmark specializzato per MySQL. Un insieme di kit di workload del database simula un'applicazione per un'azienda che possiede magazzini e prevede una combinazione di transazioni di lettura e scrittura. Utilizza questo strumento se vuoi utilizzare un test di carico di elaborazione delle transazioni online (OLTP) pronto all'uso.
• DbUnit: uno strumento di test delle unità open source utilizzato per testare le interazioni con i database relazionali in Java. La configurazione e l'utilizzo sono semplici e supporta più motori del database (MySQL, PostgreSQL, SQL Server e altri). Tuttavia, l'esecuzione del test a volte può essere lenta, a seconda delle dimensioni e della complessità del database. Consigliamo questo strumento quando la semplicità è importante.
• DbFit: un framework di test di database open source che supporta lo sviluppo di codice basato su test e i test automatici. Utilizza una sintassi di base per la creazione di scenari di test e offre test basati sui dati, controllo della versione e report sui risultati dei test. Tuttavia, il supporto per query e transazioni complesse è limitato e non dispone di un'ampia assistenza dalla community o di una documentazione completa rispetto ad altri strumenti. Ti consigliamo questo strumento se le tue query non sono complesse e vuoi eseguire test automatici e integrarli con il tuo processo di integrazione e distribuzione continua.

Per eseguire un test end-to-end, incluso il test del piano di migrazione, esegui sempre un esercizio di dry run della migrazione. Un dry run esegue la migrazione del database nell'intero ambito senza cambiare i workload di produzione e offre i seguenti vantaggi:

• Ti consente di assicurarti che tutti gli oggetti e le configurazioni vengano migrati correttamente.
• Ti aiuta a definire ed eseguire gli scenari di test della migrazione.
• Offre insight sul tempo necessario per la migrazione effettiva, in modo da poter calibrare la cronologia.
• Rappresenta un'occasione per testare, convalidare e adattare il piano di migrazione. A volte non è possibile pianificare tutto in anticipo, quindi questo ti aiuta a individuare eventuali lacune.

I test dei dati possono essere eseguiti su un piccolo insieme di database di cui eseguire la migrazione o sull'intero insieme. A seconda del numero totale di database e degli strumenti utilizzati per implementare la migrazione, puoi decidere di adottare un approccio basato sul rischio. Con questo approccio, esegui la convalida dei dati su un sottoinsieme di database di cui è stata eseguita la migrazione tramite lo stesso strumento, soprattutto se si tratta di un servizio di migrazione gestito.

Per i test, devi avere accesso ai database di origine e di destinazione ed eseguire le seguenti attività:

• Confronta gli schemi di origine e di destinazione. Controlla se tutte le tabelle e gli eseguibili esistono. Controlla i conteggi delle righe e confronta i dati a livello di database.
• Esegui script di convalida dei dati personalizzati.
• Verifica che i dati migrati siano visibili anche nelle applicazioni che sono passate all'utilizzo del database di destinazione (i dati migrati vengono letti tramite l'applicazione).
• Esegui test di integrazione tra le applicazioni trasferite e il database di destinazione testando vari casi d'uso. Questi test includono sia la lettura che la scrittura dei dati nei database di destinazione tramite le applicazioni, in modo che i workload supportino completamente i dati migrati insieme ai dati appena creati.
• Testa le prestazioni delle query del database più utilizzate per osservare se si verifica un peggioramento dovuto a configurazioni errate o dimensioni sbagliate.

Idealmente, tutti questi scenari di test di migrazione sono automatizzati e ripetibili su qualsiasi sistema di origine. La suite di scenari di test automatizzati è adattata per l'esecuzione con le applicazioni scambiate.

Se utilizzi Database Migration Service come strumento di migrazione, consulta Verifica una migrazione.

Data Validation Tool

Per eseguire la convalida dei dati, ti consigliamo di utilizzare lo strumento Data Validation Tool (DVT). Il DVT è uno strumento open source con interfaccia a riga di comando Python, supportato da Google, che fornisce una soluzione automatizzata e ripetibile per la convalida in ambienti diversi.

Il DVT può contribuire a semplificare il processo di convalida dei dati offrendo funzioni di convalida multilivello personalizzate per confrontare le tabelle di origine e di destinazione a livello di tabella, colonna e riga. Puoi anche aggiungere regole di convalida.

Il DVT copre molte origini dati, Google Cloud tra cui AlloyDB per PostgreSQL, BigQuery, Cloud SQL, Spanner, file JSON e CSV su Cloud Storage. Può anche essere integrato con Cloud Run Functions e Cloud Run per l'orchestrazione e l'attivazione basate su eventi.

Il DVT supporta i seguenti tipi di convalide:

• Confronti a livello di schema
• Colonna (tra cui "AVG", "COUNT", "SUM", "MIN", "MAX", "GROUP BY" e "STRING_AGG")
• Riga (inclusi hash e corrispondenza esatta nei confronti dei campi)
• Confronto dei risultati delle query personalizzate

Per saperne di più sul DVT, consulta il repository Git e Convalida dei dati semplificata con Data Validation Tool di Google Cloud.

Esegui la migrazione

Le attività di migrazione includono le attività per supportare il trasferimento da un sistema all'altro.

Prendi in esame queste best practice per la migrazione dei dati:

• Informare i team coinvolti ogni volta che un passaggio del piano inizia e termina.
• Se uno dei passaggi richiede più tempo del previsto, confronta il tempo trascorso con il tempo massimo assegnato per quel passaggio. In questo caso, invia aggiornamenti intermedi regolari ai team coinvolti.
• Se l'intervallo di tempo è superiore al tempo massimo riservato per ogni passaggio del piano, valuta la possibilità di eseguire il rollback.
• Prendi decisioni "go/no-go" per ogni passaggio del piano di migrazione e cutover.
• Prendi in considerazione azioni di rollback o scenari alternativi per ciascuno dei passaggi.

Esegui la migrazione seguendo le attività di esecuzione definite e consulta la documentazione dello strumento di migrazione selezionato.

Esegui il cutover di produzione

Il processo di cutover di produzione di alto livello può variare a seconda della strategia di migrazione scelta. Se puoi avere tempi di inattività sui tuoi workload, il cutover della migrazione inizia con l'interruzione delle scritture nel database di origine.

Per le migrazioni con replica continua, in genere segui questi passaggi di alto livello nel processo di cutover:

• Interrompi la scrittura nel database di origine.
• Svuota l'origine.
• Interrompi il processo di replica.
• Esegui il deployment delle applicazioni che puntano al nuovo database di destinazione.

Dopo aver eseguito la migrazione dei dati utilizzando lo strumento di migrazione scelto, convalida i dati nel database di destinazione. Confermi che il database di origine e i database di destinazione sono sincronizzati e che i dati nell'istanza di destinazione rispettano gli standard di successo della migrazione scelti.

Una volta che la convalida dei dati soddisfa i tuoi criteri, puoi eseguire il cutover a livello di applicazione. Esegui il deployment dei workload che sono stati rifattorizzati per utilizzare la nuova istanza target. Esegui il deployment delle versioni delle tue applicazioni che puntano alla nuova istanza di database di destinazione. I deployment possono essere eseguiti tramite aggiornamenti in sequenza, release in fasi o utilizzando un pattern di deployment blu/verde. Potrebbero verificarsi tempi di inattività dell'applicazione.

Segui le best practice per la transizione alla produzione:

• Monitora le applicazioni che funzionano con il database di destinazione dopo il cutover.
• Definisci un periodo di tempo di monitoraggio per valutare se devi o meno implementare il piano di riserva.
• Tieni presente che l'istanza Cloud SQL o AlloyDB per PostgreSQL potrebbe richiedere un riavvio se modifichi alcuni flag di database.
• Tieni presente che l'impegno necessario per eseguire il rollback della migrazione potrebbe essere maggiore rispetto alla risoluzione dei problemi che si presentano nell'ambiente di destinazione.

Pulisci l'ambiente di origine e configura l'istanza Cloud SQL

Al termine del cutover, puoi eliminare i database di origine. Ti consigliamo di eseguire le seguenti azioni importanti prima della pulizia dell'istanza di origine:

• Crea un backup finale di ogni database di origine. Questi backup ti forniscono uno stato finale dei database di origine. In alcuni casi, i backup potrebbero essere richiesti anche per la conformità ad alcune normative sui dati.

• Raccogli le impostazioni dei parametri del database dell'istanza di origine. In alternativa, verifica che corrispondano a quelli raccolti nella fase di creazione dell'inventario. Modifica i parametri dell'istanza di destinazione in modo che corrispondano a quelli dell'istanza di origine.

• Raccogli le statistiche del database dall'istanza di origine e confrontale con quelle dell'istanza target. Se le statistiche sono diverse, è difficile confrontare le prestazioni dell'istanza di origine e dell'istanza target.

In uno scenario di fallback, potresti voler implementare la replica delle scritture sull'istanza Cloud SQL nel database di origine originale. La configurazione è simile al processo di migrazione, ma viene eseguita al contrario: il database di origine iniziale diventa la nuova destinazione.

Come best practice per mantenere aggiornate le istanze di origine dopo il cutover, replica le scritture eseguite sulle istanze Cloud SQL di destinazione nel database di origine. Se devi eseguire il rollback, puoi tornare alle istanze di origine precedenti con una perdita di dati minima.

Oltre alla pulizia dell'ambiente di origine, è necessario eseguire le seguenti configurazioni critiche per le istanze Cloud SQL:

• Configura un periodo di manutenzione per l'istanza principale per controllare quando possono verificarsi aggiornamenti invasivi.
• Configura lo spazio di archiviazione nell'istanza in modo da avere almeno il 20% di spazio disponibile per consentire eventuali operazioni di manutenzione del database critiche che Cloud SQL potrebbe eseguire. Per ricevere un avviso se lo spazio su disco disponibile scende al di sotto del 20%, crea una criterio di avviso basata sulle metriche per la metrica di utilizzo del disco.

Non avviare un'operazione amministrativa prima che l'operazione precedente sia stata completata.

Per ulteriori informazioni, consulta le seguenti risorse:

• Informazioni sulla manutenzione delle istanze Cloud SQL.
• Impostazioni specifiche del motore SQL Server

Ottimizza l'ambiente dopo la migrazione

L'ottimizzazione è l'ultima fase della migrazione. In questa fase, esegui l'iterazione delle attività di ottimizzazione finché l'ambiente di destinazione non soddisfa i requisiti di ottimizzazione. I passaggi di ogni iterazione sono i seguenti:

1. Valuta l'ambiente, i team e il ciclo di ottimizzazione attuali.
2. Stabilisci i requisiti e gli obiettivi di ottimizzazione.
3. Ottimizza l'ambiente e i team.
4. Ottimizza il ciclo di ottimizzazione.

Ripeti questa sequenza fino a raggiungere i tuoi obiettivi di ottimizzazione.

Per saperne di più sull'ottimizzazione dell'ambiente Google Cloud , consulta Esegui la migrazione a Google Cloud: ottimizza l'ambiente e Well-Architected Framework diGoogle Cloud : ottimizzazione delle prestazioni.

Stabilisci i requisiti di ottimizzazione

Esamina i seguenti requisiti di ottimizzazione per il tuo ambiente Google Cloud e scegli quelli più adatti ai tuoi workload.

Aumenta l'affidabilità e la disponibilità del tuo database

Con Cloud SQL, puoi implementare una strategia di alta affidabilità e disaster recovery in linea con l'RTO (Recovery Time Objective) e l'RPO (Recovery Point Objective). Per aumentare l'affidabilità e la disponibilità, considera quanto segue:

• In caso di workload con un numero elevato di operazioni di lettura, aggiungi repliche di lettura per trasferire il traffico dall'istanza principale.
• Per i workload mission critical, utilizza la configurazione ad alta affidabilità, le repliche per il failover regionale e una configurazione di ripristino di emergenza efficace.
• Per i workload meno critici, i backup automatici e on demand possono essere sufficienti.
• Per evitare la rimozione accidentale delle istanze, utilizza la protezione da eliminazione delle istanze.
• Abilita il recupero point-in-time (PITR) per l'istanza Cloud SQL per SQL Server.
• Automatizza i backup dei database SQL utilizzando i piani di manutenzione.

Aumenta l'efficacia in termini di costi della tua infrastruttura di database

Per avere un impatto economico positivo, i tuoi workload devono utilizzare le risorse e i servizi disponibili in modo efficiente. Valuta le seguenti opzioni.

• Fornisci al database la capacità di archiviazione minima richiesta seguendo questi passaggi:

  • Per scalare automaticamente la capacità di archiviazione man mano che i dati crescono, abilita gli aumenti automatici dello spazio di archiviazione. Tuttavia, assicurati di configurare le istanze in modo da avere un buffer per i workload di picco. Ricorda che i workload del database tendono ad aumentare nel tempo.

• Identifica le possibili risorse sovrastimate:

  • Il dimensionamento ottimale delle istanze Cloud SQL può ridurre i costi dell'infrastruttura senza aggiungere ulteriori rischi alla strategia di gestione della capacità.
  • Cloud Monitoring fornisce dashboard predefinite che aiutano a identificare l'integrità e l'utilizzo della capacità di molti componenti Google Cloud, tra cui Cloud SQL. Per maggiori dettagli, consulta Crea e gestisci dashboard personalizzate.

• Identifica le istanze che non richiedono configurazioni di alta affidabilità o disaster recovery e rimuovile dalla tua infrastruttura.

• Rimuovi le tabelle e gli oggetti che non sono più necessari. Puoi archiviarli in un backup completo o in un bucket Cloud Storage di archiviazione.

• Valuta il tipo di archiviazione (SSD o HDD) più conveniente per il tuo caso d'uso.

  • Per la maggior parte dei casi d'uso, l'SSD è la scelta più efficiente ed economica.
  • Se i tuoi set di dati sono di grandi dimensioni (10 TB o più), non sono sensibili alla latenza o l'accesso è poco frequente, l'HDD potrebbe essere più appropriato.
  • Per maggiori dettagli, consulta Scegli tra archiviazione SSD e HDD.

• Acquista sconti per impegno di utilizzo per workload con esigenze di risorse prevedibili.

• Utilizza Active Assist per ottenere insight e suggerimenti sui costi.

  Per ulteriori informazioni e opzioni, consulta Ottieni di più con meno: introduzione ai suggerimenti per l'ottimizzazione dei costi di Cloud SQL con Active Assist.

Per ridurre i costi delle licenze, in particolare per Cloud SQL per SQL Server, tieni presente quanto segue:

• Esegui la migrazione a SQL Server Standard Edition, se gli SLA corrispondono ai tuoi requisiti.
• Disattiva il multi-threading simultaneo (SMT) e aggiungi il 25% di core in più. I core aggiuntivi potrebbero compensare l'eventuale impatto sulle prestazioni dovuto alla disattivazione di SMT. Questa strategia può contribuire a ridurre i costi delle licenze, ma potrebbe influire sulle prestazioni dell'istanza. Ti consigliamo di eseguire test di carico sull'istanza per assicurarti che i tuoi SLA non siano interessati.
• Valuta una migrazione eterogenea da Cloud SQL per SQL Server a Cloud SQL per PostgreSQL o AlloyDB per PostgreSQL, a seconda del tuo workload.

Aumenta le prestazioni dell'infrastruttura del database

I problemi di prestazioni minori relativi al database spesso possono influire sull'intera operazione. Per mantenere e aumentare le prestazioni dell'istanza Cloud SQL, tieni presente le seguenti linee guida:

• Se hai un numero elevato di tabelle di database, queste possono influire sulle prestazioni e sulla disponibilità dell'istanza e causare la perdita della copertura dello SLA.

• Assicurati che l'istanza non abbia vincoli di memoria o CPU.

  • Per i workload ad alte prestazioni, assicurati che l'istanza abbia almeno 60 GB di memoria.
  • Per inserimenti, aggiornamenti o eliminazioni lenti nel database, controlla le posizioni del writer e del database. L'invio di dati su lunghe distanze introduce latenza.

• Migliora le prestazioni delle query utilizzando la dashboard predefinita di Query Insights in Cloud Monitoring (o funzionalità integrate simili del motore del database). Identifica i comandi più costosi e prova a ottimizzarli.

• Impedire che i file di database diventino inutilmente grandi. Imposta autogrow in MB anziché come percentuale, utilizzando incrementi appropriati al requisito.

• Controlla la posizione del lettore e del database. La latenza influisce sulle prestazioni di lettura più che su quelle di scrittura.

• Evita la frammentazione di dati e indici. Imposta una pianificazione per ricostruire gli indici in SQL Server, a seconda della frequenza con cui cambiano i dati.

• Modifica le impostazioni specifiche del motore SQL Server in modo che funzionino in modo ottimale per Cloud SQL.

• Per la manutenzione di indici e statistiche, consulta SQL Server Maintenance Solution.

• Aggiorna regolarmente le statistiche su Cloud SQL per SQL Server.

• Valuta la possibilità di eseguire operazioni ETL su una replica di lettura, perché potrebbero influire sulla cache dell'istanza.

Per saperne di più su come migliorare le prestazioni, consulta Prestazioni in "Diagnostica i problemi" e Cloud SQL - Analisi delle prestazioni di SQL Server e ottimizzazione delle query.

Aumenta le funzionalità di osservabilità del database

La diagnosi e la risoluzione dei problemi nelle applicazioni che si connettono alle istanze di database possono essere difficili e richiedere molto tempo. Per questo motivo, è essenziale disporre di un luogo centralizzato in cui tutti i membri del team possano vedere cosa sta succedendo a livello di database e di istanza. Puoi monitorare le istanze Cloud SQL nei seguenti modi:

• Cloud SQL utilizza agenti personalizzati in memoria integrati per raccogliere la telemetria delle query.

  • Utilizza Cloud Monitoring per raccogliere le misurazioni del tuo servizio e delle risorse Google Cloudche utilizzi. Cloud Monitoring include dashboard predefinite per diversi prodotti Google Cloud , tra cui una dashboard di monitoraggio di Cloud SQL.
  • Puoi creare dashboard personalizzate che ti aiutano a monitorare le metriche e configurare policy di avviso in modo da ricevere notifiche tempestive.
  • In alternativa, puoi prendere in considerazione l'utilizzo di soluzioni di monitoraggio di terze parti integrate con Google Cloud, come Datadog e Splunk.

• Cloud Logging raccoglie i dati di logging da componenti di applicazioni comuni.

• Cloud Trace raccoglie i dati di latenza e i piani di query eseguiti dalle applicazioni per aiutarti a monitorare la propagazione delle richieste nell'applicazione.

• Database Center offre una panoramica centralizzata del parco risorse del database assistita dall'AI. Puoi monitorare l'integrità dei tuoi database, la configurazione della disponibilità, la protezione dei dati, la sicurezza e la conformità del settore.

• Visualizza ed esegui query sui log per la tua istanza Cloud SQL.

• Osserva lo stato dei tuoi database per migliorare le prestazioni del tuo ambiente e risolvere eventuali problemi.

Best practice generali e linee guida operative di Cloud SQL

Applica le best practice per Cloud SQL per configurare e ottimizzare il database.

Di seguito sono riportati alcuni suggerimenti generali importanti per Cloud SQL:

• Se hai istanze di grandi dimensioni, ti consigliamo di suddividerle in istanze più piccole, se possibile.
• Configura lo spazio di archiviazione per consentire la manutenzione critica del database. Assicurati di avere almeno il 20% di spazio disponibile per consentire eventuali operazioni di manutenzione del database critiche che Cloud SQL potrebbe eseguire.
• La presenza di troppe tabelle del database può influire sul tempo di upgrade del database. Idealmente, dovresti avere meno di 10.000 tabelle per istanza.
• Scegli le dimensioni appropriate per le tue istanze per tenere conto della conservazione dei log delle transazioni (binari), in particolare per le istanze con un'attività di scrittura elevata.

Per gestire in modo efficiente eventuali problemi di prestazioni del database che potresti riscontrare, utilizza le seguenti linee guida fino alla risoluzione del problema:

Fai lo scale up dell'infrastruttura: aumenta le risorse (come throughput del disco, vCPU e RAM). A seconda dell'urgenza e della disponibilità e dell'esperienza del tuo team, lo scale up verticale dell'istanza può risolvere la maggior parte dei problemi di prestazioni. In un secondo momento, puoi esaminare ulteriormente la causa principale del problema in un ambiente di test e valutare le opzioni per eliminarlo.

Esegui e pianifica le operazioni di manutenzione del database: deframmentazione degli indici, aggiornamenti delle statistiche, analisi vacuum e reindicizzazione delle tabelle con aggiornamenti frequenti. Controlla se e quando sono state eseguite l'ultima volta queste operazioni di manutenzione, soprattutto sugli oggetti interessati (tabelle, indici). Scopri se si è verificata una modifica rispetto alle normali attività del database. Ad esempio, l'aggiunta recente di una nuova colonna o la presenza di molti aggiornamenti in una tabella.

Esegui l'ottimizzazione del database: le tabelle del database sono strutturate correttamente? Le colonne hanno i tipi di dati corretti? Il tuo modello di dati è adatto al tipo di workload? Esamina le query lente e i relativi piani di esecuzione. Utilizzano gli indici disponibili? Controlla se sono presenti scansioni di indici, blocchi e attese su altre risorse. Valuta la possibilità di aggiungere indici per supportare le query critiche. Elimina gli indici e le chiavi esterne non critici. Valuta la possibilità di riscrivere query e join complessi. Il tempo necessario per risolvere il problema dipende dall'esperienza e dalla disponibilità del tuo team e può variare da ore a giorni.

Fai lo scale out delle letture: valuta la possibilità di avere repliche di lettura. Quando la scalabilità verticale non è sufficiente per le tue esigenze e le misure di ottimizzazione del database non sono utili, valuta la possibilità di eseguire lo scale out. Il routing delle query di lettura dalle tue applicazioni a una replica di lettura migliora le prestazioni complessive del workload del database. Tuttavia, potrebbe essere necessario un ulteriore sforzo per modificare le applicazioni in modo che si connettano alla replica di lettura.

Riprogettazione dell'architettura del database: valuta la possibilità di partizionare e indicizzare il database. Questa operazione richiede un impegno significativamente maggiore rispetto all'ottimizzazione e alla messa a punto del database e potrebbe comportare una migrazione dei dati, ma può essere una soluzione a lungo termine. A volte, una progettazione scadente del modello dei dati può causare problemi di prestazioni, che possono essere parzialmente compensati dallo scale up verticale. Tuttavia, un modello dei dati adeguato è una soluzione a lungo termine. Valuta la possibilità di partizionare le tabelle. Se possibile, archivia i dati che non sono più necessari. Normalizza la struttura del database, ma ricorda che anche la denormalizzazione può migliorare le prestazioni.

Sharding del database: puoi fare lo scale out delle scritture eseguendo lo sharding del database. Lo sharding è un'operazione complicata che comporta la riprogettazione del database e delle applicazioni in un modo specifico e l'esecuzione della migrazione dei dati. Suddividi l'istanza del database in più istanze più piccole utilizzando criteri di partizionamento specifici. I criteri possono essere basati sul cliente o sull'oggetto. Questa opzione ti consente di scalare orizzontalmente sia le scritture che le letture. Tuttavia, aumenta la complessità dei workload del database e delle applicazioni. Potrebbe anche portare a shard sbilanciati chiamati hotspot, che annullerebbero il vantaggio dello sharding.

In particolare, per Cloud SQL per SQL Server, tieni presente le seguenti best practice:

• Per aggiornare le impostazioni di SQL Server per prestazioni ottimali con Cloud SQL, consulta Impostazioni di SQL Server.
• Determina la capacità del sottosistema di I/O prima di eseguire il deployment di SQL Server.

• Se hai istanze di grandi dimensioni, suddividile in istanze più piccole, se possibile:

  • Un disco di almeno 4 TB offre un throughput e un numero di IOPS maggiori.
  • Un numero maggiore di vCPU fornisce più IOPS e throughput. Quando utilizzi una vCPU più elevata, monitora le attese del database per il parallelismo, che potrebbero anche aumentare.

• Disattiva SMT se le prestazioni diminuiscono in alcune situazioni. Ad esempio, se un'applicazione esegue thread che diventano un collo di bottiglia e l'architettura della CPU non gestisce questo problema in modo efficace.

• Imposta una pianificazione per riorganizzare o ricostruire gli indici, a seconda della frequenza con cui cambiano i dati.

• Imposta un fattore di riempimento appropriato per ridurre la frammentazione. Monitora SQL Server per individuare gli indici mancanti che potrebbero offrire prestazioni migliori.

• Impedire che i file di database diventino inutilmente grandi. Imposta autogrow in MB anziché come percentuale, utilizzando incrementi appropriati al requisito. Inoltre, gestisci in modo proattivo la crescita del database prima che venga raggiunta la soglia di autogrow.

• Per scalare automaticamente la capacità di archiviazione, abilita gli aumenti automatici dello spazio di archiviazione. Cloud SQL può aggiungere spazio di archiviazione se il database e l'istanza esauriscono lo spazio.

• Assicurati di comprendere i requisiti relativi alle impostazioni internazionali, l'ordinamento e la sensibilità alle maiuscole/minuscole e agli accenti dei dati con cui stai lavorando. Quando selezioni la regole di confronto per il server, il database, la colonna o l'espressione, assegni determinate caratteristiche ai dati.

• I join hash ricorsivi o i bailout hash causano una riduzione delle prestazioni in un server. Se in una traccia vengono visualizzati molti eventi di avviso di hash, aggiorna le statistiche sulle colonne che vengono unite. Per saperne di più, consulta Classe di eventi Hash Warning.

Per maggiori dettagli, consulta le best practice generali e le linee guida operative per Cloud SQL per SQL Server.

Passaggi successivi

• Scopri altri percorsi di migrazione da AWS a Google Cloud .
• Scopri come confrontare i servizi AWS e Azure con Google Cloud.
• Scopri dove trovare assistenza per le migrazioni.
• Segui il corso di formazione di Google Skills sulla migrazione a Google Cloud.
• Per ulteriori architetture di riferimento, diagrammi e best practice, esplora Cloud Architecture Center.

Collaboratori

Autori:

• Alex Cârciu | Solutions Architect
• Marco Ferrari | Cloud Solutions Architect

Altri collaboratori:

• Derek Downey | Developer Relations Engineer
• Paweł Krentowski | Technical Writer
• Matthew Smith | Strategic Cloud Engineer
• Somdyuti Paul | Data Management Specialist
• Zach Seils | Networking Specialist