Passez de VMWare à HyperV ? Est ce un projet finger in the nose ? Part 2

Bonjour à tous,

Voila déjà plusieurs mois depuis mon 1er article sur la migration

Vmware -> Hyper V que vous pouvez retrouver ici. Nous allons essayer de répondre intelligemment à ces quelques questions.

J’ai maintenant un peu plus de corde à mon arc pour vous en parler puisque cette migration (environ 250 machines virtuelles réparties sur plusieurs fermes ESX) est sur le point de se terminer en douceur d’ici fin d’année 2015.

 

  1. Y a t-il un intérêt à changer d’hyperviseur ?
  2. En pratique, est ce faisable ?
  3. A quel prix ? changement de matériel, formation, licence …
  4. Quels problèmes va t’on rencontrer ?
  5. Peut on se passer de SCVMM 2012R2 ?
  6. La gestion de la haute dispo est elle équivalente voir meilleur que sous ESX ?
  7. IDEM pour la live migration – vmotion

 

Y a t-il un intérêt à changer d’hyperviseur ?

Oui ! en tout cas dans notre cas, effectivement nous sommes une équipe de Windowsien et mettre les mains dans le cambouis dans un environnement FULL Microsoft apporte plus de compréhension, de facilité, d’autonomie et de visibilité à l’hyperviseur et l’ensemble des outils qui oscille autour de lui, pour ne pas les citer: la suite System Center 2012R2 avec Virtual Machine Manager, Data Protection Manager, Opération Manager, Orchestrator. La réponse aurait été la même si nous étions Linuxiens avec le souhait de remplacer Hyper-v par la solution VMWare.

Pour le coté financier, je ne peux hélas pas m’étaler, je n’ai pas eu à gérer cette partie, de plus chaque société dispose de ces propres partenariats que ce soit avec Microsoft, Vmware, CISCO et j’en passe, et en fonction, elle pourra avoir des tarifs plus ou moins compétitifs.

En pratique, est ce faisable ?

Oui ! mais non sans difficultés et son lot de surprise\blocage technique, ca prend également du temps, beaucoup de temps en fonction du nombre de VM à déplacer et du nombre de personne en charge de la migration. L’aspect « production » n’est pas à négliger, il est effectivement plus facile de migrer 30 machines virtuelles de qualité de dev de recette que de déplacer 5 vm de production que vous aurez à migrer en HNO avec le stresse d’espérer que tout se passe bien et avec un impact utilisateur proche du zéro absolu.

Sans trop exagérer j’ai le sentiment que chaque vm à ses particularités, son histoire, ses défauts …. voir un peu plus bas dans « Quelle problème va t’on rencontrer? ».

C’est génial de débuter la migration mais il faut également penser à sauvegarder les VM qui arrivent, au fil des migrations, sur l’environnement Hyper V, à les monitorer à nouveau etc .. il faut également prendre son temps et vérifier que le nouveau matériel absorbe bien la charge. Pensez à surveiller les IOPS et les temps de latence de votre SAN.

A quel prix ? changement de matériel, formation, licence …

Dans nos cas, le prix qu’impose l’achat de nouveaux serveurs DELL R630 avec double CPU E5-2667 v3 3.2Ghz, la RAM qui va bien (256Go sur chacun de nos 6 noeuds Hyper V), les switch CISCO dédiés au réseau ISCSI, les nouveaux SAN (NETAPP), il est difficile de prévoir au plus juste mais avec marge le dimensionnement d’une plateforme Hyper V. Faire en sorte que si un serveur crash, les autres tiendrons la charge supplémentaire le temps de le remonter. Une toute petite précision nous sommes effectivement partis sur une connectique de stockage à moindre coût, celle de l’ISCSI mais je ne vais pas plus m’étaler sur les choix d’infrastructure ici.

pour les licences nous utiliserons naturellement des licences Windows 2012R2 DC pour un nombre de VM illimité.

pour la formation, si il n’y a pas de compétence en interne, c’est plus prudent de se faire accompagner ne serait ce que quelques jours par une société externe, aussi bien pour la configuration du cluster Hyper V que pour la partie SAN et l’interconnexion des deux.

Heureusement ce n’était pas mon cas j’ai pu mener à bien ce projet et partager avec mes collègues mes idées, mes craintes, mes solutions de contournement.

Quels problèmes sommes nous susceptible de rencontrer ?

Alors il était difficile de deviner ce qui allait nous tomber dessus même avec un audit poussé. Mais avec le recul c’est tout de suite plus facile de vous en parler, surtout quand c’est encore tout chaud.

Dans un premier temps il y a la question de comment migre t on les données présentes sur un vmdk (vmware) en vhd(x) (hyper V)

Les serveurs ne sont pas les mêmes, les SAN ne communiquent pas entre eux, les technology de virtualisation sont différentes, idem pour les réseaux virtuels.

Il y a heureusement plusieurs options (non exhaustives j’imagine) mais avec ca vous devriez pouvoir vous en sortir.

La première vous passez par System Center Virtual Machine Manager 2012R2, mais là encore ca ne se fera pas à chaud ce qui implique un arrêt de production et c’est long …. très long …. très très très long…. pour avoir un ordre d’idée une douzaine d’heure pour une VM de 50Go. Il faudra également au préalable dégager le vswitch de la vm coté Vmware sans quoi SCVMM ne voudra pas la déplacer même éteinte.

Une fois terminée, la vm ayant été créée dans Hyper V vous n’aurez plus qu’à configurer la partie switch de la vm et reconfigurer l’@IP. Normalement SCVMM récupère l’ensemble des information de configuration, exemple RAM CPU. L’avantage est qu’il y a très peu de manipulation humaine. L’inconvénient étant la lenteur de l’opération.

La deuxième vous récupérez le(s) vmdk depuis le datastore puis vous le(s) convertissez en vhd(x) avec StarWind V2V Image Converter par exemple. La récupération du VMDK est également très lente. De l’ordre de 6-8Mbits/s. J’espère pour vous que si vous utilisez cette méthode vous aurez des meilleurs débits.

