Migrer de DigitalOcean vers Hetzner

• Une infrastructure de production à 1 432 $/mois a été déplacée vers un serveur dédié à 233 $/mois tout en changeant aussi de système d’exploitation, sans interruption de service
• Les 30 bases de données MySQL et 34 hôtes virtuels Nginx, ainsi que GitLab EE, Neo4J, Supervisor et Gearman, ont été recréés à l’identique sur le nouveau serveur, puis migrés via réplication en temps réel et synchronisation incrémentale finale
• Le point clé de la migration des bases de données a été la combinaison de mydumper·myloader en parallèle et de la réplication MySQL, avec correction des problèmes de schéma sys et de permissions apparus lors du passage de MySQL 5.7 à 8.0
• Le basculement s’est déroulé dans l’ordre suivant : réduction du DNS TTL, conversion du Nginx de l’ancien serveur en reverse proxy, puis modification groupée des enregistrements A, de sorte que les requêtes arrivant sur l’ancienne IP pendant la propagation DNS étaient toujours transmises au nouveau serveur
• Résultat : 1 199 $ économisés par mois, 14 388 $ par an, avec plus de CPU, de mémoire et de stockage, ainsi que 0 minute d’interruption

---

Contexte de la migration

• Dans le contexte d’une entreprise logicielle opérant en Turquie, la forte inflation et la faiblesse de la livre turque ont considérablement accru le poids des coûts d’infrastructure libellés en dollars
• Le coût mensuel de l’ancien serveur DigitalOcean était de 1 432 $, pour une configuration comprenant 192 Go de RAM, 32 vCPU, 600 Go de SSD, 2 volumes bloc de 1 To, avec sauvegardes incluses
• La nouvelle cible était un serveur dédié Hetzner AX162-R, avec AMD EPYC 9454P 48 cœurs 96 threads, 256 Go de DDR5 et 1,92 To de NVMe Gen4 en RAID1
• Le coût mensuel est descendu à 233 $, soit une économie de 1 199 $ par mois et 14 388 $ par an
• Il n’y avait pas de plainte concernant la fiabilité de l’ancien serveur ni l’expérience développeur, mais pour une charge de travail steady-state, le rapport prix/performance n’était plus raisonnable

Environnement d’exploitation existant

• La stack en production n’était pas un simple environnement de test, mais une véritable configuration de production
  • 30 bases de données MySQL, pour un total de 248 Go de données
  • 34 hôtes virtuels Nginx répartis sur plusieurs domaines
  • GitLab EE avec 42 Go de sauvegardes
  • Neo4J Graph DB exploité à hauteur de 30 Go
  • Supervisor pour gérer des dizaines de workers en arrière-plan
  • Utilisation de la file de tâches Gearman
  • Une application mobile en production pour plusieurs centaines de milliers d’utilisateurs
• Le système d’exploitation de l’ancien serveur était CentOS 7, déjà en fin de support
• Le système du nouveau serveur est AlmaLinux 9.7, une distribution compatible RHEL 9 et un successeur naturel à CentOS
• Cette migration n’était donc pas seulement motivée par les coûts, mais aussi par la sortie d’un système d’exploitation privé de mises à jour de sécurité depuis plusieurs années

Stratégie sans interruption

• Un simple changement DNS avec redémarrage des services n’était pas acceptable ; la migration a donc été menée en 6 étapes pour garantir l’absence d’interruption

• Étape 1 : installation de la stack complète sur le nouveau serveur

  • Installation de Nginx en le compilant depuis les sources avec les mêmes flags que l’ancien
  • Installation de PHP via le repo Remi, avec reprise des mêmes fichiers de configuration .ini que sur l’ancien serveur
  • Installation de MySQL 8.0, Neo4J Graph DB, GitLab EE, Node.js, Supervisor et Gearman, configurés pour reproduire le comportement existant
  • Tous les services ont été alignés sur le comportement de l’ancien serveur avant toute modification des enregistrements DNS
  • Les certificats SSL ont été copiés via rsync en transférant tout le répertoire /etc/letsencrypt/ depuis l’ancien serveur
  • Une fois l’ensemble du trafic basculé vers le nouveau serveur, un renouvellement forcé global des certificats a été effectué avec certbot renew --force-renewal

