La cuisine de Gandi

De nouvelles images sur l'hébergement IaaS axées supervision

mz — Fri, 14 Sep 2012 17:02:00 +0200

Nous vous avons préparé quelques images de distribution spécialisées dans la supervision.

Vous étiez nombreux à nous faire des demandes en ce sens, ou plus directement que Gandi propose un service de supervision à travers notre interface d'administration.

Cela sort de notre périmètre, nous préférons donc que nos clients puissent gérer leur supervision eux mêmes, à savoir qu'il existe aussi des services payants de supervision sur Internet, ce qui peut être une alternative.

Nous avons laissé les distributions telles qu'elles étaient, malgré l'envie de les compléter par des outils que nous connaissons et qui pourraient être aussi utiles, comme collectd pour les statistiques de performance par exemple :-)

OMD

OMD (Open Monitoring Distribution) est faite par les développeurs des principaux outils de supervision connus à ce jour qui ont le souhait d'intégrer/regrouper les meilleurs outils et leurs modules respectifs au sein d'un unique paquet.

Ce paquet permet l'installation aisée de plusieurs outils tels que Nagios, Icinga, Shinken ... des interfaces multiples telles que Check_MK, Thruk ... ou encore des modules non inclus dans ces outils tels que MK livestatus, mod_gearman, Nagvis ...

Grâce à un programme en ligne de commande, vous pouvez alors définir des 'sites' soit des instances de monitoring ayant leurs particularités propres, choisir l'interface graphique web pour chacun des sites gérés, agréger les sites entre eux, effectuer des maintenances par site sans éteindre tout le monitoring, mettre un site à jour par exemple.

Nous nous sommes basés sur une image Debian 6 squeeze en version 64 bits avec OMD en version 0.54 sorti en Mars 2012. Il est possible de l'installer facilement sur d'autres distributions (Ubuntu, ou basée sur le système de paquets RPM) ou d'utiliser une architecture 32 bits.

Après avoir créé l'image, il vous suffit alors d'utiliser le programme 'omd' tel que décrit dans la documentation avec les attributs 'create', 'start', 'stop' ...

EON

EON pour Eyes Of Network est une solution dont les fonctionnalités ne sont pas tournés uniquement vers la supervision, mais aussi vers la gestion des événements, de la disponibilité, ou encore de la capacité.

Elle permet de fournir des vues complètes du SI à des acteurs dépassant l'administrateur système/réseaux, comme par exemple le DSI, les techniciens, les opérateurs, ... À chaque métier peut correspondre une vue particulière.

Cette distribution embarque le moteur GED pour la gestion des événements, Nagios et Thruk pour la supervision, Nagvis pour la disponibilité, NagiosBP pour la partie applicative, Cacti pour les performances, WeatherMap pour la cartographie, ainsi que Glpi/OCSInventory/Fusion pour la gestion des parcs et inventaires, et un Dokuwiki, le tout consolidé dans une base de données (MySQL ou Berkeley), nous fournissons la version 3 basée sur CentOS.

À noter : l'équipe EON par le biais de la société APX Intégration propose des prestations de services (intégration, télé-service, support téléphonique ou encore TMA).

FAN

FAN pour Fully Automated Nagios est une distribution beaucoup plus légère qu'EON avec une pile d'outils moins important : Nagios, une suite complète de modules pour Nagios (comme souvent sur les distributions orientées supervision), l'interface Centreon produite par la société française Merethis, Dokuwiki ... le tout aussi stocké dans une base de données MySQL.

Nous nous sommes basés sur la dernière version 2.3 de FAN qui profite d'une distribution CentOS comme EON, certains modules sont à installer si vous le souhaitez comme NagiosBP ou MK livestatus, cela est expliqué dans la documentation.

Pour finir, d'autres images sont en cours de préparation (sans spécialisation supervision, des images de distributions connues et demandées), n'hésitez pas à nous faire vos demandes au support email ou sur la wishlist hébergement.

Plus il y a de demandes, plus nous accentuerons la priorité sur les distributions demandées !

La plate-forme PAAS du SimpleHosting

aegiap — Mon, 20 Feb 2012 17:45:00 +0100

Nous sommes heureux de vous faire profiter de notre nouvelle plate-forme PaaS. Cela fait maintenant plus d'un an que nous travaillons dessus en intégrant au fur et à mesure les dernières évolutions logiciels tout en restant homogène avec notre infrastructure et la gestion de notre hébergement IaaS.

Le but de la plateforme est de vous affranchir complètement de la partie système (en profitant de notre expertise) et de vous laisser libre sur la partie applicatif (dans les limites des paramétrages qui se veulent par défaut très ouvert).

Plus de détails

Rentrons en détail sur la première déclinaison : l'hébergement type LAMP. Apache/PHP/MySQL est le trio le plus largement utilisé, mais aussi le plus difficile à maîtriser au niveau sécurité et système.

Simple Hosting répond à cette problématique à votre place grâce à son architecture robuste et la possibilité de monter en gamme avec les différents packs. L'architecture du produit Simple Hosting comporte des load-balancers en amont puis des caches de contenu et enfin votre instance personnelle. L'instance n'est accessible qu'en HTTP via les load-balancers et en SFTP pour déposer les fichiers, il n'est pas prévu de l'atteindre directement.

Vous avez une instance personnelle avec un système Linux et des processus Apache2, PHP5 et MySQL. Les fichiers de cette instance et les ressources vous sont spécifiques. Les ressources de l'instance ne sont donc pas mutualisées entre les clients. Un autre site web gourmand en ressource sur une autre instance ne pénalisera pas la vôtre. Au niveau des load-balancers et des caches de contenu par contre, tous les virtualhosts sont servis par un ensemble de machines. Les données de chaque virtualhost (contenu dans le cache, sessions de visiteurs, ...) sont cependant cloisonnées.

Votre instance n'a qu'un seul utilisateur :

pas de gestion de droits d'utilisateur à l'intérieur de votre instance,
un disque dédié où toutes vos données et les logs d'erreurs des applications sont stockés et consultables.

Vous pouvez aussi l'utiliser pour sauvegarder des données privées uniquement accessibles en SFTP (par le répertoire /private).

Votre instance a un serveur apache dédié:

vous pouvez consulter, via l'interface d'administration, l'état de l'application, les requêtes en cours, les logs d'erreurs, …

Votre instance a un démon PHP dédié :

très peu de fonctions limitées comme dans le cas d'un mutualisé,
changement de la configuration possible via ini_set(). L'interpréteur PHP5 fonctionne en tant que démon fastCGI, et donc beaucoup plus performant et permet le contrôle de ressources. Attention ! Du fait de l'utilisation en fastCGI, la configuration de php_value dans le .htaccess ne marche pas.
il bénéficie d'APC un cache d'opcode PHP qui est de 64Mo pour le pack S et double à chaque augmentation de pack,
les statistiques PHP et APC sont consultables via l'interface d’administration.

Votre instance possède un serveur MySQL dédié qui :

est un démon complet sur lequel vous êtes root,
stocke les données directement sur votre disque,
est configurable directement par l'interface de PHPMyAdmin disponible par votre interface d'administration,
est non accessible depuis l'extérieur de votre instance Simple Hosting,
dont la taille mémoire est adaptée à la configuration de chaque pack pour éviter tout phénomène de swap. Il n'y a aucune différence de fonctionnalité entre les tailles de pack PHP/MySQL.

Détails sur PHP5 et le système

L'instance est basée sur la distribution Debian Linux avec des packages standards pour l'interpréteur PHP5 et ses modules. Pour une liste exacte des versions et des modules, vous pouvez consulter le wiki, ou le résultat d'un PHPinfo(). Une instance Simple Hosting ressemble donc au serveur dédié que vous pouvez souscrire dans notre offre IaaS mais spécifique pour un type de site. La liste des modules choisis et la configuration restent ainsi du ressort de notre équipe technique; il n'est donc pas possible d'installer des modules spécifiques. Cependant, si une forte demande est faite pour un module donné (par la wishlist), nous pourrons décider de fournir le module souhaité lors de la mise à jour suivante de l'image de base de l'instance.

Au niveau des mises à jour, notre équipe technique mettra à jour régulièrement les versions des librairies et interpréteurs pour chaque type d'instance de Simple Hosting; ainsi, la dernière mise à jour de sécurité de PHP5 est disponible dans les instances. Dans le cas des alertes de sécurité régulières sur PHP ou les applications en PHP livrées par Gandi, notre équipe sera réactive et appliquera le correctif dans les plus brefs délais. Nous surveillons ainsi les alertes sur l'interpréteur PHP, sur PHPMyAdmin qui est livré dans l'interface d'administration, sur apache2, sur MySQL et bien sûr, sur le système de base (noyau, libc6, ...). Attention ! Les alertes de sécurité concernant les applications que vous installez sont, par contre, de votre responsabilité.

Les performances

L'architecture de la plateforme est faite pour minimiser au maximum les temps de réponse à tous les niveaux :

Espace mémoire dédié: vos données restent cachées en mémoire ou dans votre MySQL.
Cache PHP: principalement APC qui s’avère être très efficace et nous avons été généreux sur sa taille.
Cache HTTP: Varnish apporte certainement le plus gros gain en temps de réponse : les pages/images pouvant être cachées seront directement servies par le cache.

La montée en charge

C'est la partie la moins maîtrisable. En cas de succès, votre site risque de s'écrouler sous le nombre de requêtes.

Il faut prendre en compte 2 paramètres majeurs.

Le flot de requêtes http : la ferme de Varnish régule ce flot pour éviter de surcharger votre instance. Si vos données peuvent être cachées, cela devrait être efficace. La quantité de données envoyées est soumise à un quota pour éviter les abus.
La complexité de votre site web : attention Varnish ne pourra pas tout cacher. Par exemple, si votre site comporte beaucoup de pages PHP avec des cookies, il faudra prendre un pack de taille supérieure pour tenir la charge.

Chaque taille d'instance Simple Hosting a un certain nombre de processus PHP en mémoire (2 pour la taille S par exemple). Chaque thread peut gérer le calcul d'une page de code dynamique et enverra ensuite la page au visiteur. Par exemple, vous pourrez servir des pages dynamiques à 2 visiteurs en parallèle sur une taille S. Les pages statiques HTML sont servies directement par apache2. La génération de la page dynamique utilisant les ressources CPU et RAM, un temps maximal d’exécution est configuré (voir dans le PHPinfo() ci-dessus). Le thread PHP sera alors terminé, indiquera l'information dans le log d'erreur et un message d'erreur sera retourné au visiteur. Si les pages de votre site contiennent des erreurs, vous pourrez consulter facilement l'information dans le log d'erreur de PHP par votre interface d'administration accessible par http://<login>.dc0.gpaas.net (avec <login> l'identifiant SimpleHosting composé de chiffres).

La mise en cache

Les pages générées et servies par votre instance SimpleHosting sont mises en cache par un groupe de serveurs Varnish afin d'améliorer la réactivité de votre site pour les prochains visiteurs en servant la copie des pages dans le cache. Cela vous permet de tenir une forte affluence. Vous avez la possibilité de passer des ordres aux serveurs de cache depuis votre instance pour supprimer toute cette fonction de mise en cache ou vider le cache temporairement.

Enfin, un groupe de load-balancers, en amont des serveurs de cache, vous donne une garantie supplémentaire d'accès à vos sites sur votre instance Simple Hosting. Ces load-balancers sont actuellement accessibles par un ensemble d'adresses en IPv4 (associées aux noms gpaasX.dc0.gandi.net) . L’accès en IPv6 est retardé suite à une fonctionnalité oubliée par le constructeur du load-balancer : nous attendons avec impatience la nouvelle version du firmware.

Quelques remarques pour finir :

le stockage est sur un système de fichiers compressés. Les 10Go de l'offre peuvent en réalité contenir bien plus.
le pack PHP/MySQL est fait pour servir des pages web et n'est absolument pas prévu pour faire du streaming, ou du téléchargement de gros fichiers. Notre équipe abuse veille et sera efficace.

Serveur miroir et CentOS

aegiap — Fri, 30 Dec 2011 11:31:00 +0100

Information sur l'arbre CentOS et le serveur de miroir.

Miroir local CentOS

Dans le but de reconfigurer le miroir comme CentOS l'utilise en se basant sur des mises à jour automatiques de version, la version par défaut '6' de CentOS dans le repository pointe actuellement sur CentOS 6.1. Début janvier (sûrement le 5 janvier), la version '6' passera en 6.2 et sera ainsi compatible avec les miroirs de CentOS en amont.

Images CentOS 6

Suite à la sortie de la version 6.2 de CentOS 6, les images 32 bits et 64 bits sur les datacenters de Paris et Baltimore ont été mises à jour avec la nouvelle version.

URL du miroir local

L'URL officielle du serveur miroir contenant les arbres de distributions est http://mirrors.gandi.net. La page d'index indique les distributions et systèmes disponible sur ce serveur.

Dans le cas de Debian par exemple, l'URL principale à utiliser dans le fichier /etc/apt/sources.list est :

