Architectures de virtualisation

Mardi dernier avait lieu la « soirée informatique » de l’Utt Net Group au foyer de l’UTT. L’objectif de cette soirée était de discuter d’informatique tous ensemble et d’apprendre des expériences des autres. Il s’agit d’un barcamp avec plusieurs modifications. Dans notre cas, la durée des présentations n’était pas limitée à priori, nous avons donné la possibilité à chaque orateur de choisir son temps de présentation dans la mesure du raisonnable.

Les présentations se sont déroulées les unes après les autres avec une pause barbecue car il faut bien alimenter notre cerveau. Cette soirée a été une réussite car elle a atteint son objectif de réunir des gens autour d’une passion commune. Seuls quelques petits « bugs » logistiques sont à retenir mais rien de bien grave.

En ce qui me concerne, j’ai effectué une présentation intitulée « Architectures de virtualisation ». L’objectif était de partir de la virtualisation et de faire le tour des autres éléments qui sont affectés par cette dernière. Les éléments étant affectés par la virtualisation retenus sont le stockage et le réseau. La présentation a duré 45 minutes.

Pour ceux que ca intéresse, mes slides sont disponibles en PDF et via le slideshare ci-dessous.

Les domaines Xen : les domaines non privilégiés

Aller hop on se motive ! Pour mon avant-dernier jour de stage chez Orange Business Services, je vais faire la suite du précédent article sur les domaines Xen. J’avais eu l’occasion de détailler les spécificités du domaine privilégié, plus communément connu sous le nom de dom0.

Si vous n’êtes pas familier avec le vocabulaire spécifique à Xen, je vous renvois vers l’article traitant de la terminologie Xen. Si vous ne connaissez pas bien le projet Xen, je vous renvois vers la présentation de ce projet.

Domaine non privilégié : domU

Les domaines non privilégiés sont communément appelés « domU » (U comme unprivileged). Les domU sont l’équivalent des systèmes d’exploitation invités sur les plateformes de virtualisation classiques. Concrètement, ce sont les machines virtuelles qui s’exécuteront sur votre plateforme Xen. Ces systèmes d’exploitation s’installent une fois que vous avez un hyperviseur et un dom0 fonctionnel. Il existe de nombreux outils vous permettant d’installer des domU de manière plus ou moins simple et rapide.

Comme vous le savez surement, Xen est capable de faire de la paravirtualisation mais aussi de la virtualisation matérielle assistée. A chacun de ces types de virtualisation correspond un type de domaine non privilégié. Les domU de paravirtualisation sont appelés « domU standards » et les domU de virtualisation matérielle assistée sont appelés « domU HVM ». L’acronyme HVM signifie « Hardware-Assisted Virtual Machine ».

domU de paravirtualisation : domU standard

Nous allons tout d’abord nous intéresser aux domU dits « standards ». Les domU de paravirtualisation sont considérés standards car il s’agit des premiers domU qui ont été disponibles pour Xen et les seuls jusqu’à la version 3.0. Ceci s’explique par le fait que la paravirtualisation est la raison d’être du projet Xen et ce qui en a fait un projet inédit.

Du fait qu’il s’agisse de domU de paravirtualisation, il est nécessaire que l’OS de chaque domU standard ait été adapté pour l’hyperviseur Xen. Ceci se fait par le biais d’API spécifiques supportant les hypercalls. De très nombreux systèmes d’exploitation peuvent être placés en tant que domU par dessus Xen. Tous les Linux sont compatibles ainsi que certains BSD et OpenSolaris.

domU de virtualisation matérielle assistée : domU HVM

Lorsqu’un système d’exploitation n’a pas été adapté pour Xen, il est nécessaire de recourir à une technique de virtualisation plus classique. Il s’agit bien évidemment de la virtualisation matérielle assistée. Ce type de domU permet à Xen de supporter la quasi totalité des systèmes d’exploitation existants pour l’architecture x86.

Le module utilisé par Xen pour effectuer les opérations de virtualisation matérielle assistée est le module QEMU. La contre partie des domU HVM est une perte de performances plus importante que dans le cas d’un domU standard. Ceci s’explique par le fait qu’il est nécessaire d’effectuer beaucoup plus d’opérations d’émulation.

Rôle des domU et délégation de périphériques

