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 verso i per Cloud AWS 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 locale, il sistema operativo gestisce l'assegnazione degli indirizzi IP, ma un provider di servizi cloud (AWS) gestisce l'assegnazione degli indirizzi IP nel cloud. 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 con un'attenta pianificazione e implementazione può essere eseguita 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 è una fase fondamentale del processo di migrazione di un cluster di failover verso. AWS Durante questa fase, si raccolgono informazioni sull'ambiente corrente, si determina la fattibilità della migrazione verso e si identificano eventuali AWS sfide o rischi potenziali. Durante la fase di valutazione, ti consigliamo di seguire questi passaggi:

• Valuta la preparazione delle tue applicazioni: stabilisci se è possibile migrare le applicazioni AWS senza modifiche o se devono essere aggiornate o riscritte per sfruttare i servizi nativi del cloud.

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

• Valuta i requisiti di migrazione dei dati: determina in che modo vengono migrati i dati 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 dei costi: stima il costo della migrazione a AWS, incluso il costo delle EC2 istanze Amazon, dello storage, del trasferimento dei dati e qualsiasi altro Servizi AWS requisito richiesto.

• Crea un piano di migrazione: in base alle 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 verso. AWS

Valutazione dell'ambiente attuale

Valuta l'ambiente attuale, comprese le configurazioni hardware e software, per determinare a cosa migrare. AWS Identifica eventuali dipendenze tra applicazioni, server e database.

Scelta della strategia di migrazione

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

• Migrazione tradizionale del cluster di failover: se stai configurando manualmente un cluster di failover Microsoft da zero, puoi seguire i passaggi nella parte 1 di Launch Microsoft SQL Server on Amazon EC2 Windows instance (). YouTube 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 Amazon 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 for Windows File Server. Per ulteriori informazioni, consulta il post Semplifica le distribuzioni ad alta disponibilità di Microsoft SQL Server utilizzando Amazon FSx for Windows File Server nel blog sullo AWS storage. Il passaggio successivo consiste nel portare i nodi nel cloud. Ciò può essere ottenuto utilizzando. AWS Application Migration Service Per ulteriori informazioni, consulta il post Migrazione dei cluster di Microsoft Windows CloudEndure verso AWS l'utilizzo della migrazione nel blog 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 stretch: un cluster stretch potrebbe essere la soluzione ideale se disponi di un'applicazione aziendale critica da migrare sul cloud 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 in VMware locale su Cloud on AWS— VMware VMware Cloud on offre il supporto nativo per SCSI-3 Persistent Reservation. AWS In questo modo è possibile ospitare un cluster di failover su un disco di macchina virtuale (VMDK) su Cloud on. VMware AWS Per ulteriori informazioni, consulta Migrazione del cluster FCI di SQL Server con dischi condivisi su Cloud on nella documentazione. VMware AWS VMware

  Comunicazione

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

• Migrazione di un FCI di SQL Server utilizzando il volume Amazon EBS Multi-Attach: puoi usare Amazon EBS Multi-Attach e NVMe le prenotazioni per creare istanze di cluster di failover di SQL Server () FCIs con io2 volumi Amazon EBS come storage condiviso nei 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 della FCI di SQL Server locale AWS in una singola zona di disponibilità utilizzando questo approccio, consulta il post del AWS blog How to deploy a SQL Server failover cluster with Amazon EBS Multi-Attach on Windows Server.

La fase di valutazione è fondamentale per garantire una migrazione di successo del cluster di failover verso. 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 senza intoppi verso. AWS

Mobilitazione

Durante la migrazione di un cluster di failover verso AWS, la fase di mobilitazione prevede la preparazione del cluster per la migrazione AWS e il test dello stesso per assicurarne il corretto funzionamento. La fase di mobilitazione include i seguenti passaggi:

1. Preparazione dell'ambiente di destinazione: in questo passaggio vengono create AWS le risorse necessarie per ospitare il cluster di failover. Ciò comporta la configurazione di un 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.