Consiglio per configurare un Server Storage in ESXi

[TowerPillar]

Buongiorno a tutti,
mi scuso in anticipo per il mio livello principiante, ma ho bisogno di un vostro consiglio;

Ho un microserver in casa con ESXi installato e alcune VM il tutto su 2 dischi in raid1...
Avrei bisogno di utilizzare la stessa macchina anche come server storage e a disposizione ho altri 4 dischi e un secondo controller HW.

Volevo sapere date le vostre conoscenze ed esperienze, qual'era il modo giusto, migliore o più sicuro per ottenere il tutto in ESXi.
Faccio un esempio:
dato il volume (raid5) che si verrà a creare, è cosa migliore creare una VM unica, che risieda interamente sul raid5 e che contenga tutto lo storage, o è meglio una VM col disco virtuale di sistema sul primo raid e una seconda unità virtuale (per lo storage), sul raid5???

E' sicuro poi, data la mole di dati, racchiuderli tutti in un volume virtuale???

O è meglio ad esempio creare una VM sul primo raid che gestisca in maniera diretta ed esclusiva (direct I/O) il controller e tutto il contenuto?

...o magari ho detto una marea di cavolate e non si fà in nessuno dei precedenti modi?!?!?

Spero che qualcuno mi indichi la strada giusta e che la cosa non sia così banale.
Grazie in anticipo

[zeMMeMMe]

Questo mi turba
"
Ho un microserver in casa con ESXi installato e alcune VM il tutto su 2 dischi in raid1", cioè hai aggiunto un controller PCIe per avere il RAID1?
Perchè i microserver HP (NL36, NL40) non dispongono affatto di un controller RAID hardware compatibile con ESXi.

Per il resto:
RAID-5? Nonononononono
DirectIO? Nononononono (in questo caso)

Ti serve un PDC? sì/no
Vuoi andare per forza di Windows? sì/no
Sei pigro? gui/riga di comando

Personalmente se no,no metterei zfsguru con due dischi virtuali (su due datastore) in mirror zfs.
Sì lo so, non è molto sviluppato ormai, ma è 1000 volte più veloce di FreeNAS che ha una gui davvero pessima.

Ancora peggio (sempre come gui) c'è Nexentastor, che però è stabile e funziona bene anche virtualizzato

[TowerPillar]

Allora...
intanto grazie per la risposta, il server si, è un HP (microserver Gen8) oltre al controller su Mobo (raid1) ne ho uno aggiuntivo (areca ARC1212) che controlla le 4 baie originali. Entrambi i controller sono perfettamente riconosciuti da ESXi.

