Étiquette : OS

Les technologies du Cloud Computing

Antoine 5 commentaires

Les vacances sont finies et les affaires reprennent avec plus d’open source et de cloud computing. Lors d’un précédent article, nous avons essayé de trouver une définition à peu près convenable du cloud computing de manière générale. Ceci s’est avéré relativement complexe et hasardeux. J’ai finalement choisi de conserver la définition proposée par Wikipedia en Anglais.

A défaut de réussir à définir conceptuellement le cloud computing, nous allons essayer de le définir technologiquement. Cet exercice devrait être largement plus simple que le précédent car les ressources abondent sur ce plan. Comme vous vous en doutez déjà, il existe de nombreux types d’infrastructures physiques et applicatives placées sous la dénomination de cloud computing. Nous essayerons de faire une sélection des technologies réccurentes.

La virtualisation

Lorsqu’est évoqué la notion de cloud computing, la notion de virtualisation n’est pas bien loin. La montée en popularité du cloud computing coïncide largement avec la monte en popularité des plate-formes de virtualisation. Bien qu’il existe de nombreux types de virtualisation, la virtualisation de systèmes d’exploitation est la plus fréquente, de loin. Nous pouvons affirmer de manière relativement sûre que la base essentielle du cloud computing est la virtualisation de systèmes d’exploitation.

La virtualisation de système d’exploitation n’est cependant pas un phénomène récent. Les premières applications de VMWare datent de 1998. L’amélioration des processeurs x86 n’est certainement pas étranger à ce phénomène avec la multiplication et la densification des coeurs de calcul. La montée du cloud computing est sans aucun doute liée avec la montée en puissance des applications d’automatisation des plate-formes de virtualisation. Cette automatisation permet une flexibilité exceptionnelle et une réactivité dans l’évolution du cloud.

La place de l’open source

Alors que l’on pourrait croire que l’acteur le plus populaire dans ce domaine est VMWare, la réalité ne confirme pas cette intuition. L’open source joue un rôle essentiel dans le domaine du cloud computing à travers l’hyperviseur Xen. Le cloud publique d’Amazon est basé sur le projet Xen tout comme l’offre de serveur virtuel privé de Gandi. Cette adoption massive peut probablement s’expliquer par la nature open source de l’hyperviseur ayant permis le développement des outils d’automatisation mais aussi par la faible perte de performance. Bien que le projet KVM ait été intégré dans le noyau Linux et choisi par différentes distributions, ceci signifie en aucun cas la fin du projet Xen.

Dans le cas du déploiement de grands clouds publiques, l’utilisation des plate-formes de virtualisation propriétaires telles que VMWare ou Hyper-V ne semblent pas viables financièrement. Les licences VMWare sont exceptionnellement coûteuses, de même pour les licences Windows 2008 Server. Un grand cloud public basé sur ces technologies rendrait l’offre particulièrement peu compétitive. De plus, l’hébergeur dépendrait totalement de l’éditeur pour les fonctionnalités qu’il peut implémenter et n’aura que peu de marge pour innover. L’utilisation des outils propriétaires peut être viable financièrement dans le cadre de clouds privés de taille modeste bien que la gratuité de XenServer de Citrix ne facilite pas l’adoption.

La mise en réseau du stockage

Tandis que les deux premières technologies sont visibles par les utilisateurs des clouds, le troisième l’est nettement moins. Traditionnellement, les unités de stockage de masse sont connectées directement sur les serveurs. Concrètement, cela se traduit par la connexion des disques dur directement sur le bus ATA ou SCSI de chaque serveur. Cette forme de stockage a comme avantage d’être particulièrement simple mais a comme désavantage d’être très peu flexible.

La mise en réseau des éléments de stockage à travers le SAN (Storage Area Network) a permis de s’affranchir de nombreuses contraintes. Cette flexibilité exceptionnelle a permis aux clouds de pouvoir s’automatiser rapidement avec notament l’utilisation des techniques de snapshots ou de déduplication. De plus, le réseau de stockage a permis d’augmenter massivement les performances des IO permettant de pouvoir centraliser les données. Cette centralisation a rendu possible les techniques de migration automatique à chaud et de répartition de charge dynamique entre différents hyerviseurs.

Au final, les technologies du cloud computing sont plus simples à cibler que le concept global. J’aurais l’occasion d’évoquer et de traiter les réseaux de stockage en détail ultérieurement. Ces trois technologies sont des technologies « centrales » autour desquelles peuvent en orbiter de nombreuses autres.

Installation d’OpenVPN sur OpenSolaris

Antoine

Cela fait un bon bout de temps que je n’ai pas eu l’occasion de vous parler d’OpenSolaris. Le dernier article remonte même à mi-Novembre ! Je n’ai pas abandonné ni laissé tomber OpenSolaris, loin de là. La machine virtuelle hébergeant ce blog a été migrée sur OpenSolaris comme j’avais eu l’occasion de l’expliquer dans un article précédent. Je vais donc profiter de ces quelques jours de vacances rallongées (hélas) pour vous parler de l’installation d’OpenVPN sur OpenSolaris.

Pour rappel, OpenVPN est une application qui permet de créer des tunnels VPN chiffrés afin d’y faire passser du trafic IP. Cette application est relativement simple à utiliser une fois qu’on a réussi à comprendre rapidement son fonctionnement. Je vous en avais déjà parlé à travers l’article sur Viscosity, client VPN pour MacOS. Si vous êtes intéressés par un tutoriel d’installation sous Linux, je vous renverrais vers l’excellent tutoriel écrit par Smurf.

Pré-requis

Afin de pouvoir installer OpenVPN sur OpenSolaris, il va vous falloir une installation fonctionnelle d’OpenSolaris. Logique, non ? Nous allons ensuite travailler avec les packages fournis par Blastwave. Il s’agit d’un dépot de paquets spécifiques de manière similaire au dépots Sun. L’avantage de Blastwave est que les paquets sont plus nombreux et plus récents. Le nom des paquets Blastwave commencent par CSW au lieu de SUNW pour les paquets Sun. Afin de pouvoir installer facilement des paquets Blastwave, il est nécessaire de récupérer et installer l’utilitaire d’installation pkgutil (sorte d’équivalent à apt-get).

# wget ftp://ftp.belnet.be/packages/blastwave.org/pkgutil_1.6.1_i386.pkg

# pkgadd -d pkgutil_1.6.1_i386.pkg

Une fois cette utilitaire installé, nous allons pouvoir installer le reste beaucoup plus simplement.

Installation

Tout d’abord, nous allons devoir récupérer et installer les modules tun et tap nécessaires pour le fonctionnement d’OpenVPN. Une fois que ces modules seront installés, nous allons pouvoir nous occuper d’OpenVPN. De manière similaire à apt-get, la récupération des binaires et leur installation est automatique.

# /opt/csw/bin/pkgutil -i tun tap
# /opt/csw/bin/pkgutil -i openvpn

L’installation de tous ces paquets se fait toute seule. Il sera juste peut être nécessaire de confirmer l’installation en tapant un simple « y ».

Génération des certificats

Une fois l’installation initiale des paquets terminée, nous allons nous attaquer à la génération des certificats. Nous allons tout d’abord créer le certificat racine de notre serveur OpenVPN. Le certificat racine est le certificat d’origine qui servira à signer tous les certifications délégués aux utilisateurs de notre concentrateur VPN.

# cd /etc/csw/openvpn/easy-rsa
# source vars
NOTE: when you run ./clean-all, I will be doing a rm -rf on /etc/csw/openvpn/easy-rsa/keys
# ./clean-all
# ./build-ca
Generating a 1024 bit RSA private key
.++++++
………..++++++
writing new private key to ‘ca.key’

Un certain nombre de questions vous seront ensuite posées. Les réponses à ces questions permettront de pouvoir identifier plus clairement votre certificat racine. Rassurez-vous, il n’y a donc pas de mauvaise réponse. Une fois que vous aurez fini, vous remarquerez que deux nouveaux fichiers ont été créés : ca.crt et ca.key. Le fichier ca.key est à garder précieusement car c’est ce dernier qui permet de signer et de créer de nouveaux certificats donnant accès à votre concentrateur VPN. Nous allons ensuite créer le jeu de clés du serveur OpenVPN.

# ./build-key-server server
Generating a 1024 bit RSA private key
………………………………………………++++++
………………..++++++
writing new private key to ‘server.key’

Une fois le certificat du serveur créé, vous retrouverez les fichiers server.key et server.crt. Nous allons ensuite pouvoir créer les certificats de nos utilisateurs. Des informations vous seront également demandées sur l’utilisateur pour la création de certificat. Ces informations permettent d’identifier vos utilisateurs, vous avez donc tout intérêt à les remplir précisément.

# ./build-key antoine
# ./build-key jeanmarc

Afin d’achever la génération des certificats, nous allons devoir créer le paramètre de Diffie-Hellman. La génération peut prendre du temps surtout sur un processeur peu occupé.

/etc/csw/openvpn/easy-rsa# ./build-dh
Generating DH parameters, 1024 bit long safe prime, generator 2
This is going to take a long time

Configuration d’OpenVPN

Tout d’abord, nous allons devoir rendre accessible au service les différents certificats dont il va avoir besoin.

# cd /etc/csw/openvpn
# /etc/csw/openvpn# cp openvpn.conf.CSW openvpn.conf
# /etc/csw/openvpn# ln -s easy-rsa/keys/dh1024.pem
# /etc/csw/openvpn# ln -s easy-rsa/keys/server.crt
# /etc/csw/openvpn# ln -s easy-rsa/keys/server.key
# /etc/csw/openvpn# ln -s easy-rsa/keys/ca.crt

Il est nécessaire ensuite de renseigner les différentes informations dans le fichier de configuration d’OpenVPN. Je ne parlerais pas de ce fichier en détail ici car d’autres sites le font déjà et bien mieux que moi. Les lignes importantes sont les suivantes. L’utilisation de TCP pour un VPN est sous-optimal mais permet de contourner une bonne partie des firewalls associé avec le port 443 (HTTPS).

port 443
proto tcp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
server 172.19.0.0 255.255.255.0

Ensuite, vous allez pouvoir tester votre paramétrage en exécutant le service OpenVPN.

# ifconfig tun0 unplumb
# /opt/csw/sbin/openvpn /etc/csw/openvpn/openvpn.conf

L’affichage des logs sera fera directement sur votre écran ce qui vous permettra de diagnostiquer d’éventuelles erreurs de configurations ou de connexion. Et ensuite, pour lancer définitivement le démon :

# ifconfig tun0 unplumb && /etc/init.d/openvpn start

Au final, ce petit tutoriel vous permettra de créer un tunnel OpenVPN afin de pouvoir communiquer avec votre serveur de manière sécurisée. Je ferais un autre billet expliquant les manipulations supplémentaires pour passer toute sa connexion Internet dans ce même VPN. Ce tutoriel est largement inspiré d’un autre tutoriel en anglais.

Les domaines Xen : le domaine privilégié

Antoine 4 commentaires

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.

L’envers de la virtualisation, épisode 2

Antoine 3 commentaires

tech-presentation-2Lors du précédent article, j’ai introduit cette série d’articles par le portrait marketing de la virtualisation. Vous l’aurez sans doute compris que ce portrait se voulait ironique. L’ironie puise cependant ses origines dans la réalité. Les discours marketing sont souvent assez peu loin de ce que j’ai eu l’occasion de décrire.

Une boite noire qui fait tout

La virtualisation se vend actuellement sous forme de solutions « boite noire » qu’on installe sur un serveur standard. Cette configuration incite à faire penser qu’il est possible d’installer cette « boite noire » en mode Windows sans se poser la moindre question. Lorsque vous installez une plateforme de virtualisation, l’hyperviseur de virtualisation est la couche applicative la plus critique de votre infrastructure. Vous comprendrez donc aisément l’importance et la criticité de ce composant applicatif.

L’installation d’un hyperviseur de virtualisation doit être la plus standard possible. Vous allez sans aucun doute être amené à migrer des machines virtuelles d’un serveur à un autre. Il faut donc que la couche la plus basse soit standardisée. De plus, il est nécessaire de limiter au strict nécessaire les fonctions exécutées par la couche de virtualisation afin de limiter les possibilités de bugs.

On l’installe et on l’oublie

Au cours de l’exploitation de votre plateforme, vous serez sans aucun doute amener à rencontrer des problèmes liés à la couche de virtualisation. Penser que la virtualisation est quelque chose de parfaitement transparent est parfaitement faux. Il est nécessaire de maintenir cette plateforme. Des actions de maintenance classique sont l’analyse des performances afin de déterminer si votre plateforme est correctement dimensionnée ainsi que l’analyse des fichiers de logs.

Tous les défauts inhérents à un système d’exploitation peuvent se retrouver au niveau des couches de virtualisation. Il n’y a pas de magie spécifique qui tendrait à rendre parfait une plateforme de virtualisation. Il est nécessaire d’y porter un regard attentif et régulier.

Tout marche tout seul

Cette affirmation peut être vraie. Cependant, la limite de sa véracité se limite à la survenue du premier problème lié à la couche de virtualisation. Les problèmes vont avoir besoin de personnes pour se résoudre. Les problèmes de couche de virtualisation ne sont pas forcément simples. Il est donc nécessaire d’avoir du personnel formés à la virtualisation qui connaissent les spécificités de cet outil ainsi que son fonctionnement.

Au final, la virtualisation est une technique informatique exceptionnelle qui s’implante avec succès dans les infrastructures actuelles. Il est cependant nécessaire de prévoir soigneusement l’installation des couches de virtualisation afin d’assurer une homogénéité et d’éviter de nombreuses surprises en cas de défaillance. Il est également nécessaire de prévoir et prendre le temps d’analyser le fonctionnement quotidien de cette couche de virtualisation afin de s’assurer de sa santé et de prévoir les évolutions. De plus, une couche de virtualisation n’est pas un système d’exploitation comme un autre et nécessite une formation spécifique.

Configuration réseau d’OpenSolaris

Antoine 1 commentaire

solarisJe vous ai déjà fait une présentation succincte de Solaris et introduit la prise en main d’un tel système d’exploitation. Au fur et à mesure que je découvre, de mon coté, OpenSolaris, je rencontre différents problèmes. Un problème assez handicapant que j’ai rencontré est la configuration réseau.

Lorsque j’ai monté ma machine virtuelle OpenSolaris, j’ai fait la configuration réseau à la main rapidement via l’utilitaire ifconfig. Je ne représenterais pas cet utilitaire dans ce billet. Son fonctionnement sous Solaris est fortement similaire à son fonctionnement sous Linux. L’utilitaire route fonctionne de manière similaire pour l’ajout de routes. Il est cependant différent dans la mesure où il ne permet pas l’affichage de la table de routage via la commande route -n. Afin d’afficher la table de routage, il est nécessaire d’exécuter la commande netstat -rn.

La problématique de ce type de configuration est que la configuration n’est pas conservée après un redémarrage du système d’exploitation. Nous allons donc nous intéresser plus spécifiquement à la configuration pérenne des interfaces réseau en IP statique. La configuration se fera via le module physical:default.

Tout d’abord, vous allez devoir déclarer le nom d’hôte de votre machine. Vous remplacerez xnf0 par le nom de votre interface réseau.

echo « hostname »> /etc/hostname.xnf0

Ensuite, on sauvegarde le fichier hosts d’origine et on y insère les noms d’hôte de votre machine.

echo « 127.0.0.1 localhost »> /etc/inet/hosts

echo « 10.0.0.3 antoinebenkemoun.fr »>> /etc/inet/hosts

Nous allons ensuite spécifier le masque de sous-réseau lié à cette interface.

echo « 10.0.0.0 255.0.0.0 »>> /etc/inet/netmasks

Il nous reste plus qu’à préciser la route par défaut.

echo « 10.0.0.1 »> /etc/defaultrouter

La configuration de l’interface est désormais terminée. Il ne nous reste plus qu’à vérifier que les bon services sont activés. Nous devons activer le service physical:default et désactiver physical:nwam. Ce deuxième service est un doublon du premier, il ne faut donc en activer qu’un seul.

svcadm disable svc:/network/physical:nwam

svcadm enable svc:/network/physical:default

Afin de faire prendre en compte les modifications d’interface réseau, il est nécessaire de redémarrer le service physical:default.

svcadm restart svc:/network/physical:default

Le tour est joué ! Je pense que ce billet devrait être utile à certaines personnes démarrant sous Solaris et venant du monde de Linux. Dans tous les cas, il me sera utile pour future référence.

Vestiges informatiques normands

Antoine

Ca fait plus d’une semaine que je n’ai pas publié de billet sur ce blog. La raison de ce vide est essentiellement un manque de motivation ambiante. Je reprends cependant de plus belle cette semaine. J’ai un article en préparation sur l’envers du décor de la virtualisation. En attendant la publication de cet article, je souhaitais vous faire partager une trouvaille que j’ai effectué lors de mon weekend en Normandie. Je laisse parler la photo suivante.

IMAG0034

Vous pourrez tout d’abord remarquer la qualité assez étonnante de la photo étant donné qu’elle a été prise avec mon HTC G1. J’ai été, moi même, surpris après l’exportation. Vous remarquerez ensuite la présence de bonnes vieilles disquettes sur l’étalage d’un magasin. Ceci n’est pas une image d’archive, loin de là. Elle a été prise Samedi dernier. 10 disquettes 2HD formatées pour MS-DOS pour la modique somme de 5,25€ !

La capacité de stockage de chaque disquette est de 1,44 Mo, nous avons donc au totale 14,4 Mo de données. Ceci nous fait un prix de 36 cents le Mo. Que le stockage amovible a évolué depuis cette époque… Ce qui fait l’objet de ce billet est que cette époque ne semble pas être totalement révolue chez quelques irréductibles normands.