Pour savoir où on va, il faut savoir d'où l'on vient

Vous avez
une question ?
Un projet ?

Contactez nous !
 

Contactez-nous

Vous avez une question ? un projet ? 
Vous souhaitez plus d'informations sur un produit ? sur notre offre ? 
Contactez-nous, on vous répond sous 4H.

eZHumanCAPTCHACode reload
retour

Domaines d’Application

Domaines d’Application

Nous allons maintenant voir quelques exemples d'application de ces techniques de virtualisation, dans les domaines où elles sont couramment mises en place.

Hébergement VDS

Les offres d’hébergement étaient traditionnellement distinguées en deux catégories :  hébergement dédié et hébergement mutualisé.

Dans un hébergement dédié, le fournisseur met à disposition de son client un ou plusieurs serveurs, configurés selon ses besoins. Selon les cas, le contrat peut prévoir une plus ou moins grande autonomie du client par rapport à la configuration et l’exploitation de son serveur, mais du moins au plan technique, rien ne s’oppose à ce que le contrôle soit total.

Avec un hébergement mutualisé, le fournisseur utilise un même serveur pour plusieurs de ses clients. Il utilise différentes solutions de cloisonnement pour maintenir une certaine étanchéité entre ces environnements.   

Le partage de la ressource serveur permet bien sûr un coût très inférieur, particulièrement attractif pour les sites à faible trafic. Mais l’hébergement mutualisé simple a plusieurs handicaps :

  • L’allocation des ressources du serveur n’est pratiquement pas contrôlée, de sorte que la qualité de service de chaque site peut être pénalisée par un pic de trafic, ou par la boucle d’un programme sur un autre site.
  • La configuration logicielle est unique, et dictée par l’hébergeur.  Elle fait le choix, en général, d’un même serveur Http, mais aussi très souvent d’un même outil de gestion de contenus et de base de données.   La simple installation de telle ou telle librairie spécifique nécessaire à l’un des clients n’est en général pas possible.  Et a fortiori, des configurations globales sur mesure sont interdites.
  • En termes d’exploitation, chaque client est extrêmement confiné, de peur qu’il ne perturbe la configuration.  Il dispose le plus souvent d’un simple accès en transfert de fichier sur son répertoire privé, et dans tous les cas n’a jamais l’accès root (administrateur) sur le serveur.

Entre ces deux modes d’hébergement, la virtualisation a permis un mode combinant les bénéfices de l’un et de l’autre :  le partage de ressources d’une part, l’autonomie et le contrôle d’autre part.

C’est le mode que l’on appelle « VDS » pour Virtual Dedicated Server, un serveur dédié virtuel.

Il consiste tout simplement à mettre en œuvre des serveurs virtuels selon les différentes technologies décrites plus haut, et d’allouer un serveur virtuel à chaque client.

Le mode VDS permet donc :

  • De partager un même serveur physique en N serveurs virtuels, alloués à différents clients.   Le nombre de serveurs virtuels par serveur physique dépend bien sûr des besoins respectifs de chacun, mais n’a pas de limite théorique.
  • De définir – du moins selon la technologie de virtualisation retenue – la part de ressources allouée à chaque client.
  • De donner à chaque client un contrôle total sur son serveur virtuel :  il peut y installer les composants de son choix, disposer d’un accès root, gérer ses utilisateurs et droits, rebooter le serveur, ré-installer l’OS.

Selon la technologie de virtualisation retenue, les limites de cette maîtrise pourront varier :

  • Avec une technologie d'isolation de type OpenVZ, il aura la liberté de choisir quelle distribution il souhaite installer, et quelles applications il utilisera, mais devra se satisfaire du noyau en place.
  • Avec une technologie de  virtualisation complète, il aura le choix du système d'exploitation installé sur sa machine, et pourra utiliser des applications fonctionnant en mode noyau tels des systèmes de stockage ou réseau avancés (GFS, DRBD, IPsec, etc.).

Plateforme de validation et de développement

La compatibilité des applications avec la grande variété des configurations informatiques disponibles est un enjeu majeur, tout particulièrement pour les progiciels.
Garantir cette compatibilité implique de tester les produits sur un large ensemble de plateformes, d'architectures, de systèmes d'exploitation différents, associés le cas échéant à une variété de bases de données ou d’autres composants système.

Les grands éditeurs, tels que Dassault Système par exemple, utilisent pour cela des fermes de validation comportant plusieurs centaines de serveurs.