Là encore vous devez faire cela OFFLINE mais ca va ceci dit plus vite qu’avec SCVMM, vous aurez cependant besoin de reconfigurer entièrement la VM (vcpu, ram, remapper les vhd, etc ..). Si vous voulez éviter d’avoir à reconfigurer la VM, vous pouvez détacher tous les vmdk de la vm ESX et la migrer « vide » via SCVMM (premiere méthode).

Vous pouvez si la vm et l’application qu’il y a dessus le permettent cloner la vm ESX et ainsi récupérer le vmdk sans toucher à la vm encore en production. C’est possible si le delta entre le clonage -> la copie du clone ->  la conversion puis la création de la vm coté hyper-v peuvent être perdue, exemple un site web (blog ?) sur lequel tout le monde s’accorde à ne plus faire de modification le temps de la maintenance

Si toutes ces opérations vous prenne du temps, attention au redémarrage de la VM, il se peut qu’elle ne soit plus synchroniser avec votre AD. Il faudra alors réinitialiser le compte Ordinateur du serveur dans Active Directory, sortir la VM du domaine et rejoindre celui ci.

Troisième solution et c’est ma préférée, Disk2vhd, un petit utilitaire « efficace » de microsoft qui permet à la suite d’un snapshot de copier la vm vmware à chaud en .vhd sur un lecteur réseaux. Il ne vous reste plus qu’à créer la vm coté hyperV en pointant sur le vhd et ca boot. Quand vous êtes prêt, vous déconnectez le réseaux coté vmware de la vm encore allumée et vous activez le vswitch coté hyper-v. Il faudra en amont reparamétrer l’@IP sur la VM hyper V. Ce type de conversion, même rapide peuvent poser un problème si le delta entre l’opération disk2vhd et la mise à dispo de la vm sous hyper v prend trop de temps au risque de perdre des données, exemple une vm hébergeant une base de donnée.

Si on veut éviter une corruption de base de donnée, il est plus sage d’arrêter certains services avant le snapshot. (exemple SQLSERVER)

C’est également le seul outil à ma connaissance capable de récupérer le contenu d’un RDM. Petit bémol cet outil fonctionne qu’avec une VM source Windows. Pour les linux faudra passer par la solution 1 ou 2 ou 4.

En toute franchise j’ai déplacé 98% des VM Windows avec Disk2VHD.

Quatrième solution que je viens de découvrir post migration ………………….

Microsoft Virtual Machine Converter.  Je vais le tester ces prochains jours et vous faire un retour.

mais il semblerait que cet outil permet la migration à chaud des vm windows et linux selon la version installée. il est également capable de déinstaller les vmware tool et ce de façon entièrement automatisée.

Il permettrait aussi le P2V. Module disparue de VMM2012R2

ci dessous le snapshot réalisé par MVMC

image002

le suite de la migration, à mon grand étonnement, la VM source n’était pas accessible pendant la période de conversion, l’OS source était pourtant un Win 2008R2Sp1

 

image001 (1)

Fin de la migration

image001

ce n’est pas terminé, il faut ensuite configurer le réseaux virtuel de la VM et installer les services d’intégrations. Pour le délais je n’ai pas été bluffé. Encore une fois Disk2VHD est en tête mais la migration n’étant pas une course, ces différentes possibilités de migration peuvent vous attirer.

 

Peu importe de quelle maniere vous allez vous y prendre profitez en pour nettoyer la vm, les TEMP, les LOGS, les user Profils, les SoftwareDistribution directory, etc … ca sera toujours ca de moins à copier, on peut facilement récupérer une dizaine de Go. Ceci étant attention à ne pas abuser du nettoyage, garder en tête que si la migration se passe mal vous serez rassuré de pouvoir redémarrer la vm vmware le cas échéant en l’ayant laissée quasi intacte.

Ci dessous, une liste des problèmes rencontrés:

bon à savoir\retenir également -> https://technet.microsoft.com/en-us/library/dn792027.aspx

  • L’application ne démarre pas correctement, effectivement dans certain cas, les licences sont basées sur les @mac des serveurs! il vous suffira de reporter l’@mac de la vm ESX à celle d’HyperV.
  • Version windows non supportée (cf lien du dessus) -> impossible d’installer les services d’intégration, pas de réseau, pas de souris -> Service Pack à installer soit sur la VM déplacée via un ISO soit sur la source mais opération de migration à refaire et impact prod.
  • Version linux non supportée -> pour que la vm dispose d’une connection on va devoir passer un « legacy network », pas le choix -> baisse des performances réseaux. Je ne suis pas capable de juger de la baisse de perf, si elle existe vraiment et encore moins sa valeur en %. j’ai meme vue des VM linux refusant de booter tant que je n’avais pas retiré la carte réseau ou mis une carte virtuelle de type « Legacy network »
  • Perte du mdp admin local windows -> impossible d’installer les services d’intégration, refaire la migration en modifiant le mdp sur la VM source. C’est tout bête mais ca m’est arrivé … en effet vous avez beau vous etre logé en domain admin sur la vm avant la migration, je me suis vue refuser l’installation des services d’intégration et donc pas de détection de carte réseaux
  • internal error lors de l’installation des services d’intégration sur un win2008Sp2 par exemple. solution qui a fonctionné pour moi -> https://srvcore.wordpress.com/2010/05/28/integration-components-setup-error-an-error-has-occurred-internal-error/
  • Dans le même genre perte du mdp root linux -> impossible de paramétrer l’@IP de la nouvelle interface détectée.
  • Plus brutal, le fatal kernel error au boot d’une VM linux. Vous partez pour des heures de recherches sur google.
  • Os linux trop vieux -> le linux commence a charger puis s’arrête il ne trouve pas ses disk de démarrage car il est passé de sda à hda, rescue linux à faire, gparted dans certain cas, etc …. au secours !
  • Avec Vmm j’en ai également vu de toutes les couleurs j’ai du migrer 5 vm avec SCVMM puis les 100 autres avec la solution 2 ou 3 car il y a trop souvent quelque chose qui lui pose problème. C’est d’ailleurs hallucinant que Microsoft (outre MVMC et Disk2VHD) n’est pas facilité ce genre de migration. Et quel intérêt d’enlever le module P2V de SCVMM2012R2 ? ca fait tout de même râler.
  • la question des RDM (disks pass through coté Microsoft). Nous avons opter pour ne plus nous en servir et déplacer les data sur un vhd. Ce type de connectique n’a quasi plus aucun intérêt de nos jours. (hormis décharger le CPU car on ne passe pas par le system NTFS du parent). Encore une fois pour une VM windows ce n’est pas compliqué on se fait un robocopy /syncall /sec, coté linux, rsync vous aidera mais c’est tout de même moins évident avec les points de montage le fstab et j’en passe.
  • Quid des vmware tools ? Pour être franc je ne les ai pas retiré des machines virtuelles puisque je voulais modifier le moins possible les VM sources. Il faut maintenant prendre le temps de les retirer proprement …  si c’est faisable. Ca n’a pas l’air simple.