deb http://mirrors.gandi.net/debian squeeze main experimental non-free

Les anciennes URL du type http://centos.mirror.gandi.net/.../ ou http://debian.mirror.gandi.net/.../ sont maintenant obsolètes et vont bientot etre supprimées. Elles datent de la période de beta pour l'hébergement IAAS.

Le miroir est disponible pour les machines virtuelles de l'hébergement IAAS, il n'est pas joignable depuis les machines en dehors du réseau de Gandi.

Penser architecture web - Aller plus loin avec plusieurs centres de données

Nicolas (Gandi) — Fri, 08 Jul 2011 13:33:00 +0200

Un peu dans l'esprit de l'article Penser architecture web que nous avions publié il y a 2 ans, nous allons aborder dans cet article les problématiques que nous savons récurrentes pour nos clients hébergement ainsi que dans le monde du web en général : que faire quand mon serveur web est surchargé ou mes sites web sont lents ?

1. Vérifier d'abord votre code source, puis les configurations des services

Bien entendu, avant de se lancer dans les optimisations du serveur ou plus loin dans une architecture spécifique, il convient d'identifier les problèmes inhérents aux code source.

Puis il est nécessaire de vérifier si les services (serveur web, de bases de données, ...) sont bien configurés par rapport au serveur d'hébergement (ses ressources, notamment RAM et processeur).

2. Augmenter la puissance du serveur en adaptant les configurations des services

Une fois que vous avez optimisé le code source et que les configurations sont optimales, si le service manque toujours de réactivité, si le serveur ne parvient pas à honorer les requêtes de vos visiteurs (syndromes de la page blanche, de pages incomplètes ou encore expiration de la connexion), vous pourrez augmenter la puissance et reconfigurer les services en accord avec ces nouveaux paramètres.

Sur un serveur physique, il sera difficile d'augmenter les ressources sans changer d'offre.
Sur un serveur cloud Gandi, il vous suffit d'ajouter du processeur et de la mémoire vive, à chaud, sans redémarrage (dans une certaine limite)

Si vous avez déjà poussé tous les paramètres à fond, il va falloir aller plus loin...

3. Optimiser les services

Il y a plusieurs services qui peuvent être optimisés, prenons l'exemple d'un blog qui connaît un nombre important de connexions qui fonctionne sous PHP/MySQL, soit une grande partie des sites web aujourd'hui.

Serveur web (Apache, Nginx, Cherokee, ...)

Pour chacun d'entre eux, les gestionnaires de connexions diffèrent, il est préférable de vérifier les bonnes pratiques pour les configurer par rapport à la puissance du serveur, la consommation de ressources maximum par visite, ... Leurs documentations restent le bon point de départ pour les appréhender au mieux.

Module/interpréteur PHP

Apache est connu pour faire fonctionner l'interpréteur PHP à la volée, soit le démarrer lorsqu'il y a du code PHP à exécuter. Démarrer l'interpréteur peut etre long à s'instancier, cela peut paraître infime, cependant, c'est une source majeure de ralentissements. Pour éviter cela, on peux sortir PHP du serveur web en passant du mode module (mod_php) en FastCGI. L'interpréteur démarre donc au meme moment que le serveur web, reste en arriere plan et est disponible immédiatement. Il est donc recommandé de passer PHP en mode FastCGI. Notez que Cherokee ou Nginx sont paramétrés comme cela nativement.

Serveur de bases de données MySQL

Il existe sur MySQL plusieurs optimisations comme sur cet article (qui date un peu).
La documentation à jour est disponible sur cette page.

Comme vous le verrez dans cet article provenant de MySQL, ils demandent bien de trouver les goulots d'étranglement inhérents au code source, au serveur, aux liaisons entre les services, ... avant de se lancer dans les optimisations qui peuvent être :

matérielles : comme adapter la version du système selon la taille des bases et de la mémoire vive (32/64bits), les disques (lire plusieurs blocs à la fois) ou le système d'exploitation (nombre de fichiers ouverts avec ulimit)
la réplication pour avoir plus de serveurs permettant d'augmenter le nombre de requêtes possibles en simultané
augmenter le nombre de threads et/ou de connexions sur chaque serveur
optimiser les requêtes SQL et utiliser un moteur convenant à l'utilisation faite
utiliser les caches (query, key myisam ou buffer innodb)
...

Systèmes de caches

Vous pouvez installer des systèmes de cache à plusieurs niveaux : nous l'avons vu pour MySQL rapidement, sachez qu'il existe des caches à placer devant le serveur web (cache HTTP tel que Varnish) qui garde une copie de la page web complète en mémoire. D'autres systèmes de cache pour les interpréteurs comme Xcache pour PHP. Ils consomment un peu de ressources mais évitent une charge supplémentaire sur les services principaux en limitant les appels que pour le recalcul de la page web et le remplaçement dans le cache.

Pour le cache Web/HTTP, il permet aussi d'éviter que le serveur web ne soit directement accessible depuis l'extérieur, offrant un protection légère mais non négligeable.

4. Opter pour une architecture répartie

Si, au terme de ces optimisations, le serveur ne supporte toujours pas la charge, il faudra donc penser architecture web

Cela implique de multiplier les serveurs où sont installés les services pour répartir la charge sur chacun d'eux, il est possible de dupliquer tout ou partie de l'infrastructure : web, caches, bases de données, ... La répartition peut se faire au niveau du cache HTTP (Varnish), des DNS (Round Robin) ou d'un proxy (tel qu'Haproxy) selon les souhaits et la taille de la plateforme.

Avec des systèmes de vérification (de type "healthcheck" sur Haproxy, Heartbeat ou encore Varnish par exemple), nous pouvons éviter d'envoyer un visiteur sur un serveur dont les services ne fonctionnent pas.

La géolocalisation des visiteurs ou l'exploitation de plusieurs centres de données pour le même service
Avec l'architecture répartie, nous avons trouvé une solution qui permet d'honorer la charge en terme de visites simultanées en masse. Cependant, certains visiteurs éloignés du pays de localisation des serveurs peuvent avoir une latence importante (depuis la Nouvelle Zélande ou le Chili vers la France par exemple). Une solution est de mettre à disposition des serveurs plus proches d'eux, en géolocalisant par pays par exemple, le serveur DNS Bind avec le système de "vues" (views) allié à la base MaxMind qui contient les plages d'adresses IP par pays effectue bien cette opération.

Un exemple concret avec un blog Wordpress sur 2 centres de données

Vous pourrez voir un exemple de cette solution réalisé par Emerick du support hébergement sur le site suivant. Le site est ouvert aux commentaires, sera agrémenté avec plus de solutions et d'explications dans les prochaines semaines. Vous aurez une vue plus détaillée de l'utilisation de chaque service, voir des configurations (basiques) utilisées pour mettre en place cette petite plate-forme.

A titre d'information, nous avons pris des serveurs d'une part chacun :

un DNS,
deux serveurs Web,
deux serveurs de bases de données.

Nous n'avons pas mis en place toutes les optimisations décrites, les serveurs web sont différents en France et aux USA, les caches Varnish sont situés sur les serveurs web directement.

Quand Null0 et BGP peuvent causer problème

Leland Vandervort — Mon, 20 Jun 2011 15:00:00 +0200

Si vous lisez des manuels ou des livres de réseau traitant de BGP et de la stabilité des routes, la plupart du temps vous trouverez mention ou même une suggestion de lier votre sommaire de préfixe (aggregated prefix) à null0 pour assurer la présence permanente de ces préfixes dans la table de routage. De ce fait, augmenter la stabilité de vos annonces BGP.

Cette méthode est intéressante jusqu'à un certain point mais il y a des situations ou cette configuration peut provoquer une interruption de service dans le cas d'une panne. Ce bref article a pour sujet le routage sur Internet par BGP et certaines "pratiques répandues".

Prenons comme exemple une paire de système autonome (AS : autonomous systems). Sur la gauche, AS1 et AS2 sur la droite; ces deux réseaux ont une connectivité vers Internet et en même temps une relation de peering directe entre-eux. Dans les circonstances normales, le trafic réseau entre les clients d'AS1 et les serveurs dans l'AS2 vont suivre le chemin le plus court (AS-Path) qui, dans ce cas, passera par la session de peering.

Dans cet exemple, les routeurs ont des routes statiques sur null0 pour 'fixer' les préfixes qu'ils annoncent en BGP par leurs ASNs respectifs. La seule différence significative dans cette exemple entre les deux réseaux vient de la connexion mono-lien entre R2 dans l'ASN1 et le reste du réseau de l'AS1. Après tout, cela est juste un routeur de peering et il est moins critique que les routeurs de coeur de réseau ou de transit Internet, non ? Prenons le temps de regarder la situation.

Imaginons que la connectivité entre R2 et le reste du réseau derrière l'AS1 soit coupée. Les routes vers les réseaux dans l'AS2 ne seront alors vu sur Internet que par les connections de transit, comme indiqué dans les annonces BGP. Avec une configuration correcte, le trafic entre les deux réseaux devrait maintenant passé par Internet par leurs connections de transit respectifs comme indiqué par le schéma suivant :

Dans cette exemple cependant, les connections de R2 vers la session de peering entre les deux ASNs sont encore actives et de ce fait, la session BGP est encore active entre les deux. Comme R2 a "fixé" statiquement les préfixes réseaux par une route vers null0, ces préfixes sont toujours annoncés à R3 dans l'AS2.

Ainsi, le trafic des paquets de retour suivant le chemin le plus court (AS-Path) seront envoyés par R3 vers R2. Malheureusement, du fait de la coupure de connectivité entre R2 et le reste de son réseau, la destination du client est injoignable. Cela provoque donc un "trou noir" partiel causé par la coupure de connexion et amplifié par, ce qui semble semble être, un problème d'administration ou une mauvaise compréhension de la topologie du réseau au moment de la configuration.

Comment peut-on corriger ce problème ?

Il y a trois façons de diminuer l'impact de ce problème. La première méthode demande d'ajouter une connexion redondante séparée depuis R2 au reste du réseau d' AS 1 (de la même façon qu'avec R3 et AS 2 dans les schéma au dessus. Cela réduit le risque que R2 soit isolé complètement et du coup que l'on se trouve avec black hole partiel. En fonction de la distance cela peut ajouter des frais.

Une autre alternative pourrait être de mettre les préfixes seulement sur le core (qui normalement devrait déjà avoir une connexion redondante), et annoncer ceux là avec un protocole de routage interne comme OSPF ou IS-IS au reste des équipements extérieurs.

Si R2 perds sa connectivité au reste du réseau de AS1, il ne reçoit plus les annonces interne pour l'ensemble des préfixes. Du fait que ces préfixes ne sont plus dans la table de routage de R2, ils ne seront plus annoncés a tout les peers BGP. De ce fait le trafic retour de AS2 à AS1 passera par le dernier chemin restant dans l'internet en utilisant les connexions de transit.

La troisième alternative implique une configuration plus compliqué et demande un protocole interne de routage dynamique au sein de l'AS. Avec ce scénario les annonces BGP seront fonction de l'existence (ou de la non existence selon les préférences) d'un autre préfixe dans les tables de routage. Cette autre préfixe sera reçu par le protocol interne de routage. Cela est parfois appelé comme le "BGP Conditional Route Injection". Sur les équipements Cisco, cela implique d'utiliser "advertise-maps" dans la configuration BGP et la documentation à ce sujet est disponible sur le site de Cisco.

En complément de ces méthodes, une quatrième possibilité pourrait être de lier la route statique vers null0 à un objet de suivi associé avec un agent de surveillance de la disponibilité (SLA) IP. Par exemple, le routeur peut être configuré pour vérifier régulièrement une adresse IP située ailleurs mais dans le réseau en utilisant PING ou un autre protocole. En liant cette agent de surveillance et l'objet de suivi avec la route statique vers null0, cette route ne va rester dans la table de routage que si l'agent de surveillance à un code de retour valide. (Le seuil peut-être configuré par la même occasion pour éviter des faux négatifs issus de micro-coupure ...) Si l'agent de surveillance échoue, la route est alors retirée de la table de routage et ainsi le préfixe n'est plus annoncé dans les annonces BGP.

Le stockage fait sa migration

William — Wed, 06 Apr 2011 15:27:00 +0200

Depuis quelques mois, vous avez peut-être pu utiliser des serveurs aux États-Unis. Le changement de l’infrastructure de stockage était un des points forts dans l'infrastructure pour l'hébergement.
Avant ça, il a fallu adapter notre infrastructure afin qu'elle puisse comprendre "n" datacenters. La mise en place de la nouvelle plateforme de stockage n'a pas été si compliquée puisqu'elle était indépendante de celle existante en France. Le datacenter était nouveau, c'était donc assez simple à mettre en place : tous les nouveaux serveurs aux États-Unis ont bénéficié de cette nouvelle technologie.

Côté France, la migration était inévitable afin d'avoir une infrastructure homogène bénéficiant de nouvelles fonctionnalités. Le problème est différent et un peu plus compliqué : faire cohabiter deux systèmes de stockage différents. En effet, nous avons été confrontés à quelques problèmes pour que les machines hébergeant les serveurs puissent faire cohabiter les deux systèmes en même temps. La mise en production aux États-Unis date déjà de plus de trois mois, une grosse partie de notre temps a donc été consacrée à cette migration. Celle-ci suit son cours, elle prend du temps (beaucoup) et sera disponible pour tout le monde dans les prochaines semaines ; nous serons alors capable de fournir du stockage sur deux technologies différentes.
Quand cela sera effectif, toutes les nouvelles créations de disques se feront sur la nouvelle plateforme : on entrera alors dans une nouvelle phase de migration, c'est à dire celle qui vous concerne directement, migrer vos disques.

Il y aura plusieurs façons de migrer :

Créer un nouveau disque :

la simple création d'un disque se fera sur la nouvelle plateforme

Attachez ce disque à votre serveur actuel et copiez les données qui vous intéressent ; une très bonne occasion pour faire le ménage dans ce que vous n'utilisez pas. Les commandes comme cp/rsync seront tout à fait appropriées.
Créer un disque à partir d'un autre :

Cette fonctionnalité est disponible depuis plusieurs mois dans l'API :
disk.create_from(apikey, disk_spec, src_disk_id)
voir http://doc.rpc.gandi.net/hosting/reference.html#disk.create_from

La prochaine mise en production fera apparaître sur l'interface de gestion des disques, la possibilité de créer un disque à partir d'un autre afin de vous faciliter la tâche si vous n’êtes pas un utilisateur de l'API.
Cela nécessitera que le serveur auquel est attaché le disque soit stoppé, ou alors que le disque source soit détaché.

Il faut par ailleurs noter que la durée de la copie dépendra directement de la taille du disque ; il faudra donc s'armer d'un peu de patience si vous utilisez cette méthode pour copier un disque d'une taille importante.

Si le nouveau disque est un disque système, il suffira alors de le passer en disque de boot via l'interface ("Disque de boot" dans les détails de votre serveur), ou via l'API :
vm.disk_attach(apikey, vm_id, disk_id, {'position': 0})
voir http://doc.rpc.gandi.net/hosting/reference.html#vm.disk_attach

Cette migration vous permettra, entre autres, de bénéficier de nouvelles fonctionnalités comme les snapshots, "redimensionnements", "copie rapide"... qui arriveront dans les semaines suivantes... Au delà d'une infrastructure qui s'améliore de mois en mois, on espère vous parler très vite de ces fonctionnalités qui pourraient changer la façon d'utiliser vos serveurs.

Opération Libellule - Un tout nouveau réseau Gandi

Leland Vandervort — Mon, 24 Jan 2011 14:07:00 +0100

Comme vous avez probablement dû vous en apercevoir, sur les 18 derniers mois, nous avons effectué plusieurs maintenances sur le réseau Gandi. Certaines ont été visibles avec des interruptions de service, d'autres ont été effectuées sans que cela impacte le service. Beaucoup d'entre vous nous ont demandé plus de détails sur ces travaux en cours, j'ai donc décidé de faire ce petit billet pour vous en dire un peu plus concernant l'évolution du réseau sur les prochains mois.

Tout d'abord pourquoi ce nom "Opération Libellule" ? (Dragonfly en anglais) Hmm...disons que je vais vous laisser y réfléchir un peu. D'ailleurs, les 5 premiers qui trouveront et m'enverront l'explication par email avant le 14 février sur libellule AT gandi DOT net gagnent un t-shirt Gandi. (précisez votre taille pour le t-shirt). Quelques indices sont disséminés dans ma présentation ci-dessous.

Un peu d'histoire

Le réseau actuel de Gandi a grossi de manière organique sur les 10 dernières années sur une base relativement simple et "flat". À chaque fois que nous avons ajouté un nouveau service, le réseau a été étendu pour soutenir l'innovation des produits. Une des plus notables a été l'expansion de notre réseau de l'autre côté de l'atlantique sur notre centre de données de Baltimore.

Du fait de cette base originelle assez simple justement, et du désir d'avoir un réseau de niveau 2 adjacent entre plusieurs centres de données, une des façons les plus simples d'avoir une proximité entre nos salles était d'utiliser un système de "span" (ou d’agrégation (trunk)) pour diviser les différents réseaux locaux (LAN) sur les différents sites. Bien que ce système soit assez efficace pour un réseau de taille raisonnable, il est de plus en plus difficile à maintenir et de moins en moins efficace avec un réseau grandissant. C'est peut-être sur ce point que nous nous sommes égarés les années précédentes.

En 2008, nous avons réalisé que même si de nombreux équipements (switchs, routeurs) du réseau avaient des "noms" spécifiques comme s’ils appartenaient à un modèle de réseau hiérarchique, en pratique, cela n'était pas le cas. Nous nous sommes retrouvés avec une infrastructure avec six switchs/routeurs de cœur de réseau et de nombreux équipements de distribution distribués sur quatre sites différents -- tous dans le même segment de réseau spann-é/agrégé à travers le cœur à tous les niveaux du réseau. Le résultat était un cauchemar de gestion et de diagnostic des problèmes en relation avec les calculs de spanning tree et autres comportements de routage étrange.

L'origine de l'opération Libellule

En plus de la simple architecture à revoir, les équipements, eux-mêmes, commençaient à être dépassés et ne pouvaient plus suivre les évolutions produits nécessaires. Du coup, dès 2009, nous avons commencé à moderniser et restructurer notre réseau en prenant en compte l'évolution de la société sur les 3 à 5 ans à venir, en France et à l'international.

La première étape a été de consolider la connectivité entre nos sites, qui jusqu'alors utilisaient de multiples réseaux locaux virtuels (VLAN) agrégés (trunked) sur des connexions en fibre noire. Nous avons bien entendu gardé la fibre noire, mais migré/multiplexé la connectivité point à point sur plusieurs longueurs d'onde à travers la fibre.

Le challenge était d'effectuer toutes ces modifications sans impacter en même temps tous les services Gandi. Certains de nos services (DNS, Hébergement, ..) requièrent 100% de disponibilité. Tout casser et tout réinstaller sur de nouveaux équipements était tout simplement inconcevable. Du fait de ces contraintes, le travail a pris près de 2 ans pour être finalisé.

Cela étant dit, nous devons continuer de remettre à flot et maintenir les services tout en allant de l'avant à pleine vitesse vers les nouvelles fonctionnalités passionnantes qui seront implémentées pendant cette nouvelle année. Pour parler aux marins, il fallait mettre à jour les hors-bords !

En septembre 2009, nous avons mis à jour nos switchs de cœur de réseau en passant d'une plate-forme Cisco sup32 vers une Cisco Sup720 3BXL.

Ensuite, en novembre 2009, nous avons déployé la refonte de notre vielle plateforme de distribution à base de Cisco 6500 et des anciennes cartes Supervisor-2A vers un système tout neuf en switch virtuel (VSS) à base de Cisco Virtual Switching System 1440 dans notre centre de donnée à Saint-Denis. C'est à ce moment aussi que nous avons commencé à déployer la technologie MPLS (MultiProtocol Label Switching) à travers notre réseau afin d'être capable de fournir de l'ingénierie sur le trafic et des systèmes innovants sur la façon d'interconnecter nos salles réseaux

Objectifs à l'international

Avec l'extension du réseau Gandi, non seulement en France, mais aussi à l'international, nous avions comme objectif d'adapter la structure de notre réseau pour obtenir un système à la fois évolutif et capable de prendre en charge notre trafic international (nous vendons dans 192 pays) et l'ajout de centre de données dans d'autres pays.

Tous les architectes réseau vous diront qu'un réseau évolutif est modulaire et hiérarchique. Ceci a été l'un des principes de base du design d'infrastructure réseau pendant des années et reste aujourd'hui vrai. Cisco appelle cela le "modèle de réseau en trois niveaux". Cependant, durant les dernières années, la situation est devenue un peu plus complexe avec la montée de la virtualisation et des architectures orientées services où les services sont devenus, eux-mêmes, un élément du réseau. Cela étant dit, pratiquement tous les larges réseaux évolutifs actuellement en fonctionnement utilisent un modèle d'architecture modulaire et hiérarchique.

Avec l'expansion de Gandi sur le continent nord-américain, nous devons assurer une redondance entre les centres de données. Une simple règle s'applique ici : chaque centre de données est connecté à au moins deux autres centres par divers moyens de connectivités.

Pendant cette année écoulée, nous avons construit notre centre de données à Baltimore, actuellement complètement fonctionnel pour la plate-forme d'hébergement de Gandi. Pendant les prochains mois, un certain nombre de systèmes de Gandi seront aussi disponibles à Baltimore -- principalement le DNS et le site web de Gandi.

À la fin de 2010, notre connectivité internationale passait par plus de capacité de peering à Londres, Amsterdam et Ashburn Virginia/Washington DC -- d'autres seront mis en place pendant les prochaines années..

Et ensuite ?

Nous avons augmenté le nombre d'opérations par nos ingénieurs réseau depuis le début de l'année 2011 et sur la période des prochains mois à venir, un certain nombre d'opérations de maintenance hautement intrusives seront entreprises dans le but de finaliser l'Opération Libellule avant la fin de la première moitié de 2011.

La première étape de cette phase finale a eu lieu le week-end dernier à Saint-Denis pendant lequel nous avons définitivement enlevé les réseaux locaux (LANs) spann-é et agrégés (trunked) entre la distribution/agrégation et le niveau du cœur du réseau à Saint-Denis. En résultat de cette maintenance, les incidents dans les niveaux de distributions ou d'accès du segment de réseau à Saint-Denis n'auront aucun impact sur le routage du cœur du réseau de Gandi dans ce centre de données. Nous avons ensuite à faire la même opération à Telehouse2 (Voltaire, Paris); cela est cependant un peu plus complexe.

Pendant les prochaines semaines, vous allez voir un certain nombre de maintenances planifiées pendant lesquelles nous allons entreprendre le reste des modifications nécessaires pour permettre de mener à bien ce projet planifié sur trois ans :

Fermeture de notre point de présence à Paris Telehouse 1 (Jeuneurs, Paris)
Mettre à jour un certain nombre de services critiques de Gandi afin d'utiliser de nouveaux équipements et logiciels.
Implémenter une solution Anycast et Content Delivery pour un certain nombre de services comme le DNS ou le site web de Gandi dans tous nos centres de données en Europe et aux USA.
Ré-installation et mise à jour complète des services de Gandi à Telehouse 1 (Voltaire, Paris) avec une redondance et interopérabilité inter-site.

A quoi cela va ressembler ?

La nouvelle infrastructure réseau de Gandi sera proche du schéma ci-dessous (schéma quelque peu simplifié). L'élément clé est l'architecture qui est prévue et construite dans une optique de disponibilité, modularité et surtout extensible. Tout cela reste assez élémentaire après tout ... Comme Mickey Mouse a dit un jour : "L'arithmétique, c'est être capable de compter jusqu'à vingt sans enlever ses chaussures." ;)

Nouveaux noyaux disponibles pour votre serveur.

aegiap — Mon, 17 Jan 2011 14:07:00 +0100

La liste des noyaux disponibles sur l’hébergement de Gandi s'allonge. Vous avez maintenant la possibilité d'utiliser un 2.6.36 ou un 2.6.32 avec le patch grsecurity.

L’hébergement Gandi dispose de noyaux compilés et préparés par l'équipe technique de Gandi. Trois nouveaux éléments ont été récemment ajouté à la liste des noyaux disponibles :

2.6.36 en version x86_32 et x86_64

Le noyau Linux est en développement continuel et de nouvelles versions contenant des correctifs et des nouvelles fonctionnalités sont publiées régulièrement. Nous avons donc préparé une version 32 et 64 bits du noyau 2.6.36 avec le patch de D.Kipper qui améliore la gestion de la mémoire en option. De plus, la fonctionnalité de redimensionnement directe d'un disque attaché à une machine virtuelle est maintenant intégré dans le noyau. La fonctionnalité devrait arriver bientôt dans l'interface d’hébergement de Gandi.

2.6.32 en version x86_64 avec le patch grsecurity.

Les noyaux précédents permettaient déjà de mettre en place des solutions de sécurité sur le système de la machine virtuelle (au travers de SELinux par exemple). En choisissant ce noyau, vous pourrez mettre en place une politique de sécurité avancée grâce au patch grsecurity en version 2.1.14-201005151340. Le noyau contient aussi la réplication de disque DRBD en version 8.3.8 qui n'était pas encore intégrée officiellement dans le noyau (maintenant intégrée depuis la version 2.6.33).

Vous pouvez consulter le changelog des noyaux de Gandi et la procédure de mise à jour des modules des noyaux.

Quota, parts et coeurs en option

zllak — Mon, 27 Dec 2010 17:39:00 +0100

La prochaine version (3.0.8) va apporter un changement majeur dans la gestion du quota Hébergement, ainsi que dans l'utilisation de l'API associée. Notez bien que les modifications décrites ci-dessous n'arriveront que lors de la mise en production effective de la 3.0.8, dans les prochains jours.

Le changement a principalement été motivé par l'envie de vous proposer des cœurs en options pour vos serveurs. Mais il s'est avéré que dans l'état actuel des choses, cette option n'était pas possible.

Petite explication...

Existant

Lors de la création d'un serveur, le nombre de cœurs est déterminé en fonction du nombre de parts associées au serveur. Nous donnons un cœur CPU toutes les 4 parts, soit :

1 cœur pour un serveur avec 1 à 4 parts
2 cœurs pour un serveur de 5 à 8 parts

...

6 cœurs pour un serveur de 21 à 24 parts.

Le nombre total de cœurs utilisés dépend donc directement de l'utilisation des parts. Prenons l'exemple d'un client qui aurait 48 parts :

Si il créé 48 serveurs, il aura donc un total de 48 cœurs utilisés.
Si il créé deux serveurs de 24 parts, il aura donc un total de 12 cœurs utilisés (6 par serveur).

Il devient évident qu'il est très difficile de déterminer le nombre de cœurs "disponibles" puisque cela dépend entièrement de l'utilisation qu'il est fait des parts. Et sans cette notion essentielle de "cœur disponible", nous ne pouvions pas vous proposer d'acheter des cœurs supplémentaires.

Changements

Il a donc fallu trouver une solution pour palier ce problème. Nous sommes arrivés à une solution qui permettait de rester cohérent avec l'existant, tout en ouvrant la possibilité de compter des cœurs en option.

La solution qui nous est venue est tout simplement de supprimer les parts. Les parts au sens technique bien-sûr. La part devient ce qu'elle aurait toujours du être : un bundle commercial, et non une notion technique.

Pour rappel, la part apporte aujourd'hui :

8192 Mo d'espace disque,
5 Mbps de bande passante,
256 Mo de mémoire.

Le droit de créer un serveur ne s'appuyait que sur le fait d'avoir une part disponible.

Pour supprimer cette notion technique de part, nous avons donc ajouté dans ce bundle "part" : 1 quota-serveur. Pour créer un serveur, il faudra donc avoir 1 quota-serveur et des ressources disponibles (mémoire, disque, et cœur).

En effet, pour les utilisateurs de l'API, la méthode vm.create prenait un paramètre "shares". Ce paramètre disparait donc. Il laisse sa place au paramètre "cores", qui représente le nombre de cœurs qui seront utilisés par ce serveur.

Maintenant, pour maintenir l'offre actuelle, nous avons dû ruser :)

Le quota-serveur inclut 0.75 de quota de cœur et chaque bundle (le bundle "part") inclut, lui, 0.25 de quota de cœur. Si vous souhaitez créer un serveur avec 2 cœurs, 1 quota-serveur sera utilisé et fournira 0.75 de quota-cœur. Le premier bundle "part" fournira le 0.25 manquant pour compléter le 1er cœur et vous devrez disposer de 1 de quota-cœur (fournit avec les parts ou en option) supplémentaire pour avoir votre second cœur.

Pour les utilisateurs de l'API, par exemple, si l'on veut créer un serveur avec 3 cœurs, on appelle la méthode 'vm.create' avec le paramètre "cores" qui vaut 3 directement. Vous consommerez de votre pool de ressources, 1 quota-serveur et 2.25 de quota-cœur.

Autre note, quand un serveur est créé, les 0.75 quota-cœur fournit par le quota-serveur viendront s'ajouter à votre total de cœur. Il n'est donc pas bizarre de voir ce chiffre monter après chaque création de serveur.

Site web

Pour le site web, les deux nouveaux quotas ont fait leur apparition dans la barre de récapitulatif des ressources. Sur la page de création de serveur, on ne choisit désormais plus le nombre de parts, mais le nombre de cœurs, ainsi que sur la page de mise à jour des serveurs. Là, comme dans l'API, on ne parle que de cœurs entiers, pas de virgule.

Il faut également choisir la bande passante désirée lors de la création de l'interface réseau, car c'était le nombre de parts qui déterminait la bande passante. En attendant de vous fournir de la bande passante en option (cette année), nous la globalisons et vous permettons d'utiliser votre quota comme vous le souhaitez.

API

Les méthodes qui ont été impactées sont 'vm.create', 'vm.update' et 'account.info'. Les paramètres "shares" des méthodes 'vm.create' et 'vm.update' disparaissent, et les paramètres "cores" et "bandwidth" font leur apparition :

cores : nombre de cœurs pour la création/mise à jour du serveur (entier de 1 à 6)
bandwidth : la bande passante pour créer l'interface réseau (selon votre quota)

Le paramètre "shares" reste disponible jusqu'à la fin de la période de beta de l'API. Il disparaitra totalement après cette période.

La méthode 'account.info' affiche désormais les ressources 'granted', 'used' et 'available' pour "cores" et "servers".

Ces changements interviendront dans les prochains jours, lors de la mise en production de l'API 3.0.8

Nouvelle architecture de stockage

man — Tue, 14 Dec 2010 17:56:00 +0100

Notre infrastructure de stockage nouvelle génération est en cours de déploiement.

La gestion des disques, elle aussi, passe à la moulinette de la virtualisation... et nous sommes impatients de vous en faire profiter !

Comme vous allez le voir, les fonctionnalités sont très intéressantes et nous allons les intégrer, au fur et à mesure, sur votre interface de gestion ainsi que sur la nouvelle API.

Améliorations

Outre les disques, bien sûr toujours en RAID pour la redondance, et le cache en écriture résistant à une coupure de courant, les serveurs de stockage sont maintenant en cluster : en cas de panne d'un contrôleur, un contrôleur de secours est prêt à reprendre la gestion des disques.

La capacité de stockage a été améliorée ainsi que les I/Os. Vous pourrez créer ainsi, très prochainement, des disques plus gros.

La création, la copie et l'agrandissement de disques seront plus rapide et plus automatisés.

Snapshot

Ce mécanisme permet de réaliser un cliché instantané de votre disque qu'il soit utilisé ou détaché. Le Snapshot peut être utilisé pour réaliser une sauvegarde cohérente de votre disque. D'ici quelques semaines, une gestion des Snapshots à la demande sera mise à votre disposition. Nous travaillons également sur une gestion périodique des Snapshots. Par exemple, la possibilité de créer un Snapshot tous les jours et de ne garder que les 7 derniers.

Copie de disque

Grâce aux Snapshots, il sera possible, dès la sortie, d'effectuer une copie rapide de votre disque à chaud, même en ayant de l'activité sur celui-ci. Cette fonctionnalité facilitera le déploiement rapide (clone) de serveurs.

Restauration

Vous pourrez, à partir d'un Snapshot, créer un disque, récupérer vos fichiers effacés ou encore effectuer un retour arrière (rollback).

Sauvegarde automatique de disque

Pour les plus exigeants, un système de sauvegarde disque à disque, vers un système de stockage indépendant, est à l'étude. Pour la majorité des usages, le mécanisme des snapshots devrait largement répondre à vos besoins.

Disques et partitionnement

Les disques Gandi sont des disques logiques, c'est à dire que nous fournissons accès à des disques déjà optimisés, sécurisés, et qu'il est facile d'en créer, de les agrandir, ou de les détruire à la volée.

Les partitions, LVM, ou des algorithmes RAID représentent pour votre machine virtuelle au mieux une surcharge inutile, au pire une réorganisation des accès disques pouvant résulter en une dégradation des performances (voir ci-dessous). De plus, vous pouvez vous priver de fonctionnalités très pratiques : un snapshot effectué sur un disque faisant partie d'un RAID n'aurait aucun intérêt, le redimensionnement d'un disque partitionné (notre ancien système pour ceux qui ont pratiqué) est complexe voire dangereux si on ne fait pas attention.

Comme pour les SSD et les nouveaux disques dur, les blocs en interne ne sont plus de 512 octets mais de 4k. Si vous utilisez des partitions, ou LVM, les accès à vos données risquent de ne pas être alignés, et les performances divisées par trois.

Les partitions n'ont de réelle utilité que pour les disques physiques. Cela complique la gestion de vos disques pour rien : regrouper vos données sur un seul disque de data ou créer plusieurs disques est la bonne solution.

Les disques créés par Gandi n'utiliseront plus de partitions. Actuellement seuls les disques système possèdent une partition par défaut (système et swap) : elle va disparaitre. Le disque système sera alors géré comme n'importe quel autre disque, ce qui facilitera la gestion. Pour garder le même niveau de service, nous vous fournirons un disque temporaire pour le swap. Pour rester cohérents avec les configurations actuelles, nous émulerons des partitions virtuelles pour vous présenter le disque système et le swap : le système sera vu comme xvda1, le swap comme xvda2.

Comment créer une image pour ses serveurs ?

aegiap — Tue, 09 Nov 2010 16:27:00 +0100

Les applications pour une image système ne manquent pas : créer son propre système avec ses applications préférées pré-installées, préparer une image d'un serveur de jeux facilement remontable, dupliquer un serveur personnalisé facilement ou tout simplement sauvegarder son système...

Le processus est assez simple et peut être réalisé par tout le monde. Il suffit juste d'être rigoureux dans son déroulement.

Créer un disque de données

Vous devez créer un disque de données à partir de l'interface de création de disque de votre compte hébergement. Dans le cas d'une copie de disque existant, le disque de données doit avoir une taille suffisante.

Attachez simplement votre nouveau disque au serveur cible : le serveur contenant le disque virtuel à copier ou le serveur pour faire l'installation de base.

Créer l'image système

En faisant une copie des données d'un disque virtuel

Attention : il vous faudra suffisamment de place sur le disque destination.

Copiez les données de votre disque source vers le disque de destination avec la commande tar :

tar cC /srv/disk1 . | tar xC /srv/disk2

si /srv/disk1 est le répertoire dans lequel est monté le disque source et /srv/disk2 le répertoire du disque de destination. La copie par tar ne copiant que les données et non les blocs vides, l'opération est rapide.

Attention : si vous voulez copier le disque système du système local, il faudra ajouter des exclusions :

tar --exclude=/proc --exclude=/sys --exclude=/srv/disk2 c / | tar xC /srv/disk2

En installant un système de base

Préambule

Votre nouveau disque attaché à un serveur est prêt à être utilisé. Vous pouvez partitionner votre disque image pour éventuellement intégrer une partition de swap dans l'image, mais nous vous conseillons de ne pas créer de partition et de créer le système de fichiers directement dans le disque.

Cela représente l'avantage d'être plus souple si vous comptez redimensionner le disque par la suite (plus de calcul de table de partition à faire), d'être mieux aligné avec le stockage des blocs sur nos filers physiques et de pouvoir décider ou non d'utiliser une partition de fichier d'échange (swap).

Dans un futur proche, toutes les images d'OS fournies par Gandi n'auront plus de partition et l'hébergement Gandi fournira un espace de swap supplémentaire automatiquement.

Cependant, les serveurs virtuels verront toujours le premier disque comme "xvda1", et le disque de swap comme "xvda2".

Que vous choisissiez de partitionner ou non, l'hébergement Gandi saura démarrer les disques systèmes ayant votre image comme source en détectant le début du disque et en adaptant les options de démarrage du kernel. Gandi fournit un serveur contenant une copie des distributions proposées en images de système. Vous pourrez utiliser ce serveur pour accélérer l'installation : mirrors.gandi.net

Préparation

Dans un premier temps, vérifier que le disque virtuel n'est pas déja monté (dans /proc/mounts par exemple). Le démontez si il l'est. Partitionner eventuellement le disque virtuel puis formatez le tout.

Nous vous recommandons de formatter le disque directement et d'utiliser un système de fichiers ext4. Dans le cas où votre disque serait xvdc : mkfs.ext4 -j -m0 /dev/xvdc puis montez le disque dans un répertoire de votre système : mount -o rw /dev/xvdc /var/tmp.

Installation par debootstrap pour les distributions en package .deb

L'installation d'un système de base peut se faire par debootstrap qui installe dans un répertoire. Une fois l'installation finie et quelques modifications effectuées, le disque contiendra un système GNU/Linux bootable et fonctionnel. Le système contiendra un minimum d'application et il vous faudra adapter le système à vos besoins en installant les applications souhaitées avec apt-get et configurer notamment les locales.

Nous vous recommandons d'installer un système en architecture amd64/x86_64 qui sera plus rapide sur l'hébergement Gandi. Au moment du choix du kernel, il faudra choisir le kernel x86_64 qui convient (2.6.32-3831 par exemple).

Exemple d'installation pour une Ubuntu Maverick 10.10 sur le disque monté précédemment :

debootstrap --arch=amd64 --verbose --components=main,universe,multiverse \
--include=openssh-server,openssh-client maverick /var/tmp \
http://mirrors.gandi.net/ubuntu/

Dans le cas où debootstrap vous indique qu'aucun fichier de config pour maverick est accessible, il suffira de faire un lien dans /usr/share/debootstrap/scripts de lucid vers maverick. L'étape suivante est de modifier le fichier contenant les sources vers les médias des packages. Editez le fichier /etc/apt/sources.list dans le répertoire en ajoutant les médias de la distribution et le média contenant les paquets faits par Gandi.

Exemple :

# cat /var/tmp/etc/apt/sources.list
deb http://mirrors.gandi.net/ubuntu maverick main universe multiverse
deb http://mirrors.gandi.net/ubuntu maverick-security main universe multiverse
deb http://mirrors.gandi.net/ubuntu maverick-updates main universe multiverse
deb http://mirrors.gandi.net/gandi/ubuntu maverick main

Copiez ensuite les fichiers /etc/hosts, /etc/resolv.conf et /etc/fstab du système du serveur vers le répertoire contenant le système nouvellement installé (/var/tmp dans notre exemple). Modifiez les valeurs des fichiers en effaçant le hostname de la machine courante dans /etc/hosts et en adaptant le fichier /etc/fstab à votre disque image.

Une fois la commande debootstrap et la configuration terminées, vous pourrez accéder au système fraichement installé en chroot-ant le répertoire.

Par exemple : chroot /var/tmp

Vous pourrez ainsi rafraichir les médias de package par : apt-get update et installer les applications nécessaires pour votre utilisation. Attention cependant, l'installation de certains packages dans un chroot demande quelques corrections. Il faudra notamment monter /proc et /dev/pts normalement disponible dans votre /etc/fstab : mount -a puis rejouer la configuration des packages par : dpkg --configure -a. Certains paquets cherchent à démarrer automatiquement les démons et serveurs installés.

Afin de finir l'installation de ces paquets, il faudra modifier les fichiers de postinst installé dans /var/lib/dpkg/info/ en commentant les appels à invoke-rc.d ou start comme dans le cas de procps : #start procps dans procps.postinst ou rsyslog : #invoke-rc.d dans rsyslog.postinst.

Pour les distributions Ubuntu récentes, il faudra ajouter une entrée pour /dev dans le fichier /etc/fstab : dev /dev tmpfs rw 0 0 afin de démarrer correctement.

Nous vous recommandons d'installer les packages gandi-hosting-agent et gandi-hosting-vm disponibles dans le média Gandi. Pour ce faire, ajoutez la clef de mainteneur Gandi par :

apt-key adv --keyserver keyserver.ubuntu.com --recv-keys D8EAC2F4DAFE3FA5

puis :

apt-get install gandi-hosting-agent gandi-hosting-vm

Les packages installeront les dépendances nécessaires. Pour un description des fonctionnalités de ces packages, veuillez lire l'article précédent sur la Cuisine de Gandi.

Si le système sur votre serveur virtuel utilise une version 2.6 de python, il faudra installer le package gandi-hosting-agent-py2.6 à la place de gandi-hosting-agent.

Installation de base pour les distributions en package .rpm

L'installation d'une distribution à base de package en .rpm utilise la même méthode que l'installation d'une distribution à base de package .deb mais en utilisant rinse ou une application spécifique de la distribution que vous avez choisie.

Par exemple en utilisant le même répertoire :

rinse --arch=amd64 --directory=/var/tmp --distribution=centos-5

Suivant votre système de gestion des packages, il faudra ensuite ajouter les médias de paquets dans la configuration afin d'installer les applications nécessaires.

Autres moyens d'installation de système de base

D'autres distributions (souvent plus spécifiques) proposent d'autres méthodes d'installation du système de base. Parfois une image est disponible, il suffira alors de la monter en loop puis de copier les fichiers dans l'image

En reprenant l'exemple ci-dessus :

mkdir /srv/a
mount -o loop,ro /mon/répertoire/image /srv/a
cp -raf /srv/a/ /var/tmp/

Une méthode plus radicale

On peut aussi copier tout le disque; s'assurer que le disque virtuel de destination qui vient d'être attaché au serveur ne soit pas monté puis vérifiez dans /proc/mounts que le label du disque n'est pas présent.

Attention : cette méthode marche pour un disque de destination de même taille que le disque source.

Pour créer l'image de votre système et la copier sur votre nouveau disque de données, vous devez utiliser la commande dd. La syntaxe de la commande demande un peu d'attention.

voici un exemple explicité après :

dd if=/dev/xvda of=/dev/xvdc conv=sync

Le paramètre if= correspond au disque source; of= indique le disque de destination dont les données existantes seront complètement effacées. Pour distinguer vos disques, nous vous conseillons d'utiliser préalablement df.

Notez cependant que le chemin à utiliser pour le paramètre if sera toujours /dev/xvda directement, sans quoi votre image ne sera pas bootable. Il est nécessaire de reconfigurer le réseau de votre machine en DHCP avant de procéder à la création de l'image. La copie par dd prend beaucoup de ressources et du temps, puisqu'elle copie octet par octet le disque source sur le disque destination sans distinction entre bloc de donnée et bloc vide. . Le kernel Linux pour l'hébergement Gandi démarre par défaut sur la première partition (root=/dev/xvda1 sur la ligne de commande pour le démarrage). Si vous copiez un disque système existant, la table de partition sera correcte. Sinon, veuillez vous assurer que la première partition du disque contient les fichiers du système et l'attribut bootable. Vous pouvez aussi ajouter une deuxième partition contenant un espace de swap.

Impératif pour le démarrage

Dans le cas d'une copie de disque virtuel existant, le disque source ayant déjà booté, il suffit de vérifier la configuration réseau en DHCP pour que l'image produise des serveurs correctement bootable. Dans le cas d'image créée par installation d'un système de base, certains points sont à modifier/vérifier :

Tous les services ou modules en relation avec les éléments physiques de serveurs sont à désactiver (par exemple, le service lié à l'horloge physique d'un serveur - hwclock).
Certains services au démarrage comme ureadahead, console-setup, ondemand, plymouth doivent être désactivés. Déplacez les fichiers d'appel par init de ces services. Dans une image Ubuntu, les fichiers se trouvent dans /etc/init.
Ajoutez les packages gandi-hosting-agent et gandi-hosting-vm : l'agent permet de finir l'installation de votre serveur. Les scripts contenus dans le package gandi-hosting-vm permettent de gérer automatiquement les ressources dynamiques de votre serveur. Pour un système avec une version 2.6 de python, il faudra installer gandi-hosting-agent-py2.6 à la place.
Supprimez les fichiers relatifs aux clefs ssh générées à l'installation du package de sshd pour éviter d'avoir les mêmes clefs de machines sur tous les serveurs ayant votre image comme source.
Vérifiez que xinetd/inetd soit bien démarré au boot sinon, activez-le. L'agent de Gandi est lancé par xinetd/inetd et permettra la fin de la configuration de votre serveur. Le package gandi-hosting-agent installe le fichier de configuration dans /etc/gandi/agent.yml.
Vérifiez les permissions de la racine de votre répertoire d'installation (/var/tmp dans l'exemple) et les répertoires lib/, root/ et tmp/ dans ce répertoire d'installation. En cas de doute, appliquer les mêmes permissions que les répertoires dans le système de votre serveur courant.

chmod 0755 /var/tmp/lib
chmod 1777 /var/tmp/tmp
chmod 0750 /var/tmp/root
chmod 0755 /var/tmp/

Créez les fichiers de base dans le répertoire /dev de votre installation pour les premières étapes du démarrage.

Par exemple,

[ -e "$chroot"/dev/xvc0 ] || mknod "$chroot"/dev/xvc0 c 204 191
[ -e "$chroot"/dev/console ] || mknod "$chroot"/dev/console c 5 1
[ -e "$chroot"/dev/null ] || mknod "$chroot"/dev/null c 1 3
[ -e "$chroot"/dev/ptmx ] || mknod "$chroot"/dev/ptmx c 5 2
[ -e "$chroot"/dev/zero ] || mknod "$chroot"/dev/zero c 1 5

Ajouter les modules pour le kernel choisi dans le répertoire /lib/modules du

répertoire contenant l'installation. Les modules sont disponibles sur mirrors.gandi.net/kernel/. Voir l'article sur le wiki.

A la fin de la configuration, quittez le chroot si vous êtes à l'intérieur par exit puis démonter les éléments concernant votre image dans /proc/mounts. Tuez les processus et démons qui ont pu être lancés pendant l'installation de package dans le chroot/répertoire contenant l'installation. Par exemple : grep /var/tmp /proc/mounts puis démonter umount /var/tmp/proc et les autres. Finir par umout /var/tmp qui devrait se dérouler sans erreur.

Détacher le disque

Retournez maintenant dans votre interface de gestion de disque, sur votre compte hébergement, puis détachez le disque sur lequel vous avez copié le disque ou préparé l'installation.

Rendre le disque bootable en associant un noyau

Dans l'interface d'administration, vous avez maintenant la possibilité de définir un noyau (kernel) pour un disque, sélectionnez alors le disque de données et associez-lui un noyau adapté à l'image que vous venez de créer. Prenons un disque de type "données" que l'on souhaite transformer en disque système/image :

Utilisez alors le lien pour changer les informations du disque, vous trouverez en bas de page une option pour changer le type de disque :

Vous avez alors accès aux options avancées comme sur un disque système :

En associant un noyau, le disque devient utilisable comme image perso et sera dans la liste d'images comme les images Gandi AI ou Expert lorsque vous créez un serveur sur l'interface d'administration.

Créer un serveur à partir de cette image

Lors de la création d'un serveur par votre interface sur le site, vous trouverez votre nouvelle image perso dans la liste des images disponibles. La création du serveur utilisera donc cette image comme source pour le disque système. Le serveur démarrera normalement sur un disque copie de votre image. Vous aurez donc la possibilité de créer plusieurs serveurs "identiques" à partir de cette image perso.

Dépanner le serveur pendant le démarrage

L'hébergement Gandi vous donne la possibilité d'accéder au démarrage de votre serveur en passant par la console d'urgence qui permet par une simple connexion ssh d'avoir la sortie de la console par défaut de votre serveur.

Si vous configurez un getty sur la console par défaut (tty1, xvc0, hvc0 suivant la version de votre kernel), vous obtiendrez un shell de secours en cas d'erreur de boot ou un prompt en cas de boot correct.

Cette console d'urgence vous permet de voir les messages de démarrage et notamment les erreurs et ainsi de debugguer votre image.

Corriger l'image

Dans un second temps, si vous vous apercevez d'erreurs ou d'oublis dans votre image perso, il suffira d'attacher de nouveau votre disque/image sur un de vos serveurs virtuels (éventuellement un serveur dont la création du disque système a utilisé cette même image comme source). Une rapide correction sur l'image puis vous pourrez détacher le disque/image.

L'image sera alors de nouveau disponible pour créer des serveurs sans l'erreur.

Modification des OS standards par Gandi

aegiap — Thu, 28 Oct 2010 15:27:00 +0200

Quelles sont les modifications appliquées par l'équipe de Gandi sur les installations standard d'OS pour être utilisé avec l'hébergement Gandi ?

Modifications du système local

L'infrastructure de l'hébergement Gandi utilise la virtualisation Xen en mode paravirtualisation (pour le moment). Nous devons ainsi compiler un noyau Linux avec des options spécifiques pour lui permettre de démarrer votre serveur virtuel. De plus, comme nous offrons la possibilité aux clients d'ajouter ou retirer des ressources dynamiquement, le système hotplug du noyau a été patché par notre équipe pour rendre cette fonctionnalité efficace (principalement des appels à udev). Tous les modules noyaux sont disponible pour chaque nouvelle version du noyau sur http://mirrors.gandi.net/kernel/. A partir de Linux 2.6.32, nous compilons le noyau Linux xenU avec les sources disponibles sur noyau.org et vous pourrez trouver le fichier de config de la compilation dans /proc/config.gz sur votre serveur virtuel. Nous intégrons aussi des patches externes comme drbd (avant son intégration dans les sources officielles du noyau Linux).

Chaque image de système d'exploitation que nous mettons à disposition sur l'hébergement Gandi contient des modifications par notre équipe. Nous désactivons par exemple le service d'horloge matériel (hwclock) car Xen ne permet pas d'y accéder. Sur certaines distributions nous désactivons des fonctionnalités du démarrage comme ureadahead ou plymouth pour obtenir un démarrage fluide du serveur virtuel. La plupart de la configuration système est effectué pendant le démarrage du serveur, notamment pendant le premier boot.

Il faut noter que sur l'architecture x86_32 et afin d'utiliser la capacité matériel (hwcap) de Xen, la libc peut utiliser la capacité nosegneg avec le package libc-xen correct.

Le package gandi-hosting-vm

L'idée de cet article a été initiée par la mise à disposition d'une nouvelle version de gandi-hosting-vm. Le package contient une collection de scripts pour configurer le système de votre serveur virtuel à chaque boot et sur des événements spécifiques des ressources du serveur.

Changement dynamique des ressources du serveur