Les solutions de virtualisation permettent d’alléger quelque peu ces infrastructures de validation, leur coût matériel, mais aussi leur exploitation.  

Les applications peuvent être compilées et testées automatiquement sur un grand nombre d'environnements virtuels (successivement ou même simultanément).   Dans ce domaine, on privilégie naturellement les solutions de virtualisation complète, supportant une variété d’OS.

Les solutions de machines virtuelles avec émulateur, bien que moins efficaces en termes de performances, permettent même de simuler un processeur différent de celui de l'hôte.

Un autre usage de la virtualisation dans le cadre d'une plateforme de développement est l'instanciation et l'administration de parcs de serveurs de développement, d'intégration, de recette, etc...

Au sein de larges équipes de développement, comme c’est typiquement le cas chez un prestataire informatique, chaque projet peut posséder ses propres serveurs virtuels, sans aucun impact sur les autres projets, et mettre en place des environnements de test et de pré-production de façon souple et rapide.

Screenshot from 2015-04-21 15:52:51

Haute disponibilité

En matière de haute disponibilité ou de haute capacité d’accueil, les mécanismes centraux sont devenus classiques et bien maîtrisés :  répartition de charge (load balancing) et reprise automatique sur incident (failover). Sur ces différentes techniques, la virtualisation apporte son lot d'avantages.

Répartition de charge

La répartition de charge est à la base un moyen d'augmenter la tenue en charge d'une application, en l’hébergeant sur plusieurs serveurs qui se partagent les visiteurs.

La répartition de charge est le plus souvent mise en œuvre au moyen d’un boitier spécialisé, qui dirige les requêtes des visiteurs sur les différents serveurs, en conservant ou non un même visiteur sur un même serveur. Les boitiers de répartition de charge savent en général détecter la panne d’un serveur, et ne plus lui affecter de trafic. Ainsi, load balancing et failover vont souvent de pair.  

Pour des plateformes à très forte audience, et à vocation ciblée, le partage des serveurs physiques n’est pas d’une grande utilité. C’est le cas typiquement d’un grand site web recevant plusieurs centaines de milliers de visiteurs par jour, dont le trafic est réparti sur quelques serveurs.   Pour autant, la virtualisation pourra avoir d’autres usages.
Mais si l’on est en présence de plusieurs applications, ayant chacune besoin de répartition de charge sur plusieurs serveurs, alors la virtualisation peut apporter une meilleure mutualisation de moyens.

Supposons que l’on exploite deux applications critiques A1 et A2.  Chacune dispose de deux serveurs physiques entre lesquels le trafic est réparti. Supposons, ce qui arrive souvent, que ces serveurs ne soient pas utilisés à pleine capacité. Une bonne alternative d’architecture, consiste alors à réunir les deux applications sur deux, voire trois serveurs, chacun partagé en deux machines virtuelles, l’une pour A1, l’autre pour A2.

Ainsi au lieu de 4 serveurs, on n’en a plus que 3, voire 2.  Et au lieu d’une répartition sur 2 serveurs, on a une répartition sur 3.

Screenshot from 2015-04-21 15:54:53
Screenshot from 2015-04-21 15:56:10
Reprise automatique

Un autre usage de la virtualisation dans une optique de haute disponibilité de service peut consister à avoir sur plusieurs serveurs physiques les mêmes environnements virtuels (synchronisés régulièrement).

Les différents serveurs physiques se partagent les différents serveurs virtuels, et si un des serveurs physiques tombe en panne, les machines dont il avait la responsabilité sont relancées sur les autres serveurs. Cela permet d'assurer un temps d'indisponibilité minimum, et une continuité de service malgré des performances amoindries. On peut ainsi travailler plus sereinement à la remise en route du serveur en panne.

Bien sûr il est possible de combiner répartition de charge et reprise automatique sur plusieurs hôtes physiques pour une robustesse encore accrue.

Screenshot from 2015-04-21 15:57:39

Après une panne d'un des serveurs :

Screenshot from 2015-04-21 15:59:09

Virtual appliance

Le concept d’appliance

Dans le domaine du réseau, le concept d' appliance est démocratisé depuis plusieurs années. Il s'agit de boîtiers prêts à l'emploi : firewall, routeurs, solutions de sécurité tout-en-un, qui se branchent facilement sur le réseau et nécessitent très peu de configuration de la part des administrateurs.