• Étape 2 : réplication des fichiers web via rsync

  • Environ 65 Go et 1,5 million de fichiers dans tout le répertoire /var/www/html ont été copiés via rsync sur SSH
  • L’option --checksum a servi à vérifier l’intégrité
  • Une synchronisation incrémentale finale a été effectuée juste avant le cutover pour intégrer les fichiers modifiés

• Étape 3 : réplication maître-esclave MySQL

  • Plutôt que d’arrêter les bases pour faire un dump puis une restauration, une réplication en temps réel a été mise en place
  • L’ancien serveur a été configuré comme maître, le nouveau comme esclave en lecture seule
  • Le chargement initial massif s’est fait avec mydumper, puis la réplication a démarré à partir de la position binlog exacte enregistrée dans les métadonnées du dump
  • Jusqu’au moment du basculement, les deux bases sont restées synchronisées en temps réel

• Étape 4 : réduction du DNS TTL

  • Un script a appelé l’API DNS de DigitalOcean pour réduire le TTL de tous les enregistrements A/AAAA de 3600 secondes à 300 secondes
  • Les enregistrements MX et TXT n’ont pas été modifiés
  • Ils ont été exclus afin d’éviter d’éventuels problèmes de délivrabilité liés au changement de TTL des enregistrements mail
  • Après une heure d’attente pour laisser l’ancien TTL expirer partout, le basculement pouvait être effectué avec une propagation ramenée à 5 minutes

• Étape 5 : conversion du Nginx de l’ancien serveur en reverse proxy

  • Un script Python a analysé les blocs server {} des 34 configurations de sites Nginx
  • Les configurations existantes ont été sauvegardées puis remplacées par des réglages de proxy pointant vers le nouveau serveur
  • Ainsi, pendant la propagation DNS, les requêtes arrivant encore sur l’ancienne IP étaient silencieusement relayées vers le nouveau serveur
  • Du point de vue des utilisateurs, il n’y avait aucune interruption visible

• Étape 6 : basculement DNS et arrêt de l’ancien serveur

  • Un script Python a appelé l’API DigitalOcean pour changer en quelques secondes tous les enregistrements A vers l’IP du nouveau serveur
  • L’ancien serveur a été conservé pendant une semaine en cold standby, puis arrêté
  • Pendant tout le processus, le service continuait à répondre soit directement, soit via le proxy, sans aucune fenêtre d’indisponibilité

Migration MySQL

• La partie la plus complexe de l’ensemble de l’opération a été la migration MySQL

• Dump des données

  • mydumper a été utilisé à la place du mysqldump standard
  • Grâce à l’export/import parallèle exploitant les 48 cœurs CPU du nouveau serveur, une opération qui aurait pris plusieurs jours avec mysqldump mono-thread a été ramenée à quelques heures
  • Les principales options utilisées comprenaient --threads 32, --compress, --trx-consistency-only, --skip-definer, --chunk-filesize 256
  • Le fichier metadata du dump principal enregistrait la position binlog au moment du snapshot
    • File: mysql-bin.000004
    • Position: 21834307
  • Ces valeurs ont ensuite servi de point de départ pour la réplication

• Transfert du dump

  • Une fois le dump terminé, il a été transféré vers le nouveau serveur via rsync sur SSH
  • Au total, 248 Go de chunks compressés ont été envoyés
  • L’option --compress de mydumper a contribué à améliorer la vitesse de transfert réseau

• Chargement des données

  • myloader a été utilisé
  • Les principales options étaient --threads 32, --overwrite-tables, --ignore-errors 1062, --skip-definer

• Problèmes lors du passage de MySQL 5.7 à 8.0

  • En raison de l’environnement CentOS 7, l’ancien serveur était resté bloqué sur MySQL 5.7
  • Avant la migration, mysqlcheck --check-upgrade a permis de vérifier la compatibilité des données avec MySQL 8.0, sans problème détecté
  • Le nouveau serveur a reçu la dernière version de MySQL 8.0 Community
  • Les temps d’exécution des requêtes ont nettement baissé sur l’ensemble des projets, l’article original l’attribuant au meilleur optimizer et aux améliorations d’InnoDB dans MySQL 8.0
  • Mais le saut de version a aussi causé des problèmes
    • Après l’import, la table mysql.user ne présentait que 45 colonnes au lieu des 51 attendues
    • Résultat : absence de mysql.infoschema et dysfonctionnements de l’authentification utilisateur
  • La première tentative de correction a consisté à exécuter les commandes suivantes
    • systemctl stop mysqld
    • mysqld --upgrade=FORCE --user=mysql &
  • La première tentative a échoué avec l’erreur ERROR: 'sys.innodb_buffer_stats_by_schema' is not VIEW
  • La cause était que le schéma sys avait été importé comme une table ordinaire au lieu d’une vue
  • La solution a consisté à exécuter DROP DATABASE sys; puis relancer l’upgrade
  • Après cela, tout s’est terminé correctement

