Spegnimento imprevisto

[Linoxmandy]

A seguito di alcuni test sul circuito elettrico, che causavano brevi ma frequenti assenze di energia elettrica,  si è verificato lo spegnimento di tutte le VM di un cluster vsphere 4.1 con HA e DRS attivo.

Escludo che le VM siano state spente dagli ups, in quanto gli agent degli ups dialogano soltanto con gli host esxi, e questi utlimi sono sempre rimasti accesi.

Alla riaccensione delle VM ho notato che erano presenti i seguenti errori su entrambi i due host esxi che compongono il cluster:

Network uplink redundancy lost

Network connectivity lost

Credo che gli errori siano dovuti al fatto che gli switch (sia gli switch che gescitono il traffico privato iscsi,  che gli switch che gestiscono il traffico pubblico LAN) siano andati off-line per qualche istante.

Nei log delle VM (windows) rilevo questo evento:

The process C:\Program Files\VMware\VMware Tools\vmtoolsd.exe (GA06) has initiated the shutdown of computer GA06 on behalf of user NT AUTHORITY\SYSTEM for the following reason: Legacy API shutdown

Nei SystemLog che ho esportato dal VCenter ritrovo questo evento:

Log Name: System

  Source: USER32

  Date: 2011-11-02T20:35:57.000

  Event ID: 1074

  Task: N/A

  Level: Information

  Opcode: N/A

  Keyword: Classic

  User: S-1-5-18

  User Name: NT AUTHORITY\SYSTEM

  Computer: vc01.dominio.locale

  Description:

The process C:\Program Files\VMware\VMware Tools\vmtoolsd.exe (VC01) has initiated the shutdown of computer VC01 on behalf of user NT AUTHORITY\SYSTEM for the following reason: Legacy API shutdown

Reason Code: 0x80070000

Shutdown Type: shutdown

Comment:

Dove potrei trovare i log che mi aiutino a capire il perchè le VM sono state spente?

[Tinto1970]

a logica direi proprio che gli spegnimenti delle vm sono stati iniziati dagli host a seguito dell'input proveniente dagli ups. gli host non si sono poi spenti perche' come dici tu le interruzioni sono state abbastanza brevi.

[Linoxmandy]

Lo escludo perchè gli ups generano log per ogni operazione che effettuano, ed in questa occasione non hanno  inviato log circa il raggiungmento del run-time limit circa lo shutdown degli host.

Anche pechè gli ups mandano in shutdown gli host quando raggiungono un limite di autonomia di 8-10 minuti, ed in questi test il limite non è mai sceso sotto i 15 minuti.

Ho il sospetto che invece sia qualche politica dell'HA del vCluster, che manda in shutdown le VM... qualcosa simile a questo articolo che ho trovato:

http://www.yellow-bricks.com/2008/09/08/ha-isolation-response-shutdown-guest/

Credo che i log potranno chiarimi le idee.

Ho provato a generare i log dal Vsphere Client, ma vengono fuori una marea di log e mi ci perdo.....

[max_esprient]

Credo che il fatto sia accaduto per i seguenti motivi:

- VMware HA non ha (scusa la ripetizione!) il network di management ridondato

- VMware potrebbe essere impostato che in caso di isolamento spenga le VM

- Lo switch a cui sono collegate le schede di management (vmkernel o service console) si è spento e l'HA, ha fatto il suo dovere spegnendo le VM.

Max

[Linoxmandy]

Tutt i servizi (management, vmotion, ecc.) hanno NIC ridondate.

Verificando meglio, ho riscontrato che anche il nostro unico DNS Interno (e domain controller) [appena possibile li ridonderemo]  è andato in shutdown per una politca troppo aggressiva da parte dell'ups che lo gestisce.

Credo quindi che gli alert riscontrati sugli host:

Network uplink redundancy lost

Network connectivity lost

siano dovuti al fatto che HA e gli host non rilevavano il DNS.

Posso stabilire di non mandare in shutdown le VM anche in presenza di problemi di Network uplink redundancy lost, Network connectivity lost.?

[max_esprient]

Sono molto perplesso che l'HA ti abbia spento le VM perchè il DNS è stato spento, in ogni caso puoi impostare che in caso di isolamento le VM restino accese se esse utilizzano una rete fisica separata da quella di management.

Se cambi le impostazioni di rete/DNS ricordati di configurare gli HA agent degli Host.

Max

[Linoxmandy]

Grazie Massimiliano,

credo per questo che sia utile consultare i log...

Mi indicheresti il percorso dove poter impostare che in caso di isolamento le VM restino accese?

[max_esprient]

Vai nelle ipostazioni del Cluster HA, troverai nel wizard una voce tipo "Host isolation response" e metti "Leave Powered On"

[Linoxmandy]

Ok,

riguardo la rete fisica: nel mio caso ho un unico Vswitch, con 4 NIC fisiche per ogni host. 2 NIC sono dedicate al traffico publico delle VM, altre 2 NIC sono dedicate al management/vmotion ecc.

Tutte e 4 le NIC sono collegate nell'unico switch lan a cui sono collegati tutti gli altri servizi.

Ho verificato che il valore HOST ISOLATION RESPONSE era impostato su: SHUT DOWN

Ho cambiato il valore in LEAVE POWERD ON e ho effettuato il "reconfigure HA host" sugli host esxi.

[Linoxmandy]

Forse è più corretto dire che le VM sono andate in shutdown perchè è andato giù il link tra gli host (il link di hearthbeat) essendo andati giù gli switch?

[max_esprient]

La seconda!

[ldelloca]

Tecnicamente sono avvenute diverse cose:

- mancato contatto master-slave

- nessuna richiesta di elezione slave-> master

- l'heartbeat di HA non è riuscito a contattare l'isolation address

Se volete capirne meglio:

http://www.yellow-bricks.com/vmware-high-availability-deepdiv/

Ciao,

Luca.

--

Luca Dell'Oca

http://www.vuemuer.it

@dellock6

vExpert 2011

[Assegnare punti a una risposta utile è un modo di dire grazie]

[max_esprient]

Non per confutare uno dei migliori vExper (), ma essendo una 4.1 non c'è Master e Slave (roba della 5.0), ma primary e secondary, che funzionavano un

po' diversamente (direi peggio).

max

[ldelloca]

Nono, confutami pure, sorry non avevo letto 4.1.

Comunque il mancato contatto dell'isolation address vale sempre, di la almeno ci sarebbe lo storage heatbeat di backup.

Consiglio spassionato: a meno di non avere SLA da dover garantire e voler essere aggressivi, mettere "leave powered on". VMware stessa nel tempo non ha mai deciso se fosse meglio lasciare accesa o spegnere, tanto che con i service pack della 3.5 continuavano a cambiare sta cosa...

--

Luca Dell'Oca

http://www.vuemuer.it

@dellock6

vExpert 2011

[Assegnare punti a una risposta utile è un modo di dire grazie]

[Linoxmandy]

Avendo due soli host, entrambi sono primary, quindi si pingano a vicenda per stabilire l'hearthbeat. Giusto?

The first 5 hosts that join the VMware HA cluster are automatically selected as primary nodes. All the others are automatically selected as secondary nodes.

Considerato il punto di sopra, potrei tralasciare il discorso dell'elezione master->slave, ovvero primary->secondary. Giusto?

Riguardo l'isolation response e lo shutdown delle VM. Interessante leggere che:

Up to ESX 3.5 U2 / vCenter 2.5U2 the default isolation response when creating a new cluster was “Power off”.

As of ESX 3.5 U3 / vCenter 2.5 U3 the default isolation response is “leave powered on”.

For vSphere ESX / vCenter 4.0 this has been changed to “Shut down”. Keep this in mind when installing a new environment, you might want to change the default depending on customer requirements.

Many people prefer to use “Leave powered on” because it reduces the chances of a false positive.

Potrei decidere di utilizzare un das.isolationaddress più "stabile" oppure un das.failuredetectiontime più lungo (ad esempio, nel caso del mio evento di down degli switch, potrei impostare un detectiontime di 90 secondi, tempo utile al completo riavvio del firmware degli switch).

Ma credo che nel mio caso, avendo due soli host, la soluzione più semplice sia quella di impostare l'isolation response in “leave powered on”.

Che ne pensate?

[ldelloca]

Un cluster HA a due soli nodi è sempre "rischioso", sia per queste cose sia soprattutto per l'admission control.

Se confidi che i server siano stabili e che sia invece la rete ad essere "ballerina", allora lascia accese le VM, al massimo risulteranno fuori rete anche se funzionanti.

Io mi terrei i parametri avanzati per i giorni buoni, allungando i timeout del detection time senza essere sicuro che la rete sia stabile, rischi solo di allungare i tempi di riavvio di una VM che non va.

Ciao,
Luca.

--

Luca Dell'Oca
http://www.vuemuer.it
@dellock6
vExpert 2011

[Assegnare punti a una risposta utile è un modo di dire grazie]