Je suis Charlie

Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

Mon livre « Cyberstructure »

Ève

RFC 4678: Server/Application State Protocol v1

Date de publication du RFC : Septembre 2006
Auteur(s) du RFC : A. Bivens (IBM)
Pour information
Première rédaction de cet article le 15 octobre 2006


Le succès de l'Internet et des service auquel il donne accés a entrainé une très forte pression sur certains serveurs populaires. Beaucoup de sites Web, comme Google ou Amazon ne pourraient plus, depuis longtemps, tenir le coup avec une seule machine, si puissante soit-elle. Aussi la plupart des gros services sont désormais répartis en plusieurs machines et c'est souvent un répartiteur (load balancer) qui assure la distribution de charge entre ces machines. Notre RFC spécifie un protocole pour piloter ces répartiteurs.

Certains protocoles ont dès le début été conçus pour que le service puisse être assuré par plusieurs machines. C'est notamment le cas du DNS, où les enregistrements de type NS (name server) sont toujours multiples (la plupart des registres, suivant le RFC 1034, exigent au moins deux serveurs). Pour les autres protocoles, une solution élégante existe, les enregistrements DNS de type SRV (server), spécifiés dans le RFC 2782, mais qui n'ont jamais été réellement déployés. Ils permettraient notamment de résoudre le problème de la répartition de charge des serveurs Web.

En attendant une solution dans le protocole, l'approche la plus répandue est de mettre un groupe, une ferme, de serveurs derrière un répartiteur. Celui-ci peut être une machine spécialisée, une boîte noire (appliance), ou bien il peut être un logiciel, comme pen. Le contrôle de ces répartiteurs se fait toujours par un protocole privé, et c'est là qu'intervient notre RFC. (Notons que les solutions comme CARP assurent la redondance mais pas vraiment la répartition de charge.)

Notre RFC (dont il faut noter qu'il est de statut Informational ce qui signifie qu'il n'est pas approuvé par l'IETF) propose donc un nouveau protocole, SASP (Server/Application State Protocol), qui sert à la communication entre un contrôleur, le GWM (Group Workload Manager) et, d'une part le répartiteur (appelé LB pour load balancer) et d'autre part les serveurs effectifs.

Les messages envoyés en SASP permettent ensuite aux acteurs (LB et serveurs) de s'enregistrer auprès du GWM et de lui indiquer leur état, ce qui permet de leur envoyer plus ou moins de trafic.

On notera enfin un point de sécurité important : SASP, conçu pour des environnements fermés (réseaux privés, probablement avec adresses IP privées et coupe-feu devant), n'a pratiquement pas de sécurité. La section 10 du RFC explique ce point et propose des solutions, typiquement l'utilisation de TLS.


Téléchargez le RFC 4678

Version PDF de cette page (mais vous pouvez aussi imprimer depuis votre navigateur, il y a une feuille de style prévue pour cela)

Source XML de cette page (cette page est distribuée sous les termes de la licence GFDL)