Configuration de la réplication MySQL

• Une fois le chargement du dump terminé sur les deux serveurs, le nouveau serveur a été configuré comme réplique de l’ancien
• La commande CHANGE MASTER TO spécifiait l’IP de l’ancien serveur, l’utilisateur de réplication, le port 3306, MASTER_LOG_FILE='mysql-bin.000004', MASTER_LOG_POS=21834307
• Ensuite, START SLAVE; a été exécuté
• Presque immédiatement, la réplication s’est arrêtée avec une error 1062 Duplicate Key
• La cause était que le dump avait été réalisé en deux temps, et que des écritures étaient intervenues sur certaines tables entre les deux, si bien que le dump importé et la relecture du binlog tentaient d’insérer en double les mêmes lignes
• Pour corriger cela, la configuration suivante a été appliquée
  • SET GLOBAL slave_exec_mode = 'IDEMPOTENT';
  • START SLAVE;
• Le mode IDEMPOTENT ignore silencieusement les erreurs de clé dupliquée et de ligne manquante
• Toutes les bases de données essentielles se sont synchronisées sans autre erreur, et la valeur Seconds_Behind_Master est retombée à 0 en quelques minutes

Vérification avant le cutover

• Avant toute modification des enregistrements DNS, il fallait vérifier que tous les services fonctionnaient correctement sur le nouveau serveur
• La méthode utilisée consistait à modifier temporairement le fichier /etc/hosts sur la machine locale pour faire pointer les domaines vers l’IP du nouveau serveur
• Le navigateur et Postman envoyaient alors les requêtes vers le nouveau serveur, tandis que les utilisateurs externes continuaient d’accéder à l’ancien
• Les endpoints API, le panneau d’administration et l’état de réponse de chaque service ont été vérifiés
• Une fois tous les éléments validés, le cutover réel a été lancé

Problème de privilège SUPER

• Une fois la réplication maître-esclave totalement synchronisée, il a été constaté que des INSERT réussissaient sur le nouveau serveur alors que read_only = 1
• La cause était que tous les utilisateurs PHP des applications disposaient du privilège SUPER
• Dans MySQL, le privilège SUPER contourne read_only
• Le résultat de SHOW GRANTS FOR 'some_db_user'@'localhost'; a confirmé la présence du privilège SUPER
• La commande REVOKE SUPER ON *.* FROM 'some_db_user'@'localhost'; a été répétée pour 24 utilisateurs applicatifs au total
• Ensuite, FLUSH PRIVILEGES; a été exécuté
• À partir de là, read_only = 1 a correctement bloqué les écritures applicatives tout en continuant à autoriser la réplication

Préparation DNS

• Tous les domaines étaient gérés via DigitalOcean DNS, avec des serveurs de noms reliés chez GoDaddy
• La réduction du TTL a été scriptée contre l’API DigitalOcean
• Seuls les enregistrements A et AAAA étaient concernés
• Les enregistrements MX et TXT n’ont pas été modifiés
  • En raison de possibles problèmes de délivrabilité avec Google Workspace, les TTL liés au mail ont été exclus des modifications
• Après une heure d’attente pour l’expiration de l’ancien TTL, le cutover pouvait être lancé

Conversion du Nginx de l’ancien serveur en reverse proxy