inizio a risponderti e a chiedere...
Raid 5 e DirectIO... ok... ma Perchè no!?!? :( e che dovrei fare raid 10?

- PDC: No in casa non credo serva..
- Windows? non obbligatoriamente (ho provato per dire anche xPEnology con directIO sul controller)
- Pigro... di certo meglio la GUI, per la riga di comando occorre anche saper che scrivere, no!?

intanto mi informo su cosa sia e come funzioni il mirror zfs, zfsguru e nexentastor... e poi ti chiedo, ma non c'è pericolo che i file che compongono gli HDD virtuali si danneggino e/o corrompano???

[zeMMeMMe]

Allora...
intanto grazie per la risposta, il server si, è un HP (microserver Gen8) oltre al controller su Mobo (raid1) ne ho uno aggiuntivo (areca ARC1212) che controlla le 4 baie originali. Entrambi i controller sono perfettamente riconosciuti da ESXi.Non nessun gen8, per quelli più vecchi (NL40) il controller RAID1 "finto" non viene minimamente visto da ESXi (in modalità RAID intendo).

inizio a risponderti e a chiedere...
Raid 5 e DirectIO... ok... ma Perchè no!?!? :( e che dovrei fare raid 10?No, devi abbandonare vecchi sistemi
- PDC: No in casa non credo serva..E' importante perchè sennò ci voleva BSD e non Nexentastor
- Pigro... di certo meglio la GUI, per la riga di comando occorre anche saper che scrivere, no!?Eh diciamo proprio di sì

intanto mi informo su cosa sia e come funzioni il mirror zfs, zfsguru e nexentastor... e poi ti chiedo, ma non c'è pericolo che i file che compongono gli HDD virtuali si danneggino e/o corrompano???
Dipende cosa intendi, i .vmdk dentro vmfs?
Certo che sì, come tutto.
Proprio per questo ti consiglio un filesystem (zfs) che può darti la certezza (ripeto: la certezza) che i tuoi dati non si siano corrotti in nessuna parte, fino all'ultimo bit, mediante la funzione di scrub.

Riguardo all'avere più copie, per il rischio di guasto fisico, puoi usare la funzione mirror (RAID1) integrata in zfs, che non richiede nulla (anzi, meno controller hardware usi meglio è, normalmente li si configura in passthrough o alla peggio JBOD, ci sono un sacco di firmware specifici per "sraidizzarli").

In sostanza puoi avere
disco virtuale1 => datastore1 => disco fisico 1
disco virtuale2 => datastore2 => disco fisico 2
e direttamente da zfs fare il RAID1.

L'unico dubbio è la CPU davvero poco potente che utilizzi, queste configurazioni le monto con Xeon a 8 core e >=128GB di RAM, quindi ti tocca provare.

Ci sono parecchie possibilità, riguardo a zfs, essenzialmente suddivise in "sistemi operativi" e "distribuzioni con GUI".
E poi tra le due grandi famiglie "BSD" e "Solaris".

In altri termini puoi installarti il tuo sistema operativo, e poi gestire "a mano" le condivisioni (samba per BSD, CIFS per Solaris), ma da quanto capisco non è il caso.

Puoi mettere delle "distribuzioni" (cioè con interfaccia GUI web), tra le quali le 3 che ti consiglio sono
- zfsguru (in pratica su un freebsd standard c'è un'interfaccina davvero molto veloce e gradevole, unico problema usa samba3 e non samba4)
- nexentastor. Una "distribuzione" basata su solaris, con una sua GUI abbastanza lenta (molto lenta), ma funziona bene anche virtualizzato
- freenas. freebsd+interfaccia utente pessima, lenta e difficile da capire, e non certificata per l'uso virtualizzato (ma funziona comunque). ha il grosso pregio di una comunità di forummisti molto evoluta. per il resto a me non piace tanto, è incredibile come anche hardware potente venga messo in ginocchi da GUI veramente "inchiodate"

poi ce ne sono tante altro, distribuzioni sempre di tipo solaris ma con interfacce più spartane (sconsiglio), oppure basate su Linux, ma lì perdi zfs che per quanto mi riguarda oggi è IL file system per lo storage

[TowerPillar]

Un secondo, e una cosa alla volta!
partiamo dal raid...

Ti assicuro che entrambi i controller vengono rilevati da ESXi tant'è vero che dal sito HP puoi scaricare direttamente la ISO con il pieno supporto al server.

io ora come ora, nel server ho 6 HDD:
2 da 750Gb in raid1 collegati al controller HP del server (datastore1 700Gb - ESXi)
4 da 4Tb in Raid5 collegati ad un controller aggiuntivo (datastore2 12Tb)

per iniziare non ho capito proprio bene il motivo del raid5 del perchè è sconsigliato.

Grazie nuovamente per il supporto.

[zeMMeMMe]

Un secondo, e una cosa alla volta!
partiamo dal raid...

Ti assicuro che entrambi i controller vengono rilevati da ESXi tant'è vero che dal sito HP puoi scaricare direttamente la ISO con il pieno supporto al server...Certo che ci credo, come sopra precisato NON ho quel modello di microserver, ma quelli più vecchi (NL40).
per iniziare non ho capito proprio bene il motivo del raid5 del perchè è sconsigliato.Dal punto di vista teorico per il write hole, poi per il carico CPU del tutto inutile, e per il "dramma" del rebuild.
Infatti il momento più rischioso è nel momento in cui si guasta un disco e lo si sostituisce: quando parte la "ricostruzione" è frequentissimo che il carico molto gravoso sugli altri dischi... li faccia morire.

Dal punto di vista pratico perchè il recovery dei problemi (e problemi ne capitano molto spesso) è di sovente difficile e/o impossibile.

Quindi: RAID5? No se non assolutamente indispensabile.
In tutti gli altri casi? No, grazie

[TowerPillar]

E ok, anche perchè per creare il raid5 mi sembra ci abbia impiegato circa 56 ore. Come altre configurazioni però ho solo 0, 1, 10, 3, 5, 6, Single Disk or JBOD... Che tipo di raid dovrei mettere?

Poi mi interessa molto la cosa del file system in ZFS in ESXi, ora cerco di reperire informazioni.

Per quanto riguarda la configurazione hardware, come CPU c'è uno Xeon E3-1270v2 e 16Gb di DDR3 1333.

[zeMMeMMe]

E ok, anche perchè per creare il raid5 mi sembra ci abbia impiegato circa 56 ore. Come altre configurazioni però ho solo 0, 1, 10, 3, 5, 6, Single Disk or JBOD... Che tipo di raid dovrei mettere?Single disk o jbod

Per quanto riguarda la configurazione hardware, come CPU c'è uno Xeon E3-1270v2 e 16Gb di DDR3 1333.
Allora ti chiedo scusa perchè non avevo capito niente.
Mi ha tratto in inganno la lettura di "microserver", pensavo fosse questo
http://n40l.wikia.com/wiki/HP_MicroServer_N40L_Wiki che monta una CPU AMD della fascia atom.

Con quell'hardware invece non avrai problemi particolari per carichi normali.

Se vuoi iniziare con zfs parti da qui
http://zfsguru.com/download

e qui
https://nexenta.com/products/downloads/nexentastor-community-edition-download

(la seconda ha un limite di 18terabyte di spazio per la versione gratuita, penso siano più che sufficienti per te)

[TowerPillar]

Tranquillo in realtà è proprio la versione nuova (e fisicamente più piccola) di quello che hai postato... http://product-images.www8-hp.com/digmedialib/prodimg/lowres/c03760124.png con un pò di modifiche.

Tornando a noi, se ho capito bene devo togliere il raid5 e importare tutti e 4 i dischi singolarmente come 4 datastore. Poi metto un disco virtuale detro ogni datastore e faccio il raid "software" da macchina virtuale?

[zeMMeMMe]

Tranquillo in realtà è proprio la versione nuova (e fisicamente più piccola) di quello che hai postato... http://product-images.www8-hp.com/digmedialib/prodimg/lowres/c03760124.png con un pò di modifiche.

Tornando a noi, se ho capito bene devo togliere il raid5 e importare tutti e 4 i dischi singolarmente come 4 datastore. Poi metto un disco virtuale detro ogni datastore e faccio il raid "software" da macchina virtuale?

si io farei e faccio così

[nanotek]

Leggendo il post mi sorgono alcuni dubbi:
Il microserver gen 8, così come i predecessori, ha solo 4 baie per i dischi.
Dove hai infilato gli altri dischi ?

Zfs richiede 1Gb di ram per ogni Tb di dati nel datastore. Fai i conti della ram impiegata e di quanta te ne avanza, di conseguenza puoi calcolare il tuo massimo datastore.
12 TB richiedono 12 Gb di Ram. Su 16 Gb che hai in dotazione sei sicuro di usarne solo 4 per hypervisor e altre macchine virtuali ?
Le ram sono ECC ?

[zeMMeMMe]

Zfs richiede 1Gb di ram per ogni Tb di dati nel datastore.Preciso che quella è la richiesta (alla grossa) per la deduplicazione.
Funziona tranquillamente con 2-4-8GB.
L'elemento-chiave è l'uso efficiente della cache, cui viene destinata praticamente tutta la memoria libera.

La deduplicazione non è un granchè utile, se non in casi particolari, e può comunque essere attivata selettivamente su dataset (non su pool interi)


Mem: 2208K Active, 474M Inact, 60G Wired, 80K Cache, 102M Buf, 1877M Free
ARC: 57G Total, 48G MFU, 8598M MRU, 162K Anon, 295M Header, 734M Other
Swap: 4096M Total, 4096M Free
In questo esempio, preso or ora da un server freebsd virtualizzato, vedi l'occupazione di memoria modesta del sistema.

Riguardo alle memorie ECC, che dovrebbe avere e che sono in generale cosa buona e giusta, non sono necessarie per zfs (nonostante quanto affermino sul forum freebsd), proprio per il mantenimento costante degli hash di tutte le strutture.
Ovviamente è inutile ribadire che è meglio ECC.
Anzi in certi casi (vedi server Dell) è possibile utilizzare addirittura una sorta di "raid-1" per le RAM, proprio per ridurre i rischi di errori di questo tipo.
Francamente mi è capitato di farlo in produzione solo una volta

[nanotek]

In questo esempio, preso or ora da un server freebsd virtualizzato, vedi l'occupazione di memoria modesta del sistema.

Dipende anche cosa sta facendo quel server... se in quel momento non c'è nessuno che carica/compie operazioni sui file la memoria è tutta per la cache.

Facendo qualche prova, con poca ram 2 Gb su 8 Tb (2x4) il sistema aveva prestazioni veramente scarse mentre si caricavano dati massicciamente (i dati dell'archivio precedente, circa 5 Tb).

Non sapevo che si potesse attivare selettivamente la deduplicazione su alcuni dataset.

Visto che sei molto informato aggiungo una domanda: Senza deduplicazione, secondo te, bisogna comunque proteggere il server con un ups ?
Con deduplicazione attiva è indispensabile perchè può richiedere qualche instante (anche secondi) prima che il file venga salvato su disco.. ma senza deduplicazione ?

[zeMMeMMe]

Dipende anche cosa sta facendo quel server... se in quel momento non c'è nessuno che carica/compie operazioni sui file la memoria è tutta per la cache.Bhè diciamo che è "abbastanza" utilizzato :p
Il punto è che lasciato "libero" utilizza come cache (ARC) praticamente tutta la RAM (normalmente i controller anche più "intelligenti" hanno a bordo 1GB di RAM, in questo caso ce n'è 50 volte di più).
Facendo qualche prova, con poca ram 2 Gb su 8 Tb (2x4) il sistema aveva prestazioni veramente scarse mentre si caricavano dati massicciamente (i dati dell'archivio precedente, circa 5 Tb). ??? Cosa intendi per "scarse" ???
Non sapevo che si potesse attivare selettivamente la deduplicazione su alcuni dataset.Sì può, si può... così come si può attivare la compressione, il controllo hash ed addirittura la memorizzazione di più copie (in pratica gli stessi dati su parti diverse del disco)
Visto che sei molto informato aggiungo una domanda: Senza deduplicazione, secondo te, bisogna comunque proteggere il server con un ups ?
Con deduplicazione attiva è indispensabile perchè può richiedere qualche instante (anche secondi) prima che il file venga salvato su disco.. ma senza deduplicazione ???? Secondi ???
Non mi è mai capitato.
Per ordine
1) la deduplicazione non serve praticamente a nulla (oggi), con i supporti di massa di dimensione molto elevata. Serve in certi casi, ad esempio quelli in cui si mantengono molte copie degli stessi dati (server di sviluppo, dove ci sono 10000 cartelle diverse con le 10000 versioni dei sorgenti, che sono essenzialmente identici)
2) non mi risulta che richieda secondi, nel senso che banalmente si riduce la velocità di copia e bon. La deduplicazione è a livello di blocco, e non di file (per zfs).
3) l'UPS è sempre cosa buona e giusta. Tuttavia per zfs, col suo metodo COW, NON esistono chkdsk o fsck o simili.
In altri termini il sistema è SEMPRE (a meno di guasti fisici) in uno stato coerente.
Puoi benissimo staccare il cavo di alimentazione mentre stai scrivendo a tutto spiano: si riavvia senza fare una piega, senza fare scansioni del disco etc (che spesso sono molto lunghe e di dubbi risultati)
4) puoi vedere in ogni momento lo stato di integrità dei dati con lo scrub.
Anzi è prassi normale pianificarlo con crontab ogni TOT e farsi spedire per email i risultati (nexentastor lo fa da GUI)
5) non hai più la manfrina dei virus crypto locker e simili
6) puoi vedere da Windows i file nelle "versioni precedenti" (nexentastor lo fa da solo, per BSD bisogna sistemare smb.conf ma nulla di che)

