Une migration est un projet, pas un ticket.
La plateforme à fort trafic d'un éditeur, réarchitecturée pour la montée en charge, testée sous charge et déplacée sur notre bare metal. L'impact visible pour le client a été une fenêtre d'environ cinq minutes à l'intérieur d'une opération de deux heures.
Dans cet article 4 sections
- Le groupe de sites à fort trafic d'un grand éditeur devait déménager de datacenter vers notre bare metal, réarchitecturé pour la montée en charge en chemin. Le trafic des breaking news est leur métier, et chaque lecteur verrait une mauvaise bascule.
- Nous avons d'abord conçu la plateforme : un cache edge à deux niveaux sur SAN all-flash, un load balancer réglé pour de très hauts nombres de connexions, un niveau base de données avec séparation lecture/écriture, et une couche d'object cache.
- Puis nous l'avons prouvée sous un test de charge à pleine échelle, avant qu'un seul lecteur réel ne soit déplacé.
- La bascule a été une opération de deux heures avec une fenêtre DNS visible pour le client d'environ cinq minutes, chaque phase avec un chemin de retour arrière.
Ce sont des sites d'information et de lifestyle où le pic de trafic est le métier. Une migration qui les fait tomber, ou les remonte plus lentement, est visible par chaque lecteur au milieu d'une actualité brûlante. Cela n'allait jamais être un ticket. C'était un projet avec une nuit de bascule.
Pourquoi une seule équipe pour tout le travail
Le travail exigeait deux choses à la fois, d'une seule équipe : l'ingénierie pour réarchitecturer les niveaux de cache et de base de données, et l'infrastructure qui nous appartient (SAN enterprise all-flash, un vrai fabric réseau) pour l'accueillir. Nous avons réuni les ingénieurs et le métal, et la nuit de bascule était la nôtre à porter.
La plateforme, telle que conçue
L'intention de conception tenait en trois points à la fois : réarchitecturer pour la montée en charge du cache et de la base de données, basculer avec une fenêtre minimale et bornée, et porter chaque pièce du nouveau design intacte à travers la bascule. Voici ce qu'elle est devenue.
Cache edge Varnish à deux niveaux
HAProxy en frontal
ProxySQL sur chaque nœud web
Cluster Percona XtraDB
Valkey + Sentinel
Le déterministe bat l'élégant
La base de données a été déplacée par un hot backup frais plutôt que par un rattrapage de réplication en direct. C'était une décision de conception avec une raison énoncée : un backup est déterministe, donc ce qui est dans le backup est ce que le nouveau cluster possède, sans état de réplication à démêler au pire moment possible. Le chemin plus élégant existe, et nous l'avons refusé à dessein. La nuit de la bascule, vous voulez le déplacement dont vous connaissez déjà l'issue.
Déplacer les données vite a voulu dire les relayer en deux sauts : par l'Internet public vers un relais de staging, puis à travers le LAN interne au débit de ligne, transformant une copie limitée par le chiffrement en quelques minutes. À destination, le cluster a été reconstruit depuis le backup et resynchronisé nœud par nœud.
Et une synchronisation du système de fichiers portait une liste d'exclusions chirurgicale pour que la migration ne puisse pas écraser la configuration du nouveau foyer : la configuration du pointeur de base de données, le drop-in de l'object cache et la mise en place du cache à deux niveaux ont tous été explicitement préservés. La seule pièce d'état qu'une restauration de base de données efface en silence, l'activation du plugin de purge du cache, avait été cartographiée à l'avance avec sa réactivation prête à se déclencher. C'est cela, concevoir la bascule deux fois : une fois vers l'avant, et une fois pour tout ce qui pourrait mordre en chemin.
Les données, en deux sauts
Internet public vers un relais de staging, puis le LAN interne au débit de ligne. Des minutes, pas des heures.
Cluster restauré depuis le hot backup
Resynchronisé nœud par nœud.
Déplacement du système de fichiers, sous garde
Une liste d'exclusions protège la nouvelle architecture contre l'écrasement.
Le DNS bascule
La fenêtre visible : environ cinq minutes.
Le seul réglage effacé en silence, réactivé
À l'heure prévue, parce qu'il avait été cartographié à l'avance.
“Nous n'avons pas déplacé vos serveurs. Nous avons reconstruit votre plateforme et l'avons posée sur la nôtre, dans une fenêtre d'environ cinq minutes, planifiée à l'avance.”
Ce que la relation est devenue
La migration a été le point d'entrée, pas la fin. Les sites frères ont suivi le même schéma, et la discipline opérationnelle est venue avec la construction plutôt que comme une vente additionnelle ultérieure : des hot backups fréquents de la base de données et des snapshots du système de fichiers conservés, des caches edge réglés, une couche de supervision des performances à l'échelle de la flotte mise en place, et une validation par test de charge avant le lancement. La relation s'est installée dans « nous exploitons et faisons évoluer la plateforme », pas « nous l'hébergeons ».
Réponses directes
Pouvez-vous migrer un site à fort trafic sans le faire tomber ?+
Nous planifions une fenêtre bornée et l'annonçons à l'avance. Dans ce projet : environ cinq minutes de propagation DNS visible pour le client à l'intérieur d'une opération de deux heures.
Backup-restore ou réplication pour une migration de base de données ?+
Les deux sont légitimes. Nous avons choisi ici un hot backup frais parce qu'il est déterministe : ce qui est dans le backup est ce que le nouveau cluster possède, sans état de réplication à démêler en pleine bascule. Le chemin élégant n'est pas toujours le chemin sûr.
Que doit contenir un plan de retour arrière de migration ?+
Un chemin de retour arrière à chaque phase, et un chemin documenté vers l'origine jusqu'à ce que la nouvelle plateforme ait gagné la confiance.
Réarchitecturez-vous pendant une migration ou déplacez-vous simplement les choses ?+
Si le déplacement vaut un projet, il vaut en général la réarchitecture. Cette plateforme a gagné un cache edge à deux niveaux, un niveau base de données avec séparation lecture/écriture et une couche d'object cache en chemin. Le lift-and-shift est parfois le bon choix, mais c'est une décision, pas une valeur par défaut.
Vous planifiez un déménagement ? Apportez-nous la plateforme, pas un ticket.
Conception, test de charge, playbook de bascule, cordes de retour arrière. Nous vous dirons la fenêtre honnête avant la nuit, et nous tiendrons le filet.
Parler à un ingénieurVous êtes arrivé à la fin.
Mettez la lecture en pratique
Que faites-vous tourner ?
Parlez-nous de la charge de travail, du trafic et des exigences de reprise. Commencez par le configurateur de serveur, ou passez en revue les détails avec un ingénieur.
Écrit par les ingénieurs qui construisent et exploitent l'infrastructure qu'il décrit.Parler à un ingénieur