Cloud Providers : comparatif des VPS à petit budget

Après quelques années à louer des VPS chez différents hébergeurs, par curiosité ou par relative nécessité, je commence à connaître le marché et les progrès effectués par les uns et les autres au fil du temps. Sur ce blog, j'avais déjà évoqué Scaleway (filiale d'Iliad) ainsi que Hetzner. Si Scaleway ne m'avait pas laissé un souvenir impérissable, j'ai été très satisfait d'Hetzner durant les 8 mois où j'ai été client pour 4 serveurs, sans compter que peu après la rédaction de l'article, il était possible de louer du stockage supplémentaire (comme le font presque tous les fournisseurs actuellement).

Utilisant également OVH et DigitalOcean et ayant utilisé de nouveau Scaleway, j'ai pensé à réaliser un comparatif sur les offres de ces 4 prestataires concernant leurs VPS d'entrée de gamme (1 processeur virtuel et 2 Go de RAM) qui peuvent être suffisants pour débuter l'administration GNU/Linux, le développement en Python, ou encore faire fonctionner un petit serveur web ou multimédia. N'ayant pas été client à titre professionnel, je me base uniquement sur mon expérience personnelle sur ces diverses plateformes que j'ai pu arpenter pour certaines, en long, en large, et en travers.

Présentation

OVH est probablement le plus connu des 4 puisqu'il est français et principalement basé à Roubaix. Scaleway est une filiale d'Iliad et auparavant de Online.net ; désormais Online et Scaleway ont fusionné. Hetzner est un hébergeur allemand, proposant diverses solutions un peu plus rares, comme la location de Storage Boxes (partages SFTP / Samba accessibles en ligne) ou du Nextcloud en SaaS. Enfin, DigitalOcean est une société américaine qui a connu (et connaît toujours) un développement relativement rapide de son activité et de sa présence physique sur les différents continents.

Tarification

OVHHetznerScalewayDigitalOcean
DénominationVPS Cloud 2016CX11DEV1-SStandard
Prix par mois8,99 €2,99 € TVA incl.2,99 €8,90 € (10 $)
vCPU1121
RAM2 Go2 Go2 Go2 Go
Stockage25 Go20 Go20 Go50 Go
Bande passante100 Mbps1 Gbps max.100 Mbps1 Gbps max.
TraficIllimité20 To sortantsIllimité2 To sortants
Snapshot4,99 € / mois0,01 € / Go / mois0,02 € / 50 Go / mois0,05 € / Go / mois
Sauvegarde7,99 € / mois20% prix mens. / moisn/a20% prix mens. / mois

Sur le papier, Hetzner est le moins cher puisque pour moins de 3€ par mois TVA incluse, il est possible d'avoir un VPS. Cependant, en incluant la TVA, Scaleway offre un deuxième cœur sur un processeur récent, ce qui n'est pas négligeable.

Ces prix peuvent s'expliquer par le positionnement commercial : Hetzner cherche à se développer et acquérir de nouveaux clients, avec une branche cloud qui a ouvert il n'y a pas si longtemps ; Scaleway se présente avant tout comme un partenaire des développeurs, où l'on créé ses laboratoires et environnements de développement, plutôt qu'où l'on bâtit son infrastructure de production. DigitalOcean et OVH sont à l'opposé des deux autres : une approche bien plus professionnelle qui se ressent au niveau des tarifs.

Performances

J'ai appliqué le même protocole de tests de performances pour ces 4 serveurs virtuels : deux tests d'écriture sur disque (un pour des petits fichiers, un pour des gros fichiers), plusieurs tests de performances réseau (speedtest-cli) et un dernier concernant le processeur (sysbench). Tous les VPS ont été installés sous Ubuntu 18.04 LTS.

Processeurs

Les CPU utilisés ne sont pas les mêmes en fonction des VPS. En utilisant cat /proc/cpuinfo, j'ai pu obtenir quelques informations :

  • OVH utilise des Intel Core ;
  • Hetzner utilise des Intel Xeon Skylake ;
  • Scaleway utilise des AMD EPYC 7281 ;
  • DigitalOcean utilise des Intel Xeon E5-2650L (Haswell).
Un sysbench a été exécuté en utilisant tous les threads disponibles sur le VPS.

Scaleway obtient le plus gros score sur ce bench grâce à son processeur récent et ses 2 cœurs ; DigitalOcean termine bon dernier à cause de son processeur ancien. Si la différence est marquante sur un test simple, les performances réelles dépendront de l'application exécutée.

Réseau
De multiples speedtest ont été réalisés sur des emplacements différents et une moyenne a été calculée.

Les résultats surprenants d'OVH s'expliquent par la limitation volontaire à 100 Mbps du VPS. Pour les autres, les débits étaient nettement plus fluctuants mais la moyenne s'établit naturellement au-dessus. Si Hetzner et DigitalOcean offrent des débits élevés, cela se paye au prix d'un trafic limité à 20 To pour le premier et 2 To pour le second. Les VPS chez DigitalOcean et OVH ont été loués au Royaume-Uni, Scaleway sur le datacenter parisien, le VPS Hetzner étant localisé en Allemagne.