Les domU n’ont pas de rôle spécifique au niveau de la plateforme de virtualisation. Ils servent juste à exécuter les diverses applications qui sont contenues dans leurs systèmes d’exploitation. Il ne leur est accordé, par défaut, aucun privilège au niveau des ressources physiques. L’hyperviseur leur attribue une partie des ressources dynamiquement et les domU les utilisent ou pas en fonction de leurs besoins.

De plus, il est tout de même possible d’accorder quelques priviléges spécifiques aux domU. Ces privilèges spécifiques se matérialisent par la délégation de périphériques. Par exemple, il est possible de donner accès exclusif à un port USB ou PCI à un domU. Ceci va lui permettre de pouvoir utiliser un composant physique comme il le souhaite. Il y a eu des exemples de cartes graphiques déléguées à un domU permettant de jouer à un jeu 3D dans le domU. Notons tout de même que la délégation de périphérique à un domU restreint totalement sa mobilité entre plusieurs hyperviseurs ce qui peut être handicapant.

Au final, cette article présente les spécificités des domU. J’espère avoir été clair et compréhensible. Si ce n’est pas le cas, vous avez toujours la possibilité de laisser un commentaire pour me le signaler. En ce qui concerne la suite des événements, je suis encore indécis sur les sujets que je vais traiter. Cela devrait varier en fonction de mon prochain emploi. De toute manière, je souhaiterais parler plus des réseaux de stockage et du stockage en général.

Les domaines Xen : le domaine privilégié

Xen_logoCela fait désormais un bon bout de temps que je n’ai pas eu l’occasion de vous parler de Xen. Lors du dernier article sur ce sujet, nous avions surtout parlé de configuration réseau. J’aurais peut être l’occasion d’en reparler par la suite, nous verrons bien.

J’ai déjà eu l’occasion de vous parler des domaines Xen à plusieurs occasions sur ce blog. J’ai défini la notion dans l’article sur la terminologie Xen. Dans ce billet je vais essayer d’élaborer un petit plus sur ce sujet en détaillant un peu plus les interactions entre le domaine privilégié et le matériel.

Domaine privilégié : dom0

Le domaine privilégié ou dom0 est le système d’exploitation « visible » d’une installation Xen. Il s’agit du système d’exploitation que l’on installe avant d’installer l’hyperviseur. Pour rappel, cela ne veut pas dire que l’hyperviseur est au desssus du dom0 car il est bien en dessous. Vous pouvez le vérifier au démarrage, car on voit bien que Xen s’exécute avant la distribution du dom0.

Le domaine privilégié est un domaine exceptionnellement sensible. Il s’agit du domaine qui va avoir accès à toutes les ressources physiques auxquelles l’hyperviseur n’aura pas l’accès exclusif. L’hyperviseur n’a un accès exclusif au processeur et à la mémoire. Tout le reste relèvera donc de la compétence du dom0. Ceci inclut donc tout particulièrement les supports de stockage. Le dom0 a donc accès à toutes les données de votre hyperviseur, il est donc indispensable de le sécuriser.

Le rôle du domaine privilégié

En ce qui concerne le rôle du dom0, il est essentiellement de gérer les supports de stockage, les périphériques éventuels ainsi que les éventuels interfaces d’administration. Il n’est pas souhaitable de lui attribuer plus de rôles que cela. Il est cependant indispensable de lui allouer des ressources physiques convenables. Etant donné que la gestion de support de stockage fait partie de sa compétence, il est nécessaire qu’il se voit attribuer suffisamment de mémoire vive afin de pouvoir constituer un cache performant.

L’hyperviseur attribue par défaut tous les périphériques au domaine privilégié. Certaines configurations spécifiques peuvent nécessiter de rendre accessible un périphérique à une machine virtuelle. Ces configurations sont relativement compliquées à mettre en place dans un contexte de haute disponibilité avec migration à chaud. Ceci s’explique habituellement par le simple fait que le périphérique ne peut être branché sur un seul serveur à la fois. Des solutions d’USB sur IP sont plus simples. Il reste cependant possible d’effectuer une délégation de périphérique vers un domaine non privilégié. Il y a déjà eu des exemples de délégation de cartes graphique permettant de jouer à des jeux 3D dans des domaines non privilégiés.

Interface avec les autres domaines

Les autres domaines vont accéder aux ressources relevant de la compétence du dom0 via des pilotes génériques de périphérique. Ces pilotes génériques permettent de maximiser la compatibilité et d’éviter les différences entre les différentes plateformes Xen. L’intérêt des pilotes génériques est immédiat dans le cas de la migration à chaud où la standardisation des environnements est primordiale.

Le schéma suivant récapitule très bien toutes ces interactions.

Capture d’écran 2009-12-14 à 14.39.27

Au final, je pense avoir fait une présentation plutôt détaillée du domaine privilégié. Si vous avez des questions ou des remarques, n’hésitez pas, les commentaires sont faits pour cela. Dans un prochain article, j’évoquerais plus en détail les domaines non privilégiés.

Barcamp ce Samedi à Troyes

barcamp_icon_finalJe vais faire un petit billet de publicité pour un événement auquel je vais participer ce weekend. Il s’agit d’un barcamp. Pour ceux qui ne connaissent pas le principe du barcamp, il s’agit d’une rencontre entre passionnés de diverses technologies où chacun présente un sujet de son choix.

Un barcamp aura donc lieu à la Halle Sportive de l’Université de technologie de Troyes ce Samedi à partir de 17 heures. Il aura lieu en marge de l’Utt Lan Session qui est une LAN Party organisée par l’Utt Net Group. Il devrait durer jusqu’à 22 heures environ. Une pause pour manger est prévue afin de pouvoir reposer vos neurones.

En ce qui me concerne, j’aurais l’occasion de vous faire une présentation « tour d’horizon » sur les réseaux de stockage. Vous pourrez également participer à de nombreuses autres présentations parmi les suivantes :

  • VBA
  • SOAP
  • OpenID & OAuth
  • OpenPGP
  • LDAP
  • CNIL
  • Trap your process

N’hésitez pas à venir faire un tour et nous rencontrer ce weekend à Troyes. Vous trouverez toutes les infos nécessaires par rapport à cette manifestation sur le site de l’ULS.

Récapitulatif

  • Quoi ? Un barcamp
  • Quand ? Samedi 28 Novembre à partir de 17h jusqu’à 22h
  • Où ? A la Halle Sportive de l’Université de technologie de Troyes
  • Pour qui ? Tout le monde qui souhaite partager avec nous

Nouvelle classification des types de virtualisation

tech-presentation-2J’ai déjà eu l’occasion de proposer une classification des différents types de virtualisation lors d’un précédent article sur ce blog. Lors de ce précédent article, je m’étais attaché à classifier les solutions de virtualisation de systèmes d’exploitation. Je propose par le biais de cet article de re-préciser cette classification en y intégrant d’autres types de virtualisation et en reprenant en partie le précédent.

Tout d’abord, il sera essentiel de s’interroger sur ce que nous allons virtualiser car il est possible de virtualiser bon nombre de composants applicatifs. J’utiliserais le terme de composant applicatif pour désigner tout ce qui n’est pas matériel. Ce terme inclura donc les systèmes d’exploitation en globalité ou en partie aussi bien que les applications spécifiques. Ensuite, je proposerais un arbre de classification complété par rapport à la première version de cet article. Je rappellerais au passage les appellations correspondantes aux différents types de virtualisation.

Note : Cet article a été publié le 28 Octobre dans une version simplifiée sur le blog Virtualisation d’Orange Business ServiceS.

On virtualise quoi ?

Tout d’abord, il est essentiel de se poser la question « Que virtualise-t’on ? ». Il est possible de virtualiser beaucoup de choses de nos jours. Un début de liste comporterait des routeurs, des switchs, des applications, des systèmes d’exploitation, de l’espace disque et ainsi de suite.

Nous allons distinguer trois familles de virtualisation : réseaux, systèmes d’exploitation et processus. Ces trois types constitueront le premier étage de notre arbre de classification.

On virtualise comment ?

Nous avons donc effectué une première discrimination basée sur le composant applicatif que nous allons virtualiser afin d’établir le premier étage de notre arbre de classification. Nous allons ensuite établir le second étage de cet arbre.

Nous allons ensuite associer à chaque composant applicatif les différents types de virtualisation correspondants. En ce qui concerne les systèmes d’exploitation, nous ajouterons une distinction importante qui est la modification ou non du système d’exploitation invité. Un système d’exploitation invité est un système d’exploitation qui s’exécute par dessus une couche de virtualisation spécifique.

Voici donc l’arbre de classification que je propose :

schema_classification_small

Le premier type de virtualisation présent dans cet arbre est la virtualisation d’équipements réseaux. Il aurait été possible d’inclure la virtualisation de réseaux. Ceci a été exclu de cette classification car il ne s’agit que d’un mécanisme de commutation spécifique. Ce type de virtualisation permet de créer des environnements réseaux spécifiques et cloisonnés de bout en bout. Les solutions existantes dans ce domaine sont les produits Nexus de Cisco et le futur switch virtuel de Citrix.

Dans la catégorie des systèmes d’exploitation, nous avons choisi de distinguer les systèmes d’exploitation modifiées et non modifiées. Les modifications en question sont les modifications du noyau nécessaire à l’exécution du système d’exploitation par dessus une couche de virtualisation spécifique.

La virtualisation de système d’exploitation modifiés est la paravirtualisation. Ce terme a tendance à être utilisé de nombreuses manières différentes. La paravirtualisation est la virtualisation de systèmes d’exploitation dont le noyau a été modifié pour communiquer avec la couche de virtualisation au lieu de communiquer avec le matériel physique. Pour résumer, la système d’exploitation va avoir conscience d’être virtualisé et sera adapté à cet effet. L’ajout de simple drivers spécifique n’implique pas forcément paravirtualisation. Les solutions existantes dans ce domaine sont les produits XenServer de Citrix, xVM de Sun, XenSource voire Hyper-V de Microsoft. VMWare commence à se lancer dans cette technologie prudemment. Si vous souhaitez en savoir plus sur la paravirtualisation, je vous laisse consulter l’article sur la paravirtualisation.

En ce qui concerne les systèmes d’exploitation non-modifiés, nous distinguerons deux types de virtualisation : la virtualisation totale et la virtualisation matériel assistée. La virtualisation totale est la virtualisation « primitive » qui consiste à émuler le matériel physique ainsi que son comportement. Il s’agit de l’approche la plus couteuse mais la plus simple à mettre en oeuvre. La virtualisation matériel assisté est une extension du principe de virtualisation totale. Cette extension se matérialise par l’utilisation des extensions processeur spécifiques à la virtualisation (AMD-V et Intel-VT). Ces extensions permettent d’accélérer la virtualisation par différents mécanismes. Les solutions utilisant cette technologie sont VMWare, Virtualbox de Sun, Virtual PC de Microsoft, QEMU et bien d’autres.

Au niveau de la virtualisation de processus, nous retrouvons deux types de virtualisation : la virtualisation au niveau du système d’exploitation et la virtualisation d’application. La virtualisation au niveau du système d’exploitation consiste à faire croire à plusieurs jeux de processus qu’ils s’exécutent dans différents systèmes d’exploitation alors que ce n’est pas le cas. Les solutions utilisant cette technique sont les zones Solaris, les chroot Linux, les jails BSD, OpenVZ et bien d’autres. La virtualisation d’application consiste à livrer des applications non installées sur un poste par un serveur. Les solutions utilisant cette technique sont XenApp de Citrix ou VMWare Thinapp.

Au final, je pense que cette classification est plus complète que la précédente que j’avais eu l’occasion de présenter. Elle inclut notamment la virtualisation d’application et la virtualisation d’équipements réseaux. Cette classification reste une proposition et il est tout à fait possible de proposer une classification sous un autre angle.

Les mystères de la commande ping

pongJe vais faire une petite parenthèse dans ce billet sur la commande ping. Vous allez me dire que vous connaissez déjà bien la commande ping, ce dont je ne doute pas. Elle sert habituellement à vérifier la connectivité réseau d’une machine sur un réseau ou à travers plusieurs réseaux. Mais connaissez-vous complètement cette commande ?

A travers une erreur de frappe, je me suis retrouvé à découvrir quelques « mystères » par rapport à cette commande. Je tiens à remercier mon collègue Laurent et son erreur de frappe qui nous a permis de découvrir ces « mystères ». Ils ont été testés sur Windows XP et Linux.

L’utilisation habituelle de la commande ping ressemble à la commande suivante et vous donne le résultat indiqué.

root@serveur:~ # ping 10.2.0.10

PING 10.2.0.10 (10.2.0.10): 56 data bytes

64 bytes from 10.2.0.10: icmp_seq=0 ttl=255 time=0.173 ms

64 bytes from 10.2.0.10: icmp_seq=1 ttl=255 time=0.134 ms

— 10.2.0.10 ping statistics —

2 packets transmitted, 2 packets received, 0% packet loss

round-trip min/avg/max/stddev = 0.134/0.153/0.173/0.000 ms

Premier mystère

Vous avez déjà surement fait des fautes de frappe en tapant cette commande, mais avez-vous déjà regardé le résultat que cela produit ? Voici un exemple du ping vers l’IP 10.2.017.

root@serproxy01:~ # ping 10.2.017

PING 10.2.017 (10.2.0.15): 56 data bytes

64 bytes from 10.2.0.15: icmp_seq=0 ttl=255 time=0.824 ms

64 bytes from 10.2.0.15: icmp_seq=1 ttl=255 time=0.525 ms

— 10.2.017 ping statistics —

2 packets transmitted, 2 packets received, 0% packet loss

round-trip min/avg/max/stddev = 0.525/0.674/0.824/0.150 ms

On pourrait s’attendre à ce que la commande ping nous retourne un erreur. La syntaxe de l’écriture de l’adresse IP que nous avons saisie est cependant mauvaise… Vous pouvez essayer avec n’importe quelle IP, cela fonctionne de manière similaire. Nous voyons qu’un ping vers la 10.2.017 effectue en réalité un ping vers l’adresse 10.2.0.15. Un ping vers l’adresse 10.2.0.15 aurait été tout à fait logique mais ce n’est pas le cas. Quel est donc le lien entre 10.2.017 et 10.2.0.15 ? Je vous laisse essayer avec différentes IP afin d’essayer de trouver le lien logique.

Explication

Vous avez trouvé ? J’espère bien. Les plus futés d’entre vous auront remarqué que 017 correspond à 15 en base 8 ou octal. Pour la petite explication :

0 x 64 + 1 x 8 + 7 x 1 = 8 + 7 = 15.

Second mystère

Nous avons donc réussi à percer ce premier mystère. Alors que nous étions en train de chercher la solution au premier, nous avons rencontrer une seconde bizarrerie. Essayez la commande ping 10.3.2947 et remarquez le résultat produit.

D:\Documents and Settings\Administrateur>ping 10.3.2947

Envoi d’une requête ‘ping’ sur 10.3.11.131 avec 32 octets de données :

Réponse de 10.3.11.131 : octets=32 temps<1ms TTL=128

Statistiques Ping pour 10.3.11.131:

Paquets : envoyés = 1, reçus = 1, perdus = 0 (perte 0%),

Durée approximative des boucles en millisecondes :

Minimum = 0ms, Maximum = 0ms, Moyenne = 0ms

Dans la même veine, nous pouvons essayer la commande ping 10.199449 et observer le résultat.

D:\Documents and Settings\Administrateur>ping 10.199449

Envoi d’une requête ‘ping’ sur 10.3.11.25 avec 32 octets de données :

Réponse de 10.3.11.25 : octets=32 temps<1ms TTL=128

Réponse de 10.3.11.25 : octets=32 temps=1 ms TTL=128

Statistiques Ping pour 10.3.11.25:

Paquets : envoyés = 2, reçus = 2, perdus = 0 (perte 0%),

Durée approximative des boucles en millisecondes :

Minimum = 0ms, Maximum = 1ms, Moyenne = 0ms

Après le premier mystère, on commence à comprendre que la commande ping agit selon une logique étrange. Vous remarquerez qu’il ne s’agit plus, cette fois-ci, de base 8. Une fois de plus, cela fonctionne avec n’importe quelle IP formatée selon ce mode. On voit facilement qu’on n’est plus en base 8 car le chiffre 9 ne nous renvoie pas d’erreur particulière. Je laisse chercher les plus intrépides d’entre vous. Les autres, vous pouvez continuer à lire cet article.

Vous avez trouvé ? Vous en êtes bien sur ? Les plus futés d’entre vous auront remarqué que nous ne sommes plus en base 8 mais en base 256. Pour démontrer ce fait, je ferais appel à la division avec reste entier.

Explication

Reprenons le premier exemple :

2947 / 256 = 11 reste 131.

Etant donné le préfixe 10.3, vous avez donc 10.3.11.131.

Reprenons le second exemple :

199449 / (256 x 256) = 3 reste 2841

2841 / 256 = 11 reste 25

Nous avons donc 10.3.11.25. Pour vous en convaincre, vous pourrez voir que :

256 x 256 x 3 + 256 x 11 + 25 = 199449.

Au final, j’espère que cet article vous a plu et vous a un peu retourner le cerveau, car s’en était bien l’objectif. Vous ne verrez plus la commande ping de la même manière désormais.