Peut on se passer de SCVMM 2012R2 ?

NON et OUI, non car vous devez obligatoirement passer par là pour la création de vos « logical switch » que vous viendrez ensuite distribuer à vos hotes Hyper V.

Vous passerez également par là pour la création de vos TEAMING dédiés au flux de vos machines virtuelles.

Vous devrez passer par là pour la migration de VM inter Cluster Hyper V et pour l’utilisation de template.

Vous devrez passer par là pour supprimer proprement une machine virtuelle. sans quoi il restera les dossiers vide de la VM voir pire le VHD.

si vous avez un abonnement avec des VM dans AZURE vous devrez également utiliser VMM pour les voir et les administrer.

en dehors de ca (je vais pas tout lister !) vous pouvez vous en passer.

Effectivement l’utilisation de l’hyper v manager et/ou la console de cluster management jouent également assez bien leur rôle. On peut pour ainsi dire tout faire à partir de là. Si je ne m’abuse certaines fonctionnalités telles que le status des repli sont beaucoup plus lisible via hyperV manager .

lorsqu’on travaille sous VMM on se rend vite compte qu’on est obligé de régulièrement mettre à jour le cluster les hosts et les vm sans quoi on a pas le vrai status à l’instant T, c’est très vite fatigant.

pour finir sur cette question, VMM reste l’outil qui permet d’avoir une vision globale de son infrastructure de virtualisation (ESX Vcenter et Hyper v + Azure dans la même console)

La gestion de la haute dispo est elle équivalente voir meilleur que sous ESX ?

je n’ai pas assez d’expérience pour juger Vmware à ce sujet.

je vais donc juger Microsoft uniquement. Nous avons eu beau plantage récemment.

sur notre cluster de production à deux nœuds, l’un des nœuds a redémarré violemment. Toutes les VM qui étaient hébergées sur ce dernier se sont mises à redémarrer sur le noeud encore actif jusqu’au moment où certaines VM n’ont pas pu démarrer faute de mémoire libre  🙂

bien dimensionner son infra c’est la clé du succès !

tout ca pour dire qu’on a beau tester\recetter son infra, y a que lorsque ca plante en pleine production qu’on voit si ca tient la route; et ce fut le cas. Alors certes on a eu une perte de la production, mais notre PCA a joué son role. Pour le manque de mémoire nous étions au courant ce qui nous a permis de rapidement éteindre les VM non critique afin de libérer quelques Go. Nous allons régler ce problème par l’ajout de deux nouveaux serveurs à notre cluster de production.

et c »est aussi dans ce genre de cas qu’on peut justifier que le budget alloué à l’infra n’était pas insensé. Quand on met tout ces œufs dans même panier à un moment donné il faut de la redondance partout sinon à quoi bon..

Gestion de la live migration – vmotion ?

je n’ai rien à dire sur la partie VMware, ca répondait vite et ca « faisait le job ». RAS

Idem pour la partie live migration de Microsoft, pas de mauvaise surprise, aucune perte de ping, l’utilisation de la bande passante est optimale. Attention tout de même lorsque vous déplacer plusieurs VM d’un seul coup, si l’une d’elle est arrêtée, vous allez lancer une quick migration de vos VM et non une Live migration … pas tout à fait pareil !

dans les best pratice de microsoft, il est préconisé un réseau dédié pour ce flux. J’ai toujours aimé séparer les flux que ce soit le heartbeat, les flux SAN, les flux d’admin, les flux de live migration, les flux de sauvegarde pourquoi pas ?

ceci dit, et cela m’a été imposé, pour nos serveurs sur les 8 ports ethernet Gigabits nous avons opté pour ceci:

un teaming de 3 ports pour l’admin, le heartbeat et la live migration

un teaming de 3 port en mode trunk pour le virtual switch des VM

2 ports ISCSI, avec chacun leur sous réseaux et MTU 9000.

ci joint un petit schéma ( merci à Swan pour sa maitrise de Visio :p )

HypV-Netapp

me voilà arrivé à la fin de cet article

en espérant qu’il vous a plu et qu’il pourra vous servir si un jour

vous partez en croisade VmWare -> Hyper V

Maxime

 

petite mise à jour de l’article

Les étapes d’une bonne migration

