[Virtualisation] Où ? Quand? Comment? Pourquoi?

Technique
1

Bonjour à tous,

Le CLOUD est partout, la virtualisation on en parle tous les jours. Les ressources pour en apprendre sur le sujet sont nombreuses mais pas forcement toutes pertinentes.

Je songe depuis quelques semaines à « virtualiser » mon infrastructure mais avant de franchir le pas, J’aimerais donc savoir si vous avez des bibles sur le sujet, votre avis, vos retours d’expériences.

J’ai un client qui utilise VMWARE pour son infrastructure, cela semble bien fonctionner. D’après quelques échanges que j’ai eu avec l’équipe IT, le plus gros challenge, c’est de créer le réseau entre les machines virtuelles.

Cyril

2

Je ne vois pas en quoi c’est un challenge de créer le réseau entre les machines… Tu peux décider de créer un réseau « local » entre chaque machine (de sorte à en protéger certaines d’un accès « public »); ou de faire pointer une IP WAN sur chacune… Bref, à toi de faire la configuration et c’est assez permissif quant à ce que tu veux faire…

Pour ma part, je virtualise tout depuis plusieurs années avec VMWare ESXi… aucun souci et une facilité de migration inégalée. La VM devient trop petite ? Il suffit de la migrer sur un autre hôte (dont le disque est + gros) et de redimensionner sa taille… Aucune réinstallation à prévoir.

Bref, je suis conquis… (je m’occupe d’hébergement depuis plus de 10 ans, au départ sur des serveurs mutualisés, puis dédiés… pour au final passer à la virtualisation). Si tu as des questions précises, n’hésite pas…

3

Oui sans être un challenge, cela semblé quand même plus compliqué à mettre en œuvre. As-tu des livres sur le sujet à conseiller?

Cyril

4

Si tu veux avoir des ressources et des conseils de personnes qui touchent vraiment leurs billes il faut aller sur la communauté Vmware: https://communities.vmware.com/

Si c’est pour de la prod, je te conseille fortement de passer à Vsphere, Esxi n’étant que l’hyperviseur (c’est bien pour se faire la main mais pas en prod… c’est lourd à gérer).

Vmware kit Essential est très abordable (450$) et te permet de disposer du Vcenter server.
Vcenter server est un service console (c’est une VM tout simplement), qui donne accès à l’hyperviseur et au système VMFS… c’est carrément confortable… sinon c’est tout en mode SSH ligne de commandes(pas marrant du tout).

Mais si tu veux vraiment disposer de toute la puissance de la virtualistation, c’est à dire:

  • la migration à chaud des machines
  • La haute disponibilité (bascule d’un serveur physique vers l’autre en cas de panne… avec relance des Vm)
  • La sauvegarde, via dataprotection (il y a quelques problèmes avec la librairie, Veeam est une meilleure alternative)
  • Ou la réplication (Vsphere replication),
    Il faut passer par Vmware kit Essential+

C’est 10 fois plus chère mais je sais qu’il existe un Bundle pour ferme de 3 serveurs plus qu’abordable (il faut appeler Vmware: ils ne vendent pas directement mais apportent d’excellents conseils)
C’est largement suffisant pour des structures jusqu’à 150/200 personnes (si pas trop de DB à forte concurrence et pas d’I/O de malades sur tes serveurs).

Mais tu n’utiliseras que 2 licences, une par serveur (1 répliquant l’autre)

Par contre, 2 monstres: pas lésiner sur le nombre de coeurs… attention, je parle de coeurs et pas d’hyper threading / et sur la RAM: fait un audit des serveurs existants pour dimensionner les bêtes (I/O, ressources proc utilisés, ressources RAM utilisés, etc.)
-> je connais pas ton infra ni sa charge, donc derniers conseils à ne pas prendre au pied de la lettre.
Mais attention quand même: avec des serveurs entrées de gamme et pas trop costaud tu risques d’être déçu suivant l’utilisation que tu souhaites en faire… alors que la virtualisation via Vmware améliore les perfs des serveurs sur certains points.

Et bien sur: RAID 1 sur le système et pour le reste… ça va dépendre de l’utilisation des Vm et du nbr d’I/O sur tes disques (prends du SATA-3 si tu veux faire des économies… pas n’importe quels disques)

Et si en plus tu couples la virtualisation de tes serveurs avec la virtualisation de ton stockage… là tu entres véritablement dans le monde du Cloud.

Mon conseil: parts directement sur Vsphere (le 1er kit Essential ou le bundle 3 serveurs Essential+), trouves des ressources sur le web et montes toi une maquette… et testing, testing et encore testing
Et franchement depuis Vsphere, c’est frisette (avant c’était tout en ligne de commandes)

