Migrazione da AWS a Google Cloud: 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 la migrazione da Amazon Relational Database Service (RDS) a Cloud SQL per SQL Server.

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

Questo documento si concentra sulla migrazione omogenea dei database, ovvero in cui i database di origine e di destinazione utilizzano la stessa tecnologia dei 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 a Google Cloud che include i seguenti documenti:

• Inizia
• Eseguire la migrazione da Amazon EC2 a Compute Engine
• Eseguire la migrazione da Amazon S3 a Cloud Storage
• Eseguire la migrazione da Amazon EKS a GKE
• Migrate from AWS to Google Cloud: Migrate from Amazon RDS for SQL Server to Cloud SQL for SQL Server (questo documento)

Questa serie presuppone che tu abbia letto e abbia familiarità con i seguenti documenti:

• Migrazione a Google Cloud: guida introduttiva: descrive il framework generale della migrazione che seguirai in questa migrazione.
• Migrazione a Google Cloud: best practice per la convalida di un piano di migrazione: descrive potenziali modifiche e miglioramenti al piano di migrazione.

Il seguente diagramma illustra il percorso del tuo percorso di migrazione. Per gli scenari di migrazione, la fase di deployment equivale all'esecuzione di un processo di migrazione.

Puoi eseguire la migrazione da Amazon RDS a Cloud SQL in una serie di iterazioni, ad esempio, potresti eseguire la migrazione di alcune istanze di database prima e altre in un secondo momento. Per ogni iterazione di migrazione separata, segui le fasi del framework di migrazione generale, che è la seguente:

1. Valuta e individua i carichi di lavoro e i dati.
2. Pianifica e crea una base su Google Cloud.
3. Esegui la migrazione dei carichi di lavoro e dei dati in Google Cloud.
4. Ottimizza il tuo ambiente Google Cloud.

Per saperne di più sulle fasi di questo framework, consulta Eseguire la migrazione a Google Cloud: iniziare.

Valuta l'ambiente di origine

Nella fase di valutazione, stabilisci i requisiti e le dipendenze delle risorse di cui vuoi eseguire la migrazione.

La fase di valutazione è composta dalle seguenti attività:

1. Crea un inventario completo dei tuoi carichi di lavoro.
2. Cataloga i carichi di lavoro in base alle loro proprietà e dipendenze.
3. Formazione e formazione su Google Cloud per i tuoi team, incluse le best practice per i database.
4. Crea esperimenti e proof of concept su Google Cloud.
5. Calcola il costo totale di proprietà (TCO) dell'ambiente di destinazione.
6. Decidi l'ordine e la priorità dei carichi di lavoro di cui vuoi eseguire la migrazione.

La fase di valutazione del database consente di 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 a dimensioni del disco e velocità effettiva, IOPS e numero di vCPU. Le migrazioni potrebbero avere difficoltà o non riuscire a causa del dimensionamento errato dell'istanza del database di destinazione. Il dimensionamento non corretto può comportare lunghi tempi di migrazione e problemi di prestazioni del database, nonché di errori del database e delle prestazioni delle applicazioni. Quando scegli l'istanza Cloud SQL, tieni presente che le prestazioni del disco si basano sulle dimensioni del disco e sul numero di vCPU.

Per ulteriori informazioni sulla fase di valutazione e su queste attività, consulta Eseguire la migrazione a Google Cloud: valutare e scoprire i carichi di lavoro. Le sezioni seguenti si basano sulle informazioni contenute nel 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 dell'istanza o operazioni simili. Alcune funzionalità potrebbero essere implementate in modo diverso o non essere disponibili. Le aree differenze potrebbero includere infrastruttura, archiviazione, autenticazione e sicurezza, replica, backup, alta disponibilità, modello di capacità delle risorse e estensioni e integrazioni 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 carichi di lavoro di cui eseguire la migrazione e a definire la giusta architettura dell'ambiente di destinazione della migrazione. La raccolta di informazioni sulle prestazioni è importante per stimare le esigenze di prestazioni dell'ambiente di destinazione di Google Cloud. I concetti e gli strumenti di benchmarking sono descritti in dettaglio nella fase Esecuzione di 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 di valutazione di database specializzati come migVisor e Database Migration Assessment Tool (DMA).

Con il Centro di migrazione puoi eseguire una valutazione completa del panorama delle applicazioni e dei database, compresa l'idoneità tecnica per una migrazione del database a Google Cloud. Riceverai suggerimenti relativi a dimensioni e configurazione per ogni database di origine e crei un report sul costo totale di proprietà (TCO) per i server e i database.

Per ulteriori informazioni sulla valutazione dell'ambiente AWS mediante il Centro di migrazione, vedi Importare dati da altri cloud provider.

Oltre a Migration Center, è possibile utilizzare lo strumento specializzato migVisor, che supporta vari motori di database ed è particolarmente adatto per migrazioni eterogenee. Per un'introduzione a migVisor, vedi la panoramica di migVisor.

migVisor è in grado di identificare artefatti e funzionalità di database di proprietà incompatibili che possono causare l'inadempienza della migrazione e può indicare soluzioni alternative. migVisor può anche suggerire una soluzione Google Cloud di destinazione, compresi dimensionamento e architettura iniziali.

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

• Rilevamento e analisi complete delle implementazioni attuali dei database.
• Report dettagliato della complessità della migrazione, basato sulle funzionalità proprietarie utilizzate dal database.
• Report finanziario con dettagli su risparmi sui costi dopo la migrazione, costi di migrazione e nuovo budget operativo.
• Piano di migrazione per fasi per spostare i database e le applicazioni associate con interruzioni minime dell'attività.

Per vedere alcuni esempi di output di valutazione, vedi migVisor - Cloud Migration Assessment Tool.

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 di valutazione di migVisor consente di creare un inventario completo delle istanze RDS. Il report include proprietà generiche (versione e versione del motore del database, CPU e dimensioni della memoria), nonché dettagli su topologia del database, criteri di backup, impostazioni dei parametri e personalizzazioni speciali in uso.

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

Consigliamo lo strumento open source DMA, realizzato dagli ingegneri di Google. Offre una valutazione completa e accurata dei database, tra cui le funzionalità in uso, la logica del database e gli oggetti di database (inclusi schemi, tabelle, viste, funzioni, trigger e procedure archiviate).

Per utilizzare DMA, scarica gli script di raccolta per il 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 tempi di inattività convenienti

In questa fase, devi documentare le informazioni essenziali che influenzano la strategia e gli strumenti di migrazione. A questo punto, puoi rispondere alle seguenti domande:

• I database hanno dimensioni superiori a 5 TB?
• Nel 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?
• Quanto sono compatibili i database di origine e di destinazione?
• I dati devono trovarsi in luoghi fisici?
• Ci sono dati che possono essere compressi e archiviati o che non richiedono la migrazione?

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

Stabilisci basi di migrazione dei dati che ti aiutino a confrontare e valutare i risultati e l'impatto. Queste basi sono punti di riferimento che rappresentano lo stato dei dati prima e dopo la migrazione e ti aiutano a prendere decisioni. È importante effettuare misurazioni sull'ambiente di origine per poter valutare l'efficacia della migrazione dei dati. Queste misurazioni includono:

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

