Blog d'un Psychopathe

Tweakons cette saloperie de vCenter

Tue, 27 Jul 2010 10:41:23 +0200

Après une migration, réalisée avec succès - on oubliera la petite heure passée en mode Fin du Monde quand l'AD du clent s'est mis à déconner suite à un truc qui n'a rien à voir avec cette migration mais que Murphy... -, de vCenter, il faut remettre en place les petits paramétrages non officiels qui vous facilitent la vie en améliorant les performances et en évitant des incidents.

1- Ajouter une dépendance sur le démarrage du service VMware VirtualCenter Server
Si comme moi vous utilisez, pour une petite infrastructure, SQL Server Express livré de base avec vCenter, vous pouvez constater que, de temps en temps, quand vous redémarrez votre serveur, le service VMware VirtualCenter Server se plante au démarrage car il démarre plus vite que le service SQL Server.
C'est très con.
Donc, le but du jeu, c'est de faire en sorte que le service VMware VirtualCenter Server ne démarre que quand la partie SQL Server est fonctionnelle. Donc créer une dépendance.
Bien évidement, chez Windows, créer une dépendance sur le démarrage d'un service ne se fait pas simplement. Naaaan. Ce serait trop sympa.
Il faut donc mettre les mains dans le camboui et dans la base de registres.
Il faut donc localiser le répertoire suivant : HKLM\SYSTEM\CurrentControlSet\Services. Puis, il faut trouver l'entrée vpxd, qui est l'entrée pour le service VMware VirtualCenter Server. Dans vpxd, localisez la clé DependOnService qui est du type REG_MULTI_SZ. Si vous éditez cette clé, vous devez normalement voir qu'elle contient déja deux entrées : ProtectedStorage et lanmanworkstation. Il faut alors ajouter une troisième ligne représentant le service SQL Server. Dans mon système, l'entrée pour SQL Server s'appelle MSSQL$SQLEXP_VIM. Vous êtes censés trouver cette entrée aussi dans HKLM\SYSTEM\CurrentControlSet\Services. Surtout ne pas rajouter une ligne vide, vous feriez planter le service. Une fois l'entrée concernant le service SQL Server ajoutée, vous pouvez fermer la base de registres et vérifier directement que le service VMware VirtualCenter Server a bien une nouvelle dépendance.

2- Augmenter la taille du journal des transactions de la base SQL
Il arrive de temps en temps qu'il y ait un problème avec le journal de transaction de la base SQL Server. - ici dans sa version Express. - Si ce journal est plein, votre service vCenter va planter. Vous pourrez alors voir dans les logs vCenter un message assez explicite. Les logs se trouvent - sur un serveur Windows 2008 R2 - dans C:\Utilisateurs\All Users\VMware\VMware VirtualCenter\Logs. Ce sont les fichiers vpxd-XX.log. Un nouveau fichier est créé à chaque démarrage du service VMware VirtualCenter Server.
Pour pouvoir modifier les paramétrages du journal des transactions de votre base, il faut avoir récupérer les outils d'administration de base qui ne sont pas installés par défaut. Il s'agit, pour une base en SQL Server 2005 Express, de "Microsoft SQL Server Management Studio Express". Qui vient en version 32 ou 64 bits. Il existe aussi une version pour SQL Server 2008 Express.
Une fois ces outils récupérés et installés, connectez-vous à votre base SQL correspondant à votre vCenter.Dans la partie Base de données, faites un clic droit sur la base correspondant à votre vCenter - qui s'appelle chez moi VIM_VCDB - et choisissez Propriétés. Choisissez ensuite Fichiers. Vous avez alors deux entrées. Une de type Données qui est la base et une de type Journal qui est le fameux journal de transactions. Pour résoudre les éventuels problèmes, ou pour en éviter, il faut augmenter la taille maximum du journal de transaction. Cette option est réglable dans la colonne Croissance Automatique. Il faut cliquer sur le petit bouton gris avec "...". Là, vous pourrez configurer la façon dont le journal augmente automatiquement de taille - ne pas toucher à ce paramètre - et la taille maximum du journal. Aujourd'hui, franchement, n'hésiter pas à mettre 2048 Mo. Le journal pourra ainsi grandir jusqu'à 2 Go. Et normalement, il n'y aura pas de problème.

A noter que sur une ancienne mission, le vCenter reposait sur une base Oracle et plantait régulièrement à cause d'espace insuffisant sur le tablespace temp.

3- Reconstruction des indexes
Quatre tables posent problème pour vCenter. Ces quatre tables receuillent les informations de statistiques des serveurs ESX, des VMs et de l'ensemble de l'architecture. Ce qui fait que leurs indexes se fragmentent extrêmement rapidement. Ce qui entraîne des baisses des performances assez sensibles quand on consulte les sections liées aux graphes de performances et autres dans vCenter.
Pour solutionner le problèmes, il faut reconstruire les indexes en question de façon régulière. Dans un système de gestion de bases de données classique, cela se ferait sans problème. Par contre, quand vous avez SQL Server Express, c'est plus problèmatique. Comme c'est la version gratuit de SQL Server, certaines choses ne sont pas présentes et notament les plans de maintenance.
Donc, pour réindexer les quatres tables en questions, il faut faire un petit script SQL - avec Management Studio, c'est très facile à faire- qui sera lancer en ligne de commande.
Le script SQL ressemble à ceci :
USE [VIM_VCDB]
GO
ALTER INDEX [PK_VPX_HIST_STAT1] ON [dbo].[VPX_HIST_STAT1] REBUILD WITH
( PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, ALLOW_ROW_LOCKS =
ON, ALLOW_PAGE_LOCKS = ON, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY =
OFF, ONLINE = OFF )
GO
ALTER INDEX [PK_VPX_HIST_STAT2] ON [dbo].[VPX_HIST_STAT2] REBUILD WITH
( PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, ALLOW_ROW_LOCKS =
ON, ALLOW_PAGE_LOCKS = ON, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY =
OFF, ONLINE = OFF )
GO
ALTER INDEX [PK_VPX_HIST_STAT3] ON [dbo].[VPX_HIST_STAT3] REBUILD WITH
( PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, ALLOW_ROW_LOCKS =
ON, ALLOW_PAGE_LOCKS = ON, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY =
OFF, ONLINE = OFF )
GO
ALTER INDEX [PK_VPX_HIST_STAT4] ON [dbo].[VPX_HIST_STAT4] REBUILD WITH
( PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, ALLOW_ROW_LOCKS =
ON, ALLOW_PAGE_LOCKS = ON, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY =
OFF, ONLINE = OFF )
GO
Pour le lancer en ligne de commande, ça peut ressembler à ça :
sqlcmd -S .\SQLEXP_VIM -i "D:\Reconstruction_Index\Reconstruction.sql" >> Log.log

