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
Ciao,
da vSphere 5.0 è stato esteso il limite dei datastore VMFS fino a 64 Tb, ma i dischi VMDK delle singole virtual machine possono essere al massimo di 2Tb (tecnicamente 2tb - 512 bytes) come nelle precedenti versioni.
Per costruire dischi di grandi dimensioni virtuali hai due opzioni:
- concatenare nel guest OS multipli dischi utilizzando gli strumenti offerti dal sistema operativo (dynamic disks su Windows o LVM su linux)
- usare dischi RDM fisici (il virtual RDM ha lo stesso limite di 2 tb)
La scelta tra i due dipende da alcuni fattori. Scegli RDM se devi anche clusterizzare il disco con strumenti come MSCS, ricordandoti però che non puoi fare snapshots di questi volumi con vCenter e quindi poterlo salvare con i vari software di backup esistenti. Io ti consiglierei di usare la concatenazione dei vmdk nel guest.
Ciao,
Luca.
Il limite dei 2TB è stato superato per quanto riguarda la dimensione dei datastore VMFS.
I dischi virtuali VMDK in esso contenuti, sono ancora limitati ai 2 TB meno 512bytes. http://www.vmware.com/pdf/vsphere5/r51/vsphere-51-configuration-maximums.pdf
Se necessiti di un unico disco da 4 TB ti conviene fare un RDM fisico.
Ciao
Ciao a tutti e grazie...
La concatenazione del disco a livello OS porta un degrado a livello di performance (non dovrebbe se fa uno striping). Comunque, in questo caso, qualora avessi un vmfs di 4TB dovrei fare 2 vmdk da 2TB è unirli corretto? O converrebbe fare 2 VMFS da 2 TB sui quali creare due vmdk da 2TB?
Ciao e grazie ancora
Su windows personalmente ti sconsiglio i dischi dinamici e il concatenamento dei volumi.
Più che uno striping è un extend. Comincia a scrivere su uno e al riempimento passa all'altro. Se perdi il primo volume perdi tutto.
A livello di performance non vedo grandi differenze.
Le differenze le puoi avere se metti i vmdk su datastore diversi e quindi lun diverse, gestite da controller diversi.
Ma qui dipende da che storage stai utilizzando.
Ma il server sarà win o linux?
Ciao
Ciao, Due osservazioni: - il dynamic disk è configurabile, si può decidere di usare un jbod oppure configurarlo in un raid0, a seconda delle necessità, e le sue performance non sono scadenti se si evitano raid5 o simili. Raid0 o jbod vanno come i dischi sottostanti - per i rischi connessi alla perdita del metabase, non ci vedo differenze rispetto ad usare un rdm fisico sinceramente. In entrambi i casi bisogna prevedere backup adeguati per proteggersi dalle perdite di dati. E vedo molto più facile salvare un disco vmdk con uno dei molti software di backup disponibili per VMware (avendo ovviamente cura di verificare il supporto ai dischi dinamici, non tutti ce l'hanno) piuttosto che avere un RDM cui puoi accedere solo con un agent installato dentro la VM. Ciao, Luca.
Ciao Luca,
Sono d'accordo con te che è molto più gestibile un vmdk che non un RDM fisico.
Converrai con me però, che i dischi dinamici di Windows e il suo relativo raid software sono una delle maggiori schifezze che esistono.
Io dovessi scegliere, farei più dischi vmdk. A windows li mapperei come dischi di base e poi distribuirei le varie share tra di essi.
Ciao!
Ah vabbeh, così son d'accordo anche io, ma non possiamo sapere a prescindere se l'opener ha bisogno di uno spazio dati contiguo da 4 Tb o può separarlo in più shares piccole.
Solo risolto questo dubbio si può allora valutare se convenga usarli o meno. Riguardo l'affidabilità, da 2008 in poi sono nettamente migliorati, e fintanto che si usano in jbod o raid0 funzionano bene, io non ho mai avuto problemi.
Sono curioso di provare i volumi virtuali di ReFS sotto windows 2012, che hanno un comportamento molto simile a LVM di linux.
ciao,
Luca.
Riguardo l'affidabilità, da 2008 in poi sono nettamente migliorati, e fintanto che si usano in jbod o raid0 funzionano bene, io non ho mai avuto problemi.
nel mio piccolo li ho usati spessisimo per espandere i dischi e mai visto problemi di alcun tipo
Tinto1970 ha scritto:
Riguardo l'affidabilità, da 2008 in poi sono nettamente migliorati, e fintanto che si usano in jbod o raid0 funzionano bene, io non ho mai avuto problemi.
nel mio piccolo li ho usati spessisimo per espandere i dischi e mai visto problemi di alcun tipo
Con 2008 l'espansione dei dischi la puoi fare anche con i dischi "basic"
Ciao
Anche oltre i 2 TB su un disco VMDK? (Oh, fai queste alzate... :P)
Luca Dell'Oca ha scritto:
Anche oltre i 2 TB su un disco VMDK? (Oh, fai queste alzate... :P)
Si parlava di stare sotto i 2TB, altrimenti non avrebbero senso tutti gli altri discorsi fatti.
I dischi basic possono arrivare a max 2 TB. Oltre servono i dinamici.
A questo punto il nostro amico ci dovrebbe dire su che OS deve implementare sto file server.
Magari è un opensolaris con ZFS :smileysilly:
Se hai uno storage iSCSI io personalmente preferisco l'opzione del guest iSCSI initiator da dentro la VM.
In questo modo sei svincolato dai limiti di VMware e hai in vantaggio (o svantaggio, a seconda dei software di backup) di escludere il disco dati dai programmi di backup per VMware (ma di poterlo ad esempio gestire da tool dello storage o da agenti o da altro).
Rispetto all'RDM fisico (dove comunque non puoi avere il backup VMware based) o alla schifezza dei dischi dinamici (che possono dare vari problemi con i programmi di backup VMware based) è, dal mio punto di vista, una soluzione più pulita.
Oh, questo è interessante, in tre risposte ci siamo ritrovati a indicare come preferita ognuna delle tre soluzioni disponibili
Andrea, sono interessato a sapere perchè dici "schifezza dei dischi dinamici (che possono dare vari problemi con i programmi di backup VMware based)"; se il problema è la compatibilità coi programmi di backup, mi verrebbe da dire che esistendo da Windows 2000, il non supporto dei dischi dinamici è allora più dovuto al programma di backup stesso che è "una schifezza".
Io sono più che altro dubbioso di dover gestire due software differenti di backup per gestire una stessa VM, e la VM stessa che possiede una componente praticamente ignota all'ambiente di virtualizzazione, ancora meno visibile di un disco RDM...
Ciao,
Luca.
Buongiorno a tutti e grazie per le risposte.
La mia richiesta era del tutto generica. Era un dubbio a livello di design perchè ho un cliente che ha un fileserver windows a cui ha attaccato 16 dischi RDM da 4TB in modalità fisica e questo mi rompe non poco le scatole per il discorso backup(ad esempio con Veeam....a proposito, il fatto di usare il virtual mode piuttosto che physical mode comporta un degrado delle performance in qualche modo?) .
Ciao e grazie
Ciao,
tecnicamente una lieve differenza di prestazioni tra i due c'è, dato che nel vRDM l'I/O attraversa lo stack VMFS, quanto poi questa differenza sia effettivamente visibile non lo so, non ho mai fatto o visto in giro test approfonditi, mi verrebbe da dire poca...
Data la limitazione a 2 Tb del vRDM io sinceramente lo vedo come una soluzione un pò "ne carne ne pesce", allora tanto vale usare dei veri e propri VMDK, e risolvi i problemi di snapshot e backup; oppure se devi scavalcare i 2 Tb e non ti fidi della concatenazione guest, allora vai con i pRDM con tutti i vantaggi e svantaggi che ne conseguono.
Ciao,
Luca.
16 dischi da 4TB per un file server Windows virtuale??? :smileyshocked:
Sicuro che il tuo cliente non abbia bisogno di un vero NAS per fare questo?
La mia è una provocazione
Non ha bisogno di una NAS ma di un bravo psicologo
Oltretutto, e questo ti farà sorridere, ha uno storage unified...quindi anche la parte nas...Non aggiungere altro ti prego :smileygrin:
Se mi dici che la VM fileserver è ospitata sullo unified storage e che questo è un NetApp, lo psicologo bravo glielo mando io. :smileygrin:
Beh, il problema in entrambi i casi sarebbe poi estrarre i dati dallo storage per farne i backup, sia usando RDM che la parte NAS integrata.
E non è detto che NAS sia per forza la scelta migliore, ho diversi clienti che preferiscono unificare comunque la parte file sulle VM per poter usare appieno Windows nelle varie versioni, così come Active Directory e le varie policy, cosa che non sempre è possibile fare su un NAS.
Bisognerebbe capire i requisiti iniziali come prima cosa, e in base a questi capire se gli RDM sono stati la scelta migliore.
Ciao,
Luca.