Pièges de la virtualisation / leçons apprises

Quels sont les pièges ou les leçons apprises après la conversion du matériel existant en un environnement virtualisé? Y a-t-il quelque chose que vous avez essayé de virtualiser mais que vous ne ferez plus jamais?

TOUJOURS éjecter tous les supports virtuels (CD / DVD / disquette) une fois que vous avez terminé car le non-respect de cette règle arrêtera souvent une vMotion sur ses pistes.

Obtenez votre configuration NTP et DNS correctement, cela vous évitera d'envisager le suicide :)

Vous ne pouvez jamais avoir suffisamment de mémoire ou de stockage.

Assurez-vous que vous disposez d'un accès à distance, sans système d'exploitation, à vos machines telles que le système iLO de HP.

Gardez un référentiel de fichiers OS / App .ISO.

Pas une réponse directe à votre question, mais dans l'espoir que quelqu'un se sauve de s'arracher les cheveux à l'avenir en trouvant cette réponse - les serveurs lames HP ne sont pas livrés avec leur bit 'VT' activé par défaut, vous devez activer dans le BIOS (F9). Sans cet ESX 3.5U4 ne génère pas d'erreur utile, non, il se bloque juste avant l'installation du code :(

Pour répondre à la question posée - pièges liés aux migrations P2V.

Tout d'abord - les migrations P2V fonctionnent très bien pour la plupart. Plus les systèmes sont propres et récents, mieux c'est, mais même avec la migration d'anciens (systèmes NT4), mon taux de réussite après plus d'une centaine de migrations dans divers environnements a été d'environ 90%. Ce sont des systèmes qui ont migré et ont été remis en production le jour (et surtout la nuit) prévu. Je n'ai eu qu'un seul système que nous avons dû inverser après une migration apparemment réussie - une boîte SQL qui nécessitait plus de puissance CPU que la plate-forme ne pourrait jamais en fournir. VMware Converter est bon et gratuit (pour la version non entreprise), Platespin est très bon (mais coûteux).

Cela dit, il y a des choses à éviter.

Clusters MSCS. Vous pouvez les faire fonctionner, mais ce n'est jamais une excellente idée et Microsoft ne vous aidera certainement en aucune façon si vous rencontrez des problèmes plus tard. Construisez plutôt de nouveaux systèmes autonomes.

Grands serveurs SQL - accent sur les grands. Celles-ci auraient dû être signalées en rouge à partir d'un PDV de configuration processeur requise à l'avance, mais ne soyez pas tenté d'en déplacer une si vous n'êtes pas certain que la machine virtuelle cible disposera d'un espace libre suffisant pour le processeur.

Si vous prévoyez de modifier les noms de système ou les adresses IP (ou les deux) pendant la migration, envisagez d'abord de ne pas le faire et si vous n'avez absolument pas le choix, assurez-vous d'avoir des personnes à portée de main qui comprennent comment ces changements peuvent affecter le systèmes en question. Ma pire migration a été un serveur RSA ACE utilisé pour authentifier un VPN situé dans la DMZ où le client a refusé d'écouter mes objections et a insisté pour changer le nom et l'adresse IP pendant la migration.

En rapport avec ce qui précède - si vous avez autre chose qu'un réseau complètement plat, créez des VM de test et assurez-vous à 100% que vos réseaux de VM reproduisent parfaitement ceux physiques à partir desquels vous migrez.

Dans les environnements Windows AD, assurez-vous toujours que vous disposez d'un compte d'administrateur local sur la zone en cours de migration. Et testez-le avant de migrer.

Assurez-vous d'avoir une bonne idée du temps que cela prendra. Les temps de copie P2V varient en fonction de la bande passante réseau disponible (évidemment) mais peuvent également être considérablement affectés par le nombre de fichiers dans chaque volume migré. Ceci est particulièrement un problème avec les systèmes Platespin migrant NT4 * mais affectera toute copie de logiciel P2V au niveau du fichier (qui s'applique généralement si vous choisissez de redimensionner les volumes). Des taux de copie de 70 à 80 Mo par seconde sont possibles avec les réseaux GigE, une source relativement rapide et une bonne configuration cible, mais 20 à 30 Mo / s est plus typique et pour les systèmes NT susmentionnés avec des réseaux de 100 Mo et beaucoup de fichiers, j'ai vu des taux de copie descendre dans la gamme 50kilobyte / sec.

• Idéalement, vous vous en débarrasseriez, mais certaines personnes n'ont pas ce luxe et obtenir un tel système d'exploitation du matériel complètement irréparable sur lequel il fonctionne probablement est presque toujours une bonne idée.