• Plutôt que d’éditer manuellement 34 fichiers de configuration, la transformation a été automatisée via un script Python
• Le script analysait les blocs server {} de tous les fichiers de configuration, identifiait le bloc de contenu principal, puis le remplaçait par une configuration de proxy
• Les configurations d’origine ont été sauvegardées dans des fichiers .backup
• L’exemple de configuration appliquait proxy_pass https://NEW_SERVER_IP;, proxy_set_header Host $host;, proxy_set_header X-Real-IP $remote_addr;, proxy_read_timeout 150;
• L’option clé était proxy_ssl_verify off
  • Parce que les certificats SSL du nouveau serveur étaient valides pour les domaines, mais pas pour l’adresse IP
  • Comme les deux extrémités étaient sous contrôle, la désactivation de la vérification était acceptable dans ce contexte

Procédure de cutover

• Juste avant le basculement, les conditions étaient un retard de réplication à Seconds_Behind_Master: 0 et un reverse proxy prêt à fonctionner
• L’ordre d’exécution était le suivant
  • Sur le nouveau serveur, STOP SLAVE;
  • Sur le nouveau serveur, SET GLOBAL read_only = 0;
  • Sur le nouveau serveur, RESET SLAVE ALL;
  • Sur le nouveau serveur, supervisorctl start all
  • Sur l’ancien serveur, nginx -t && systemctl reload nginx pour activer le proxy
  • Sur l’ancien serveur, supervisorctl stop all
  • Depuis le Mac local, exécution de python3 do_cutover.py pour changer tous les enregistrements A du DNS vers l’IP du nouveau serveur
  • Attente d’environ 5 minutes pour la propagation
  • Commentaire de toutes les entrées crontab sur l’ancien serveur
• Le script de cutover DNS appelait l’API DigitalOcean pour modifier tous les enregistrements A en environ 10 secondes

Travaux complémentaires après le cutover

• Une fois la migration terminée, il a été constaté que de nombreux webhooks de projets GitLab pointaient encore vers l’IP de l’ancien serveur
• Un script a été écrit et appliqué pour scanner tous les projets via l’API GitLab et mettre à jour en masse les webhooks

Résultat final

• Le coût mensuel est passé de 1 432 $ à 233 $
• L’économie annuelle atteint 14 388 $
• Un serveur plus puissant a aussi été obtenu
  • Le CPU est passé de 32 vCPU à 96 CPU logiques
  • La RAM est passée de 192 Go à 256 Go de DDR5
  • Le stockage est passé d’une configuration mixte d’environ 2,6 To à 2 To de NVMe en RAID1
  • Le temps d’interruption a été de 0 minute
• La migration complète a pris environ 24 heures
• Aucun impact utilisateur n’a été observé

Enseignements clés

• La réplication MySQL est l’outil central d’une migration sans interruption
  • Il faut la mettre en place tôt, lui laisser le temps de rattraper son retard, puis effectuer le cutover
• Il faut absolument vérifier les privilèges des utilisateurs MySQL avant la migration
  • Avec le privilège SUPER, read_only peut être contourné, ce qui signifie qu’un esclave supposé en lecture seule ne l’est pas réellement
• Les mises à jour DNS, les modifications de configuration Nginx et les corrections de webhooks gagnent à être scriptées
  • Traiter manuellement plus de 34 sites prend du temps et augmente le risque d’erreur
• La combinaison mydumper + myloader est bien plus rapide que mysqldump sur de gros jeux de données
  • Le dump et la restauration en parallèle sur 32 threads réduisent à quelques heures un travail qui aurait demandé plusieurs jours
• Sur des charges steady-state, les fournisseurs cloud peuvent coûter cher, et un serveur dédié peut offrir de meilleures performances à moindre coût

Scripts GitHub

• Tous les scripts Python utilisés pour la migration ont été publiés sur GitHub
• Liste des scripts inclus
  • do_list_domains_ttl.py
    • Liste les enregistrements A, les IP et les TTL de tous les domaines DigitalOcean
  • do_ttl_update.py
    • Réduit en masse le TTL de tous les enregistrements A/AAAA à 300 secondes
  • do_to_hetzner_bulk_dns_records_import.py
    • Migre toutes les zones DNS de DigitalOcean vers Hetzner DNS
  • do_cutover_to_new_ip.py
    • Bascule tous les enregistrements A de l’IP de l’ancien serveur vers celle du nouveau
  • nginx_reverse_proxy_update.py
    • Convertit toutes les configurations de sites nginx en configuration de reverse proxy
  • mysql_compare.py
    • Compare le nombre de lignes de toutes les tables entre deux serveurs MySQL
  • final_gitlab_webhook_update.py
    • Met à jour tous les webhooks des projets GitLab vers l’IP du nouveau serveur
  • mydumper
    • Bibliothèque mydumper
