Étiquette : Cloud

Accélérer son site web avec Squid – 2

Antoine 2 commentaires

Dans le billet précédent, nous avons vu l’intérêt d’un reverse-proxy Squid ainsi que son installation et sa configuration basique. Dans ce billet, nous allons réellement utiliser les possibilités de Squid.

Rappels

Historiquement, les proxy HTTP ont été mis en place afin d’accélérer les chargements des pages web. A une certaine époque l’acronyme WWW pouvait avoir pour signification « World Wide Wait ». La solution apportée à ce problème a été de mettre en cache les contenus au plus proche de l’utilisateur par le biais de proxy.

La gestion du cache HTTP doit être géré du coté du fournisseur de contenu, à savoir le serveur web. En théorie, ce dernier a autorité sur les données du site qui pourront être mises en cache ou non. Ces informations sont transmises dans les en-têtes HTTP par le biais de divers champs que nous ne détaillerons pas tous ici. Un champ particulièrement intéressant est la durée de rétention dans le cache.

Par défaut, Apache n’envoie pas d’informations quant à la mise en cache du contenu ce qui signifie donc qu’en théorie les données de notre site ne seront pas mises en cache. Dans notre situation, cela signifie que Squid ne met rien en cache tant que nous n’avons pas configuré Apache pour lui indiquer qu’il est possible de le faire.

Configuration d’Apache

Nous allons donc devoir paramétrer Apache pour utiliser les en-têtes contrôlant la mise en cache de nos pages web. Ainsi, notre serveur Squid pourra prendre une partie de la charge de notre serveur web et ainsi le soulager.

Le module Apache qui nous intéresse plus particulièrement est mod_expires. Son activation est simple et, dans le cas de Debian, il est packagé avec Apache. Il suffit donc de l’activer comme suit.

# a2enmod expires

# /etc/init.d/apache2 restart

Une fois ce module activé, nous allons pouvoir le configurer.

Configuration de mod _expires

Nous allons pouvoir configurer mod_expires par le biais de fichiers .htaccess comme il est possible de le faire pour bon nombre d’autres modules. Ce module nous permet de gérer assez finement la mise en cache des fichiers. La syntaxe est simpliste mais efficace. Si vous souhaitez obtenir une explication exhaustive dans la syntaxe et de ses fonctionnalités, je vous recommande de consulter la documentation.

Pour ce site, j’ai choisi la politique suivante de mise en cache.

ExpiresActive On
ExpiresByType image/gif « access plus 1 week »
ExpiresByType image/jpeg « access plus 1 week »
ExpiresByType image/png « access plus 1 week »
ExpiresByType text/css « access plus 1 days »
ExpiresByType application/x-shockwave-flash « access plus 1 hour »

Ensuite, c’est à vous de voir ce que vous voulez que Squid mette en cache ou pas en fonction des fonctionnalités de votre site.

Vérification

Afin de vérifier si tout fonctionne correctement, je vous invite à consulter les log d’accès à votre serveur Squid. Des lignes comportant « TCP_HIT » s’afficheront lorsque Squid servira des données du cache à la place d’Apache. Si vous n’avez que des « TCP_MISS », il doit probablement manquer un élément à votre configuration.

Au final, cette méthode permet d’accélérer significativement son site web et ainsi d’améliorer son référencement sur Google. Dans mon cas, le temps de chargement de ce site a été divisé par un facteur 2 à 3 ce qui est tout de même très intéressant. Des lecteurs m’ont fait remarquer qu’il existait une alternative plus moderne à Squid, Varnish qui permettrait de définir des politiques de mise en cache plus fine. Je vous laisse donc y jeter un coup d’œil !

Accélérer son site web avec Squid – 1

Antoine 17 commentaires

La rapidité de l’Internet est une préoccupation omniprésente car elle améliore significativement l’expérience utilisateur. De plus, récemment Google a annoncé que la rapidité d’affichage des sites serait prise en compte dans le calcul de l’affichage des pages de résultat de recherche. Cette prise en compte avait de quoi en motiver plus d’un à accélérer l’affichage de son site, dont moi.

Contexte

L’affichage de ce blog était relativement lent. Il pouvait mettre plus de 5 secondes pour s’afficher complètement ce qui n’est pas un temps d’affichage très bon. J’ai donc entrepris de trouver une solution à ce problème.

