Meilleures pratiques pour virtualiser les serveurs sur le SAN?

Très bien, je veux donc commencer à exploiter mon SAN un peu plus que je ne l'ai été, et en même temps, profiter d'ESXi.

Actuellement, j'ai une matrice de lames Dell PowerEdge 1955 connectée à une matrice de stockage EMC AX4-5 FC à boîtier unique. J'utilise essentiellement le SAN comme DAS. J'ai des LUN sur le SAN qui pointent vers des machines physiques spécifiques, et ces machines utilisent les LUN pour quoi que ce soit (principalement des bases de données et des partages Samba / NFS, selon le serveur cible).

J'ai plusieurs serveurs de fichiers physiques, et chacun a une configuration de configuration samba pour servir les partages appropriés. Comme je n'ai jamais réussi à faire fonctionner RHCS, un seul des serveurs de fichiers a les LUN montés à la fois. Dans le cas où un serveur de fichiers meurt, je le clôture manuellement (soit en démontant et en présentant le lecteur, en utilisant l'utilitaire navisphere, ou en coupant l'alimentation via DRAC), puis j'utilise l'utilitaire navisphere pour afficher les LUN présentées sur le concurrent suivant ( après quoi, lancez apache et les autres démons). Tout à la main, en ce moment.

Je me sens un peu comme Ferris Bueller jouant de la clarinette. Jamais eu de leçon!

Quoi qu'il en soit, j'essaie de m'améliorer. Ce que je veux faire, c'est installer ESXi sur les hôtes physiques, puis créer des LUN pour contenir deux images de serveur de fichiers (au cas où l'une serait corrompue / fubar), dont l'une sera active, l'autre sera en veille. Au moins de cette façon, je n'améliore pas l'automatisation (même si je vais bientôt écrire un script pour changer de serveur "actif"), mais j'ai l'impression d'ajouter de la flexibilité, en plus je peux utiliser les hôtes ESXi pour contenir d'autres machines virtuelles, et le matériel ne sera pas gaspillé, comme il l'est maintenant.

Mes questions sont:

1) Dans quelle mesure mon plan est-il stupide?

2) En ce qui concerne l'implémentation réelle, dois-je créer une image vmdk normale sur le LUN, ou dois-je lui donner une partition "brute" (si c'est même possible avec ESXi?)

3) Existe-t-il un "bon" moyen d'utiliser des serveurs de fichiers non groupés?

Votre plan n'est pas fou. Comme d'habitude, il existe plus de quelques façons d'attaquer cela en fonction de ce que vous essayez de réaliser et de la façon de protéger vos données.

Tout d'abord, vous pouvez présenter un LUN brut à une machine virtuelle à l'aide d'un "Raw Device Mapping". Pour faire ça:

• Présentez le LUN à l'hôte ESXi (ou au groupe d'hôtes, si vous allez utiliser le clustering / HA)
• Ajoutez un disque à votre VM, sélectionnez Raw Device Mapping, pointez sur le LUN
• Nouvelle analyse du bus SCSI à l'intérieur de la machine virtuelle
• fdisk, monter et ajouter à fstab, tout comme un disque normal.

À l'envers: rapide à configurer, rapide à utiliser, facile, peut représenter le disque à l'hôte physique si vous avez besoin de V2P sur la piste

Inconvénient: vous risquez de perdre certaines options de snapshot / restauration basées sur VMware, selon que vous utilisez le mode de compatibilité physique ou virtuel

Une autre option consiste à créer VMFS sur le LUN pour créer une banque de données, puis ajouter un disque VMDK à la machine virtuelle vivant sur cette banque de données.

• À l'envers: il est compatible avec Storage vMotion si vous achetez une licence pour l'utiliser. Cela permet une migration à chaud des disques VMDK entre les LUN et même les SAN.

Dans les deux cas, vous êtes dans une position de risque similaire si VMware ou votre machine virtuelle mange le système de fichiers lors d'une panne; l'un n'est pas radicalement meilleur que l'autre, bien que les options de récupération disponibles soient très différentes.

