Capitolo 7. Virtualizzazione e High Availability
Varie piattaforme di virtualizzazione sono supportate insieme al Red Hat Enterprise Linux 6 usando l'High Availability e il Resilient Storage Add-On. Sono supportati due tipi di implementazioni insieme con il Red Hat Enterprise Linux High Availability Add-on.
Ciò si riferisce a RHEL Cluster/HA in esecuzione su host bare metal utilizzabili come piattaforme di virtualizzazione. Così facendo è possibile configurare il cluster resource manager (rgmanager) per la gestione di macchine virtuali (guest), come risorse ad elevata disponibilità.
- VM come servizi/risorse ad elevata disponibilità
- Cluster guest
7.1. VM come servizi/risorse ad elevata disponibilità
Sia RHEL HA che RHEV forniscono i meccanismi utili per rendere disponibili le macchine virtuali HA (elevata disponibilità). A causa della loro funzionalità fare attenzione nella scelta del prodotto più idoneo a soddisfare le vostre esigenze. Di seguito sono riportate alcune linee guida per la scelta di RHEL HA o RHEV per HA delle VM.
Per il conteggio delle macchine virtuali e degli host fisici:
- Se un numero molto grande di VM risulta essere HA su numerosi host fisici, allora l'uso di RHEV potrebbe rappresentare una opzione migliore a causa della presenza di algoritmi più sofisticati per la gestione del posizionamento delle VM, considerando fattori come CPU, memoria e le informazioni sul carico.
- Se un numero ristretto di VM è HA su alcuni host fisici, l'uso di RHEL HA potrebbe rappresentare la soluzione migliore poichè essa implica un uso ridotto di infrastrutture supplementari. La soluzione più semplice di RHEL HA VM richiede due host fisici per un cluster con 2 nodi. Al contrario, la soluzione RHEV più semplice richiedere 4 nodi: 2 per fornire HA per il server RHEVM e 2 per fungere da host della VM.
- Non sono presenti linee guida specifiche sulla definizione di 'numerosi' host o VM. Ma ricordate che il numero massimo di host in un cluster RHEL HA è 16, e ogni cluster con 8 o più host avrà bisogno di una revisione dell'architettura da parte di Red Hat per determinare il tipo di supporto.
Utilizzo della macchina virtuale:
- Se le VM HA forniscono i servizi usati per le infrastrutture condivise, allora sarà possibile utilizzare RHEL HA o RHEV.
- Per l'HA di un insieme piccolo di servizi critici in esecuzione all'interno delle VM, sarà possibile utilizzare RHEL HA o RHEV.
- Per una infrastruttura idonea ad abilitare il provisioning rapido delle VM, utilizzare RHEV.
- RHEV VM HA è stato ideato per essere dinamico. L'aggiunta di nuove VM al 'cluster' RHEV¸ può essere eseguito facilmente ed è completamente supportato.
- RHEL VM HA non è stato ideato per essere un ambiente molto dinamico. Un cluster deve avere un numero fisso di VM, e per l'intero ciclo di vita è consigliato non aggiungere o rimuovere alcuna VM.
- Non utilizzare RHEL HA per la creazione di ambienti simili al cloud, a causa della natura statica della configurazione del cluster e per il conteggio basso di nodi fisici (16 nodi)
RHEL 5 supporta due piattaforme di virtualizzazione. Xen è supportato dalla release RHEL 5.0. KVM è stato introdotto con RHEL 5.4.
RHEL 6 supporta solo KVM come piattaforma di virtualizzazione.
RHEL 5 AP Cluster supporta sia KVM che Xen nelle macchine virtuali in esecuzione, gestite dall'infrastruttura cluster host.
RHEL 6 HA supporta KVM nelle macchine virtuali in esecuzione, gestite dall'infrastruttura cluster host.
Di seguito vengono riportati i diversi scenari attualmente supportati da Red Hat:
- RHEL 5.0+ supporta Xen insieme con RHEL AP Cluster
- RHEL 5.4 rende disponibile il supporto per le macchine virtuali KVM come risorse gestite in RHEL AP Cluster sotto forma di Anteprima di tecnologia
- RHEL 5.5+ rende disponibile un supporto completo per le macchine virtuali KVM.
- RHEL 6.0+ supporta le macchine virtuali KVM come risorse ad elevata disponibilità in RHEL 6 High Availability Add-On.
- RHEL 6.0+ non supporta le macchine virtuali Xen con RHEL 6 High Availability Add-On, poichè RHEL 6 non supporta più Xen.
Nota
Per informazioni più aggiornate sulle note speciali relative agli scenari d'impiego supportati, consultare la seguente voce nel Red Hat Knowledgebase:
Non ha importanza il tipo di macchine virtuali eseguite come risorse gestite. Qualsiasi guest supportato da Xen o KVM in RHEL, potrà essere utilizzato come guest ad elevata disponibilità. Ciò include le varianti di RHEL (RHEL3, RHEL4, RHEL5) e altre variati di Microsoft Windows. Consultare la documentazione di RHEL per l'ultimissimo elenco di sistemi operativi guest supportati con ogni hypervisor.
7.1.1. Consigli generali
- Con RHEL 5.3 e versioni meno recenti, rgmanager utilizza le interfacce Xen native per la gestione dei Xen domU's (guests). Con RHEL 5.4 questa impostazione è stata modificata in modo da utilizzare libvirt per gli hypervisor Xen e KVM, fornendo una unterfaccia omogenea tra i due tipi di hypervisor. Oltre a questa modifica con RHEL 5.4 e 5.4.z sono state rese disponibili alcune correzioni, e per questo motivo è consigliato aggiornare gli cluster host con i pacchetti di RHEL 5.5 più recenti prima di configurare i servizi gestiti di Xen.
- Per i servizi gestiti KVM è necessario eseguire un aggiornamento a RHEL 5.5 poichè questa è la prima versione di RHEL dove la funzionalità è completamente supportata.
- Controllare sempre l'ultimissima errata di RHEL prima di implementare un cluster, così facendo avrete sempre le ultimissime correzioni relative alle problematiche conosciute.
- L'uso di un insieme di diversi tipi di hypervisor non è supportato. Il cluster host deve essere basato su Xen o KVM.
- Eseguire il provisioning dell'hardware host in modo da poter accettare i guest riposizionati da altri host falliti, senza causare un overcommit della memoria o un overcommit delle CPU virtuali. In presenza di un numero molto elevato di errori tali da causare un overcommit della memoria o delle CPU virtuali, ciò potrebbe deteriorare le prestazioni causando un potenziale fallimento del cluster.
- L'uso diretto degli strumenti di xm o libvirt (virsh, virt-manager) per la gestione delle macchine virtuali (live migrate, stop. start) sotto il controllo di rgmanager, non è supportato o consigliato poichè ciò potrebbe baipassare lo stack di gestione del cluster.
- Ogni nome della VM deve essere unico su tutto il cluster, incluso le VM local-only / non-cluster. Libvirtd applica solo i nomi unici in base all'host. Se eseguite una clonazione manuale di una VM, modificarne il nome nel file di configurazione.
