Le premier objectif d’un serveur personnel est de disposer d’un ordinateur qui permettra de rendre un certain nombre de services sur son réseau de domicile. Ces services peuvent être variés en fonction des envies et des motivations de chacun. Des exemples de services sont DHCP, DNS, Pare-feu, NFS, HTTP et bien d’autres. L’objectif secondaire inavoué, mais non moins important, est la disposition d’une machine permettant de « bidouiller » à loisir.

Objectif

Dans mon cas, l’objectif était de disposer d’une capacité de stockage convenable afin de pouvoir y stocker de nombreuses sauvegardes diverses et variées mais aussi de pouvoir héberger quelques services associés tels que NFS et HTTP. N’ayant plus que du Linux ou du MacOS, CIFS ou Samba ne m’intéressaient pas. Le besoin en puissance est donc relativement limité.

Contraintes

Les contraintes pour ce type de serveur sont cependant nombreuses. Tout d’abord, il est nécessaire que ce serveur soit assez silencieux. J’ai la possibilité de le stocker dans un placard et/ou dans un cagibi mais le problème est qu’il m’est impossible d’y amener un connexion Internet en câblé. Sa localisation sera donc sur une étagère ou entre le canapé et le mur. Le silence est donc un facteur contribuant à une non volonté d’extermination de la part de ma fiancée. Ensuite, il est nécessaire que ce serveur consomme relativement peu d’électricité. L’électricité, ça coûte cher et donc il faut en consommer le moins possible, c’est aussi simple que cela.

De plus, il faut que ce serveur ait des proportions réduites. L’espace entre le mur et le canapé est assez réduit de même pour la place sur l’étagère. Une tour moyenne sera donc bien trop grande pour ces contraintes. Je souhaitais également utiliser du ZFS pour ce serveur afin de ne pas avoir à faire du RAID logiciel standard assez douteux. Il était également nécessaire de pouvoir y placer deux disques dur de 3 pouces et demi en SATA.

Solution matérielle

La plateforme Intel Atom répond particulièrement bien à la contrainte de consommation électrique ainsi qu’à la contrainte de volume physique. C’était donc un choix évident. Le nombre d’ordinateurs de bureau Atom capables d’accommoder deux disques dur de 3 pouces et demi est relativement faible. Mon choix s’est tourné vers la plateforme MSI Nettop.

Par défaut, il n’y a qu’un seul emplacement 3 pouces et demi mais il est possible de retirer le lecteur DVD et le remplacer par un disque dur moyennant l’achat d’un petit kit adaptateur. L’alimentation électrique se fait via un transformateur qui vient fournir le PC directement en courant continu. Il dispose également d’un emplacement SD ce qui pourra éventuellement être utile pour faire de la sauvegarde sur ce type de médium.

Comme vous le savez, ZFS calcule de somme de contrôle pour toutes les données écrites sur ses volumes. Cette opération consomme de la ressource processeur. Le processeur étant un Intel Atom, il y a de quoi se poser des questions en effet. L’objectif n’étant pas de faire des gros transferts de données à la vitesse de la lumière, cela n’est pas réellement problématique. Le débit de données reste relativement correcte.

Par défaut, le MSI Nettop est fourni avec un disque dur de 160Go ce qui est trop peu. J’ai donc acheté un disque supplémentaire Western Digital de 500Go pour le remplacer.

Solution logicielle

Une des contraintes était de pouvoir disposer de ZFS. Cela laisse donc trois choix : Solaris, OpenSolaris ou FreeBSD. Étant donné l’orientation entreprise de Solaris et la nouvelle politique de support d’Oracle, il n’était pas souhaitable de l’utiliser. FreeBSD est un système d’exploitation qui ne me plait pas particulièrement et ce dernier n’est pas au niveau d’OpenSolaris en terme de versions de ZFS. Il n’y a pas de déduplication de données sur ZFS sous FreeBSD. Mon choix s’est donc naturellement tourné vers OpenSolaris.

Un autre avantage est qu’il gère directement NFS et CIFS sans avoir besoin d’applications supplémentaires. Cela rend très simple la gestion de partages réseaux par le biais de commandes simples et efficaces. La documentation Oracle est très claire à ce niveau, je vous laisse la consulter.

Utilisation

Une fois que nous avons une solution logicielle et une solution matérielle, nous allons pouvoir décider ce que nous allons en faire.

