Amazon AWS EC2, DigitalOcean & Linode : test comparatif des performances

Virtual Server

Aujourd'hui, lorsqu'on souhaite héberger une application web un peu conséquente le recours à un (ou plusieurs) serveurs dédiés n'est plus la seule solution. On s'oriente de plus en plus souvent vers un système virtualisé offrant beaucoup plus de souplesse et d’options en matière d'administration. Je suis pour ma part entièrement convaincu par ce type d'offres et je ne vois plus beaucoup d’intérêt à opter pour un "vrai" serveur dédié ...

On trouve de nombreux acteurs sur ce marché, mais j'ai décidé de me concentrer sur 3 fournisseurs de serveurs privés virtuels particulièrement bien implantés sur ce secteur : Amazon avec son offre "Elastic Cloud Computing / EC2", Linode et DigitalOcean.

Comparer leurs offres n'est pas simple. En effet certains fournisseurs comme Amazon propose une multitude de configurations différentes ...

J'ai donc arbitrairement décidé de me mettre à la place d'un bloggeur souhaitant héberger son site avec un budget mensuel aux alentours de 20$. J'ai mis en place une méthodologie de test (certainement perfectible) permettant de comparer les points suivants : les performances des accès disques, des processeurs, de la mémoire ainsi que de la connectivité réseau.

Les outils utilisés sont les suivants :

  • "fio" : pour le premier test d'accès disques. Le test est basé sur une lecture aléatoire
  • "hdparm" : pour le deuxième test d'accès disques (test réalisé sans cache)
  • "sysbench" : pour le test du processeur et de la mémoire
  • "byte-unixbench" : pour obtenir un score de performance global
  • "Speedtest_Cli" : pour le test de débit (raccordement à l'Internet - les tests sont effectués en sélectionnant les serveurs d'OVH à Roubaix comme cible)

Afin de réaliser ces tests, j'ai commandé (le dimanche 13/4/2014) 3 serveurs virtuels auprès des différents fournisseurs. Ces serveurs étaient tous équipés d'une distribution "Ubuntu 13.10 - 64bits" et localisés en Europe (Irelande pour Amazon, Amsterdam pour DigitalOcean et Londres pour Linode). Les tests réalisés sont rigoureusement identiques sur les 3 VPS.

Les résultats des tests sont les suivants :

Test Amazon EC2 DigitalOcean Linode
HD test1 (bande passante) 9,56Mo/s 48,31Mo/s 13,21Mo/s
HD test2 (iops) 2 391 iops 12 800 iops 3 301 iops
HD Hdparm (sans cache) 9,76Mo/s 379,81Mo/s 223,68Mo/s
CPU (durée du calcul) 18,47s 14,45s 11,91s
MEM (durée du test) 9,30s 7,52s 12,53s
MEM (bande passante) 5 504Mo/s 6 807Mo/s 4 085Mo/s
score "Byte Unix" (1 proc) 235,7 1 167,7 522,2
Score "Byte Unix" (tous les procs.) 235,7 1 939,5 1 563.3
Speedtest Download 87,28Mbit/s 785.05Mbit/s 691,19Mbit/s
Speedtest Upload 106,12Mbit/s 104,59Mbut/s 160,22Mbit/s

Les caractéristiques (en date du 13/4/2014) des différentes offres souscrites pour ces tests sont les suivantes :

  • Amazon AWS EC2
    • instance de type "t1.micro" (à la demande)
    • abonnement mensuel : 22,05$
    • ram : 615Mo
    • disque : 30Go (EBS)
    • bande passante par mois : 51 Go
    • Mode de calcul du prix mensuel :
      • instance : 14,40$ / mois
      • disque EBS : 30Go x 0.055$ / mois = 1,65$ / mois
      • bande passante : 50Go x 0,120$ / mois = 6 $ / mois
  • DigitalOcean (premier pour 8 critères)
    • offre : "2Go"
    • abonnement mensuel : 20$
    • ram : 2Go
    • disque : 40Go
    • bande passante par mois : 3 To
  • Linode (premier pour 2 critères)
    • offre "Linode 1GB"
    • abonnement mensuel : 20$
    • ram : 1Go
    • disque : 48Go
    • bande passante par mois : 2To

