VMware VMFS5 et dimensionnement des LUN - plusieurs petites banques de données ou 1 grande banque de données?

Avec VMFS5 n'ayant plus la limite de 2 To pour un volume VMFS, je réfléchis au scénario qui serait le plus avantageux dans l'ensemble: -

• Moins de LUN de plus grande taille, ou
• Plus de LUN de plus petite taille.

Dans mon cas, j'ai une nouvelle baie de stockage de 24 disques avec des disques de 600 Go. J'utiliserai RAID10, donc environ 7,2 To, et j'essaierai de décider s'il faut utiliser 1 grand magasin de données de 7 To ou plusieurs magasins de 1 To chacun.

Quels sont les avantages et les inconvénients de chaque approche?

Mise à jour : Bien sûr, j'ai négligé d'inclure les disques de rechange dans mon calcul, ce sera donc un peu moins de 7,2 To, mais l'idée générale est la même. :-)

Mise à jour 2 : il y a 60 machines virtuelles et 3 hôtes. Aucune de nos VM n'est particulièrement gourmande en E / S. La plupart d'entre eux sont des serveurs Web / d'applications, ainsi que des éléments comme la surveillance (munin / nagios), 2 contrôleurs de domaine Windows avec une charge minimale, etc. Les serveurs de base de données sont rarement virtualisés, sauf s'ils ont des exigences d'E / S TRÈS faibles. En ce moment, je pense que le seul serveur de base de données virtuel que nous avons est une boîte MSSQL et la base de données sur cette boîte est <1 Go.

Mise à jour 3 : quelques informations supplémentaires sur la matrice et la connectivité FC. La baie est un IBM DS3524, 2 contrôleurs avec 2 Go de cache chacun. 4x ports FC 8 Gbit par contrôleur. Chaque hôte ESXi dispose de 2 HBA FC 4Gbit.

Vous n'avez pas spécifié le nombre de machines virtuelles dont vous disposez ou ce qu'elles vont faire. Même sans ces informations, j'éviterais d'en créer un pour des raisons de taille / performance, de conflit et de flexibilité.

Je suppose que vous allez virtualiser des serveurs, pas des bureaux, d'accord? Ensuite, je vais supposer que vous allez utiliser plusieurs serveurs ESX / ESXi pour accéder à votre stockage et les faire gérer par vCenter Server.

Lorsque vous décidez de la taille des LUN et du nombre de VMFS, vous équilibrez plusieurs facteurs: performances, flexibilité de configuration et utilisation des ressources, tout en étant lié par la configuration maximale prise en charge de votre infrastructure.

Vous pouvez obtenir les meilleures performances avec 1 mappage VM à 1 LUN / VMFS. Il n'y a pas de concurrence entre les machines sur le même VMFS, pas de conflit de verrouillage, chaque charge est séparée et tout va bien. Le problème est que vous allez gérer une quantité impie de LUN, que vous pouvez atteindre les limites maximales prises en charge, faire face à des maux de tête avec le redimensionnement et la migration VMFS, avoir des ressources sous-utilisées (cet espace libre d'un point de pourcentage sur VMFS s'ajoute) et créer généralement une chose qui n'est pas agréable à gérer.

L'autre extrême est un grand VMFS désigné pour tout héberger. Vous obtiendrez la meilleure utilisation des ressources de cette façon, il n'y aura aucun problème à décider quoi déployer où et les problèmes avec VMFS X étant un point chaud, tandis que VMFS Y est inactif. Le coût sera la performance agrégée. Pourquoi? À cause du verrouillage. Lorsqu'un ESX écrit sur un VMFS donné, d'autres sont verrouillés pendant le temps nécessaire pour terminer les E / S et doivent réessayer. Cela coûte des performances. En dehors des terrains de jeux / des environnements de test et de développement, il s'agit d'une mauvaise approche de la configuration du stockage.

