Migration serveur – inventaire et architecture cible

Fin février j’ai reçu un mail d’OVH m’annonçant la fin de service des serveurs « Bare Metal » à Roubaix 1. Pour une bonne raison, OVH va entreprendre des travaux dans ce datacenter, il faut donc le vider. Histoire de m’inciter à migrer rapidement cette annonce de fin de service est accompagnée d’une augmentation tarifaire de 15% à partir de mi-avril… et de deux bons de réduction : l’un offrant les frais d’installation et l’autre permettant de réduire le coût mensuel pour un nouveau serveur. J’ai jusqu’à fin décembre pour migrer ou abandonner ce serveur.

Avant de me décider il fallait que je me pose deux questions :

• ce serveur est il toujours nécessaire ? j’ai commencé à m’héberger chez OVH du temps de l’ADSL et de ses débits asymétriques. Avec la fibre il est plus simple de s’héberger à la maison. Est-ce que l’achat d’un NUC, qui serait amorti en moins de deux ans ne serait pas préférable ?
• si je continuer de m’héberger sur internet quels sont mes réels besoins ? Ai-je toujours besoin d’un serveur « bare metal » ou un simple VPS est il suffisant ?

Ce serveur est-il toujours nécessaire ?

Afin de répondre à cette question j’ai fait un rapide inventaire de ce qui est présent sur le serveur :

• mon infrastructure mails : serveur postfix avec tout ce qui va bien autour (antispam, antivirus, etc.) et Kopano pour la partie boîtes mails
• un serveur nextcloud avec beaucoup de fichiers (environ 100Go de données)
• un site web sous wordpress et quelques sites périphériques plus ou moins à l’abandon (encore plus que ce blog !)
• un « extranet » qui ne sert plus vraiment et qui regroupait l’accès aux outils d’administration
• un « serveur subversion » pour héberger quelques développements historiques et le code source de l’extranet des MSIT
• des synchronisations de backups (principalement des bases mysql)

Concrètement la majorité de ce qui est sur ce serveur pourrait effectivement être hébergé à la maison. La grosse exception étant la partie mail. En effet les principaux fournisseurs de mail (Google et Microsoft en tête) ont des politiques antispam agressives pour les serveurs hébergés sur des adresses IP de fournisseurs d’accès internet. Le fait de ne pas pouvoir positionner de reverse est également un handicap et surtout je n’ai pas d’adresse IP fixe. Il est aussi possible que le port 25 soit bloqué par mon FAI, je n’ai pas vérifié !

Mon infrastructure mail portant sur plusieurs domaines soit je continue de m’auto-héberger, soit il faut que je trouve un autre fournisseurs de mail. Pour presque tous mes domaines ça ne poserait pas de problème insupportable mais pour mon domaine principal j’utilise un « catch-all » (pratique peu recommandable aujourd’hui mais mise en place depuis trop longtemps pour revenir en arrière) et j’héberge également des mailing listes via mailman (enfin, surtout une !)

Autres éléments à prendre en compte si on veut héberger un serveur chez sois : la consommation électrique induite, le matériel qui peut tomber en panne (mais c’est aussi le cas d’un « bare metal »), le bruit, etc.

En conclusion je souhaite continuer d’auto-héberger mes mails et donc la solution du serveur à la maison s’éloigne même si une approche mixte resterait possible.

Quels besoins pour quel hébergement ?

Le serveur actuel dispose de 2x1To de stockage en RAID. L’espace disque reste confortable mais les fichiers nextcloud et les mails prennent « un peu » de place. L’offre Kimsufi d’OVH propose des serveurs avec des disques de 480Go en SSD ou 2To en HDD.

J’ai rapidement regardé les offres de la concurrence comme Scaleway par exemple.

Au final j’opte pour un Kimsufi, les promotions OVH me permettant de rester sur un budget très similaire. C’est aussi un boost significatif par rapport à mon serveur actuel :

• Processeur intel 4 coeurs / 8 cores à 3,7 GHz. Le CPU n’a jamais été un facteur limitant sur l’ancien serveur
• 32 Go de RAM vs 8 Go actuellement… à l’heure de la virtualisation, des dockers & co c’est un bon point !
• 2×2 To vs 2x1To… et bonne surprise j’ai été livré avec 2x4To ce qui laisse de la marge !

Bande passante identique et toujours une IPv6 en /128 (ça c’est bof OVH… un /64 ne changerait pas grand chose non ?)… Allez c’est parti ! Le serveur est livré assez rapidement – comme toujours chez OVH – et je vais donc pouvoir passer à l’installation. Mais pour installer quoi ?

Quelle architecture cible ?

En pratique j’avais plusieurs options possibles :

• la solution d’apparente simplicité : je récupères mon backup (le serveur actuel est sauvegardé avec Veeam) et j’installe le backup sur le nouveau serveur. Avec cloud-init il y a une petite chance pour que ça marche du premier coup !
  • avantage : c’est quasi immédiat et ça permet de tester mes procédures de backup
  • inconvénient : je ne me débarrasse pas de ma dette technique accumulée sur cet ancien serveur
• installer un hyperviseur me permettant d’avoir des machines virtuelles. Les possibilités sont nombreuses entre VMWare, Proxmox et XCP-NG
  • avantages : apprendre plein de nouvelles choses et une architecture plus flexible, changements de serveurs futurs facilités en « bougeant » les VM ou containers d’un serveur à l’autre
  • inconvénients : une partie des ressources utilisée par le superviseur

Le choix est vite fait et je décide de partir vers la solution de l’hyperviseur. Pour le choix OVH propose en standard Proxmox et VMWare ESXi (et aussi du Microsoft mais ce n’est pas ma cible). Broadcom ayant annoncé la fin de la gratuité pour ESXi je porte mon choix sur Proxmox VE 8. N’y connaissant rien je fais l’installation par défaut (ce qui me vaudra une phase de reconfiguration des volumes pour pouvoir faire du LVM-Thin par la suite).

Reste à choisir une stratégie de migration :

• restaurer le backup de mon serveur en tant que VM dans la nouvelle infrastructure
  • avantage : ça devrait être assez immédiat
  • inconvénient : la dette technique reste toujours présente mais je devrais pouvoir migrer les services au fur et à mesure de mes besoins
• migrer progressivement les services présents sur le serveur actuel sans passer par l’étape précédente
  • avantage : plus de dette technique (ou plus faible !)
  • inconvénients : plus long à faire et idéalement je dois faire ça en un mois pour ne pas payer les deux serveurs trop longtemps

Comme je suis joueur je suis parti sur la dernière option. Au moment où j’écris ce post la migration est quasi terminée et le challenge de la migration en un mois semble réussie !

Dans les semaines à venir je tenterai de faire des billets spécifiques aux migrations des différents services et les choix techniques retenus pour remplacer ou répondre à de nouveaux défis.