Lorsque vous ajoutez ou retirez des ressources dynamiquement à votre serveur, le noyau Linux reçoit des informations de la part de Xen - le système gérant la virtualisation. Chacun de ces événements est passé au démon udevd qui les compare à ses règles définies. Sa fonction principale est de créer les fichiers dans le répertoire /dev/ pour permettre aux applications d'accéder aux nouvelles ressources.

Sur l'hébergement Gandi et afin de gérer les ressources dynamiques, notre équipe a écrit des règles udev (disponible dans /etc/udev/rules.d/86-gandi.rules) pour démarrer un script quand un disque virtuel, une interface réseau virtuel ou même un processeur virtuel est attaché (ou retiré) du serveur virtuel.

À un niveau plus détaillé, quand une interface virtuelle est attachée au serveur, le script /etc/gandi/manage_iface.sh est appelé par le démon udev et une requête DHCP est envoyée sur l'interface. Plusieurs scripts traitent ensuite les données récupérées par la réponse DHCP et configurent la route par défaut (/etc/gandi/dhcp-postconf) et stockent les informations de configuration réseau (/etc/dchp-hostname) dans un répertoire en tmpfs pour une configuration complète pendant le démarrage. Quand l'interface réseau virtuel est détachée, le script enlève simplement l'interface.

Quand un disque virtuel est attaché, un script (/etc/gandi/manage_data_disk.py) est appelé de manière similaire. Il essaie de vérifier le système de fichier sur le disque ou les partitions (seulement en mode GandiAI) puis monte le tout dans un point de montage spécifique utilisant le label du système de fichier /srv/<FS label>. Si aucun label n'est configuré, le nom du disque ou de la partition est alors utilisé (par exemple /dev/xvdc). Pour changer les options de montage par défaut, vous pouvez éditer la variable mount_options au début du script Python.

Pendant le démarrage du serveur

Le package gandi-hosting-vm installe deux services appelé au démarrage : gandi-mount et gandi-config. Le premier monte les systèmes de fichiers des disques virtuels déjà attachés dans le répertoire /srv/ du système d'exploitation (voir la description de /etc/gandi/manage_data_disk.py ci-dessus). Vous pouvez lancer le service manuellement ensuite une fois le serveur démarré complètement et il va essayer de monter les systèmes de fichiers de tout les disques virtuels attachés au serveur (dans le cas où vous désinstallez les packages udev par exemple).

Le deuxième service démarre plusieurs 'plugin' spécifique pour configurer le système. Une partie des étapes de configuration est optionnelle et un fichier de configuration (/etc/default/gandi) est disponible pour choisir d'activer ou non ces étapes. Chaque variable de configuration contient une courte description. Ces 'plugins' configurent par exemple : la console locale pour accéder par la console d'urgence de l'hébergement Gandi, le nom de la machine et les serveurs DNS pour les requêtes, le fuseau horaire à Europe/Paris, la capacité matériel (hwcap) nosegneg en fonction du kernel choisi, modifie le message du jour (motd) avec un texte par défaut, etc.

Par exemple, quand le 'plugin' 11-config_ssh est appelé, il créé les clefs SSH pour la machine virtuelle si elles ne sont pas déjà présentes. Puis, en fonction de votre configuration, il peut ajouter la clef SSH de management par Gandi dans le trousseau de clef du compte root (variable CONFIG_SSHMGMT). Il va ensuite modifier la configuration du serveur ssh pour désactiver les mots de passe vides, activer la compression et désactiver les accès en root (variable CONFIG_SSHD).

Le package gandi-hosting-agent

L'agent Gandi est utilisé pour configurer le serveur virtuel en fonction des informations du client. Dans le cas de serveur en mode expert, la configuration du système local est limitée au mot de passe root et à la création de l'utilisateur administrateur (choisi par le client) pour éviter les accès en root par ssh. Dans le cas de serveur en mode GandiAI, l'agent utilise des modules spécifiques pour configurer les applications choisies sur le système.

Lorsque votre serveur en mode expert est configuré après la création, vous pouvez désinstaller les packages de gandi-hosting-agent. En utilisant par exemple : dpkg -P $(dpkg -l | awk '/gandi-hosting-agent/ { print $2 }' | xargs) pour une distribution à base de package .deb ou rpm -e gandi-hosting-agent pour une distribution à base de package .rpm.

API Hosting 1.0 en bêta

zllak — Wed, 01 Sep 2010 15:23:00 +0200

Comme vous le savez peut être déjà, nous sommes en train de finaliser la gestion de notre plateforme d'hébergement Cloud via une API publique. Afin de vous faciliter le travail, beaucoup de choses ont été remaniées afin de vous permettre une utilisation plus simple, et une vraie maitrise de vos ressources hébergement chez Gandi.

En guise d'introduction, ce billet sera volontairement peu technique, et ne présentera que succinctement des parties qui seront développées en détails lors de la sortie officielle de l'API.

API ?

Pour la plupart des humains, le terme API n'évoque pas forcément grand chose. Je vous propose donc une petite définition rapide de ce qu'est une API.

Une interface de programmation (Application Programming Interface ou API) est une interface fournie par un programme informatique. Elle permet l'interaction des programmes les uns avec les autres de manière analogue à une interface homme-machine qui rend possible l'interaction entre un homme et une machine. Du point de vue technique une API est un ensemble de fonctions, procédures ou classes mises à disposition par une bibliothèque logicielle, un système d'exploitation ou un service. La connaissance des API est indispensable à l'interopérabilité entre les composants logiciels.

Voici la définition complète.

Concrètement, l'API Hébergement permettra à la personne qui s'en sert de pouvoir manipuler ses diverses ressources hébergement de Gandi. Il pourra par exemple, créer de nouvelles machines virtuelles, créer de nouveaux disques, relâcher des adresses IP, etc...

L'API a été pensée pour être la plus simple possible à utiliser.

Utilité de l'API

L'API va vous permettre de manipuler tous vos objets hébergement, à savoir vos machines virtuelles, vos disques, vos interfaces réseaux, vos IPs, etc..., le tout de façon programmatique. Vous pourrez en créer, en supprimer, les modifier, les lister.
L'API fournit également la possibilité de gérer les attachements entre vos ressources.

Mais l'un des buts essentiel est d'être utilisé par d'autres programmes afin de construire quelque chose en lien direct avec nous.

Prenons 2 petits exemples:

un valable pour tous, grâce à la commande vm.update par exemple, vous pourrez, si vous détectez dans les logs que votre serveur manque de RAM, lui en ajouter à la volée automatiquement.
un exemple pour une société qui édite un logiciel, grâce à la commande vm.create, vous pourrez démarrer automatiquement et rapidement un serveur à partir d'un disque préparé avec votre applicatif et le proposer à vos clients

Le premier jeu de méthode vous permettra de manipuler les objets suivants :

datacenter list info
image list info
vm list info count create update delete start stop reboot disk_attach disk_detach iface_attach iface_detach
disk list info count create create_from update delete
iface list info count create delete

ainsi qu'une gestion des opérations
operation list info count delete

Nouveautés à venir

Profitant de la sortie de l'API, plusieurs fonctionnalités vont voir le jour. Ce sont des choses qui nous ont été demandées pour la plupart, et qui sont pour l'instant gérées par nos équipes du support. Certaines fonctionnalités ont été revues, et déplacées là où cela nous permettrait d'apporter quelque chose de nouveau.

Le choix du kernel et de la ligne de commande se fait maintenant sur chaque disque. Les disques auront un rôle plus important que maintenant. Il sera également possible de détacher un disque anciennement "système", pour l'attacher sur une autre machine virtuelle pour, par exemple, faire du recovery en cas de problème lors d'une mise à jour ou d'une installation ratée. On pourra également choisir sur quel disque une machine virtuelle démarrera.

Comment participer

La phase e bêta privée est en cours. Il vous suffit d'envoyer un e-mail à beta-hosting@gandi.net avec votre identifiant et nous vous recontacterons pour vous donner les accès.

Tester notre solution ?

Tous les clients inscrits à la lettre d'information disposent dans leur compte d'un coupon permettant de tester gratuitement notre solution pendant un mois. Pour les autres, un formulaire de demande de parts de test est également disponible.

Restez donc à l'affut, plus d'informations vont venir dans les jours qui viennent !

Mandriva 2010, image en accès alpha [maj]

aegiap — Mon, 16 Aug 2010 10:39:00 +0200

L'hébergement sur des serveurs Gandi permet à ses clients de choisir parmi une sélection d'image d'OS disponible à la création de la machine. Après la préparation en interne de l'image et après une batterie de test, l'image est mise à disposition d'un groupe de client 'alpha' pour l'hébergement Gandi. Ces clients peuvent ainsi créer des serveurs utilisant ces images en 'release candidate'. De notre coté, cela nous permet d'élargir le champs des tests effectués sur les images et de dénicher les bugs et problèmes en touchant un plus petit groupe de client.

Aujourd'hui - 21 Mai - sort donc l'image d'OS basée sur une Mandriva 2010.0. Cette nouvelle version de la distribution Mandriva démarre avec un kernel 2.6.27 par défaut. Cette image est pour le moment disponible pour le groupe de client hosting en 'alpha'. Cette image de système sera bientôt disponible pour tous. N'hésitez pas à nous contacter si vous souhaitez participer à nos phases de test alpha.

16 aout 2010 : L'image est maintenant disponible pour tous

Kernel et cmdline

Kalou — Tue, 18 May 2010 11:28:00 +0200

Nous vous proposons (enfin!) de choisir la version de votre kernel (parmi une liste qui évoluera), et les options de démarrage associées (cmdline). Les 2.6.18 et 2.6.27 sont les versions "de base" fournies par Xen (backport des patches xen pour la 2.6.27). La 2.6.32 actuellement disponible utilise paravirt_ops et l'implémentation "linux" des patches de Xen.

Nous vous annoncerons les nouveaux kernels disponibles ici même.

Ça se trouve dans "Mode avancé", dans l'interface d'administration du serveur :

Et vous donne accès à ceci :

Coté cmdline, vous pouvez maintenant désactiver selinux au boot, booter en single user, changer le disque et la partition de boot (pratique pour travailler avec des "images"), choisir la console la plus appropriée. Bref, de quoi gérer plus agréablement vos mises à jour ou réparer votre serveur de façon plus autonome.

Si une option vous manque, n'hésitez pas à nous la suggérer.

Cherokee arrive chez Gandi.

hobbestigrou — Thu, 29 Apr 2010 00:08:00 +0200

Un ami m'expliquait qu'il venait de terminer l'installation d'un serveur web. Ayant décidé de changer et de ne pas utiliser le géant Apache que tout le monde connait, mon ami semblait avoir trouvé une bonne alternative. Portant le doux nom de Cherokee, il paraissait plus léger et plus performant qu'Apache. Voir les benchmarks provenant du site du projet à la fin de l'article. ^[1]

Personnellement, je ne le connaissais pas du tout, j'avais certainement déjà entendu son nom une ou deux fois, mais je n'y avais pas prêté attention. Pour voir ce qu'il donnait, j'ai décidé de l'installer en local. Je fus agréablement surpris ! Sur une distribution Debian like, l'installation se fait très simplement avec un apt-get install cherokee (ou aptitude).

L'interface web qu'il fournit est claire et plutôt agréable. L'idée est intéressante. Il sera possible d'activer l'interpréteur PHP avec un simple clic, pareil pour l'activation de différents virtualhost ou autres options. Il y a un assistant qui permet d'installer des technologies comme Django, Rails, ou Wordpress, etc.

Je me suis dit que présenter ce projet à une réunion devs chez Gandi pouvait être intéressant, notamment pour les personnes utilisant GandiAI. Le projet a bien été perçu. Après discussion et un coup d'œil rapide sur le code source, rien ne nous a choqués. Cela ne signifie pas qu'il n'y a pas de bugs, toutefois un code propre c'est plutôt bon signe ! Le cœur est écrit en C et l'interface d'administration en Python.

C'est donc de cette manière que Cherokee a fait son apparition chez Gandi et qu'une image a été réalisée, vous permettant ainsi de le tester rapidement.

Nous avons ajouté une distribution en mode expert avec Cherokee de préinstallé... il vous suffit de choisir cette distribution lors de la création de votre serveur. Je vous rappelle aussi que si vous n'avez pas encore essayé notre service, vous pouvez faire une demande sur notre formulaire de demande de test.

Pour avoir plus d'informations sur Cherokee, vous pourrez vous rendre sur le site du projet . Un article lui a également été consacré dans Gnu/linux magazine France par Carl Chenet dans le numéro 125.

Notes

[1]

Le courriel s'est fait la malle

Nicolas (Gandi) — Fri, 26 Mar 2010 21:59:00 +0100

Okay, il fallait que je pousse un jeu de mots idiot comme d'habitude, mais c'est la meilleure traduction que j'ai trouvée pour introduire le post de Leland, que je recommande d'ailleurs dans sa version originale pour les anglophones, il est ici.