Disque
Un test d'écriture de plusieurs fichiers de plus d'1 Go ainsi qu'un test d'écriture d'une dizaine de milliers de petits fichiers de quelques Ko ont été menés.

DigitalOcean rattrape ses performances CPU plus faibles sur le papier par un temps d'écriture sur disque très faible par rapport à la concurrence. Je soupçonne également OVH de faire du throttling afin de conserver un niveau de performance égal entre "locataires" d'une même unité de stockage, d'où le score plus élevé que la moyenne.

En pratique

OVH

L'interface entièrement en français d'OVH n'est pas des plus modernes ni des plus légères. Pour cause : elle n'est pas dédiée au cloud et n'en adopte pas la philosophie de fonctionnement. Sur les petits modèles, pas de tarification à l'heure, peu de flexibilité concernant les fonctionnalités de sauvegarde, tout se paye au mois. De multiples localisations sont possibles, en Europe comme sur le continent Américain ou en Asie. Il est possible de recourir à un firewall sur IP afin de sécuriser son serveur ; plus pratique qu'iptables pour les néophytes. Malgré son prix relativement élevé pour les caractéristiques, rien ne semble vraiment différencier OVH de la concurrence sur cette gamme, cependant la fiabilité sans faille ainsi que la réactivité du support et les nombreux tutoriels disponibles sur le site sont de sérieux arguments. Le côté simple de la location du serveur, sans véritable approche d'une vision flexible comme chez Scaleway par exemple et la tarification au mois sans surprise sont également rassurants. L'évolutivité n'est pas oubliée puisque l'on peut upgrader et downgrader son serveur depuis l'interface. Si OVH se concentre beaucoup sur des produits et offres généralement plus chères, le "petit" VPS bénéficie du même sérieux... ce qui se ressent sur le prix. Un choix avant tout à faire pour la sérénité de fonctionnement et la simplicité d'usage.

Scaleway

Bien qu'intégralement en anglais, l'interface de Scaleway est simple et rapide. Tout est compréhensible et la flexibilité semble être le maître mot pour déployer de multiples VM, soit à partir d'ISO standards d'OS GNU/Linux, ou à partir de snapshots réalisés, ou encore depuis le marketplace. Pour l'instant, deux sites sont proposés : Paris et Amsterdam. Attention car certains serveurs ne sont disponibles que sur un seul site et certains types de serveurs sont fréquemment en rupture de stock. Scaleway propose également des serveurs fonctionnant avec des processeurs ARM. Le gros bémol de Scaleway est son approche "en perpétuelle évolution". Ce qui peut être une qualité peut s'avérer être un défaut : serveurs qui s'installent mal, règles de pare-feu sur IP qui bloquent complètement le serveur au point d'avoir à le redémarrer pour retrouver la main et disponibilités parfois aléatoires... rien n'a spécialement changé depuis l'année dernière où j'essayais Scaleway pour la première fois avant de jeter l'éponge après 2 semaines. Cependant, pour un usage ponctuel mais avancé Scaleway est un excellent choix pour son rapport prix/performances !

Hetzner

Jusqu'à il y a peu un outsider, Hetzner affiche un rapport prix/performances excellent. L'interface en anglais est très proche de celle de DigitalOcean et en reprend les mêmes qualités : simplicité et rapidité. La qualité de service ne souffre d'aucun reproche : la création des serveurs est rapide, la fiabilité est réelle. Sans être aussi orienté "technologie" que Scaleway, Hetzner propose de nombreuses ISO et applications à installer sur le VPS. Sans supplément de coût et moyennant une clef de licence à configurer post-installation, il est même possible de déployer en quelques clics un serveur Windows ! Seul le trafic sortant limité à 20 To et l'absence de firewall sur IP peuvent jouer en la défaveur d'Hetzner. Si cela n'est pas rédhibitoire, Hetzner est un choix tout à fait recommandable grâce à ses multiples datacenters situés en Allemagne et en Finlande.

DigitalOcean

DigitalOcean est probablement le meilleur compromis entre OVH et Hetzner. En reprenant la simplicité d'Hetzner et le professionnalisme d'OVH, DigitalOcean offre énormément de possibilités ; qu'il s'agisse de VPS (appelés droplets), mais aussi d'instances de bases de données ou d'espaces de stockage d'objets. Tout comme OVH, DO met à disposition une belle base de connaissances pour se faire la main sur les divers environnements proposés. Firewall sur IP, stockage supplémentaire, load balancing, déploiements Kubernetes, création d'images... tout ou presque est possible peu importe son niveau de compétences. Il est dommage que la tarification soit dans le haut du panier au regard des performances processeur des petites instances mais elle se justifie aisément par la qualité de service et l'intégration complète des divers outils proposés ; le succès de DigitalOcean se comprend aisément !

Et au final ?

