Migrazione dei cluster di failover Windows - AWS Guida prescrittiva
ValutazioneMobilitazioneMigrazione

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Migrazione dei cluster di failover Windows

Un cluster di failover Microsoft è un gruppo di server con archiviazione perlopiù condivisa tra di loro. Utilizzando i cluster di failover, è più facile ottenere un'elevata disponibilità delle applicazioni e dei servizi. Inoltre, è possibile migrare i cluster di failover al cloud AWS per trarne vantaggio dall'affidabilità, dalle prestazioni e dalla riduzione del TCO.

I cluster di failover Windows funzionano in modo diverso nel cloud rispetto agli ambienti on-premise. È importante notare che nel cloud possono essere implementati soltanto i cluster con più sottoreti. A differenza degli ambienti on-premise, in un cluster di failover Windows l'indirizzo IP viene assegnato a un adattatore elastico di rete (ENA) anziché a livello di sistema operativo. In un ambiente on-premise è il sistema operativo a gestire l'assegnazione degli indirizzi IP, ma nel cloud tale attività è svolta da un provider cloud (AWS). Poiché il cluster di failover è una funzionalità a livello di sistema operativo, non può assumere il controllo del failover dell'IP. Pertanto, lo stesso IP non può eseguire il failover tra i nodi. Per ovviare a questo problema, è possibile utilizzare cluster con più sottoreti in cui i cluster eseguono il failover su un IP secondario. L'IP secondario viene assegnato a un ENA in una sottorete diversa e può rimanere attivo online. Per ulteriori informazioni, consulta la pagina Failover Clustering Networking Basics and Fundamentals nella documentazione di Microsoft.

La migrazione di un cluster di failover Windows a AWS può essere un processo complesso, ma una pianificazione e un'implementazione accurate consentono di eseguirla con interruzioni minime delle operazioni aziendali. Ad esempio, su un cluster di failover ogni applicazione è configurata in modo diverso, quindi è fondamentale comprenderne le esigenze e poi scoprire in anticipo come soddisfarle nel cloud. Il processo prevede le seguenti fasi:

  • Verificare che tutti i nodi del cluster eseguano la stessa versione di Windows e tutti gli aggiornamenti necessari

  • Configurare il quorum del cluster

  • Garantire che tutte le applicazioni e i dati siano sottoposti a backup e possano essere ripristinati durante la migrazione

Valutazione

La fase di valutazione è un passaggio fondamentale nel processo di migrazione di un cluster di failover ad AWS. Durante questa fase, si raccolgono informazioni sull'ambiente attuale, si determina la fattibilità della migrazione ad AWS e si identificano eventuali sfide o rischi potenziali. Durante la fase di valutazione, ti consigliamo di seguire questi passaggi:

  • Valuta la preparazione delle applicazioni: determina se le tue applicazioni possono essere migrate ad AWS senza modifiche o se devono essere aggiornate o riscritte per sfruttare i servizi nativi del cloud.

  • Valuta i requisiti di rete e sicurezza: determina i requisiti di rete e sicurezza, inclusa la configurazione di firewall, sistemi di bilanciamento del carico e VPN.

  • Valuta i requisiti di migrazione dei dati: determina in che modo i dati verranno migrati ad AWS, comprese le dimensioni e la posizione dei dati, il tempo necessario per la migrazione e gli eventuali costi di trasferimento dei dati. In un ambiente on-premise, potresti utilizzare diverse tecnologie di archiviazione come JBOD, NAS e SAN. Ciascuna di esse può presentare i dati all'applicazione tramite diversi metodi di accesso, ad esempio condivisioni SMB/NFS, SAN Fibre Channel, iSCSI o SAS.

  • Identifica potenziali rischi e sfide: identifica eventuali rischi o sfide che potrebbero influire sul processo di migrazione, come tempi di inattività, problemi di compatibilità o perdita di dati.

  • Stima i costi: stima il costo della migrazione ad AWS, incluso il costo delle istanze EC2, dell'archiviazione, del trasferimento dei dati e di qualsiasi altro servizio AWS necessario.

  • Crea un piano di migrazione: sulla base delle informazioni raccolte durante la fase di valutazione, crea un piano di migrazione dettagliato che includa le tempistiche, le risorse richieste e le fasi necessarie per la migrazione ad AWS.

