Titolo contorto? Può darsi!
Fatto sta che ho aggiornato in azienda (l’ottimo) Acronis per il backup aziendale e di conseguenza avevo aggiornato su di una macchine VMware ESX 3.5 (l’unica rimasta) l’appliance per il backup.
Al primo backup (quello di Exchange server, che risiede su questo host) mi da un bell’errore, sul SOAP, dicendo che non trova lo SDK all’url dell’host e così via…
Mi sono detto…vuoi vedere che non è compatibile con questa versione??
Infatti di diverso rispetto alla vecchia versione c’erano almeno un paio di cose, che in AMS veniva riportato l’FQDN dell’host-VA, mentre nelle vecchie versioni l’IP ed inoltre nella configurazione dell’agent era presente solo la richiesta di autenticazione sull’host, cioè prima andava impostata anche la password dell’agente stesso….(chi usa Acronis mi ha capito!).
Fatto sta che leggendo nella documentazione ho scoperto che ufficialmente l’appliance per ESX NON HA MAI SUPPORTATO ufficialmente ESX 3.5 pre Upgrade 2, l’host in questione è un 3.5 senza upgrade, dato cheè una macchina standalone non ho mai avuto la necessità dell’upgrade.
Mentre è probabile, anzi sicuro, che le nuove versioni dell’appliance sfruttano le nuove API di VMware e quindi non vanno più bene, per la cronaca quindi fino alla build 11105 si lavora tranquillamente con ESX 3.5 e U1, mentre dalle successive (adesso ho la 11639 no).
Mi è capitato giorni addietro di avere un problema con un flusso primario della Wind, collegato ad una Sangoma A102DE.
Tutte le telefonate ai fissi funzionavano perfettamente, mentre verso i cellulari andava subito in hangup.
Dopo un breve controllo al debug sul primario e con la collaborazione dei loro tecnici, è uscito il problema, perchè le telefonate si presentavano con dialplan national, pertanto non venivano instradate, quindi è opportuno aggiungere
pridialplan=unknown
prilocaldialplan=unknown
in chan_dahdi.conf, ma diversamente da altri moduli, non basta riavviare solo il servizio, me è opportuno riavviare la macchina.
Inoltre un altro caso può essere quello di dover inserire, sempre nello stesso file
nationalprefix=0
internationalprefix=00
In breve, come funziona il cluster HA di vSphere?
Quando si configura un cluster HA su ESX, è consigliabile avere oltre la service console, anche una service console di backup su NIC separate e su switch separati per garantire che gli heartbeats continuino ad essere ricevuti in caso di una scheda di rete o switch vadano giu.
Se gli heatbeats non sono ricevuti per 15000 millisecondi (15 secondi), i server ESX entrano in isolation response che è, per impostazione predefinita arrestano le macchine virtuali in esecuzione in modo che possano essere riavviate su un altro host.
L’isolation response inzia quando un host ha smesso di ricevere gli heartbeats da altri nodi del cluster e l’indirizzo di isolamento non può essere pingato.
L’indirizzo di isolamento predefinito è il servizio di ESX console gateway, e la risposta di default tempo l’isolamento è di 15000 millisecondi (15 secondi).
Utilizzando la configurazione sopra descritta, con indirizzi IP nella stessa sottorete per la console di Backup Service e Service Console, entrambi gli indirizzi IP verranno risolti con lo stesso MAC per entrambe le NIC.
Questo farà sì che il nodo è segnalato come “isolato”, producendo effetti indesiderati sull’host, ad esempio l’impossibilità di accendere nuove vms sull’host e/o il non funzionamento del cluster stesso.
E ‘il comportamento di default di Red Hat Enterprise Linux che le interfacce di rete rispondano alle richieste ARP per l’indirizzo IP su qualsiasi interfaccia della macchina stessa. Un comportamento simile può essere visto quando un servizio di console è disconnesso, a causa di problemi di routing etc..
Su ESXi il problema non dovrebbe esserci, su ESX 3.5 non è risolvibile facilmente (e non è tema di questo post), mentre su ESX 4.x dato che è presente il nuovo kernel rispetto alla 3.5 è possibile farlo semplicemente collegandosi in ssh alla service console e digitare
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
mentre per rendere permanente la modifica aggiungere la seguente riga al file /etc/sysctl.conf
net.ipv4.conf.all.arp_ignore = 1
Hoi effettuato seguendo passo passo il kb di VMware, il tutto senza grossi intoppi..bhe qualcuno piccolo si!
Sicuramente il peggiore è stato questo, in pratica il server vCenter si stoppava dopo pochi secondi di esecuzione, dopo circa un paio di giorni di utilizzo.
Dopo un breve sguardo all’event viewer si capiva che il problema stava nel SQL Server, nel mio caso l’Express, “Transaction log for database VIM_VCDB is full” quindi come risolvere?
Abbastanza semplice, usate il Management Studio Express, cliccate sul database VIM_VCDB con il destro, proprietà, sotto opzioni “Recovery Model” selzionate simple (nella versione italiana credo si chiami modello di recupero -> minimo).
Questo effettuerà lo shrink del Transaction Log, pertantò il vCenter sarà riavviabile senza problemi.
VMware consiglia di lasciare a simple (o minimo) questo valore.
Come tutti saprete ESXi non ha la service console, ma di fatto è possibile ancora collegarsi da remoto tramite SSH (nonchè usare SCP per trasferire files), ovviamente non esiste nessuna possibilità di farlo tramite vClient, ma tramite una “porta di servizio”.
Niente di più semplice
1. Dalla console di ESXi premere ALT+F1 per accedere alla console
2. Digitare “unsupported” (al buio) e premere invio. A video non comparirà nulla.
3. Se avete digitato il comando correttamente, vi comparirà una console denominata “Tech Support Mode” e vi verrà richiesta la password dell’utente root
4. Editare il file /etc/inetd.conf attraverso vi
5. Cercate la linea che inizia con “#ssh” e rimuovete il # iniziale. Salvare il file con :wq
6. Eseguite ps | grep inetd e controllate il pid del processo inetd. Se ad esempio il valore dovesse essere 1979, eseguite kill -HUP 1979 per riavviare inetd e di conseguenza ssh.
Ovviamente questa opzione “non è supportata” da VMware e potete usarla anche con ESX 3.5 Update 2,3,4,5
Dato che nella futura major release ESX scomparirà in favore del solo ESXi, mi sono detto..proviamolo!
Quindi ho fatto fuori un server con il vecchio ESX 3.5 e ci ho installato ESXi 4.0, aggiornato poi alla Update 2.
Ovviamente è molto più veloce, perchè la classica installazione Linux RedHat è sostituita dalla snella BusyBox, ma apparte ciò a me interessava inserirlo nel mio cluster vSphere, niente di più facile…o quasi.
Infatti collegango ESXi insieme a degli ESX potrete avere questo errore
HA agent on <esxhostname> in cluster <clustername> in <datacenter> has an error Incompatible HA Network:
Consider using the Advanced Cluster Settings das.allowNetwork to control network usage
Questo perchè a partire dal VirtualCenter 2.5 Update 2, due opzioni avanzate sono state aggiunte per permettere un maggiore controllo sulle reti utilizzate per la comunicazione di cluster. Queste due impostazioni avanzate permettono una maggiore flessibilità nel controllo e l’utilizzo delle reti di VMware HA, che i nodi abbiano reti compatibili.
Un’opzione, che non tratteremo ora, è das.allowVmotionNetworks mentre quella che interessa adesso è das.allowNetwork[...]
In pratica la rete di gestione in ESX si chiama tipicamente Service Console, mentre in ESXi Managment Network, quindi elevando ESXi a nodo del cluster otteniamo l’errore e per toglierlo semplicemente facciamo click con il tasto destro sul cluster, Enable VMware HA, click su VMware HA e poi Advanced options.
Qui scrivete das.allowNetwork0 Service Console e das.allowedNetwork1 managmnet Network, come in figura.
I massimi valori ammissibili sono da 0 a 10.
Fatto ciò potrete tranquillamente procedere alla riconfigurazione del cluster HA.
Categories
Tag Cloud
Blog RSS
Comments RSS
Last 50 Posts
Back
Void 
Life 
Earth 
Wind 
Water 
Fire