Étiquette : Explication

La déduplication de données

Antoine 5 commentaires

Profitons de cette journée pluvieuse pour parler d’un peu de stockage. J’ai relativement peu l’occasion de parler de stockage sur ce blog bien que ce soit un sujet particulièrement intéressant, surtout dans le cas des réseaux de stockage. Ce n’est cependant pas de réseaux de stockage dont nous parlerons aujourd’hui mais de déduplication de données.

Notion de duplication

La notion de duplication de données est relativement simple. Prenons un jeu de données, la duplication de ces données donne un second jeu identique de données mais sur un autre espace de stockage. Il est possible de faire de la duplication dans le cas de la copie de disques ou de DVD par exemple. Il est également intéressant de faire de la duplication de données dans le cas de la virtualisation. Lorsque des machines virtuelles sont « provisionnées » ou bien, plus simplement, créées, une technique envisageable est la duplication d’une machine virtuelle « template ».

Dans le cas de la virtualisation, de nombreuses données sont présentes en plusieurs exemplaires. Sur une plateforme de virtualisation, il va être exécuté un certain nombre de systèmes d’exploitation. Un serveur de virtualisation standard aujourd’hui est capable d’exécuter 20 à 30 machines virtuelles. Supposons que ces machines virtuelles disposent de 2-3 systèmes d’exploitation différents, cela implique que 7 à 15 copies du même système d’exploitation vont être stockées.

Définition de la duplication

La déduplication va nous permettre de solutionner en grande partie ce problème. Cette technique a pour objectif de supprimer les doublons/triplons/etc du support de stockage afin de stocker qu’une seule copie des données. Il est possible d’implémenter cette technique à plusieurs endroits et à plusieurs niveaux. Prenons tout d’abord l’exemple de la mémoire vive et ensuite, l’exemple des disques.

Déduplication de la mémoire vive

La mémoire vive est un support de stockage d’information particulièrement couteux. Nous avons donc tout intérêt à en optimiser son utilisation. L’exemple que nous avons proposé plus haut pour illustrer la duplication des données est tout à fait valable pour les informations stockées en mémoire vive.

Le système d’exploitation va calculer une empreinte (« hash » pour les anglophones) pour une certaine unité de stockage pour la totalité de la mémoire vive. Lorsque le système rencontrera deux unités présentant la même empreinte, il en supprimera une copie et fera un lien vers l’unique copie. L’unité de stockage utilisée est, souvent, la page mémoire. Une empreinte est donc calculée pour chaque page mémoire et la déduplication se fait à ce niveau.

A ma connaissance, seuls les systèmes de virtualisation utilisent cette technique pour la mémoire vive. C’est, plus particulièrement, le cas de VMWare et de Xen 4.0.

Déduplication de disques

L’exemple de la mémoire vive est transposable aux supports de disque divers. La déduplication au niveau des disques va permettre les mêmes avantages que la mémoire vive et utilisera le même fonctionnement. La différence se situe principalement au niveau de l’unité de stockage qui sera choisie pour le calcul de l’empreinte. Le bloc sera, le plus souvent, utilisé pour les disques.

Une application réelle pour la déduplication se situe d’une part dans les systèmes de virtualisation mais aussi dans les systèmes de sauvegarde dans lesquels on peut retrouver de (très) nombreuses copies d’une même copie. Les équipements qui effectuent la déduplication sont les SAN mais aussi les systèmes de fichiers (« filesystem » pour les anglophones).

Vous allez me dire « Mais mon Linux il sait pas faire ca ! » et, oui, vous avez raison. Si vous voulez effectuer de la déduplication au niveau d’un système de fichiers, il va falloir utiliser ZFS sous OpenSolaris. J’en parlerais dans un prochain billet. Il serait prévu d’inclure ce type de fonctionnalité dans Btrfs.

Au final, j’espère avoir fait un tour d’horizon assez complet de cette technique relativement récente mais que je trouve particulièrement intéressante.

Installation de Xen 4.0 sur Debian Lenny

Antoine 8 commentaires

Les tutoriels d’installation ne sont pas forcément les plus intéressants à blogger et j’en ai fait très peu pour cette raison. J’avais déjà parlé de l’installation de Xen 3.2.1 sur Debian Lenny. Au moment où j’ai écrit ce billet, cette version commençait à être relativement vieillissante. Je vais donc traiter aujourd’hui de l’installation de Xen 4.0.

Petit historique

