Windows Server 2012 Shared Nothing Live Migration
Con Windows Server 2012 sono state introdotte varie novità utili soprattutto negli scenari della piccola e medio-piccola impresa dove sarebbero necessarie in certe situazioni soluzioni tipiche della medio-grande e grande impresa, ma che per motivi di budget o di complessità nell’implementazione non possono essere adottate.
Una di queste novità è sicuramente la Shared Nothing Live Migration descritta nel seguente post Shared Nothing Live Migration on Windows Server 2012. Come dice il nome consente di avere la funzionalità di Live Migration delle VM senza uno storage condiviso e senza la necessità di un cluster. In sostanza la VM risiede sullo storage locale del server Hyper-V sorgente e viene copiata via rete sullo storage locale del server Hyper-V destinazione mentre è attiva.
Dal seguente Virtual Machine Live Migration Overview:
“You can also perform a live migration of a virtual machine between two non-clustered servers running Hyper-V when you are only using local storage for the virtual machine. (This is sometimes referred to as a “shared nothing” live migration. In this case, the virtual machines storage is mirrored to the destination server over the network, and then the virtual machine is migrated, while it continues to run and provide network services.”
Quindi con Windows Server 2012 si hanno tre possibilità per avere la Live Migration delle VM:
- Usare uno storage condiviso (SAN) e configurare i nodi di virtualizzazione in un cluster, ovvero la modalità già disponibile in Windows Server 2008 R2
- Usare una share SMB 3.0 come storage condiviso e configurare i nodi in cluster o meno a seconda che sdia necessaria l’alta disponibilità
- Usare storage locali e nodi non in cluster
I requisiti della Shared Nothing Live Migration sono i seguenti:
- Nodi di virtualizzazione con WS 2012 e il ruolo Hyper-V installato
- I nodi devo avere processori dello stesso produttore (entrambi con CPU Intel o entrambi con CPU AMD)
- Appartenere allo stesso dominio Active Directory o domini che sono in trust tra loro
- Le VM devono essere configurare per usare VHD o virtual Fibre Channel disks (no physical disks, in altre parole in una Live Migration senza l’utilizzo del cluster i dischi Pass-Through non sono supportati, ma va detto che i dischi Pass-Through venivano principalmente utilizzati per workload che richiedevano uno spazio di archiviazione superiore ai 2 TB imposto dai vhd, ma dal momento che con l’introduzione deli vhdx in WS 2012 si può gestire fino a 64 TB gli scenari che richiedono l’uso di dischi Pass-Through sono pochi e soprattutto sono comunque scenari in cui si ha il budged per una SAN e di conseguenza non verrebbe utilizzata la Shared Nothing Live Migration)
- I nodi devono essere connessi via rete ad almeno 1 GB e l’interfaccia di rete utilizzata per la comunicazione deve avere abilitate le opzioni Client for Microsoft Networks e File and Printer Sharing for Microsoft Networks
- E’ consigliabile usare una rete dedicata per traffico relativo alla live migration
- Ogni nodo di virtualizzazione deve aver definito un virtual switch su cui sono attestate le VM, per garantire la continuità delle comunicazioni di rete delle VM dopo una Live Migration senza necessità di una riconfigurazione.
Per la configurazione si veda Configure and Use Live Migration on Non-clustered Virtual Machines.
In particolare si noti che è possibile configurare la Live Migration con due opzioni per quando riguarda il protocollo di autenticazione, ovvero tramite Kerberos o tramite CredSSP. In ogni caso i due nodi devono comunque essere membri dello stesso dominio o di domini in trust.
La differenza sta principalmente nel fatto che CredSSP è più semplice da configurare, ma non consente di gestire la Live Migration remotamente occorre quindi operare localmente, tramite Remote Desktop o tramite una sessione PowerShell.
Utilizzando Kerberos occorre configurare la constrained delegation, ma si ha la possibilità di utilizzare i remote management tools per gestire la Live Migration.
Dal seguente Configure and Use Live Migration on Non-clustered Virtual Machines:
“Do you plan to sign on to each server to perform the given task (either through a local console session, a Remote Desktop session, or a remote Windows PowerShell session), or do you want perform the tasks with remote management tools? The answer determines whether you should select Kerberos or Credential Security Support Provider (CredSSP) to authenticate live migration traffic. To manage the tasks with remote management tools, configure constrained delegation and select Kerberos as the authentication protocol. Otherwise, you must sign on to the source computer to perform a live migration, and CredSSP is used to authenticate the live migration.”
“The requirement of signing in to the source computer has implications that might not be obvious. For example, if you sign in to TestServer01 to move a virtual machine to TestServer02, and then want to move the virtual machine back to TestServer01, the operation will fail unless you sign in to TestServer02 before you try to move the virtual machine back to TestServer01.
If the connection between the source and destination computers cannot be authenticated, an error occurs and the following message is displayed:
Virtual machine migration operation failed at migration Source.
Failed to establish a connection with host<computer name>: No credentials are available in the security package (0x8009030E).”
Di seguito uno schema grafico che riassume i concetti dell’utilizzo di CredSSP, ovvero semplicità di configurazione, ma gestione locale:
Mentre in questo schema grafico che riassume i concetti dell’utilizzo di Kerberos, configurazione della constrained delegation in AD che garantisce la possibilità della gestione remota:
Scenari di utilizzo e considerazioni
Ovviamente la Shared Nothing Live Migration è una funzionalità che permette la mobilità delle VM da un nodo di virtualizzazione ad un altro, ma dal momento che i nodi non sono in cluster non può essere una soluzione di alta disponibilità.
Questa funzionalità può essere interessante in una piccola infrastruttura dove si devono gestire VM che erogano dei servizi di rete come un piccolo DBMS per il DB gestionale, il DC aggiuntivo, il server di posta, il server RDS che essendo rivolti a pochi utenti non hanno grandi requisiti di carico elaborativo e di spazio occupato. In uno scenario come questo può essere pensabile investire in due server entry level che su cui suddividere le VM, ma che all’occorrenza possono gestire temporaneamente tutte le VM. La Shared Nothing Live Migration può quindi essere il mezzo con cui tenere allineate le VM tramite una rete dedicata e con cui spostare manualmente le VM su uno solo dei due server quando l’altro deve essere manutenuto.
Perfomance
Rob Waggoner, nel post post Shared Nothing Live Migration on Windows Server 2012, riporta un suo test eseguito mediante due laptop non recenti connessi con un cavo di rete e i risultati sono che Live Migration di una VM di 16 GB impiega circa 8 minuti e 40 secondi:
“That means the hardware is showing some age, but still runs Windows Server 2012 and Hyper-V, just not as fast as some of the modern day hardware. Second, the VM I was Live Migrating was about 16 GB in size and took 8 minutes, 40 seconds to Live Migrate from one host to another. About 2 GB per minute? As I said, I’m running on older hardware, I expect more current hardware to reduce this migration time significantly, but the reality is that Shared Nothing Live Migration still works. I’ve even seen VMs Live Migrated from one laptop to another with just a single network cable.”
Si noti che con lo stesso hardware la Live Migration basata su cluster impiega solo 11 secondi, ma questo non deve sorprendere perché in questo caso non occorre copiare la VM.
“The same VM and hardware that took over 8 minutes to Live Migrate over the network took only 11 seconds to Migrate in a cluster.”
Un’altra cosa da tenere presente negli scenari a cui è rivolta questa funzionalità è che il canale sfruttabile verso lo storage dalle VM è quello dello storage locale, quindi tenendo conto che ultimamente anche i server entry level hanno controller SATA III si sta parlando di 6 GB/S.
Per approfondimenti si vedano: