Recentemente da un cliente ho aggiornato un cluster vSphere da 5.0 a 5.1. L’aggiornamento è andato benissimo, ma ho avuto un problema con il Failover Manager di HP StoreVirtual, detto anche FOM.
La FOM di HP StoreVirtual (o LeftHand, se siete dei nostalgici del vecchio nome) è una piccola virtual machine basata su linux, il cui compito è dotare un cluster multi-nodo StoreVirtual di un voto dispari per garantire il Quorum. Viene utilizzata quando ci sono 2 o 4 sistemi storage StoreVirtual, in modo che i manager che partecipano al quorum siano sempre in numero dispari, e che quindi non si rischi una situazione di split-brain.
Nel caso di questo cliente, ci sono due storage P4300 e una FOM. Lo storage StoreVirtual è l’unico storage condiviso di tutto il cluster, e i server ESXi sono installati su memorie SD. Dato che installare la FOM direttamente all’interno dello storage StoreVirtual è un errore madornale, e potrebbe portare a serie perdite di dati (cosa succede se si spegne tutto, e la FOM è all’interno del cluster di cui dovrebbe garantire il quorum???), il primo server ESXi del cluster ha un piccolo raid locale da 70 Gb, con l’unico compito di ospitare la FOM.
In fase di aggiornamento a vSphere 5.1, ho provveduto a spegnere la FOM e a spostarla su una LUN condivisa del cluster StoreVirtual. Una scelta temporanea per il tempo necessario ad aggiornare il server 1. Ultimato l’aggiornamento (in realtà avevamo optato per una reinstallazione + riconfigurazione dei vari ESXi) ho riportato nuovamente la FOM sullo storage locale del server 1 e provveduto a riaccenderla.
Dopo l’avvio, la console di StoreVirtual mi riportava questo errore:
Tradotto, per chi non è pratico di LeftHand, la FOM si annunciava come membro del cluster cui era stata assegnata, ma gli altri due nodi del cluster (i due storage P4300) si rifiutavano di accettarla come tale. Controllando meglio nella console, si poteva iniziare a capire l’errore:
La FOM registrata nella console era mancante, mentre compariva con il nome DNS corretto (e lo stesso indirizzo IP) una seconda FOM, che non veniva però accettata dal cluster. Provando a selezionare la FOM mancante, l’errore restituito faceva immediatamente capire dove stesse il problema:
In un sistema StoreVirtual, i vari componenti vengono registrati e licenziati in base al loro MAC Address, che la console chiama “Serial number”. La FOM possedeva un MAC Address 00:0C:29:FA:A9:CF, ma come si nota dalla schermata della console, si stava adesso annunciando con l’indirizzo 00:50:56:BF:22:7D.
Almeno il problema era stato risolto: per qualche motivo il MAC address della FOM era cambiato in seguito all’aggiornamento di vSphere da 5.0 a 5.1. Cercando in giro, ho trovato questo post di Cormac Hogan, che spiega come i MAC address siano stati modificati in vSphere 5.1, e quindi quelli vecchi non siano più utilizzabili. La FOM, che utilizzava un MAC address della serie 00:0C:29, adesso ne aveva uno della serie 00:50:56.
Come primo tentativo, ho provato a verificare che effettivamente non fosse più possibile assegnare il vecchio MAC address in modo statico. Dopo averlo modificato manualmente
in effetti ogni tentativo di avvio della FOM veniva abortito e retituiva questo errore:
Leggendo i commenti al post di Cormac Hogan, ho trovato il modo di riconfigurare la FOM senza doverla cancellare e reinstallare. Ecco i vari passaggi:
1) spegnete la FOM e col comando “Remove from Inventory” deregistratela da vCenter
2) tramite shell o ssh, recatevi nella directory che contiene la virtual machine ed editate il file VMX di configurazione.
3) al suo interno, vi sono in particolare 3 righe che ci interessano:
ethernet0.addressType = “static”
uuid.bios = “56 4d a0 1b 56 3d 38 e5-54 a0 d3 cc a0 fa a9 cf”
ethernet0.address = “00:0c:29:fa:a9:cf”
Notate in particolare il valore finale du uuid.bios, sono gli stessi valori esadecimali del mac address che ho provato a impostare manualmente. Non avendo controllato il file VMX prima del tentativo di usare il vecchio MAC address in modo statico, non so se il valore fosse già così perchè era stato creato col vecchio MAC address o meno.
4) Dovete a questo punto modificare le tre righe in modo che risultino essere:
ethernet0.addressType = “generated”
uuid.bios = “56 4d a0 1b 56 3d 38 e5-54 a0 d3 cc a0 fa a9 cf”
ethernet0.generatedaddress = “00:0c:29:fa:a9:cf”
utilizzando i valori esadecimali del MAC address che desiderate ripristinare.
5) Infine, registrate nuovamente la virtual machine nell’infrastruttura vSphere. Noterete che la configurazione è cambiata:
Siamo riusciti a ripristinare il vecchio MAC address, ma facendo in modo che risulti generato automaticamente. Niente più conflitti con la classe riservata ai MAC addresses statici, e infatti il tentativo di avviare la virtual machine questa volta andava a buon fine. Dopo qualche istante infatti ci ritrovavamo la FOM nuovamente presente nel cluster, in status “Manager Normal”
Un ulteriore controllo dello stato complessivo del cluster, ci mostrava nuovamente la presenza di un numero dispari di manager, garantendo quindi la consistenza del quorum.