Il n'est pas vraiment possible pour moi de départager ces plateformes, tant elles ont chacune leur qualités et leurs défauts, qu'elles évoluent rapidement, et surtout, que leur appréciation est avant tout une question de besoins. Pour un usage purement personnel de tests / apprentissage / curiosité, Hetzner est parfait : sa simplicité et la clarté de sa tarification - douce de surcroît - permettent de faire un premier pas dans le monde des serveurs. Pour un peu plus de possibilités en restant dans le même scope mais avec un côté "laboratoire à expériences" assumé, Scaleway est tout indiqué. Pour un usage plus pérenne et avancé, DigitalOcean ainsi qu'OVH répondent présents. La flexibilité et les possibilités pour l'un, la tarification au mois, l'interface en français et la qualité globale de service (tutoriels, support, infrastructures) pour l'autre. Le meilleur choix à faire est celui qui correspond à vos besoins ! Pour l'instant, mon cloud personnel est basé chez DigitalOcean... que j'ai rejoint après quelques mois chez OVH... après 8 mois chez Hetzner, pleinement satisfait, mais la curiosité l'emportant, j'ai fini par migrer vers un autre service. Combien de temps avant la prochaine migration ?

J'ai testé (pas longtemps) Nextcloud

NextCloud, c'est le fork d'ownCloud, qui se veut être une plateforme collaborative de stockage et partage de fichiers dans le nuage.

Utilisant au quotidien OneDrive et iCloud, il m'était impossible de ne pas finir par essayer Nextcloud pour avoir un espace de sauvegarde de mes deux autres services mais hébergé par mes soins. Les arguments avancés par Nextcloud sont plutôt flatteurs : c'est un logiciel libre, les données sont auto-hébergées et peuvent être encryptées, les clients sont disponibles pour quasiment tous les OS usuels, que ce soit desktop ou mobile.

Je me documente sur les configurations nécessaires, et monte sur un petit VPS (1 core Xeon et 2 Go de RAM, suffisant pour réaliser des tests) une distribution Ubuntu 18.04 LTS et me lance pour l'installation de Nextcloud. Plutôt bien documentée me dis-je, avant de tomber sur mon premier couac - et il va y en avoir un paquet, sans mauvais jeu de mots - : l'installation par snap ne fonctionne pas et n'opère aucune modification sur mon système, je dois donc installer tous les paquets à la main. Admettons.