C'est donc l'offre de DigitalOcean (premier pour 8 critères) qui présente les meilleures caractéristiques (pour un budget mensuel d'environ 20$). Le fait d'utiliser, en standard, des disques SSD lui donne un avantage certain sur ses concurrents (12 800 iops en lecture !). L'offre de Linode (premier pour 2 critères) est en deuxième position suivi par Amazon.

A signaler également le coût relativement important de la bande passante pour l'offre d'Amazon. En effet seul 1Go est intégré au coût mensuel de l'instance et le Go supplémentaire est facturé 0,12$ (pour une consommation inférieure à 1To / mois - une dégressivité est ensuite appliquée - attention quand même car 1To = 1000Go = 1000 x 0,12$ = 120$ / mois ...).

Il ne faut pas interpréter ce test trop négativement pour Amazon. En effet comme je l'ai précisé au début de ce billet le scénario retenu ici pour comparer les offres est spécifique (cas d'un bloggeur avec un budget mensuel de 20$ / mois ...). Amazon propose des offres très performantes mais avec un positionnement plus haut de gamme et destinées principalement aux entreprises. A signaler également qu'Amazon propose gratuitement des fonctionnalités spcécifiques et exclusives : load balancer, création automatique et "à la volée" de nouvelle instances en fonction de la charge ... On ne trouve actuellement pas d'équivalent chez les autres prestataires.

Bref, si vous disposez d'un budget de 20$ / mois et que vous souhaitez mettre en place un VPS, c'est probablement vers DigitalOcean que vous devez vous orienter !

Ce type d'offres étant en perpétuelle évolution je pense réaliser régulièrement d'autres tests de ce style en conservant ces 3 prestataires et en y ajoutant éventuellement d'autres fournisseurs.

Externalisez sereinement vos sauvegardes avec Duplicity

hard_disk

Si vous administrez des serveurs vous avez certainement déjà réfléchit aux problèmes d'externalisation de vos sauvegardes. Pour ma part j'étais à la recherche depuis pas mal de temps d'une solution permettant de réaliser une externalisation avec comme contrainte principale le fait que les sauvegardes soient stockées d’une manière chiffrée sur le serveur de destination. Bien entendu, il existe le classique Rsync (et ses dérivés), ou bien encore Rdiff-Backup, mais pour moi cette solution n'est pas viable dans tous les cas car si le transfert reste sécurisé il n'en va pas de même pour le stockage !

J'ai récemment découvert une solution qui me semble intéressante : Duplicity. Dans les grandes lignes Duplicity permet de réaliser une sauvegarde distante au travers de pas mal de protocoles : scp, ftp, ssh, rsync, s3 (et compatibles ...). Les sauvegardes peuvent être complètes ou incrémentales (à priori en mode "block" grâce à l'utilisation de librsync). Duplicity prend également en charge le chiffrement des fichiers de sauvegarde soit avec une clé symétrique soit avec un système de clé publique/privée (personnellement j'ai opté pour la première solution).

Malheureusement Duplicity semble être un peu "rude" à l'utilisation. C'est pour cette raison qu'est né le projet "Duplicity Backup". Il s'agit d'un script shell associé à un fichier de conf. L'objectif de ce script est de piloter, simplement et efficacement, le fonctionnement de vos sauvegardes (en faisant appel à Duplicity).

Voici donc un petit how-to résultant de mes premières expériences avec ce script. L'objectif pour moi était d'externaliser la sauvegarde de serveurs fonctionnant sous Linux Debian 6. J'avais initialement prévu de stocker mes sauvegardes sur Amazon S3 mais en effectuant quelques recherches j'ai trouvé un système compatible proposant un tarif plus avantageux : DreamHost proposant le Go de données stockée à 7cts/$ / mois.

C'est parti !

On va partir du principe que vous disposez d'un distrib Debian fonctionnelle (version 6 mais ça devrait également fonctionner avec les versions plus récentes). Python doit être préalablement installé (c'est normalement le cas par défaut).

  • La première chose à faire est d'installer les packages nécessaires au fonctionnement de Duplicity (le package "python-boto" permet l'interaction avec un système de type S3) :