• Tous les scripts prennent en charge un mode DRY_RUN = True pour permettre une prévisualisation sûre avant application réelle

[GN⁺]

Commentaires sur Hacker News

• Il y a quelques mois, j’ai déplacé deux serveurs de Linode et DO vers Hetzner, avec une grosse baisse des coûts à périmètre comparable. Ce qui m’a encore plus impressionné, c’est que la stack était un véritable bazar mêlant des dizaines de sites, des langages différents, de vieilles bibliothèques, ainsi que MySQL et Redis. Et pourtant, Claude Code a tout migré, en réécrivant même une partie du code quand certaines bibliothèques n’existaient plus. Ce genre de migration complexe devient maintenant bien plus simple, donc je pense que la portabilité entre fournisseurs va augmenter à l’avenir

  • À mon avis, ce pour quoi les gens payaient, ce n’était pas du compute magique, mais le fait de ne pas toucher à 10 ans de glue code accumulé. Mais si des agents commencent à dévorer cette glue, le moat des fournisseurs historiques risque de s’amincir très vite
  • Honnêtement, on dirait une pub pour Claude avec une pub pour Hetzner imbriquée dedans. Je me demande jusqu’où va la mise en abyme
  • J’ai l’impression qu’on n’est pas obligé de ramener toutes les histoires à l’IA
  • Moi aussi, je vais quitter Linode dans les prochains mois. Je l’utilise depuis plus de 10 ans et je leur ai recommandé beaucoup de clients, mais ils ont continué à augmenter les prix, au point qu’on peut maintenant avoir chez Hetzner 8 fois plus de mémoire, du NVMe dédié et un CPU dédié pour moins cher. On perd un peu des avantages comme la facilité de migration des serveurs virtuels, mais même en cas d’incident, le support Hetzner a toujours été rapide et compétent
  • J’utilise aussi de plus en plus Claude pour le DevOps. Je fais tourner des VM sur Proxmox sur mon bare metal, et Claude a optimisé et configuré un nouveau réseau réparti sur plusieurs machines à une vitesse folle, au point de donner l’impression d’être presque un collègue ou un sysadmin très bien payé

• Je suis en train de préparer une migration d’AWS vers Hetzner. Amazon facture parfois 20 fois plus cher que ses concurrents, force à prendre des engagements de long terme pour obtenir des prix à peu près corrects, et rend la sortie des données extrêmement chère, ce qui me semble très hostile envers les clients. On pourrait croire que les frais d’egress servent à enfermer les gens, mais en réalité ils créent une pression qui fait qu’en déplaçant ne serait-ce qu’une partie vers un concurrent, on finit par vouloir tout déplacer. Cela dit, comme je n’ai pas bâti ma plateforme sur des services exclusifs à Amazon, la migration est un peu plus simple pour moi

  • C’était vrai auparavant, mais l’ambiance a changé en janvier 2024, quand GCP a lancé une politique de suppression des frais d’egress, puis AWS a suivi quelques mois plus tard avec une politique similaire. Ce n’est pas pour convaincre qui que ce soit de rester, je veux juste signaler qu’un waiver request est techniquement possible. Je ne sais pas exactement jusqu’où ça va en pratique, et la formulation d’AWS laissait aussi penser à une influence du EU Data Act