Bon, c'est tout mais c'est déjà pas mal.

Upgradons un vCenter en 4.1...

Wed, 21 Jul 2010 14:53:00 +0200

... dans la joie et la bonne humeur. Enfin, non, pas vraiment dans la joie et la bonne humeur.
Comme je l'ai dit dans mon message précédent, VMware a décidé de modifier sérieusement les prérequis pour l'installation d'un vCenter et impose un OS 64 bits désormais. Pas d'OS 64 bits ? Pas de vCenter 4.1.
Aujourd'hui, même si les processeurs 64 bits et les OS 64 bits existent depuis maintenant quelques années, le besoin réel de tels architectures ne se fait pas vraiment sentir et si il n'y avait pas quelques constructeurs ou éditeurs - genre Microsoft et la dernière version de certains produits type Exchange - pour forcer plus ou moins leurs adoptions.

Pourquoi VMware force cette adoption du 64 bits pour son vCenter ? Excellente question. En recherchant sur le site de l'éditeur, vous trouverez sans doute la réponse. Une bonne grosse réponse langue de bois à n'en pas douter. Pour ma part, je pense que c'et surtout parce qu'une faible partie du vCenter a besoin, dans certaines configurations, de plus de 4 Go de RAM pour fonctionner. Et, évidement, pour gérer de telles quantités de mémoire, il faut du 64 bits. Mais bon, ça, c'est pour les grosses infrastructures. Pour les petites, comme chez mon client actuel, ce besoin n'est pas présent.

Pourquoi je m'embête à vouloir upgrader le vCenter de mon client alors que je vais bientôt le quitter, et que je pourrais laisser cela à la charge de mon successeur ?
- Parce que c'est une opération que je serais amener à faire pour mes futurs clients.
- Parce que je veux laisser une infrastructure à jour à mon client en partant. Je fais les choses correctement jusqu'à la fin.
- Parce que je n'ai aucune confiance en mon éventuel successeur pour faire les choses correctement. C'est malheureux d'en arriver là, mais bon... En l'état actuel des choses, quand on se renseigne un peu sur le marché et sur les autres boites, on constate que le taux de tocards branleurs est de plus en plus élevé en informatique. - Non, je n'ai pas honte de dire ça. -