Ci joint la liste des tâches à réaliser lorsqu’on veut migrer une VM ESX vers Hyper V via Disk2VHD. J’espère que ca vous permettra de ne rien oublier

  • Communication aux utilisateurs et chef de projet J-1 Migration
  • Communication aux utilisateurs  et chef de projet jour J de la Migration
  • Créer le répertoire de la VM sur un LUN de votre cluster Hyper V
  • Préparer la VM – Audit du nombre de lecteur, leur lettre leur taille, le nombre de vcpu le nombre de RAM et la ou les IP, Audit applicatif, se renseigner si la licence applicatif est basée sur une @Mac par exemple, auquel cas pensez à la repositionner sur la vm Hyper-V
  • Nettoyer c:\temp + C:\Windows\SoftwareDistribution (arrêt windows update service avant) + C:\Windows\temp + C:\Users obsolète
  • Positionner le répertoire disk2vhd dans c:\temp
  • Vérifier qu’il y a un espace libre convenable sur le lecteur C:\ pour que disk2vhd puisse effectuer son snapshot
  • Arrêter les services applicatifs de la VM avant de lancer le disk2VHD exemple SQL Service
  • Une fois le Disk2VHD terminé, on a le ou les VHD dans le répertoire sur le LUN, on peut créer la VM à partir d’HYPER-V MANAGER en attachant les vhd et en positionnant la RAM, ajouter la carte réseaux sans la connecter, cette étape sera réalisée via VMM uniquement
  • Retourner dans la configuration de la VM et ajuster le nombre de VCPU
  • Vérification : Démarrer la VM et vérifier qu’elle boot et qu’elle retrouve ces lecteurs. il est possible qu’il y est une première demande de reboot
  • Installer les services d’intégration Hyper V, il faut redémarrer encore une fois la VM la plupart du temps.
  • Au redémarrage, positionnez l’@IP récupérer dans l’ancienne VM et l’@mac si besoin de la conserver
  • Via la console Cluster Manager, ajouter la VM au cluster en faisant clic droit sur roles -> Configurer role -> Next -> Virtual machine -> votre VM fraichement créée puis Next Next et Next
  • Une fois la VM Hyper V complètement prête, on va pouvoir couper le réseaux de la VM ESX, exécutez un ping -t vers l’ip de la vm
  • Allez sur VCenter, dans les paramètre de la VM ESX, décoché Connected sur l’interface réseaux pour qu’on commence à perde le ping vers la VM que l’on migre
  • Dès qu’on perd le ping, allez sur la console VMM, positionnez vous sur la conf de la nouvelle VM HYPER-V et connectez votre interface au réseau (je ne rentrerai pas dans le détail des VLAN) puis OK, la machine virtuelle va s’actualiser, si la conf IP et Gateway sont bonnes, le ping devra revenir positif, à partir de là, redémarrer la VM encore une fois
  • Vérifier que l’applicatif répond bien au redémarrage
  • Vérifier sur votre outil de monitoring que les services sont UP
  • Dans la VM Hyper V, désactiver le service Vmware tool, il est préférable de déinstaller les VMware tool avant mais moins pratique en cas de retour arrière d’urgence.
  • Concrètement la migration est terminée, il reste des tâches de fond
  • Communiquer pour cloturer l’opération
  • Eteindre la VM ESX qui n’est plus accessible
  • Si retour OK des utilisateurs le lendemain de l’opération, ajouter la VM Hyper V à votre outil de sauvegarde
  • Si retour OK Global le sur lendemain renommer la VM ESX en « NomdelaVM-MIGRE HV »
  • A J+7 de la migration – faire un remove from inventory de la VM ESX migrée
Cette liste de tâche je m’en suis servis pour migrer plus de 300VM en quelques mois. C’est concluant.

 

Publicités

Mise en place d’une solution de Reverse Proxy avec le module ARR de IIS

A quoi peut bien servir un reverse proxy (RP) ?

Comme à mon habitude, je vous renvoi vers une définition déjà complète présente sur internet

http://fr.wikipedia.org/wiki/Reverse_proxy

Grosso modo, pour ceux qui ne souhaiterai pas aller lire ;p il s’agit d’un élément physique ou logiciel, qui se positionne en amont des frontaux web et les protège ainsi des attaques extérieures.

Un RP représente également un seul point d’entrée des flux en provenance du web et à destination des serveurs web. Qui dit un seul point d’entrée dit réduction du nombre des @IP publique.

Nous pouvons également l’utiliser pour faire de la répartition de charge

Etc..

Dans mon cas précis, la société utilise sharepoint server 2010 comme outil collaboratif et les utilisateurs y accèdent via cette URL ->  http://sharepoint

L’idée est de rendre cet intranet accessible également depuis l’extérieur. (Attention, je ne parle pas d’extranet …)

 

Pour parvenir à notre objectif nous avons plusieurs possibilités telles que:

choix 1) Mettre en place une redirection de port sur notre FW internet. port dest TCP 80 vers port destination TCP 80 à destination du serveur sharepoint.

choix 2) Faire la même chose mais en HTTPS port TCP 443

choix 3) Encore plus sécurisant, HTTPS + Reverse Proxy

Vous l’aurez compris nous allons nous intéresser au choix n°3 car:

– le choix 1 n’est pas envisageable car les mots de passe d’authentification circuleraient en clair sur interne

– le choix 2 est plus sécurisant mais expose toujours notre serveur web aux attaques provenant d’internet

Comme je vous l’expliquais plus haut, le RP est le meilleur choix car il va permettre de:

– masquer la véritable @IP de notre serveur

– de faire de la réécriture d’URL

– d’être en frontal et ainsi en cas d’attaque, le serveur web sharepoint ne sera pas impacté, l’accès depuis internet pourrait être down si le RP était amené a tomber mais l’accès en interne fonctionnerait encore.

– de faire de la répartition de charge si tant est qu’il y a plusieurs serveurs web derrière.

Les étapes à suivre:

  1. Choix du Reverse Proxy, ici on prend le module ARR de IIS (Application Request Routing)
  2. Création de la vm ou du serveur et on le positionne en DMZ svp !
  3. Choix du nom de domaine externe exemple sharepoint.masociété.com
  4. Configurer sharepoint pour qu’il réponde aussi bien en https:\\sharepoint qu’en https://sharepoint.masociété.com
  5. Si on veut faire les choses proprement on fait une demande de certificat à une entité externe telle que verisign (avec la liste exhaustive des noms sharepoint à prendre en compte) sinon on peut dans un premier temps commencer par faire une demande à l’autorité de certificat racine de son domaine.
  6. Lier ce certificat au serveur sharepoint mais aussi au RP (exportation du certificat puis importation)
  7. Créer la règle de redirection sur le RP
  8. Faire des tests 🙂 si tout va bien vous ne devriez pas avoir d’alerte de certificat puisqu’en frontal IIS ARR vous présentera le certificat publique
  9. Enjoy your public sharepoint site

vous aurez les screen shot quand j’aurai un peu plus de temps à consacrer à cet article! 🙂

A bientot

Passer de VMWare à HyperV ? est ce un projet finger in the nose ? part 1

Hello à tous,

tout d’abord, je tenais à vous rappeler que malgré le fait que vous soyez des millions voir des centaines de milliard à consulter régulièrement mes articles je continue de poster en français 🙂