apt-get install librsync1 python python-boto python-dev librsync-dev wget unzip
  • Créez ensuite un répertoire au sein duquel nous allons placer l'installeur de Duplicity, le script ainsi que le fichier de conf. La création de ce répertoire au sein de "/home" est proposée à titre d'exemple. Libre à vous de choisir l'emplacement qui vous convient le mieux !
mkdir /home/duplicity-backup
  • On se place ensuite au sein de ce répertoire :
cd /home/duplicity-backup
  • On télécharge Duplicity à partir du site officiel (à ajuster car la version aura préalablement évoluée lorsque vous lirez ces lignes ...) :
wget http://www.collet-matrat.com/fichiers_download/duplicity-backup/duplicity-0.6.21.tar.gz
  • On décompacte le tout :
tar -xzvf duplicity-0.6.21.tar.gz
  • On lance l'installation :
cd duplicity-0.6.21
python setup.py install

Si vous rencontrez des erreurs vérifiez bien d'avoir installé "librsync-dev" ( apt-get install librsync-dev )

  • Il faut ensuite mettre en place le script et son fichier de conf :
cd ..
wget http://www.collet-matrat.com/fichiers_download/duplicity-backup/duplicity-backup.sh
wget http://www.collet-matrat.com/fichiers_download/duplicity-backup/duplicity-backup.conf
chmod 755 duplicity-backup.sh
  • On édite ensuite le fichier de conf de Duplicity Backup (je ne détaille ici que les principales directives - pour adapter plus finement la configuration à vos besoins reportez vous à la documentation de Duplicity-Backup disponible ICI):
vi duplicity-backup.conf
  • Si vous utilisez un système de stockage AWS S3 ou compatible (comme le stockage de DreamHost par exemple) vous devez renseigner lignes 43 et 44 votre clé d'API et votre clé secrète
  • Ligne 57 maintenez le paramètre par défaut "ENCRYPTION='yes'" si vous souhaitez que vos sauvegardes soient chiffrées
  • Ligne 65 mentionnez votre clé de chiffrement (si vous optez pour un chiffrage "symétrique" / ce que je vous conseille - certes un peu moins sûr mais quand même beaucoup  plus pratique ...)
  • Commentez les lignes 78 et 79 si vous optez pour un chiffrage symétrique
  • Ligne 85 indiquez la racine du backup (utilisez un truc du style 'ROOT="/"' on définira plus tard la liste des répertoires à sauvegarder )
  • Ligne 99 mentionnez la destination de votre backup. Si vous sauvegardez directement sur AWS S3 la syntaxe est déjà prête, vous n'avez qu'à mentionner le nom de votre bucket de destination (avec un nom de répertoire). Si vous sauvegardez vers un système compatible S3 (comme DreamHost par exemple) il va falloir utiliser une syntaxe du type : DEST="s3://objects.dreamhost.com/le_nom_de_votre_bucket/le_repertoire_de_sauvegarde/"
  • Ligne 129 mentionnez le répertoire à sauvegarder (si vous avez plusieurs répertoires à sauvegarder regarder l'exemple entre les lignes 122 et 126
  • Si vous avez des répertoires à exclure ça se passe entre les lignes 134 et 137 (n'oubliez pas de commenter si vous n'en avez pas besoin)
  • La ligne 146 définie (entre autre) la politique de sauvegarde : par défaut faire un full tous les 14 jours (on peux également passer d'autres paramètres à Duplicity par le biais de cette ligne // plus d'infos : ICI)
  • La ligne 161 indique au système combien de full conserver sur le stockage distant (il existe de nombreuses possibilités en matière de conservation des données / reportez vous à la doc !)
  • On définie ligne 183 le répertoire de stockage des log de Duplicity (/var/log/duplicity par exemple)
  • Et enfin, à partir de la ligne 195 le paramétrage d'un éventuel (et optionnel) envoi de mail lors de chaque backup

Une fois ce paramétrage effectué, on peut lancer une première sauvegarde à l'aide de la commande

/home/duplicity-backup/duplicity-backup.sh -c duplicity-backup.conf -b
Pour obtenir la liste des commandes disponibles vous pouvez utiliser

/home/duplicity-backup/duplicity-backup.sh -c duplicity-backup.conf
La restauration peut être réalisée fichier par fichier à l'aide de la commande

/home/duplicity-backup/duplicity-backup.sh -c duplicity-backup.conf --restore-file fichier_à_restaurer [fichier_de_destination]
Il est également possible de restaurer l'intégralité d'une sauvegarde

/home/duplicity-backup/duplicity-backup.sh -c duplicity-backup.conf --restore [répertoire_de_destination]
Et pour finir, deux recommandations importantes :
  • n'oubliez pas de sauvegarder votre clé de chiffrement en lieu sûr !
  • consultez la documentation de Duplicity (ICI) & de Duplicity-Backup (ICI) pour découvrir toute la puissance de cet outil et du script associé !
Photo by : Jeff Kubina

Gérez « AWS Glacier » en ligne de commande

AWS_LOGO_RGB_300px

Pour ceux qui seraient passés à côté, Amazon Glacier est un système de stockage sur le cloud d'Amazon (un peu comme S3) dédié à la conservation "longue durée" de vos données (un système d'archivage en quelque sorte).