Donc comment upgrader un vCenter de la version 4.0.0 à la version 4.1 ?
Contexte : deux serveurs ESX 4, en cluster DRS et HA, avec une baie iSCSI et un vCenter virtuel sur un OS 32 bits. Le vCenter héberge la base de données, qui est sous SQL Express 2005. Peu ou pas de prod sur les VMs. Peu d'utilisation du vCenter en cette période, à part l'espèce de con qui veut le migrer. Donc possibilité de faire la migration de vCenter en pleine journée sans problème.
Le but : migrer le vCenter sur un serveur à OS 64 bits, sans perdre toute la configuration. (les pools de ressources, l'organisation de l'inventaire, le cluster, la configuration d'Update Manager, etc, etc...)
Les tests, méthodes, outils et autres utilisés :
VMware, dans sa grande générosité - j'ai vraiment envie de les pendre par les couilles avec cette histoire -, fournit un petit outil permettant de faire cette migration. "vCenter Server Data Migration Tool". Ce petit outil permet de faire un backup de la configuration du vCenter, de sa base et d'Update Manager. (même des patchs récupérés par Update Manager)
Sauf que... Ca ne migre que les bases SQL Express 2005 - là, j'ai bon - et que ça conserve le nom du serveur vCenter et son IP dans les fichiers de configuration. (Voir les gentils kbs chez VMware là et là) Et là... Vous haïssez encore plus VMware... Parce que si vous migrez, c'est vers un autre serveur histoire d'avoir un downtime minimum et un minimum de sécurité en conservant l'ancien serveur le temps de la migration. Donc serveur différent, nom différent et IP différente. - dans une architecture un minimum sérieuse, avec genre un AD... -
Le backup avec leur gentil outil : arrêt des services VMware du vCenter, exécution de la ligne de commande adéquate, interaction minimum vu que la question la plus critique doit être d'indiquer si oui ou non vous voulez sauvegarder les mppppfff Go de patchs. Au final, j'ai obtenu un peu moins de 2 Go de backup, base comprise.
Que j'ai gentillement copié sur mon nouveau serveur tout neuf en Windows 2008 R2 64 bits. Et j'ai fait un snapshot - serveur virtuel, c'est mieux pour faire des tests - avant de faire l'installation, histoire de pouvoir la rejouer en cas de problème. Et j'ai bien fait.
J'ai donc lancé l'installation à l'aide du gentil outil de VMware. Qui me signale rapidement que le nom du serveur n'est pas le même que l'ancien. Mais proposer de le changer, ça doit être trop demander... L'installation / restauration se fait sans trop de problème, avec quand même pas mal de question de la part du programme. Puis arrive la restauration de la partie Update Manager. Et le drame. Il faut lui préciser si il utilise une nouvelle base ou si il doit pointer sur une ancienne. L'option 1 permettra de finir l'installation, mais si vous essayez d'utiliser Update Manager, ça ne marchera pas. L'option 2 vous permet de pointer vers votre base qui vient d'être restaurée - si vous êtes en SQL Express - ou vers une autre base si elle est déportée. Pour se faire, il faut créer un lien ODBC. Et accrochez-vous... Un lien ODBC 32 bits. Et là, la politesse n'est même plus une option la prochaine fois que vous parlerez à un représentant de VMware. Ils imposent un passage au 64 bits mais pour certains composants, il faut rester au 32 bits. Tas de *BIPS* !!!!!!
Donc, pour créer un lien ODBC sur Windows 2008 R2, il ne faut pas passer par l'exécutable habituel car il ne crée que des liens 64 bits. Il faut lancer %windir%\SysWOW64\odbcad32.exe. Et si votre base n'est pas déportée, il faut le faire entre le moment où vCenter et sa base sont restaurés et le moment où Update Manager s'installe.
Donc, au bout de quatre tentatives d'installation, j'ai eu un vCenter fonctionnel, reconnaissant mes serveurs ESX, reconnaissant le cluster, ayant récupéré toutes les informations nécessaires. Mais... Qui croit s'appeler du nom de l'ancien serveur, y compris pour la partie licenses. Autant dire, un truc totalement bancal et impossible à utiliser et à maintenir en production.

Après ces différentes tentatives de migration, il faut être réaliste.
Si vous avez une base déportée, vous pouvez vous en sortir assez bien, avec un downtime minimum.
Si vous avez une base SQL Express sur le même serveur que le vCenter, vous serez obligé de migrer sur un serveur du même nom avec la même IP.
C'est ce que je vais faire demain.
1- Backup du serveur vCenter 4.0, avec l'outil Data Migration de VMware, avec votre solution de sauvegarde favorite et un snapshot si votre serveur est virtuel. On est jamais trop prudent.
2- Copie du résultat du Data Migration vers le nouveau serveur.
3- Arrêt du vCenter 4.0
4- Renommage du nouveau serveur avec le nom de l'ancien. - si votre serveur est dans un AD, vous voyez les problèmes qui vont se poser si il faut faire retour arrière. - Ne surtout pas rebooter à ce moment là.
5-Changement d'IP du nouveau serveur pour celle de l'ancien.
6- Reboot.
7- Installation / restauration de vCenter, avec les galères de lien ODBC.
8- On prie, on teste et on constate.

Solution de retour arrière : vous éteignez le nouveau serveur. Vous rallumez l'ancien. Et si vous êtes en AD, ben... disjoin / join au domaine. En espérant que la base SQL Express n'explose pas pour des problèmes d'authentification...

Encore une fois, merci à VMware pour cette migration forcée, merci pour l'outil de migration merdique. Quand on voit ce que l'on paye en maintenance obligatoire annuelle, c'est franchement du foutage de gueule...

VMware : serait-ce le début de la fin ?

Thu, 15 Jul 2010 13:33:55 +0200

En 2003 - 2004, je découvrais un peu par hasard la virtualisation. Dans ma branche, c'est un peu LA révolution technologique de ces dernières années, qui bouleverse énormément de choses, qui s'infiltre partout, et qui permet à votre serviteur d'être payé grassement et de changer facilement de boucherie.
Depuis le début, je suis fan, à mort, des produits de VMware. Cette entreprise propose juste les solutions les plus matures de virtualisation, que ce soit avec des hyperviseurs de type 1 ou 2, dans les fonctionnalités associées, dans la qualité des produits - à part l'ignoble Bug du 15 août 2008 - ou dans la facilité d'utilisation. - Missa dumb dumb et pourtant, j'arrive parfaitement à comprendre comment ça marche, à déployer et à administrer les architectures que je conçois avec ces produits. -

Mais... Parce qu'il y a un mais. Il y a toujours un mais. Rien n'est jamais parfait.
Il y a un mais qui commence à être de taille.
Depuis Juillet 2008, la dirigeante historique - et l'une des fondatrices - de VMware Diane Greene était subitement débarquée. Son départ fut suivi de celui de Mendel Rosenblum, chief scientist de VMware, et accessoirement mari de Diane Greene. Ces deux personnes étaient parmis les pierres angulaires de VMware.
Diane Greene a été remplacée par Paul Maritz, qui a pendant 14 ans été considéré comme le troisième homme chez Microsoft, derrière Bill Gates et Steve Ballmer.
Vous commencez à saisir le malaise ?
Depuis, un certain nombre de choses ont évoluées.
Technologiquement, VMware conserve toujours, et de loin, le lead et ma préférence. Par contre, commercialement, ça devient vraiment n'importe quoi.
Déjà, renommage des produits phares qui, de VMware ESX, ESXi, VirtualCenter et Virtual Infrastructure (bundle de ESX et VirtualCenter), sont passés à vSphere, vSphere Hypervisor, vCenter Server, vCenter, ceci à l'occasion de du passage de la version 3.5 à la 4. Tout le monde s'y perd, personne ne s'y retrouve...
Pour ajouter à la confusion, les tarifs ont changés, les fonctionnalités regroupées en différents packs qui ne veulent rien dire, le pricing des licenses a changé... - On passe de licenses pour 2 sockets à des licenses pour un socket... -
Et là... VMware vient d'annoncer la version 4.1. Je me demande sérieusement ce qu'elle apporte de plus pour mériter le .1. Et surtout j'aimerais bien arriver à comprendre si mes serveurs actuels en 4.0, il va falloir que je les upgrade - processus long et complexe où il est souvent plus simple de réinstaller le serveur en nouvelle version et de le reconfigurer - ou si je dois le mettre à jour - processus simple et automatisé -. De même, est-ce que mes licenses en 4.0 sont toujours valables pour la 4.1. Sachant qu'ils viennent encore de changer les bundles et le pricing associé...

Pour moi, aujourd'hui, VMware est en perte de vitesse. Non pas sur le plan technologique, même si je pense qu'ils vivent sur les derniers travaux de Mendel Rosenblum plus que sur de réelles nouvelles avancées, mais sur le plan commercial. On est passé de quelque chose d'assez simple à une véritable usine à gaz.
Aujourd'hui, vu la place de plus en plus importante que prend la virtualisation, de nouveaux acteurs sont apparus, pour profiter du marché en expansion. Avec des solutions qui s'améliorent de jour en jour. Avec des pricing qui peuvent être intéressants. VMware a été le leader sur les années 2000. Pour les années 2010, je crains fortement qu'il ne soient sur la pente descendante... Et qu'ils soient en train de savonner cette pente...

Et là, j'ai un message pour les actionnaires de VMware et pour EMC, sa maison mère :
Virez Paul Maritz et remettez des gens compétents à la tête de cette entreprise.

--- Update ---
J'ai commencé à faire quelques tests sur la 4.1, notamment vCenter. Je voulais upgrader mon vCenter actuel en 4.1... Comment dire... Les pré-requis ont changé... Il faut désormais que le serveur devant héberger ce service ait deux processeurs 64-bits ou un processeur double-coeur 64 bits...
Mon vCenter actuel est sur une VM avec un OS 32-bits...
JE LES HAIS !

Comment enregistrer des licenses ESX 3.5 sur un vCenter 4 - ou comment faire meuuuuh

Mon, 15 Mar 2010 14:27:58 +0100

Je suis en train de bosser sur un vrai article de blog, sur un sujet intéressant, autre que mon boulot, et que j'essaye de faire sérieusement et un minimum documenté. Et en essayant de dire le moins de conneries possibles. - Ca va être dur... - Et donc, je ne voulais pas poster entre temps. - Ou alors pour un seul évènement spécifique qui arrive bientôt. -

Mais, aujourd'hui, j'ai enfin pu résoudre un problème qui me bloquait depuis plus d'une semaine au boulot.
En effet, lorsque j'ai monté ma petite plateforme de virtualisation, j'avais décidé d'installer des serveurs ESX 3.5 avec un Virtual Center 4. - vCenter 4 / vSphere 4, enfin on s'y perd dans les nouvelles dénominations. - Pourquoi une vieille version de ESX ? Et bien principalement, parce que cette version fonctionne correctement, est stable et que j'ai déjà pu la tester longuement en production. La version 4, j'en ai eu des échos moyens et elleavait moins d'un an quand j'ai conçu l'architecture de ma petite plateforme. Et surtout, la 4 contient pleins de gadgets qui ne m'intéresse pas et qui compliquent les prix des licenses.
Pourquoi un vCenter 4 dans ce cas là ? Et bien, parce que le client avait déjà déployé plusieurs serveurs ESXi 4 dans son infrastructure.- Notez le petit i. ESXi c'est la version gratuite et limitée de ESX. -Et donc, pour des raisons de compatibilité, il fallait que j'utilise un vCenter 4, capable de gérer des ESXi 4 comme des ESX 3.5.

Or, entre les deux versions d'ESX - et de vCenter, car le vCenter habituellement associé à ESX 3.5 est le Virtual Center 2.5. Vous vous y perdez dans les versions et les noms ? C'est normal... Moi aussi... -, la façon de gérer les licenses a changé.
Alors que pour le vCenter 2.5, les licenses étaient gérées dans un fichier et avec un service LMTOOLS à part, la version vCenter 4 gère les licenses avec des numéros de série, sans service supplémentaire.
C'est ce qui arrive quand vous mettez à la tête d'une entreprise, fournissant jusqu'ici des produits cohérents et simples, un ancien de chez Microsoft. - Oui, en 2008, deux des anciens dirigeants historiques de VMware étaient débarqués au profit d'un ancien de chez Microsoft... Depuis, ça coince un peu à certains moments... -

Donc, problème. Mes licenses pour mes ESX 3.5 étaient gérées par fichier. Ce qui n'est pas géré de base dans vCenter . Et même pire, je ne pouvais enregistrer ma license de vCenter 4 tant que je ne pouvais pas enregistrer celles de mes ESX. - Serpent, queue, tout ça... -
Pour gérer mes licenses 3.5, il fallait que j'installe un license server en plus de mon vCenter 4. Ce license server est fourni gratuitement sur le site de VMware. Et j'ai essayé de l'installer. Et bizarrement, sur mon beau Windows 2008 service pack 2, ça ne marchait pas. A la fin de l'installation, le service license server me disait qu'il ne pouvait pas démarrer et qu'il n'était pas sûr que j'avais les droit pour le démarrer. Quand vous êtes admin local de la machine - et aussi admin du domaine - c'e'st un peu fort. J'ai d'abord blamé l'antivirus - mal paramétré, trop lourd et qui me bloquait des processes - et, ayant reçu l'autorisation de dégager cette saloperie, j'ai du m'incliner et voir que le problème n'était pas l'antivirus. Un petit coup de Google m'a founi la solution : la version du license server disponible sur le site de VMware n'est pas compatible Windows 2008 SP2. Glarg !
Fort heureusement, la solution était donnée. Il fallait prendre le serveur de license disponible dans l'iso du Virtual Center 2.5 (U4 minimum) pour avoir une version compatible 2008 SP2. Version que j'avais fort heureusement encore sur ma clé USB.
Trois clics de souris plus tard, ça marchait. Et je me défoncais la tête contre une porte en faisant Meuuuuuuuuuh.

Les joies des baies iSCSI au boulot...

Tue, 23 Feb 2010 22:05:39 +0100

Encore une fois, ce post n’est intéressant que pour une personne : moi. Encore une fois, c’est technique et il va me permettre de garder quelque part certains éléments.

Dans le cadre de mon boulot, j’ai eu l’occasion de concevoir et de mettre en place une petite infrastructure VMware composée de deux serveurs ESX, d’un serveur vCenter et d’une baie de stockage iSCSI. C’est sur la baie iSCSI que va porter l’essentiel de cet «article».
Premièrement, pourquoi une baie iSCSI ?  D’abord, pour des question de coût. Trois technologies se présentaient à moi dans mon étude : Fibre Channel, SAS ou iSCSI. Chez le client, aucune infrastructure n’existait pouvant supporter l’ajout de cette baie. Il fallait donc monter quelque chose à partir de rien. Pour la technologie FC, les coûts en infrastructure sont énormes. - C’est de la fibre optique. - Pour bien faire, cela implique de tirer des fibres optiques, de mettre en place des switchs spécifiques - avec de la configuration lourde - et ajouter des cartes HBA dans les serveurs. Coût : XXXk€. Avec le budget que j’avais à disposition, il est évident que cette solution n’était pas viable. Pour la technologie SAS, il fallait aussi des cartes supplémentaires sur les serveurs. Des cartes chères. La baie SAS était aussi un peu plus chère que la baie iSCSI. Pour la baie iSCSI, la moins chère, tout ce qui était nécessaire, c’était des cartes réseau supplémentaires. - Moins chères que les cartes SAS - Car le iSCSI, c’est du SCSI sur de l’ethernet. Et les infrastructures réseau, c’est la base même de l’informatique d’entreprise aujourd’hui. Aucun investissement particulier n’était nécessaire ici.
Vous allez me dire : oui, mais les performances du iSCSI, comparées à de la fibre ou du SAS, c’est la nuit et le jour. iSCSI : 1 Gbps; SAS : 3 Gbps; FC : 4 Gbps. Dans le cas de mon client, 1 Gbps était suffisant. - Peu de machines virtuelles, peu de prod, peu de réelle charge I/O - De plus, j’ai plus que 1 Gbps en iSCSI puisque avec le modèle de baie choisie, je bénéficie de quatre connexions Gigabit sur ma baie. Avec de la répartition de charge, on obtient facilement bien plus de 1 Gbps. Je n’ai pas fait de mesure exacte, mais bon...
Finalement, il fallait aussi prendre en compte la possibilité d’extension éventuelle de l’infrastructure. Depuis que je fais de la virtualisation, j’ai vu les erreurs à ne pas commettre. La première d’entre elles est de ne pas prévoir une architecture qui va évoluer. La virtualisation, une fois qu’elle a pénétré dans une entreprise, elle ne fait que s’étendre. Si mon client ne voulait que deux serveurs ESX pour commencer, il fallait prévoir de pouvoir en augmenter le nombre. Or, si pour les technologies FC et iSCSI, l’ajout de serveurs supplémentaires n’est pas un problème pour attaquer la même baie, il est largement plus problématique pour les baies SAS. En effet, dans le cadre des baies SAS, les serveurs sont en attachement direct avec la baie. Dans les cas FC et iSCSI, les serveurs sont reliés à des switchs, et ces switchs sont reliés à la baie. Pour le SAS, la baie est reliée directement aux serveurs et ne peut servir que deux serveurs au maximum. Donc exit le SAS.

Donc, pour mon architecture, mon choix s’est porté sur une baie HP, iSCSI, MSA2312i G2. Une baie avec deux contrôleurs - redondance, sécurité, tout ça - quatre ports réseau pour le iSCSI, deux ports pour le management, avec la possibilité de mettre 12 disques SAS ou SATA, et une possibilité de rajouter des modules supplémentaires - quatre maximum - pouvant gérer chacun soit 12, soit 24 disques supplémentaires. - En l’occurrence, on a pris un module supplémentaire pour 12 disques. -
L’installation physique de la baie s’est fait sans problème - Ahahahahahhahahahaha... Pardon... C’est nerveux... Quand le client ne vous file pas les bonnes infras pour installer votre matos... -, la configuration effectuée normalement. Puis, voulant faire bien, et parce que c’était la dernière fois possible avant la mise en prod et la possibilité de la faire en heures normales et sans impact, j’ai voulu mettre à jour le firmware de la baie. Opération on ne peut plus normale.
Première étape : récupération du dernier firmware à jour sur le site du constructeur. Autant dire, la galère... Le site de HP est franchement l’un des plus bordéliques qui puissent exister. Même quand vous possédez les références exactes de votre matériel.
Deuxième étape : lancer la mise à jour. Fort heureusement, les baies de nos jours possèdent des interfaces web. Vous vous connectez, vous allez sur la bonne page, vous sélectionnez le fichier contenant le firmware et vous appuyez sur : «vas-y fait ton boulot».
Et là... COIN ! «Mauvaise extension de fichier». Marmotte, tout ça, vous vérifiez le fichier, la source, vous réessayez : COIN ! Marmotte moins polie, vous vérifiez la doc pour cette opération, vous ne constatez aucune erreur, votre fichier est correct, vous réessayez. - Oui, dans l’informatique, si vous ne touchez à rien, des fois, au bout de la xème tentative, ça marche. - COIN ! toujours et encore. Et là... L’éclair de génie. Votre fichier est dans un répertoire dont le nom contient un espace. Ouais... Le vieux truc qui n’a plus d’impact normalement... Vous résolvez le problème et l’opération se lance. Et dure... Et dure... Vous regardez d’un oeil morne les écrans et les étapes qui défilent. Et l’opération aboutie enfin. Comme vous avez deux contrôleurs sur cette baie, cette opération doit être effectuée sur les deux. Ce qui se fait automatiquement.
Et là... Le drame... La mise à jour boucle. Une fois terminée, elle repart à zéro. Avec des écrans qui vous empêche d’accéder à l’interface web, pour consulter les logs... Au bout de la troisième boucle, vous faites ce qu’il ne faut pas faire. Vous allez éteindre électriquement la baie. - Ne faites jamais ça chez vous les enfants. Ni même au boulot. Seuls les professionnels suicidaires, déprimés, ayant envie d’être virés ou cons sont habilités à le faire. - Elle redémarre correctement, vous accédez à l’interface web, vous commencez à consulter les logs et à voir que c’est la mise à jour sur le contrôleur 2 qui merde et... La mise à jour se relance d’elle-même, et c’est reparti pour une boucle. Et là... Vous n’êtes plus de bonne humeur... Vous vous passez les nerfs sur le collègue bourré en train de chanter le générique français de l’Agence Tout Risque.
Et vous commencez à googler le problème à l’aide des différents messages que vous voyez passer et repasser en boucle. Et vous comprenez que le problème est connu - Vous maudissez le constructeur sur 150 générations - et vous obtenez les commandes nécessaires à la désactivation de la mise à jour automatique d’un contrôleur par l’autre contrôleur.
La manipulation est simple. Vous vous connectez à la baie en ligne de commande, ce qui nécessite un câble au format propriétaire, qui relie un port COM - Essayez de trouver de nos jours un portable qui a encore un port COM... - à un port propriétaire.
Et vous désactivez la fonction avec la commande suivante :
set job-parameters partner-firmware-upgrade disable
Vous pouvez vérifier que la commande a bien été prise en compte à l’aide de :
show job-parameters
Une fois cette fonction désactivée, vous êtes bons pour attendre la fin d’un cycle de mise à jour avant de redémarrer électriquement la baie. - Ou avant si vous êtes complètement timbrés. -
Et à recommencer l’upgrade, contrôleur par contrôleur. Et bien noter dans votre documentation d’exploitation que vous allez filer au client toutes les petites merdes qu’ils peuvent avoir, les solutions éventuelles, et que si ils font cette opération, il vaut mieux la prévoir hors heures ouvrées et prévoir une interruption de service.

Et si vous êtes architecte virtualisation, prévoir que pour la prochaine fois, vous ne prendrez pas du HP. A la rigueur, de l’EMC ou du NetApp. - Ouais, parce que là, c’est la version courte des problèmes que j’ai eu pour faire cette bon dieu de mise à jour de firmware... -

Tout ça pour juste me faire une petite note pour ne pas oublier les deux commandes, notées sur un post-it.

Ressources virtualisation

Wed, 13 Jan 2010 15:38:39 +0100

Cherchez pas. C'est juste un article pour moi même pour retrouver facilement les ressources concernant un certain nombre de technologies que j'utilise au boulot.

Ressources virtualisation

http://www.yellow-bricks.com/ (Bonne source sur VMware
http://www.rtfm-ed.co.uk/ (Bonne source sur VMware)
http://www.vmug.fr/ (VMware User group France)
http://blog.scottlowe.org/
http://www.boche.net/blog/
http://vmetc.com/

VMware View 3 installation
http://searchvirtualdesktop.techtarget.com/generic/0,295582,sid194_gci1374137,00.html

VMware HCL
http://www.vmware.com/resources/compatibility/search.php

iSCSI et VMware vSphere
http://virtualgeek.typepad.com/virtual_geek/2009/09/a-multivendor-post-on-using-iscsi-with-vmware-vsphere.html

Débat vSwitch
http://kensvirtualreality.wordpress.com/2009/03/29/the-great-vswitch-debate-part-1/

Ressource Kit vSphere
http://www.vsphereresourcekit.com/videos.html
http://www.vsphereresourcekit.com

Blog Formations VMware et certifications
http://vmwaretraining.blogspot.com/

Des conneries dites sur la virtualisation

Fri, 11 Dec 2009 10:00:16 +0100

Toujours sur la virtualisation, donc chiant.

Je lisais dernièrement dans un article du 01Net les choses suivantes :

La virtualisation gagne du terrain :28 % des répondants y recourent, contre 13 % l'an passé. Les bénéfices attendus vont du bien connu (réduction des coûts d'administration, facilitation des opérations de maintenance, de migration, de remplacement, et de la mise en place de classes de stockage) au plus inattendu : économies sur les licences de réplication, mise en concurrence accrue entre fournisseurs, et pratique de la sur-réservation (thin-provisionning). La virtualisation crée aussi de nouveaux problèmes : fort impact des opérations de montée en version des moteurs de virtualisation, sollicitation accrue des liens intercommutateurs de la matrice SAN risquant de générer des congestions et/ou des indisponibilités, et enfin, complexité de l'analyse des incidents dans les environnements virtualisés.