J'installe donc Apache, mariaDB et php conformément à ce qui est indiqué. En suivant scrupuleusement la documentation, j'arrive donc avec une base de données qui n'est pas configurée et un Apache incapable d'exécuter le moindre bout de code php (en cause : libapache-mod-php qui visiblement ne fonctionne pas, j'ai dû utiliser php-fcm). Passionnant ; je dois donc me rendre sur divers sites ou faire appel à mes connaissances perdues d'Apache pour réussir à faire fonctionner php. La configuration de mariaDB/MySQL ne pose pas de problèmes, il faut simplement se souvenir de finir le déploiement pour configurer un mot de passe root, puis créer un user lambda sur le SGBD pour lui donner les privilèges sur la future base nextcloud. Après quelques heures de perdues, j'arrive enfin sur la page d'accueil, qui m'indique qu'il me manque encore des modules php. L'installation et la configuration d'Apache prend quelques secondes et je peux ENFIN finir l'installation de Nextcloud, mo gwai !

Je me rends donc dans les menus et tombe sur des avertissements de sécurité et de conformité par rapport à des best practices. Je dois sécuriser un peu mieux mon infrastructure, changer quelques paramètres dans Apache et php pour rendre l'utilisation de l'outil plus fluide. Si les réglages propres à php se font facilement, les changements dans les configurations de Nextcloud sont bien plus anarchiques. Selon la documentation, je devais modifier le fichier de configuration de Nextcloud pour y définir proprement ma racine web, et relancer le script de vérification d'intégrité. Je suis donc toujours la documentation, modifie proprement ma racine web, définit les IP seules autorisées à se connecter, et relance le script de vérification d'intégrité.

Grave erreur. Très grave erreur. Maintenant, je n'ai plus accès du tout à mon Nextcloud. Non pas car mon IP n'est pas reconnue (en fait, le filtrage par IP dans la configuration ne marche pas du tout, peu importe mon IP j'avais accès à la plateforme, excellent) mais j'arrive directement sur l'arborescence des répertoires d'Apache comme si il n'y avait plus d'index.php ; je ne peux même pas fermer ma session. Changement de navigateur, impossible de me connecter : c'est déjà ça, personne à part moi grâce à ma session active ne peut parcourir le contenu des répertoires. Je cherche donc à faire machine arrière et à remettre la valeur par défaut dans le fichier de configuration concernant mon adresse web : impossible d'exécuter le script de vérification d'intégrité car il ne reconnaît pas l'URL d'origine! Du coup, je me retrouve avec un Nextcloud complètement cassé et inutilisable. J'interroge les forums, j'ai l'impression d'être le seul à utiliser Apache et pas nginx. Finalement, il a fallu que j'aille sur la documentation d'une précédente version de Nextcloud pour y trouver la bonne configuration à donner au site virtuel pour que cela fonctionne. Intéressant.

Et, ça fonctionne ! Je n'ai plus d'avertissements de mauvais réglages - enfin presque, car visiblement mon infrastructure n'est toujours pas bien sécurisée malgré le suivi de la documentation et la vérification d'intégrité, les hash ne sont pas identiques entre ce qu'il veut et ce que j'ai. Visiblement je ne suis pas le seul et j'adopte la bonne vieille méthode qui consiste à tout claquer sous le tapis car j'ai autre chose à faire que de tenter de débugger moi-même, j'aimerais pouvoir vraiment me servir de l'outil, et je me suis dit que je regarderais plus tard : je décide donc de shunter le check d'intégrité comme conseillé sur les forums (sic).

Plutôt satisfait d'avoir un peu lutté pour arriver à quelque chose qui fonctionne, je configure donc l'application, y ajoute 2 ou 3 add-ons, configure l'encryption des données et installe le client sur macOS. Je commence donc par uploader environ 5 Go de données... plutôt devrais-je dire 50 Mo de données car je me heurte bien rapidement à un souci de synchronisation : certains fichiers coincent et bloquent complètement le transfert (pas possible de les zapper pour au moins transférer le reste). Certains fichiers font planter la connexion. Rien de particulier dans les logs, seulement que la connexion se ferme et que les fichiers peuvent pas être écrits. Admettons. Je relance Apache, aucun succès, je relance le serveur complet, aucun succès. Je tente de renommer en local (sur mon Mac, s'entend) les fichiers et le répertoire, aucun succès. Je décide donc de tenter de supprimer les fichiers du serveur : impossible. Que ça soit tout le répertoire ou même chaque fichier à la main : impossible, "erreur inconnue". Je tente donc de passer outre l'interface web et tente de passer par WebDAV. Je prends donc le lien WebDAV disponible sur la page d'accueil : celui-ci ne fonctionne pas. Encore une fois, je dois aller fouiner dans la documentation d'une ancienne version de Nextcloud pour modifier le lien WebDAV afin qu'il fonctionne. J'accède donc à mes répertoires et tente de supprimer ceux qui posent problème. Impossible : verrouillé par HTTP. Intéressant, ça.

Agacé, je décide donc d'envoyer ce serveur à la poubelle, non sans constater par ailleurs que les fichiers que j'avais uploadé et qui devaient être encryptés lors de l'envoi étaient bel et bien lisibles en clair sur le système de fichiers de l'OS. Super.

Me disant que je suis peut-être une quiche et que j'ai été trop vite sur cet outil, que j'ai loupé quelque chose lors de l'installation, je décide de donner une nouvelle chance à ce produit qui semble pourtant être pétri de qualités lorsqu'il fonctionne. Je jette donc mon dévolu chez un prestataire qui propose de l'hébergement Nextcloud, avec une instance déjà installée clef en mains, où il ne reste juste qu'à configurer ses utilisateurs, ses répertoires et add-ons. Je signe donc pour une offre d'un mois, et accède au même portail que celui que je viens de détruire. Je me connecte sans erreur, pas de message par rapport à l'intégrité (j'avoue que l'idée que les tests aient été désactivés m'a bien effleuré l'esprit), je commence à configurer mes clients et repars pour le même upload d'environ 5 Go de documents. Si le transfert s'effectue apparemment proprement, j'ai quand même de belles erreurs dans le client de synchro qui vire au rouge sur des erreurs d'écriture de clés primaires pour un bon paquet de fichiers. Au final, j'ai un message comme quoi la synchronisation est OK. C'est sans doute psychologique, mais quand on me dit que tout s'est bien passé en rouge et pas en vert ou dans une couleur neutre, j'y crois pas trop. Je regarde rapidement, tout à l'air d'y être... le lendemain, une nouvelle synchro se fait suite à modification et il upload (remplace ?) des fichiers auxquels je n'avais pas du tout touché : est-ce des fichiers qu'il avait oublié la veille ou bien a-t-il remplacé ces fichiers ?.. synchronisation qui ne se fait pas sans son lot d'erreurs SQL. Le test de la petite synchronisation ayant à peu près fonctionné (à vrai dire, je n'avais aucune confiance), je cherche à copier un gros répertoire d'environ 300 Go d'images ISO, de sauvegardes en tout genre. Bien évidemment, ça n'a pas loupé, l'application a commencé à envoyer les fichiers avant de lamentablement se noyer dans diverses erreurs de fichiers non accessibles, de serveur ayant rejeté la requête et d'autres joyeusetés SQL.

Je décide alors de jeter complètement l'éponge sur ce produit qui pourtant, a de beaux arguments, semble avoir de belles fonctionnalités et sur le papier, facile à installer et à déployer, mais desservi par une documentation incomplète, des forums où les participants et contributeurs semblent être complètement perdus dès qu'on sort des erreurs de configuration basique d'Apache ou de php ou de firewall, et surtout, un besoin de tout régler au millimètre près pour avoir un fonctionnement "propre". Dommage, j'ai même pas pu vraiment profiter de Nextcloud.