• Chaque fois que je vois ce genre de billet, je trouve curieux que les gens parlent si peu de redondance ou de load balancer. Si un seul serveur tombe, plusieurs services peuvent tomber avec lui, donc je me demande si les gens trouvent vraiment ça acceptable. Ils économisent peut-être de l’argent, mais risquent d’y perdre en temps de maintenance et en futurs maux de tête

  • À mon avis, ça dépend du type de service et de son importance. Si un serveur peut tourner 10 ans et n’être indisponible qu’entre une semaine et un mois sur toute cette période, c’est souvent un compromis tout à fait acceptable. Pour une petite entreprise, un site hobby, un forum ou un blog où le site n’est pas au cœur de l’activité, une courte indisponibilité n’est pas forcément grave. En fait, cette longue traîne de sites à faible trafic représente peut-être la majorité du web. Tout n’a pas besoin d’être hautement disponible, et si on le souhaite, ces fournisseurs proposent aussi des fonctions comme des load balancers
  • Si ce genre de billet devient populaire, c’est souvent parce qu’il révèle un décalage entre les besoins et la solution. S’il s’agit d’un projet hobby ou d’une petite entreprise surarchitecturée avec une architecture de niveau entreprise, alors si une panne d’une journée de temps en temps reste acceptable, tout l’attirail cloud n’est pas forcément nécessaire. Cela dit, ce billet était un peu étrange, car il mettait l’accent sur une migration sans interruption, alors que l’architecture d’arrivée ne semblait pas très tolérante aux pannes. On aurait pu l’améliorer nettement avec juste un peu plus de structure côté Hetzner
  • Beaucoup de workloads n’ont pas besoin d’un tel niveau de préparation. Et il ne faut pas sous-estimer la fiabilité de la simplicité. J’ai travaillé longtemps comme admin Linux, et j’ai vu bien plus d’indisponibilités dans les systèmes complexes que dans les systèmes simples. Quelque part entre la théorie et la réalité, j’ai fini par avoir l’impression que, dans la plupart des cas, les systèmes simples tiennent mieux
  • Pour être juste, ils utilisaient déjà à l’origine une VM unique chez DigitalOcean, donc ils ne profitaient pas tant que ça des avantages du cloud provider. En général, ce type de billet se divise entre les cas où l’on est allé vers le cloud pour de mauvaises raisons et où revenir à quelque chose de plus physique a du sens, et ceux où faire ce déplacement serait catastrophique. Celui-ci me semble plus proche du premier cas. Si la configuration tournait bien sur DO, alors avec une politique de DR adaptée, ça devrait aussi très bien se passer chez Hetzner
  • Cette décision repose peut-être aussi sur une expérience qui n’a pas vraiment connu longtemps l’enfer de la maintenance ni les futurs casse-têtes

• Chez lithus.eu, nous avons souvent migré des clients de divers clouds vers Hetzner. En général, nous mettons en place du multi-serveur, parfois du multi-AZ, et nous répartissons les workloads avec Kubernetes pour fournir de la HA. Sur un nœud unique, Kubernetes est sans doute excessif, mais dès qu’il y a plusieurs nœuds, ça devient beaucoup plus pertinent. Pour les sauvegardes, nous utilisons Velero en plus des sauvegardes au niveau applicatif ; par exemple, pour Postgres, nous avons aussi des sauvegardes WAL afin d’aller jusqu’au PITR. Les données d’état sont placées sur au moins deux nœuds pour garantir la HA. Côté performances aussi, le bare metal est généralement meilleur, et nous avons souvent vu le temps de réponse être réduit de moitié par rapport à AWS. À mon avis, cela tient moins à la virtualisation elle-même qu’à des facteurs périphériques comme le NVMe, une latence réseau plus faible et moins de cache contention. J’avais détaillé tout ça dans un ancien post HN

  • J’avais fait moi-même des mesures il y a quelques années, et depuis, je ne regarde plus les serveurs virtuels de la même façon. Le temps CPU n’est pas réservé comme la RAM, donc les performances étaient vraiment mauvaises par rapport au matériel réel. Ce billet de mesure valait aussi le détour
  • Les déploiements k8s sont vraiment agréables à déplacer. Il y a moins de dépendance fournisseur que lorsqu’on s’appuie sur les services managés de plusieurs clouds. Dans ma stack, il y a surtout k8s, un Postgres hébergé et du stockage de type s3 ; je peux toujours auto-héberger Postgres, donc au final il ne reste vraiment que k8s et s3 comme éléments clés. Il me semble qu’Hetzner a aussi quelque chose qui ressemble à s3, mais je n’ai pas encore regardé, et déplacer 100 To serait un chantier assez lourd
  • Pour info, HA signifie high availability
  • Le billet était raisonnable, mais le fait d’avoir laissé un email à la fin lui donnait un petit côté message promotionnel

