Le titre "disponibilité des services", et on parle répartition de charge
Je ne comprends pas cette remarque : à quoi peut bien servir la répartition de charge si ce n'est pas pour améliorer la disponibilité de ses services ? Parmi mes nombreux défauts j'ai aussi celui de ne pas être un geek, je ne fais de la technique que pour répondre à un besoin, pas pour la beauté conceptuelle ou technique du geste.
Ce n'est pas du tout conceptuel, ce sont deux choses totalement différentes, la répartition de charge et la gestion de la haute dispo. Connectées, mais différentes.
Côté répartition de charge, tu l'as expliqué, on a le round robbin, le least connection, bref un ensemble de techniques pour distribuer la charge plus ou moins justement sur un ensemble de serveurs, tous actifs.
Côté haute dispo, la virtual ip du service qui se balade du serveur actif au passif, la bascule d'une BDD avec linux ha (ou l'équivalent à la mode du moment), la redondance du stockage.
On fait plus souvent de la haute dispo sans répartition de charge, pour s'assurer la disponibilité d'une base de donnée par exemple. On met un mysql ou un postgresql en cluster actif/passif, et on bascule les clients (par modif de conf et arrêt/relance, ou par gestion de la couche client qui se connecter).
La répartition de charge sans haute dispo, google fait ça. Il faut du shared nothing sur des zilliards de serveur, ça monte très bien en charge, on peut rajouter des noeuds sans s'embêter. Et tant pis si le crash d'un serveur prive de service 0.1% des utilisateurs. Parce que c'est compliqué de faire de la haute dispo sur toute la chaine, c'est souvent plus simple, moins complexe à gérer, d'accepter une certaine perte de service pour une partie des utilisateurs.
Là dans la dépêche par exemple, on parle surtout faire du Load balancing / high availibility sur du service HTTP. Mais ça parle du serveur NFS pour stocker les sessions utilisateurs. Si le serveur NFS n'est pas là, tout le service est indisponible (en tout cas, le test de vie applicatif devrait échouer). Le maillon le plus faible conditionne la disponibilité de l'ensemble.
La répartition de charge sur des services autre que http, c'est moins courant par contre. Côté BDD relationnelle on a tendance à pas trop s'embêter avec ça, et si on veut pas de relationnel (ou qu'on peut s'en passer) il reste les quelques nosql prévus pour ça, comme Cassandra ou Couchdb.
Côté système de fichier, les rares qui gèrent ça (de ma faible expérience, j'en ai pas testé des masses) ont tendance à être compliqués à mettre en place, pour des perfs assez aléatoires.
On peut toujours mettre un test de vie et envoyer les utilisateurs vers un autre serveur, mais comme les serveurs ne partagent rien, l'utilisateur perd la session, et donc ce qu'il était en train de faire. La haute dispo du pauvre.
[^] # Re: Titre de l'article
Posté par hermenegilde . En réponse à la dépêche Améliorer la disponibilité de ses services. Évalué à 7.
Ce n'est pas du tout conceptuel, ce sont deux choses totalement différentes, la répartition de charge et la gestion de la haute dispo. Connectées, mais différentes.
Côté répartition de charge, tu l'as expliqué, on a le round robbin, le least connection, bref un ensemble de techniques pour distribuer la charge plus ou moins justement sur un ensemble de serveurs, tous actifs.
Côté haute dispo, la virtual ip du service qui se balade du serveur actif au passif, la bascule d'une BDD avec linux ha (ou l'équivalent à la mode du moment), la redondance du stockage.
On fait plus souvent de la haute dispo sans répartition de charge, pour s'assurer la disponibilité d'une base de donnée par exemple. On met un mysql ou un postgresql en cluster actif/passif, et on bascule les clients (par modif de conf et arrêt/relance, ou par gestion de la couche client qui se connecter).
La répartition de charge sans haute dispo, google fait ça. Il faut du shared nothing sur des zilliards de serveur, ça monte très bien en charge, on peut rajouter des noeuds sans s'embêter. Et tant pis si le crash d'un serveur prive de service 0.1% des utilisateurs. Parce que c'est compliqué de faire de la haute dispo sur toute la chaine, c'est souvent plus simple, moins complexe à gérer, d'accepter une certaine perte de service pour une partie des utilisateurs.
Là dans la dépêche par exemple, on parle surtout faire du Load balancing / high availibility sur du service HTTP. Mais ça parle du serveur NFS pour stocker les sessions utilisateurs. Si le serveur NFS n'est pas là, tout le service est indisponible (en tout cas, le test de vie applicatif devrait échouer). Le maillon le plus faible conditionne la disponibilité de l'ensemble.
La répartition de charge sur des services autre que http, c'est moins courant par contre. Côté BDD relationnelle on a tendance à pas trop s'embêter avec ça, et si on veut pas de relationnel (ou qu'on peut s'en passer) il reste les quelques nosql prévus pour ça, comme Cassandra ou Couchdb.
Côté système de fichier, les rares qui gèrent ça (de ma faible expérience, j'en ai pas testé des masses) ont tendance à être compliqués à mettre en place, pour des perfs assez aléatoires.
On peut toujours mettre un test de vie et envoyer les utilisateurs vers un autre serveur, mais comme les serveurs ne partagent rien, l'utilisateur perd la session, et donc ce qu'il était en train de faire. La haute dispo du pauvre.