Attention : cluster ne veut pas dire calcul distribué ici ;-)
J'emploie le terme cluster au sens plusieurs machines. Dans ton cas, si tu es sur une base Etcd par exemple avec 3 machines, les sessions peuvent être en RAM car la probabilité de perdre les 3 noeuds est faible. Ainsi, tu peux mettre à jour un nœud, le rebooter puis le faire sur les suivants...
Moins il y a de données en dur qui doivent être persistantes, plus c'est facile de mettre le service dans un conteneur, on est plus en mode "cloud". L'idéal est la VM virtuelle qu'on met à la poubelle à chaque reboot.
Pour Glewlwyd, cela pourrait apporter une certaine robustesse d'administration, de déploiement... Plus trop à s'inquiéter du SPoF (Single Point of Failure). Tu installes cela dans un cluster kubernetes et hop, le truc tourne tout seul ;-)
[^] # Re: Base de données
Posté par Sytoka Modon (site web personnel) . En réponse au journal Sortie de Glewlwyd 2.0, serveur SSO. Évalué à 2.
Attention : cluster ne veut pas dire calcul distribué ici ;-)
J'emploie le terme cluster au sens plusieurs machines. Dans ton cas, si tu es sur une base Etcd par exemple avec 3 machines, les sessions peuvent être en RAM car la probabilité de perdre les 3 noeuds est faible. Ainsi, tu peux mettre à jour un nœud, le rebooter puis le faire sur les suivants...
Moins il y a de données en dur qui doivent être persistantes, plus c'est facile de mettre le service dans un conteneur, on est plus en mode "cloud". L'idéal est la VM virtuelle qu'on met à la poubelle à chaque reboot.
Pour Glewlwyd, cela pourrait apporter une certaine robustesse d'administration, de déploiement... Plus trop à s'inquiéter du SPoF (Single Point of Failure). Tu installes cela dans un cluster kubernetes et hop, le truc tourne tout seul ;-)