Dernier truc: prends une assistance Vmare type Silver ou Gold (si c’est pour de la prod).
En cas de problème, un technicien Vmware prend la main à distance sur ton serveur et s’occupe de tout (de mémoire la gold c’est 500$/an avec support illimité… mais je crois que leur système à changer, c’est à vérifier)

Sinon j’ai trouvé ça, mais j’ai pas vraiment regardé (mais il y a les bases): http://www.tuto-it.fr/vmware.php

PS: je rejoins Frédéric… je ne vois pas non plus en quoi c’est un challenge

2 « J'aime »
5

@Aka74, merci pour ta réponse complète. Je n’ai pas une infrastructure importante (2-3 serveurs). J’ai comme politique d’installer le site d’un client (ou autre) sur un espace reservé lui donnant ainsi accés à son produit pour test sans interferer avec les autres espaces clients. Je pense que la virtualisation devrait m’eviter de disposer d’un trop gros nombre de serveur et de pouvoir monitorer tout cela facilement, backup, restore etc… J’ai également besoin de centraliser tous les documents sociétés, et échanges avec mes collaborateurs sur un espace totalement fermé et backupé. Nous travaillons avec plusieurs SGBD, je préfère séparer également toutes les machines.

Je m’interresse à la virtualisation car je pense qu’elle pourrait répondre à mes attentes mais je ne suis pas fermé.

Cyril

6

Avant toute chose, il faut voir à quoi sert la virtualisation pour s’assurer qu’elle réponde à ce besoin
1/ la mutualisation des serveurs: en règle général les serveurs physiques sont utilisés à 20/25% de leur capacité
2/ PCA (limiter les interruptions à moins de 5 min) et PRA (permettre des reprises rapides: limite le RTO/ mettre en place du cross site mirroring)
3/ Les possibilités de migration des VM (dans des datacenters ou cross site)

D’après ton besoin (j’essaye de comprendre avec les qqls lignes lues)

  • Le nombre de serveurs n’est pas ce qui me semble le plus problématique (l’espace pris par les serveurs est vite réglé avec les formats pizza-switch: 1 à 3 U)
    Reste le taux d’usage de tes machines, il faut les auditer.
  • Le monitoring, soit, mais avec des batchs ou des outils de monitoring comme Intellipool peuvent suffire.
  • Les backup/restore peuvent être centralisés sur un NAS et pilotés via des outils comme Veeam (d’ailleurs même avec la virtualisation, si tu fais du backup D2D il faudra en passer par là ou créer une LUN spécifique)
  • Quant à la centralisation de document, c’est le rôle d’un serveur de fichier ou d’outils tels que Sharepoint et non de la virtualisation.
  • Pour le SGBD, un tout autre problème, mieux vaut des serveurs dédiés SGBD (en physique ou en virtuel) et faire pointer tes appris (hébergés ailleurs) dessus.

Outre les raisons citées (qui n’ont pas pour but d’éviter la virtualisation, mais bien de savoir pourquoi) il faut voir que ne pas utiliser la virtualisation des serveurs et du stockage de nos jours, c’est un peu comme être à l’âge de pierre de l’info.

Ce sont des technos acquisent et maitrisées depuis 15 ans (la virtualisation date tout de même des années 60… même si démocratisée sur le wintel depuis fin 90), que l’on rencontre maintenant partout depuis 5/6 ans (depuis le iSCSI qui n’a plus réservé ça au fiber channel) et dans tout type d’entreprises et collectivités à partir d’une 50aines d’utilisateurs.
… ce serait dommage de passer à coté.

7

Vu ton cas d’utilisation je te conseillerai d’avantage Docker que du VMware.

C’est plus léger et plus adapté a l’utilisation : un container = une application.

8

Docker comme virualbox n’est pas du bare metal.
Ca va bien pour faire de la virtualisation sur son poste de travail pas sur du server.

Mais surtout, Vmware sont les inventeurs de la virtualisation hors Unix et sur proc Intel et à ce jour aucun produit n’est à leur niveau (ni Citrix ni Hyper-V les 2 autres leaders sur serveur)

9

En quoi VmWare est du bare metal ?
Le bare metal, c’est quand ton OS tourne direct sur le « bare metal », donc la machine. Donc pas de virtualisation du tout. Donc pas de VmWare.
Et docker et Virtualbox n’ont pas grand chose en commun du tout. Docker c’est un peu le nouvel ovni, et apporte une nouvelle vision de la virtualisation (et surtout un lot d’outils, fonctionnalités, qui apporte un vrai plus.). Et surtout, niveau perf, c’est quand même ce qui se fait de mieux. Et il me semble que les derniers points bloquants (la sécurité) sont en passe d’être réglés voire sont réglés tout court.

10

