Buongiorno a tutti,
sicuramente chi ha fatto il percorso "design" (che prima o poi vorrei fare) potrà darmi una risposta a questa semplice domanda.
Nel caso volessi aggiungere ad un fileserver virtuale un disco da 4 TB (esxi 5.1 quindi nessun limite dei 2TB) dovrei aggiungere un disco dedicato formattarlo vmfs e crearci sopra un vmdk da 4TB o sarebbe meglio aggiungere lo stesso disco dedicato ma farglielo vedere come RDM?
CIao e grazie
Non conosco altri NAS, ma ti assicuro che NetApp si integra perfettamente in AD, lo puoi tranquillamente gestire come un fileserver windows.
Hai la possibilità di fare il restore dei file direttamente da esso, con le snapshot dei volumi. L'operazione è semplicissima, tipo il filelevel restore di Veeam.
Se hai necessità di disaster recovery, lo puoi sempre abbinare ad un sistema di backup via NDMP.
Ti assicuro che chi lo ha se ne innamora. Costo a parte...
Ciao
hai perfettamente ragione, però c'è da dire che il costo della licenza CIFS sui netapp è veramente molto importante.
Francesco Bonetti ha scritto:
Non conosco altri NAS, ma ti assicuro che NetApp si integra perfettamente in AD, lo puoi tranquillamente gestire come un fileserver windows.
Hai la possibilità di fare il restore dei file direttamente da esso, con le snapshot dei volumi. L'operazione è semplicissima, tipo il filelevel restore di Veeam.
Se hai necessità di disaster recovery, lo puoi sempre abbinare ad un sistema di backup via NDMP.
Ti assicuro che chi lo ha se ne innamora. Costo a parte...
Ciao
Ecco, però questa cosa vorrei chiarirla a beneficio di chi in futuro dovesse leggere questo thread: se il backup lo fai all'interno dello storage stesso, che backup è? Ho capito la risposta "ha tutto ridondato", ma basta un firmware scaricato male, un fulmine o la legge di Murphy e ti ritrovi in un colpo solo senza i dati primari e le loro copie "di sicurezza"
Secondo me la copia esterna non è disaster recovery, è la base di un semplice backup: i dati li salvo "lontano" da dove stanno solitamente.
Ciao,
Luca.
penso che Francesco stesse sottolineando che il backup diciamo "anti utente che si cancella i file" viene gratuitamente con un fileserver netapp, anche in cifs, addirittura in modo che puo' essere gestito autonomamente dall'utente stesso.
Con questa tecnologia si possono risparmiare ore di lavoro dell'IT per recuperare file da nastri, consentendo all'utente di ripescarsi in pochi secondi il file cancellato/modificato dalla cartella .shapshot.
Una cosa di cui sicuramente il sistemista si innamora perche' gli toglie una rottura notevole
Poi sempre come diceva Francesco, ci sono tutte le possibilita' di replicare i dati su altra macchina (cluster, metrocuster, snapmirror) sia di portare tutto su nastro "via NDMP".
Magari stiamo chiamando la stessa cosa in due modi diversi, ma quello "per me" non è un backup, è una snapshot esattamente come si può fare con le shadow copies di Windows, magari saranno più schifose di NetApp ma non era questo il punto della mia osservazione.
Non ho mai messo in dubbio la qualità di NetApp o il fatto che le loro snapshots siano grandiose. Dicevo però che fare il salvataggio dei dati "fuori" dallo storage secondo me non è un optional, ma va fatto e basta.
Ciao,
Luca.
Magari stiamo chiamando la stessa cosa in due modi diversi
sì: quello che tu chiami "backup" francesco lo chiamava "disaster recovery"
Si Tinto, intendevo proprio questo. Lungi da me pensare che perchè hai uno storage "tutto ridondato" puoi fare a meno dei backup.
Riportandoci in topic, tutto era partito dal fatto che il cliente mp_roma ha una vm con 16 pRDM da 4TB e mi sembra d'aver capito che non fa il backup.
Questo per me è allucinante.
Ciao
Tinto1970 ha scritto:
Magari stiamo chiamando la stessa cosa in due modi diversi
sì: quello che tu chiami "backup" francesco lo chiamava "disaster recovery"
Lo chiamo disaster recovery nel caso del NetApp.
Per il fatto che tramite NDMP salvi l'intero volume e non la singola share/file documento ecc. e per il fatto che con questo puoi recuperare l'intero storage oltre che il singolo file. Spero di esser stato più chiaro questa volta
Questo per me è allucinante.
conosco alcune realtà (emh) in cui non è bastato un terremoto disastroso a pochi km di distanza per capire la necessità di creare un sito di DR su un'altra sede.
Ciao,
sperando che non ce ne voglia l'OP, dato che stiamo andando piu' verso questioni "quasi filosofiche".
Premessa: conosco NetApp solo a livello teorico.
Credo che tutto l'oggetto del contendere sia sulla definizione di backup e sul livello della propria "sana" paranoia (e sul fatto che anche in letteratura devo dire che ogni tanto si mescolano un po' le terminologie).
Personalmente preferisco avere i backup fuori dallo storage che li contiene, qualunque esso sia (EMC, NetApp, HP, quellochevolete) per il semplice motivo che avere una copia di sicurezza sullo stesso oggetto che devo proteggere mi sembra un cane che si morde la coda: se perdo l'oggetto protetto perdo anche il suo backup. E, opinione personale, non esiste l'oggetto indistruttibile capace di resistere a tutto e tutti (mai sottovalutare cosa possono fare gli utenti, anche sistemisti )
Ovviamente questo ragionamento vale per i backup "importanti" (daily, weekly): per i backup "spendibili e frequenti" per i danni passeggeri (l'utente che elimina quello che non dovrebbe o simili) mi va benissimo uno snapshot dello storage, ancora meglio se posso poi gestirli con facilita'. (nota: snapshot a livello storage, non di VM).
Per quanto riguarda copia di backup esterna e DR, io considero che una copia esterna diventi un copia di DR solo quando viene portata "in un posto sicuro" (replica a distanza chilometrica/in altro edificio, tape portati in banca/in altra sede e cosi' via) e ha associato un piano che indica quando e come va usata.
Il tutto ovviamente IHMO.
--
Giuseppe
L'argomento backup, restore, business continuity, disaster recovery, è un argomento che porta sempre a dei bei confronti e discussioni.
Fossimo davanti a birre e sprite (Giuseppe ) a quest'ora avremmo trovato un punto d'accordo.
Ciao a tutti ragazzi,
questa discussione mi interessa molto, piu che altro, perche vorrei capire quale possa essere
la migliore conf di mie numerose VM.
Circa 2 anni fa siamo passati da sistemi Unix AIX a VM Linux.
Ora , nell' allocare lo storage a tali VM, la scelta fatta e' stata quella di RDM (physical mode), in particolare per DB.
Leggendo su vari doc, attualmente le performance tra vmdk e rdm sono molto simili, ma cio che non riesco ad avere
come conferma e' la seguente;
Presa per esempio una VM tipo,
Le configurazioni Storage sono le seguenti;
(sotto c'e' un CX4-480)
VM Linux Red Hat - DATASTORE1
OS: 20 GB ( vmdk )
SWAP: 4 GB ( vmdk )
DB: 6 dischi da 50 GB agganciati tutti come RDM e gestiti tramite LVM su di un unico VG
se io volessi migrare i miei RDM to VMDK , avrei le stesse performance se alloco i nuovi vmdk sullo stesso datastore?
oppure e' preferibile avere ( per alte performance ) un vmdk per ogni datastore?
Tutto cio e' relativo solo a capire dove le mie performance siano migliori,
sicuramente un vmdk e' molto piu "gestibile" di un un RDM,
ma e' altrettanto vero che le utility storage, come clone e snapshot , con un rdm
, quindi una lun, ti permettono di lavorare sul singolo device, piuttosto che sul datastore totale.
Spero che la mia domanda possa aiutare molti del gruppo.
Grazie a tutti per le eventuali considerazioni che andrete ad esprimere.
prima di tutto dovresti dirci quale DB usi ma suppongo oracle, visto anche lo storage che hai dietro.
Probabilmente stiamo parlando di db molto carichi e/o che devono essere molto performanti e solidi.
Penso comunque che la tua architettura sia davvero un po' troppo complessa, nel senso che usare così pesantemente RDM è "filosoficamente" contrario alla virtualizzazione, nel senso che come dici tu gestire dei vmdk è molto più facile.
Anche il creare un datastore per ogni vmdk è probabilmente non giustificato neanche in un ambiente super prestante. Sicuramente non converrà mettere tutti i vmdk in un solo datastore, ma arrivare a un buon compromesso, analizzando se ci sono colli di bottiglia da qualche parte.
E' vero il discorso che fai sul fatto che gli snapshot che fai con navisphere, nella situazione RDM, ti permettono di lavorare a livello di device mentre gli shansphot fatti da ESXi lavorano a livello di VM. Ci sono pregi e difetti in entrambi i casi, che dipendono molto dagli applicativi che sono nella vm, in questo caso il db.
Io ho un po' di esperienza con MySQL: in quel caso ciò che ho visto essere importante per le prestazioni non è tanto "come vanno i dischi" ma "quanto più possibile uso lra RAM invece di fare IO su disco".
Ciao,
considerei tra i vari vantaggi anche la maggiore facilità di espansione dei dischi stessi, dato che immagino che i 6 rdm concatenati con lvm siano frutto di espansioni successive. Con VMDK faresti un unico disco da 300 Gb successivamente espandibile a caldo.
Per quanto riguarda il design, bisogna anche considerare come è configurato e segmentato il CX, a parte i soliti paper dei produttori di DB che suggeriscono dischi separati per ogni mount point, se poi alla fine tutti gli RDM vengono esportati da un unico volume sottostante alla fine rischia di essere più una complicazione che altro.
Per la gestione delle snapshot, torniamo a quello che già stiamo dicendo in questi giorni, dipende anche come vengono gestiti i backup, quale software e con quale frequenza, dove vengono salvati e altro...
Ciao,
Luca.
Ciao,
devo dire che sia Tinto che Luca ti hanno fornito ottimi spunti di riflessione.
A questo punto, se puoi, potresti mettere in piedi qualche VM di test e fare delle prove.
E' probababile che la tua configurazione attuale sia stata fatta per mirare alle performance.
Se i vari RDM e relative lun, sono distribuite su controller diversi e VDISK diversi (non so come li chiama EMC), con raid level diversi, avrai un carico sullo storage ottimizzato.
Ripeto, metti in piedi un ambiente di test e prova
Ciao
Grazie a tutti per la condivisione di idee.
I DB utilizzati , i quali reggono il Business Aziendale sono Oracle e Adabas.
Sicuramente ho tralasciato molti aspetti , nel chiedere un vostro parere
riguardo performance tra vmdk e rdm.
Alcuni di questi aspetti sono;
L' utilizzo di rdm ci facilita molto la gestione del Disaster Recovery, ovvero;
Prendendo per esempio i 6 dischi, tramite MirrorView, vengono replicati,
in modalita asincrona ( ogni 5 minuti ) verso il sito di DR, con conseguente
clone, in un determinato momento della giornata, per preservare consistenza e
non avere problemi in caso di replica di un errore sul DB nell' arco di 5 minuti.
Mirror attivo H24, al termine del batch serale, stop del DB, sincronizzazione forzata sul sito di dr,
golden copy su ulteriori dischi, se tutto ok, restart DB e tutti felici e contenti.
Questo se fosse gestito con VMDK mi porterebbe sicuramente ad utilizzare piu spazio disco,
se avessi i vmdk su due DataStore diversi, sicuramente avrei la necessita non di due lun da 150 GB,
ma almeno 150 GB +20%.
Il mio sito DR , e' configurato per ospitare solo le VM Business CORE e quindi anche un +20%
di disco utilizzato non mi darebbe la possibilita di replicare tutto.
Si e' vero, se VMDK ,potrei espandere i dischi a caldo, ma anche tramite Host Level Mirror,
non avrei nessun tipo di disservizio.
Oltre a tutto cio espresso prima e' pur vero che ogni notte, nel nostro ambiente di Prod,
avvengono delle Snap dei 6 dischi ( sempre per prendere in considerazione l' argomento di partenza) ,
le quali ( tramite processo automatico ) vengono montate su di una ulteriore VM per eseguire
report di statistiche, senza intaccare le performance della VM di Prod.
Questo utilizzando Snapshot delle LUN tramite Utility Storage.
E' vero che la domanda fatta in precedenza era stata molto generica e ogni architettura
vive in base a determinate esigenze, ma proprio perche sento sempre molto + parlare di vmdk che di RDM,
che cerco di capire cosa mi possa dare piu performance o valore aggiunto da permettermi di scegliere una piuttosto che l' altra conf.
Grazie ancora Luca e Tinto per le vostre considerazioni e
sono qui ad attenderne altre, ma non bocciatemi tutta l' architettura, altrimenti
mi metto a piangere .
Saluti e spero che tali info siano utili anche ad altri utenti.
Ciao ,
grazie anche per il tuo contributo.
Le risorse per tirar su un ambiente di test non ci sono,
quindi se ci fosse qualcuno che abbia gia fatto tale test spero che mi risponda.
Anche perche su KB di vmware trovi test 1 to 1.
1 RDM vs 1 VMDK, ma non tra + RDM vs + VMDK.
Cmq si , le sei LUN risiedono tutti su differenti Raid Group.
Saluti
Sicuramente non ti boccio nulla anche perché oracle so appena come si scrive
una cosa da tenere in conto è anche il "fattore umano": se voi siete "skillati" ed esperti nel lavorare con gli strumenti forniti dal vostro storage ci sono buoni motivi per continuare a lavorare sul quel livello.
In generale gli snapshot fatti dal sistema di storage sono molto veloci ed efficienti. Quelli fatti dall'hypervisor sono più lenti e pesanti ma secondo me più facili da capire e usare: fare un revert è semplice e riporta la VM allo "status quo". Lavorare con gli snapshot a livello di RDM comporta il conoscere bene oltre allo storage anche il sistema operativo e l'applicativo, pena il ritrovarsi con un db che non riparte o con dati incoerenti.
le sei LUN risiedono tutti su differenti Raid Group
curiosità: questi raid group hanno anche altre lun, per applicativi diversi? Come sono fisicamente distribuite le lun sui dischi (e che tipo di dischi...)?
Si ,
i Raid Group ospitano anche altre Lun, ma con basso utilizzo e richiesta di I/0.
Tutti in RAID 5 e sono composti da 9 dischi FC da 256 GB.