Vous savez peut être que Xen a été quelque peu obscurcit par l’introduction de KVM dans le noyau Linux. Cette inclusion de KVM a conduit des distributions telles que Red Hat et Ubuntu à supprimer Xen de leurs distributions ou de ne laisser qu’un support pour le moins minimal. A l’époque de ces faits, Xen n’était compatible qu’avec un ou deux noyaux Linux patchés par l’équipe de Xen. Cette époque est révolue car Xen a évolué vers les noyaux dits « Paravirt Ops » ce qui signifie que la compatibilité d’un noyau Linux avec Xen ne tient plus qu’à un module de ce même noyau.

La version Xen 4.0 est particulièrement intéressante car il s’agit de la première version qui fonctionne par défaut avec les noyaux Paravirt Ops. L’installation de versions antérieures vous assurera la douleur de devoir éventuellement passer vers une version supérieure à la 4.0 lorsque vous voudrez mettre à jour vos noyaux Linux.

Installation

Nous pouvons désormais passer aux choses sérieuses. Nous allons effectuer une installation à partir des sources car il n’existe pas encore de paquets. Et puis de toute façon, une petite compilation ne vous fait pas peur !

Nous allons tout d’abord récupérer l’archive sur le site de Xen et on la dézippe :

wget http://bits.xensource.com/oss-xen/release/4.0.0/xen-4.0.0.tar.gz

tar zxvf xen-4.0.0.tar.gz

Nous allons ensuite installer tous les pré-requis et ils sont nombreux.

apt-get install bcc bin86 gawk bridge-utils iproute libcurl3 libcurl4-openssl-dev bzip2 module-init-tools transfig tgif texinfo texlive-latex-base texlive-latex-recommended texlive-fonts-extra texlive-fonts-recommended pciutils-dev mercurial build-essential make gcc libc6-dev zlib1g-dev python python-dev python-twisted libncurses5-dev patch libvncserver-dev libsdl-dev libjpeg62-dev iasl libbz2-dev e2fslibs-dev git-core uuid-dev gcc-multilib

Passons désormais à la compilation. Si vous avez une machine dotée de plusieurs cœurs / processeurs, n’hésitez surtout pas à utiliser l’option -jX où X est le nombre de cœurs que vous avez. Cette option permet de répartir la compilation sur tous les cœurs et ainsi de la finir plus rapidement. J’avais un BiQuad Core, donc ce sera 8 pour cet exemple.

make -j8 xen

make -j8 tools

make -j8 stubdom

Ensuite, on installe tout ca.

make -j8 install-xen

make -j8 install-tools

make -j8 stubdom

Grâce à toutes ces commandes, nous avons installé Xen ainsi que tous les outils associés. Il nous manque plus que le noyau Linux pour les domaines. A partir de là, vous pouvez soit créer votre propre noyau soit utiliser un noyau proposé par Xen. J’ai choisi de faire cela car c’était plus simple, plus rapide et plus pratique.

On va donc exécuter la commande qui va nous permettre de récupérer et de compiler le noyau qui va bien pour notre installation de Xen.

make -j8 world

Pour installer le noyau que vous avons compilé, il ne manque qu’à exécuter la commande suivante. On crée au passage l’initrd qui va bien.

make install

mkinitramfs -o /boot/initrd-2.6.31.13.img 2.6.31.13

Vous devez ensuite modifier Grub afin qu’il s’adapte à Xen. La configuration suivante fonctionne sur l’hyperviseur que j’ai eu l’occasion d’installer. Il faut adapter le root en fonction de votre serveur. Ici, il s’agissait d’un contrôleur RAID HP.

title           Xen 4.0.0 / Debian GNU/Linux, kernel 2.6.31.13
root            (hd0,1)
kernel          /boot/xen-4.0.0.gz
module          /boot/vmlinuz-2.6.31.13 root=/dev/cciss/c0d0p2 ro console=tty0
module          /boot/initrd-2.6.31.13.img

Vous pouvez ensuite rebooter sur votre nouvelle installation de Xen 4.0 avec votre noyau Paravirt Ops. Si vous souhaitez modifier des options à la compilation du noyau, il faut se placer dans le bon répertoire et activer les bons paramètres dans le menu.

cd build-linux-2.6-pvops_x86_64

make menuconfig

Il faut activer le support TUN/TAP si vous souhaitez exécuter des domaines HVM ainsi que le support du 802.1Q si vous souhaitez placer vos domaines sur différents VLAN. Ces deux options ne sont pas activées par défaut.

