Récemment, j'ai aidé une station de commerce électronique à résoudre le problème de commutation de nœuds d'un CDN à haute défense, et son activité a failli s'effondrer à cause du pic de latence des nœuds. J'ai jeté un coup d'œil à l'arrière-plan de l'heureux événement - ce copain est en fait un commutateur de nœuds en tant qu'opération de commutation, une coupure manuelle directe, le résultat est que les plaintes des utilisateurs s'envolent comme des flocons de neige.
Le changement de nœud dans un CDN de haute défense n'est pas simplement une question de "changement de route", c'est plus comme changer de pneus lorsque vous êtes en pleine course sur l'autoroute. Il faut tenir compte du trafic professionnel, de la maintenance des sessions, de la mise en cache DNS, de la politique de retour à la source de ces éléments, un peu de négligence se traduisant par un écran d'erreur 500.
Pourquoi les nœuds deviennent-ils des goulets d'étranglement pour les entreprises ?J'ai découvert que 80 % du problème réside dans la "confiance excessive dans la configuration par défaut". De nombreuses équipes pensent que l'achat d'un CDN à haute défense est une bonne chose, mais lorsque le nœud est pénétré par un DDoS, il n'y a pas d'autre solution. N'oubliez pas qu'aujourd'hui, même les CDN doivent "prévenir les coéquipiers" - la surveillance des nœuds de certains fournisseurs de services n'est qu'une simple façade.
Commençons par un scénario typique de commutation manuelle. Lorsque vous constatez que le temps de réponse d'un nœud passe de 50 ms à 2 000 ms, votre première réaction est certainement de "couper". Mais si vous éteignez directement le nœud, la connexion TCP établie sera soudainement interrompue et la commande à moitié payée de l'utilisateur sera perdue.
Une commutation manuelle fiable doit passer par un processus à échelle grise : d'abord le poids du nouveau nœud à 5%, observer 15 minutes de stabilité et ensuite augmenter progressivement la proportion. J'ai utilisé l'API CDN5 pour faire des expériences, le taux d'échec de la commutation instantanée forcée peut atteindre 37%, alors que le taux d'échec de la commutation à l'échelle grise est presque nul.
Pour vous montrer un exemple de configuration, voici le script pour le changement de niveau de gris en utilisant l'API du CDN5 :
Mais la commutation manuelle est en fin de compte un travail de pompier. C'est le système automatique de reprise après sinistre qui est vraiment fiable. Une bonne commutation automatique devrait être comme un pilote automatique - changer de voie avant de détecter un danger.
J'ai comparé les solutions des trois principaux fournisseurs de services : le routage intelligent de CDN5 est basé sur l'analyse en temps réel des signatures d'attaques, CDN07 s'appuie sur la surveillance globale des sondes, et 08Host a développé un algorithme de prédiction du trafic qu'il a lui-même mis au point. Pour être honnête, il n'y a pas de solution parfaite, la clé dépend des caractéristiques de l'entreprise.
Ne croyez pas à la propagande "aucune configuration n'est requise" !. Vous souvenez-vous de l'échec de la commutation automatique d'un fournisseur de services en nuage l'année dernière ? En raison d'une mauvaise évaluation des caractéristiques du trafic, les demandes normales des utilisateurs ont toutes été transférées vers le nœud en attente, ce qui a eu pour conséquence de transpercer directement le nœud en attente. Une bonne commutation automatique doit être configurée avec un mécanisme de fusion :
Il y a une leçon à tirer de cette situation : vous devez mettre en place une politique de retour en arrière pour la commutation automatique. Une fois, je n'ai pas configuré les conditions de retour en arrière, le trafic de récupération du nœud a été automatiquement réduit, puis a déclenché une deuxième panne. Désormais, ma pratique standard consiste à observer au moins deux heures de stabilité avant de procéder à un retour en arrière automatique.
Le réglage de la valeur TTL est un art : certaines équipes l'ont fixée à 60 secondes pour plus de rapidité, ce qui a eu pour effet de faire grimper en flèche les requêtes DNS et d'entraîner la chute des serveurs autorisés. Il est recommandé d'utiliser un TTL de 300 secondes pendant les heures de pointe, puis de le ramener à 60 secondes pendant la maintenance nocturne. N'oubliez pas qu'il y a aussi le problème de la validité locale, le rafraîchissement du cache DNS dans certaines régions peut être si lent que vous doutez de votre vie.
Récemment, j'ai aidé un client du secteur financier à concevoir une solution à double activité et j'ai découvert que le basculement automatique basé sur Anycast était la solution idéale. Bien que le coût soit si élevé qu'il fait mal aux gens, il s'agit vraiment d'une commutation sans perception de la part de l'utilisateur. En particulier contre les attaques DDoS, Anycast peut répartir le trafic sur des nœuds globaux, ce qui est beaucoup plus fiable qu'un point de défense unique.
Enfin, une suggestion solide : vous devez faire un exercice d'échec tous les mois. Débranchez directement le cordon d'alimentation du nœud maître pour voir si la commutation automatique peut vraiment fonctionner. J'ai vu trop d'équipes les configurer puis les mettre de côté, et lorsque quelque chose va vraiment mal, elles découvrent que la surveillance et l'alerte ne sont pas configurées correctement.
Le changement de nœud consiste essentiellement à équilibrer les risques. Une commutation trop rapide peut déclencher une réaction en chaîne, tandis qu'une commutation trop lente aggravera l'impact de la défaillance. Après tant d'arrêts pratiques, mon principe est le suivant : la priorité de l'activité de pointe est la stabilité avec la commutation à l'échelle grise, la maintenance de nuit peut essayer la récupération automatique en cas de catastrophe, les activités majeures doivent être effectuées avant le test de pression de la liaison complète.
Allez vérifier votre configuration CDN maintenant et voyez si la stratégie de commutation des nœuds est encore à l'âge de pierre. N'oubliez pas que la meilleure commutation est toujours celle que les utilisateurs ne ressentent même pas.