• Avoir une stratégie de sauvegarde solide en place au préalable. Décidez si vous allez sauvegarder la machine virtuelle comme si elle était sur du métal nu, ou si vous allez sauvegarder les disques durs virtuels sur les magasins de données (ou les deux). De manière générale, j'ai constaté que mon empreinte de sauvegarde requise a augmenté considérablement au début, alors préparez-vous à un pic initial où vous pourriez sauvegarder à la fois une ancienne machine physique et une nouvelle machine virtuelle avant de résoudre tous les problèmes.
• L'étalement des VM est également quelque chose à surveiller. Une fois que la virtualisation commence à décoller, l'envie de tout déplacer vers la VM devient grande. Bien que cela puisse fonctionner, vous n'avez probablement pas commandé exactement assez de matériel dès le départ.
• Je pense qu'il y a des machines qui ne peuvent pas être converties, et d'autres machines qui ne devraient probablement pas être converties. Bien qu'il soit agréable de pouvoir prendre une machine physique de 10 ans et de la cloner sur une machine virtuelle, avec des verrues et tout, il y a certainement des scénarios où vous feriez mieux de construire un
  système d'exploitation propre et de migrer des objets à partir de la machine physique. Parfois, il vaut mieux ne pas convertir sur les toiles d'araignées.
• Soyez prêt à utiliser de nombreux ports réseau. Si vous avez des systèmes qui s'exécutent sur différents VLANS, alors que des ports uniques peuvent être partagés, vous souhaiterez probablement avoir des ports individuels pour vos VLAN alimentant votre vSwitch. Si vous souhaitez une redondance et que vous utilisez iSCSI, vous pouvez consulter un grand nombre de cartes réseau.

D'après mon expérience, faites très attention à votre support de stockage. Nous sommes allés avec un SAN iSCSI qui s'est avéré ne prendre en charge que les connexions 100 Mbits. L'exécution d'une VM sur le système n'était pas mauvaise, deux était moins adéquate ... et au moment où nous avons atteint notre objectif de 8 VM, elles étaient horribles.

Ma leçon personnelle apprise: vérifiez les IOPS notées et lisez plus d'avis sur un produit qui se rapportent à la façon dont vous avez l'intention d'utiliser le périphérique de stockage

Une autre chose pratique que j'ai apprise ... La création d'une image disque de «sauvegarde» après une installation de base et un durcissement accélérera la construction de tout autre système et est une chose très pratique à conserver.

Essayez de ne pas exécuter les serveurs de base de données de production dans un environnement virtuel. Les frais généraux pour les E / S sont inacceptables. Nous avons eu d'énormes problèmes lorsque notre DBA a permis à notre serveur MSSQL principal de devenir virtualisé. Les requêtes prenaient des milliers de millisecondes pour s'exécuter. Lorsque nous les avons convaincus de le replacer dans une boîte dédiée, le débit et la vitesse ont augmenté de 10 000%.

Utilisez un réseau redondant pour le trafic vmotion / vmkernel. Vous ne voulez pas que les machines virtuelles s'arrêtent simplement parce qu'un commutateur a redémarré.

Oh, et laissez un serveur DC / DNS / DHCP hors de la virtualisation. Vos utilisateurs vous détesteront moins si vous obtenez un crash SAN majeur.

Si vous n'en avez pas déjà - Ayez une sauvegarde complète de la machine physique avant la migration. Une image est probablement la meilleure ou et une restauration ASR / système ou tout ce qui vous donne un instantané complet du système, au lieu de la sauvegarde de contenu habituelle que la plupart des machines ont.