Valutazione dell'ambiente attuale

Valuta l'ambiente attuale, comprese le configurazioni hardware e software, per stabilire quali componenti devono essere migrati ad AWS. Identifica eventuali dipendenze tra applicazioni, server e database.

Scelta della strategia di migrazione

Valuta le opzioni a tua disposizione per la migrazione ad AWS, tra cui un lift-and-shift approccio o la riprogettazione del tuo ambiente per sfruttare i servizi nativi del cloud.

  • Migrazione tradizionale dei cluster di failover: se stai configurando un cluster da zero nel cloud, puoi seguire i passaggi del Esercitazione: configurazione di un cluster Windows HPC su Amazon EC2 nella Guida per l'utente di Amazon EC2 per le istanze Windows, saltando i passaggi specifici per HPC. In alternativa, puoi creare un cluster di gruppo di disponibilità SQL Server Always On senza seguire i passaggi specifici per SQL. L'archiviazione condivisa è una delle considerazioni più importanti per la migrazione di un cluster di failover. Amazon EBS multi-attach non supporta SCSI-3 Persistent Reservation, ma Amazon FSx for Windows File Server e FSx for NetApp ONTAP funzionano entrambi bene come opzioni di storage condiviso. Uno dei casi d'uso più comuni è l'utilizzo di un'istanza di cluster di failover Always On per un cluster SQL Server con Amazon FSx per Windows File Server. Per ulteriori informazioni, consulta il post Simplify your Microsoft SQL Server high availability deployments using Amazon FSx for Windows File Server del blog sull'archiviazione di AWS. Il passaggio successivo consiste nel portare i nodi nel cloud. A tale scopo, è possibile utilizzare Servizio di migrazione delle applicazioni. Per ulteriori informazioni, consulta il post Migrazione dei cluster Microsoft Windows in AWS utilizzando CloudEndure Migration nel blog di AWS Storage. Dopodiché, è possibile configurare un ruolo in cluster per l'applicazione per conseguire un'elevata disponibilità.

  • Migrazione praticamente senza tempi di inattività utilizzando un cluster esteso: un cluster esteso potrebbe essere la soluzione ideale se devi migrare al cloud un'applicazione aziendale critica e non puoi permetterti tempi di inattività. Con un cluster esteso Microsoft, il sito A e il sito B devono comunicare tra loro tramite una rete, ma possono disporre di un proprio spazio di archiviazione condiviso individuale. È possibile utilizzare tale caratteristica a proprio vantaggio in uno scenario di migrazione. Ad esempio, l'origine (on-premise o nel cloud di un altro provider) può essere il sito A, che dispone della connettività di rete con un Amazon VPC su cui implementare il sito B. Dopo che il sito B è attivo e funzionante, è possibile passare al sito B. In questo approccio, il meccanismo di replica dei dati è fondamentale perché la tecnologia di archiviazione di origine potrebbe avere fattori limitanti in termini di metodo di replica che potrebbe funzionare.

  • Migrazione di un cluster di failover distribuito su VMware in locale a VMware nel cloud su AWS: VMware Cloud on AWS offre il supporto nativo per SCSI-3 Persistent Reservation. In questo modo è possibile ospitare un cluster di failover su un disco di macchina virtuale (VMDK) su VMware Cloud on AWS. Per ulteriori informazioni, consulta la pagina Migrating SQL Server FCI cluster with shared disks to VMware Cloud on AWS nella documentazione di VMware.

    Comunicazione

    A partire dal 30 aprile 2024, VMware Cloud on non AWS è più rivenduto né dai suoi partner di canale. AWS Il servizio continuerà a essere disponibile tramite Broadcom. Ti invitiamo a contattare il tuo AWS rappresentante per i dettagli.

  • Migrazione di una FCI di SQL Server utilizzando volumi Amazon EBS Multi-Attach: puoi utilizzare le prenotazioni Amazon EBS Multi-Attach e NVMe per creare istanze di cluster di failover di SQL Server (FCI) con volumi Amazon io2 EBS come storage condiviso sui cluster di failover di Windows Server. Questi volumi possono essere collegati solo a istanze che si trovano nella stessa zona di disponibilità. La distribuzione di cluster di failover di Windows Server utilizzando i io2 volumi Amazon EBS richiede i driver Windows più recenti che traducono i comandi di prenotazione SCSI in comandi di prenotazione NVMe. Per ulteriori informazioni sulla migrazione delle FCI di SQL Server locali in AWS in una singola zona di disponibilità utilizzando questo approccio, consulta il post del blog AWS How to deploy a SQL Server failover cluster with Amazon EBS Multi-Attach on Windows Server.