La pratique acceptée consiste à créer des banques de données suffisamment grandes pour héberger un certain nombre de machines virtuelles et à diviser l'espace de stockage disponible en blocs de taille appropriée. Le nombre de machines virtuelles dépend des machines virtuelles. Vous pouvez souhaiter une ou plusieurs bases de données de production critiques sur un VMFS, mais autoriser trois ou quatre douzaines de machines de test et de développement sur la même banque de données. Le nombre de machines virtuelles par magasin de données dépend également de votre matériel (taille du disque, tr / min, cache des contrôleurs, etc.) et des modèles d'accès (pour tout niveau de performance donné, vous pouvez héberger beaucoup plus de serveurs Web sur le même VMFS que de serveurs de messagerie).

Les banques de données plus petites ont également un autre avantage: elles vous empêchent physiquement de surcharger trop de machines virtuelles par banque de données. Aucune pression de gestion ne peut contenir un téraoctet supplémentaire de disques virtuels sur un stockage d'un demi-téraoctet (au moins jusqu'à ce qu'ils entendent parler de l'allocation dynamique et de la déduplication).

Une dernière chose: lors de la création de ces banques de données, normalisez sur une seule taille de bloc. Cela simplifie beaucoup de choses plus tard, lorsque vous voulez faire quelque chose dans les banques de données et voir des erreurs laides "non compatibles".

Mise à jour : DS3k aura des contrôleurs actifs / passifs (c.-à-d. Que n'importe quel LUN donné peut être servi par le contrôleur A ou B, l'accès au LUN via le contrôleur non propriétaire entraîne une pénalité de performance), donc il sera payant d'avoir un nombre pair de LUN , répartis également entre les contrôleurs.

Je pourrais imaginer commencer avec 15 VM / LUN avec de l'espace pour atteindre 20 environ.

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

Je vous suggère de jeter un œil ici http://www.yellow-bricks.com/2011/07/29/vmfs-5-lun-sizing/ car cela peut vous aider à considérer vos IOPS prévus et combien de LUN pourraient convenir. Cela dit, si vous deviez faire preuve de prudence, certaines personnes conseilleraient d'avoir plusieurs LUN (si ma correction à une réponse précédente est approuvée, voir mes commentaires concernant les files d'attente LUN IO du côté de la baie). J'ai tendance à être d'accord, mais j'irais plus loin pour ensuite les étendre ensemble en un seul / quelques volumes VMFS (ne croyez pas le FUD à propos des étendues et des autres limites VMFS http://virtualgeek.typepad.com/virtual_geek/2009/03 /vmfs-best-practices-and-counter-fud.html). Cela aura l'avantage de gérer une ou plusieurs banques de données au sein de vSphere et, puisque vSphere équilibre automatiquement les machines virtuelles sur les extensions disponibles en commençant par le premier bloc de chaque extension, l'avantage en termes de performances répartit votre IO sur plusieurs LUN.

Autre chose à considérer ... Vous dites qu'aucune des machines virtuelles n'est particulièrement intensive en E / S. Compte tenu de cela, vous voudrez peut-être envisager une combinaison de RAID5 et RAID10, pour obtenir le meilleur des deux mondes (espace et vitesse).

De plus, si vos machines virtuelles sont configurées avec plusieurs VMDK, avec les modèles d'ES du système d'exploitation et des applications répartis sur ces disques virtuels (c.-à-d. OS, Web, DB, journaux, etc. chacun sur un VMDK distinct), vous pouvez alors localiser chaque VMDK sur un magasin de données différent pour correspondre aux capacités d'E / S de ce LUN physique (par exemple, OS sur RAID5, journaux sur RAID10). Il s'agit de conserver des modèles d'E / S similaires pour tirer parti du comportement mécanique des disques sous-jacents afin que, par exemple, les écritures de journal dans une VM n'affectent pas vos taux de lecture Web dans une autre VM.