Determina il tempo di riposo che puoi permetterti. Quali sono l'impatto dei tempi di inattività sull'attività? Esistono periodi di scarsa attività del database durante i quali si verificano meno utenti con tempi di inattività? Se sì, quanto sono lunghi e quando si verificano? Valuta la possibilità di prevedere un tempo di inattività parziale in scrittura mentre le richieste di sola lettura continuano a essere gestite.

Valutare il processo di implementazione e amministrazione

Dopo aver creato gli inventari, valuta i processi operativi e di deployment del database per determinare come devono essere adattati per facilitare la migrazione. Questi processi sono fondamentali per preparare e mantenere l'ambiente di produzione.

Valuta come completare le seguenti attività:

• Definisci e applica i criteri di sicurezza per le tue istanze: ad esempio, potrebbe essere necessario sostituire Amazon Security Groups. Puoi utilizzare i ruoli IAM di Google, 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 di Windows con Cloud SQL per SQL Server, devi eseguire il deployment di Managed Microsoft AD e connetterti all'infrastruttura Active Directory esistente.
• Applica le 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 Amazon o nei gruppi di opzioni Amazon. Potrebbe essere necessario adattare gli strumenti di provisioning in modo da utilizzare Google Cloud Storage o Secret Manager per leggere questi elenchi di configurazioni personalizzate.
• Gestisci l'infrastruttura di monitoraggio e avviso: le categorie di metriche per le istanze del database di origine Amazon consentono l'osservabilità durante il processo di migrazione. Le categorie di metriche possono 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 le restanti attività della fase di valutazione come descritto in Eseguire la migrazione a Google Cloud: valutare e scoprire i carichi di lavoro.

Pianifica e costruisci le tue basi

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

• Supporta i tuoi carichi di lavoro nel tuo ambiente Google Cloud.
• Connetti il tuo ambiente AWS e il tuo ambiente Google Cloud per completare la migrazione.

Crea le tue basi su Google Cloud

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

1. Creare una gerarchia di risorse.
2. Configura la gestione di identità e accessi.
3. Configura la fatturazione.
4. Configura la connettività di rete.
5. Rafforza la tua sicurezza.
6. Configura il logging, il monitoraggio e gli avvisi.

Per ulteriori informazioni su ciascuna di queste attività, consulta Eseguire la migrazione a Google Cloud: creare la tua base.

Monitoraggio e avvisi

Utilizza Google Cloud Monitoring, 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 con Google 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 in Cloud SQL per SQL Server

Per eseguire la migrazione delle istanze, segui questi passaggi:

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

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

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

4. Definisci le attività di preparazione da eseguire per garantire che lo strumento di migrazione possa funzionare correttamente.

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

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

7. Esegui test e convalida in un ambiente di gestione temporanea separato.

8. Esegui la migrazione.

9. Esegui la migrazione completa della produzione.

10. Pulire l'ambiente di origine e configurare l'istanza di destinazione.

11. Eseguire l'ottimizzazione e l'ottimizzazione.

Ogni fase è descritta nelle sezioni seguenti.

Scegli la strategia di migrazione

In questo passaggio, avrai informazioni sufficienti per valutare e selezionare una delle seguenti strategie di migrazione più adatte al tuo caso d'uso per ogni database:

• Manutenzione pianificata (chiamata anche migrazione una tantum): questo approccio è ideale se puoi consentire tempi di inattività. Questa opzione ha costi e complessità relativamente inferiori, perché i carichi di lavoro e i servizi non richiedono un refactoring eccessivo. Tuttavia, se la migrazione non riesce prima del completamento, devi riavviare il processo, il che prolunga il tempo di inattività.

• Replica continua (chiamata anche migrazione a rete): per i database mission-critical, questa opzione offre un rischio inferiore di perdita di dati e tempi di inattività quasi azzerati. Gli sforzi sono suddivisi in diversi blocchi, quindi in caso di errore, il rollback e la ripetizione richiedono meno tempo. Tuttavia, la configurazione è più complessa e richiede più tempo e pianificazione. Sono necessari inoltre ulteriori sforzi per il refactoring delle applicazioni che si connettono alle istanze del tuo database. Prendi in considerazione una delle seguenti varianti:

  • Utilizza l'approccio Y (scrittura e lettura), una forma di migrazione parallela che duplica i dati nelle istanze di origine e di destinazione durante la migrazione.
  • Utilizzo di un microservizio di accesso ai dati, che riduce lo sforzo di refactoring richiesto dall'approccio Y (scrittura e lettura).

Per ulteriori informazioni 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 avere quando decidi la strategia di migrazione per un singolo database:

Il diagramma di flusso precedente mostra i seguenti punti decisionali:

• Puoi permetterti un tempo di riposo?

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

• Puoi permetterti il tempo di inattività rappresentato dalla finestra di migrazione durante la migrazione dei dati? La finestra di migrazione completa rappresenta la quantità di tempo necessaria per eseguire un backup del database, trasferirlo in Cloud SQL, ripristinarlo e quindi passare alle applicazioni.

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

Le strategie possono variare per database diversi, anche se si trovano nella stessa istanza. Un mix di strategie può produrre risultati ottimali. Ad esempio, puoi eseguire la migrazione di database di piccole dimensioni e utilizzati raramente utilizzando l'approccio di manutenzione pianificata, ma utilizza la replica continua per i database mission critical in cui il tempo di inattività è costoso.

Di solito, una migrazione viene considerata completata quando avviene il passaggio tra l'istanza di origine iniziale e l'istanza di destinazione. Qualsiasi replica (se utilizzata) viene arrestata e tutte le operazioni di lettura e scrittura vengono eseguite sull'istanza di destinazione. Cambiare quando entrambe le istanze sono sincronizzate significa nessuna perdita di dati e tempi di inattività minimi.

Per ulteriori informazioni sulle strategie e sui deployment di migrazione dei dati, consulta Classificazione delle migrazioni dei database e Strategie di deployment.

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

Le configurazioni di migrazione che non offrono tempi di inattività delle applicazioni richiedono una configurazione più complicata. Trova il giusto equilibrio tra complessità di configurazione e tempi di inattività pianificati durante gli orari di lavoro con traffico ridotto.

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

• Il completamento delle query sul 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 notevole memoria del buffer.
• Le applicazioni arrestate nell'origine e riavviate in Google Cloud potrebbero avere un leggero ritardo prima che venga stabilita la connessione all'istanza del database Google Cloud.
• Le route di rete alle applicazioni devono essere reinstradate. A seconda di come sono configurate le voci DNS, questa operazione può richiedere del tempo. Quando aggiorni i record DNS, riduci il TTL prima della migrazione.

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

• Trova un periodo di tempo in cui il tempo di inattività abbia un impatto minimo sui carichi di lavoro. ad esempio al di fuori del normale orario di lavoro, nei fine settimana o in altri periodi di manutenzione programmata.
• Identifica le parti dei carichi di lavoro che possono essere sottoposte a migrazione e migrazione completa della produzione in fasi diverse. Le 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 possono avere i propri database, che possono essere pianificati per la migrazione prima o dopo.
• Se puoi permetterti un po' di 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 carichi di lavoro in modo che operino con i dati inattivi nell'istanza di destinazione.
• Valuta la possibilità di eseguire il refactoring delle applicazioni per supportare un impatto minimo sulla migrazione. Ad esempio, adatta le applicazioni in modo che scrivano su database di origine e di destinazione, implementando quindi una replica a livello di applicazione.