C'est la partie en gras qui me fait bondir.
Je ne nie pas que la virtualisation crée de nouveaux problèmes. Mais ceux qui sont cités ne sont pas liés spécifiquement à la virtualisation, mais plutôt à des problèmes d'exploitation, de supervision et d'architecture.

- "fort impact des opérations de montée en version des moteurs de virtualisation"
Déjà, ce type d'opération n'est pas fréquent. Vous ne ferez une montée de version majeure de votre solution de virtualisation qu'au mieux tous les deux ou trois ans. En théorie, c'est la même fréquence que la montée de version du système d'exploitation d'un serveur standard.
Si on parle de versions mineure, celles-ci sont moins impactantes que, par exemple, les service packs windows.
De plus, avec les outils à disposition des solutions type VMware, ces opérations de montée de version, majeure comme mineure, sont au mieux transparentes, au pire aussi impactant que le passage d'un patch Windows.
Une bonne architecture de base comportera au moins deux noeuds (serveurs hôtes) dans un cluster hébergeant vos machines virtuelles. Tous les derniers produits, que ce soit Microsoft (Hyper-V), VMware (vSphere), Citrix (Xen) ou Sun (Virtualbox), permettent de faire des migrations de machines virtuelles, à chaud, de façon transparente pour les utilisateurs, entre les deux serveurs hôtes. Durant l'opération de montée de version, vous devrez mettre toutes vos machines virtuelles sur un seul noeud - bien évidement, si vous avez respecté les best practices, vous aurez largement les ressources nécessaires pour le faire sur le deuxième noeud - et vous ferez l'opération de montée de version sur l'autre. Jusqu'ici, l'impact sur la disponibilité de vos serveurs virtuels et sur les utilisateur est nul.
On passe ensuite à la partie pouvant avoir un impact. - Bien évidement, comme votre architecture est bien conçue, vous avez sauvegardé auparavant vos machines virtuelles. Chose qui ne doit pas être exceptionnel car devant être fait de façon régulière. - Donc, il faut maintenant migrer vos machines virtuelles sur le serveur hôte qui a monté de version. Au mieux, aucun impact car rien n'est modifié pour la machine virtuelle. Celle-ci n'ayant que des drivers générique, elle ne voit rien de particulier si la façon d'émuler le matériel à changer. De même, si le format de stockage des VMs n'a pas changé, aucun impact. - Ce cas de figure est quand même extrêmement rare. Sur ces sept dernières années, je ne l'ai vu qu'une seule et unique fois. - Par contre, si l'émulation change, les drivers sont à changer dans la machine virtuelle. Avec un produit comme VMware, cela revient à mettre à jour les VMTools, opération largement automatisable, n'impactant pas les applicatifs hébergés sur la machine virtuelle, et qui n'implique au final qu'un redémarrage du serveur virtuel. - Même impact qu'un patch Windows -
Bref, une montée de version de solution de virtualisation demande juste un peu d'organisation. C'est tout. C'est même moins impactant qu'une montée de version de système d'exploitation.