Ce site est hébergé sur une machine virtuelle Xen dont le système d’exploitation est OpenSolaris 2009.06. Elle est globalement assez lente car relativement peu de mémoire lui est alloué. De plus, la cohabitation d’Apache et de MySQL sur le même système ne favorise clairement pas les choses. Certains médisants diront que WordPress et/ou PHP sont des facteurs de lenteur. Ils auront raison mais je n’ai aucune intention d’utiliser autre chose que WordPress car c’est un réel plaisir à l’utiliser.

Un peu de théorie

Un proxy ou en Français « serveur mandataire » est un serveur qui se place entre le client et le serveur. Le client va interroger le proxy qui va à son tour interroger le serveur. Le serveur répondra au proxy qui, à son tour, répondra au client. Ceci est le fonctionnement le plus classique mais on peut placer un proxy dans nombreuses configurations et donner au proxy une intelligence supplémentaire.

Dans le cas de proxys HTTP(S) classiques, on y ajoute des mécanismes de cache afin d’économiser de la bande passante. On peut également y ajouter des fonctions de filtrage d’URL afin d’éviter la consultation de certains sites.

L’exemple d’application du proxy qui nous intéresse ici est le reverse proxy. Le client n’aura aucune connaissance de la présence d’un proxy et pensera qu’il s’agit d’un serveur HTTP comme un autre. Le proxy interrogera ensuite le serveur web et la requête sera renvoyée au client. Dans cette situation, la fonctionnalité de cache du proxy est très intéressante car elle permet d’éviter le traitement de certaines requêtes au serveur HTTP. On pourrait également utiliser le proxy couplé à plusieurs serveurs HTTP afin d’effectuer du load balancing et de la redondance.

Une autre VM

La première étape a été de trouver une machine supplémentaire afin de ne pas faire cohabiter la pile LAMP et Squid sur le même serveur. Dans l’absolu, ce n’est pas impossible mais lorsqu’on a un serveur déjà surchargé, ce n’est peut être pas la meilleure idée.

Étant donné qu’OVH vient de lancer son offre miniCloud, ce projet était une parfaite excuse pour la tester. Le prix de cette offre est vraiment très bas. Pour une VM de 256Mo de RAM, cela revient à 8,5€/mois. J’ai donc crédité 10€ sur mon compte. L’interface de gestion n’est pas la plus esthétique ni la plus rapide mais elle fait l’affaire.

En une petite dizaine de minutes, j’avais donc à ma disposition une machine virtuelle Debian Lenny 64-bits. Le réel inconvénient de l’offre d’OVH est que l’IP de la machine virtuelle change à chaque fois que vous l’arrêtez par le biais de l’interface de gestion.

L’installation de la pile LAMP est très simple et je ne la détaillerai donc pas ici. Il existe des masses incroyables de documentation à ce sujet.

Squid

L’installation de Squid est très simple. Je l’ai installé sur OpenSolaris à partir des dépôts Blastwave via pkgutil. Dans le cas de Debian, un apt-get s’occupera de tout ca pour vous.

Une fois installé, nous pouvons passer à sa configuration. La configuration du reverse proxy est la suivante :

http_port 80 accel defaultsite=www.antoinebenkemoun.fr
visible_hostname vm.antoine.fr
cache_peer 178.32.yy.xx parent 80 0 no-query originserver name=myAccel
acl all src 0.0.0.0/0.0.0.0
cache_peer_access myAccel allow all
acl our_sites dstdomain antoinebenkemoun.fr www.antoinebenkemoun.fr antoinebenkemoun.com www.antoinebenkemoun.com
http_access allow our_sites

Tout d’abord, on indique à Squid d’écouter les requêtes sur le port 80 et que le site que l’on va proxy-er est « www.antoinebenkemoun.fr ». Ensuite, on lui indique l’IP du serveur web où est réellement hébergé le site. Il est ensuite nécessaire de définir un certain nombre d’ACL qui sont ici assez génériques et tout à fait simples. Dans l’exemple, nous avons autorisé le reverse proxy pour 4 sites et nous avons autorisé toutes les IP à visionner le site.

Il est également possible d’utiliser d’autres options afin de mieux régler votre reverse proxy. L’ajout d’un « access log » va vous permettre de voir les pages qui sont consultés mais surtout si le contenu est envoyé par Squid ou par votre serveur LAMP. Il est également possible de régler la quantité de mémoire vive utilisé pour le cache de pages web. L’espace mémoire utilisé pour le cache sera donc alloué en plus de l’espace mémoire du programme principal.

cache_mem 20 MB
cache_access_log /opt/csw/var/logs/access.log