In generale zfs è PIU' LENTO di un filesystem più arcaico (il migliore da questo punto di vista è FAT32).
Se lo scopo è fare dei benchmark è tempo perso, conviene andare di ext2 o FAT32.

La differenza è che con l'hardware odierno, superpotente e tipicamente usato al 2% nei server, e per il 98% in idle, si riesce a sfruttare non dico tutte le capacità di elaborazione, ma una frazione decisamente superiore.

E le funzioni di snapshot e scrub, e resilvering, e raidz, per quanto mi riguarda (e per chiunque si occupi di storage di dati importanti) sono indispensabili.

Ci sono anche degli aspetti migliorabili, soprattutto nel meccanismo di zfs send che non è bufferizzato e senza possibilità di scegliere lo snapshot da spedire.

Su una macchina moderna di fascia "consumer" tranquillamente satura la banda gigabit, sia in "fisico" che in "virtuale", il che significa che fin quando non si ha una infrastruttura da 10Gb è veloce quanto Linux o Windows.

D'altronde se hai macchine a 10Gb quasi certamente hai dati importanti, e quindi... userai zfs lo stesso ;)

[nanotek]

5) non hai più la manfrina dei virus crypto locker e simili
Questa non l'ho capita..

Cosa intendi per "scarse" ???
La prova l'avevo fatta in ufficio: hp microserver gen 7 N40L, 2 gb di ram, 4 hdd 2Tb wd red.
La prova era per vedere se zfs era più performante di un raid mdadm (2 coppie raid 1). Con mdadm riesce a caricare i dati tramite cartella condivisa samba a 80 Mbyte/s al secondo.. con un raid zfs eravamo poco sotto ai 45 Mbyte/s. In lettura invece le velocità erano praticamente uguali, arrivano quasi a saturare la gigabit.
La deduplicazione era attiva. SO Centos 7, samba configurato così come è dopo l'installazione.
Alla fine non mi è parso conveniente su piccoli datastore.. nas per piccoli uffici etc.

Due aspetti che quando ho approcciato zfs per qualche test ho trovato critici:
Aumentare il volume del datastore è impegnativo quasi quanto lo è con mdadm e la ricostruzione del raidZ è indicato da tutti come operazione gravosa sui dischi, tanto quanto lo è la ricostruzione di un raid5. Con alcuni vantaggi per zfs dato che ricostruisce solo i dati.

[zeMMeMMe]

Questa non l'ho capita..Metti snapshot ogni 5 minuti e passa la paura. In sostanza puoi tornare indietro a come erano i file 5 minuti fa, 10 minuti... 15... 1 ora... 3 ore... 2 giorni... 1 settimana... magari 3 mesi fa...
E puoi "browsare" direttamente dalle sottocartelle snapshot dentro .zfs (se abiliti la proprietà), o da tasto destro=>versioni precedenti di Windows.
La prova l'avevo fatta in ufficio: hp microserver gen 7 N40L, 2 gb di ram, 4 hdd 2Tb wd red.
La prova era per vedere se zfs era più performante di un raid mdadm (2 coppie raid 1). Con mdadm riesce a caricare i dati tramite cartella condivisa samba a 80 Mbyte/s al secondo.. con un raid zfs eravamo poco sotto ai 45 Mbyte/s. In lettura invece le velocità erano praticamente uguali, arrivano quasi a saturare la gigabit.
La deduplicazione era attiva. SO Centos 7, samba configurato così come è dopo l'installazione.
Alla fine non mi è parso conveniente su piccoli datastore.. nas per piccoli uffici etc.E' evidente che con la deduplicazione e una CPU poco potente, e poca RAM, ti sei messo nella situazione peggiore.
Se disattivi la deduplicazione, e magari pure la compressione, le prestazioni sono identiche a Linux anche con una configurazione così leggerina (intendo per saturazione gigabit)

Due aspetti che quando ho approcciato zfs per qualche test ho trovato critici:
Aumentare il volume del datastore è impegnativo quasi quanto lo è con mdadmA dir la verità è banale
e la ricostruzione del raidZ è indicato da tutti come operazione gravosa sui dischi, tanto quanto lo è la ricostruzione di un raid5. Con alcuni vantaggi per zfs dato che ricostruisce solo i dati.Qualsiasi operazione che implichi la lettura dell'intero disco è ontologicamente gravosa.

"tutti" spesso (senza offesa) significa "utenti non molto formati"

Per quanto mi riguarda non lo uso praticamente mai (raidz), a favore del semplice ed assai performante mirror, con dischi da 2TB (SSD) e 6TB (magnetici)

Ho una macchina virtuale FreeBSD che gira proprio su uno di quei serverini NL40, virtualizzato, con 8GB di RAM e 4x2TB di dischi Western Digital RE.
Lo uso per fare le replice zfs dei server di produzione con una scheda di rete Intel 10Gb e sono ragionevolmente soddisfatto.

ps non confrontiamo mdadm, e LVM, con zfs.
E' come confrontare vetro e diamanti.
Basta questo (quando si parla di raid >1)
Which brings us to the coolest thing about RAID-Z: self-healing data. In addition to handling whole-disk failure, RAID-Z can also detect and correct silent data corruption. Whenever you read a RAID-Z block, ZFS compares it against its checksum. If the data disks didn't return the right answer, ZFS reads the parity and then does combinatorial reconstruction to figure out which disk returned bad data. It then repairs the damaged disk and returns good data to the application. ZFS also reports the incident through Solaris FMA so that the system administrator knows that one of the disks is silently failing.

[nanotek]