- "sollicitation accrue des liens intercommutateurs de la matrice SAN risquant de générer des congestions et/ou des indisponibilité"
Le commentaire ici est facile, simple et tranchant :
un tel problème ne se produit que si l'architecte qui a pondu la solution de virtualisation est un âne baté qui n'a pas fait correctement son boulot.
Le temps de réponse, de transfert, les taux d'I/Oentre les serveurs hôtes et la partie SAN sont l'un des points les plus regardés quand on conçoit une telle architecture. La recherche de la meilleure performance possible est au coeur de l'architecture.
Et l'idée d'un simple congestionnement des liens est ridicule au regard des possibilités de perte de performances si votre baie SAN est mal taillée en terme de RAID Group et de volumes.
Bref, avec un vrai architecte qui sait ce qu'il fait, les problèmes de ce genre ne se produisent pas.

- "complexité de l'analyse des incidents dans les environnements virtualisés"
Là encore, ça va trancher.
Quand on sait utiliser, exploiter et superviser correctement une plateforme de virtualisation, ce n'est pas plus complexe qu'autre chose à analyser en cas de problème.
Si vous supervisez correctement toute la chaine, vous êtes capables de détecter rapidement td'où vient le problème. Comme pour le reste des systèmes informatiques ! Nom d'un chien - ça y est, je m'énerve - quand on conçoit les choses correctement, quand on met en place les bons outils, les bonnes procédures, avec des gens formés, on réduit les incidents et le temps de traitements des incidents. En clair, quand on fait correctement son travail, ce n'est pas plus complexe que le reste !
Et personnellement, j'ai moins de problème à analyser un incident sur une plateforme de virtualisation q'un incident sur un bon dieu d'AD Microsoft. Et pourtant, je suis compétent sur les deux.