Les outils P2V peuvent se retourner contre vous de manière inattendue, ruinant la machine physique (j'ai eu un convertisseur VMWare tuer une machine que j'essayais de P2V une fois, heureusement, c'était juste une migration de test). Soyez prêt à devoir restaurer le système à partir de zéro. Oui, c'est peut-être une chance de 1000 pour une, mais voulez-vous être celle-là?

VMWare Converter crée des machines virtuelles qui démarrent à partir de scsi. Les machines virtuelles MS ne peuvent pas démarrer à partir de scsi. [edit - apparemment la version 4 du convertisseur vous permet maintenant de spécifier SCSI ou IDE, j'adore ces gars]

Si vous souhaitez virtualiser une machine physique non ACPI , achetez un logiciel à cet effet. (sauf si vous avez quelques semaines pour un voyage passionnant de découverte!)

En outre, VMWare Converter s'attaquera aux travaux au cours desquels MS SCVMM lèvera les mains au désespoir.

Apportez beaucoup de RAM.

Ne faites rien tant que les outils de virtualisation (que ce soit VMWare ou MS) ne sont pas installés.

Si vous prévoyez de le déplacer vers une autre plate-forme / version, désinstallez les outils susmentionnés.

Faites attention à vos limites CPU. Le P2V de 2 fenêtres CPU 2000 m'a appris qu'un seul est pris en charge.

• 2000 - 1 noyau
• 2003-2 cœurs
• 2008-4 cœurs

Si vous prévoyez d'utiliser SAN pour stocker vos images de machine virtuelle, assurez-vous d'étiqueter vos appareils et hébergez TRÈS CLAIREMENT. La suppression des mappages d'hôte à disque sur le SAN fait des choses terribles s'ils sont toujours utilisés par les machines virtuelles.

Microsoft ne prend pas en charge Exchange 2003 exécuté dans VMware (du moins, c'était la réponse officielle). Avec beaucoup de torsions de bras, nous avons pu obtenir un soutien officieux de leur part, mais cela a provoqué des maux de tête supplémentaires dans une crise déjà stressante.

Beaucoup d'entre eux sont spécifiques à VMware:

• S'il fonctionne mal en tant que machine physique, il fonctionnera mal en tant que machine virtuelle.
• Le Cold Clone ISO est votre ami
• Déchets dedans, Déchets dehors. Si vous utilisez des systèmes P2V plus anciens, ils peuvent laisser une empreinte inutile. Voir Affichage du matériel fantôme après P2V , étapes requises après P2V et p2v-scripts.pdf
• Assurez-vous que vos systèmes d'exploitation invités sont pris en charge par votre logiciel P2V.
• Windows 2000 peut être pénible pour les pilotes SCSI

Gêne stupide avec VMware: différentes versions de VMware utilisent différents pilotes SCSI pour leurs périphériques de disque virtuel. Il est tout à fait possible de perdre 2 heures avant d'envisager cette option.

Eh bien, jusqu'à présent, je n'ai pas d'histoires d'horreur sur moi-même faisant la virtualisation. Cependant, quelques notes cependant.

1. Planifiez soigneusement dans les détails à venir. Faites surtout des devoirs qui ne peuvent pas être virtualisés.

2. Si le fournisseur de l'application exécutée sur votre serveur ne prend pas en charge l'environnement virtuel, attendez qu'il le prenne en charge.

3. Implémentez avec un SAN comme stockage stockant toutes les images de machine virtuelle.

4. Exécutez ESX ou ESX (i) ou Hyper-V pour obtenir la plupart des performances.

Peut-être plus mais c'est tout pour l'instant. :)

[mise à jour] en voici une autre. Appliquez le dernier micrologiciel au serveur hôte. J'en ai eu un que je n'ai pas fait, ce qui m'a donné un écran violet une fois quelques jours et a complètement bloqué le serveur.

L'impact de la virtualisation représente environ 5% des performances des frais généraux. Mesurez la consommation de ressources sur l'environnement existant pour déterminer si votre environnement de virtualisation peut supporter cette charge.

Avant de mettre en ligne votre solution de virtualisation:

• Vérifiez que vous savez comment sauvegarder ET restaurer une machine virtuelle. L'utilisation de l'instantané peut ne pas être prise en charge, comme sur Windows DC
• Demandez à votre éditeur si sa solution est prise en charge dans VM. Microsoft maintient la liste de leurs logiciels pris en charge dans la machine virtuelle: KB 897613
• Comme il est très facile de créer une machine virtuelle, les gens ont tendance à générer une nouvelle machine virtuelle pour chaque demande. Ensuite, vous avez plus de VM que votre solution ne devrait en prendre en charge.

Y a-t-il quelque chose que vous avez essayé de virtualiser mais que vous ne ferez plus jamais?

Je ne dirais pas que je ne vais pas réessayer, mais la virtualisation en couches n'est pas agréable à gérer.

Par couches, je veux dire exécuter xen ou esx sur du matériel virtualisé tel que Egenera, HP Virtual Connect ou Cisco UCS. Cela semble être une bonne idée, mais le débogage peut prendre beaucoup de temps.

Dans VMWare, sachez où se terminent les instantanés. Nous avions le nôtre configuré pour se retrouver dans le LUN sur le SAN avec les fichiers VM eux-mêmes. Un technicien pratiquait le processus d'instantané sur une LUN presque pleine. Plus tard, il a redémarré la machine virtuelle pour une raison quelconque, et les fichiers journaux ont empêché la machine virtuelle de démarrer. C'est un peu de chance qui nous a conduit à ce que le LUN soit plein comme cause.

Si vous optez pour un disque dur virtuel à expansion dynamique, assurez-vous que vous allez assez grand. Si vous optez pour 100 Go et que vous n'utilisez que 20 ... pas de problème. Cependant, si vous êtes allé avec 25, vous avez du travail devant vous.