Faire rouler les mises à jour dans une batterie de serveurs Web?
Les grands sites Web (Amazon, Facebook, Yahoo, etc.) ne planifient pas les temps d'arrêt pour les mises à niveau. Habituellement, ils sont terminés "en direct" et roulés progressivement dans la batterie de serveurs. Ils ont également une grande infrastructure et des équipes pour gérer cela.
Les sites Web plus petits mettent généralement l'ensemble du site hors ligne pour mettre à jour la structure de la base de données et mettre à niveau le code exécuté sur les serveurs Web. Les temps d'arrêt peuvent être très minimes, mais cela reste une interruption pour les clients.
Comment avez-vous fait le saut aux mises à jour roulantes sans temps d'arrêt? Quelles sont les exigences minimales pour y arriver? Que pouvons-nous faire pour créer des applications qui rendent cela possible dès le début?
Quelles sont les exigences minimales pour y arriver?
Une fois que vous avez au moins deux serveurs derrière un équilibreur de charge, vous pouvez supprimer un serveur du cluster de manière séquentielle, le mettre à jour et le rajouter au cluster pour terminer la mise à jour (dans la mesure où le visiteur est concerné).
Que pouvons-nous faire pour créer des applications qui rendent cela possible dès le début?
Concevez votre application en tenant compte de exigences en matière d'équilibrage de la charge .
0 webtime correspond à "la conception doit être identique dans tous les navigateurs". Les temps d'arrêt planifiés sont acceptables, il suffit de les programmer et de mettre en place une notification statique. À moins que cela ne vous coûte vraiment beaucoup de visites ou d'argent, ce qui n'est pas un petit site Web. Si vous ne voulez pas que quelqu'un le voie, faites-le au-dessus du 4 juillet (ou de Thanksgiving ou d'un autre moment opportun), à moins que votre site Web ne devienne le premier résultat de recherche Google pour "Traitement de brûlage de feu d'artifice" ou "Paroles de Francis Scott Key". ça va.
Faire cela dès le départ entraîne généralement un risque beaucoup plus grand: la sur-ingénierie.
Il y a toujours une raison pour un temps d'arrêt planifié, mais il peut être minimisé.
En fonction de votre infrastructure, différentes stratégies peuvent minimiser les temps d'arrêt. Les mises à jour régulières ne doivent pas nécessiter de temps d'arrêt.
Sur un certain nombre de sites gérés par PHP, je conserve des copies côte à côte de la base de code, par exemple les versions 1.0, 1.1 et 1.2:
/sites/site-1-0-0
/sites/site-1-1-0
/sites/site-1-2-0
Et créez ensuite des liens symboliques que le serveur Web peut utiliser:
/sites/production --> /sites/site-1-1-0
/sites/staging --> /sites/site-1-2-0
De cette façon, je peux organiser mon code sur le serveur de production pour des vérifications de sécurité de dernière minute, et lorsque je souhaite entrer en production, je viens de:
$ rm /sites/production; ln -s /sites/site-1-2-0 /sites/production
Le serveur Web utilise les liens symboliques de la spécification DocumentRoot, de sorte que la transition est pratiquement instantanée.
Il y a bien sûr des pièges, ici. Il faut s'assurer que les données externes sont stockées quelque part, euh, externe. Vous ne voulez pas écrire de fichiers temporaires ni stocker le contenu généré par l'utilisateur dans le système de fichiers sous les répertoires site-x-y-z.
Une autre alternative, si vous avez plusieurs serveurs, consiste à effectuer la transition via le routage. Certains fournisseurs de VPS (on pense notamment à Linode) facilitent l’acquisition de deux machines virtuelles et l’échange de leurs adresses IP. Vous devez donc configurer votre nouvelle version sur un nouveau serveur, effectuer les tests nécessaires, puis échanger les adresses IP pour déployer votre mise à jour. Les mêmes problèmes concernant la mise à jour d'actifs non codés s'appliquent, mais une réflexion et une planification minutieuses peuvent en faire un problème.
Avec des configurations plus robustes et équilibrées, les stratégies telles que celles suggérées dans la réponse de danlefree fonctionnent également.