Et donc, merci encore une fois aux journalistes spécialistes dans les petits pois qui pondent des articles mal foutus et plein de lieux communs.
Surtout que c'est ce genre d'articles que lisent des managers incompétents et qu'ils utilsent pour justifier leurs décisions à la noix...

Virtualisation

Thu, 10 Dec 2009 10:21:02 +0100

Encore une fois, ceci va être un article chiant.

Ceci reprend en partie la présentation que je fais de la virtualisation, et principalement de VMware, dans les propositions techniques adressées à mes clients.
Je la mets là parce que ça peut être intéressant et parce que c'est en grande partie en refonte. Car j'avais basé cette présentation sur VMware Infrastructure 3 (VMware ESX 3.5) et que la version 4 est sortie depuis quelques temps maintenant et peut commencer à être considérée comme stable et déployable en production.
Toutes les images sont tirées des white papers VMware disponibles sur leur site.

Principes de la virtualisation

La virtualisation est une couche d’abstraction qui découple la partie matérielle (hardware) du système d’exploitation pour permettre une meilleure utilisation des ressources et une plus grande flexibilité dans l’utilisation de ces ressources. La virtualisation permet à de multiples machines virtuelles, avec des environnements hétérogènes (Windows NT4, Windows 2000, Windows 2003, Windows 2008, Linux, …), de fonctionner sur la même machine physique, tout en étant isolées les unes des autres.
Une machine virtuelle est la représentation d’une machine physique par un logiciel. La machine virtuelle a son propre ensemble de composants virtuels (RAM, CPU, Carte réseau) sur lesquels le système d’exploitation et les applications sont chargés. Le système d’exploitation ne voit qu’un ensemble de composants consistant et normalisé, totalement indifférent des composants matériels physiques réels.

Avant virtualisation

Après virtualisation

Deux principes existent dans le monde de la virtualisation :

• Une approche « hébergée » qui fournit un service partitionnement par-dessus un système d’exploitation standard. Dans ce mode de fonctionnement, la partie chargée de faire tourner les machines virtuelles est considérée comme une application pour son installation et son exécution.