Hyperviseur bare metal (type 1), ça veut dire que t’as pas d’OS host (windows, linux, etc.) qui contient l’hyperviseur. L’hyperviseur « est » l’OS host (ou bien t’as un OS super light fait pour l’utilisation de l’hyperviseur).
Ton hyperviseur ensuite régit l’allocation des ressources (cpu, memory, storage) aux différente VM.
VMware fait des hyperviseurs de type 1 (ESX(i)) et type 2 (Fusion).

J’ai fait de la virtualisation avec VMware vSphere:

  • Pour avoir testé Hyper-V et Xen, VMware les surpasse tous. Les arguments sont cités un peu plus haut.
  • C’est cher. Niveau prix ils mettent aussi le paquet.
  • ESX(i) n’est pas compatible tout matériel. Le matériel HP s’en sort plutôt bien.

Je n’ai jamais utilisé Docker par contre. Mais c’est plus du compartiment de ressources par application au lieu de VM il me semble.

1 « J'aime »
11

Xenserver (Citrix) et Hyper-V (MS) sont aussi des hyperviseurs bare-metal

12

Testé sur IBM, HP, Futjitsu-Siemens, Dell… sans problème
Mais pas testé sur du matériel « exotique »

13

Docker’s Use Case. Visiblement tout le monde n’est pas aussi radical.
Et je réitère, pour le use case évoqué : isolation simple d’application, gestion de dépendance et de configuration spécifique, Docker est bien plus léger (donc les coût d’infrastructure moins élevé) et disponible gratuitement.

VMware, VSphere etc… sont bien évidemment parmi les solutions les plus puissantes, mais pour monter un meuble Ikea, j’ai pas besoin d’une grue de chantier.

Et Docker n’a vraiment rien à voir avec Virtualbox.

1 « J'aime »
14

Jeremy,

Il ne s’agit pas d’être radical mais pragmatique pour le cas d’utilisation ici.

Virtualiser sur un OS (comme le fait Docker) pose énormément de problème en production:

  • Toutes tes Vm reposent sur un OS… un problème sur l’OS hôte rendra indisponible l’ensemble de tes Vm
  • L’accès aux ressources matériels par les VM est conditionné par l’OS hôte: il y a donc des transactions entre la VM et l’hyperviseur, entre l’hyperviseur et l’OS Hôte, l’OS hôte et les ressources (ensuite, le chemin inverse est fait): tu as un fort ralentissement des performances.

Même si Docker shunt l’OS Vm (puisque fusionné avec l’hyperviseur… on est donc complètement dépendant de leur système: le dev est encapsulé dans le conteneur Docker), on se retrouve avec le même genre de problématiques plus de nouvelles (liées à leur conteneur).

Les tests que j’avais réalisé pour voir l’intérêt de passer à du bare métal faisait état de pertes de plus de 30% sur un hyperviseur installé sur un OS hôte comparé à un hyperviseur sur bare métal.

Je pourrais parler des inconvénients de la virtualisation sur OS hôte sans discontinuer.

Aucune entreprise utilise cette technique pour virtualiser ses serveurs de production, aucune: parce que ce n’est pas performant et trop risqué.

Mais je pense que tu n’as pas lu la doc sur Docker (je ne l’avais pas fait non plus jusqu’à présent c’est pour ça que je l’ai comparé à virtualbox… tu as raison les utilisations sont différentes) .

Docker est un outil « bac à sable » pour développeur et pour déploiement (mais déploiement de conteneur Docker… ça a tout de même pas mal d’inconvénients cette forte dépendance à mon avis… autre débat).

C’est tout autre chose. Ce n’est pas un outil de prod.
Rien à voir avec la demande initiale.

Quant au serveur de prod (pour finir sur la petite blague), c’est pas du meuble ikea… c’est le coeur même de ton infra, avec le coeur de réseau, soit les fondations de ton SI.
Et là une grue est nécessaire à mon avis, si tu veux mettre des meubles ikea dans une maison qui tient debout.

1 « J'aime »
15

Pour information Docker est utilisé en production par des gros acteurs

Un exemple :

Docker at Shopify: How we built containers that power over 100,000 online shops
Shopify Engineering

1 « J'aime »
16

Je pense qu’on est tous d’accord sur ce point là. Mais ce n’est pas le cas de docker qui n’a pas de couche de virtualisation.

Quel est le problème à ce niveau là ?

@cyril veut virtualiser son infra. Cela semble pour moi principalement pour simplifier l’administration et peut être également réduire l’acquisition/maintenance de serveurs individuels. Je pense que docker peut complètement remplir cette tâche si les services peuvent fonctionner sur linux.

