Étiquette : Internet

Content Delivery Networks : Introduction

Antoine 2 commentaires

J’ai récemment effectué un petit projet dans le cadre de mes études dans le cadre de l’unité de valeur « Services Réseaux » traitant des Content Delivery Networks (ou CDN) avec un binôme de choc. Dès que nous avons vu que ce sujet était proposé dans la liste des projets, nous l’avons immédiatement choisi. Le reste des projets était plus ou moins classique mais ce sujet ressortait du lot. Ce sujet fera l’objet d’une série de billets car un unique billet serait bien trop long.

Avant de rentrer dans le vif du sujet, la présentation que nous avons effectué est disponible sur Slideshare. L’affichage des animations est quelque peu fastidieux par le biais de la visionneuse Slideshare mais ca reste assez lisible. Il s’agit d’une présentation Keynote contenant assez peu de détails car la plupart du sujet a été traité à l’oral. Pour le détail, il faudra lire les articles de cette série de billets.

Tout d’abord, nous pouvons traduire le terme « Content Delivery Network » par « Réseau de distribution de contenu ». L’adaptation de ce terme en Français me semble tout à fait satisfaisante. J’utiliserais ce terme pour la suite des billets et les autres billets à venir. Je ferais une exception pour le titre mais ça c’est pour l’indexation Google.

Les réseaux de distribution de contenu ont été conçus pour répondre à des problématiques très concrètes rencontrées sur Internet. Lors de cette introduction, nous nous attacherons à identifier ces problématiques et à les détailler. Nous distinguerons deux types de problématiques : les nouvelles problématiques et les problématiques historiques.

Nouvelles problématiques

L’utilisation de l’Internet a beaucoup évolué depuis ces dix dernières années et ces évolutions ont amené de nombreuses nouvelles problématiques.

La première grande révolution est l’introduction de la vidéo dans le navigateur web. Ceci peut paraitre tout à fait « normal » aujourd’hui mais l’intégration de contenus vidéos était quelque chose de rare il y a une dizaine d’années. Le lecteur Real Player avait permis de faire les premiers pas vers cette intégration mais son utilisation était exceptionnellement pénible. Ceux qui l’ont utilisé se souviendront probablement du casse tête entre les version gratuites et payantes ainsi que les publicités associées. Cette révolution a permis au plus grand monde d’accéder à des quantités de contenu astronomiques.

La seconde révolution est le haut débit par le biais des technologies de transmission ADSL et câble. Chaque utilisateur connecté derrière la box de son fournisseur d’accès à Internet obtient ainsi la possibilité de récupérer des données à une vitesse particulièrement élevée. Aujourd’hui, la quasi totalité des accès ADSL/Câble classiques disposent de plusieurs Mégabits de débit.

La troisième révolution a été les réseaux sociaux. Dans l’absolu, les réseaux sociaux ne sont que des sites comme des autres. Leur particularité réside dans le fait que la quantité de contenu qui y est ajouté chaque heure est colossale. De plus, ces contenus sont consultés de manière régulière par de nombreuses personnes à longueur de journée.

Pour résumer, le contenu distribué sur Internet a largement grossi à cause de la vidéo mais les utilisateurs ont également la possibilité de le récupérer à des vitesses élevés. Au final, il était nécessaire de trouver un solution efficace et le moins cher possible car tous ses contenus sont accessibles gratuitement.

Problématiques historiques

Nous venons de voir un certains nombre de facteurs récents qui ont modifié l’utilisation de l’Internet. Nous allons maintenant nous intéresser aux problématiques qui ne sont elles pas récentes.

La première problématique est le coût de la mise en place des liaisons transocéaniques et transcontinentales. L’investissement initial est élevé et la maintenance sur ces câbles est exceptionnellement compliquée. Les procédés de fabrication des fibres ont été améliorés et leur utilisation a été optimisé mais il reste nécessaire de faire traverser l’océan par un navire câblier ou bien de creuser les trous pour enfouir les fibres. Cette problématique induit le fait que plus le trafic réseau parcourt de la distance, plus les couts sont élevés.

La seconde problématique est la vitesse de la lumière. Transcrit en des termes plus informatiques, la seconde problématique est la latence. Cette dernière est bornée inéluctablement par la vitesse de propagation d’un signal dans une fibre optique qui dépend de la vitesse de la lumière. Les utilisateurs veulent non seulement du contenu mais le veulent rapidement. La latence peut devenir un problème dans le cas de liaisons transocéaniques. Des chiffres donnés par Akamai évoquent une latence de 1,6 ms pour du contenu situé à 160 Km et une latence de 96 ms pour du contenu situé sur un autre continent.

Au final, ces deux jeux de problématiques s’additionnent et viennent compliquer la vision traditionnelle de la distribution de contenu sur Internet. Les réseaux de distribution de contenu ont été créé dans l’objectif de résoudre au mieux à toutes ces problématiques.

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

Dangers du cloud computing : l’interopérabilité

Antoine 3 commentaires

Ce billet fait suite au premier sur les dangers du cloud computing qui s’était plus orienté vers la sécurité des données placées dans le cloud. La seconde problématique que je souhaitais aborder est la celle de l’interopérabilité entre les clouds.

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.

Le retour d’expérience d’OVH en matière d’infrastructure

Antoine 6 commentaires

Tout le monde connait sans aucun doute OVH. Nombre d’entre vous ont probablement déjà eu à faire à eux à travers leurs différentes offres que ce soit de l’hébergement mutualisé ou bien un serveur dédié. J’avoues ne pas toujours avoir été un fan de leurs offres.

Qu’on apprécie OVH ou non, le nombre de serveurs qu’ils hébergent est réellement impressionant. Selon leurs dires, ils hébergeraient pas moins de 70.000 serveurs aujourd’hui et visent 100.000 d’ici à la fin de l’année. Selon Wikipedia, il s’agirait même du 5ème hébergeur mondial en terme de quantité de serveurs.

Leur succès est lié à leurs prix qui défient toute concurrence sur le marché des serveurs dédiés. Je ne connaissais absolument pas l’histoire d’OVH et ce qui faisait leur succès. La présentation suivante est une présentation faite par deux responsables d’OVH qui retrace l’histoire de leur société. Elle est particulièrement intéressante car elle détaille toutes les « astuces » qu’ils ont utilisé afin de pouvoir grandir au fur et à mesure. Vous y apprendrez par exemple que la quasi totalité des serveurs OVH sont refroidis par un système à eau.


FRnOG 15 – Comment héberger 70000 serveurs ? (part 1)


FRnOG 15 – Comment héberger 70000 serveurs ? (part 2)

Cette présentation est un bel exposé d’audacité et d’ingéniosité comme il en faudrait, surement, plus souvent. Il y a en tout une bonne heure de vidéo. Ceci est extrait d’une conférence FRnOG qui regroupe tous les grands opérateurs Français.

Livre sur la sécurité informatique : Menaces sur le réseau

Antoine 2 commentaires

Cela faisait quelques temps que je ne vous avais pas recommandé de livre. La dernière fois remonte tout de même à Octobre avec le livre sur Xen. Cette fois-ci, je ne vous recommanderais pas un livre parlant de Xen ou même de virtualisation, mais plutôt de sécurité informatique.

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.

Dangers du cloud computing : la sécurité des données

Antoine 6 commentaires

Ce billet fait suite aux précédents billets ayant pour objectif de présenter sur différents niveaux le cloud couputing. Je vais continuer cette série de billets en parlant des dangers liés à cette technologie.

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.