Hyper-V Live Migration & Cluster Shared Volumes Speaker : Ivan Salvadè MCT, MCITP, MCTS Technical Trainer & Consultant Web site : www.ivansalvade.com

Agenda Come funziona la Live Migration Pre-requisiti per la Live Migration CSV (Cluster Shared Volumes)

Live Migration – Inizio della migrazione Facciamo una Live Migration di questa VM verso un altro server fisico Client che accede alla VM SAN Si inizia una Live Migration per spostare una VM da un host all’altro VHD

Live Migration – Copia della memoria : Copia Full Il contenuto della RAM è copiato verso il nuovo server VM pre-creata SAN La prima copia iniziale riguarda tutta la RAM VHD

Live Migration – Copia della memoria : le pagine “sporche” Il client continua ad accedere alla VM Le pagine di RAM nel frattempo sono ulteriormente modificate (“sporche”) SAN Il client continua ad accedere alla VM, causando la modifica delle pagine di RAM VHD

Live Migration – Copia della memoria : gli incrementali Nuova copia delle modifiche Piccolo insieme di modifiche Hyper-V tiene traccia dei dati cambiati, e ri-copia le modifiche con passate incrementali Le susseguenti passate incrementali sono sempre più veloci in quanto le modifiche sono sempre minori SAN VHD

Live Migration – La transazione finale Il “Partition State” viene copiato La VM è messa in pausa SAN Operazione molto veloce : avviene entro il “TCP connection timeout” VHD

Live Migration – Dopo la transizione : fase di clean-up Client redirezionato al nuovo host Sono rilasciate broadcast ARP per aggiornare i dispositivi di routing Dato che lo stato della sessione è mantenuto, non sono necessarie riconnessioni La vecchia VM è cancellata dopo che la migrazione è stata eseguita con successo SAN VHD

Ragioni per configurare la Live Migration Course 10159A Module 5: Configuring Server Virtualization by Using Hyper-V Ragioni per configurare la Live Migration Manutenzione hardware dell’host fisico First, ask students why would they use Live Migration, and then discuss the answer and supplement it with the additional information from the topic. Question: Why would you use Live Migration? Answer: Reasons for using Live Migration can be different, but will probably include proactive actions such as servicing the hardware, servicing the host operating system, and moving the VM to a more appropriate host. Provide reasons for using Live Migration. Remind students that Live Migration is not a high availability solution on its own, because it requires the source host to be operational to start it. With the help of the slide, list the following reasons for configuring Live Migration: Servicing hardware Updating the host operating system Moving a VM to an appropriate host You can remind students that in many environments, planned and short downtime of VMs outside working hours would be acceptable and Quick Migration could be used in such situations. Live Migration minimizes this downtime, so VM migration can be performed during working hours. However, most organizations still rather perform VM migration outside working hours. For example, When a new update is released, which requires rebooting the host, the update must be applied to Windows Server 2008 R2 in the parent partition, and Windows Server 2008 R2 requires rebooting. You can use Live Migration to move all VMs to another physical host. For performing Live Migration, you must apply the update to the parent partition, reboot the physical server, and use Live Migration to migrate VMs back. You can perform Live Migration during working hours and users will not notice it. Aggiornamento del sistema operativo dell’host fisico Spostamento della macchina virtuale su un host più appropriato N.B. : la Live Migration richiede che l’host sorgente sia in linea. Se avviene un disastro improvviso sull’host sorgente, i servizi di Cluster garantiscono la ripresa della macchina Virtuale su un altro nodo rimasto operativo, ma con del downtime 9

Live Migration : prerequisiti Windows Server 2008 R2 Enterprise o Datacenter Edition, o Hyper-V Server 2008 R2 Microsoft Failover Clustering su tutti i nodi fisici Più reti dedicate alle comunicazioni del cluster Tutti gli host fisici sulla stessa subnet TCP/IP Accesso allo storage condiviso per tutti gli host fisici N.B. : CSV (Cluster Shared Volume) non è un obbligo, ma se non viene utilizzato siamo costretti a posizionare solo 1 macchina virtuale su ogni LUN dello storage condiviso

Il Failover Clustering nel passato 11/22/2018 2:57 AM Il Failover Clustering nel passato Failover Clustering tipicamente ha sempre implementato un modello di storage “shared nothing” Piazzare i VHD sullo stesso volume richiede che le VM siano in esecuzione sullo stesso nodo di cluster Solo un nodo alla volta accede al LUN SAN SAN

Complessità nella gestione della SAN… Flessibilità Il LUN è la più piccola unità di failover Scalabilità Complessità con le lettere di drive Capacità Utilizzo di spazio su SAN non ottimale Gestibilità MPIO e Masking di un grosso numero di LUN

E allora…. “Cluster Shared Volumes"!!  Soluzione di “File System ad accesso distribuito” per Hyper-V Accesso concorrente allo storage da ogni nodo Le VM non conoscono il loro host Le VM non sono più legate allo storage Le VM possono condividere un disco CSV per ridurre i LUN Le VM rimangono online durante la live migration

Overview di Cluster Shared Volumes 11/22/2018 2:57 AM Overview di Cluster Shared Volumes Accesso concorrente al file system SAN Volume singolo VHD VHD VHD Disk5

Compatibilità di CSV CSV è totalmente compatibile con ciò che è già installato per supportare Windows Server 2008! Nessun requisito hardware speciale Nessuna limitazione di struttura di directory Nessun agente speciale o installazioni addizionali Nessun file system proprietario Usa il tradizionale NTFS (con dei “Junction Point”) Migrazione semplice a CSV

Ridondanza sulla connettività I/O 11/22/2018 2:57 AM Ridondanza sulla connettività I/O I/O Redirezionato via rete La VM in esecuzione su Nodo 2 non è influenzata Coordinator Node SAN Interruzione della connettività alla SAN Le VM possono sempre essere “Live Migrated” ad un altro nodo senza downtime VHD

Ridondanza dei nodi SAN Rottura del nodo 11/22/2018 2:57 AM Ridondanza dei nodi Rottura del nodo La VM in esecuzione su Nodo 2 non è influenzata Breve accodamento delle operazioni di I/O mentre si cambia l’ownership del volume SAN Il volume è rilocato su un nodo attivo VHD

Ridondanza della rete SAN 11/22/2018 2:57 AM Ridondanza della rete Gli aggiornamenti dei metadati sono eseguiti su una rete ridondata La VM in esecuzione su Nodo 2 non è influenzata Volume montato su Nodo 1 Interruzione della connettività di rete SAN Le connessioni TCP ridondate rendono innocue le interruzioni dei percorsi di rete VHD

Pianificazione della densità delle VM sui dischi CSV 11/22/2018 2:57 AM Pianificazione della densità delle VM sui dischi CSV Nessun limite al numero di VM su un volume CSV Considerazioni sulle performance dello storage array Tanti server che eseguono I/O su un unico LUN Appoggiarsi alle best practices del vendor dello storage Quanti IOPS può gestire il vostro storage array ?