VMware VMFS5 et dimensionnement LUN - plusieurs petits datastores ou un grand datastore ?

Vous n'avez pas précisé combien de machines virtuelles vous avez ou ce qu'elles vont faire. Même sans cette information, je recommanderais d'éviter de créer un seul grand LUN pour des raisons de taille de bloc/performance, de contention et de flexibilité.

La réponse courte à votre question est la suivante : tout dépend de quels sont vos modèles d'E-S, et cela sera unique à votre environnement.

Je vous suggère de jeter un coup d'oeil ici http://www.yellow-bricks.com/2011/07/29/vmfs-5-lun-sizing/ car cela pourrait vous aider à considérer vos E/S anticipées et combien de LUNS pourraient être appropriées. Cela dit, si vous préférez jouer la prudence, certaines personnes conseilleraient d'avoir de nombreux LUNS (Si ma correction à une réponse précédente est approuvée, consultez mes commentaires sur les files d'attente IO LUN du côté du tableau). Je suis plutôt d'accord, mais j'irais plus loin en les étendant ensemble dans un ou quelques volumes VMFS (ne croyez pas la désinformation à propos des extensions, et d'autres limites VMFS http://virtualgeek.typepad.com/virtual_geek/2009/03/vmfs-best-practices-and-counter-fud.html). Cela vous permettra de gérer un ou quelques datastores à l'intérieur de vSphere et, puisque vSphere équilibre automatiquement les machines virtuelles sur les extensions disponibles en commençant par le premier bloc de chaque extension, le bénéfice de performance à répartir votre E/S sur plusieurs LUNs.

Autre chose à considérer... Vous dites que aucune des VMs n'est particulièrement intensive en E/S. Compte tenu de cela, vous pourriez envisager une combinaison de RAID5 et RAID10, pour avoir le meilleur des deux mondes (espace et vitesse).

De plus, si vous avez configuré vos VMs avec plusieurs VMDKs, avec les modèles E/S du système d'exploitation et des applications répartis sur ces disques virtuels (c'est-à-dire, système d'exploitation, web, base de données, logs, etc. chacun sur un VMDK séparé), vous pouvez alors placer chaque VMDK sur un datastore différent pour correspondre aux capacités E/S de cette LUN physique (par exemple, système d'exploitation sur RAID5, Logs sur RAID10). Il s'agit de regrouper des modèles E/S similaires ensemble pour profiter du comportement mécanique des disques sous-jacents afin que, par exemple, les écritures de logs dans une VM n'impactent pas les taux de lecture web dans une autre VM.

FYI... vous pouvez virtualiser avec succès des serveurs de base de données, vous devez simplement analyser les modèles E/S et les taux d'IOPS et cibler ces E/S vers une LUN appropriée ; tout en étant conscient des modèles E/S et des IOPS que cette LUN effectue déjà. C'est pourquoi de nombreux administrateurs blâment la virtualisation pour une mauvaise performance des bases de données... car ils n'ont pas calculé soigneusement les E/S/IOPS que de multiples serveurs généreraient lorsqu'ils les ont placés sur une LUN partagée (c'est la faute des administrateurs, pas la faute de la virtualisation).

Chaque volume (LUN) a sa propre profondeur de file d'attente, donc pour éviter les conflits d'E/S, de nombreuses implémentations utilisent plusieurs petits LUNs. Cela dit, vous pouvez facilement faire en sorte qu'un datastore couvre plusieurs LUNs. L'inconvénient des datastores VMWare plus grands (et moins nombreux) est, autant que je sache, que vous pouvez rencontrer des limites sur le nombre de VM qui pourraient être en cours simultanément.

Une autre considération est la performance du contrôleur. Je ne connais pas votre SAN spécifiquement, mais la plupart, sinon tous les SAN, exigent qu'un LUN soit détenu par un seul contrôleur à la fois. Vous voulez avoir suffisamment de LUN sur le système pour pouvoir équilibrer votre charge de travail entre les contrôleurs.

Par exemple, si vous n'aviez qu'un seul LUN, vous n'utiliseriez qu'un seul contrôleur actif à la fois. L'autre resterait inactif car il n'aurait rien à faire.

Si vous aviez deux LUN, mais que l'un était beaucoup plus occupé que l'autre, vous utiliseriez les deux contrôleurs mais pas également. En ajoutant plus de LUN, les contrôleurs partagent la charge de travail de manière plus équilibrée.

Conseils spécifiques pour vous:

Vos machines virtuelles ont toutes des exigences de performance relativement similaires. Je créerais deux LUN, un par contrôleur. Commencez à placer les machines virtuelles sur le premier LUN, et mesurez votre latence E/S et la profondeur de la file d'attente au fil du temps à mesure que les machines virtuelles se stabilisent. N'utilisez pas encore le second LUN. Continuez à remplir le LUN 1. Vous atteindrez soit un point où vous commencerez à voir des indicateurs de performance montrant que le LUN est plein, soit vous aurez migré la moitié de vos machines virtuelles vers ce LUN, tout en maintenant les performances.

Si vous rencontrez des problèmes de performance, je retirerais 30% des machines virtuelles du LUN 1 et les déplacerais vers le LUN 2. Ensuite, commencez à remplir le LUN 2 de la même manière. Passez au LUN 3 si nécessaire... Est-ce clair? L'idée est d'atteindre une densité maximale de machines virtuelles sur un LUN donné avec une marge de sécurité d'environ 30%.

Je créerais également une paire de LUN "haute performance" pour les machines virtuelles les plus gourmandes en ressources. Encore une fois, un par contrôleur pour partager la charge de travail.

En fonction de vos explications ci-dessus, vous devriez vous en sortir avec 1 datastore. 60 vm sur 3 hôtes ce n'est pas si mal (20:1). Je vous recommanderais toutefois de mettre à niveau les HBA en 8 Gb si cela est financièrement possible sur au moins un hôte, à condition que votre commutateur fibre soit un commutateur 8 Gb au minimum.

Cela étant dit, je créerais au moins 2, voire 3 datastores sur le tableau. 1 datastore par hôte, avec tous les serveurs accédant aux autres pour vMotion. Je ne connais pas très bien le tableau IBM ; avec EMC, je créerai un seul groupe RAID10 avec 3 LUN pour chaque datastore. Avec cette configuration, l'hôte doté des HBA 8 Gb serait idéal pour vos systèmes à volume élevé d'I/O.

Vous pouvez également faire 1 datastore/serveur, et il y a des cas où je le fais moi-même, mais je le fais uniquement avec une réplication SAN sur des serveurs spéciaux. Gérer 87 datastores différents sur 9 serveurs pour vMotion devient compliqué lors de la configuration ! La majorité de mes vm se trouve dans des datastores partagés avec 5 à 10 serveurs en fonction de l'espace dont ils ont besoin.

Une dernière remarque. Si vous avez des serveurs en paire de basculement/cluster ou en équilibrage de charge, vous voudrez les mettre dans des datastores différents. Vous ne voulez pas que le datastore tombe en panne, et vous retrouver sans serveurs. Il est vrai que si vous perdez le tableau, vous avez tout perdu, mais c'est pourquoi nous faisons des sauvegardes, n'est-ce pas ?