• Ce billet était assez pénible à lire. On avait l’impression que Claude faisait la migration, puis qu’on lisait ensuite le rapport écrit par Claude. Si les LLM ont permis de faire de telles économies, c’est très bien, mais si on publie le texte, la moindre des choses serait au moins de le relire pour enlever les répétitions et le style narratif typique des LLM

  • Je sais que beaucoup de gens ne lisent pas l’original, mais là c’était vraiment douloureux à lire

• Je pense qu’il faut se méfier d’Hetzner. J’adorais vraiment ce fournisseur auparavant, mais je l’ai quitté récemment. Ils ont coupé d’un coup la trentaine de VM que nous utilisions pour notre pipeline CI/CD à cause d’un unique litige de facturation de 36 dollars. Nous avions pourtant fourni la preuve du paiement intégral, y compris les relevés bancaires, mais ils n’ont même pas voulu regarder, et malgré nos tentatives urgentes pour les contacter, ils ont fini par bloquer tout accès. Nous sommes maintenant passés chez Scaleway

  • Je trouve leur service client étonnamment hostile. Cela dit, je continue quand même à les utiliser pour des usages non critiques
  • La gestion de la facturation chez Hetzner est assez automatisée, mais en général, même quand un paiement par carte échoue, ils laissent plutôt un délai d’environ un mois pour régulariser

• Il y a quelques mois, en cherchant une alternative à AWS pour un petit side project SaaS, j’ai d’abord sérieusement envisagé Hetzner, à la fois pour réduire les coûts et pour soutenir un cloud européen. J’étais prêt à accepter le supplément de travail manuel, mais c’est finalement la réputation des IP qui m’a bloqué. Une des règles de pare-feu AWS managé utilisées dans mon entreprise bloquait beaucoup d’IP Hetzner, peut-être même toutes, et sur mon ordinateur portable pro, les sites hébergés sur des IP Hetzner ne s’ouvraient pas non plus à cause des politiques IT. Avec quelque chose comme Cloudflare, ce serait peut-être moins visible, mais j’ai aussi vu passer des remarques sur une protection DDoS plus faible. Au final, j’ai choisi DO App Platform dans une région UE, et l’option de base de données managée a aussi été un gros avantage

  • Si Amazon bloque ses concurrents de cette manière, c’est une façon quand même bien pratique de faire les choses de leur point de vue
  • Je ne sais pas de quelle règle de pare-feu il s’agit, mais l’idée que DO soit plus digne de confiance qu’Hetzner me surprend assez. Quand je vois des scrapers ou des hackers, je tombe souvent aussi sur des ASN de DO, donc j’ai le sentiment qu’eux aussi pourraient finir bloqués un jour
  • D’après mon expérience, les IP de DO étaient encore pires. C’est d’ailleurs exactement pour cette raison que j’ai quitté DO
  • J’avais déjà mentionné ce sujet dans un ancien fil sur Tor. J’avais supposé qu’Hetzner était favorable à Tor et que cela pouvait affecter la réputation des IP, mais à l’époque certaines réponses disaient qu’il n’y avait pas vraiment de problème de réputation. Pourtant, en regardant des documents du Tor Project, Hetzner semble représenter environ 7 % du réseau Tor, donc l’histoire n’a pas l’air si simple
  • Ironiquement, j’ai résolu 99 % de mes problèmes de bots simplement en bloquant AWS et Azure. Aucun faux positif sur de vrais utilisateurs, et du coup je me demande presque si je ne devrais pas vendre ce blocage comme un service à part entière

• Je trouve très utile et appréciable d’avoir partagé cette expérience de migration. Pour moi, la comparaison entre DO et Hetzner ressemble au compromis entre ouvrir DoorDash ou UberEats, et cuisiner soi-même son dîner. Le rapport de coût me semble assez comparable. Je travaille avec les trois grands clouds et avec de l’on-prem, mais pour les petites tâches ou les tests de PoC, je reviens encore au tableau de bord DigitalOcean. Le fait d’avoir un serveur ou un bucket en quelques clics, des sane defaults, et des sauvegardes activables via une simple case à cocher, ce niveau de commodité a clairement de la valeur quand on tient compte du coût du temps

  • Je ne suis pas totalement sûr de ce que tu veux dire, mais j’ai l’impression que la console Hetzner fonctionne de façon assez similaire
  • Il y avait deux choses intéressantes dans ce billet. La première, c’est la procédure de migration sans interruption elle-même, qui peut servir de référence de manière générale. La seconde, c’est la décision de remplacer des instances cloud par du bare metal, auquel cas il faut considérer que la réduction des coûts inclut aussi la perte de bascule rapide et de capacités de sauvegarde. À leur place, j’aurais probablement dépensé environ 200 dollars de plus pour garder un hot spare et permuter le primaire et le secondaire tous les quelques jours afin de vérifier que les deux fonctionnent bien. Pour un coût relativement faible, cela réduit fortement le risque de panne critique
  • Ce que tu décris correspond en fait presque exactement à l’expérience proposée par Hetzner Cloud depuis déjà plusieurs années. Et il y a aussi une API Hetzner Cloud, donc on peut tout mettre en place en IaC sans même cliquer sur des boutons
  • Dans mon cas, j’ai installé Coolify sur des serveurs Hetzner, ce qui me donne une expérience presque équivalente à un service en un clic
  • Tout cela m’a simplement fait penser à ce xkcd

• Je me demandais comment étaient gérées les sauvegardes de la base de données. Est-ce qu’il y a un replica ou un standby, ou juste des sauvegardes horaires ? Dans ce genre de configuration sur serveur unique, une panne matérielle comme celle d’un SSD peut arrêter l’application immédiatement, et si le SSD meurt vraiment, on peut se retrouver avec plusieurs heures ou plusieurs jours d’indisponibilité pendant la remise en place

  • Hetzner commercialise généralement ses serveurs matériels avec 2x 1TB SSD, et recommande fortement une configuration en RAID1 logiciel pour obtenir 1 To utilisable. Leur installateur d’image va d’ailleurs dans ce sens par défaut. Même si le premier SSD meurt quelques années plus tard, si le monitoring le détecte, on peut migrer vers une nouvelle machine, utiliser une solution intermédiaire ou un replica, ou continuer sur l’autre disque le temps de faire un hot-swap. Bien sûr, en passant sur des serveurs physiques, on perd une partie de la redondance du cloud, donc il faut l’intégrer au modèle de risque avec les économies réalisées. Et au minimum, ne même pas avoir de sauvegarde quotidienne vers un stockage distant me semblerait imprudent. Cela vaut aussi dans le cloud, même si c’est plus simple à configurer
  • Une indisponibilité aussi longue pourrait très bien ne déranger presque personne. Par exemple, si l’application mobile de mon association de copropriété tombe pendant une semaine, ça m’est assez égal. Tout n’a pas besoin d’être disponible en permanence
  • J’avais la même inquiétude. Ce billet donnait l’impression que son auteur se focalisait surtout sur une réduction agressive des coûts sans avoir suffisamment réfléchi au reste. Une VM DigitalOcean proposait probablement la live migration et les snapshots, alors que chez Hetzner ce genre de choses n’est possible que sur les offres cloud. En bare metal chez Hetzner, si un disque ou un composant lâche, c’est terminé ; même s’ils remplacent le disque, la restauration repart entièrement à la charge de l’utilisateur. Hetzner l’indique d’ailleurs clairement à plusieurs endroits
  • La chose la plus simple que j’aie mise en place était du côté de MongoDB, où replication, sharding et failover étaient très simples. Plus récemment, sur PostgreSQL, j’ai monté une configuration avec pg_auto_failover comportant 1 monitor, 1 primary et 1 replica, et une fois les réglages et les pièges compris, c’était aussi plutôt simple. D’après mon expérience, une migration sans interruption est également possible dans ce cas
  • S’ils ont jugé que ce compromis était acceptable, on ne peut pas affirmer d’emblée qu’ils ont tort. Toutes les applications n’ont pas besoin d’une disponibilité 24/7, et la plupart des sites web supportent plusieurs heures de panne sans impact majeur. Si l’économie réalisée est supérieure au risque, cela peut être une décision métier parfaitement rationnelle. Ce qui m’intéresserait plutôt, c’est de savoir quelle est leur stratégie de sauvegarde et de restauration, et ce qui a changé à ce niveau avec le passage chez Hetzner

• L’image de mème dans l’en-tête, c’était moi qui l’avais faite. Je l’avais utilisée dans cet article, donc ça m’a fait plaisir de la voir réutilisée deux fois