Nombre de LUN pour une infrastructure virtualiser ?

Nombre de LUN pour une infrastructure virtualiser ? - Stockage - Systèmes & Réseaux Pro

Marsh Posté le 05-12-2011 à 21:18:38    

bonjour,
on a un projet de virtualisation
nous avons un SAN branché à deux hotes.
Le SAN dispose de 5to utile en SAS.  
Dans les versions antérieure de vmware 5 les lun ne devaient pas dépasser les 2TO.
J'ai 20 machines à virtualiser, qui devraient utiliser environ 2To.
J'aimerai savoir si c'est nécessaire de faire plusieurs LUN ou alors qu'un LUN.
J'aimerai trouver des argument pour et contre et des idées pour organiser mes VM.
1 - si plus de place dans un, arrêter une VM pour la déplacer de datastore serait stupide
...
 
d'autre idées par retour d’expérience ?
 
 


---------------
je veux tout, tout de suite, et gratuitement ! miladiou !
Reply

Marsh Posté le 05-12-2011 à 21:18:38   

Reply

Marsh Posté le 05-12-2011 à 21:37:52    

la réponse est : "ça dépend"
VMware recommande de mettre 20 à 25 VM par LUN
En réalité il faut réussir à éclater tes VM de façon à ce que l'utilisation de tes disques soient équilibrés entre les LUN, mais cela dépend de ton SAN, de tes RAID Group et de la façon dont tu tailles tes LUN dans tes RAID groups...
 
A l'époque où je travaillais sous VMware, j'éclatait en gamelle de 1To et j'équilibrait mes VM sur ces LUN de 1To
Ensuite si un dimensionnement a été mal fait, ou si ça commence à tirer sur une LUN en particulier, un petit coup de Storage vMotion pour déplacer à chaud les VM entre datastores me sauvait la mise :)

Reply

Marsh Posté le 06-12-2011 à 08:45:50    

oui mais pourquoi ne pas mettre tout dans un LUN ?
je n'arrive pas a faire deux groupes de VM logique ... donc j'aurai preferer tout mettre dans un lun


---------------
je veux tout, tout de suite, et gratuitement ! miladiou !
Reply

Marsh Posté le 06-12-2011 à 10:11:19    

ouais t'as pas tout bien lu : ca dépend de ton stockage et de la manière dont tu veux organiser et sécuriser
 
vu comment tu insistes sur ce LUN unique tu dois avoir les mêmes disques avec 1 seul raid group
... à moins que tu possèdes un san avec certaines fonctionnalités genre agrégat de LUN, LUN éclatée sur plusieurs raid group avec équilibrage de charges, etc.

Reply

Marsh Posté le 06-12-2011 à 10:47:55    

je pense qu'il y a tout ça.
 EMC VNX 5300
donc ça serait plutot pour les performances creer different LUN
je met 12disques SAS en RAID5 dans un le lun 1 avec un hotspear et un autre lun avec les 12 disque en raid 5 et un hot spear ?


---------------
je veux tout, tout de suite, et gratuitement ! miladiou !
Reply

Marsh Posté le 06-12-2011 à 11:07:12    

heu jamais bossé sur un VNX, mais à l'époque où je bossais sur du Clariion il y avait des préco EMC sur le nbre de disques par RAID Group
 
et l'agrégat de LUN, j'espère que ca a évolué parce que j'avais eu de sacré problèmes de perf. avec
 
et tu n'as pas que les performances, mais également la sécurité : perdre 1 LUN c'est pas joyeux, mais c'est pire encore quand tu perd ton unique LUN
 
de tte facon tu peux déplacer à chaud tes VM au sein des RAID group avec le LUN migration d'EMC ou alors avec un Storage vMotion de VMware

Reply

Marsh Posté le 06-12-2011 à 11:18:00    

le storage vmtion ce n'est pas économiquement trés acceptable :)
il faut une version entreprise ou entreprise +
je n'ai qu'une version essential + vmware
Sinon le SAN sera répliqué sur un autre site avec l'outil recoverpoint de EMC..
mais je connais pas encore cet outil.
Que veux tu dire par l'agrégat de LUN, je ne comprend pas ?
pourquoi je perdrai un LUN ?


Message édité par skoizer le 06-12-2011 à 11:44:03

---------------
je veux tout, tout de suite, et gratuitement ! miladiou !
Reply

Marsh Posté le 07-12-2011 à 05:21:38    

skoizer a écrit :

oui mais pourquoi ne pas mettre tout dans un LUN ?
je n'arrive pas a faire deux groupes de VM logique ... donc j'aurai preferer tout mettre dans un lun


 
 
Pour des raisons de sauvegarde notamment. C'est beaucoup plus facile de sauvegarder/restaurer 4 LUN de 512 Go que 1 de 2 To.

Reply

Marsh Posté le 07-12-2011 à 09:17:44    

oui mais dans la gestion courante c'est plus facile d'avoir qu'un lun, pour mutualiser l'espace vide !


---------------
je veux tout, tout de suite, et gratuitement ! miladiou !
Reply

Marsh Posté le 07-12-2011 à 09:37:41    

ce que tu gagnes d'un côté tu le perds de l'autre
après tu décides en connaissance de cause

Reply

Marsh Posté le 07-12-2011 à 09:37:41   

Reply

Marsh Posté le 07-12-2011 à 10:38:43    

si on perd un LUN on a un san en miroir avec des serveurs pour le PRA.
donc ce cas de figure peut être facilement geré.


---------------
je veux tout, tout de suite, et gratuitement ! miladiou !
Reply

Marsh Posté le 07-12-2011 à 14:57:40    

donc pas la peine de te convaincre et d'avancer des arguments, car ton choix est déjà fait :) tu vas partir sur 1 LUN pour simplifier la gestion
 
saches juste qu'on t'aura mis en garde :
- sur la répartition de tes LUN sur tes RAID Group. D'accord tu n'as qu'1 seul RAID Group, mais dans 2 ans ?
Pour continuer dans ta logique, tu devras soit étendre ton RAID group pour étendre ta LUN, soit faire des meta-lun (donc potentiel perte de perf)
- la sécurité. OK t'as un site de repli, mais ce serait bien dommage de déclencher le PRA au complet pour la perte de 2 disques simultanées
 
bref "ne pas mettre tous ses oeufs dans le même panier"

Reply

Marsh Posté le 16-12-2011 à 18:17:05    

skoizer a écrit :

oui mais pourquoi ne pas mettre tout dans un LUN ?
je n'arrive pas a faire deux groupes de VM logique ... donc j'aurai preferer tout mettre dans un lun


 
Perte de performances, sauvegardes, administration...
Il ne faut pas tout mettre dans une LUN, c'est déconseillé dans les best practices.
 
Il faut privilégier des Lun de 500-800 Go pour l'OS des VM (10-20 par Lun), et des Lun pour les données. Si tes données dépassent 2 To, utiliser RDM ou utiliser un mappage de plusieurs vmdk.


---------------
D3/Hots/Hs Doc#2847
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed