Comment les services à disponibilité élevée appliquent-ils les correctifs sans redémarrer?
Comment les mises à jour de sécurité critiques sont-elles installées sur des systèmes que vous ne pouvez pas vous permettre de redémarrer, mais la mise à jour nécessite un redémarrage. Par exemple, les services/entreprises qui doivent fonctionner 24h/24 et 7j/7 sans interruption de service, par exemple Amazon.com ou Google.
Il existe différents utilitaires dans différents systèmes d'exploitation qui permettent de corriger à chaud le code en cours d'exécution. Un exemple de ceci serait kpatch et livepatch les fonctionnalités de Linux qui permettent de patcher le noyau en cours d'exécution sans interrompre ses opérations. Ses capacités sont limitées et ne peuvent apporter que des modifications insignifiantes au noyau, mais cela est souvent suffisant pour atténuer un certain nombre de problèmes de sécurité critiques jusqu'à ce que le temps soit trouvé pour effectuer une correction appropriée. Ce type de technique est généralement appelé mise à jour dynamique du logiciel .
Je dois cependant souligner que les sites avec pratiquement aucun temps d'arrêt ( haute disponibilité ) ne sont pas si fiables en raison des correctifs en direct, mais en raison de la redondance. Chaque fois qu'un système tombe en panne, un certain nombre de sauvegardes sont en place et peuvent immédiatement commencer à acheminer le trafic ou à traiter les demandes sans délai. Il existe un grand nombre de techniques différentes pour y parvenir. Le niveau de redondance fournit un temps de disponibilité significatif mesuré en neuf . Un temps de disponibilité de trois neuf est de 99,9%. Quatre neuf disponibilité est de 99,99%, etc. Le "Saint Graal" est de cinq neuf, ou 99,999% de disponibilité. La plupart des services que vous avez répertoriés ont une disponibilité de cinq neuf en raison de leurs systèmes de sauvegarde redondants répartis dans le monde entier.
J'ai regardé une présentation lors d'une conférence de sécurité par un employé de Netflix. Ils ne patchent pas du tout. Au lieu de cela, lorsqu'un correctif est requis, ils lèvent de nouvelles instances, puis éliminent celles qui ne sont pas corrigées. Ils le font presque constamment. Ils l'appellent déploiement rouge-noir .
La réponse courte est:
Ils redémarrent.
Vous semblez supposer qu'Amazon et Google fonctionnent sur un seul serveur, et si cela est redémarré, l'ensemble du site/service est en panne. C'est très loin de la vérité - les grands services s'exécutent généralement sur de nombreux serveurs qui fonctionnent en parallèle. Pour de plus amples informations, consultez des techniques telles que clustering , équilibrage de charge et basculement .
Google, par exemple, a plus d'une douzaine de centres de données à travers le monde , et chacun détient un grand nombre de serveurs (les estimations sont 100 000 à 400 000 serveurs par centre ).
Dans de tels environnements, les mises à jour (mises à jour de fonctionnalités et de sécurité) sont généralement installées sous la forme déploiements continus :
- choisir un sous-ensemble de serveurs
- installer des mises à jour sur le sous-ensemble
- redémarrez le sous-ensemble; en attendant les autres serveurs prennent le relais
- répéter avec le sous-ensemble suivant :-)
Il existe d'autres options, telles que les correctifs à chaud, mais elles ne sont pas utilisées aussi fréquemment dans mon expérience, du moins pas sur les grands sites Web typiques. Voir la réponse de la forêt pour plus de détails.
Vous pouvez vérifier " Activités de déploiement " sous "Déploiement de logiciels". Une méthode courante consiste à utiliser un équilibreur de charge en face de vos services et à rediriger le trafic en conséquence. Dans une technique appelée "déploiement bleu-vert", vous redirigez le trafic des serveurs "bleu" vers les serveurs "verts". Cela n'a aucun temps d'arrêt côté utilisateur, à condition bien sûr que l'application puisse gérer cela correctement, par exemple par le biais de services apatrides.
Supposons que votre application exécute la v1 sur le serveur bleu et que votre équilibreur de charge y dirige le trafic. Vous pouvez mettre à niveau le serveur vert (qui ne reçoit aucun trafic) vers la v2. Vous reconfigurez ensuite l'équilibreur de charge pour diriger le trafic vers le serveur vert. Vous êtes donc passé de la v1 à la v2 sans interruption.
Vous pouvez également utiliser la technique bleu-vert dans le cadre des tests. Par exemple, vous configurez l'équilibreur de charge pour diriger 95% du trafic vers le serveur bleu (v1) et 5% vers le serveur vert (v2). De cette façon, vous pouvez tester votre nouvelle version, avec moins de trafic et ayant moins d'impact sur les utilisateurs en cas de bugs.
C'est assez facile lorsque les choses sont regroupées et mandatées. Parce que vous avez de nombreux nœuds capables de faire le même travail (ou plusieurs dans le cas de référentiels de données tels que les moteurs de recherche, les systèmes de fichiers Hadoop, etc.)
Effectuez une recherche sur le Web. Vous frappez www.altavista.com. L'entrée DNS répertorie une demi-douzaine d'adresses IP et votre client en trouve une au hasard. Chaque adresse IP est un routeur Cisco, qui diffuse ce trafic vers un serveur aléatoire parmi 8 serveurs physiques frontaux (48 au total) sur des adresses IP internes. Ce serveur normalise votre requête (supprime les espaces, etc.) puis en prend un hachage MD5. Le MD5 décide vers lequel des 300 serveurs proxy cette requête est envoyée. Cette requête est envoyée au proxy via un protocole standard comme SOAP.
Les serveurs frontaux sont interchangeables car ils ne gèrent que les demandes transitoires d'une seule requête. En dehors du pire des cas, un client obtient sa requête abandonnée. Vous utilisez les données RRD ou toute autre collecte de données pour surveiller un serveur frontal qui commence à échouer et vous redirigez son trafic vers un serveur de secours. On peut en dire autant des routeurs Cisco.
Le proxy vérifie d'abord son cache . Pour un accès au cache, il mélange la localisation et renvoie la réponse; terminé. S'il s'agit d'un "échec de cache", le proxy étend la requête aux clusters de recherche.
Si un proxy tombe en panne, une autre machine physique peut à nouveau être échangée contre ce proxy. C'est un peu plus critique maintenant, car les procurations ne sont pas interchangeables; chacun "possède" une petite tranche du spectre des résultats de la recherche. Donc, si la machine 0x0000-0x00d9 tombe en panne, le substitut doit savoir intervenir pour cette plage. Et pire encore, cette machine de remplacement aura un cache vide, donc chaque requête de recherche sera un échec de cache . Cela augmentera la charge sur les clusters de recherche proprement dite d'un tout petit peu par proxy arrêté . Cela signifie que si vous rebondissez tous les mandataires en même temps, ne le faites pas pendant les heures de pointe de recherche!
Les clusters de recherche ont bien sûr une superposition et une redondance similaires, et chaque segment de la base de données de recherche réside sur plusieurs nœuds, donc si un nœud tombe en panne, d'autres nœuds peuvent servir cette tranche de résultats.
Je me concentre sur le proxy comme exemple. La communication à l'intérieur se fait via SOAP, la communication à l'extérieur se fait via un protocole de haut niveau similaire. Les données entrant et sortant sont transitoires, à l'exception du cache qui est important pour équilibrer la charge du cluster du moteur de recherche. Le fait est qu'il peut être échangé instantanément à tout moment, avec le pire des résultats de quelques recherches expirant. C'est quelque chose que le serveur frontal remarquerait et pourrait simplement renvoyer sa requête, date à laquelle le nouveau proxy serait opérationnel.
Donc, si vous avez 300 procurations, et qu'il faut une demi-heure à un proxy pour récupérer son cache, et que vous pouvez supporter une augmentation de 20% de la charge du moteur de recherche, vous pouvez échanger 1 proxy toutes les 30 secondes, donc dans tout glissement de 30 -période de minutes, 60 mandataires (20%) reconstruisent les caches. En supposant qu'il y ait même un besoin urgent d'aller aussi vite que .
Cet exemple prend 2-1/2 heures pour être déployé, et si une menace émergente nécessitait une réponse plus rapide, alors vous subissez la douleur de plusieurs échecs de cache, ou vous interrompez votre service assez longtemps pour patcher (mais dans l'exemple du moteur de recherche, le les échecs de cache seront toujours un problème lorsque vous reviendrez. J'ai regardé les graphiques RRD après un rechargement d'urgence de la base de données et le vidage du cache nécessaire, c'est quelque chose à voir.)
Bien sûr, le processus peut généralement être corrigé, arrêté et redémarré sans redémarrage complet. J'ai vu une disponibilité de 2 ans sur les nœuds de production.