Un’idea per un nuovo tool

0 Flares Twitter 0 Facebook 0 LinkedIn 0 Email -- 0 Flares ×

Ciao a tutti,

la scorsa settimana di rientro mi ha visto letteralmente sovraccarico di nuovi lavori: abbiamo una nuova piattaforma aziendale di hosting di database filemaker accedibili via client 2X, un concorrente di citrix col quale ci siamo trovati benissimo già in passato, e stiamo mettendo in piedi l’infrastruttura definitiva.

Inoltre, sembrerà incredibile ma il lavoro che più mi ha assorbito è stata la catalogazione e scrematura delle foto fatte in vacanza: 1200 scatti da 13 Mb cadauno hanno quasi affondato il mio fido mac, che però ha retto egregiamente il colpo. Se vi va, potete vedere il risultato finale qua.

Passando a vmware, sto lentamente leggendo tutti i vari articoli che si sono accumulati nel mio feed reader durante la mia assenza, e non sono pochi. VMWorld è ovviamente l’argomento principale. Ho però avuto tempo di fare un’interessante colloquio con un nuovo partner col quale abbiamo iniziato a collaborare, il quale mi ha sottoposto subito un’interessante argomento. Con l’uscita di ESXi, sempre più aziende di piccole e medie dimensioni hanno deciso di utilizzare questa piattaforma per consolidare vecchi server oppure semplicemente per ottimizzare le risorse hardware. Capita però spesso che questi server vengano utilizzati con solamente lo storage locale disponibile. Questo di per sè non è un problema, a patto di avere un buon piano di backup delle virtual machines.

Cosa succede se ESXi si blocca e non si riesce a farlo ripartire? E se non si hanno dei backup delle varie VM? Avevamo parlato mesi fa del VMDK Recovery Tool, ma l’argomento in questo caso presuppone un ESXi non più funzionante. Sto quindi studiando una soluzione a questo problema, incentrato sul driver open source per vmfs. Vi aggiornerò nei prossimi giorni su quello che scoprirò.

9 thoughts on “Un’idea per un nuovo tool

  1. Ciao Luke e ben tornato. Mi sono trovato a studiare la stessa cosa qualche tempo fa. Un soluzione – non credo molto performante tuttavia, dovrei fare dei test – potrebbe essere l’utilizzo di macchine (anche virtuali) che sono delle vere e proprie SAN software che utilizzano SCSI initiator tipo Openfiler or Starwind. Dubito sulle performance per ambiente produttivo, ma rimane cmq una cosa figa vedere sul vCenter i datastore che sono vm che ci girano sopra 😀

    • Il problema permane. Se perdi ESX il filesystem vmfs locale non è più recuperabile e serve un tool che permetta di aprirlo e leggerlo, sulla falsariga dei live cd linux di recovery.

  2. Anche se utilizzi una macchina fisica con SAN software? Scenario: 3 DL380, 2 per le VM e 1 con Openfiler per i datastore delle VM. Che dici?

    • Sì, se hai una san esterna e la puoi ricollegare a un nuovo esx ti salvi. Ma se hai uno storage locale? Al cliente non posso dire “eh dovevi metterti una san esterna” 🙂

  3. Beh, direi che(ora ci penso sù che la cosa mi intrippa)al momento di fare la lista per la spesa si poteva evidenziare il problema. Se i soldi non ci sono pazienza e una volta reso nota questa possibilità, basta. Non è detto che le cose si possano sempre risolvere solo al livello macchina 😉 e a posteriori…

  4. Per esempio se fossero macchine con scsi array come nei DL380, si potrebbe risolvere con una configurazione pendente più sulla robustezza che sulla quantità disco effettiva, configurando l’array con il RAID giusto. Da noi per il D.R abbiamo scelto una configurazione RAID 1, poichè già i dischi non sono veloci come quelli della SAN del Blade, se poi ci montavamo il RAID 5 non si arrivava più. Tuttavia abbiamo perso quasi la metà dello spazio che avremmo avuto in RAID 5, considerando inoltre che dopo la formattazione vmfs + raid i dischi da 146 all’incirca valevano 140 GB

    • Mia opinione, condivisa da VMWare: scordati raid 5 per metterci vmfs! L’unica strada percorribile ” E’ ” il raid 10. Punto.
      Si può discutere al massimo su quanti spindle mettere per ogni stripe, e questo è il reale parametro dove si vedono le differenze di performance.

      tornando al topic: questi sono clienti nuovi, che si sono installati ESXi in casa, e chiamano a posteriori. Io intanto il cliente lo prendo, gli salvo la situazione, poi di tempo per progettare meglio l’architettura ne abbiamo 🙂

  5. Concorco Luke. Mi sono sbagliato, anche noi sul D.R. era abbiamo un 1+0…

Comments are closed.