Mes premiers pas sur Azure, première partie

Comme vous le savez peut-être déjà, je suis assez captivé par le Cloud en général ; si j'ai touché à quelques produits de petits acteurs, j'ai également utilisé Azure il y a de cela quelques années - 2012 pour être plus précis. Six ans plus tard, je remets le couvert, avec l'intention de creuser plus profondément et de pouvoir comprendre la philosophie, le fonctionnement et les possibilités ouvertes par ce produit qui s'annonce impressionnant. Je vais donc publier mes notes et mon ressenti à ce sujet, en plusieurs fois, qui détailleront ma découverte du produit de Microsoft ; j'espère retransmettre ma curiosité et l'excitation ressentie à l'usage de cette solution et que cela vous donnera envie d'essayer.

Et essayer, rien de plus facile, possédant un crédit de 170 euros valable 30 jours sur simple inscription. Une inscription qui demande quelques informations personnelles, dont un numéro de téléphone valide ainsi qu'un numéro de carte bleue. Mais Microsoft assure qu'elle ne sera pas débitée sans abonnement Azure ou mon consentement après que le crédit d'essai soit épuisé ou expiré.

Premiers pas sur l'interface, c'est quelque peu déroutant.

Les objets sur la gauche, et le tableau de bord au milieu, faisant la part belle aux raccourcis et aux ressources. En fait, les ressources sont les différents objets qui constituent une infrastructure dans Azure. Par exemple, lorsque je vais créer une machine, elle sera découpée en plusieurs ressources : une machine virtuelle, un ou plusieurs disques, une (ou plusieurs) adresses IP, réseaux virtuels, etc.

Droit au but, je vais créer une ressource, une machine virtuelle toute simple, un Windows 10, pour me déployer un bureau. Je clique donc sur le lien de création, et je dois choisir ce que je souhaite installer.

En fait, Azure permet de monter presque tout. Si l'on cherche à développer une application web, il procèdera à la création d'une machine frontend web, une machine backend, un serveur SQL, etc.

C'est parti, je me lance, création d'une VM Windows 10.