Je ne déploie pas de RDM sauf si je dois le faire; J'ai trouvé qu'ils ne m'achetaient pas beaucoup de flexibilité en tant que VMDK (et j'ai été mordu par des bogues qui les rendaient impraticables lors de l'exécution d'autres opérations de stockage (depuis corrigé - voir la section RDM dans ce lien))

En ce qui concerne votre machine virtuelle, votre meilleur pari pour la flexibilité est de stocker le disque de démarrage de votre serveur de fichiers en tant que VMDK sur le SAN afin que d'autres hôtes puissent le démarrer en cas de défaillance d'un hôte. En utilisant la fonctionnalité HA de VMware, le démarrage de votre machine virtuelle sur un autre hôte est automatique (la machine virtuelle démarrera sur le deuxième hôte comme si l'alimentation avait été coupée; attendez-vous à effectuer les fsck et la magie habituels pour la faire apparaître comme dans le cas d'un serveur normal ). Remarque, HA est une fonctionnalité sous licence.

Pour éviter une panne de machine virtuelle, vous pouvez créer un clone léger de votre serveur de fichiers, contenant le strict minimum requis pour démarrer et faire démarrer SAMBA dans un état configuré et le stocker sur le disque local de chaque hôte, en attendant que vous ajoutiez le lecteur de données à partir de la VM défaillante et allumez-la.

Cela peut ou non vous acheter des options supplémentaires en cas de défaillance du SAN; Dans le meilleur des cas, votre stockage de données nécessitera une réparation fsck ou autre, mais au moins vous n'avez pas à réparer, reconstruire ou configurer la machine virtuelle par-dessus. Le pire des cas, vous avez perdu les données et devez retourner sur bande ... mais vous étiez déjà dans cet état de toute façon.

Je m'en tiendrai aux images vmdk, au cas où vous passeriez à l'utilisation de vmotion à l'avenir, vous ne savez jamais que vous pourriez obtenir un budget pour cela.

Si vos machines ne sont pas en cluster, la meilleure façon de les gérer consiste à répartir la charge aussi uniformément que possible. J'ai 3 2950 non groupés où la charge des vms les plus critiques est autant que possible 1/3 sur chacun. La théorie étant qu'il est peu probable que je perde plus d'une boîte à la fois, donc au moins 2/3 pourront continuer à fonctionner sans être affectés.

D'un point de vue énergétique, il serait probablement plus efficace de charger les machines à près de 100% que vous pouvez et d'avoir d'autres machines éteintes, mais il semble que je mette tous vos œufs dans le même panier.

Je ne me dirais pas expert en la matière, c'est juste ce que je fais.

Salut Matt. Il existe de nombreuses façons de découper une solution lorsque vous utilisez une solution de virtualisation. Tout d'abord, il y a eu de nombreux tests de performances montrant le LUN brut (RDM) par rapport aux performances du VMDK et la différence est généralement négligeable. Certaines choses à savoir avec les RDM: Seules certaines situations de clustering nécessitent l'utilisation de RDM (clustering MS). Les RDM ont une limite de 2 To mais LVM peut être utilisé pour contourner cette limite. Les RDM sont plus difficiles à suivre que de donner un LUN à ESXi à utiliser pour VMFS et d'y mettre des vmdk. Les VMDK (comme mentionné) ont de beaux avantages: svMotion, Snapshots (ne peut pas snapshoter un pRDM).

Si vous utilisez Free ESXi, voici comment je pourrais aborder votre situation. Tout d'abord, toutes les données se trouvent dans des fichiers vmdk sur VMFS LUNS. Configurez 2 VM et utilisez Heartbeat pour le basculement d'IP et de services. Heartbeat décale l'IP du service et peut gérer les scripts pour démonter / monter le LUN de données, le cas échéant. Vous pouvez même créer un script pour certaines CLI à distance VMware pour vous assurer que la machine virtuelle `` en panne '' est mise hors tension pour l'escrime. Le rythme cardiaque se coordonnant directement entre les systèmes, le risque d'accéder à la fois aux données lun / d'exécuter les mêmes services devrait être extrêmement faible. La clé ici est de s'assurer que le montage / démontage du LUN de données et le démarrage / arrêt des services sont gérés par Heartbeat, pas les mécanismes d'initialisation normaux.