Metti snapshot ogni 5 minuti e passa la paura.
Adesso ho capito.

A dir la verità è banale
La procedura che ho trovato scritta su alcune guide (non l'ho provata) diceva, semplificando, di rimpiazzare un disco alla volta con uno di capacità maggiore, rimpiazzarlo nel pool e lasciare che zfs ricostruisse i dati.. se hai 4 dischi pieni da rimpiazzare può prendere un sacco di tempo.
A meno di qualche comando in più è la stessa procedura che richiede un raid mdadm.

[zeMMeMMe]

Adesso ho capito.


La procedura che ho trovato scritta su alcune guide (non l'ho provata) diceva, semplificando, di rimpiazzare un disco alla volta con uno di capacità maggiore, rimpiazzarlo nel pool e lasciare che zfs ricostruisse i dati.. se hai 4 dischi pieni da rimpiazzare può prendere un sacco di tempo.
A meno di qualche comando in più è la stessa procedura che richiede un raid mdadm.Scusami, e quale "magica" procedura non prevede la copia dei dati su un supporto più grande ?
Se rifletti bene vedrai che c'è poco da fare.
Il resilvering di raidz si differenzia per 2 elementi basiliari: da un lato ti dà la CERTEZZA che i dati ricostruiti siano identici a quello di partenza (cosa che mdadm non dà), e poi che nel caso di fail multipli (entro certi limiti) i dati riscostruiti sono di nuovo con CERTEZZA corretti.

Usando GUI (tipo zfsguru) non c'è molto più da fare di un paio di click

[nanotek]

Scusami, e quale "magica" procedura non prevede la copia dei dati su un supporto più grande ?
Se rifletti bene vedrai che c'è poco da fare.
Al pari di una ricostruzione di un raid sia esso gestito da controller dedicato che da mdadm.
E' banale ma fa' perdere un sacco di tempo.

Raidz non lo usi mai e consigli il mirroring e su questo mi trovi daccordo ma:
fail multipli (entro certi limiti)
Se il datastore è piccolo i fail multipli portano comunque alla perdita dei dati. Es. fail multiplo in coppie in mirroring.
Usare tre dischi in mirroring su un set di 4 non è efficiente.
Quindi è un vantaggio ma non per chi deve fare un datastore con 4 dischi in un microserver.

Per quanto riguarda il discorso snapshot volevo farti una domanda:
Esiste un comando per ripristinare una selezione di file alla loro ultima versione contenuta nello snapshot (quindi ultima modifica, perchè se non c'è modifica non viene fatto)?
Te lo chiedo perchè tempo fa' sono intervenuto in una azienda dove un un cryptolocker aveva corrotto circa 5 Gb di dati però in diversi giorni (10 giorni).
Il problema non è stato recuperare i dati, c'era il backup di tutto, ma andare a spulciare ogni backup giornaliero per capire quale era l'ultima versione del file buona (distinguibile perchè il cryptolocker cambiava le estensioni in .encrypted). Non si poteva ripristinare di colpo uno o l'altro backup perchè i file erano stati corrotti in giorni diversi.

[zeMMeMMe]

Al pari di una ricostruzione di un raid sia esso gestito da controller dedicato che da mdadm.
E' banale ma fa' perdere un sacco di tempo.E' inevitabile
Raidz non lo usi mai e consigli il mirroring e su questo mi trovi daccordo ma...Nel microserver si mettono facilmente almeno 5 hard disk, usando una porta SATA "vuota" sulla scheda madre
Per quanto riguarda il discorso snapshot volevo farti una domanda:
Esiste un comando per ripristinare una selezione di file alla loro ultima versione contenuta nello snapshot (quindi ultima modifica, perchè se non c'è modifica non viene fatto)?
Te lo chiedo perchè tempo fa' sono intervenuto in una azienda dove un un cryptolocker aveva corrotto circa 5 Gb di dati però in diversi giorni (10 giorni).
Il problema non è stato recuperare i dati, c'era il backup di tutto, ma andare a spulciare ogni backup giornaliero per capire quale era l'ultima versione del file buona (distinguibile perchè il cryptolocker cambiava le estensioni in .encrypted). Non si poteva ripristinare di colpo uno o l'altro backup perchè i file erano stati corrotti in giorni diversi.
Non mi è chiarissima la domanda, se interpreto bene basta guardare dentro .zfs, da lì puoi fare banalmente copia-incolla.
Puoi anche cercare con normali programmi tutti i file con l'estensione che vuoi (quindi non .encrypted).
http://oi63.tinypic.com/3308ttv.jpg
Anzi bisogna porre particolare attenzione ad escludere tale cartella dai backup, per evitare di avere una crescita spropositata.

[nanotek]

Puoi anche cercare con normali programmi tutti i file con l'estensione che vuoi (quindi non .encrypted).

Nel caso che ho descritto c'erano qualche migliaio di piccoli file ( documenti office e pdf) sparsi in diverse cartelle/sottocartelle.
Cercarli tutti a mano per poi ripristinarli è disumano e richiede una quantità di ore spropositata.

Nel mio caso il recupero è stato risolto creando uno script per cercare tutti i file con estensione .encrypted, ricavare la data dell'ultima modifica, far creare un file con la riga di comando che dicesse al backup di ripristinare il file dal backup del giorno prima della data di modifica. Eseguire il file con tutte le righe di comando. Ricontrollare. In alcuni casi, pochi per fortuna, è servito il backup del giorno prima ancora. Fine del recupero.

Pensavo invece che con lo snapshot sarebbe più comodo se ci fosse qualche comando per dire ripristina l'ultima versione di un dato file contenuta nello snapshot. Il che significa ripristinare il file allo stato precedente all'ultima modifica.

Dovrei studiarmelo bene.. anche perchè per non occupare quantità spropositate di spazio andrà limitato a tenere le copie di tot giorni. O si possono impostare il numero di copie del file ? Es. tieni 10 copie del file, alla 11a modifica butta via la copia più vecchia.
Da noi in ufficio modifichiamo circa 200 Mb di dati al giorno.

[zeMMeMMe]

Pensavo invece che con lo snapshot sarebbe più comodo se ci fosse qualche comando per dire ripristina l'ultima versione di un dato file contenuta nello snapshot. Il che significa ripristinare il file allo stato precedente all'ultima modifica.Non è un meccanismo che lavora a livello di file, lavora a livello di filesystem, esattamente come gli snapshot delle macchine virtuali.
Quindi puoi vedere tutti i file dello snapshot X, oppure tornare a quello snapshot

Dovrei studiarmelo bene.. anche perchè per non occupare quantità spropositate di spazio andrà limitato a tenere le copie di tot giorni. O si possono impostare il numero di copie del file ? Es. tieni 10 copie del file, alla 11a modifica butta via la copia più vecchia.
Da noi in ufficio modifichiamo circa 200 Mb di dati al giorno.

Come accennato non lavora "a file" (come rsnapshot, o time machine), lavora "a filesystem".
L'occupazione di spazio è minima.
Idealmente se fai uno snapshot al giorno, nel tuo caso, sono 200MB al giorno di spazio in più.


Usualmente si utilizzano meccanismi di pruning dei vecchi snapshot, qui è facilitato chi usa una GUI, oppure con crontab, oppure con scriptoni.

Le politiche più comuni sono
- uno snapshot all'ora per 30 giorni
- uno snapshot al giorno per 365 giorni
- uno snapshot alla settimana per sempre

e
- uno snapshot ogni 5 minuti tenuti per 24 ore
- uno snapshot all'ora tenuto per una settimana
- uno snapshot al giorno tenuto per un mese
e così via

[zeMMeMMe]

Mi rendo conto che per chi non è abituato sembra strano.

In sostanza dentro le condivisioni appare una cartella speciale .zfs, la quale contiene a sua volta tante cartelle quanti snapshot ci sono.
Entrando in quelle cartelle si vede tutto il contenuto del filesystem nel momento in cui è stato fatto lo snapshot.

Su macchine veloci e con SSD gli snapshot impiegano meno di un secondo, e sono a sola lettura.

E' possibile, volendo, trasformarle in un clone, cioè un filesystem aggiuntivo dove si può anche modificare i dati (ma è raro, essenzialmente si utilizzano a scopo di backup)

Ad esempio quando si vuol fare un backup di un sistema con sopra qualcosa di "strano" (un database) si
- cancella uno snapshot particolare (caso mai ci fosse uno zombi in giro)
- lo si crea
- si fanno le copie partendo dalla cartella dello snapshot "con calma", il server continua a lavorare indisturbato mentre lo snapshot è a sola lettura, si può usare tar, rar, 7z o quello che si preferisce
- si cancella lo snapshot creato

[nanotek]

In sostanza dentro le condivisioni appare una cartella speciale .zfs, la quale contiene a sua volta tante cartelle quanti snapshot ci sono.
Entrando in quelle cartelle si vede tutto il contenuto del filesystem nel momento in cui è stato fatto lo snapshot.

Si adesso ho capito..
nel caso citato non avrebbe particolarmente accelerato il processo di recupero (almeno la parte manuale).. sarebbe stato uguale.. creare lo script e via..

Il fatto che il pruning sia fatto tramite script però (anche se rende la cosa estremamente versatile) non mi piace molto.. porta facilmente a script molto complessi e che potenzialmente impiegano molto tempo a girare.

P.s. Infilare i dischi in zone del microserver con scarsa ventilazione li porta a morte prematura.
Nella versione gen 7, era disponibile un'unità opzionale da mettere nella baia del lettore dvd in grado di ospitare 4 hd da 2.5". Data la scarsa ventilazione i dischi lavoravano a temperature non proprio "fresche", il che li portava a morire in due - tre anni.
Nella gen 8 infatti non hanno proposto proposto nulla di simile.
Intendo dischi meccanici.

[zeMMeMMe]

Il fatto che il pruning sia fatto tramite script però (anche se rende la cosa estremamente versatile) non mi piace molto.. porta facilmente a script molto complessi e che potenzialmente impiegano molto tempo a girare.Per il "tempo" no, nel senso che sono millisecondi.
Per "complessi" dipende dalle politiche, quelle "basiche" del tipo "tieni gli ultimi 100 snapshot" sono piuttosto banali.
Comunque trattandosi di "mondo" UNIX crontab e scriptoni "della mado...a" [è il termine tecnico, se ne posto un paio penso che nessuno possa contestarlo] sono "normalissimi" ;)

Ad ogni modo FreeNAS e Nexentastor consentono di impostare la politica snapshot (di tipo diciamo così "banale") direttamente dalla GUI (che poi crea gli scriptoni, ovviamente :D )

P.s. Infilare i dischi in zone del microserver con scarsa ventilazione li porta a morte prematura...
Personalmente ci metto un singolo SSD attaccato col nastro adesivo americano, quindi il problema non è così grave :stordita:
Sulla nuova generazione, come precisato, non so, non ne ho mai avuto uno

[nanotek]

SSD sul quale metti l'hypervisor e vm e poi i nelle baie i dischi dello storage, immagino.

Come mai preferisci creare un disco virtuale all'interno di ogni disco fisico e poi dare accesso al disco virtuale alle vm ?

[TowerPillar]

Mamma mia, mi sono soffermato un giorno per documentarmi e guarda quanti post!

Leggendo il post mi sorgono alcuni dubbi:
Il microserver gen 8, così come i predecessori, ha solo 4 baie per i dischi.
Dove hai infilato gli altri dischi ?

Ho creato un supporto per 2 HDD da 2,5" agganciabile di fianco all'alimentatore; l'idea di base non è mia, ho preso spunto in giro su internet... io ho solo riprogettato il tutto in CAD e realizzato tramite una fresa CNC su policarbonato.
Ho riprogettato anche il supporto del dissipatore (questa di ideai invece è mia) in modo da unire la parte in alluminio di un classico stock intel ad un Noctua NF-A9x14 PWM, il tutto al posto di quello originale passivo.

Se volete ho le foto di tutto l'assemblaggio...

Zfs richiede 1Gb di ram per ogni Tb di dati nel datastore. Fai i conti della ram impiegata e di quanta te ne avanza, di conseguenza puoi calcolare il tuo massimo datastore.
12 TB richiedono 12 Gb di Ram. Su 16 Gb che hai in dotazione sei sicuro di usarne solo 4 per hypervisor e altre macchine virtuali ?
Le ram sono ECC ?

Questo l'ho appena letto anche io... infatti non sapevo come valutare la cosa.

Ho letto anche un'altro articolo che proponeva questa soluzione, ma non mi convince gran ché, ve lo ripropongo.

In pratica, viene creata una VM con installato FreeNAS che controlla tramite DirectIO in esclusiva il controller per lo storage;
le unità disco singole vengono quindi trattate in raid con ZFS dallo stesso FreeNAS, generato un volume iSCSI riacquisito in ESXi come Datastore.

Che ne pensate? Può essere una cosa "sana"?

[zeMMeMMe]

SSD sul quale metti l'hypervisor e vm e poi i nelle baie i dischi dello storage, immagino.Quasi: ESXi lo tengo su chiavetta USB. Ne tengo un'altra identica con una copia a livello di settore appiccicata al case col nastro adesivo
Come mai preferisci creare un disco virtuale all'interno di ogni disco fisico e poi dare accesso al disco virtuale alle vm ?Sia perchè il controller è finto RAID, e quindi con ESXi non ci sono alternative, sia perchè se lavori col virtuale non ha un grandissimo senso mappare i device fisici, almeno se hai hardware sufficientemente potente o non ti interessano particolarmente le prestazioni.
Nel mio caso i microserver li uso come backup dei "veri" server di virtualizzazione, quindi fanno essenzialmente le copie notturne dei dati e poco più

[zeMMeMMe]

..
Se volete ho le foto di tutto l'assemblaggio...Vai :eek:
Questo l'ho appena letto anche io... infatti non sapevo come valutare la cosaSe vuoi spiego il perchè e il percome

In pratica, viene creata una VM con installato FreeNAS che controlla tramite DirectIO in esclusiva il controller per lo storage;
le unità disco singole vengono quindi trattate in raid con ZFS dallo stesso FreeNAS, generato un volume iSCSI riacquisito in ESXi come Datastore.

Che ne pensate? Può essere una cosa "sana"?

Non mi pare.
Innanzitutto freenas non è certificato per la virtualizzazione (e vabbè, tanto funziona lo stesso, non è altro che freebsd)
Ma è il mappaggio del controller che non ha tantissimo senso, per i motivi spiegati sopra (se lavori in virtuale, lavora in virtuale, no?)
Un target iscsi non si nega a nessuno, lo scopo di quell' "accrocchio" è evidentemente poter fare gli snapshot delle macchine virtuali a basso costo computazionale, magari mettendoci sopra compressione e deduplicazione (nel caso in cui le VM siano praticamente identiche)

In sostanza è un approccio specifico per certi scenari.
Infatti ESXi non ha un filesystem (ha una specie d'abbozzo vmfs), e quindi non ha nessuna delle funzioni che sarebbero tanto belle di zfs.
Si può andare di promo, ma francamente non mi piace tanto, o addirittura di virtualbox su un qualche host.

Essenzialmente dipende dal tipo di macchina virtuale da fare: per windows e linux vanno bene praticamente tutti i virtualizzatori; per sistemi diversi (bsd, solaris, osx) mi oriento su ESXi, che grosso modo fa il suo lavoro

[malatodihardware]

Una curiosità: tutti quegli snapshot non rallentano zfs (come ad esempio gli snapshot su esxi)?

[zeMMeMMe]

Una curiosità: tutti quegli snapshot non rallentano zfs (come ad esempio gli snapshot su esxi)?Per niente

[zeMMeMMe]

Riguardo alla deduplicazione la RAM necessaria (in realtà funziona anche con meno, ma swappa e quindi rallenta) è di circa 320 byte per ogni blocco, i quali si possono stimare con zdb o addirittura contare (con un po' di pazienza)

Dipendono ovviamente dalla macchina; per un server tipico con 200GB di dati (documenti Word, Excel, PDF, posta elettronica etc) alla grossa (appena provato) ci sono circa 1.5M blocchi, quindi servono circa 480MB di RAM per le tabelle di deduplicazione (DDT).

Per uno storage con circa 1 milione di file per circa 1 terabyte circa 3GB di RAM, ammesso di voler fare la deduplicazione sull'intero filesystem, cosa del tutto priva di una logica

[conzi]

E' inevitabile
Nel microserver si mettono facilmente almeno 5 hard disk, usando una porta SATA "vuota" sulla scheda madre

Non mi è chiarissima la domanda, se interpreto bene basta guardare dentro .zfs, da lì puoi fare banalmente copia-incolla.
Puoi anche cercare con normali programmi tutti i file con l'estensione che vuoi (quindi non .encrypted).
http://oi63.tinypic.com/3308ttv.jpg
Anzi bisogna porre particolare attenzione ad escludere tale cartella dai backup, per evitare di avere una crescita spropositata.

ci sono versioni di cryptolocker che accedono agli share di rete anche se non sono connessi come unità di rete (con lettera per intenderci), usando le credenziali dell'utente loggato in quel momento al pc.
nel tuo esempio il contenuto di \\192.168.011\dati\.zfs\snapshot\ non è a rischio?

[mmiat]

ci sono versioni di cryptolocker che accedono agli share di rete anche se non sono connessi come unità di rete (con lettera per intenderci), usando le credenziali dell'utente loggato in quel momento al pc.
nel tuo esempio il contenuto di \\192.168.011\dati\.zfs\snapshot\ non è a rischio?

credo (spero) siano in readonly

[zeMMeMMe]

ci sono versioni di cryptolocker che accedono agli share di rete anche se non sono connessi come unità di rete (con lettera per intenderci), usando le credenziali dell'utente loggato in quel momento al pc.
nel tuo esempio il contenuto di \\192.168.011\dati\.zfs\snapshot\ non è a rischio?Per nulla, sono tutti (per rispondere anche al post precedente) readonly (è quello il "loro bello").
Con opportuna configurazione appaiono anche nelle versioni precedenti di Windows
http://i68.tinypic.com/eio86.jpg

Ad esempio da lì sopra si vede che una segretaria inizia a lavorare verso le 0715-0720

[zeMMeMMe]

Una curiosità: tutti quegli snapshot non rallentano zfs (come ad esempio gli snapshot su esxi)?
Precisazione: rallentano il send (cioè il meccanismo per trasformare un intero disco... in un file a scopo di backup). L'elaborazione di migliaia di snapshot riduce, effettivamente, la velocità di trasferimento nell'ordine di 20-40MB/s (con hardware performante).

Questo perchè "send" manda tutto, ma proprio tutto (cioè i dati, i metadati e tutti gli snapshot), una specie di "acronis" a costo zero.

Per come lo vedo è una delle caratteristiche che sarebbe tanto bello migliorare (cioè inviare solo l'ultimo snapshot); si può adottare una metodologia incrementale, cioè inviare solo le differenze dall'ultimo snapshot, ma la complessità di gestione (scriptoni) aumenta.

Spesso mi propongo di fare un'interfaccina PHP per gestire queste cose, ma non trovo mai il tempo :stordita:

[nanotek]

Ma è il mappaggio del controller che non ha tantissimo senso, per i motivi spiegati sopra (se lavori in virtuale, lavora in virtuale, no?)

Creare un disco virtuale vmdk da 2TB non mi ispira molta fiducia.
Ho diverse macchine virtuali di grandi dimensioni (40-50 GB) e un paio di volte mi è capitato che si corrompesse l'immagine vmdk. Se si corrompe un'immagine da 2Tb il tempo di recupero (ammesso che si possa fare) sarebbe lunghissimo.
Tu non hai mai avuto problemi in tal senso ? O esxi usa altri formati ?
Sono d'accordo che lavorare completamente in virtuale porta con se il vantaggio di slegarsi completamente dall'hw e quindi poterlo cambiare e migrare velocemente.. però non sono cose che capitano spesso e sono in genere programmate.

[TowerPillar]

Creare un disco virtuale vmdk da 2TB non mi ispira molta fiducia.

ripensandoci neanche a me, però stando ai consigli di zeMMeMMe dovrei crearne 4 da 4Tb circa (cioè uno per ogni disco fisico) per importarli nella VM con la quale ci creerei il RAID (5?) in ZFS...

Che faccio quindi? ..Ma nelle Aziende, come cavolo fanno?!?

[zeMMeMMe]

Creare un disco virtuale vmdk da 2TB non mi ispira molta fiducia.Si fa tutti i giorni
Ho diverse macchine virtuali di grandi dimensioni (40-50 GB)...Per ESXi sono di "minime" dimensioni, < della RAM di una macchina di fascia bassa.
Io, che amministro parecchi server ma non certo una farm intera, ho più VM di storage da 1TB/1M file senza particolari problemi. Usualmente non le faccio molto più grandi perchè dischi SSD >2TB sono difficili da trovare (vedo che Samsung propone un nuovo modello EVO, ma non li metto neppure in conto) e un po' di spazio per gli eventuali snapshot me lo tengo
e un paio di volte mi è capitato che si corrompesse l'immagine vmdk. Se si corrompe un'immagine da 2Tb il tempo di recupero (ammesso che si possa fare) sarebbe lunghissimo.E' quasi impossibile, anche con l'aiuto degli ingegneri Vmware (esperienza personale), sistemare i danni vmfs. E' così "banale" che è praticamente privo di qualsiasi elemento di aiuto nel casi di ripristino. Addirittura se viene "presentato" per errore a una macchina Windows (che mi mette il suo "marchio") spesso è ... fott-uto del tutto
Tu non hai mai avuto problemi in tal senso ?Toccando... no. Certo non posso asserirlo per tutto e tutti
O esxi usa altri formati ?Per ora solo quello

Sono d'accordo che lavorare completamente in virtuale porta con se il vantaggio di slegarsi completamente dall'hw e quindi poterlo cambiare e migrare velocemente.. però non sono cose che capitano spesso e sono in genere programmate.
Fai bene la "ritagliare" le operazioni per le tue necessità; a me capita abbastanza spesso di migrare da locale a cloud e viceversa durante l'avvio in produzione o per backup.

La miglior postazione per il disaster recovery è... un PC da 500 euro (magari 600 con più RAM) con Windows e... vmware player (tornato gratuito, fino a poco tempo fa era a pagamento), e magari una scheda da 10Gb (~400 euro), e un "discone" da 6TB.

Perchè ebbene sì, il virtualizzatore sotto windows (il primo prodotto di vmware) funziona bene, molto bene, e sfruttando il filesytem NTFS (e la sua cache) anche velocemente, molto velocemente, per gli snapshot

[zeMMeMMe]

ripensandoci neanche a me, però stando ai consigli di zeMMeMMe dovrei crearne 4 da 4Tb circa (cioè uno per ogni disco fisico) per importarli nella VM con la quale ci creerei il RAID (5?) in ZFS...Mai mai mai, sempre raid-1 o mirror che dir si voglia.
Solo se assolutamente indispensabile (cioè hai una caterva di dischi, tipo una dozzina).
Per il resto... maimaimai
Che faccio quindi? ..Ma nelle Aziende, come cavolo fanno?!?
... assumono quelli come me :D o alla peggio usano Windows :stordita:

Allora tornando al punto, ci sono vari approcci

1) fai il RAID-1 dei dischi col controller hardware, e quindi su ESXi vedrai un singolo volume (per ogni coppia di dischi). secondo i sacri testi non è consigliato. nella mia esperienza funziona
2) disattivi il controller RAID hardware, e metti i vmdk sui datastore diversi, e fai il mirror dal sistema operativo con zfs. questa configurazione non è consigliata secondo i sacri testi. nella mia esperienza funziona
3) disattivi il controller RAID hardware, e metti in directio i dischi, e fai creare i volumi direttamente da zfs. alcuni sacri testi consigliano questa configurazione. io non l'adotto per i motivi sopra precisati (spesso sposto da ESXi locale a cloud, ed anche avanti-indietro da VmWare Workstation)
4) (se HW sufficientemente potente) crei DUE macchine virtuali su due datastore diversi, sulla seconda fai fare i backup della prima (zfs send-receive). In questo caso niente mirror, però hai una VM praticamente pronta per uso come sviluppo o backup della prima. La uso con dischi SSD

5) tutta la serie con lo storage "fuori" (iscsi, nfs etc)

[TowerPillar]

... assumono quelli come me :D o alla peggio usano Windows :stordita:

Alla peggio con windows come sarebbe il tutto???

[zeMMeMMe]

Alla peggio con windows come sarebbe il tutto???

Dai stavo scherzando... :D
Come file server non sarebbe neppure male, se non avesse il "problemino" che non sei mai sicuro se i tuoi dati sono non modificati.
In parecchi casi non è così importante (se si corrompono le foto di un viaggio, pazienza).
In altri, se hai esami non ripetibili, son dolori (anche non eufemistici)

Per un riassunto su zfs & raid (però fisico, non virtuale) questo è uno dei miei siti più consultati
https://calomel.org/zfs_raid_speed_capacity.html

[nanotek]

E' quasi impossibile, anche con l'aiuto degli ingegneri Vmware (esperienza personale)
Eheh.. allora ti è capitato !

A me è capitato su due VM di sviluppo gestite con workstation su host ubuntu. Perdita totale. Per fortuna c'erano i backup aggiornati però solo al giorno prima.

Questa discussione mi ha spinto a guardare a esxi però la versione free ha la forte limitazione di non avere disponibili le api per il backup. Per ora la licenza standard è fuori budget :(
Magari quando ho tempo libero guardo xenserver cercando qualche guida.

Diciamo che per un datastore aziendale puro (nel senso che fa solo quello) l'esigenza di migrare le macchine in cloud (per farle funzionare, non a scopo di backup) è inesistente. L'unica migrazione che si fa' è quando si cambia l'hw.

[TowerPillar]

È che da un lato mi scoccia anche un pò mettere 4 dischi in mirror invece che raid5... 4TB in più fanno comodo!
Poi comunque sia, se non mi serve o sono fuori, probabilmente starà spento, e alla peggio lo accendo da remoto, oppure può anche accadere che lo metto a scaricare e si fà 30-90 giorni no-stop, o che devo fare dei test con una vm e sta una settima accesso, o lo tengo acceso solo di giorno...

Per dirla tutta, non è neanche solo in casa, ho anche un acer ac100 con un i5, 12Gb di ram, 4+1 hdd e altri 2 NAS da 2 baie, un synology e un qnap, però questo essendo il più nuovo, potente e capiente, mi piaceva sfruttarlo bene e nella miniera giusta.

[zeMMeMMe]

È che da un lato mi scoccia anche un pò mettere 4 dischi in mirror invece che raid5... 4TB in più fanno comodo!Vedo che non ti ho convinto :cry:
Certamente non sono una "fonte" abbastanza affidabile.
Fai qualche ricerca e vedi cosa "dicono tutti" (nella maggior parte dei caso non sanno nulla)

http://www.zdnet.com/article/why-raid-5-stops-working-in-2009/

Ti metto la chiosa
Which means that consumer RAID5 arrays can't be trusted to store your data reliably. Quickly, yes. In large chunks, yes. More simply than individual USB drives, yes.

But not more reliably than a single drive.
A me è capitato di fare il recovery di dati RAID5 (linux), e non mi è piaciuto per niente, nonostante sia il mio lavoro.
Ma proprio per niente niente.

Non sono certo il solo
Using RAID-5 remedies in an attempt to put right a RAID-10 tends strongly to create disastrous outcomes. A word to the wise IT service professional: never assume your client knows what RAID level is in use.
Fai qualche piccola "ricerca" (come detto per la maggior parte di ggente ignorante) e vedi te cosa succede con RAID5

[nanotek]

In realtà con 4 dischi in mirror a coppie ottieni 8 TB.
Anche io non mi fido del raid 5e in effetti anche i nas di grosse dimensioni si affidano al raid 6.

Un chiarimento: con zfs è possibile far vedere i due dischi da 4 tb (in mirror su altri due) come un unico spazio da 8 tb creando un pool con i 4 dischi ?

[TowerPillar]

Si mi sono informato già verso aprile su quale raid adottare e sul raid5 in particolare, conosco già tutti i pro e i contro e varie esperienze.
Ho già avuto di recente poi a che fare con un recupero dati proprio sui 4 dischi che ho ora nel server, in configurazione raid5 Linux e non è stato facile, per questo alla peggio preferirei usarli nativamente con windows, almeno ho visto che i software di recovery sono più facile da reperire.

Detto ciò però, anche il pezzo di articolo che hai riportato ne parla e lo sconsiglia, ma è altrettanto vero che indica però quelli di fascia consumer e molto probabilmente sono quelli software, e quelli per esperienza sò già che non vanno di per sè.

Per questo ho preferito metterci un controller hardware da server, con CPU e ram dedicata e elettronica di controllo. Un pò meglio dovrà essere... o ancora no?!?!?!

[zeMMeMMe]

Per questo ho preferito metterci un controller hardware da server, con CPU e ram dedicata e elettronica di controllo. Un pò meglio dovrà essere... o ancora no?!?!?!
no, anzi peggio.
non esiste un raid hardware, è il controller ad essere dotato di cpu e ram, e firmware, più o meno bacato.
stai semplicemente demandando il lavoro.

se sai già che i problemi son tanti, perchè non te ne stai alla larga?

meglio ancora scarica nexentastor community, aggiungi un paio di dischi virtuali e prova a vedere cosa succede se ne togli uno.
o meglio ancora importa un singolo disco (pool) su un'altra VM, alteralo brutalmente (con dd ad esempio) per simulare un guasto magnetico grave, e poi ripresentalo alla prima.

insomma simula tutti i "drammi" che ti vengono in mente, così ti farai una tua opinione (se le mie non ti bastano)

[TowerPillar]

meglio ancora scarica nexentastor community, aggiungi un paio di dischi virtuali e prova a vedere cosa succede se ne togli uno.

Ritorniamo al fatto che dovrei creare file grandi 4Tb per i dischi delle VM... non era stato sconsigliato qualche post fà?

[nanotek]

Cavoli.. zeMMeMMe è stato bannato.
Volevo chiedergli altre cosette..

Chi è esperto di zfs può dirmi perchè preferiscono freeBSD e non zfs su linux? Questione di maturità (zfs è su freebsd dalla ver 7, zfs su linux è production ready da solo 2 anni) ?

Ritorniamo al fatto che dovrei creare file grandi 4Tb per i dischi delle VM... non era stato sconsigliato qualche post fà?
Io ho sollevato il dubbio perchè ho avuto un paio di esperienze negative su macchine di sviluppo gestite con vmware workstation. zeMMeMMe ha detto che con esxi non ha mai avuto problemi con dischi così grandi.

[zeMMeMMez]

...

[nanotek]

Mi sono documentato un pochino e in effetti zfs su linux, anche se c'è una buona comunità di utilizzatori, pare non dare le stesse certezze che da su freebsd.
Sarebbe interessante creare un confronto tra i due: quali strumenti stabili ci sono e non (su un post a parte).

Ho trovato anche molti che consigliano il directIO sui dischi perchè alla fine se ci si dedica interi dischi fisici, in un eventuale migrazione, si migreranno anche i dischi fisici. Non ci sono vantaggi particolari rispetto a migrare dischi virtuali.

[zeMMeMMez]

...

[nanotek]

Credo che lo scenario tipico a cui si riferiscono sui forum sia quello di avere il server "in casa" e di cambiare hw (tipicamente ogni 5 anni).

SSD per lo storage mi pare per ora uno scenario poco frequente. Ci devono proprio essere necessità di alte prestazioni. Per lo storage "di massa" regnano ancora i dischi meccanici.

C'è da dire che in effetti ha ben poco senso virtualizzare se poi si dedica l'intera macchina fisica ad un unico scopo.

[zeMMeMMez]

...

[nanotek]

Dopo 5 anni gli hard disk saranno "cotti", e quelli nuovi 4 volte più capienti costeranno come un pacchetto di sigarette
;)
Sono anni che queste previsioni non funzionano ;)
Me l'hanno detto anche 10 anni fa' quando compravo hd da 1TB. Dopo 10 anni il prezzo è solo dimezzato (a parità di dimensioni, riferito ad hd enterprise class 1TB).
Anche se adesso con l'arrivo di più produttori di nand "3d" ci sono condizioni per una maggior competizione.