Le chemin pour l’access log est adapté à mon OpenSolaris mais à vous de l’adapter à votre distribution. Si vous êtes sur Linux, vous voudrez surement placer les logs quelque part dans /var/log/.

Au final, nous avons installé notre serveur Squid et l’avons configuré en mode reverse-proxy. Dans le billant suivant, nous verrons les modifications qu’il faut apporter à notre serveur Apache afin d’utiliser réellement la fonctionnalité de cache du reverse proxy.

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.

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.

Définition du « Cloud Computing »

Antoine 15 commentaires

Je profite de cette journée de vacances pour prendre le temps de blogger sur un sujet d’actualité mais surtout particulièrement à la mode. Certains préfèreront le terme « trendy » mais je trouve que ca fait peut être un peu beaucoup pour une technique informatique. J’aurais l’occasion de revenir sur le sujet du cloud computing plus d’une fois. Je ne ferais cependant pas une série d’articles liés mais différents aspects à visée plus ou moins objective.

L’objectif de cet article est de présenter les différentes définitions du cloud computing que l’on peut trouver sur le web et de les comparer. Afin d’avoir un premier élément de définition, nous pouvons nous rendre sur Wikipedia qui définit le cloud computing comme suit.

L’informatique dans les nuages (en anglais, cloud computing) est un concept majeur faisant référence à l’utilisation de la mémoire et des capacités de calcul des ordinateurs et des serveurs répartis dans le monde entier et liés par un réseau, tel Internet (principe de la grille informatique).

Tout d’abord, Wikipedia France traduit cloud computing par le terme informatique dans les nuages. Cette traduction est une traduction très littérale qui, selon moi, s’adapte relativement mal en Français. A défaut d’une meilleure traduction, je continuerais à utiliser le terme anglais beaucoup plus répandu.

Ensuite, intéressons-nous à la définition proposée par Wikipedia. Cette définition ressemble beaucoup plus à un slogan marketing qu’à une véritable définition d’un concept informatique. Elle commence par préciser qu’il s’agit d’un concept majeur. Cette affirmation est soutenue par un rapport Gartner cité en bas de page. Sans questionner le point de vue de ces analystes, cette définition s’attache en premier lieu à définir la taille de ce concept avant même d’avoir précisé de quoi il s’agissait.

De plus, l’utilisation de capacités de calcul et de mémoire d’ordinateurs via Internet est loin d’être quelque chose de récent ni de propre au cloud computing. Une application web est une utilisation de capacité de calcul via Internet et ce n’est pas pour autant qu’il s’agit d’une nouveauté ou bien même de cloud computing. La fin de la définition fait allusion au grid computing qui est une technique bien différente du cloud computing du fait qu’elle soit conçue pour effectuer du calcul distribué.

Nous pouvon ensuite nous tourner vers la définition proposée par Wikipedia en Anglais en espérant obtenir un résultat plus probant.

In concept, it is a paradigm shift whereby details are abstracted from the users who no longer need knowledge of, expertise in, or control over the technology infrastructure « in the cloud » that supports them. Cloud computing describes a new supplement, consumption and delivery model for IT services based on Internet, and it typically involves the provision of dynamically scalable and often virtualized resources as a service over the Internet.

Pour les francophones, voici la traduction « best effort » que je propose de cette définition.

Conceptuellement, il s’agit d’un changement fondamental se traduisant par une abstraction de l’infrastructure technologique désormais transposée « dans les nuages ». Ce changement fondamental implique que les utilisateurs n’aient plus besoin d’une connaissance ou d’une maitrise de l’infrastructure technologique. Le cloud computing est un technique basée sur un nouveau modèle de consommation et d’utilisation des TIC basées sur Internet. Typiquement, cela inclut la mise à disposition de ressources extensible à la volée et, souvent, virtualisées par le biais d’Internet.

Cette définition semble convenir bien mieux à l’idée du cloud computing qui est traitée régulièrement sur Internet. Je trouve que cela décrit beaucoup mieux le concept et la pratique du cloud computing. Nous remarquons également que la page Wikipedia en Anglais sur le cloud computing précise bien que ce n’est pas la même chose que le grid computing. Promis, je ne l’avais pas vu avant.

Au final, la définition du cloud computing est relativement compliquée à poser étant donné la jeunesse de la technique. De plus, le succès de cette technique incite tous les vendeurs de solutions informatiques à se mettre à l’heure du cloud computing moyennant une définition approximative de ce concept. Dans un prochain article, nous essayerons de trouver une définition plus pratique du cloud computing.