Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

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.