Un basculement alternatif peut être effectué via le système de surveillance. Lorsqu'il détecte l'hôte en panne, il peut utiliser VMware Remote CLI pour émettre un arrêt (pour être sûr), puis rallumer le VM de sauvegarde. Dans cette situation, le retour en arrière est assez manuel.

Dans mon "petit" environnement, je n'ai pas vu un VMDK corrompu. Ce que j'ai également réalisé, c'est que si vous avez plus de 2 hôtes ESX (i) ou une douzaine de machines virtuelles, vous voudrez que vCenter vous aide à garder une trace de tout. Certains des packages Essential / Plus ne sont pas trop coûteux compte tenu des avantages.

Matt, tu sais que je n'utilise pas VMware mais j'ai toujours utilisé "RAW" avec Xen. Avec seulement quelques machines virtuelles légèrement chargées, je doute que vous constatiez une grande différence de performances. Mais lorsque vous commencez à entrer de plus en plus d'invités si tous ces invités sont sur le même système de fichiers, vous vous retrouverez avec des problèmes de profondeur de file d'attente. Cela est particulièrement vrai pour le stockage soutenu par NFS. Ce n'est pas tellement que le serveur NFS a des problèmes mais la plupart des implémentations de clients NFS sont nulles.

Je ne connais pas de bon moyen de synchroniser les vmdks si vous recherchez une redondance (échec san). Mais si vous utilisez des périphériques blocs, vous avez toujours la possibilité d'utiliser DRBD pour répliquer uniquement les vms que vous souhaitez / devez répliquer.

Je pense que vous devriez vous demander "Est-ce que je prévois de retourner sur des serveurs physiques"

Si la réponse est peut-être, alors vous devriez peut-être vous en tenir à RDM. ESXi avec RDM exigerait (je pense) que vous achetiez quelque chose pour que votre fibre fonctionne (encore une fois pas sûr à 100% sur esxi).

Nous avions plusieurs machines que je venais de déplacer rapidement des serveurs physiques vers ESX (4.0) en utilisant RDM. J'avais un mélange de machines Linux et Windows (super facile pour les deux plates-formes). Nous avons encore quelques FreeBSD légères (6.0 et plus anciennes) en cours d'exécution sur des serveurs physiques pour lesquels nous ne pouvons pas utiliser RDM car l'ancien noyau FBSD ne le prend pas en charge. Cela a été rapide et m'a obligé à ne rien faire d'autre que de pointer mon LUN puis à installer les outils VMWare. Cerveau mort facile .. pas de convertisseur pas de chichi ...

Une autre chose que vous devriez vous demander est "Quelles fonctionnalités de VMWare dois-je utiliser?"

Selon votre réponse, vous n'aurez peut-être pas d'autre choix que VMDK. Si vous utilisez votre SAN pour des instantanés, et ne vous souciez pas d'utiliser vmware pour cela par exemple ..

Certaines notes que je partagerai avec vous sur ce que nous avons rencontré jusqu'à présent .. Vmotion fonctionne tout aussi bien avec RDM et VMDK, Storage Vmotion, d'autre part, ne fonctionne correctement qu'avec non RDM, et essayer d'utiliser le stockage Vmotion pour passer de RDM à VMDK est nul. utilisez simplement le convertisseur .. La plupart des distributions Linux ont un paquet d'outils vmware open source qui rend l'installation des outils un problème non. L'application de sauvegarde fonctionne vraiment bien et est exempte de vmware, mais ne fait pas autant de choses que nous le souhaiterions. Je recommande fortement de prendre un cours de vmware. Celui que j'ai pris était d'une semaine et valait chaque centime. Le support VMWare est génial .. Si vous obtenez un contrat de support et que vous devez appeler, ils sont de premier ordre .. Je suis frustré de trouver quelqu'un qui peut m'aider (dans de nombreux menus .. ), mais une fois que je les reçois, ils viennent TOUJOURS avec un support rapide et fiable.