Au final, j’espère que ce tutoriel vous sera utile et que j’ai été clair. Le passage vers les noyaux en Paravirt Ops est une évolution majeure dans l’histoire de Xen et permettra une adoption nettement plus large.

Génération de certificats OpenVPN par lots

Antoine 4 commentaires

J’ai déjà eu l’occasion de parler d’OpenVPN plusieurs fois sur ce blog car je pense qu’il s’agit d’une application très intéressante. J’avais déjà traité l’installation d’OpenVPN sur OpenSolaris et le client MacOS Viscosity. Une problématique régulièrement rencontrée est la génération de certificats SSL pour OpenVPN afin de créer des accès utilisateur à un serveur.

La méthode la plus simple consiste à utiliser les outils easy-rsa en ligne de commande. Ces outils simplifient réellement la tâche par rapport à l’utilisation directe d’OpenSSL. Le problème avec l’utilisation de ces outils est la nécessité d’interagir avec le terminal. Cet outil va vous demander bon nombre de renseignements tels que le pays, la ville, l’adresse email, etc. Cette interaction rend compliquée la création par lots de certificats.

Une méthode plus compliquée, mais plus efficace, consiste à adapter les scripts easy-rsa afin de rendre leur utilisation plus linéaire et non interactive afin qu’un script puisse les exécuter. De plus, j’ai souhaité donner la possibilité de spécifier la durée de validité du certificat au cas par cas, ce qui n’est pas possible par défaut.

Le premier script, build-key-batch, permet de créer une clé en spécifiant une durée de validité. Il n’y a qu’une toute petite modification qui permet de récupérer la durée de validité passée en argument.

#!/bin/sh

if test $# -ne 2; then
     echo « usage: build-key-batch <name> <duree> »;
     exit 1
fi

if test $KEY_DIR; then
     cd $KEY_DIR && \
     openssl req -days $2 -nodes -new -keyout $1.key -out $1.csr -batch -config $KEY_CONFIG && \
     openssl ca -days $2 -out $1.crt -in $1.csr -batch -config $KEY_CONFIG && \
     chmod 0600 $1.key
else
     echo you must define KEY_DIR
fi

Par défaut, easy-rsa nécessite d’exécuter le fichier vars dont le rôle est d’exporter un certain nombre de variables d’environnement utilisées par les scripts de génération de clé. Cela ne me convenait pas car je souhaitais exécuter un seul fichier contenant toutes les informations dont je pouvais avoir besoin. J’ai donc créé un script nommé build-batch qui contient toutes les options.

#!/bin/sh
if test $# -ne 2; then
     echo « usage: batch-build <name> <duree> »;
     exit 1
else
     # Definition des variables
     export D=`pwd`
     export KEY_CONFIG=$D/openssl.cnf
     export KEY_DIR=$D/keys
     export KEY_SIZE=1024
     export KEY_COUNTRY=FR
     export KEY_PROVINCE=XX
     export KEY_CITY=Paris
     export KEY_ORG= »Keeyyyy »
     export KEY_EMAIL= »$1″
     export KEY_CNAME=$1
     ./build-key-batch $1 $2
fi

Ce script nécessite une petite modification du fichier openssl.cnf présent dans le dossier easy-rsa qui est la suivante :

commonName = Common Name (eg, your name or your server\’s hostname)
commonName_max = 64
++ commonName_default = $ENV::KEY_CNAME

Le script a exécuter afin de générer un certificat est donc build-batch suivi de deux arguments qui sont le nom du certificat et la durée de validité. Vous pourrez ainsi générer des certificats pour OpenVPN simplement et efficacement sans nécessiter une intervention humaine.

Source : insights

Le futur d’OpenSolaris

Antoine 10 commentaires

Ce billet marque une petite pause dans les billets sur la gestion du réseau d’une LAN Party. Au début de ce blog, j’avais annoncé que je ne souhaitais pas être un blog traitant de l’actualité au jour le jour car il en existe déjà de nombreux. Je vais donc traiter aujourd’hui de l’actualité d’OpenSolaris suite au rachat de Sun par Oracle.

