Dans tout environnement où les temps d'arrêt sont à prendre en considération, vous utilisez sûrement une sorte de grappe de serveurs pour augmenter la fiabilité par la redondance. Je sortirais un hôte du cluster, je le mettrais à jour, puis je le remettrais dans le cluster. Si vous avez une mise à jour qui ne peut pas être exécutée dans un environnement mixte (changement de schéma incompatible requis sur la base de données, par exemple), vous allez devoir arrêter tout le site, au moins pour un moment. L'astuce consiste à mettre en place les processus de remplacement avant d'abandonner les originaux.
En utilisant tomcat comme exemple - vous pouvez utiliser CATALINA_BASE pour définir un répertoire où se trouveront tous les répertoires de travail de tomcat, séparément du code exécutable. Chaque fois que je déploie un logiciel, je le déploie dans un nouveau répertoire de base afin que le nouveau code réside sur le disque à côté de l'ancien. Je peux ensuite démarrer une autre instance de tomcat qui pointe vers le nouveau répertoire de base, tout démarrer et fonctionner, puis échanger l'ancien processus (numéro de port) avec le nouveau dans l'équilibreur de charge.
Si je suis soucieux de préserver les données de session sur le commutateur, je peux configurer mon système de telle sorte que chaque hôte ait un partenaire auquel il réplique les données de session. Je peux laisser tomber l'un de ces hôtes, le mettre à jour, le faire remonter pour qu'il récupère les données de session, puis commuter les deux hôtes. Si j'ai plusieurs paires dans le cluster, je peux laisser tomber la moitié de toutes les paires, puis effectuer une commutation de masse, ou je peux le faire une paire à la fois, selon les exigences de la version, les exigences de l'entreprise, etc. Personnellement, cependant, je préfère permettre aux utilisateurs finaux de subir la perte très occasionnelle d'une session active plutôt que d'essayer d'effectuer une mise à niveau avec des sessions intactes.
Il s'agit d'un compromis entre l'infrastructure informatique, la complexité du processus de publication et l'effort des développeurs. Si votre cluster est assez grand et votre désir assez fort, il est assez facile de concevoir un système qui peut être remplacé sans aucun temps d'arrêt pour la plupart des mises à jour. Les changements de schéma importants nécessitent souvent un temps d'arrêt réel, car le logiciel mis à jour ne peut généralement pas s'adapter à l'ancien schéma, et vous ne pouvez probablement pas vous en sortir en copiant les données dans une nouvelle instance de base de données, en effectuant la mise à jour du schéma, puis en basculant les serveurs sur la nouvelle base de données, car vous aurez perdu toutes les données écrites dans l'ancienne base de données après que la nouvelle ait été clonée. Bien sûr, si vous disposez des ressources nécessaires, vous pouvez charger les développeurs de modifier la nouvelle application afin d'utiliser les nouveaux noms de tables pour toutes les tables mises à jour, et vous pouvez mettre en place des déclencheurs sur la base de données active qui mettront correctement à jour les nouvelles tables avec les données écrites dans les anciennes tables par la version précédente (ou peut-être utiliser des vues pour émuler un schéma à partir de l'autre). Mettez en place vos nouveaux serveurs d'applications et insérez-les dans le cluster. Il y a une tonne de jeux que vous pouvez jouer afin de minimiser les temps d'arrêt si vous avez les ressources de développement pour les construire.
Le mécanisme le plus utile pour réduire les temps d'arrêt lors des mises à jour logicielles consiste peut-être à s'assurer que votre application peut fonctionner en mode lecture seule. Cela permettra à vos utilisateurs de disposer de certaines fonctionnalités nécessaires, mais vous laissera la possibilité d'effectuer des changements à l'échelle du système qui nécessitent des modifications de la base de données, etc. Placez votre application en mode lecture seule, puis clonez les données, mettez à jour le schéma, mettez en place de nouveaux serveurs d'applications sur la nouvelle base de données, puis modifiez l'équilibreur de charge pour utiliser les nouveaux serveurs d'applications. Le seul temps d'arrêt est le temps nécessaire pour passer en mode lecture seule et le temps nécessaire pour modifier la configuration de votre équilibreur de charge (la plupart d'entre eux peuvent le gérer sans aucun temps d'arrêt).