La VM fait donc partie d'un pool de ressources (qui, comme je l'ai expliqué plus haut, n'a rien à voir avec un pool de ressources de calcul), et est déployable dans de nombreux datacenters. De nombreuses images sont déployables, dans le cadre de Windows 10 il est même possible de choisir son niveau de mise à jour. Le principal hic concernant la configuration de base est la taille de la VM. En effet, les dénominations sont quelque peu complexes, bien que la tarification estimée au mois soit affichée :
Il existe donc des offres "Standard" et "de base" (ça a quand même l'air relativement similaire), des familles de calcul optimal et d'autres d'usage général... des machines avec un stockage temporaire (je reviendrai dessus plus tard), etc. Il y a le choix pour vraiment obtenir une configuration comme on le désire, mais c'est quand même déroutant au départ. Au moins la tarification mensuelle est claire, même si au final elle est calculée à la minute de fonctionnement. Je pars pour une machine B1ms : 1 coeur virtuel et 2 Go de mémoire vive, le minimum.

La suite : les disques.

Par défaut, les machines Windows ont un disque système calibré à 128 Go, et en fonction de la taille de la machine commandée, un disque supplémentaire "temporaire". Le disque temporaire est un disque qui est monté vierge à chaque extinction complète de la VM (lorsque les ressources sont libérées côté Azure, j'y reviendrai également). Il ne peut donc pas servir pour du stockage usuel, mais pourquoi pas pour des fichiers temporaires ou pour le fichier d'échange. Pas bête. Naturellement, il est possible d'ajouter des disques supplémentaires. La technologie des disques est laissée au choix de l'utilisateur, avec bien évidemment des performances supérieures pour les SSD, avec un prix en rapport.

La configuration de mise en réseau permet de définir comment la machine va être raccordée aux autres machines que l'on possède et éventuellement à internet.

L'adresse IP publique est par défaut dynamique, en sachant qu'un nom DNS fixe peut être défini (quelque peu long puisque pour une VM située en France, le sous-domaine est francecentral.cloudapp.azure.com). Il est cependant possible d'attribuer une adresse IP publique fixe.

Je dois avouer que j'ai pas encore trop saisi l'intérêt de la partie Administration, peut-être que ça viendra plus tard ; cela est sans doute utile dans le cadre de déploiement d'applications ou de maquettes de tests. Ayant monté cette VM Windows 10 pour me faire un bureau à distance avec des applications standards, je pense pas vraiment avoir besoin de cette feature.

La configuration de l'invité ne fonctionne pas pour les OS Windows car il s'agit d'un traitement CloudInit, cela concerne donc plus les machines fonctionnant sous GNU/Linux. Les étiquettes permettent de mettre des libellés sur les machines comme le nom l'indique bien. Pratique pour retrouver ses ressources dans de grands environnements.

Et enfin, au moment de la vérification de la configuration, juste avant de créer la ressource, on obtient la tarification définitive, dépendant de la taille de la machine, des disques, des options réseau ainsi que de l'emplacement où se situera la VM. En fonction des datacenters le prix peut varier du simple au double presque, ce qui n'est pas négligeable. A noter qu'en Europe de l'Ouest, l'Allemagne est le pays où la tarification horaire est la plus faible, bien que nous ne soyons pas si mal lotis en France.

Je valide la création. C'est en cours :

Puis quelques minutes plus tard, la création est terminée. Dans l'écran des ressources, je vois donc tout ce qui a été créé avec ma VM :

J'obtiens donc une vue toute éclatée de tous les éléments comportant la VM, que je peux ensuite parcourir pour obtenir plus de détails. La vue de la VM reste la plus complète avec une vision d'ensemble de celle-ci. Il est possible de s'y connecter en RDP avec des liens tout prêts, fonctionnant avec Windows mais aussi le client RDP disponible sous macOS.
Sur cette page, je peux démarrer ou arrêter la VM ; sachant qu'un arrêt sur cette page arrêtera la tarification de la VM. En effet, les ressources sont complètement désallouées, ce qui signifie qu'il faut un peu plus de temps qu'un simple boot pour démarrer la VM. Si cela peut être problématique pour des VM supposées démarrer quotidiennement et que l'on éteint pour des économies, dans un cadre personnel ou pour se monter un environnement de développement ou une maquette, cela n'a rien d'aberrant.
La ressource de l'IP publique permet de gérer la sécurité et le pare-feu.
A noter que lors de la création de VM, il est demandé si l'on souhaite par exemple autoriser le RDP entrant ou le SSH. Il est toujours possible d'accéder bien évidemment aux fonctionnalités de pare-feu depuis l'OS invité.
Parlons maintenant ce qui peut fâcher : la facturation. Pour le coup, tout est plutôt clair et limpide. En se rendant dans la partie facturation du portail Azure, les chiffres sont exposés et tous les coûts par ressources sont éclatés. Par exemple, ce "camembert" permet de comprendre le coût de chacun des éléments de la VM et d'identifier les coûts de multiples adresses IP pour une machine, ou encore de multiples disques.
Je vois donc qu'au bout de quelques jours, le stockage m'a coûté 1€, la ressource pour la VM (finalement 2 coeurs et 4 Go de RAM) 72 centimes et l'allocation d'IP sur le réseau 32 centimes. La partie droite sur le schéma permet de budgéter sur le mois les coûts. Plus de précision est évidemment possible, que ce soit par pool ou par type de ressource.
Cela me semble déjà pas mal pour un premier aperçu. Il existe pas mal d'autres pages par rapport à la VM, notamment tout l'aspect sauvegarde, supervision et automatisation. J'essayerai d'aborder cela prochainement dans un deuxième billet avec un peu plus de recul, en mettant en situation le fonctionnement d'une infrastructure de petite PME (2 contrôleurs de domaine - si possible en Windows Server 2019 si il est disponible d'ici là... - et quelques stations Windows 10) pour gérer la partie réseau ainsi que la séparation dans un autre pool.

J'ai testé Hetzner Cloud, un service (presque) parfait

Cela fait environ une semaine maintenant que je me sers du cloud chez Hetzner pour héberger 4 serveurs virtuels (3 sous GNU/Linux et un sous Windows). Je ne suis pas nouveau sur ce genre de plateformes puisque j'ai essayé Scaleway (Online) il y a quelques temps et que j'utilise un VPS chez OVH pour héberger les fichiers de ce blog.

Hetzner propose donc plusieurs serveurs Cloud, sous cette dénomination, comme chez la concurrence, il s'agit de machines virtuelles (instances KVM généralement) avec des limitations de ressources définies et un espace de stockage limité. Dans mon cas, j'utilise les offres CX11 et CX21 (respectivement à 3 et 6€ par mois TTC environ), m'affectant 1 et 2 cœurs, 2 et 4 Go de RAM, 20 et 40 Go de stockage SSD, avec une limite mensuelle de trafic de 20 To (qui ne concerne que le sortant, par ailleurs). On peut aller jusqu'à 8 cœurs, 32 Go de RAM et un stockage de 240 Go. Au final, 5 configurations différentes couvrent à peu près tous les besoins ; il est possible de remplacer le SSD pour un stockage en réseau pour le même prix. Seul accroc : il n'est pas possible d'augmenter le stockage sans lier CPU et RAM avec des disques additionnels.

Hetzner met l'accent sur le travail collaboratif ; en effet, chaque serveur peut être lié à un projet, qui permet d'inviter d'autres personnes pour gérer les machines sans avoir à partager le même compte. La facturation à l'heure est très appréciable, bien qu'à la différence de Scaleway, un serveur éteint est quand même facturé (mais à la différence de ce dernier, il n'y a pas de délai ou de process pour le rallumer). L'interface est plutôt claire, la création d'un serveur se fait en quelques instants : localisation du serveur (Allemagne ou Finlande), OS de base (il y a pas mal de choix, c'est un grand point fort d'Hetzner, j'y reviendrai plus tard), configuration et options.

Une fois le serveur créé, on a accès à la console du serveur, le coût engendré par celui-ci pour le mois en cours et le trafic et les outils habituels. Les graphiques sont clairs, à l'inverse des fonctionnalités de sauvegarde et de snapshot qui font un peu doublon. Les sauvegardes (20% du prix mensuel du serveur) sont automatisées de manière journalière avec une rétention de 7 sauvegardes en fonction d'un créneau défini à l'avance, tandis que les snapshots sont déclenchés par l'utilisateur quand il le souhaite (0,012€ par mois et par Go occupé). Pour un usage hors production et purement découverte/personnel, il y a peu de différence entre les deux, au final on prendra le moins cher. La sauvegarde peut être convertie en snapshot, et ce dernier peut servir d'image pour build un nouveau serveur personnalisé.

En parlant de build, la liste des OS fournie par Hetzner peut paraître courte sur la page de création du serveur mais il est possible de monter des ISO d'autres systèmes. C'est ici un des points forts d'Hetzner, car non seulement il est possible d'installer diverses distributions Linux, mais en plus d'installer Windows, sans surcoût ! Evidemment, la licence n'est pas comprise mais la proposition a le mérite d'exister. Windows est disponible dans plusieurs langues, et en versions 2012 et 2016.

Deux IP sont fournies avec chaque instance, une v4 et une v6. Il est possible de prendre une adresse IP "fixe" que l'on pourra allouer aux machines de notre choix pour quelques deniers supplémentaires. Il est possible de suivre le trafic consommé de la machine, bien qu'avec 20 To sortant mensuels, on soit relativement large de ce côté.

L'autre différence notable avec Scaleway, c'est le type de processeur. En effet, Scaleway embarquait des Atom Avoton dans ses hôtes. Hetzner propose des Xeon, de génération Skylake. Bien évidemment, les performances réelles sont bien supérieures.

Les performances disque et réseau sont à l'avenant : ça dépote, et la bande passante suffira à satisfaire bien des usages.

En une semaine, je n'ai encore eu aucun souci de disponibilité des serveurs. Les réinstallations se sont réalisées très rapidement, et les fonctionnalités de sauvegarde et de restauration se sont passées sans encombre. L'installation de Windows également, ce qui est plutôt surprenant étant donné qu'il est clairement dit qu'aucun support ne sera fourni et que la fonctionnalité est quelque peu "expérimentale". A ce jour, aucun dysfonctionnement n'est à déplorer, ce qui encore une fois, marque une différence avec mon expérience chez Scaleway avec des machines indisponibles sans raison à peine 24 heures après leur création.
Pour faire un petit bilan, Hetzner propose une offre très cohérente à tous les niveaux : prix, interface, large choix de configurations et OS, performances et disponibilité. Seul le support en allemand mais qui tend à se généraliser en anglais à base de wiki et l'impossibilité de commander plus d'espace disque sans lier CPU et RAM pourrait rebuter, mais vu le reste...

J'ai testé Scaleway, la "Disruptive Cloud Platform"

Dans l'optique de repenser ma plateforme Cloud personnelle et de changer de serveur car désormais surdimensionné par rapport à mes besoins, j'ai essayé Scaleway, qui est une filiale d'Online, qui propose des serveurs virtuels et physiques à des prix plutôt intéressants avec une interface simple et mettant en avant la flexibilité et la rapidité.

L'offre de Scaleway est plutôt simple à comprendre :

  • Les gamme Start, Pro et ARM sont basées sur des serveurs entièrement virtuels, cela signifie que les coeurs et RAM sont en partage avec d'autres utilisateurs sur le même serveur physique ;
  • La gamme BareMetal représente les serveurs physiques dédiés.
J'ai testé la gamme Start avec 2 types de serveurs :  le XS (1 core et 1 Go de RAM, pour 25 Go de disque) et M (4 cores, 4 Go de RAM et 100 Go de disque de base). 
Au niveau des CPU, il s'agit d'Intel Atom C3955 ; peu performants en soi par rapport à ce que l'on peut trouver dans des serveurs mais suffisants pour bien des usages et permettant d'offrir un prix plancher puisque le XS coûte 2,40€ par mois TTC maximum, la facturation étant à l'heure, un serveur qui est détruit dans le mois ne coûte que les heures où il a fonctionné. 
Concernant le stockage, c'est déjà un peu plus flou : il y a la notion de LSSD et de DSSD. Tous les disques chez Scaleway sont des SSD ; la différence entre le L et D SSD réside dans l'emplacement dudit stockage : le LSSD est en fait une allocation disque sur une baie de stockage en réseau, donc non-physiquement présente sur le serveur ou l'hyperviseur hébergeant votre machine, tandis que le DSSD est bel et bien un disque intégré au serveur. Ce qui est dommage, c'est que seul le plus gros serveur BareMetal comprend un DSSD ; pour le reste on est obligé de passer par la case disque réseau. Les performances sont cependant au rendez-vous, mais il faut garder à l'esprit qu'en fonction du noeud sur lequel notre serveur est installé cela peut fluctuer :
Seul le plus petit modèle héberge un LSSD de 25 Go, les autres serveurs offrent au minimum 50 Go de disque, extensibles par tranche de 50 Go, soit sur le même disque, soit en disque supplémentaires si l'on souhaite plusieurs points de montage. Dommage que la partition système ne soit pas extensible et soit figée à 50 Go. Par ailleurs, cela n'est pas précisé mais certains types de serveurs ont une limite de disques rattachables en nombre mais pas en taille ; si 1 To est le maximum de stockage pouvant être accolé à un serveur, au final sur un S on ne peut attacher qu'un disque, sur un M il n'est pas possible de rattacher un troisième disque, et ce qui est quelque peu idiot est qu'une fois un disque rattaché il n'est pas possible d'en augmenter sa taille (quelle raison, étant donné que ce ne sont que des allocations sur une baie ?)...
Le concept de flexibilité chez Scaleway est plutôt important car au final, le serveur n'est qu'un objet au même titre que les IP ou le stockage ou les images de déploiement ; on peut monter ou démonter nos LSSD sur n'importe quel serveur, supprimer un serveur sans perdre le stockage associé, etc. L'interface de gestion est plutôt claire et agréable à utiliser, même si potentiellement déroutante au départ pour qui ne parle pas anglais et/ou est néophyte. Quelque part le prix plancher des offres se paye par le support limité malgré une documentation relativement fournie par rapport aux services offerts.
La gestion d'un serveur est plutôt minimaliste mais a le bon goût d'offrir un accès console, permettant quand même de maniper au cas où le SSH est par terre ou bien que nous sommes connectés depuis une IP habituellement rejetée par SSH. On retrouve le nom du serveur, son emplacement géographique (Paris ou Amsterdam), son IP publique, son IP sur le réseau interne (qui change à chaque fois que vous éteignez ou rallumez votre serveur), et d'autres informations, y compris les disques. Par défaut, la connexion à un serveur se fait avec votre clé SSH renseignée dans votre compte.
La création d'un serveur est plutôt rapide, il doit se passer à tout casser 2 minutes entre le moment où l'on arrive sur la page de création et le moment où celui-ci est effectivement disponible :
On choisit la taille du serveur désiré, la distribution ou application pré-installée (par exemple WordPress, PrestaShop, OpenVPN...) ou encore un déploiement par rapport à une image que vous avez créé vous-même (et non pas un ISO personnalisé...) et c'est parti. Le choix de distributions comprend l'essentiel et se limite au monde GNU/Linux ; la virtualisation se base sur KVM et il n'y a pas de Windows disponibles.
Au niveau réseau, pas de grosse surprise, sur 300 Mbps annoncés :
Lorsqu'on souhaite éteindre un serveur, le stockage est déplacé de la baie de stockage vers des "archives" et le serveur n'est plus accessible immédiatement. Ensuite, lorsqu'on souhaite le rallumer, le stockage redescend vers la baie et les coeurs sont de nouveau alloués ; cependant il arrive que le processus de "rallumage" de serveur prenne du temps car les ressources ne sont pas disponibles ; il convient donc de laisser allumé le serveur 24/7 à moins de vraiment vouloir tirer jusqu'au bout la notion de facturation à l'heure... et pour rendre le serveur indisponible on pourra plutôt couper la patte réseau afin qu'il ne communique plus via la console intégrée.
Actuellement, il ne me reste chez Scaleway que le miroir du blog (basé sur un lighttpd tout simple) ; j'y avais 3 autres serveurs que j'ai fini par bouger ailleurs sur un hyperviseur basé sur Proxmox. En effet, la puissance un peu légère des processeurs pour faire fonctionner Plex et quelques autres applications était problématique, et la gestion du stockage méritait d'être améliorée car en total décalage avec la flexibilité annoncée et plutôt réelle du reste des éléments du cloud. En l'état, Scaleway est une très bonne plateforme pour y monter des serveurs peu critiques ou pour se monter des labos de tests ou encore une petite infrastructure cloud légère ; en gros pour des besoins particuliers. Pour un usage professionnel ou plus sérieux, d'autres fournisseurs me semblent plus adaptés.
Si je devais faire un bilan de mon expérience chez Scaleway en deux semaines :
  • Points forts : tarifs intéressants et à l'heure, rapidité de build d'un serveur, large panel de configurations matérielles, performances disques et réseau suffisantes dans une majorité de situations, flexibilité
  • Points faibles : gestion du stockage, support limité en version de base, interface uniquement en anglais, disponibilité de l'infrastructure lors de la remise en route d'un serveur incertaine.