Hyper-V.
Panoramica della soluzione VMware vSphere
Suggerisci modifiche
PDF
VCenter Server Appliance (VCSA) è un potente sistema di gestione centralizzato e un singolo pannello di controllo per vSphere che consente agli amministratori di utilizzare in modo efficace i cluster ESXi. Agevola le funzioni chiave come provisioning delle macchine virtuali, funzionamento di vMotion, alta disponibilità (ha), Distributed Resource Scheduler (DRS), Tanzu Kubernetes Grid e altro ancora. Si tratta di un componente essenziale negli ambienti cloud VMware e deve essere progettato tenendo presente la disponibilità del servizio.
Alta disponibilità vSphere
La tecnologia cluster di VMware raggruppa i server ESXi in pool di risorse condivise per le macchine virtuali e offre vSphere High Availability (ha). VSphere ha offre alta disponibilità e facile da utilizzare per le applicazioni eseguite su macchine virtuali. Quando la funzionalità ha è abilitata sul cluster, ogni server ESXi mantiene la comunicazione con altri host in modo che, se un host ESXi non risponde o si isola, il cluster di ha può negoziare il recovery delle macchine virtuali in esecuzione sull'host ESXi tra gli host sopravvissuti nel cluster. In caso di errore del sistema operativo guest, vSphere ha riavvia la macchina virtuale interessata sullo stesso server fisico. VSphere ha consente di ridurre i downtime pianificati, prevenire i downtime non pianificati e eseguire un rapido ripristino in caso di interruzioni.
Cluster vSphere ha in grado di ripristinare le VM dal server guasto.
È importante comprendere che VMware vSphere non conosce NetApp MetroCluster o SnapMirror Active Sync e vede tutti gli host ESXi nel cluster vSphere come host idonei per le operazioni del cluster ha in base alle configurazioni di affinità dei gruppi VM e host.
Rilevamento errori host
Non appena viene creato il cluster ha, tutti gli host nel cluster partecipano alle elezioni e uno degli host diventa un master. Ogni slave esegue heartbeat di rete al master, e il master a sua volta esegue heartbeat di rete su tutti gli host slave. L'host master di un cluster vSphere ha è responsabile del rilevamento del guasto degli host slave.
A seconda del tipo di errore rilevato, potrebbe essere necessario eseguire il failover delle macchine virtuali in esecuzione sugli host.
In un cluster vSphere ha, vengono rilevati tre tipi di errore dell'host:
-
Errore - Un host smette di funzionare.
-
Isolamento - Un host diventa isolato dalla rete.
-
Partizione - Un host perde la connettività di rete con l'host master.
L'host master monitora gli host slave nel cluster. Questa comunicazione viene fatta attraverso lo scambio di heartbeat di rete ogni secondo. Quando l'host master smette di ricevere questi heartbeat da un host slave, controlla la liveness dell'host prima di dichiarare che l'host non è riuscito. Il controllo liveness che l'ospite principale effettua è di determinare se l'ospite secondario sta scambiando i heartbeat con uno dei datastore. Inoltre, l'host master verifica se l'host risponde ai ping ICMP inviati ai propri indirizzi IP di gestione per rilevare se è semplicemente isolato dal suo nodo master o completamente isolato dalla rete. Per farlo, eseguire il ping del gateway predefinito. È possibile specificare manualmente uno o più indirizzi di isolamento per migliorare l'affidabilità della convalida dell'isolamento.
Best practice
NetApp consiglia di specificare un minimo di due indirizzi di isolamento aggiuntivi e che ciascuno di questi indirizzi sia locale al sito. Ciò migliorerà l'affidabilità della convalida dell'isolamento.
Risposta di isolamento dell'host
Risposta di isolamento è un'impostazione in vSphere ha che determina l'azione attivata sulle macchine virtuali quando un host in un cluster vSphere ha perde le connessioni di rete di gestione ma continua a essere eseguito. Sono disponibili tre opzioni per questa impostazione: "Disabilitato", "Arresta e riavvia le macchine virtuali" e "Spegni e riavvia le macchine virtuali".
Lo "spegnimento" è migliore dello "spegnimento", che non svuota le modifiche più recenti al disco o esegue il commit delle transazioni. Se le macchine virtuali non si sono arrestate entro 300 secondi, vengono spente. Per modificare il tempo di attesa, utilizzare l'opzione avanzata das.isolationshutdowntimeout.
Prima che ha avvii la risposta di isolamento, verifica prima se l'agente master ha vSphere è proprietario del datastore che contiene i file di configurazione della VM. In caso contrario, l'host non attiverà la risposta di isolamento, poiché non vi è alcun master per riavviare le VM. L'host controllerà periodicamente lo stato del datastore per determinare se viene richiesto da un agente vSphere ha che detiene il ruolo master.
Best practice
NetApp consiglia di impostare la risposta di isolamento dell'host su Disabilitato.
Una condizione split-brain può verificarsi se un host viene isolato o partizionato dall'host master vSphere ha e il master non è in grado di comunicare tramite datastore heartbeat o tramite ping. Il master dichiara l'host isolato inattivo e riavvia le macchine virtuali su altri host nel cluster. Esiste ora una condizione split-brain perché esistono due istanze della macchina virtuale in esecuzione, una sola delle quali è in grado di leggere o scrivere i dischi virtuali. Le condizioni split-brain possono ora essere evitate configurando VMCP (VM Component Protection).
Protezione dei componenti VM (VMCP)
Uno dei miglioramenti delle funzionalità di vSphere 6, relativi all'ha, è VMCP. VMCP fornisce una protezione avanzata da APD (All Path Down) e PDL (Permanent Device Loss) per lo storage a blocchi (FC, iSCSI, FCoE) e a file (NFS).
Perdita permanente del dispositivo (PDL)
PDL è una condizione che si verifica quando un dispositivo di memorizzazione si guasta in modo permanente o viene rimosso amministrativamente e non deve essere restituito. L'array di storage NetApp invia un codice di rilevamento SCSI a ESXi dichiarando che il dispositivo è perso in modo permanente. Nella sezione Condizioni di guasto e Risposta VM di vSphere ha, è possibile configurare la risposta che deve essere dopo il rilevamento di una condizione PDL.
Best practice
NetApp consiglia di impostare "Risposta per datastore con PDL" su "Spegni e riavvia VM". Quando viene rilevata questa condizione, una VM viene riavviata istantaneamente su un host integro all'interno del cluster vSphere ha.
Tutti i percorsi verso il basso (APD)
APD è una condizione che si verifica quando un dispositivo di archiviazione diventa inaccessibile all'host e non sono disponibili percorsi all'array. ESXi considera questo un problema temporaneo con il dispositivo e si aspetta che diventi nuovamente disponibile.
Quando viene rilevata una condizione APD, viene avviato un timer. Dopo 140 secondi, la condizione APD viene dichiarata ufficialmente e il dispositivo viene contrassegnato come timeout APD. Una volta trascorsi i 140 secondi, ha inizia il conteggio dei minuti specificati nell'APD Delay for VM failover. Una volta trascorso il tempo specificato, ha riavvia le macchine virtuali interessate. È possibile configurare VMCP in modo che risponda in modo diverso, se lo si desidera (Disattivato, Eventi problema o Spegni e riavvia le macchine virtuali).
Best practice
NetApp consiglia di configurare "Risposta per datastore con APD" su "Spegni e riavvia le VM (conservative)".
Conservative si riferisce alla probabilità che ha sia in grado di riavviare le VM. Quando è impostata su Conservative, ha riavvia la VM interessata dall'APD solo se sa che un altro host può riavviarla. In caso di problemi aggressivi, ha tenterà di riavviare la macchina virtuale anche se non conosce lo stato degli altri host. Ciò può comportare il mancato riavvio delle VM se non vi è alcun host con accesso al datastore su cui si trova.
Se lo stato APD viene risolto e l'accesso allo storage viene ripristinato prima del termine del timeout, l'ha non riavvia inutilmente la macchina virtuale a meno che non sia stata configurata esplicitamente. Se si desidera una risposta anche quando l'ambiente è stato ripristinato dalla condizione APD, è necessario configurare la risposta per il ripristino APD dopo il timeout APD in modo da ripristinare le VM.
Best practice
NetApp consiglia di configurare la risposta per il ripristino APD dopo il timeout APD su Disabilitato.
Implementazione VMware DRS per NetApp MetroCluster
VMware DRS è una funzionalità che aggrega le risorse host in un cluster e viene utilizzata principalmente per il bilanciamento del carico all'interno di un cluster in un'infrastruttura virtuale. VMware DRS calcola principalmente le risorse di CPU e memoria per eseguire il bilanciamento del carico in un cluster. Poiché vSphere non è consapevole del clustering allungato, considera tutti gli host in entrambi i siti durante il bilanciamento del carico. Per evitare il traffico tra siti, NetApp consiglia di configurare le regole di affinità DRS per gestire una separazione logica delle VM. In questo modo si garantisce che, a meno che non si verifichi un errore completo del sito, ha e DRS utilizzino solo host locali.
Se si crea una regola di affinità DRS per il cluster, è possibile specificare in che modo vSphere applica tale regola durante il failover di una macchina virtuale.
Esistono due tipi di regole che è possibile specificare il comportamento di failover di vSphere ha:
-
Le regole di anti-affinità delle macchine virtuali costringono le macchine virtuali specificate a rimanere separate durante le azioni di failover.
-
Le regole di affinità degli host VM collocano macchine virtuali specifiche su un host specifico o su un membro di un gruppo definito di host durante le azioni di failover.
Utilizzando le regole di affinità degli host delle macchine virtuali in VMware DRS, si può avere una separazione logica tra il sito A e il sito B in modo che la macchina virtuale venga eseguita sull'host nello stesso sito dell'array configurato come controller di lettura/scrittura principale per un determinato datastore. Inoltre, le regole di affinità degli host delle macchine virtuali consentono alle macchine virtuali di rimanere locali rispetto allo storage, il che a sua volta determina la connessione della macchina virtuale in caso di errori di rete tra i siti.
Di seguito è riportato un esempio di gruppi di host VM e regole di affinità.
Best practice
NetApp consiglia di implementare le regole "should" invece di quelle "must", in quanto vengono violate da vSphere ha in caso di errore. L'utilizzo di regole "must" può potenzialmente causare interruzioni del servizio.
La disponibilità dei servizi dovrebbe sempre prevalere sulle prestazioni. Nello scenario in cui si verifica un guasto di un data center completo, le regole "must" devono scegliere gli host dal gruppo di affinità degli host VM e, quando il data center non è disponibile, le macchine virtuali non verranno riavviate.
Implementazione di VMware Storage DRS con NetApp MetroCluster
La funzione VMware Storage DRS consente l'aggregazione di datastore in una singola unità e bilancia i dischi della macchina virtuale quando vengono superate le soglie di controllo i/o di storage.
Il controllo i/o dello storage è abilitato per impostazione predefinita sui cluster DRS abilitati per Storage DRS. Il controllo i/o dello storage consente a un amministratore di controllare la quantità di i/o dello storage allocata alle macchine virtuali nei periodi di congestione dell'i/o e di conseguenza le macchine virtuali più importanti possono preferire le macchine virtuali meno importanti per l'allocazione delle risorse i/O.
Storage DRS utilizza Storage vMotion per migrare le macchine virtuali in datastore diversi all'interno di un cluster di datastore. In un ambiente NetApp MetroCluster, la migrazione di una macchina virtuale deve essere controllata all'interno dei datastore di quel sito. Ad esempio, la macchina virtuale A, in esecuzione su un host nel sito A, dovrebbe idealmente migrare all'interno dei datastore della SVM nel sito A. In caso contrario, la macchina virtuale continuerà a funzionare ma con prestazioni ridotte, poiché la lettura/scrittura del disco virtuale avverrà dal sito B attraverso collegamenti tra siti.
Best practice
NetApp consiglia di creare cluster di datastore in relazione all'affinità con i siti storage. In altre parole, i datastore con affinità con i siti per il sito A non devono essere mescolati con i cluster di datastore con datastore con affinità con i siti per il sito B.
Ogni volta che viene eseguito il provisioning o la migrazione di una macchina virtuale mediante Storage vMotion, NetApp consiglia di aggiornare manualmente tutte le regole VMware DRS specifiche di tali macchine virtuali. In questo modo, si verificherà l'affinità della macchina virtuale a livello di sito per host e datastore, riducendo così l'overhead di rete e storage.