Vous le savez sans aucun doute tous, Oracle a racheté Sun suite à de nombreuses négociations avec les différentes autorités notamment européennes. Sun est un grand groupe informatique relativement peu connu du grand public aujourd’hui mais qui a largement participé à l’expansion de l’informatique tel que nous la connaissons aujourd’hui. Les produits les plus connus de Sun sont la base de données MySQL, le système d’exploitation Solaris et la plateforme Java. Oracle est également un grand groupe dont le cœur de métier est la base de données dans toutes ses formes.

Annonces faites par Oracle

Dès l’annonce du rachat, Oracle a manifesté un fort intérêt pour Solaris contrairement aux intentions que certains ont pu lui prêter. L’annonce d’un investissement massif, supérieur à celui de Sun, dans Solaris a rapidement été évoqué. Le futur de Solaris n’a jamais été mis en doute. La réelle modification apportée par Oracle est la suppression de la gratuité de Solaris.  Ceci se comprend dans la mesure où Solaris est un système d’exploitation réellement orienté vers les infrastructures à très haute disponibilité. Qui dit haute disponibilité, dit coûts. C’est donc une évolution relativement logique pour viabiliser cet OS.

La gestion par Sun de Solaris faisait qu’il était possible pour une société de payer une souscription Solaris pour un seul serveur et ensuite de propager toutes les mises à jour sur tous leurs serveurs. Oracle a voulu, assez logiquement, supprimer cela en introduisant la notion de contrats équivalents sur tous les serveurs. De plus, Oracle a annoncé que toutes les fonctionnalités ne seraient pas incluses dans Solaris ce qui était déjà le cas à l’époque de Sun. Il s’agit cependant de fonctionnalités ultra-spécifiques. Le cheminement naturel est plutôt d’introduire les fonctionnalités OpenSolaris vers Solaris.

La situation d’OpenSolaris

Parlons désormais d’OpenSolaris. De la même manière que GNU n’est pas Linux, OpenSolaris n’est pas Solaris. OpenSolaris est à Solaris ce qu’est Fedora à Red Hat.

OpenSolaris est effectivement un logiciel libre bien que pas sous licence GNU/GPL.  Sur les mailing-list associées à ce projet, il a été fait une étude des éléments qui seraient à recréer si Oracle reniait OpenSolaris. Seul une centaine d’éléments non critiques seraient à revoir dont une bonne partie sont déjà en cours de réécriture.

Enfin une annonce !

L’erreur d’Oracle a surement été leur mutisme par rapport au futur d’OpenSolaris. Ceci est cependant terminé car Oracle sont sortis de leur silence et ont annoncé qu’il continueraient à soutenir ce projet. Je vous laisse consulter la présentation qui a été faite afin que vous puissiez vous faire votre propre idée.

Oracle is investing more in Solaris than Sun did prior to the acquisition, and will continue to contribute innovative technologies to OpenSolaris, as Oracle already does for many other open source projects

Oracle will continue to make OpenSolaris available as open source and Oracle will continue to actively support and participate in the OpenSolaris community

Toutes les annonces de la mort d’OpenSolaris sont fausses et basées sur le simple silence d’Oracle à ce sujet. De plus, ces fausses annonces ont été fortement relayées sur tous les sites d’informatique. Par contre, lorsqu’Oracle annonce le maintien du projet, l’annonce est pratiquement inaudible et invisible.

Architecture réseau d’une LAN Party : DHCP

Antoine 8 commentaires

Après une petite pause pour parler d’OpenSolaris et une (très) courte semaine de vacances, revenons sur l’Utt Arena et, plus particulièrement, le réseau associé. Aujourd’hui, nous allons faire une pause sur la spécificité du DHCP dans le cadre de ce réseau.

Comme d’habitude, faisons un point d’avancement avant de rentrer dans la discussion technique. Le jour J est ce Vendredi soir donc nous nous retrouvons rapidement au pied du mur. Nous sommes cependant prêts à mettre en place l’architecture que nous avons prévu. La dernière de séance de préparation a été assez confortante car nous avons réussi à mettre en place l’architecture rapidement et effectuer les différents ajouts rapidement. Nous avons du apporter des modifications significatives à l’architecture dont je parlerais dans un prochain billet.

J’en avais déjà parlé lors du billet sur la conception de ce réseau, nous avons prévu de mettre en place un certain nombre de VLAN. Traditionnellement, un seul serveur DHCP était nécessaire afin d’allouer des adresses IP à toute la LAN. Or dans le cas présent, nous sommes loin de cette configuration.