Architecture "hébergée"

• Une approche « hyperviseur ». La partie chargée de faire tourner les machines virtuelles est directement installée sur le matériel. Puisque l’hyperviseur a directement accès aux ressources matérielles, celui-ci est plus robuste, performant et permet une meilleur extensibilité que la version « hébergée ».

Architecture "Hyperviseur"
Bénéfices de la Virtualisation

•    Consolidation des serveurs
La virtualisation va permettre une consolidation des parcs serveurs. Au lieu d’avoir une vingtaine de serveurs ne consommant au mieux qu’à 10 ou 15% des ressources disponibles, vous aurez, par exemple, quatre serveurs consommant 80% de leurs ressources, avec ainsi une marge en cas de nécessité d’augmenter la puissance d’une machine virtuelle à un instant T.
Dans certains cas, la virtualisation a permis des gains du type 8 à 10 :1.
Cela permet de sortir du schéma « une application = un serveur ».

•    Disponibilité

Grâce à la virtualisation, il est désormais possible de ne plus interrompre la production pour des interventions de maintenance. Notamment grâce à la possibilité de déplacer sans interruption les environnements virtuels d’un serveur hôte à un autre.
De même, avec les options de haute disponibilité de certains constructeurs, en cas de défaillance d’un serveur hôte, les machines virtuelles peuvent être redémarrées automatiquement sur un autre serveur hôte.

•    Performance

La virtualisation permet de mieux contrôler les performances. En effet, différentes solutions de virtualisation offrent des solutions de monitoring de performances, d’allocation et de réallocations de ressources qui permettent d’affiner au mieux les configurations des serveurs virtuels. De plus, si le besoin se fait sentir, certaines solutions permettent d’automatiquement transférer une machine virtuelle d’un serveur hôte à un autre moins chargé au niveau des ressources.

•    Flexibilité

La virtualisation permet une plus grande flexibilité dans la gestion des serveurs et des postes de travail. En effet, la mise en place d’un serveur virtuel peut se faire en quelques heures contre quelques jours pour un serveur physique. Par exemple, gain de temps au niveau de l’achat de matériel. Pour un serveur physique, vous devez commander le matériel auprès du constructeur, attendre la livraison, mettre en place l’équipement dans un environnement approprié (rack, salle serveurs). Avec un serveur virtuel, il ne suffit que de quelques clics pour qu’un nouveau serveur virtuel soit créé. Et gain de temps en déployant des serveurs virtuels depuis des templates prédéfinis et contenant déjà un certain nombre d’applications de base préconfigurées.

•    Sécurité

La portabilité des machines virtuelles offre la possibilité de mettre en œuvre des processus de restauration et de PRA à moindres coûts et réduit considérablement le temps nécessaire à la remise en route d'un serveur. Elle permet entre autre de déplacer facilement la charge de travail d'un serveur physique à un autre.
Les nouvelles fonctions offertes par la virtualisation permettent de concevoir des systèmes capables de basculer automatiquement en cas de défaillance.
Enfin, en consolidant des infrastructures complexes dans des environnements et des réseaux virtuels séparés, les administrateurs peuvent configurer des règles spécifiques à chaque environnement et maximiser la sécurité. (Environnements de tests, ou de développement, environnements de production).
De même, avec les notions de snapshots, il est possible de faire une image figée à un instant T d’un serveur, de continuer à travailler sur le serveur (pour l’application de patchs par exemple) et de faire un retour arrière en cas de problème.
Acteurs
Dans le monde de la virtualisation, il existe trois acteurs « majeurs » :
•    Microsoft avec Hyper-V

Cette solution est assez récente et peu mature. Face à ses concurrentes, elle manque de fonctionnalités critiques et de maturité.

•    Citrix avec la gamme de produits Xen

Solution basée sur un ancien projet open-source. (Xen App) Cette solution manque encore de fonctionnalités et de maturité.

•    VMware

VMware offre la solution la plus mature et la gamme de produits la plus complète disponible à ce jour dans le monde de la virtualisation.
VMware
•    VMware Workstation

C'est la version station de travail du logiciel. Il permet la création d'une ou plusieurs machines virtuelles au sein d'un même système d'exploitation. (Généralement Windows ou Linux). Il s’agit d’une application de virtualisation fonctionnant sur une « architecture hébergée ». Il est possible de faire fonctionner plusieurs machines virtuelles en même temps, la limite correspondant aux performances de l'ordinateur hôte. Cette version gère les snapshots. Elle dispose de Virtual SMP. Elle ne dispose pas d’une console d’administration à distance. Ce produit est payant.

•    VMware Player

C'est une Workstation extrêmement allégée, qui permet d'utiliser une machine virtuelle, mais non pas de la créer. Cette version ne gère pas les snapshots. Elle ne dispose pas d’une console d’administration à distance. Ce produit est gratuit.

•    VMware Server

VMware Server est la solution serveur en mode « hébergé ». Elle permet la création d'une ou plusieurs machines virtuelles au sein d'un même système d'exploitation. (Windows ou Linux). Cette version gère les snapshots. Elle dispose de Virtual SMP. Elle dispose d’une console d’administration à distance. Elle ne propose aucune fonctionnalité avancée, du type VMotion, DRS, templates, HA… Ce produit est gratuit.

•    VMware vSphere ( anciennement ESX)

VMware ESX est le produit phare de Vmware. VMware Server est la solution serveur en mode « hyperviseur ». ESX est basé sur un noyau RedHat. Cette version est la plus poussée et la plus aboutie, disposant de toutes les options : Virtual SMP, VMotion, HA, DRS, snapshots, templates, Virtual Center… Cette version est payante, vendue sous diverses formes.
Une version gratuite et limitée en termes de fonctionnalité est disponible : ESXi.
Options VMware
- Virtual SMP
  
  Il permet d’améliorer les performances des machines virtuelles en permettant à une seule machine virtuelle d’utiliser simultanément plusieurs processeurs physiques.
  Cela offre la possibilité d’exécuter des applications consommant le plus de ressources dans les environnements virtualisés (comme les bases de données et les applications ERP ou CRM).
- VMotion
  Il s’agit de la capacité de déplacer des machines virtuelles d’un serveur ESX à un autre sans interruption de services de la part des machines virtuelles.
- VMware HA
  
  VMware HA signifie VMware High Availability.
  A travers du concept de cluster HA (High Availability), VMware propose une solution de haute disponibilité des serveurs virtuels. Dans le cas de la défaillance d’un serveur ESX, les machines virtuelles hébergées sur ce serveur sont automatiquement redémarrées sur les autres serveurs ESX du cluster.
  Attention, il faut comprendre que la disponibilité des serveurs virtuels n’est en aucun cas de 100% avec cette solution. Cette solution ne fait que minimiser l’indisponibilité des serveurs et permet de redémarrer automatiquement, sans intervention humaine, les serveurs impactés.