Scegli gli strumenti di migrazione

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

Sono disponibili molti strumenti, ciascuno ottimizzato per determinati casi d'uso della migrazione. Ecco alcuni casi d'uso:

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

Per garantire una migrazione e una migrazione senza interruzioni, puoi utilizzare pattern di deployment delle applicazioni, orchestrazione dell'infrastruttura e applicazioni di migrazione personalizzate. Tuttavia, strumenti specializzati denominati servizi di migrazione gestita 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, trasportano i dati 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 il tempo di inattività: i servizi utilizzano le funzionalità di replica integrate dei motori del database, se disponibili, e eseguono la promozione delle repliche.

• Garantire l'integrità e la protezione dei dati: i dati vengono trasferiti in modo sicuro e affidabile dall'origine al database di destinazione.

• Offri un'esperienza di migrazione coerente: è possibile consolidare tecniche e pattern di migrazione diversi in un'interfaccia coerente e comune utilizzando gli eseguibili per la migrazione dei database, che puoi gestire e monitorare.

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

• Ottimizzazione dei costi: i servizi di migrazione gestiti possono essere più convenienti del provisioning di risorse e server aggiuntivi per soluzioni di migrazione personalizzate.

Le sezioni successive descrivono i suggerimenti degli strumenti di migrazione, che dipendono dalla strategia di migrazione scelta.

Strumenti per migrazioni di manutenzione pianificate

Le seguenti sottosezioni descrivono gli strumenti che possono essere utilizzati per le migrazioni una tantum, nonché i relativi limiti e best practice.

Backup integrati del motore del database

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

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

I backup del motore del database hanno 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 sono gestiti correttamente.
• I backup non dispongono di funzionalità di monitoraggio adeguate.

Se scegli questo approccio, considera le seguenti restrizioni e best practice:

• Per i backup di database più grandi di 5 TB, utilizza un backup con 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 su 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 di SQL Server, perché sono situati a livello di istanza. Per trasferire questo tipo di dati dall'istanza di origine all'istanza di destinazione, utilizza gli script di PowerShell o gli strumenti come DBAtools.

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

Altri approcci per le migrazioni di manutenzione pianificate

L'utilizzo di altri approcci può offrire maggiore controllo e flessibilità nel processo di migrazione della manutenzione pianificata.

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

• Esegui 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 quali lasciare indietro. Potresti decidere di estrarre solo un sottoinsieme delle 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.
• Esegui il refactoring delle strutture del database e sincronizza il tempo di inattività sostenuto con il tempo di inattività della migrazione.
• Consolidare più istanze o database in un'unica istanza o database, per mitigare i costi operativi e ridurre i problemi di scalabilità. Ad esempio, potresti voler cambiare il tuo approccio da un'istanza, un database o uno schema per cliente a un'unica struttura di database ottimizzata per l'architettura multi-tenancy.

Altri approcci includono:

• Utilizza file CSV o JSON: con questo approccio estrai i dati del database nei file e quindi li importi nelle istanze di destinazione.

  • Questo metodo, in genere più lento, consente di eseguire la migrazione di un sottoinsieme di tabelle (o di dati all'interno di una determinata tabella).
  • I formati CSV e JSON sono interpretabili da molti strumenti.
  • Se automatizzi il processo, puoi scegliere di passare a una migrazione della replica continua in batch.

• Utilizza la procedura guidata di importazione ed esportazione di SQL Server di Microsoft: questo strumento utilizza SQL Server Integration Services (SSIS) e consente di importare i dati da varie origini, come altri motori di database o file flat.

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

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

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

  • Con questo approccio, ripristini il backup di SQL Server dell'istanza RDS in un'altra istanza autonoma di SQL Server su Compute Engine. Utilizza quindi la replica degli snapshot per eseguire la migrazione a Cloud SQL per SQL Server.
  • La generazione degli snapshot mantiene bloccati le tabelle di origine, che potrebbero influire sui carichi di lavoro.
  • La replica degli snapshot potrebbe introdurre carichi aggiuntivi sul server Amazon RDS.
  • Tuttavia, puoi scegliere quali oggetti sottoporre a migrazione o replica, per offrire flessibilità.
  • Per maggiori dettagli, consulta Migrazione dei dati da SQL Server 2017 a Cloud SQL per SQL Server utilizzando la replica degli snapshot.

Strumenti per la migrazione della replica continua

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

Il diagramma di flusso precedente mostra i seguenti punti decisionali:

• Preferisci utilizzare i servizi di migrazione gestiti?

  • In caso affermativo, passa 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, consigliamo Database Migration Service. In caso contrario, esamina le opzioni di terze parti.
  • In caso contrario, vai alla prossima decisione. Se la replica integrata del motore del database è supportata, ti consigliamo di utilizzare la replica integrata. In caso contrario, ti consigliamo di valutare altre opzioni di migrazione.

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

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

• La replica integrata specifica del motore del database è supportata?

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

Le sezioni seguenti descrivono gli strumenti che possono essere utilizzati per le migrazioni di repliche continue, con i relativi limiti e best practice.

Database Migration Service per la migrazione della replica continua

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

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

• Puoi permetterti un tempo di inattività minimo.
• Non è necessaria la sincronizzazione in tempo reale.
• Non è necessario eseguire trasformazioni dei dati durante la migrazione.

Se scegli questo strumento, considera le seguenti restrizioni e best practice:

• Il tempo di inattività dipende dalla frequenza dei backup dei log delle transazioni.
• I backup non includono gli accessi, le autorizzazioni o i ruoli del server di SQL Server, perché sono a livello di istanza. Esegui uno script fuori dall'istanza di origine e poi trasferiscili all'istanza di destinazione utilizzando script di PowerShell o strumenti come DBAtools.

Per un elenco completo delle limitazioni, vedi Limitazioni note.

Replica integrata del motore del database

Cloud SQL supporta la replica per SQL Server. Tuttavia, Amazon RDS standard per SQL Server 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 della replica continua

Altri approcci per la migrazione della replica continua includono i seguenti:

• Esegui il refactoring delle applicazioni in modo che esegua Y (scrittura e lettura) o utilizzi un microservizio di accesso ai dati.

  • La replica continua viene eseguita dalle tue applicazioni.
  • Le attività di migrazione si concentrano sul refactoring o sullo sviluppo di strumenti che si connettono alle istanze del tuo database.
  • Dopo il refactoring e il deployment delle applicazioni dei lettori, viene gradualmente eseguito il refactoring dell'istanza di destinazione.

• Implementare funzioni che eseguono query periodiche sui dati sull'istanza di origine, filtrano solo i nuovi dati e scrivono i dati in file CSV, JSON o Parquet.

  • Questi file sono archiviati in un bucket Google Cloud Storage.
  • I file possono essere scritti immediatamente nell'istanza del database di destinazione utilizzando Cloud Functions.
  • Le funzionalità di Change Data Capture (CDC) possono aiutarti a eseguire una migrazione della replica quasi in tempo reale.
  • Puoi trasferire flussi 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 migrazioni della replica continua

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

Striim è una piattaforma in memoria end-to-end per la raccolta, l'applicazione di filtri, la trasformazione, l'arricchimento, l'aggregazione, l'analisi e la distribuzione di dati in tempo reale:

• Vantaggi:

  • Gestisce grandi volumi di dati e migrazioni complesse.
  • Change Data Capture (CDC) integrata per SQL Server.
  • Modelli di connessione preconfigurati e pipeline no-code.
  • È in grado di gestire grandi database mission critical che operano sotto un enorme carico transazionale.
  • 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 maggiori informazioni, consulta Operazioni DDL supportate e Note e limitazioni sull'evoluzione dello schema.

Per ulteriori informazioni su Striim, consulta Esecuzione di Striim in Google Cloud.

Debezium è una piattaforma distribuita open source per CDC e può trasmettere flussi di modifiche ai dati ai sottoscrittori esterni:

• Vantaggi:

  • Open source.
  • Un solido supporto dalla community.
  • Conveniente.
  • Controllo granulare su righe, tabelle o database.
  • Specializzato per l'acquisizione di modifiche in tempo reale dai log delle transazioni del database.

• Sfide:

  • 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 del monitoraggio manuale con Grafana e Prometheus.
  • Nessun supporto per la replica batch incrementale.

Per ulteriori informazioni sulle migrazioni di Debezium, consulta Replica di dati quasi in tempo reale con Debezium.

Definire il piano di migrazione e le tempistiche

Per una migrazione dei database e una migrazione completa della produzione, ti consigliamo di preparare un piano di migrazione ben definito e completo. Per ridurre l'impatto sulla tua attività, ti consigliamo di creare un elenco di tutti gli elementi di lavoro necessari.

La definizione dell'ambito della migrazione rivela le attività di lavoro da eseguire 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, potrebbero essere necessarie attività di pre-migrazione o post-migrazione per implementare questo filtro. Ti assicuri inoltre che la migrazione del database non influisca sull'accordo sul livello del servizio (SLA) e sul piano di continuità aziendale esistenti.

Ti consigliamo di includere nella documentazione relativa alla 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. Di solito, le migrazioni ben pianificate vengono eseguite senza problemi, ma potrebbero sorgere problemi non pianificati. Ti consigliamo di avere sempre un piano di rollback. Come best practice, segui le indicazioni riportate in Eseguire la migrazione a Google Cloud: best practice per la convalida di un piano di migrazione.

DDT

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

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

Matrice RACI

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

Cronologia

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

Per ogni ambiente di migrazione, 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 sequenza temporale non deve includere solo l'esecuzione delle attività di preparazione pre-migrazione, ma anche le attività di convalida, controllo o test che vengono eseguite 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à dei team.

Un piano T-Minus potrebbe avere il seguente aspetto:

Data	Fase	Categoria	Attività	Ruolo	T-meno	Stato
1/11/2023	Pre-migrazione	Test	Crea report di valutazione	Il team addetto all'individuazione	-21	Completato
7/11/2023	Pre-migrazione	Preparazione del bersaglio	Progettare l'ambiente di destinazione come descritto nel documento di progettazione	Team della migrazione	-14	Completato
15/11/2023	Pre-migrazione	Governance aziendale	Data migrazione e approvazione T-Minus	Leadership	-6	Completato
18/11/2023	Migrazione	Configura DMS	Creazione di profili di connessione	Ingegnere della migrazione cloud	-3	Completato
19/11/2023	Migrazione	Configura DMS	Crea e avvia i job di migrazione	Ingegnere della migrazione cloud	-2	Non avviata
19/11/2023	Migrazione	Monitora DMS	Monitora i job DMS e le modifiche DDL nell'istanza di origine	Ingegnere della migrazione cloud	-2	Non avviata
21/11/2023	Migrazione	DMS di cutover	Promuovi replica DMS	Ingegnere della migrazione cloud	0	Non avviata
21/11/2023	Migrazione	Convalida della migrazione	Convalida della migrazione del database	Team della migrazione	0	Non avviata
21/11/2023	Migrazione	Test applicazione	Esegui test delle funzionalità e delle prestazioni	Team della migrazione	0	Non avviata
22/11/2023	Migrazione	Governance aziendale	Convalida della migrazione GO o NO GO	Team della migrazione	1	Non avviata
23/11/2023	Dopo la migrazione	Convalida il monitoraggio	Configura il monitoraggio	Team Infrastruttura	2	Non avviata
25/11/2023	Dopo la migrazione	Sicurezza	Rimuovi account utente DMS	Team della sicurezza	4	Non avviata

Migrazioni di più database

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

Ti consigliamo di iniziare la procedura eseguendo la migrazione di un database più piccolo, idealmente non mission critical. Questo approccio può aiutarti a creare conoscenze e strumenti di migrazione. Puoi rilevare eventuali difetti del processo anche nelle prime fasi della pianificazione della migrazione complessiva.

Se devi eseguire la migrazione di più database, le cronologie possono essere parallelizzate. Ad esempio, per velocizzare il processo di migrazione, potresti scegliere di eseguire contemporaneamente la migrazione di un gruppo di database piccoli, statici o meno mission-critical, come illustrato nel diagramma seguente.

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. Senza le attività di preparazione, la migrazione non può avvenire o comportare uno stato inutilizzabile del database migrato.

Le attività di preparazione possono essere categorizzate come segue:

• Preparazioni e prerequisiti delle istanze 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à di configurazione comuni e di prerequisiti:

• A seconda del percorso di migrazione, potrebbe essere necessario consentire le connessioni remote sulle 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 in un gruppo di sicurezza le regole 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 (flussi di modifiche tramite CDC), devi utilizzare un'istanza RDS completa e non una replica di lettura, con CDC abilitata. Per maggiori dettagli, consulta Utilizzo di Change Data Capture con SQL Server.

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

Preparazione e prerequisiti del database di origine

• Assicurati che nel database di origine siano disponibili memoria e spazio di archiviazione del buffer 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 aggiuntivo nel buffer.
• Documenta le impostazioni dei parametri del database e applicale all'istanza di destinazione prima di eseguire il test e la convalida della migrazione.

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

  • Misura la dimensione dei dati e le prestazioni del carico di lavoro. Quanto tempo richiedono in media le query o le transazioni importanti? Quanto dura durante le ore di punta?
  • Documenta le misurazioni di riferimento per i confronti successivi, per aiutarti a decidere se la fedeltà della migrazione del database è soddisfacente. Decidi se puoi cambiare i carichi di lavoro di produzione e ritirare l'ambiente di origine o se ne hai comunque bisogno per i fallback.

Configurazione di Cloud SQL

Scegli con attenzione le dimensioni e le specifiche dell'istanza del database Cloud SQL di destinazione in modo che corrispondano all'origine per esigenze di prestazioni simili. Presta particolare attenzione a dimensioni del disco e velocità effettiva, IOPS e numero di vCPU. Il dimensionamento non corretto può comportare lunghi tempi di migrazione e problemi di prestazioni del database, nonché degli errori del database e delle prestazioni delle applicazioni.

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

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

• Scegli con attenzione il progetto e la regione delle istanze Cloud SQL di destinazione. Non è possibile eseguire la migrazione di istanze Cloud SQL tra regioni e progetti Google Cloud senza Data Transfer.

• 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 backup del motore del database integrati o Database Migration Service. Per maggiori dettagli, esamina le limitazioni nella sezione Backup specifici del motore del database.

• Esamina i flag di configurazione specifici del motore del database e confronta i valori dell'istanza di origine e di destinazione. Assicurati di capire il loro impatto e se devono essere uguali o meno. Ad esempio, consigliamo di confrontare i valori nella visualizzazione sys.configurations nel database di origine con i valori nell'istanza Cloud SQL. Tieni presente che non tutti i flag devono essere uguali e che non sono consentite modifiche 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 dell'istanza 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 la migrazione o lo strumento di migrazione 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 Archiviare i file di backup in un bucket Cloud Storage.

Se utilizzi la replica, devi assicurarti che questCloud SQL abbia accesso al database principale. Ciò può essere fatto attraverso le opzioni di connettività documentate.

A seconda dello scenario e della criticità, potrebbe essere necessario implementare uno scenario di riserva, che di solito include l'inversione della direzione della replica. In questo caso, potrebbe essere necessario un ulteriore meccanismo di replica da Cloud SQL all'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, per iniziare devi utilizzare Google Cloud Marketplace. Quindi, per configurare l'ambiente di migrazione in Striim, puoi utilizzare Flow Designer per creare e modificare applicazioni oppure puoi selezionare un modello preesistente. Le applicazioni possono anche essere codificate utilizzando il linguaggio di programmazione TQL (Tungsten Query Language). Con una dashboard di convalida dei dati puoi ottenere una rappresentazione visiva dei dati gestiti dall'applicazione Striim.

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

Definisci le attività di esecuzione

Le attività di esecuzione implementano il lavoro di migrazione stesso. Le attività dipendono dallo strumento di migrazione scelto, come descritto nelle sottosezioni riportate di seguito.

Backup specifici del motore del database

Per ulteriori informazioni e istruzioni per i backup specifici dei database, vedi Importare dati da un file BAK a Cloud SQL per SQL Server ed Esportazione di dati da RDS per SQL Server. Per ulteriori informazioni su come automatizzare i caricamenti dei file di log delle transazioni, consulta Pianificare 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 carichi di lavoro possono lasciare un tempo di inattività ridotto per la migrazione e la produzione.

Il processo di migrazione di solito prevede 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 e caricalo nello stesso bucket Cloud Storage. Per ulteriori informazioni su come automatizzare questo processo, consulta Pianificare i caricamenti dei file di log delle transazioni per Amazon RDS.
• In Database Migration Service viene monitorata l'elaborazione dei backup dei log delle transazioni.
• Interrompi la scrittura sul database di origine.
• Attendi che l'origine e la destinazione vengano sincronizzate, ovvero quando viene elaborato il backup finale del log delle transazioni.
• Arresta 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 quindi promossa a istanza principale.
• Eseguire il deployment delle applicazioni che puntano al nuovo database di destinazione.

Per una procedura dettagliata di configurazione della migrazione, consulta Eseguire 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 personalizzata di Amazon RDS e poi replicare in Cloud SQL.

Cloud SQL supporta la replica per SQL Server. Per ulteriori informazioni sulla replica da un server esterno, consulta Migrazione dei dati da SQL Server 2017 a Cloud SQL per SQL Server utilizzando la replica degli snapshot.

Strumenti di terze parti

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

Definire gli scenari di fallback

Definisci le attività di fallback per ogni attività di esecuzione della migrazione, a scopo di salvaguardia da problemi imprevisti che potrebbero verificarsi durante il processo di migrazione. Le attività di riserva in genere dipendono dalla strategia di migrazione e dagli strumenti utilizzati.

La procedura di riserva potrebbe richiedere uno sforzo significativo. Come best practice, non eseguire la migrazione completa della produzione finché i risultati del test non sono soddisfacenti. Sia la migrazione del database che lo scenario di fallback devono essere testati adeguatamente per evitare un'interruzione grave.

Definisci i criteri di successo e la casella temporale per tutte le attività di esecuzione della migrazione. Eseguire una prova di migrazione consente di raccogliere informazioni sulle tempistiche previste per ogni attività. Ad esempio, per una migrazione di manutenzione pianificata, puoi permetterti il tempo di inattività rappresentato dalla finestra di migrazione completa. 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 metà. A seconda del tempo trascorso del tempo di inattività pianificato, potrebbe essere necessario posticipare la migrazione se l'attività di migrazione non viene completata nel periodo di tempo previsto.

Un piano di riserva di solito si riferisce al rollback della migrazione dopo aver eseguito la migrazione completa in produzione, se si verificano problemi nell'istanza di destinazione. Se implementi un piano di riserva, ricorda che deve essere considerato come una migrazione completa del database, incluse pianificazione e test.

Se scegli di non avere un piano di riserva, assicurati di comprendere le possibili conseguenze. L'assenza di un piano di riserva può aumentare gli sforzi imprevisti e causare interruzioni evitabili nel processo di migrazione.

Sebbene un fallback sia l'ultima risorsa e la maggior parte delle migrazioni dei database non lo utilizzerà, ti consigliamo di adottare sempre una strategia di riserva.

Semplicità di riserva

In questa strategia di riserva, ripristini l'istanza del database di origine originale per le applicazioni. Adotta questa strategia se puoi permetterti tempi di inattività quando ricorri o se non hai bisogno delle transazioni impegnate nel nuovo sistema target.

Se hai bisogno di tutti i dati scritti nel tuo database di destinazione e puoi permetterti un tempo di inattività, puoi considerare di interrompere le scritture sull'istanza del database di destinazione, eseguire backup integrati e ripristinarli sull'istanza di origine e poi ricollegare le tue applicazioni all'istanza del database di origine iniziale. A seconda della natura del carico di lavoro e della quantità di dati scritti sull'istanza del database di destinazione, potresti trasferirli nel sistema di database di origine iniziale in un secondo momento, soprattutto se i carichi di lavoro non dipendono da tempi specifici per la creazione di record o da vincoli di tempo nell'ordinamento.

Replica inversa

In questa strategia, devi replicare le scritture che si verificano sul nuovo database di destinazione dopo il passaggio della produzione al database di origine iniziale. In questo modo, mantieni sincronizzata l'origine originale con il nuovo database di destinazione e le scritture avvengono sulla nuova istanza del database di destinazione. Il suo svantaggio principale è che non puoi testare il flusso di replica finché non esegui il passaggio all'istanza del database di destinazione. Di conseguenza, non consente i test end-to-end e non è possibile eseguire il fallback.

Scegli questo approccio se puoi conservare l'istanza di origine per un po' di tempo ed eseguire la migrazione mediante la replica continua.

Inoltra replica

Questa strategia è una variante della replica inversa. Puoi replicare le scritture sul nuovo database di destinazione su una terza istanza di database a tua scelta. Puoi puntare le tue applicazioni a questo terzo database, che si connette al server ed esegue query di sola lettura quando il server non è disponibile. Puoi utilizzare qualsiasi meccanismo di replica, a seconda delle esigenze. Il vantaggio di questo approccio è che può essere testato completamente end-to-end.

Utilizza questo approccio quando vuoi avere sempre un servizio di riserva o quando devi ignorare il database di origine iniziale subito dopo il passaggio in produzione.

Scritture duplicate

Se scegli una strategia di migrazione dei microservizi Y (scrittura e lettura) o accesso ai dati, questo piano di riserva è già impostato. Questa strategia è più complicata, perché devi eseguire il refactoring delle applicazioni o sviluppare strumenti che si connettono alle istanze del tuo database.

Le applicazioni scrivono nelle istanze del database di origine e di destinazione iniziali, il che consente di eseguire un passaggio di produzione graduale fino a quando non utilizzi solo le istanze del database di destinazione. In caso di problemi, riconnetti le applicazioni all'origine iniziale senza tempi di inattività. Puoi ignorare l'origine iniziale e il meccanismo di scrittura duplicato se consideri la migrazione eseguita senza problemi.

Consigliamo questo approccio quando è fondamentale non avere tempi di inattività per la migrazione, disporre di un fallback affidabile e quando si dispone di tempo e risorse per eseguire il refactoring delle applicazioni.

Esegui test e convalida

L'obiettivo di questo passaggio è testare e convalidare quanto segue:

• Migrazione dei dati nel database riuscita.
• L'integrazione con le applicazioni esistenti dopo l'uso della nuova istanza di destinazione.

Definisci i principali fattori di successo, soggettivi alla migrazione. Di seguito sono riportati alcuni esempi di fattori soggettivi:

• Quali dati eseguire la migrazione. Per alcuni carichi di lavoro, potrebbe non essere necessario eseguire la migrazione di tutti i dati. Potresti non voler eseguire la migrazione di dati già aggregati, ridondanti, archiviati o obsoleti. Puoi archiviare i dati in un bucket Cloud Storagee come backup.
• Una percentuale accettabile di perdita di dati. Questo vale in particolare per i dati utilizzati per i carichi di lavoro di analisi, dove la perdita di una parte dei dati non influisce sulle tendenze generali o sulle prestazioni dei carichi di lavoro.
• Criteri di qualità e quantità dei dati, che puoi applicare all'ambiente di origine e confrontarli con l'ambiente di destinazione dopo la migrazione.
• Criteri delle prestazioni. 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 nel tuo ambiente di origine potrebbero non essere mappate direttamente alle destinazioni dell'ambiente Google Cloud. Ad esempio, configurazioni da volumi SSD per uso generico (gp2 e gp3) con prestazioni di burst di IOPS o unità SSD IOPS sottoposte a provisioning. Per confrontare e dimensionare correttamente le istanze di destinazione, esegui il benchmarking delle istanze di origine, sia nelle fasi di valutazione che di convalida.

Nel processo di benchmarking, applicherai sequenze di operazioni di tipo produzione alle istanze del database. Durante questo periodo, acquisisci ed elabori le metriche per misurare e confrontare il rendimento relativo 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 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à.

Per i test, la convalida e il benchmark dei database si possono usare i seguenti strumenti:

• HammerDB: uno strumento di benchmarking e test di carico di database open source. Supporta carichi di lavoro 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 su diversi motori di database e configurazioni di archiviazione. Per ulteriori informazioni, consulta Test di carico di SQL Server con HammerDB e Eseguire il benchmarking delle prestazioni di Amazon RDS SQL Server utilizzando HammerDB.
• Strumento di benchmark DBT2: benchmarking specializzato per MySQL. Un set di kit per i carichi di lavoro del database imita un'applicazione per un'azienda che possiede dei warehouse e prevede un mix di transazioni di lettura e scrittura. Usa questo strumento se vuoi usare un test di carico pronta all'uso per l'elaborazione delle transazioni online (OLTP).
• DbUnit: uno strumento open source di test delle unità utilizzato per testare le interazioni dei database relazionali in Java. La configurazione e l'uso sono semplici e supporta più motori di database (MySQL, PostgreSQL, SQL Server e altri). Tuttavia, a volte l'esecuzione del test 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 creare 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 da parte della community o di una documentazione completa, rispetto ad altri strumenti. Ti consigliamo questo strumento se le query non sono complesse e vuoi eseguire test automatici e integrarle nel tuo processo di integrazione e distribuzione continue.

Per eseguire un test end-to-end, compreso il test del piano di migrazione, esegui sempre un esercizio di prova della migrazione. Una prova esegue la migrazione del database nell'intero ambito senza cambiare carichi di lavoro di produzione e offre i seguenti vantaggi:

• Consente di assicurare che la migrazione di tutti gli oggetti e di tutte le configurazioni venga eseguita 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 sequenza temporale.
• Rappresenta un'occasione per testare, convalidare e adattare il piano di migrazione. A volte non è possibile pianificare tutto in anticipo e questo può aiutarti a individuare eventuali lacune.

I test sui dati possono essere eseguiti su un piccolo insieme di database di cui eseguire la migrazione o sull'intero set. 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 mediante lo stesso strumento, in particolare se si tratta di un servizio di migrazione gestito.

Per i test, dovresti avere accesso sia ai database di origine che di destinazione ed eseguire le seguenti attività:

• Confrontare gli schemi di origine e di destinazione. Controlla se esistono tutte le tabelle e tutti gli eseguibili. Controllare i conteggi delle righe e confrontare i dati a livello di database.
• Eseguire script di convalida dei dati personalizzati.
• Verifica che i dati migrati siano visibili anche nelle applicazioni che hanno scelto di utilizzare il database di destinazione (i dati migrati vengono letti attraverso l'applicazione).
• Eseguire 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 di dati nei database di destinazione tramite le applicazioni, in modo che i carichi di lavoro supportino completamente i dati migrati insieme ai dati appena creati.
• Testa le prestazioni delle query di database più utilizzate per osservare se si è verificato un peggioramento dovuto a configurazioni errate o a dimensioni non corrette.

Idealmente, tutti questi scenari di test di migrazione sono automatizzati e ripetibili su qualsiasi sistema di origine. La suite di scenari di test automatici è adattata per funzionare contro le applicazioni trasferite.

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

Strumento di convalida dei dati

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

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

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

La TVP supporta i seguenti tipi di convalide:

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

Per ulteriori informazioni sulla TVP, consulta il repository Git e la pagina Convalida dei dati semplificata con lo strumento di convalida dei dati di Google Cloud.

Eseguire la migrazione

Le attività di migrazione includono le attività di supporto del trasferimento da un sistema all'altro.

Considera le seguenti best practice per la migrazione dei dati:

• Informa i team coinvolti ogni volta che inizia e finisce un passaggio del piano.
• Se un passaggio richiede più tempo del previsto, confronta il tempo trascorso con il tempo massimo previsto per quel passaggio. In tal caso, rilascia aggiornamenti regolari degli intermediario per i team coinvolti.
• Se l'intervallo di tempo è superiore alla quantità massima di tempo riservata per ogni passaggio del piano, valuta la possibilità di eseguire il rollback.
• Prendi decisioni "a o senza obbligo" per ogni fase della migrazione e piano di implementazione.
• Prendi in considerazione azioni di rollback o scenari alternativi per ogni passaggio.

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

Esegui la migrazione completa della produzione

Il processo di migrazione completa della produzione può variare a seconda della strategia di migrazione scelta. Se i carichi di lavoro hanno tempi di inattività, la migrazione completa inizia interrompendo le scritture sul database di origine.

Per le migrazioni della replica continua, in genere vengono eseguiti i seguenti passaggi generali nel processo di migrazione completa:

• Interrompi la scrittura sul database di origine.
• Svuoti la fonte.
• Arresta il processo di replica.
• Eseguire il deployment delle applicazioni che puntano al nuovo database di destinazione.

Dopo aver eseguito la migrazione dei dati utilizzando lo strumento di migrazione scelto, i dati nel database di destinazione vengono convalidati. Confermi che il database di origine e i database di destinazione siano sincronizzati e che i dati nell'istanza di destinazione siano conformi agli standard di successo della migrazione che hai scelto.

Una volta che la convalida dei dati ha superato i criteri, puoi eseguire la migrazione completa a livello di applicazione. Esegui il deployment dei carichi di lavoro sottoposti a refactoring per utilizzare la nuova istanza di destinazione. Puoi eseguire il deployment delle versioni delle applicazioni che puntano alla nuova istanza del database di destinazione. I deployment possono essere eseguiti tramite aggiornamenti in sequenza, release temporanee o utilizzando un pattern di deployment blu/verde. Potrebbero verificarsi dei tempi di inattività delle applicazioni.

Segui le best practice per la migrazione completa della produzione:

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

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

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

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

• Raccogli le impostazioni dei parametri di database dell'istanza di origine. In alternativa, controlla che corrispondano a quelli raccolti durante la fase di creazione dell'inventario. Regola 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 di destinazione. Se le statistiche sono diverse, è difficile confrontare le prestazioni dell'istanza di origine e dell'istanza di destinazione.

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

Come best practice per mantenere aggiornate le istanze di origine dopo la migrazione completa, replica al database di origine le scritture eseguite sulle istanze Cloud SQL di destinazione. Se hai bisogno di eseguire il rollback, puoi utilizzare le istanze di origine precedenti con una perdita di dati minima.

Oltre alla pulizia dell'ambiente di origine, devi 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.
• Configura lo spazio di archiviazione sull'istanza in modo che abbia almeno il 20% di spazio disponibile per contenere eventuali operazioni critiche di manutenzione del database che Cloud SQL potrebbe eseguire. Per ricevere un avviso se lo spazio su disco disponibile scende al di sotto del 20%, crea un criterio di avviso basato su metriche per la metrica di utilizzo del disco.

Non avviare un'operazione amministrativa prima del completamento dell'operazione precedente.

Per ulteriori informazioni, consulta le seguenti risorse:

• Informazioni sulla manutenzione delle istanze Cloud SQL.
• Impostazioni specifiche per SQL Server Engine.

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 non soddisfa i requisiti di ottimizzazione. I passaggi di questa iterazione sono i seguenti:

1. Valuta il tuo ambiente attuale e i tuoi team.
2. Definisci i requisiti e gli obiettivi di ottimizzazione.
3. Ottimizza il tuo ambiente e i tuoi team.
4. Ottimizza il processo di ottimizzazione.

Ripeti la sequenza finché non hai raggiunto gli obiettivi di ottimizzazione.

Per ulteriori informazioni sull'ottimizzazione dell'ambiente Google Cloud, consulta Migrazione a Google Cloud: ottimizzazione dell'ambiente e Processo di ottimizzazione delle prestazioni.

Definisci i tuoi requisiti di ottimizzazione

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

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

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

• In caso di carichi di lavoro ad alta intensità di lettura, aggiungi repliche di lettura per trasferire il traffico dall'istanza principale.
• Per i carichi di lavoro mission critical, utilizza la configurazione ad alta disponibilità, le repliche per il failover a livello di regione e una solida configurazione per il ripristino di emergenza.
• Per i carichi di lavoro meno critici, i backup automatici e on demand possono essere sufficienti.
• Per impedire la rimozione accidentale delle istanze, utilizza la protezione da eliminazione delle istanze.
• Abilita il recupero point-in-time (PITR) per la tua istanza Cloud SQL per SQL Server.
• Automatizza i backup dei database SQL utilizzando i piani di manutenzione.

Aumenta la convenienza economica della tua infrastruttura di database

Per avere un impatto economico positivo, i carichi di lavoro devono utilizzare in modo efficiente le risorse e i servizi disponibili. 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 aumentano, abilita gli aumenti automatici dello spazio di archiviazione. Tuttavia, assicurati di configurare le istanze in modo che abbiano un po' di buffer nei carichi di lavoro di picco. Ricorda che i carichi di lavoro del database tendono ad aumentare nel tempo.

• Identifica le possibili risorse sovrastimate:

  • Stabilire 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 offre dashboard predefinite che aiutano a identificare l'integrità e l'utilizzo della capacità di molti componenti di Google Cloud, incluso Cloud SQL. Per maggiori dettagli, consulta Creare e gestire le dashboard personalizzate.

• Identifica le istanze che non richiedono configurazioni dell'alta disponibilità o del ripristino di emergenza 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 più conveniente (SSD o HDD) per il tuo caso d'uso.

  • Nella maggior parte dei casi d'uso, SSD è la scelta più efficiente ed economica.
  • Se i tuoi set di dati sono di grandi dimensioni (10 TB o più), non sensibili alla latenza o si accede raramente, HDD potrebbe essere più appropriato.
  • Per maggiori dettagli, vedi Scegliere tra archiviazione SSD e HDD.

• Acquista sconti per impegno di utilizzo per carichi di lavoro con esigenze prevedibili in termini di risorse.

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

Per ulteriori informazioni e opzioni, consulta Ottieni di più con meno risorse: introduzione dei 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, considera quanto segue:

• Esegui la migrazione a SQL Server Standard Edition, se gli SLA soddisfano i 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 derivante dalla disattivazione di SMT. Questa strategia può aiutare 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 gli SLA non siano interessati.
• Considera una migrazione eterogenea da Cloud SQL per SQL Server a Cloud SQL per PostgreSQL o AlloyDB per PostgreSQL, a seconda del tuo carico di lavoro.

Aumenta le prestazioni della tua infrastruttura di database

Problemi di prestazioni minori legati al database spesso possono influire sull'intera operazione. Per mantenere e aumentare le prestazioni dell'istanza Cloud SQL, considera queste 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 (accordo sul livello del servizio) dell'istanza.

• Assicurati che l'istanza non sia vincolata alla memoria o alla CPU.

  • Per carichi di lavoro che richiedono alte prestazioni, assicurati che l'istanza abbia almeno 60 GB di memoria.
  • Per inserimenti, aggiornamenti o eliminazioni lenti dei 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 Query Insights predefinita in Cloud Monitoring (o funzionalità simili integrate nel motore del database). Identificare i comandi più costosi e provare a ottimizzarli.

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

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

• Evita la frammentazione dei dati e dell'indice. Imposta una pianificazione per ricreare gli indici in SQL Server, a seconda della frequenza di modifica dei dati.

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

• Per la manutenzione degli indici e delle statistiche, consulta la pagina Soluzione di manutenzione SQL Server.

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

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

Per ulteriori informazioni sull'aumento delle prestazioni, consulta Prestazioni in "Diagnosticare 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 complesse e richiedere molto tempo. Per questo motivo, è essenziale una posizione centralizzata in cui tutti i membri del team possano vedere cosa sta succedendo a livello di database e istanza. Puoi monitorare le istanze Cloud SQL nei seguenti modi:

• Cloud SQL utilizza agenti personalizzati della memoria integrata per raccogliere la telemetria delle query.

  • Utilizza Cloud Monitoring per raccogliere le misurazioni del tuo servizio e delle risorse Google Cloud che utilizzi.
  • Puoi creare dashboard personalizzate per monitorare le metriche e configurare criteri di avviso per ricevere notifiche tempestive.

• Cloud Logging raccoglie dati di logging dai componenti dell'applicazione comuni. Puoi anche visualizzare ed eseguire query sui log per la tua istanza Cloud SQL.

• Cloud Trace raccoglie dati sulla latenza ed esegue piani di query dalle applicazioni per aiutarti a tenere traccia del modo in cui le richieste si propagano nella tua applicazione.

• Il Centro database offre una panoramica del parco risorse di database centralizzato e assistita. Puoi monitorare l'integrità dei database, la configurazione della disponibilità, la protezione dei dati, la sicurezza e la conformità del settore.

Linee guida operative e best practice generali di Cloud SQL

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

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

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

Per essere in grado di gestire in modo efficiente eventuali problemi di prestazioni del database che potresti riscontrare, utilizza le seguenti linee guida finché il problema non viene risolto:

Fai lo scale up dell'infrastruttura: aumenta le risorse, ad esempio la velocità effettiva del disco, vCPU e RAM. A seconda dell'urgenza, della disponibilità e dell'esperienza del tuo team, la scalabilità verticale dell'istanza può risolvere la maggior parte dei problemi di prestazioni. In seguito, potrai esaminare ulteriormente la causa principale del problema in un ambiente di test e valutare delle opzioni per eliminarlo.

Eseguire e pianificare operazioni di manutenzione del database: deframmentazione dell'indice, aggiornamenti delle statistiche, analisi "vacuum" e reindicizzazione di tabelle molto aggiornate. Controlla se e quando sono state eseguite le ultime operazioni di manutenzione, soprattutto sugli oggetti interessati (tabelle, indici). Scopri se c'è stata una modifica alle normali attività del database. ad esempio l'aggiunta di una nuova colonna o la presenza di molti aggiornamenti in una tabella.

Esegui ottimizzazione e ottimizzazione del database: le tabelle nel tuo database sono strutturate correttamente? Le colonne contengono i tipi di dati corretti? Il tuo modello dati è adatto al tipo di carico di lavoro? Analizza le tue query lente e i relativi piani di esecuzione. Utilizzano gli indici disponibili? Verifica la presenza di scansioni degli indici, blocchi e attese su altre risorse. Valuta la possibilità di aggiungere indici per supportare le query critiche. Elimina gli indici non critici e le chiavi esterne. Valuta la possibilità di riscrivere query e join complessi. Il tempo necessario per risolvere un 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 utilizzare repliche di lettura. Se la scalabilità verticale non è sufficiente per le tue esigenze e le misure di ottimizzazione e ottimizzazione del database non sono utili, valuta la possibilità di scalare orizzontalmente. Il routing delle query di lettura dalle tue applicazioni a una replica di lettura migliora le prestazioni complessive del carico di lavoro del database. Tuttavia, potrebbe essere necessario un ulteriore impegno per modificare le applicazioni per la connessione alla replica di lettura.

Riprogettazione dell'architettura del database: valuta la possibilità di partizionare e indicizzare il database. Questa operazione richiede uno sforzo notevolmente maggiore rispetto all'ottimizzazione e all'ottimizzazione del database e potrebbe comportare una migrazione dei dati, ma può essere una soluzione a lungo termine. A volte, una progettazione di modello dei dati non ottimale può portare a 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. e archiviare i dati non più necessari, se possibile. Normalizza la struttura del database, ma ricorda che la denormalizzazione può anche migliorare le prestazioni.

partizionamento orizzontale del database: puoi fare lo scale out delle scritture effettuando lo sharding del database. Lo sharding è un'operazione complicata e comporta la riprogettazione dell'architettura del database e delle applicazioni in un modo specifico ed esecuzione della migrazione dei dati. Puoi suddividere l'istanza del database in più istanze più piccole utilizzando criteri di partizionamento specifici. I criteri possono essere basati sul cliente o sul soggetto. Questa opzione consente di scalare orizzontalmente sia le scritture che le letture. Tuttavia, aumenta la complessità dei carichi di lavoro di database e applicazioni. Potrebbe anche portare a shard non bilanciati chiamati hotspot, che supererebbero il vantaggio dello sharding.

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

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

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

  • Una dimensione del disco di almeno 4 TB garantisce una maggiore velocità effettiva e IOPS.
  • Una vCPU maggiore fornisce più IOPS e velocità effettiva. Se utilizzi una vCPU più alta, monitora il database in attesa di parallelismo, che potrebbe anche aumentare.

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

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

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

• Evita che i file di database diventino di dimensioni inutilmente grandi. Imposta autogrow in MB anziché come percentuale, utilizzando gli incrementi appropriati in base 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 disponibile.

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

• I join hash ricorsivi o i blocchi di hashing riducono le prestazioni in un server. Se in una traccia noti molti eventi di avviso relativi all'hash, aggiorna le statistiche nelle colonne che vengono unite. Per ulteriori informazioni, consulta la sezione Hash Warning Event Class.

Per ulteriori dettagli, consulta Best practice generali e Linee guida operative per Cloud SQL per SQL Server.

Passaggi successivi

• Scopri come eseguire la migrazione da Amazon EC2 a Compute Engine.
• Scopri come eseguire la migrazione da Amazon S3 a Cloud Storage.
• Scopri di più su altri percorsi di migrazione da AWS a Google Cloud.
• Scopri come confrontare i servizi AWS e Azure con i servizi Google Cloud.
• Scopri quando trovare assistenza per le migrazioni.
• Per altre architetture di riferimento, diagrammi e best practice, esplora il Cloud Architecture Center.

Collaboratori

Autori:

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

Altri collaboratori:

• Derek Downey | Developer Relations Engineer
• Paweł Krentowski | Scrittore tecnico
• Matthew Smith | Strategic Cloud Engineer
• Paolo Somdyuti | Esperto di gestione dei dati
• Zach Seils | Esperto di networking

Per vedere profili di LinkedIn non pubblici, accedi a LinkedIn.