Tout ou presque est dans la question. Mais cela soulève en fait d’autres questions avoisinantes telles que:

  1. Y a t-il un intérêt à changer d’hyperviseur ?
  2. En pratique, est ce faisable ?
  3. A quel prix ? changement de matériel, formation, licence …
  4. Quels problèmes va t’on rencontrer ?
  5. Est ce financièrement intéressant court , moyen et long terme ? cela rejoins la question 1
  6. Comment migrer les machines virtuelles sans impacter la production ?
  7. Peut on se passer de SCVMM 2012R2 ?
  8. La gestion de la haute dispo est elle équivalente voir meilleur que sous ESX ?
  9. IDEM pour la live migration – vmotion

je reviendrais compléter ce post au fur et à mesure de mes découvertes !

en attendant je vous laisse sur votre faim :p

Salutation les blogueurs.

Maxime

Externalisation de la messagerie In The Cloud … ou pas.

Bonjour à tous,

un petit article, déjà d’une car cela fait un moment que je n’ai pas posté faute de temps.

Les causes: changement de boulot, jeune papa … bref de quoi m’occuper encore pas mal de temps.

Mais aujourd’hui est THE jour ou je vous consacre quelques minutes et quelques lignes de lecture autour du cloud.

Je ne vais pas vous en parler des heures mais vous exposer rapidement une problématique professionnel qui me concerne en ce moment.

« Du haut » de mon nouveau statut de Responsable Informatique, j’ai pour mission « demain » de faire en sorte que tous nos collaborateurs disposent d’une @mail du type m.jouan@masociete.com.

L’état actuel de la messagerie de la société est le suivant:

Faisant partie d’une SSII, seuls les membres du/des sièges disposent d’une @mail corporate. Vous l’avez compris, les collaborateurs envoyés en clientèle ont .. walou. Ce qui représente à la louche 150 internes et 450 externes.

Aujourd’hui nous hébergeons les 150 boites aux lettres en interne à l’aide d’Exchange 2007 sur 3 serveurs + une baie de stockage.

1 serveur transport HUB et 2 serveurs de boite aux lettres montés en cluster CCR (cluster à copie continue). Ces serveurs IBM ont environ 4-5 ans et ne sont plus sous garantie.

La baie est également de type IBM et est reliée en fibre optique aux deux serveurs de boite aux lettres pour l’accès aux banques de données. Elle non plus ne dispose pas de contrat de support.

En frontal de tout ceci est branché un FireWall Fortinet 100c avec support, entre parenthèse c’est lui qui joue le rôle de backbone.

Voilà pour résumer la situation et le besoin, maintenant s’offre à nous plusieurs possibilités pour faire évoluer l’existant et pouvoir absorber la charge qui passerait de 150 utilisateurs à 600 en un mois ou deux selon le temps pris par la migration.

En gros de ce qui l’en ressort (en tout cas de mon point de vue):

– Soit on continue de gérer le service de messagerie en interne sur nos serveurs obsolètes (achat\location de nouveaux serveurs ? on en profite pour migrer sous Exchange 2010 ?)

– Soit on réfléchie à la solution proposée par le Cloud autrement appelée SAAS qui me permettrait d’externaliser la messagerie sous Exchange ou Zimbra par exemple. L’idée est de disposer de compte « complet » (partage de calendrier, synchro iphone) pour les 150 internes et de compte light pour ceux en clientèle (accès webmail 500Mo)

Si vous voyez d’autres solutions auxquelles je n’aurai pas pensé je suis preneur.

M’en vient à vous parler des avantages et inconvénients de ces deux solutions. Ce qui va suivre ne s’applique pas uniquement à mon besoin mais je pense est assez exhaustif à toute société ayant le même projet d’externalisation/refonte de sa messagerie.

Pour une messagerie interne:

Avantages:

– Réactivité du service informatique en cas de simple demande (ajout d’un membre dans une liste de diffusion par exemple)

– Total autonomie sur le choix et l’évolution de l’infrastructure des serveurs de messagerie (nouveaux serveurs, ajout de noeud, ajout de règle FW, choix des baies de stockage..)

– Les mails entres membres internes ne circulent pas sur le net

Inconvénients:

– Si demain 450 externes viennent faire du webmail -> augmentation de la charge internet donc upgrade du/des liens internet.

– Dans le cadre d’un service informatique à taille humaine, il est impossible d’assurer une disponibilité des services égale aux grand datacenter c’est à dire >= 99,9% due aux congés, astreintes pas astreintes, due aussi aux manques d’expertise sur le produit en cas de panne Exchange, ou tout simplement coupure électrique prévue sur le bâtiment ou dans le quartier.

– Héberger un exchange c’est savoir répondre à n’importe quelle problématique, il ne s’agit pas de passer 3 jours sur un problème bloquant toute la société.

– C’est aussi assurer tous les niveaux de supports, ce qui chargera rapidement un administrateur. Peut être pas avec 150 comptes mais 600 … (changement de mot passe, compte verrouiller etc..)

Sans compter tous les appels téléphoniques (« je ne reçois pas mes mails », « c’est quoi la taille max d’une pièce jointe », etc ..)

– L’accès internet, si celui-ci est coupé, la messagerie est paralysée que ce soit pour les internes comme les externes.

– Dernier inconvénient le prix:

  1. Des licences OS serveurs
  2. Des licences Exchange serveur
  3. Des licences d’accès cliente CAL
  4. Prix des serveurs avec support sur 3 voir 5 ans qui généralement double le prix de départ.

Pour une messagerie externalisée:

Avantages:

– Plus de serveurs obsolète au bout de quelques années

– Réduction d’électricité (cela passe bien en ce moment tout est bio et vert)

– Aucune licence exchange serveur ou OS est à acheter (il est possible de transférer sa licence Exchange actuel interne vers un Exchange en cloud)

– La haute dispo du service >99,9% est cette fois assurer par de gros Datacenter redondés les uns aux autres et généralement reliés en fibre noir.

– Les soucis matériels exemple perte d’un disque dur, serveur qui reboot etc ne sont pas à prendre en compte.

– La sauvegarde est effectuée par l’hébergeur. (Attention tout de même à bien se renseigner à ce sujet, certaines formules vous permettrons de restaurer un mail supprimer y a 30j mais pas plus)

– Permet à l’équipe informatique de s’enlever une épine du pied et de travailler sur des projets moins lourds en administration quotidienne.