- Virtual DRS
  
  Virtual DRS signifie Virtual Distributed Resource Scheduler.
  VMware DRS (Distributed Resource Scheduling) et VirtualCenter permettent de gérer toutes les ressources dans un cluster. Un ordonnanceur interne à VirtualCenter permet l’allocation des ressources et la surveillance de toutes les machines virtuelles qui tournent sur les serveurs ESX composant ce cluster.
  DRS procure un placement initial automatique d’une machine virtuelle sur n’importe quel hôte du cluster et fait aussi une répartition automatiques des ressources et prend des décisions d’optimisation au fur et à mesure que des machines virtuelles ou des hôtes sont ajoutées ou supprimées du cluster.
  De façon plus générale, il faut comprendre que DRS équilibre automatiquement la charge sur les différents serveurs ESX composant un cluster.
- VMware Consolidated Backup
  Il s’agit de l’utilitaire de sauvegarde centralisé adapté aux machines virtuelles.
- Virtual Center
  
  Virtual Center est l'outil de gestion de la gamme ESX, cet outil (optionnel) comprend l'ensemble des options liées à ESX telles que VMotion, DRS et HA. Cet outil de gestion permet de gérer l'ensemble des machines virtuelles et des hôtes physiques. Il est également possible à travers de cette interface de gérer :
  o        * les alarmes de supervision (CPU/RAM) ;
  o        * les templates (enveloppes de systèmes d'exploitation pré-configurés) ;
  o        * l'utilisation des options (HA, VMotion, DRS).
  Cet outil nécessite l'installation d'une base de données (Oracle ou MS SQL Server). Pour les petites plateformes, il est possible d’utiliser Virtual Center avec un vase SQL Express. Toutes les données et les statistiques d'utilisation des ressources y sont stockées ainsi que l'ensemble de la configuration.
- VMware Update Manager
  
  VMware Update Manager est l’outil de gestion et de déploiement centralisé des mises à jour de Virtual Infrastructure. Cet outil peut mettre à jour aussi bien les serveurs hôtes ESX (ou ESXi) que les systèmes d’exploitation des machines virtuelles. (Windows, Linux pour les distributions supportées)
  Dans les faits, Update Manager gère surtout les mises à jour pour les serveurs VMware. Les machines virtuelles sont mises à jour par les mêmes outils que les machines physiques, avec des outils type WSUS.
  Cet outil nécessite l'installation d'une base de données. Elle peut être mutualisée avec la base de données de Virtual Center. L’un des points importants est l’espace disque nécessaire au stockage des mies à jour. Plus vous choisirez de mettre à jour des systèmes différents par Update Manager, plus vous aurez besoin d’espace disque pour stocker ces mises à jour.
- Templates
  
  Un template est un modèle qui sert à déployer des machines virtuelles facilement et rapidement. Un template est à la base identique à une machine virtuelle. Lors du déploiement d’un template, un paramétrage automatique peut être lancé, permettant de configurer exactement la machine virtuelle comme souhaité.
  Les templates permettent des gains de temps importants dans les déploiements de serveurs et de postes de travail. Là où une installation basique a partir d’un CD peut prendre deux à trois heures, la même installation à partir d’un template prend une demi-heure.
- VMTools
  Les VMtools sont un jeu de drivers et de programmes qui permettent le fonctionnement optimal d’une machine virtuelle.
  Entre autres, les VMTools contiennent des drivers vidéo, réseau, permettent de partager des répertoires avec le serveur hôte, facilite l’usage de la machine virtuelle à travers l’interface Virtual Infrasctructure Client et permet un synchronisation de temps entre la machine virtuelle et le serveur hôte.
  Les programmes installés par les VMTools sont paramétrables sans difficulté.
- VMware Converter
  VMware converter est l’outil de virtualisation de serveurs de VMware. Ce produit est disponible en deux versions : Standalone ou Enterprise.
  Les deux versions sont capables de virtualiser un serveur « à chaud ». (Néanmoins, l’applicatif doit être arrêté) La version standalone est gratuite mais présente certaines limitations.
  La version Enterprise vient en bundle avec Virtual Center et est intégré à celui-ci. Cette version est capable de faire des virtualisations « à froid ».

Virtualisons, virtualisons...

Thu, 12 Apr 2007 18:39:53 +0200

La virtualisation...
La nouvelle marotte des DSI - Directeurs des Systèmes d'Informations - Lord of the Geeks quoi.. - Le nouveau grand défi des pauvres grouillots qui, comme moi, doivent mettre en place les solutions choisies par les incompétents en chef...

Qu'est ce que la virtualisation ?
En gros, c'est transformer un serveur physique en serveur virtuel. Cette définition ne vous avance pas ? C'est normal.
C'est très simple. Prenez un datacenter. C'est un espace où il y a plein de serveurs. Genre 10.000. Ces serveurs prennent de la place, chauffent comme c'est pas permis, consomment énormemment d'électricité. Le but du jeu est de transformer tous ces méchants serveurs, qui ne sont jamais utilisés à 100%, en de gentils serveurs qui ne seraient en vérité que des "programmes".
Si vous ne comprenez pas le principe, allez donc chez VmWare ( http://www.vmware.com ) les leaders du marché.

Actuellement, c'est ce que je suis en train de faire... Enfin... Superviser... Y a des sous-grouillots quand même pour faire ce types de basses besognes qu'est de transformer un serveur physique en virtuel. Moi je dis si ils ont bien fait leur boulot ou pas. - oupas oupas - Et en l'occurence, c'est limite oupas vu les boulets...

Le truc sympa, c'est que si tu veux héberger plein de petits serveurs, c'est qu'il te faut quelques gros serveurs. Des bons gros serveurs bien cons...
Genre : des serveurs tellement puissants qu'ils font sauter l'armoire électrique qui les alimente si on les allume tous. (4 serveurs... 4 putains de serveurs...)
C'est rigolo une fois... Surtout si tu perds certaines configurations...
C'est moins rigolo la deuxième fois...
Surtout si tu as une alimentation d'un de ces serveurs qui crame. Et qu'il faut bien évidement remplacer. Heureusement qu'il y a deux alimentations dans ces serveurs... Dommage que ces alimentations soient tellement mal placées que tu ne puisses pas les changer à chaud, malgré le fait que, théoriquement, ce soit possible. - Ca c'est pour ça que je bosses cette nuit... -
C'est encore moins rigolo quand un responsable se décide enfin à faire changer l'armoire... Ce qui implique que tes serveurs doivent être éteints... - C'est pour ça que je bosse la nuit dans 15 jours... -

Putain...

J'aime mon job...