La fase di valutazione è fondamentale per garantire il successo della migrazione del cluster di failover ad AWS. Se dedichi del tempo alla raccolta di informazioni e all'identificazione delle potenziali sfide, puoi sviluppare un piano di migrazione completo che riduca al minimo i tempi di inattività, riduca i rischi e garantisca una transizione fluida ad AWS.

Mobilitazione

Durante la migrazione di un cluster di failover ad AWS, la fase di mobilitazione prevede la preparazione del cluster per la migrazione in AWS e successivamente il test per garantirne il corretto funzionamento. La fase di mobilitazione include i seguenti passaggi:

  1. Preparazione dell'ambiente di destinazione: in questo passaggio, vengono create le risorse AWS necessarie per ospitare il cluster di failover. Questa operazione include la configurazione di Amazon VPC, sottoreti, gruppi di sicurezza e altre risorse necessarie.

  2. Preparazione dell'ambiente di origine: in questo passaggio, si prepara il cluster di failover esistente per la migrazione. Ciò può comportare la modifica della configurazione di rete, la configurazione della replica o l'installazione del software necessario.

  3. Convalida del cluster: dopo aver preparato sia l'ambiente di origine sia quello di destinazione, è possibile eseguire un test di convalida per verificare che il cluster funzioni correttamente. A tale scopo, viene condotta una serie di test per garantire che il cluster possa eseguire correttamente il failover nell'ambiente di destinazione.

  4. Creazione di un link di replica: dopo il test di convalida, è possibile creare un link di replica tra l'ambiente di origine e quello di destinazione. Ciò garantisce che tutte le modifiche apportate all'ambiente di origine vengano replicate nell'ambiente di destinazione.

  5. Monitoraggio della replica: dopo aver stabilito il collegamento di replica, monitora il processo di replica per garantire che tutte le modifiche vengano replicate correttamente.

  6. Failover del cluster: dopo aver verificato che la replica funzioni correttamente, esegui il failover finale nell'ambiente di destinazione. Ciò comporta l'arresto dei servizi del cluster nell'ambiente di origine e il loro avvio nell'ambiente di destinazione.

  7. Verifica del failover: una volta completato il failover, esegui un test per verificare che le applicazioni e i servizi in esecuzione sul cluster funzionino correttamente nel nuovo ambiente.

Migrazione

La migrazione di un cluster di failover Microsoft può essere un processo complesso, per garantire il successo del quale occorrono una pianificazione e una implementazione accurate. Prima di apportare modifiche all'ambiente di produzione, è essenziale valutare a fondo l'ambiente esistente, identificare potenziali problemi e sviluppare un piano di migrazione completo che includa test e convalide. Durante la fase di migrazione, è importante monitorare il processo con attenzione e risolvere tempestivamente eventuali problemi o comportamenti imprevisti. La comunicazione e la collaborazione tra tutte le parti interessate, inclusi team IT, utenti aziendali e fornitori, sono fondamentali per un processo di migrazione senza intoppi.

Inoltre, è importante considerare l'impatto della migrazione su eventuali applicazioni o servizi di terze parti in esecuzione sul cluster di failover. Identifica eventuali dipendenze e testa accuratamente tali applicazioni per assicurarti che continuino a funzionare come previsto dopo la migrazione. Un altro aspetto chiave della fase di migrazione è la definizione di un piano di rollback in caso di problemi o guasti imprevisti durante il processo di migrazione. Idealmente, questo piano dovrebbe includere le fasi per annullare la migrazione e ripristinare l'ambiente originale, riducendo al minimo l'impatto sull'ambiente di produzione.

Infine, una volta completata la migrazione e aver attivato la corretta esecuzione del cluster di failover nel nuovo ambiente, è importante eseguire la convalida e i test successivi alla migrazione per confermare che tutto funzioni come previsto. Ciò include il monitoraggio delle prestazioni, la convalida delle funzionalità di failover e la garanzia del corretto funzionamento di tutte le applicazioni e i servizi.