– Si le lien internet de la société tombe, l’accès webmail peut encore être joint à partir d’un Iphone en 3G par exemple.

Inconvénients:

– Ici aussi, il y aura très probablement besoin d’augmenter la bande passante internet car si demain on externalise la messagerie, après demain ce sera peut être la messagerie instantanée avec Lync.

– On perd en réactivité, on imagine bien qu’un technicien cloud n’est pas dédié à notre société, donc en cas de question/problème technique, il faudra très certainement passer par la création d’un ticket d’incident, avec des délais GTI et GTR.

– Cette fois, tous les mails y compris ceux de l’interne vers interne passeront par internet. Ce qui utilise de la bande passante bêtement j’ai envie de dire.

– Dernier point négatif et pas des moindres, le retour en arrière si on se retrouve dans une situation ou la solution cloud n’est pas satisfaisante. Bien s’assurer que celui-ci est possible et pas trop complexe. Comment récupérer les boites mails, comment repartir sur une nouvelle infra etc etc ..

Voilà pour ce poste, j’espère qu’il vous servira à vous poser les bonnes questions et surtout à ne pas se précipiter.

Pour ma part, je parts dans l’optique qu’une migration vers le cloud n’est pas simple à mettre en place car beaucoup d’acteurs et de compétence entrent en jeu (hébergeur, partenaire, service informatique, direction financière, compétence système, réseaux et sécurité) mais que le jeu (et oui faut quand même s’amuser!) en vaut la chandelle et que les bénéfices apportés par cette solution auront un impact positif sur le service informatique et sur la société en elle même.

J’attends avec impatiente vos commentaires si j’ai omis un détail important ou dit une grosse ânerie , faite le savoir!

Bon cloud à tous!

A la découverte de la solution Citrix XenServer (partie 3)

Dans la première partie on a pu voir la configuration de la vm sous Workstation 8.0

Dans la seconde, l’installation de Xen Server

Dans cette partie nous allons voir comment accéder à notre serveur et ainsi pouvoir l’administrer et commencer la création du cluster.

Installation de Xen Center, cet outil se trouve sur le cd d’installation de xen server

CD-ROM\client_install\XenCenter.msi

Il n’y a pas plus simple comme installation ..

Une fois Xen Center lancé, on peut ajouter nos deux serveurs Xen comme ceci

pour attacher Xen server à Xen Center, on doit connaitre l’@IP de management de Xen server + login et mot de passe root

Une fois attaché, le serveur Xen serveur apparait tel quel

Il faut évidemment faire la même chose avec le second serveur Xen

ce qu’il me reste à faire maintenant:

1) Paramétrer le disque partagé entre les deux Xen server sur mon SAN via Starwind

  • ajout d’un disque à la VM Win2008
  • création d’une cible ISCSI sous Starwind
  • Attachement du disque à la cible ISCSI fraîchement créée

2) Créer un réseau privée en 10.0.0.x/24 pour le SAN et les deux Xen Server

  • Une carte réseaux en 10.0.0.1 à déjà été ajoutée à ma VM Win2008
  • Ajout de carte réseaux sur les deux VM Xen Server
  • Reboot des serveurs Xen pour prise en compte du nouveau matériel
  • Paramétrage IP via Xen Center
  • Ajout du disque partagé sur les deux Xen Server via Xen Center et ISCSI

3) Créer le Pool de serveur Xen, autrement dit, le cluster Xen
4) Créer une machine virtuelle
5) Faire des tests de crash Xen pour s’assurer que la vm bascule bien d’un hôte à l’autre sans perte de connectivité

1) Paramétrer le disque partagé entre les deux Xen server sur mon SAN via Starwind

StarWind ISCSI permet de simuler une baie SAN pour l’attachement des LUN

ce logiciel s’installe sous win2008 et s’administre via une interface graphique

la première chose à faire dans mon cas est d’ajouter un nouveau disque dur virtuel à ma machine virtuelle Win2008

je me servirai de ce nouveau disque pour le stockage des VM du cluster Xen server

Création d’un nouveau disque dur

Seul le type ISCSI est accessible lorsqu’une vm tourne

Dans l’exemple la taille est de 50Go mais en réalité j’ai mis 80Go

Configuration de starwind

Comme on peut le voir sous windows 2008, il y a bien un nouveau disque détecté dans le gestionnaire de disque, vous pouvez faire annuler, il n’y pas de manipulation à faire à ce niveau là.

Sous Starwind, créer une « target » avec « add target », et bien penser à cocher « allow multiple concurrent ISCSI connexion (clustering) »

Donner lui un nom exemple cluster-xenserver-storage

Petit récapitulatif avant de terminer

Attribuons maintenant notre nouveau disque récemment ajouté à cette cible ISCSI (cluster-xenserver-storage)

Ajout disque dur

De type physique (il est émulé en tant que physique mais il est bien virtuel j’espère que vous suivez !)

Sélectionnons le bon parmis les autres disques déjà présent, généralement c’est celui qui à le chiffre le plus haut, ici il s’agit de « device address » -> 2,0,4,0

Cache inactif

Petit récapitulatif avant de terminer

2) Créer un réseau privée en 10.0.0.x/24 pour le SAN et les deux Xen Server et Ajout du LUN

  • Une carte réseaux en 10.0.0.1 à déjà été ajoutée à ma VM Win2008
  • Ajout de carte réseaux sur les deux VM Xen Server
Pour ajouter un périphérique, il faut aller dans Setting
puis cliquer sur ADD
choisir Network adapter..
On sélectionne Host-only pour avoir un réseau privé
On voit donc 2 carte réseaux correspondant à cette machine virtuelle
Retournons sous XenCenter, normalement il y a une fonction RESCAN qui permet de détecter les nouvelles cartes réseaux, chez moi ca ne fonctionne pas je suis obligé de reboot le serveur Xen
Une fois redémarre, si on rescan, la nouvelle carte réseau apparaît déconnectée
c’est à faire sur vos deux serveurs XEN bien sur.
  • Paramétrage IP via Xen Center