Mon serveur me sert en tant que serveur NFS afin de sauvegarder des données à la volée à partir de mes différents ordinateurs. Pour mon MacBook Pro, cela me permet d’utiliser l’excellent Time Machine. La mise en place de Time Machine sur un NFS ne se fait pas sans douleur mais il existe de nombreux tutoriels sur Internet afin de vous aider. Ce serveur effectue une sauvegarde périodique (tous les 15 minutes) de mes emails Gmail. L’application getmail permet de récupérer en POPS les nouveaux mails. La récupération initiale de mes 70.000 mails a pris une nuit sur mon ADSL 7Mbit/s et désormais il récupère juste les mails le plus récents.

Ce serveur héberge également mon blog en ce moment le temps que je réinstalle ma VM Xen. Le temps de chargement de pages web a même été amélioré par rapport à ma VM ce qui est assez impressionnant. J’ai activé la déduplication de données en même temps que j’ai écrit le tutoriel précédent. Ce serveur a été tout à fait stable. Je n’ai rencontré aucun problème depuis 2 mois que ce serveur est en place.

]]> http://www.antoinebenkemoun.fr/2010/05/un-serveur-personnel-avec-zfs/feed/ 7 http://www.antoinebenkemoun.fr/2010/05/activer-la-deduplication-de-donnees-avec-zfs/ http://www.antoinebenkemoun.fr/2010/05/activer-la-deduplication-de-donnees-avec-zfs/#comments Tue, 11 May 2010 12:41:47 +0000 Antoine http://www.antoinebenkemoun.fr/?p=1140 Nous avons vu la dernière fois ce qu’était la déduplication de données ainsi que les applications (essentiellement libres) de cette technologie. Nous allons désormais nous intéresser à la mise en place de cette technologie dans le cas d’un système de fichiers ZFS.

Si vous avez un système de fichiers ZFS, cela signifie que vous avez soit un OpenSolaris soit un BSD. Vous ne pourrez pas faire de déduplication de données avec votre BSD car les versions actuellement implémentées ne supportent pas cette technologie. Vous devrez donc avoir un OpenSolaris sous le coude. De plus, la déduplication a été ajouté au build 128 d’OpenSolaris. Si vous avez une version 2009.06, vous allez devoir faire une mise à jour vers les dépôts de développement ou bien attendre la nouvelle version (qui aurait du être 2010.03). Je parlerais de la mise à jour très prochainement.

Vérifions donc que vous avez la bonne version d’OpenSolaris en regardant le fichier /etc/release. Vous devez avoir une information indiquant un numéro de version supérieur à 128. Dans le cas de mon OpenSolaris, ce fichier contenait, entre autre, la ligne suivante : OpenSolaris Development snv_134 X86.

Par défaut, la déduplication n’est activée sur aucun pool ZFS. Si vous avez fait la montée de version sans demander de fonctionnalités supplémentaires de ZFS, il est probable que votre version de ZFS soit antérieure à celle supportant la déduplication.

Vérifiez donc la liste des volumes ZFS à mettre à jour.

# zpool upgrade
This system is currently running ZFS pool version 22.

The following pools are out of date, and can be upgraded. After being
upgraded, these pools will no longer be accessible by older software versions.

VER POOL
— ————
14 rpool

Use ‘zpool upgrade -v’ for a list of available versions and their associated features.

Nous allons donc mettre à jour nos pools ZFS afin de pouvoir bénéficier de la déduplication.

# pfexec zpool upgrade -a
This system is currently running ZFS pool version 22.

Successfully upgraded ‘rpool’

Nous avons donc mis à jour notre pool ZFS. Il nous reste plus qu’à activer la fonctionnalité.

$ zfs get dedup rpool
NAME PROPERTY VALUE SOURCE
rpool dedup off default
$ pfexec zfs set dedup=on rpool
$ zfs get dedup rpool
NAME PROPERTY VALUE SOURCE
rpool dedup on local
$ zpool list rpool
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
rpool   19.9G 10.7G   9.19G  53% 1.00x     ONLINE       -

Le tour est joué ! Le facteur de déduplication vous indique la quantité d’espace disque que vous avez économisé. Lorsque vous activez la déduplication sur un volume, ce facteur est de 1x par défaut. Les données actuellement présentes sur le volume ne seront pas dédupliquées, il faudra attendre que de nouvelles données soient ajoutées.

Source : CTIStrategy

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.

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.

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

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.

