7.2. Cluster guest
Questo si riferisce a RHEL Cluster/HA in esecuzione nei guest virtualizzati su una varietà di piattaforme virtualizzate. In questo caso RHEL Clustering/HA viene utilizzato principalmente per l'esecuzione delle applicazioni all'interno dei guest ad elevata disponibilità. Questo scenario è simile all'impiego tradizionale di RHEL Clustering/HA negli host bare-metal. La differenza è che il Clustering viene eseguito all'interno dei guest.
Di seguito viene riportato un elenco di piattaforme di virtualizzazione e il livello di supporto attualmente disponibile per l'esecuzione dei cluster guest utilizzando RHEL Cluster/HA. Nell'elenco i guest di RHEL 6 racchiudono sia High Availability (core clustering) che il Resilient Storage Add-Ons (GFS2, clvmd e cmirror).
- Gli host Xen RHEL 5.3+ supportano i cluster guest in esecuzione, dove i sistemi operativi guest hanno una versione RHEL 5.3 o più recente.
- I cluster guest Xen possono utilizzare fence_xvm o fence_scsi per il fencing del guest.
- Per utilizzare fence_xvm/fence_xvmd è necessario eseguire un cluster host per il supporto di fence_xvmd, e fence_xvm deve essere utilizzato come un guest fencing agent su tutti i guest clusterizzati.
- Lo storage condiviso può essere reso disponibile tramite i dispositivi a blocchi condivisi Xen o iSCSI, supportati da uno storage a blocchi dell'host o da un file backed storage (immagini raw).
- Gli host KVM di RHEL 5.5+ non supportano i cluster guest in esecuzione.
- Gli host KVM di RHEL 6.1+ supportano i cluster guest in esecuzione, dove i sistemi operativi guest presentano una versione RHEL 6.1+ o RHEL 5.6+. I guest RHEL 4 non sono supportati.
- È permesso usare un mix di nodi del cluster bare metal e nodi virtualizzati.
- I cluster guest RHEL 5.6+ possono utilizzare fence_xvm o fence_scsi per il fencing del guest.
- I cluster guest RHEL 6.1+ possono utilizzare fence_xvm (nel pacchetto
fence-virt) o fence_scsi per il fencing del guest. - Gli host KVM di RHEL 6.1+ devono utilizzare fence_virtd se il cluster guest utilizza fence_virt o fence_xvm come fence agent. Se il cluster guest utilizza fence_scsi, allora non sarà necessario utilizzare fence_virtd sugli host.
- fence_virtd può operare in tre modi:
- In modalità standalone dove la mappatura host su guest ha una codifica fissa, e la migrazione live dei guest non è consentita
- Uso del servizio Openais Checkpoint per controllare le migrazioni live dei guest clusterizzati. Per questa operazione eseguire il cluster host.
- Utilizzo di Qpid Management Framework (QMF) reso disponibile dal pacchetto libvirt-qpid. Uso di QMF per controllare la migrazione dei guest senza la presenza di un cluster host completo.
- Lo storage condiviso può essere reso disponibile tramite i dispositivi a blocchi condivisi KVM o iSCSI, supportati da uno storage a blocchi dell'host o da un file backed storage (immagini raw).
- Red Hat Enterprise Virtualization Management (RHEV-M) versioni 2.2+ e 3.0 attualmente supportano guest clusterizzati RHEL 6.1+ e RHEL 5.6+.
- I cluster guest devono essere omogenei (tutti guest RHEL 5.6+ o tutti guest RHEL 6.1+ ).
- È permesso usare un mix di nodi del cluster bare metal e nodi virtualizzati.
- Il fencing viene reso disponibili da fence_scsi in RHEV-M 2.2+ e da fence_scsi e fence_rhevm in RHEV-M 3.0, ed è supportato usando fence_scsi come di seguito descritto:
- L'uso di fence_scsi con lo storage iSCSI è limitato ai server iSCSI che supportano SCSI 3 Persistent Reservation con il comando preempt-and-abort. Non tutti i server iSCSI supportano questa funzionalità. Consultare il rivenditore dello storage per controllare se il server è conforme al supporto SCSI 3 Persistent Reservation. Da notare che il server iSCSI disponibile con Red Hat Enterprise Linux, attualmente non supporta SCSI 3 Persistent Reservation e per questo motivo non è idoneo all'uso con fence_scsi.
- VMware vSphere 4.1, VMware vCenter 4.1, VMware ESX e ESXi 4.1 supportano i cluster guest in esecuzione, dove i sistemi operativi del guest sono RHEL 5.7+ o RHEL 6.2+. Anche la versione 5.0 di VMware vSphere, vCenter, ESX e ESXi è supportata; tuttavia, a causa di uno schema WDSL non completo fornito nella release iniziale di Vmware vSphere 5.0, l'utilità fence_vmware_soap non funziona con l'installazione predefinita. Consultare il Red Hat Knowledgebase https://access.redhat.com/knowledge/ per le procedure aggiornate per correggere questo problema.
- I cluster guest devono essere omogenei (tutti guest RHEL 5.7+ o tutti guest RHEL 6.1+ ).
- È permesso usare un mix di nodi del cluster bare metal e nodi virtualizzati.
- L'agent fence_vmware_soap ha bisogno di VMware perl API di terze parti. Questo pacchetto software deve essere scaricato dal sito web di VMware e installato sui guest clusterizzati RHEL.
- Alternativamente fence_scsi può essere usato per fornire il fencing come di seguito riportato.
- Lo storage condiviso può essere reso disponibile tramite i dispositivi a blocchi condivisi raw iSCSI o VMware.
- L'uso dei cluster guest VMware ESX è supportato tramite l'uso di fence_vmware_so_ap o fence_scsi.
- Attualmente non è supportato l'uso dei cluster guest Hyper-V.
7.2.1. Utilizzo storage condiviso iSCSI e fence_scsi
- In tutti gli ambienti di virtualizzazione sopra riportati lo storage iSCSI e fence_scsi possono essere utilizzati al posto dello storage nativo condiviso e dei dispositivi di fencing nativi.
- fence_scsi può essere usato per fornire il fencing I/O per lo storage condiviso disponibile attraverso iSCSI, se il target iSCSI supporta correttamente SCSI 3 persistent reservation e i comandi abort e preempt. Controllare con il rivenditore dello storage per determinare se la soluzione iSCSI desiderata è in grado di supportare le funzionalità sopra indicate.
- Il software del server iSCSI disponibile con RHEL non supporta SCSI 3 persistent reservation, per questo motivo non è possibile un suo utilizzo con fence_scsi. Al contrario, è possibile una sua implementazione come soluzione di archiviazione condivisa insieme ad altri dispositivi di fencing come fence_vmware o fence_rhevm.
- Se utilizzate fence_scsi su tutti i guest allara non sarà necessario utilizzare un cluster host (nei casi in cui viene utilizzato RHEL 5 Xen/KVM e RHEL 6 KVM Host)
- Utilizzando fence_scsi come fence agent, tutto lo storage condiviso deve essere composto da iSCSI. Non è permesso utilizzare un mix tra storage condiviso nativo e iSCSI.