P.s. Le stesse previsioni le sentivo spesso fare con i processori..


Per la verità sono anni, almeno 4 o 5, che in ambito lavorativo (* nuove installazioni, non vecchie highlanders') si è ormai passati a 100% flash, il primo SSD che mi è arrivato dalla Korea mi sembra sia del 2007/2008.
Il limite principale è la dimensione a 2TB (oggi 4 per 850EVO) per volume, ma non è un grande problema con zfs fare un array con una ventina o anche più (magari con controller PCIe da 24 porte senza expander, non di ultimissima generazione ma valido).
;)
Forse guardiamo a fasce diverse.. storage con ssd 5 anni fa' avevano costi eccessivi per le piccole imprese. Tutt'ora lo vedo solo in ambiti dove prevale la necessità di performance alte.

[zeMMeMMez]

...

[pac0]

Io invece vedo (e vendo) macchine solo flash.
Come accennato perfino nel PC "da computer discount" ormai trovi SSD (sia pure economici eccetera). E nelle piccole aziende 1 o 2TB di spazio-disco è più che sufficiente (anzi, buona parte dei server Windows ~2003/2008 usano spesso tagli da mezzo TB).


Per curiosità di che fascia di SSD stiamo parlando?
Io per il momento, per quanto riguarda server del livello PMI, ho avuto modo di testare solo SSD di fascia consumer o poco sopra (Samsung 950 EVO e PM863, Crucial MX200) e devo dire che la differenza si sente molto, anche con l'uso di controller RAID di un paio di generazioni fa che sicuramente sono un collo di bottiglia per un array di SSD.
Volevo capire se oltre alle prestazioni c'è anche un ottimo livello di affidabilità. Ho letto alcuni articoli/report dell'uso di SSD di fascia consumer in ambienti di produzione con ottimi risultati anche dal punto di vista dei guasti, con numeri migliori (o comunque paragonabili) rispetto a quelli di HDD SAS di fascia enterprise.