Avant de commencer, il est nécessaire de balayer toutes les éventuelles rumeurs quant à une éventuelle disparition d’OpenSolaris suite au rachat par Oracle. De nombreux médias dits « spécialisés » ont publié des informations très largement fausses par rapport aux conséquences du rachat ou ont très largement oublié certains faits. Si vous souhaitez un article relativement neutre sur le sujet, je vous conseille le blog c0t0d0s0.org.

Le projet Crossbow est un sous-projet lié à la distribution OpenSolaris qui a été intégré à la version 2009.06. L’objectif de ce projet était d’adapter la pile TCP/IP à la virtualisation et d’y ajouter de nombreuses fonctionnalités. Je m’intéresserais plus particulièrement aux outils de gestion de bande passante.

La gestion de bande passante ou QoS est une fonctionnalité bien ancrée dans les équipements réseaux. L’objectif de cette technique est de réguler les flux réseau afin de permettre un partage équitable ou bien une limite définie. La mise en place de cette fonctionnalité est particulièrement compliquée et obscure sous Linux. La documentation, particulièrement nécessaire étant donnée la complexité des outils, est difficile à trouver.

OpenSolaris propose un première utilitaire permettant de différencier les différents flux réseaux selon des critères de niveau 3 et 4 : flowadm. Vous allez pouvoir créer un « flow » selon différents critères que vous choisirez. Vous allez ensuite pouvoir attribuer différentes caractéristiques à ce flux. Par exemple, vous pouvez lui donner un ou bien une priorité, voire même une limite de bande passante. L’incroyable avantage de cet outil est la simplicité avec laquelle il est possible de l’utiliser. En une commande, vous arrivez à créer un flux, lui donner une priorité et lui appliquer une limite de bande passante. En voici un exemple :

flowadm add-flow -l bge0 -a transport=UDP -p maxbw=100M, priority=low limit-udp-1

La page de man de flowadm est particulièrement claire et propose de nombreux exemples dont celui ci-dessus. Une seule commande pour faire tout ca, je trouve ca plutôt exceptionnel. La limite minimale de bande passante que vous pouvez attribuer est fonction du MTU. Dans le cas d’un MTU Ethernet classique, il s’agit de 1,2Mbps.

Une autre fonctionnalité très intéressante est la possibilité d’effectuer de « l’accounting » sur les différents flows que vous avez créé. Vous pourriez par exemple avoir envie de connaitre la quantité de données échangées pour chaque flux. OpenSolaris vous propose ceci ainsi que la possibilité de voir la quantité de données échanges par intervalle de temps. Pour cela, vous pourrez utiliser l’utilitaire acctadm. Cet utilitaire vous permet d’activer l’accounting au niveau de votre système et la commande flowadm vous permettra d’en visualiser le résultat.

Ce billet effectue un tour d’horizon rapide de ce que peut proposer le projet Crossbow en termes de gestion de bande passante réseau. OpenSolaris a clairement une grande avance sur Linux sur ce point bien que ce dernier en soit capable, mais clairement pas avec autant de simplicité.

Lorsqu’une architecture est conçue initialement, les concepteurs disposent d’un certain nombre d’éléments motivant un choix technologique par dessus un autre. Dans le cas du cloud computing, ces éléments ne sont pas fixés depuis une durée particulièrement longue et ne sont clairement pas fixés à des échéances au delà du moyen terme. La relative nouveauté du cloud computing devrait démotiver bon nombre de concepteurs d’architecture.

Dans le cas où le choix serait fait de se baser sur une architecture intégrée au sein d’un cloud quelconque, il est nécessaire de se poser très sérieusement la question de l’interopérabilité. Lorsqu’une entité va placer son architecture,  elle confiera d’une part ses données mais aussi le travail humain lié à la conception d’une plateforme. Ce travail humain a un coût relativement important en fonction de l’architecture en question. De sérieux problèmes sont à envisager dans l’éventualité d’une faillite de la société hébergeant le cloud ou même une catastrophe quelconque mettant à mal le cloud. La non-transparence des clouds actuels rend exceptionnellement compliqué l’évaluation de ces risques.

La problématique de l’interopérabilité se pose ainsi. Dans le cas où une entité utilisatrice utilisatrice d’infrastructure cloud souhaite changer d’hébergeur pour une raison X ou Y, en a-t’elle la possibilité ? Il y a bien sur plusieurs niveaux de réponse à cette question. Nous pouvons envisager une situation dans laquelle il lui est juste possible de récupérer les données applicatives ce qui impliquerait de devoir reconstruire la quasi totalité de l’infrastructure applicative. Nous pouvons également envisager une situation où il est possible de récupérer une version « packagée » des machines virtuelles ou, à l’opposé, une situation où rien n’est prévu pour être compatible avec d’autres plateformes.