Comme beaucoup le savent maintenant, la plateforme de Mail Gandi a subi, ces deux dernières années, de récurrentes baisses de performance tous les deux mois en moyenne. Comme nous vous l'avons annoncé sur le Bar, nos équipes ont travaillé afin de vous offrir une nouvelle plateforme Mail bien plus robuste. Celle-ci est le résultat d'un investissement de ressource considérable sur plusieurs mois. Je suis aujourd'hui, heureux de vous dire que la nouvelle plateforme est totalement opérationnelle et que tous les clients Gandi Mail sont migrés dessus (la migration à elle toute seule a pris près de six semaines). Nous avons pris la décision de migrer les clients au fur et à mesure, en plusieurs semaines afin de minimiser l'éventuel impact sur nos clients, et pour la plupart (avec très peu d'exceptions), la migration complète s'est passée parfaitement sans même que personne ne s'en rende compte ;)

Bref, sans plus attendre, jetons rapidement un œil à cette nouvelle plateforme Mail et regardons ce qui a changé dans Gandi Mail V2. Oh, et juste avant de commencer, cet article va être (au grand désespoir du traducteur) quelque peu technique de temps en temps, avec l'utilisation (NDT: abusive) de quelques acronymes et autres expressions geeks. Ne vous inquiétez pas, vous saurez d'ici peu ce que nous autres, barbus technophiles, échangeons comme bavardage quotidien ! ;)

Au commencement, il y avait le Mot…

… et le Mot fut écrit… et avant même la naissance d'internet, le Mot est devenu une part critique de nos vies... Oui, c'est exact… E-mail. Bref, en tant que registrar, Gandi fournit des services email pour les noms de domaines enregistrés chez nous. Jusqu'ici, tout va bien… La plateforme originale a été conçue pour être dimensionnable horizontalement afin de supporter plusieurs dizaines, voire centaines de milliers de boites mails. L'un des défis rencontrés fût une architecture pourvue de capacités de stockage dimensionnables tout en permettant les utilisateurs d'accéder à leurs boites sans même vérifier sur quel système de stockage ou d'accès ceux-ci étaient raccordés. Ça ressemble bien à un boulot pour ce bon vieux Network File System (NFS). Du coup, la plateforme originale fut basée sur une infrastructure NFS pour les boites mail.

Les mails entrants étaient reçus sur n'importe lequel des nombreux serveurs entrants tournants sur Postfix. Une fois les mails reçus et passés aux moulinettes antispam et autres filtres, le spool s'occupait alors d'identifier quel filer de stockage contenait la boite mail en question, puis forwardait le mail en utilisant le SMTP au serveur de stockage de backend (lui-même utilisant aussi Postfix) pour la livraison locale.

Lorsque l'utilisateur souhaitait accéder à sa boite mail, il devait accéder à un serveur frontal faisant tourner Dovecot. Les serveurs d'accès devaient avoir un accès "local" à toutes les boites mails via l'utilisation des montages NFS. Le client souhaitait simplement utiliser un client POP ou IMAP pour se connecter au serveur, pour accéder à sa boite mail.

Le mail sortant est plus simple; basiquement, un relais SMTP utilisant une authentification SASL.
Le schéma suivant vous montre un très haut niveau de vue générale de la version originale de la plateforme Mail.

Et ? Qu'est-ce qui a changé ?

Okay – avant de savoir ce qui a changé, regardons d'abord pourquoi nous avions à le faire.

La plateforme originale était jolie et l'architecture fonctionnait très bien à un niveau de trafic modéré, indépendamment du nombre de boites mail. Le risque avec le fait de dimensionner une plateforme basée sur le nombre de boites mail, c'est que c'est très facile à surcharger ou, dans certains cas, mal interpréter les effets induits de ce dimensionnement. Alors que le trafic commençait à augmenter au fil des années, de temps à autre, les serveurs d'accès frontaux avaient à lutter pour accéder au système de fichiers NFS, qui lui, utilise un système de verrouillage pour éviter les corruptions pouvant intervenir dans le cas d'opérations de lecture/écriture multiples sur le même fichier (ou bloc).

Ce graphique représente les volumes moyens pour l'année dernière (notez que les courbes ne sont pas agrégées, donc les éléments sont cumulatifs). L'axe vertical représente le nombre de "messages par minute" (avec un indice max. à 24 000) alors que l'axe horizontal représente les mois (avril à mars).

Alors que les verrouillages augmentaient avec le temps (et rappelez-vous que tous les serveurs avaient un accès à travers tous les systèmes de fichiers), le résultat fut un effet boule de neige qui a engendré de sévères dégradations des performances de l'ensemble de la plateforme – et pas seulement des boites mails présentes sur le serveur de stockage concerné par le verrouillage en cours. Pendant ce temps, les utilisateurs essayaient de se connecter à leurs boites mail dont le serveur acceptait la connexion et attendait simplement que le verrouillage cesse pour les laisser accéder aux boites.

Donc, les défis étaient simples :

Comment supprimer le besoin de NFS et continuer à permettre le dimensionnement horizontal.
Comment éviter d'impacter la plateforme Mail complète en cas de problème sur un seul serveur de stockage, et comment minimiser l'impact sur les utilisateurs dans ce cas.
Comment maximiser les performances de la plateforme pour permettre le dimensionnement vertical aussi bien qu'horizontal.

Comme il y a très peu de changement sur les éléments du spool SMTP entrant, et que la majorité de la charge était associée au NFS, regardons de plus près les éléments d'accès.

Où est ma boite mail ?

D'accord, donc l'utilisateur se connecte à sa boite mail avec son client préféré (Thunderbird, Outlook Express, Mail.App, Evolution, ou n'importe quoi d'autre dans ce cas…). La connexion du client arrive sur l'un des nombreux serveurs frontaux d'accès Mail sous Dovecot. Comment, du coup, le serveur sait où chercher pour trouver l'email ? À l'origine, le mail était en "local" puisque tout était monté en NFS. Dovecot fait une simple requête en base pour déterminer le chemin d'accès de la boite mail de l'utilisateur. Avec le nouveau système, il n'y a pas de NFS, donc pas de système de fichier "local" où Dovecot pourrait chercher.

C'est à cet instant qu'une option très utile de Dovecot entre en scène : la fonction proxy. En l'utilisant, le serveur frontal s'occupe de l'authentification de l'utilisateur, vérifie quel serveur de stockage héberge la boite mail, puis initie une connexion "client" proxyfiée directement avec le serveur de stockage qui tourne, lui-même, sous Dovecot. Si le client se connecte en utilisant l'IMAP, alors la connexion proxy sera aussi IMAP.
De la même manière, si le client utilise POP3, alors la connexion proxy sera POP3. Le serveur de stockage n'a pas besoin de re-authentifier la connexion.

Il y a plusieurs bénéfices avec cette architecture :

La suppression du NFS supprime également l'effet de bord des locks NFS
Puisque le serveur backend de stockage a la boite mail physiquement attachée en local, il n'y a pas de conflit dans le filesystem, et donc pas besoin de locks. De plus, maintenant que les baies de stockage sont en hautes performances, les accès aux boites mails sont beaucoup plus rapides.
Les serveurs frontaux n'ont plus à faire d'opérations couteuses en I/O sur les disques locaux, et consomment donc considérablement moins de CPU (en fait, techniquement, il n'y a aucune vraie raison pour que les frontaux aient leurs propres disques. Cela pourrait même réduire les coûts de dimensionnement horizontal de pouvoir utiliser des serveurs sans disque…).

Et que se passe t'il si un Filer lache ?

Afin de répondre à l'autre partie du défi, et de limiter l'impact en cas de défaillance d'un composant pour le moins d'utilisateurs possible, le concept original de stockage dimensionnable pour tenir le maximum de boites mail possible a dû être abandonné. Après tout, si un filer tombe, toutes les boites mails associées seraient également hors ligne.

Du coup, l'idée ici est d'augmenter le nombre de serveurs de stockage, et de répartir les boites mails plus finement entre eux. De cette manière, en cas de défaillance du serveur de stockage, beaucoup moins de boites mails sont affectées.

Le second aspect pour minimiser l'impact d'une défaillance d'un composant est lui aussi assez simple. Avec la version précédente de la plateforme (vous vous rappelez des locks NFS ?), une connexion d'un client mail à sa boite était juste répondu par le serveur d'accès et attendait simplement de pouvoir accéder au système de fichiers. L'effet pour l'utilisateur est que son client mail se plante là et éventuellement, se fait time out.

En utilisant l'arrangement proxy IMAP/POP3, si le serveur de stockage actuel est tombé, le serveur frontal répondra immédiatement au client mail avec un message "Temporarily Unavailable", et la connexion TCP sera fermée.

Les baies de disques sont elles-mêmes bien entendu redondantes. Le seul réel point de faiblesse (SPoF) potentiel est le serveur qui contrôle les baies de disque, car à cause d'une limitation technique des baies, il n'est pas possible d'avoir un double contrôleur si l'on utilise des volumes séparés et en miroir RAID via deux baies de disques. Cela serait possible si les volumes n'étaient pas en miroir entre baies, mais ce serait plus risqué puisqu'il n'y aurait pas de copie "backup" des données en cas de défaillance d'une baie… Nous considérons donc que le risque d'avoir un seul contrôleur de serveurs de disque est un risque acceptable, étant donné que nous en avons un autre de disponible, prêt à être monté. L'image ci-dessous illustre la solution de stockage des mails

Mais...on a rien vu en fait ?

Si vous êtes dans cette catégorie, c'est que le pari est réussi ! C'était le postulat absolu du début : tout changer sans impacter nos clients et sans perdre de données.

Alors, comment s'est passée la migration ? Bon, bien sûr déjà, le processus a duré plusieurs semaines, pendant les périodes où l'activité était la plus faible. Nous avons opéré unité de stockage après unité de stockage, en migrant via plusieurs itérations de rsync. À la dernière, nous avons mis la base de données à jour pour indiquer à la boite son nouvel emplacement.

Au fur et à mesure des semaines, un effet secondaire appréciable a tout de suite été détecté avec le retrait du NFS de la plateforme, la charge sur les serveurs d'accès a graduellement diminué, ce que vous pouvez voir sur le graphique ci-dessous. Maintenant que NFS a disparu, la charge serveur est quasi nulle. Les 2 graphiques ont une échelle relative qui donne une moyenne sur la période. Le premier est sur 6 mois alors que le deuxième montre la moyenne sur les 5 dernières semaines.

Voilà, J'espère que ce (petit) article vous a donné une bonne idée de ce à quoi ressemble notre nouvelle plateforme Gandi Mail, ses nombreux avantages en terme de performance et de robustesse.

10 ans de Gandi: retour d'expérience

Kalou — Tue, 16 Mar 2010 16:51:00 +0100

À l'occasion des dix ans de Gandi, l'idée un peu folle de donner, sur dix jours, 55000 domaines, a posé une question pratique. Comment, en ouvrant les vannes d'une telle opération, maintenir une qualité irréprochable sur le site ? L'ambiance festive aurait aussi bien pu se transformer en cauchemar pour nos clients si ils avaient été privés d'accès à leurs interfaces de gestion.

La décision fût donc prise d'héberger l'événement sur un site dédié. Occasion rêvée pour se mettre un peu à la place de nos clients, et utiliser notre infrastructure d'hébergement. Règles du jeu : on utilise exclusivement les outils fournis au client, on prépare une archi qui monte en charge facilement, ça ne doit pas coûter un bras, ça peut illustrer notre flexibilité légendaire.

Keep it simple, stupid

De la décision à l'implémentation, on avait une semaine. L'idée charmante de monter un site "cloudish" à base de technos modernes, et peu maîtrisées, est donc oubliée d'office. Pour être honnête, vu les délais, le développeur désigné d'office se voit choisir la techno : "là où t'es à l'aise, tu as une semaine". Ça sera PHP/mysql, ce qui n'est pas du goût de tout le monde ! Mais permettra de sortir le site testé et dans les temps.

Pour tenir une charge correcte, plusieurs serveurs seront nécessaires. Premier rappel de nos imperfections, Gandi ne fournit pas de load balancing ! Qu'importe, on ira donc sur un round robin DNS, à petit TTL pour pouvoir sortir facilement un frontal cassé de la production.

Notre distribution pour l'occasion, sera une ubuntu 9.10 - parce qu'elle est assez à jour, et qu'elle utilise un kernel 2.6.27.

Multiplier les petits serveurs

La meilleur façon de monter en charge sur notre infrastructure est d'isoler fonctionnellement l'architecture en nombreux petits serveurs. Là où nous assurons un minimum de "scalabilité" verticale (vous pouvez augmenter dynamiquement la RAM, le CPU alloués à un serveur), c'est à l'architecture de prévoir la scalabilité "horizontale".

Ainsi, on peut facilement monter les ressources là où les bottlenecks se font sentir, et ajouter/ou déplacer des parts d'un serveur vers l'autre lorsque la puissance allouée le demande. Les avantages des "nombreux petits serveurs" sont multiples :

chaque serveur bénéficie au minimum d'un core CPU en burst (oui, un core entier, même sur une part : c'est nouveau)
la redondance est assurée, et vos parts s'étalent un peu aléatoirement sur des centaine de serveurs physiques
particulièrement en environnement virtualisé, la performance mémoire est meilleure sous 1G de RAM
si vous avez 4 serveurs d'une part, au lieu d'un gros de 4 parts, ils montent à 8x4 parts dynamiquement, ou 24x4 parts en un reboot, tout ça sans toucher à l'archi - là ou le gros s'arrête à 8 sans reboot, ou 24
les ressources sont faciles à déplacer vers les serveurs qui en ont besoin.