Pour info ... vous pouvez virtualiser avec succès les serveurs de base de données, il vous suffit d'analyser les modèles d'E / S et les taux d'IOPS et de cibler cette E / S sur un LUN approprié; tout en étant conscient des modèles d'E / S et des IOPS que ce LUN fait déjà. C'est pourquoi beaucoup admins blâme virtualiseation pour la mauvaise performance de DB ... cos ils ne calculent soigneusement l'IO / IOPS que plusieurs serveurs produiraient quand ils les ont mis sur un LUN partagé (ie. La faute il admins, 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 des LUN plus petits. Cela dit, vous pouvez créer un LUN couvrant une banque de données assez facilement. L'inconvénient des banques de données VMWare plus grandes (et moins nombreuses) est, pour autant que je sache, que vous pouvez rencontrer certaines limites sur le nombre de machines virtuelles pouvant être activées simultanément.

Une autre considération est la performance du contrôleur. Je ne connais pas votre SAN en particulier, mais la plupart sinon tous les SAN exigeaient qu'un LUN soit la propriété d'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 à voir.

Si vous aviez deux LUN, mais que l'un était beaucoup plus occupé que l'autre, vous utiliseriez les deux contrôleurs mais pas de manière égale. Lorsque vous ajoutez des LUN supplémentaires, les contrôleurs partagent la charge de travail de manière plus égale.

Des conseils spécifiques pour vous:

Vos machines virtuelles sont toutes relativement les mêmes en termes d'exigences de performances. Je créerais deux LUN, un par contrôleur. Commencez à placer des machines virtuelles sur le premier LUN et mesurez votre latence d'E / S et la profondeur de la file d'attente au fil du temps au fur et à mesure que les machines virtuelles s'installent. N'utilisez pas encore le deuxième LUN. Continuez à remplir le LUN 1. Vous atteindrez un point où vous commencerez à voir des indicateurs de performances indiquant que le LUN est plein, ou vous aurez migré la moitié de vos machines virtuelles vers ce LUN, et vous conserverez toujours les performances.

Si vous constatez des problèmes de performances, je supprimerais 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. Allez à LUN 3 si nécessaire ... est-ce que cela a du sens? L'idée est d'atteindre une densité maximale de VM sur un LUN donné avec une surcharge d'environ 30% pour la salle de fudge.

Je ferais également une paire de LUN «hautes performances» pour toutes les machines virtuelles à fort impact. Encore une fois, un par contrôleur pour partager la charge de travail.

Sur la base de vos explications ci-dessus, vous devriez aller bien avec 1 magasin de données. 60 vm sur 3 hôtes n'est pas si mal (20: 1). Je vous recommanderais cependant de mettre à niveau le HBA vers 8 Go si cela est financièrement possible sur au moins un hôte à condition que votre commutateur fibre soit un commutateur 8 Go au minimum.

Cela étant dit, je ferais au moins 2 sinon 3 banques de données sur la baie. 1 banque de données par hôte, tous les serveurs accédant aux autres pour vMotion. Je ne connais pas grand-chose à la baie IBM; avec EMC, je créerais un seul groupe RAID10 avec 3 LUN pour chaque magasin de données. Avec cette configuration, l'hôte avec les adaptateurs de bus hôte 8 Go serait idéal pour vos systèmes d'E / S supérieurs.

Vous pouvez faire 1 magasin de données / serveur, et il y a des cas où je le fais moi-même, mais je ne le fais qu'avec la réplication SAN sur des serveurs spéciaux. La gestion de 87 banques de données différentes sur 9 serveurs pour vMotion devient confuse lorsque vous la configurez! La majorité de mes VM se trouvent dans des banques de données partagées avec 5 à 10 serveurs, selon l'espace dont ils ont besoin.

Une dernière note. Si vous avez n'importe quel type de serveurs dans une paire / cluster de basculement ou une charge équilibrée, vous allez les vouloir dans différentes banques de données. Vous ne voulez pas que la banque de données tombe en panne, puis ne vous retrouviez avec aucun serveur. Certes, si vous perdez la baie, vous avez tout perdu, mais c'est pourquoi nous sauvegardons, non?