La nouvelle carte réseaux se configure dans l’onglet Networking
Ajout d’un réseaux Externe
Mettre un nom à ce réseau
Lui attribuer une carte réseau physique
Dans un second temps, cliquer sur « Configure »
Puis New Interface
Donnez un nom à notre interface exemple ISCSI puis sélectionnez notre nouveau réseaux ici « réseaux ISCSI » et configurer l’@IP
j’ai utilisé un @IP static en 10.0.0.1 pour la baie et 10.0.0.2 et 10.0.0.3 pour mes deux hosts Xen
Voilà le résultat final
  • Ajout du disque partagé sur les deux Xen Server via Xen Center et ISCSI

Dans l’onglet Storage cliquer sur New SR

Sélectionnez Software ISCSI puis Next

Donnez un nom puis suivant

Indiquez l’@IP du la cible ISCSI ici c’est notre baie en 10.0.0.1 puis cliquez sur Discover IQN de sorte à afficher l’ensemble des cibles ISCSI

Une fois que l’on a sélectionné notre cible on clique sur Discover LUN pour afficher notre future disque dur

Puis cliquez sur Finish

petit avertissement de formatage cliquez sur yes

petit message d’erreur que je cherche à corriger :p

Voila qui est fait, en fait il fallait retourner sur le NAS et dans gestion des disques il fallait mettre en ligne le nouveau disque détecté sans quoi Xen Center n’arrivait pas à le formater..logique vous me direz ..

Voila le résultat

Logiquement on pourrait penser qu’il faut faire la même manipulation sur le second Host Xen server hors vous aurez un avertissement du type:

« This LUN is already in use as SR Stockage VM en cluster on server Cluster-xenserver2 »

Pour résoudre ce message il vous reste simplement à créer le cluster XEN, de cette manière, le SR monté sur Cluster-xenserver2 va automatiquement être monté sur Cluster-xenserver1

Création d’un nouveau POOL

Donnez un nom à ce Pool et indiquez qui est le serveur Maître, ici je n’ai pas le choix ce sera xenserver2 le maitre

Un petit screen shot de la configuration finale

Contrairement à l’installation d’un cluster Hyper-V ou VMWare, j’ai l’impression que Xen effectue très peu de vérification avant de créer ce dernier ce qui rend l’installation presque simpliste…

Nous voilà rendu à l’étape suivante:

4) Créer une machine virtuelle
5) Faire des tests de crash Xen pour s’assurer que la vm bascule bien d’un hôte à l’autre sans perte de connectivité

 

Nous verrons tout ca dans un prochain article.

A la découverte de la solution Citrix XenServer (partie 2)

Installation de Xen Server pas à pas

Lancement de l’installation du serveur Xen

choix de la langue du clavier

xen nous prévient que l’installation écrasera tout sur le disque d’installation

Acceptation des termes du contrat CITRIX

Message d’avertissement car j’ai omis d’activer la virtualisation lors de la création de la VM Xen Server, cependant le processus d’installation peut malgré tout continuer.

Xen nous demande où souhaitons nous stocker les futures machines virtuelles, pour l’instant je n’ai pas le choix car qu’un seul disque.

le media d’installation est local, c’est à dire émulé comme un CD-ROM

xen nous demande si nous souhaitons installer des composants supplémentaire, pour l’instant non

Il y a la possibilité de tester le media d’installation avant de lancer l’installe

vérification du média

le media est clean

l’installation commence réellement, on nous demande de rentrer le mot de passe root du serveur

puis d’indiquer l’@Ip du serveur, je laisse en DHCP pour l’instant, mais il est évident qu’un serveur doit disposer d’une @IP fixe

indiquer ensuite le nom d’hôte exemple XenServer1 et préciser si les DNS sont attribués automatiquement ou pas.

Ensuite, on doit rentrer le choix de la région et de la ville

Paramétrage du service NTP, synchronisation de l’horloge

il est préférable de se synchroniser sur une source externe, pour un lab, je pense qu’il est tout de même inutile de se soucier de ce genre de détail.

Il n’y a plus qu’à lancer l’installation

Progression de l’installation

Installation réussite le serveur va redémarrer

Une fois redémarré voilà ce que vous devriez obtenir à peu de chose prêt que votre configuration IP sera probablement différente.

Ici, l’@IP 192.168.87.147 va nous permettre d’administrer notre serveur XEN.

Comme il est question de construire un cluster Xen, l’idée est de refaire extactement le même process pour avoir un second hôte, en changeant le nom d’hôte en « Xenserver2 » par exemple.

A la découverte de la solution Citrix XenServer (première partie)

Installation d’un cluster Xen Server

Et oui en parallèle de mon pseudo « laboratoire » VMWare ESxi, j’ai monté un 2ème « lab » pour tester la virtualisation mais cette fois sous XenServer.

Toujours dans un environnement clusterisé bien évidemment 🙂

La première partie décrit uniquement le paramétrage de la VM XenServer sous Workstation 8.0

   On sélectionne Custom afin de personnaliser notre machine virtuelle

 On sélectionne le mode de compatibilité le plus haut

 On indique le path pour l’image d’installation de Xen Server

 Au niveau du type d’OS, j’ai choisi Other 64Bits

 Il reste a indiquer le nom de la vm et le path par défaut de celle-ci

 Coté processeur, il y aura 1 processeur muni de 4 coeurs
 la vm disposera de 3 x 1024Mo

 coté réseau il y a pour l’instant qu’elle seul interface réseau public en 192.168.87.x

 j’ai laissé cet onglet par défaut

 Création d’un nouveau disque dur virtuel

 avec une interface IDE

 la taille est de 15Go, pas besoin de plus sachant que l’idée est d’avoir les VM sur un SAN partagé avec un second host Xen Server

 on indique le path du disque dur virtuel

 Résumé de la machine virtuelle puis Finish

A la découverte de vSphere (partie 3)

Mon cluster ESXi fonctionne enfin ! 🙂 mais ca n’a pas été sans douleurs..!

un petit schéma récapitulatif de l’infra de lab, je n’ai pas eu le temps de vous faire un magnifique schéma milles excuses.

Pour résumer, tout se passe sur mon PC seven

sur lequel je fais tourner:

  • VMWare Workstation 8.0
  • VMWare Vcenter Server
  • VMWare Client