Par rapport à S3 le principal avantage de cette solution est le prix. En effet avec un coût de $0,01 par Go et par mois il s'agit certainement là de la solution de stockage la plus économique du marché (10€ / 1To / mois difficile de faire mieux) - A titre de comparaison 1To stocké sur S3 coûte 95$ / mois !

Bon à ce tarif là vous devez vous douter qu'il y a quelques inconvénients. Le plus significatif est certainement le délai de récupération des données. En effet si l'upload d'informations est immédiat, toute opération de récupération de données va nécessiter une attente préalable d'au moins 4 h ! Et ce délai concerne toutes les opérations : même une demande d’inventaire (un "ls" en quelque sorte) du contenu d'un dépôt va demander le même délai (4h) avant d'obtenir le résultat de votre requête ...

Il est donc clair qu'avec une telle contrainte il faut réserver l'usage de Glacier à des seules fins d'archivage ...

A l'inverse de S3 il n’existe pas (pour le moment) d'interface web (fournie par Amazon) permettant de gérer le contenu de ses archives. Plusieurs logiciels dédiés existent toutefois sur le marché. J'ai par exemple testé "FastGlacier" sur une des mes machines Windows (ce soft est gratuit pour un usage non commercial). Toutefois, dans certains cas, il est plus pratique d'utiliser directement une interface en ligne de commande (pour archiver le contenu d'un serveur Linux par exemple). Il existe, pour ce faire, un ensemble de scripts Python totalement fonctionnels et qui permettent d'agir sur vos archives. Il s'agit de "glacier-cmd".

L'installation (et l'utilisation) de "glacier-cmd" ne pose pas vraiment de problème, mais j'ai quand même décidé de faciliter la tâche à ceux (celles) d'entres vous qui ont quelques petites difficultés avec la langue anglaise et/ou démarrer rapidement à partir d'un document de synthèse.

C'est parti ...

Ce how-to est basé sur l'utilisation d'une distribution Debian 6 "out of the box" sans particularité. Bien entendu aucune interface graphique n'est nécessaire (c'est d’ailleurs un peu l'objectif de ce how-to ...)