[zeMMeMMez]

...

[TowerPillar]

E alla fine eccomi di nuovo qui :)
Ho usato questo tempo un pò per testare tutte le soluzioni che mi avete consigliato, le ho confrontate anche con l'esperienza di altri tecnici del settore scoprendo che alla fine sono tante "dottrine" e modi di fare anche opposti.
Il Risultato??? Che ancora non lo sò, ma credo che comunque inserire grosse moli di dati in unità virtuali non sia molto salutare, anche se con chi ho parlato che lo fà, non ha mai avuto problemi. Tutta fortuna???

Ho tentato alla fine di sperimentare questo famoso directpathIO (conosciuto anche come passthrough) direttamente al controller, come sto già facendo col serverino precedente e ho scoperto tristemente che in questo nuovo, ESXi mi và in kernel Panic!:(

Ma non mi dò per vinto e dato che ho una nuova pulce nell'orecchio, provo a rilanciare con quest'altra domanda; Conoscete VMware Virtual SAN??? Ed è adattabile al mio caso???

[zeMMeMMez]

...

[TowerPillar]

Ok dai, non siamo poi cosi distanti... entrambi abbiamo 12Tb, solo che io di datastore e lui di ram :P.
Si, ripensandoci ammetto ora che hai ragione, riconosco la grande esperienza e diffusione di vmware nel mondo, nonché leadership in questo campo.

Tornando a me, dato che il passthrough mi blocca la macchina, e c'ho pure perso inutilmente 2 giorni a capirne il perché e ne sono anche un pò amareggiato, al momento la soluzione migliore mi sembra quella col raid virtuale in ZFS, se non mi passa altro per le mani nel frattempo.

Invece, solo a livello di informazione, dato che conosci la virtual SAN, sapresti illustrarmi a grandi linee, come funziona, lavora e non sò, i "requisiti"?
Una panoramica... dato che a me il sito di vmware spesso pare in arabo!

[zeMMeMMez]

...