Après les appliances physiques, les software appliances sont des configurations logicielles complètes packagées, incluant le système d’exploitation, la configuration système complète, l’application principale et tous les composants logiciels dont elle a besoin, le tout en un paquet aisément installable. La software appliance permet à l’administrateur système de ne plus se préoccuper de la compatibilité de tels et tels composants logiciels :  la configuration est unique, validée et packagée en amont. Les software appliance permettent d’alléger considérablement l’administration des configurations, de même que les tests de qualification d’un produit. Elles n’ont qu’un inconvénient :  en l’absence de virtualisation, elle requièrent un serveur par application.

D’où le concept de virtual appliance, une software appliance qui s'installe dans une solution de virtualisation existante dans le but de remplir une certaine fonction.

Ces "virtual appliances" se présentent sous la forme d"images de machines virtuelles, déjà parfaitement configurées et packagées avec l'application voulue. Leur déploiement est aisé, bien loin de l'installation manuelle complète d'un système d’exploitation, d’une l'application et des utilitaires associés, en terme de temps donc de coût.

De plus ces "appliances" sont facilement sauvegardables et transportables car en général elles occupent un espace disque réduit (très peu de logiciels superflus, seulement l'OS de base est installé ainsi que l'application voulue).

De très nombreuses possibilités

On peut ainsi trouver ou construire des "appliances" pour tout type de besoins, il suffit ensuite de configurer quelques variables et l'architecture est opérationnelle et déployable à volonté.

On trouve sur le web des idées d'appliance pour tout les usages, et pour tout les produits phares de l'industrie open source : LAMP, Asterisk, Nagios/Cacti, Joomla, etc..

Architecture LAMP

Pour faire du développement ou simplement des tests il est souvent très utile d'avoir des environnements LAMP génériques, par exemple pour les équipes de Smile, nous avons souvent déployé ce genre d'environnement pour nos développeurs ou nos clients. Nous gagnons énormément de temps avec ce genre d'appliance, qui sont prêtes à l’emploi pour divers types de besoins (eZ Publish, TYPO3 ...).

Firewall, VPN

Les capacités réseau de certaines solutions de virtualisation permettent même de mettre en place des serveurs virtuels ayant la main sur les interfaces réseau, ce qui permet l'utilisation d'un composant virtuel pour servir de firewall, de système de détection d'intrusions, de endpoint VPN, totalement isolé du matériel, et donc moins sensible en cas d'attaque.

Cloud Computing

L'une des idées fortes qui se cache derrière la notion, un peu vague, de Cloud Computing (informatique nébuleuse), est l'abstraction de la plateforme d'une application, à différents niveaux.

On parle d'IaaS (Infrastructure as a Service) lorsque l'on abstrait uniquement l'infrastructure physique d'une application. On conserve ainsi la notion de serveur, sur lequel une plateforme applicative (LAMP, ou encore J2EE) reste à installer.

On parle de PaaS (Platform as a Service) lorsque l'on abstrait cette fois-ci la plateforme, c'est ce que font des services comme Microsoft Azure ou Google App Engine.

Enfin, on parle de SaaS (Software as a Service) lorsqu'on abstrait tout, y compris l'application. Ce qui est ni plus ni moins que la fourniture « traditionnelle » de service payant via une application web. Les fers de lance de cette approche sont par exemple SalesForce ou encore Google Apps.

La virtualisation est bien sûr fondamentale dans la mise en place d'une IaaS. Cependant, il est nécessaire d'automatiser entièrement la mise à disposition de machines virtuelles. Le suivi de consommation des ressources à des fins de facturation fait partie du modèle commercial du Cloud Computing, il doit donc faire partie intégrante de la solution d'IaaS. Le produit doit également s'occuper de configurer automatiquement un espace de stockage persistant pour les VM, ainsi que leur fournir une connectivité réseau. Fournir cette connectivité nécessite à son tour de configurer des équipements tels que des switchs, et d'immobiliser des adresses IP. Enfin, l'accès, même indirect, des clients finaux à la plateforme physique du prestataire IaaS pose de nombreux problèmes de sécurité, de traçabilité, d'isolation entre les clients.

Une solution d'IaaS est donc un logiciel complexe, qui doit jongler entre de nombreux domaines d'activité. On comprend pourquoi les solutions de virtualisation ne prennent pas en charge directement l'IaaS. Des projets logiciels spécialisés sont nécessaires, et sont d'ailleurs souvent indépendants de la technologie de virtualisation sous-jacente. Dans la suite de ce livre blanc nous présenterons OpenStack qui est l'un de ces outils.