Une première solution, assez primitive, aurait consisté à placer un serveur DHCP dans chaque VLAN. Cette solution est, bien évidemment, pas envisageable de par sa complexité de gestion et de sa consommation en machines. Il aura été possible de comprimer cette solution en utilisant des machines virtuelles mais nous n’avons pas de machine suffisamment puissante afin de faire celà.

La seconde solution, la plus évidente, est d’utiliser les ASA afin d’attribuer les bails DHCP. Cette idée est particulièrement efficace car elle permet de regrouper la configuration en un seul point. Les ASA sont parfaitement capables d’assurer la fonctionnalité DHCP pour plusieurs LAN. Ils peuvent allouer des IP inclues dans une plage sur chaque interface. Ce qui est cependant franchement ridicule, ils ne sont capables d’attribuer qu’une seule passerelle par défaut pour tous les LAN. Concrètement, vous pouvez allouer IP et Passerelle pour un LAN mais que des IP pour tous les autres LAN. Nous ne pouvons donc pas utiliser les ASA afin de servir d’allouer des bails DHCP décemment.

La solution finale est d’utiliser des Cisco 3750 afin d’attribuer des bails DHCP. Les 3750 sont des switchs avec une grosse dose d’intelligence supplémentaire. Ils sont capables, en plus de commuter, de router, de gérer un (ou plusieurs) protocoles de routage et d’allouer des bails DHCP pour plusieurs LAN. Cette solution implique que les 3750 aient une interface IP valide dans chaque LAN.

La configuration DHCP des 3750 est particulièrement simple à effectuer. Il faut d’abord créer l’interface IP associée au VLAN. Dans cet exemple, nous créons une interface IP associée au VLAN n°50 qui aura pour IP 10.5.0.5

interface Vlan50
description Admin
ip address 10.5.0.5 255.255.255.0

Il faut ensuite indiquer au switch la plage d’IP qu’il peut allouer sur cette interface ainsi que la passerelle par défaut.

ip dhcp pool 50
network 10.5.0.0 255.255.255.0
default-router 10.5.0.1

Nous pouvons ensuite exclure une plage d’IP qui servira pour adresser divers équipements réseau : ASA et 3750 dans notre cas.

ip dhcp excluded-address 10.5.0.1 10.5.0.10

Au final, la configuration DHCP des Catalyst 3750 est relativement simple. Afin d’adresser de nombreux VLAN, il suffit de répéter le processus précédent. Ensuite, il suffit de placer les joueurs dans le bon VLAN et ils obtiendront les informations de configuration réseau.

Architecture réseau d’une LAN Party : Filtrage

Antoine 2 commentaires

Ce billet continue la série de billets traitant de l’architecture d’une LAN Party. Après avoir présenté la topologie IP de notre réseau, nous allons nous intéresser au filtrage IP.

Avant de commencer à traiter ce sujet, je vais faire un petit point d’avancement sur la préparation du réseau. Nous avons passé 2 soirées à configurer les équipements Cisco et nous avons réussi à créer la topologie IP évoqué au billet précédent en 2 heures. Ce résultat est relativement satisfaisant et a été rendu possible par la préparation des configurations à l’avance. La quantité de VLAN ne nous a pas posé de problème particulier car la configuration des équipements Cisco est claire à ce niveau. Il nous reste juste une petite problématique au niveau de la communication entre deux interfaces du même ASA.

Le filtrage IP est une composante nécessaire de notre configuration réseau car les ASA refusent par défaut le trafic réseau. Dans le cadre d’une LAN, nous pouvons dissocier deux périodes : les périodes de tournoi et les périodes sans tournoi. Nous avons décidé d’adapter la configuration réseau en fonction de chaque période.

Le filtrage IP hors tournoi sera le plus permissif possible. Il n’y a aucun intérêt à restreindre les flux émanant des tables. Nous imposerons éventuellement une limite de bande passante au niveau des flux sortant sur Internet afin d’éviter la saturation trop rapide du lien. Ce niveau de filtrage nous permettra de tester notre configuration réseau sans se soucier des ACL.

Le filtrage IP pendant les tournois sera, au contraire, le plus restrictif possible. L’objectif est de limiter les flux au minimum nécessaire pour les jeux. La présence de flux parasites serait susceptibles d’impacter négativement la latence des flux de jeux causant ainsi le mécontentement des joueurs.

Au final, le filtrage IP s’adaptera en fonction des conditions de la LAN. Ceci se concrétisera par deux jeux d’ACL que nous appliquerons aux interfaces en fonction du filtrage souhaité.