De plus, ce n’est pas parcqu’il est possible de récupérer une machine virtuelle qu’il sera possible de l’exécuter sur une autre plateforme sans devoir se plonger dans les méandres du système d’exploitation pour peu que celà soit même possible.

Au final, l’interopérabilité est un enjeu majeur de toute plateforme informatique et suscite de nombreux débats habituellement. Les problématiques d’interopérabilité dans le cloud computing ne semblent pas encore avoir passioné grand monde ce qui est dommage car elle est bien réelle et existante. Le logiciel libre a clairement un rôle à jouer dans le cadre de cette standardisation avec les acteurs majeurs de l’industrie associée.

J’ai pu emprunter ce livre deux semaines à la Bibliothèque des Sciences et de l’Industrie située à l’intérieur de la Cité des Sciences. Je me suis tourné vers cette bibliothèque car il s’agissait de la plus proche de mon lieu de travail avant la reprise des cours. J’y ai cependant trouvé un large choix de livre récents traitant de nombreux sujets informatiques. J’avais plutôt été habitué aux livres poussiéreux des bibliothèques classiques. Je vous recommande donc ce lieu si vous passez dans le coin !

« Menaces sur le réseau » est un ouvrage traitant de la sécurité informatique au sens très large. Il a été écrit par un chercheur en sécurité informatique polonais qui explique les différents concepts avec une pédagogie exceptionnelle. Ce livre reprend rapidement les bases théoriques nécessaires à la compréhension des éléments techniques et vous explique différentes techniques d’attaques. Il est donc à lire si vous avez certaines bases en systèmes d’exploitation et en réseaux IP.

Ce livre permet de comprendre plus concrètement le monde de la sécurité informatique. Un exemple est l’explication du fingerprinting de systèmes d’exploitation dont l’auteur semble particulièrement friant. Vous comprendez quelles sont les traces laissées par les systèmes d’exploitation dans tous les paquets IP qu’ils émettent. Un autre exemple est le fingerprinting d’OS en se basant uniquement sur les ID des paquets IP, ce qui est pour le moins créatif mais surtout impressionnant. Grâce à une analyse statique graphique, l’auteur arrive à démontrer la possibilité de cette technique, intimement liée au fait que les ID ne sont pas générés tout à fait aléatoirement.

Au final, ce livre est à lire absolument pour tous ceux qui souhaitent s’intéresser à la sécurité dans le domaine des systèmes d’exploitation et des réseaux et qui ont quelques bases dans ces domaines. Pour ceux qui souhaitent s’intéresser aux aspects « management » de la sécurité, passez votre chemin.

Les dangers liés au cloud computing sont la conséquence directe de la dématérialisation des infrastructures physiques.

Tout d’abord, la première problématique est la localisation des données. L’abstraction des infrastructures physiques rend la localisation de données spécifiques significativement plus compliquée. Cette incertitude induit une sécurité pas forcément amoindrie mais certainement considérablement complexifiée.

Cette première problématique est évidente dans le cas des clouds publics ou privés-publics. Le client des infrastructures de cloud computing accorde une confiance totale aux prestataires en lui livrant toutes ses données. Bien que la plupart des argumentaires commerciaux mettent en avant une sécurité des données et, le plus souvent, un chiffrement, il est impossible de vérifier cela. Le client devient spectateur de la sécurisation de ces données.

Nous pouvons faire une exception à cette problématique dans le cas de clouds privés-publics. Ce cloisonnement reste tout à fait relatif. Ce cloisonnement peut être, dans le cas d’infrastructures « bas de gamme » seulement un mécanisme réseau tel que les VLAN. Ce mécanisme peut difficilement être considéré en tant que mécanisme de cloisonnement de données efficace.

Dans le cas d’infrastructures « haut de gamme », nous pouvons imaginer une architecture de type « cloud computing » exclusive à chaque client. Cette alternative se place dans le haut de gamme par le coût que cela engendre. Ce type d’offre permettrait, au passage, une plus grande flexibilité dans l’architecture à tous les niveaux.

Au final, la sécurité des données est une réelle problématique du cloud computing. Nous nous intéresserons plus tard aux problématiques d’interopérabilité des plateformes.