Nous partons sur l'infrastructure simpliste :

24 (!) serveurs d'une part, pour gérer le web et PHP : 10 en anglais, 10 en français, et 2 + 2 pour l'IPv6
2 serveurs de 4 parts, des memcached répliqués pour soulager la DB et gérer les sessions
1 serveur mysql de 4 parts, qui contiendra les coupons pré-générés (ils tiennent en RAM, la base doit théoriquement s'ennuyer)

Après quelques belles surcharges et un bout de code revu, la base de donnée sera finalement épargnée au maximum par memcached (voir chapitre « un code léger… »)

Soit 36 parts, pour une durée de dix jours : environ 140 euros.

C'est un admin qui s'usera les doigts sur notre site pour créer, et configurer les 24 serveurs en parallèle. Visiblement, la sortie de l'API hosting ou une fonction dans l'interface web seraient les bienvenus. (Merci à cssh pour l'occasion).

Sécuriser (un peu) les machines

Une distribution par défaut mérite toujours quelques retouches. Exporter mysql sur le réseau « public » du hosting gandi nous ennuyait un peu. À grands coups de netstat, fermer les services inutiles qui écoutent sur un port public. Avec l'aide de tcpwrappers (hosts.allow, hosts.deny), on ferme toutes les interfaces « privées » (sshd, mysql réservé aux machines frontales du web).

Restera à bien faire attention au code php et à nos queries mysql : le meilleur moyen d'éviter les injections est encore de binder tous les params après un prepare(). En plus, ça décharge la DB lorsqu'on effectue plusieurs execute.

Un détail important : notre site autorisant l'envoi de mail à un destinataire « arbitraire », il était critique de limiter au maximum son exploitation potentielle par un spammer malin : restrictions du nombre d'envoi par coupon, au minimum, et monitoring.

Prévoir l'environnement de dev et le déploiement

Partager les données entre les sites, c'est ajouter un "single point of failure" et un point de contention à l'archi. Nous optons donc pour un déploiement "local" à chaque serveur du contenu du site. Un site de développement et de "staging" sur une VM sert à tester et développer les mises à jour. Un script et quelques rsync permettent de déployer l'ensemble sur tous les frontaux de l'architecture. On a dit simple !

Surveiller ses ressources

Quelques minutes avant l'opération, pour prévenir plutôt que guérir, la totalité des machines virtuelles sont augmentées d'une à deux parts. En utilisant l'interface des stats, dès le premier jour, on peut constater l'ennui total qui habitait les machines virtuelles:

Il aurait été malin, à ce moment précis, de revenir à une part par machine. Ou d'exploiter gandi "autoflex", ou encore, vu le type de charge observée, de préparer des flexs programmés pour les heures de lâcher des coupons ! Malheureusement, beaucoup de monde sur beaucoup de ponts, on a raté l'occasion de vous faire cette belle démonstration (écono-techno-(éco ?)logique).

Un code léger vaut mieux que mille CPU costauds

Même si nous avions à notre disposition plusieurs milliers de CPU et beaucoup de teras de RAM, mardi fut suffisamment chaotique pour qu'on en reparle ici : après un lundi très bien tenu en charge, le plan d'exécution de notre unique SELECT COUNT changea brutalement et devint terriblement plus lent (300ms). Avec foi, nous avions pensé que ce query « unique », sur une table présente complètement en mémoire, ne poserait pas de problème : il était donc exécuté sur toutes les pages du site. La concurrence d'accès avec les UPDATEs des coupons finit par avoir raison de la base qui, malgré des stats systèmes proches de l'idle, entra discrètement en contention de lock.

La réaction habituelle est d'ajouter des parts pour monter en charge. C'est une solution temporaire acceptable, mais ça ne suffit pas !

Un analyse système, une remise en question du code, et une utilisation salvatrice de memcached permit de retrouver des performances acceptables. Une modification des queries utilisés aurait peut-être pu faire l'affaire également.

Une moralité à cet épisode: le code, les indexes, l'architecture, (…) sont les garants de votre montée en charge, et si ils sont « cpu friendly » vous épargneront, sinon une catastrophe, au moins un achat de parts inutiles.

En plus, comme on dit ici en plaisantant, c'est écolo.

Quelques chiffres

36 parts, mais on aurait pu tenir sur moins (snif)
5% de CPU en peak
4000 requêtes par frontal dans la première minute de chaque heure de pointe (environ 1400 req/seconde au total)
un minimum de 11 secondes pour donner 1000 coupons
pour le même nombre de coupons, un maximum de 40 minutes, pendant l'incident.

Que faire si son serveur ne répond plus ?

Nicolas (Gandi) — Thu, 14 May 2009 12:00:00 +0200

Comme vous le savez probablement déjà, notre plateforme vous met à l'abri d'une panne matérielle sur votre serveur.

En effet, en cas de soucis sur la machine ou si nous suspectons un problème à venir (température anormale, mémoire corrompue...), votre "serveur" sera migré automatiquement sur une autre machine. Par contre, si vous avez un problème interne à celui-ci et qu'il ne répond plus, c'est alors souvent à vous d'intervenir. Dans tous les cas, vous devez préalablement vérifier que votre serveur est marqué comme 'Ok' sur votre interface Gandi, il peut être soit stoppé, soit en pause pour défaut de paiement par exemple.

On peut distinguer trois cas:

1. Vous arrivez encore à vous connecter en ssh sur votre serveur. Les commandes suivantes vous permettront alors d'analyser la situation :

- "uptime" vous donnera la charge instantanée de la machine,
- "free", dont la colonne "used" vous indiquera la quantité de mémoire utilisée par vos applications
- "top" (nous vous conseillons d'installer "htop") vous indiquera en temps presque réel le classement des applications (ou processus) qui consomment des ressources (mémoire, processeur),
- "dmesg" vous montre les messages issus du kernel linux de votre serveur,
- la lecture des fichiers de logs comme /var/log/messages ou /var/log/daemons avec la commande 'tail' par exemple (tail /var/log/daemons) vous donnera également de précieuses informations.
- "df –h" vous indique le taux d'occupation de vos disques.

Les pannes les plus courantes sont les suivantes :

   - plus d'espace disque sur votre disque système: la situation est souvent causée par une mauvaise gestion des logs sur le serveur ou par une base de données, par exemple, qui se remplirait trop rapidement. La solution consiste souvent à faire le ménage ou à agrandir le disque (voir le tutoriel)
   - plus assez de mémoire vive sur le serveur ou trop de mémoire utilisée : la solution simple consiste à prendre plus de RAM en ajoutant des parts. Si vous êtes en mode expert, vous pouvez également essayer de modifier le comportement de Linux avec la mémoire disponible en utilisant la commande 'sysctl -w vm.overcommit_memory = 2'.
Attention : pour que la modification soit maintenue lors d'un redémarrage, vous devrez aussi ajouter la ligne "vm.overcommit_memory = 2" aux fichiers "/etc/sysctl.conf" et "/etc/gandi/sysctl.conf".
   - trop de processus tournent en parallèle sur votre machine : il vous faudra alors diminuer les valeurs dans les fichiers de configuration de vos applications (le nombre de connexions simultanées sur Apache, par exemple) ou augmenter la puissance de votre serveur en lui ajoutant des parts.

2. Vous n'arrivez plus à vous connecter à votre serveur en ssh, qu'il ne répond plus au ping ou qu'il répond lentement.

La console virtuelle, activable à partir de votre compte (tutoriel disponible), vous donne un accès direct à votre machine à la manière d'un écran et un clavier (toujours virtuel) branché en direct sur le serveur.

Dans ce cas-là, il existe une méthode pour stopper tous les processus qui posent problème et avoir de nouveau accès au serveur.

Les raccourcis 'sysreq' sont disponibles par la console sur votre serveur. Les commandes sont à donner en appuyant sur Ctrl et "o" (comme Oscar) pour entrer en mode sysreq, puis indiquez la commande. Vous pouvez ainsi stopper tous les processus par : Ctrl+o +i (pour kill).
Ctrl+o +h vous permet d'avoir une aide succincte sur toutes les commandes sysreq disponibles.

3. Une troisième situation existe : votre serveur peut être "injoignable" mais fonctionner tout de même sans aucun problème technique.

Cela peut arriver dans le cas où votre serveur aurait été victime d'une attaque DDoS par exemple. Votre serveur sera alors isolé du réseau afin de protéger notre infrastructure et la qualité de service pour les autres clients.

Vous pouvez vérifier si votre serveur est dans cet état en effectuant une commande 'traceroute' vers l'IP de votre serveur. Si ce dernier s'arrête à l'entrée de Gandi, sur un de nos routeurs par exemple ou même avant, il est bien probable que votre serveur ait été isolé du réseau. Vous pourrez alors vous connecter au serveur via la console, mais il faudra contacter le support pour régler la situation (il vous contactera souvent avant). Ce cas de figure ne concerne que très peu de serveur.

Maintenant si vous êtes toujours bloqué, c'est que vous êtes dans le 4ème cas : le votre. Envoyez alors un email à notre équipe support indiquant bien que votre serveur est bloqué, vous recevrez alors une réponse le plus rapidement possible.

Penser infrastructure web

Nicolas (Gandi) — Tue, 05 May 2009 13:31:00 +0200

Comme vous le savez, notre système est flexible et vous permet de passer à n'importe quel moment et autant de fois que vous le souhaitez d'un serveur sur 1 part (1/64 de machine + 1/64 en boost, 256Mo de Ram) à un serveur de 16 parts (1/4 de machine + 1/4 en boost, 4Go de Ram), mais nous avons de plus en plus de clients qui après le lancement de leur service sont victimes de leur succès et se retrouvent en limite d'utilisation des 16 parts et viennent nous demander des serveurs de 24 ou 32 parts.

Notre réponse est souvent la même, nous leur conseillons alors de penser infrastructure web plutôt que serveur web.

En effet, notre solution vous permet de créer autant de serveurs que vous le souhaitez sur les ressources souscrites dans votre compte hébergement, la solution optimale consiste donc à séparer vos services pour une plus grande flexibilité et une plus grande robustesse.

Mais le plus simple est de prendre un exemple concret : comme certains le savent déjà, nous soutenons l'association Millenium pour la promotion des jeux et loisirs numériques en ligne.

Le succès grandissant du site millenium.org nous poussait à rapidement repenser l'architecture du site pour tenir la charge (de nombreuses vidéos, 17 000 visiteurs uniques/jours). Pour ne rien vous cacher, nous avons quelques priorités et projets Gandi à régler avant de nous occuper du site.

Suite à une importante mise à jour d'un des jeux suivis par Millenium (NDLR: WOW patch 3.1), et même si nous avions anticipé une charge importante en passant le serveur sur 16 parts, celle-ci a vite dépassé nos estimations avec plus de 50 000 visiteurs uniques le premier jour et surtout presque autant les jours suivants.

Le site recevait alors entre 500 et 1000 visiteurs en simultané, ce qui n'est pas viable pour un serveur unique de type LAMP avec, de plus, de très nombreuses vidéos. Nous avons donc changé l'infrastructure immédiatement, pour passer d'un modèle sur un serveur unique (qui est souvent le choix au démarrage) à un modèle en infrastructure. Nous sommes passés d'une extension verticale (plus de puissance) vers une extension horizontale (plus de serveurs) :

Comme le montre ce schéma, nous avons donc sorti la base de données sur un serveur à part et dupliqué le serveur web sur 2 machines, la répartition de charge se faisant via la zone DNS du domaine. Nous pouvions aussi envisager de dédier un serveur d'une part à la répartition de charge, mais cette solution était un peu plus longue à mettre en place. Dans notre cas, il a fallu 2 minutes pour ajouter des parts sur le compte, 6 minutes pour créer les 2 serveurs, 10 minutes pour transférer les données et 2 heures environ pour configurer les services.

Aujourd'hui, la plateforme tient 1 million de visiteurs uniques par mois pour plus de 3 millions de pages vues, ce qui est une bonne chose. Mais le mieux c'est que maintenant la plateforme est évolutive. Si la base de données souffre, il nous suffira d'augmenter le nombre de parts allouées au serveur, et si les frontaux web arrivent à saturation, il nous suffira d'en ajouter un.

Si vous vous trouvez confronté à ce genre de problématique, n'hésitez pas à nous consulter, nous nous ferons un plaisir de vous conseiller.