La première chose à faire est de s'assurer que Python est bien installé sur votre système.

Un petit "python -V" devrait vous retourner la version de Python installée

Dans le doute vous pouvez toujours lancer un "apt-get install python" ça ne peut pas faire de mal !

Il faut ensuite passer à l'installation de "Git" (qui vous permettra de faciliter l'installation de "glacier-cmd")

apt-get install git

On récupére ensuite l'intégralité de glacier-cmd avec une seule ligne de commande :

git clone https://github.com/uskudnik/amazon-glacier-cmd-interface.git

On entre dans le répertoire où ont été récupérées les sources

cd amazon-glacier-cmd-interface/

On installe un module supplémentaire pour Python nécessaire au lancement du script d'installation

apt-get install python-setuptools

Et on lance finalement le script d'installation

python setup.py install

On va ensuite créer un fichier de configuration pour glacier-cmd.

vi /etc/glacier-cmd.conf

Le fichier va ressembler à ça :


[aws]
 access_key=Identifiant de clé d’accès
 secret_key=Clé d’accès secrète

[glacier]
 region=us-east-1
 logfile=~/.glacier-cmd.log
 loglevel=INFO
 output=print

Pour récupérer (ou créer les clés AWS) il faut se connecter ICI

Ce fichier de conf va également vous permettre de sélectionner la zone géographique où seront hébergés vos données (les tarifs varient légèrement en fonction de ce paramètre : toutes les infos sont ICI ).

Les valeurs possibles pour "region" sont donc les suivantes :


us-east-1 pour : US - Virginia
us-west-1 pour : US - N. California
us-west-2 pour : US - Oregon
eu-west-1 pour : EU - Ireland
ap-northeast-1 pour : Asia-Pacific - Tokyo

On peut ensuite passer à l'utilisation de glacier-cmd. Les principales commandes sont les suivantes :

  • Pour créer un dépôt ("vault") de stockage (afin d'y déposer ensuite des archives)
    glacier-cmd mkvault <le_nom_de_votre_dépôt>
    
  • Pour lister les dépôts disponibles :
    glacier-cmd lsvault
  • Pour obtenir le contenu (liste des archives/fichiers) d'un dépôt (attention le résultat de cette commande ne sera disponible qu'après 4h d'attente ...)
    glacier-cmd inventory <le_nom_de_votre_dépôt>
  • Pour uploader une archive (fichier) au sein d'un dépôt :
    glacier-cmd upload <nom_de_votre_dépôt> <nom_du_fichier_a_uploader> --description "la_description_du_fichier"
  • Pour télécharger les archives (fichiers) contenues au sein d'un dépôt  :

    L'opération se déroule en deux temps:

    1) On lance une demande de récupération de l'archive avec la commande suivante :

    glacier-cmd getarchive <nom_de_votre_dépôt> <id_de_l'archive_à_récupérer>

    NB : On récupère l'id de l'archive avec la commande "inventory" (voir ci-dessus)

    2) Après environ 4h d'attente vous pouvez demander le téléchargement de l'archive avec cette commande :

    glacier-cmd download <nom_de_votre_dépôt> <id_de_l'archive_à_récupérer> --outfile <nom_du_fichier>

    Donc pour résumer une récupération "type" s'effectue en 8h : 4h pour obtenir le contenu du dépôt (avec les identifiants d'archives) puis 4h pour obtenir une archive prête à être téléchargée et enfin le temps nécessaire au téléchargement du fichier ! Mieux vaut ne pas être pressé ...

  • Pour obtenir la liste de jobs en cours (inventaire, récupération ...) :
glacier-cmd listjobs nom_de_votre_dépôt

Ce how-to n'a bien entendu pas vocation à être exhaustif. Si vous souhaitez découvrir l'intégralité des fonctionnalités proposées par glacier-cmd, je vous invite à consulter la documentation disponible ICI .

Dans un prochain billet, je vous présenterai une solution permettant d'automatiser le backup d'un serveur Linux vers Glacier ...