Sur VMWare Workstation 8.0 j’ai crée 3 machines virtuelles.

  • Un hote ESXi 5.0
  • Un second host ESXi 5.0
  • Un Win2008R2 DataCenter pour simuler un SAN avec l’outil Starwind ISCSI

VMWare Vcenter Server permet de manipuler et de configurer nos hôtes ESXi, il permet en autre la création du cluster.

Contrairement à ce que je pensais, c’est un logiciel et non un OS il peut donc être installé sur un OS serveur tel que Win2008.

Mais dans mon cas, il a été installé en local sur seven, !Attention! ce n’est pas supporté par VMWare. Il y a en effet quelques manipulations à réaliser pour que l’installation s’opère bien sous Seven. cf le lien suivant -> http://communities.vmware.com/docs/DOC-16950

Ci joint un document PDF récapitulatif sur les OS compatibles avec une installation VMWare Vcenter Server  -> vsp_compatibility_matrix

VMWare Client permet d’accéder soit directement à un serveur ESXi soit d’accéder à Vcenter Server.

Ci joint les différentes source qui m’ont permis d’avancer sur le sujet:

Un powerpoint sur la création d’un cluster -> http://www.slideshare.net/esloof/introduction-vsphere-5-high-availability-ha

Tuto pas à pas pour y arriver -> http://www.tuto-it.fr/ClusterVcenter.php

Une introduction à VSphere -> VMware-Introduction-to-vSphere-PG-FR

Bientôt une ribambelle de screenshot pour vous expliquer l’installation pas à pas et de A à Z.

A la découverte de vSphere (partie 2)

Finalement,  contrairement à ce que je pensais il n’y a pas si longtemps  https://blog.virtuoze.fr/2012/05/02/a-la-decouverte-de-vsphere/, installer une maquette VMWare ESXi 5.0, c’est la croix et la bannière…

Mais qu’est ce qui leur a pris à VMWare de rendre les choses si complexe ??????

petit rappel sur la définition de « complexe » qui à mon gout est en adéquation avec le produit…

Un complexe est un tout qui comprend un certain nombre de parties, en particulier avec des parties interconnectées ou reliées mutuellement.

Avec Hyper-V en quelques cliques on peut avoir un cluster opérationnel.

Vmware, avant de comprendre comment installer le host, comment gérer le host, comment mettre en place un cluster ESXi il s’en passe du temps… et le temps je le passe sur le site de VMWare a essayer de comprendre la différence entre chaque composants de la solution, car des composants, il y en a la pelle..

L’idée de départ semblait pourtant simple mais il y a des points de blocage:

Les étapes:

  1. 1ère étape: L’installation de workstation 8.0 pour la gestion des machines virtuelles, dont mes deux serveurs ESXi, ça, ça va…
  2. Installation du premier serveur ESXi
  3. Installation du deuxième serveur ESXi
  4. Ajout d’une VM sur l’un des mes serveurs ESXi
  5. Mise en place du cluster entre mes deux serveurs
  6. Test du cluster avec errêt du noeud actif
  7. Fêter ma victoire :p

Pour l’instant je bloque à l’étape 5 car je ne trouve pas l’option ou l’outil qui me permettrait de configurer le cluster…

Si je ne m’abuse, en plus de l’installation de VMware Vsphere client pour la gestion des serveurs ESXi, je dois installer un module complémentaire nommé VMware High Availability (HA), outil nécessitant VMWare VCenter server

C’est ce que j’essaye de faire désespérément ces derniers jours avec l’ajout d’une nouvelle machine virtuelle car comme son nom l’indique (VMWare VCenter server)  il s’agit d’un serveur.

Désespérément car je suis confronté à des erreurs linux lors de l’installation… (génial..)

Je vous fait un petit screen shot très bientôt

Le CDN kezako ?

Acronyme de:  Content Delivery Network

 

Le plus simple pour vous expliquer l’idée générale est l’utilisation d’un cas pratique:

 

Un Australien tape dans son navigateur l’URL suivante: http://blog.virtuoze.fr

Si on fait une résolution DNS classique, ce nom de domaine pointe sur un serveur français (pas le peine de vérifier, c’est uniquement à titre d’exemple ^^)

Qui dit serveur Français et client Australien dit longue distance entre les deux… donc une page web qui peut prendre du temps à s’afficher.

Certes, sur des connexions ADSL, le site web s’affichera assez rapidement… mais on peut encore améliorer la rapidité d’affichage en réduisant la distance….

 

Le CDN va justement permettre de rapprocher les deux, le client et le serveur…. mais comment ?

En réalité, le CDN est un réseaux de serveurs dispatchés dans de nombreux pays …. on parle de serveur mais on peut surtout parler de cache mémoire.

En effet, le rôle de ces serveurs géographiquement mieux placés est de répondre à ce client à la place du serveur situé à l’origine en france.

– premier avantage, on décharge le serveur français

– deuxième avantage, le page web s’affiche plus rapidement sur le navigateur de monsieur Kangourou

 

On a pas encore réellement répondu à la question du comment ca marche ?

Pour ce faire, le réseaux de serveurs CDN doit en amont récupérer l’intégralité ou une partie du site web http://blog.virtuoze.fr situé en france.

C’est ce que le serveur CDN Australien se chargera de faire.

Ensuite en fonction de notre architecture web, les pages web changent plus ou moins souvent, il sera alors possible d’indiquer aux serveurs CDN de se mettre à jour par rapport au serveur français, régulièrement ou pas.

 

Plus concrètement, je vous ai parlé plus haut de la résolution DNS de blog.virtuoze.fr, pour passer sur le réseaux CDN, il faudra faire pointer le nom de domaine blog.virtuoze.fr sur une @IP CDN.

C’est le réseaux CDN qui, en fonction de la provenance de la requête web, répondra au client par tel ou tel serveur proche de celui-ci.

 

Voilà une brève initiation à la découverte de cette technologie qui séduit de plus en plus de sociétés. Sociétés qui, finalement, peuvent traiter avec l’international sans avoir peur d’afficher des temps de réponse ridicule.

 

Pour la petite info, l’hébergeur OVH propose cette solution.

Leur explication autour du CDN est d’ailleurs assez enrichissante -> http://www.ovh.com/fr/cdn/