Ogni tanto riesco a “evadere” dal mercato SMB per il quale lavoro, e dedicarmi a quei due-tre clienti un pò più grossi che seguo.

Settimana scorsa abbiamo ragionato di come utilizzare il sito di Disaster Recovery, distante 5 km, per poter gestire al meglio i sistemi vmware. Attualmente i loro sistemisti interni utilizzano le snapshot integrate nel sistema FalconStor per replicare tra le due SAN presenti nel sito primario e in quello di disaster recovery. In caso di failure, bisogna connettersi alle macchine ESX del sito di disaster recovery e avviare le corrispettive VMs precedentemente replicate. Questo sistema mi è sempre sembrato estremamente farraginoso, con troppi interventi manuali da gestire, e complicato; e non ho mai perso occasione per farlo notare…

Dicevo, settimana scorsa si è forse visto uno spiraglio nella “saccenza” di alcuni sistemisti interni, anche solo per concedermi il “privilegio” di esporre le mie idee. In parole povere, o utilizziamo SRM, scelta ovvia e scontata, oppure visto che tutta la rete utilizza SMLT su hardware Nortel, uno dei vantaggi è poter spostare lo stesso indirizzo IP presente su tronconi di rete diversi. Da qua l’idea di provare il Long Distance VMotion; il vantaggio su SRM ovviamente è di tipo economico, non dovendo prendere altre licenze, e di semplicità del sistema, non dovendo mettere in piedi tutta la parte programmativa e di analisi di SRM. Ho cercato quindi in giro e ho trovato un riepilogo dei requisiti necessari per fare ciò in un post di Duncan Epping. Vediamoli insieme, con in parentesi quello che abbiamo nella realtà analizzata:

• rete IP con banda minima di 622 Mbps (2 Gbps dedicati tra le due sedi)
• latenza massima 5 millisecondi (dobbiamo fare dei test approfonditi, ma da una prima verifica ci siamo, siamo sotto ai 4)
• gli ESX di partenza e arrivo devono avere una rete privata sulla stessa subnet IP per la rete di VMotion (possiamo farla via vlan)
• l’indirizzo IP della VM deve essere raggiungibile da entrambi gli ESX, dato che col vmotion l’ip continua ad essere funzionante durante tutto il processo (come detto prima, tramite SMLT siamo a posto)
• lo storage condivisio deve essere visibile da entrambi i nodi ESX (questo è già previsto adesso)

Direi che potremo quantomeno parlarne!!! Un avviso ai naviganti però: a meno che non abbiate una SAN tra le due sedi che funziona in modalità active/active, dovrete controllare bene DRS per evitare che molte VMs vengano eseguite nel sito di disaster recovery mentre i loro dischi sono nella SAN del sito primario.

Una potenziale soluzione in futuro potranno essere gli Stretched Clusters, ovvero la possibilità di suddividere i cluster in “sotto-cluster” per rispettare al meglio alcune regole di DRS/HA tra siti diversi appunto. Una specie di affinity dichiarata tra VM e sotto-cluster.