È necessario abilitare VMware HA Admission Control per i piccoli cluster (2/3-host)?

Prendi il seguente scenario comune … Un cluster vSphere di base che esegue due o tre host, storage condiviso e un set di computer virtuali sotto la licenza Essentials Plus o superiore.

Dovrebbe essere abilitato il controllo di ammissione HA su una così piccola configuration? Ha senso?

  • VMWare ESXi 5 - Array RAID 5 estese - non è in grado di accedere a datastore
  • Come eseguire il backup di macchine virtuali su un host ESXi autonomo?
  • La ridimensionamento dei volumi utilizzati come file di dati VMWare NFS causa problemi Linux VM
  • Quanta memory richiede ESXi per se stessa?
  • VMWare VCenter Server 4.1 e Oracle
  • VMWare ha distribuito l'interruttore, VM da host diversi non può ping l'altro
    • Se sì, quali sono i parametri appropriati?
    • Se no, allora perché è abilitato per impostazione predefinita su tante configurazioni vSphere? (supponendo che la maggior parte delle installazioni di vSphere siano più piccole)

    Questo cluster di due host è stato configurato con una politica di controllo di accesso che "tollera" un host, quindi l'avviso di configuration . immettere qui la descrizione dell'immagine

    immettere qui la descrizione dell'immagine

    Edit:

    Mi appoggio anche verso NO … Niente di peggio di get questo

    Not enough resources to failover this virtual machine. vSphere HA will retry when resources become available. warning 2/25/2014 4:57:19 PM MSSQL 

    One Solution collect form web for “È necessario abilitare VMware HA Admission Control per i piccoli cluster (2/3-host)?”

    Di solito, no; probabilmente non sono in esecuzione ambienti che vedranno beneficio da esso. Ma dipende dalle circostanze.

    Il controllo di ammissione agisce come una sorta di prova antideflagrante per HA, per garantire che tutte le VM di un host sceso potranno effettivamente essere accese. Ma questo non è un rischio per tutti nella grande maggioranza degli ambienti – tutti gli host devono avviare una data VM è abbastanza RAM per il sovraccarico di memory di tutti i VM in esecuzione totale (non ha bisogno di CPU gratuita e non fa ' t bisogno di qualsiasi RAM fisica gratuita, che tutti possono essere in swap) .. tranne quando il VM ha una prenotazione.

    Il trucco qui è nei calcoli della dimensione slot. Vedi qui per maggiori informazioni che probabilmente avete a che fare con questo argomento.

    La maggior parte degli ambienti ha molti VM senza alcuna prenotazione e forse una manciata piccola con riserva di qualche tipo. Quelle VM con riserve determinano la dimensione della slot, in modo da poter facilmente trovarti con un cluster all'uso di risorse del 20% rifiutando di alimentare più VM.

    Un ambiente senza riserve avrà quasi mai il controllo di ammissione; ti permetterà felicemente di metterti in una situazione in cui metà della memory VM è seduta in file di scambio, perché non è una violazione di una prenotazione, quindi non compromette la capacità di avviare i VM.

    La circostanza in cui il controllo di ammissione di HA aiuterà quando è disponibile un sacco di risorse riservate, potenzialmente al punto in cui se si perde un host, i VM potrebbero non riavviare perché le VM in esecuzione dispongono di tutte le risorse riservate. In tal caso, un criterio di controllo di ammissione adeguatamente aggressivo (probabilmente sintonizzato manualmente con das.slotCpuInMHz e das.slotMemInMB ) può essere utile per assicurarsi che tutti i VM verranno avviati correttamente in un evento HA.

    • Se no, allora perché lo trovo triggersto su tante configurazioni di vSphere?

    Poiché è triggersto per impostazione predefinita sulla creazione di cluster quando HA è abilitata.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.