Après, c’est vrai que la vision des machines virtuelles et des containers docker est différente. On ne réfléchit plus vraiment en terme de serveur, mais plus en terme de services.
1 service pour gérer l’AD, 1 service pour gérer les fichiers partagés, 1 service pour faire de la GED, 1 autre pour les mails, etc. L’overhead est quasi inexistant entre les services, du coup, le partitionnement des services peut être plus poussé. (c’est ma vision de la chose, je ne m’avance pas en tant que grand gourou ès docker).
Après, on peut évidemment partager des ressources entre containers (genre une BDD), mais je pense qu’il faut vraiment réfléchir si c’est la meilleure solution et bien poser son infra sur un beau schéma avant de se lancer. Après, je pense que c’est un peu le cas de tout projet. Se lancer tête baissée sous l’excuse d’agilité est pour moi un aller direct dans le mur ou des problèmes quoi qu’il en soit.

17

Je me suis mal fait comprendre alors: je parlais en tant qu’outil de vitualisation de serveur.

Car effectivement, les conteneurs sont déployés en prod, comme indiqué ici:

18

Docker est bien une plateforme de virtualisation comme indiquée dans le user guide section « Dockerizing Applications »

Pour faire fonctionner le conteneur sur un serveur, il faut obligatoirement le moteur.

Pour l’instant ça ne semble poser aucun problème, pas de licencing.

Mais ça va pas rester gratuit longtemps à mon avis… et bien sure, ce n’est qu’un avis tout comme ce qui suit… après en avoir vu des vertes et des pas mures dans ce métier, je deviens méfiant.

C’est peut être open source pour l’instant, mais il va y avoir du dépôt de brevet (pas des gros, comme à fait MS par ex. sur certain dev Opensource) si ça prend… voir une professionnalisation du truc comme ça a été le cas avec RedHat ou Suze sur Linux.

2 indices:
1/ Le marketing : La démarche ressemble étrangement à ce qu’a fait Vmware au début des années 2000 avec GSX puis ESXi avant de tester les services annexes, le licencing sur Esxi 3.5 (si je ne me trompe pas de version) puis l’arrivée de Vsphère.

2/ Les référents… que de la pêche au gros (beaucoup en tout cas).

Malin, ils laissent les boites s’approprier le truc pour l’instant…jusqu’à en devenir dépendant si le produit est bon (comme Vmware).
Et là… tarification.

Mais après, tarifer sur quoi?

Les conteneurs?
Peu de risque, les clients ne vont surement pas apprécier : ils penseront avoir été pris pour des pigeons, et, même à faible tarif, le cout peut être très très élevé en raison du nombre de conteneurs… gros risque de fuite des clients pour une autre solution ou retour arrière.

Le moteur en mode écriture (ce n’est peut être pas le terme approprié mais l’idée est là)?
Peu de chance là aussi, il suffit de n’avoir qu’un moteur par dev… ce qui limitera les rentrées d’argent.

Reste donc le moteur sur les serveurs host qui feront tourner les conteneurs.
Il n’est pas question de Dokeriser un AD, une GED ou un serveur de messagerie (ça me parait un peu trop énorme) mais ses applications développées (c’est ce que j’ai compris en lisant le user guide).

Donc on se retrouve avec ses applis encapsulées qui ne peuvent fonctionner que grâce à un moteur Docker.

C’est le 1er risque:
L’hyper dépendance et de comment on se sort de là si on en veut plus?.. quels coûts, quels efforts, quels risques sur le business…?

2eme risque:
Comme je le disais, Docker fait la chasse aux gros, avec le marketing utilisé par Vmware il y a 15 ans… je mise pour quelques milliers de dollars la licence moteur par Host.
Si l’infra tourne sur plusieurs dizaines de serveurs (voir centaines pour certains), ça va faire mal.
Mais même à quelques centaines de dollars, la multiplication des serveurs salera la note.

Autre cas: un licencing sur support comme RedHat ou Suze l’ont fait.

Dans l’expectative, j’y vois plus d’inconvénients que d’avantages… mais à voir lorsque le licencing sera en place.

Comme d’hab avant de se mettre corps et âme sur un produit qui arrive sur le marché, aussi révolutionnaire soit il (si c’est le cas)… on attend et on observe.
Mais ça n’empêche pas le testing bien évidement.

Je suis un peu parano, je vous l’accorde… mais vu les requins de l’info, mieux vaut y aller avec une cage.

Désolé Cyril pour ton fil, j’ai l’impression qu’on est vraiment parti en HS.

1 « J'aime »
19

C’est déjà le cas. En gros, le système de paiement est à là github. Repository opensource/ouvert = gratuit. Pour le garder privé, il faut payer.
Je ne connais pas tous les vraies histoires de github. Mais à priori, leur système leur permet de bien évoluer. Les investissements ne sont venus que bien plus tard.

En tout cas, même si on est parti en HS sur le sujet initial, je pense que docker peut toujours être une solution pour ce problème. Ou alors, je n’ai vraiment rien compris au sujet.

20

Docker n’est pas un outil pour infrastructure (sujet d’origine) mais pour dev.