Serveur HTTP Apache Version 2.5
Serveur HTTP Apache Version 2.5
| Description: | Inscription dynamique comme membre d’un répartiteur de charge où les serveurs dorsaux s’annoncent eux-mêmes au mandataire inverse à l’aide de datagrammes UDP unicast |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | proxy_beacon_module |
| Fichier Source: | mod_proxy_beacon.c |
| Compatibilité: | Disponible à partir de la version 2.5 du serveur HTTP Apache |
Ce module permet à des serveurs dorsaux de s’annoncer eux-mêmes
à un mandataire inverse frontal qui les ajoute alors en tant que membre
actif (worker) d’un répartiteur de charge de
mod_proxy_balancer. Lorsqu’un serveur dorsal cesse de
s’annoncer, le mandataire l’enlève de la rotation. Cela permet une gestion
autonome (inscriptions et maintenance) de la liste des membres du
répartiteur sans avoir à éditer la configuration du mandataire ou piloter le
balancer-manager à la main.
La communication utilise des datagrammes pleinement unicast UDP (pas de multicast qui est filtré sur la plupart des réseaux et ne passe pas sur l’Internet public). Les données sont transmises du serveur dorsal vers le mandataire :
ProxyBeaconListen).ProxyBeaconAddress), indiquant son propre URL
routable (ProxyBeaconAdvertise).Les datagrammes sont envoyés en mode « fire-and-forget » : une annonce perdue est récupérée par la prochaine annonce périodique, et le réordonnancement est rejeté par une vérification d’horodatage par serveur dorsal ; aucune connexion, reconnection ou couche de cadrage n’est donc nécessaire.
Au niveau du mandataire, la directive
ProxyBeaconBalancer nomme le répartiteur de charge
auquel des serveurs dorsaux qui se sont annoncés ont été ajoutés. Les
changements d’appartenance s’appliquent en utilisant le même mécanisme
interne que l’interface web balancer-manager ; un serveur
dorsal ajouté de cette manière se comporte donc exactement comme un
BalancerMember configuré
statiquement ou ajouté manuellement, et est visible et éditable dans
balancer-manager.
Ce module nécessite les services de mod_watchdog et
mod_proxy_balancer. Le travail d’arrière-plan (écoute,
publication, ajout et suppression de membres) est effectué par un seul
processus enfant de mod_watchdog ; il n’est donc pas
disponible avec le comportement du MPM prefork où ce singleton
ne peut pas s’exécuter.
Tout hôte qui peut atteindre le port de réception du mandataire peut
aussi annoncer un URL de serveur dorsal arbitraire et faire que le
mandataire envoie le trafic du client à ce dernier (et une adresse source
UDP est facile à usurper). Définissez la directive
ProxyBeaconSecret à la même valeur sur le mandataire
et sur chaque serveur dorsal de façon que les annonces soient authentifiées
avec un message-authentication code (MAC) avec clé et un horodatage.
Lorsqu’une phrase secrète est configurée, le mandataire rejette toute
annonce qui n’est pas valablement signée et récente. Si aucune phrase
secrète n’est configurée, le canal n’est pas authentifié et
le mandataire journalise un avertissement au démarrage.
Les annonces sont authentifiées mais non chiffrées ; la charge utile comporte des métadonnées opérationnelles (URLs de serveur dorsal) non chiffrées. La confidentialité du transport (par exemple DTLS) n’est actuellement pas prise en charge et fera l’objet d’une couche séparée.
ProxyBeaconAddress ProxyBeaconAdvertise ProxyBeaconBalancer ProxyBeaconInterval ProxyBeaconListen ProxyBeaconMaxSkew ProxyBeaconSecret ProxyBeaconTimeout
L’exemple suivant configure un répartiteur de charge à enregistrement
autonome. Les serveurs dorsaux n’ont pas besoin de se connaître entre eux et
le mandataire n’a pas besoin d’entrées BalancerMember prédéclarées — seulement
un répartiteur vide avec de la place pour grossir.
Sur le mandataire inverse :
# Réception des annonces des serveurs dorsaux sur # l’interface réseau de cluster (UDP). ProxyBeaconListen 0.0.0.0:5555 ProxyBeaconSecret "une_grande_phrase_secrète_partagée_aléatoire_de_cluster" ProxyBeaconBalancer cluster # Un serveur dorsal est éjecté de la rotation s’il ne # s’annonce pas pendant 30 secondes. ProxyBeaconTimeout 30 # Un répartiteur initialement vide avec des emplacements # libres pour les membres dynamiques. <Proxy balancer://cluster> ProxySet growth=16 </Proxy> ProxyPass "/" "balancer://cluster/" ProxyPassReverse "/" "balancer://cluster/"
Sur chaque serveur dorsal :
# Annoncer au mandataire cette adresse routable de serveur dorsal # toutes les 10 secondes (UDP). ProxyBeaconAddress proxy.example.com:5555 ProxyBeaconAdvertise http://10.0.0.5:8080 ProxyBeaconSecret "une_grande_phrase_secrète_partagée_aléatoire_de_cluster" ProxyBeaconInterval 10
Au démarrage d’un serveur dorsal, ce dernier commence à s’annoncer. Le
mandataire vérifie la validité de chaque annonce à l’aide de la phrase
secrète, ajoute http://10.0.0.5:8080 comme membre de
balancer://cluster, et l’active. Si ce serveur dorsal arrête de
s’annoncer pendant une durée supérieure à la valeur de la directive
ProxyBeaconTimeout, le mandataire le désactive (en
l’enlevant de la rotation) ; si le serveur dorsal s’annonce à nouveau, il
est réactivé.
Un serveur dorsal ajouté à l’exécution occupe un des emplacements
du répartiteur pour la durée de vie du processus serveur ; plutôt que de le
supprimer lorsqu’il arrête de s’annoncer, il est désactivé, suivant en cela
le comportement du balancer-manager (qui peut ajouter des
membres à l’exécution, mais pas les supprimer). La taille du répartiteur
augmente jusqu’au nombre maximal de serveurs dorsaux que vous
souhaitez enregistrer.
| Description: | Adresse du mandataire inverse à laquelle un serveur dorsal envoie ses annonces |
|---|---|
| Syntaxe: | ProxyBeaconAddress address:port |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_proxy_beacon |
La directive ProxyBeaconAddress marque un serveur
comme émetteur d’annonces (un serveur dorsal). Ce dernier envoie
des datagrammes UDP à l’adresse ProxyBeaconListen du
mandataire sous la forme adresse:port, par exemple
proxy.example.com:5555 (un préfixe de protocole tel que
tcp:// est accepté, mais ignoré). Étant donné que UDP est sans
connexion, un serveur dorsal peut être démarré avant que le mandataire soit
disponible : les datagrammes seront simplement supprimés et continueront à
être envoyés selon l’intervalle spécifié.
Utilisez la directive ProxyBeaconAdvertise pour
spécifier l’URL routable qu’annonce le serveur dorsal. Les
directives ProxyBeaconListen et
ProxyBeaconAddress sont mutuellement exclusives sur
un même serveur.
| Description: | L’URL routable qu’annonce le serveur dorsal au mandataire inverse |
|---|---|
| Syntaxe: | ProxyBeaconAdvertise url |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_proxy_beacon |
La directive ProxyBeaconAdvertise permet de
définir l’adresse à laquelle le serveur dorsal peut être atteint (par
exemple http://10.0.0.5:8080) et que le mandataire ajoutera en
tant que membre BalancerMember.
Il doit s’agir d’un URL complet comme scheme://host[:port] que
le mandataire pourra atteindre — pas l’adresse d’écoute locale —
et qui sera validé lors de l’analyse de la configuration.
Cette directive est utilisée sur un serveur dorsal avec la directive
ProxyBeaconAddress. Si elle est omise, le serveur
dorsal envoie quand-même un signe de vie, mais pas d’URL ; le mandataire
journalise alors l’annonce sans ajouter de membre.
| Description: | Le nom du répartiteur de charge auquel les serveurs dorsaux annoncés sont ajoutés |
|---|---|
| Syntaxe: | ProxyBeaconBalancer name |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_proxy_beacon |
La directive ProxyBeaconBalancer permet de nommer
le répartiteur, sur le mandataire inverse, dans lequel les serveurs dorsaux
annoncés sont insérés en tant que membres. Indiquez seulement le nom du
répartiteur (par exemple cluster pour
balancer://cluster) ; le préfixe balancer:// est
accepté et supprimé.
Le répartiteur nommé doit exister et disposer d’emplacements vides.
Déclarez-le dans un bloc <Proxy> avec un paramètre
growth (ou utilisez la valeur de la directive BalancerGrowth) de façon qu’il y ait des
emplacements libres pour l’ajout dynamique de membres. Cette directive est
utilisée conjointement avec la directive
ProxyBeaconListen.
| Description: | Périodicité de l’envoi d’annonces par le serveur dorsal |
|---|---|
| Syntaxe: | ProxyBeaconInterval interval |
| Défaut: | ProxyBeaconInterval 5 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_proxy_beacon |
La directive ProxyBeaconInterval permet de définir
la périodicité à laquelle un serveur dorsal (un serveur
ProxyBeaconAddress) envoie ses annonces. Elle utilise
la syntaxe de la directive time-interval et sa valeur s’exprime
par défaut en secondes ; sa valeur par défaut est 5 secondes.
L’intervalle doit être significativement plus petit que la valeur de la
directive ProxyBeaconTimeout, de façon qu’une perte
occasionnelle ou qu’une annonce retardée ne provoquent pas l’éviction d’un
serveur dorsal opérationnel.
| Description: | Adresse sur laquelle le mandataire inverse reçoit les annonces des serveurs dorsaux |
|---|---|
| Syntaxe: | ProxyBeaconListen [address][:port] |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_proxy_beacon |
La directive ProxyBeaconListen marque un serveur
comme récepteur « phare » (le mandataire inverse). Il lie un socket
UDP à l’adresse spécifiée, par exemple 0.0.0.0:5555 pour
effectuer la réception sur toutes les interfaces. Un préfixe de protocole
(tel que tcp://) est accepté et ignoré.
L’adresse et le port sont facultatifs et, s’ils sont omis, sont hérités
de l’adresse et du port de ce serveur (ses directives Listen et ServerName). Si aucun argument n’est fourni,
l’écouteur du « phare » lie les propres adresse et port du serveur ; si
seule l’adresse est donnée, le port est hérité, et ainsi de suite. Étant
donné que UDP et TCP sont des espaces de port indépendants, lier le socket
du « phare » au port du serveur n’entre pas en collision avec
l’écouteur TCP du serveur — faisant que le canal du « phare » partage
le point de terminaison du service, qui identifie aussi le mandataire auprès
des serveurs dorsaux avec son adresse réelle (comme l’écouteur effectue ses
liens dans un processus enfant non privilégié, un port privilégié comme 80
ou 443 ne peut pas être partagé de cette manière ; n’utilisez le port du
serveur que s’il est non privilégié).
Les serveurs dorsaux envoient leurs annonces à l’adresse spécifiée par la
directive ProxyBeaconAddress. Cette dernière doit
être utilisée conjointement avec la directive
ProxyBeaconBalancer ; dans le cas contraire, les
annonces sont reçues et journalisées, mais aucun membre n’est ajouté. Les
directives ProxyBeaconListen et
ProxyBeaconAddress sont mutuellement exclusives sur
un même serveur.
| Description: | Age maximal autorisé d’une annonce signée |
|---|---|
| Syntaxe: | ProxyBeaconMaxSkew interval |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_proxy_beacon |
La directive ProxyBeaconMaxSkew permet de définir
la fenêtre anti-réémission utilisée lorsque la directive
ProxyBeaconSecret est configurée : le mandataire
rejette toute annonce dont l’horodatage signé diffère du temps actuel d’une
valeur supérieure à celle de la directive
ProxyBeaconMaxSkew, et cela dans les deux directions.
Cette directive utilise la syntaxe de la directive time-interval et sa valeur s’exprime
par défaut en secondes.
Si elle n’est pas définie, sa valeur par défaut est de 30 secondes. Une
fenêtre plus large tolère des écarts d’horloge plus grands entre les hôtes ;
une fenêtre plus petite restreint la tolérance sur la vérification de
fraîcheur. Notez que la vérification de la croissance stricte des
horodatages d’un même serveur (voir la directive
ProxyBeaconSecret) bloque les réémissions, quelle que
soit la valeur de cette fenêtre. Cette directive est utilisée au niveau du
mandataire.
| Description: | Phrase secrète partagée à l’avance pour authentifier les annonces des serveurs dorsaux |
|---|---|
| Syntaxe: | ProxyBeaconSecret secret |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_proxy_beacon |
La directive ProxyBeaconSecret permet de définir
une phrase secrète partagée à l’avance au sein de la grappe de serveurs.
Elle doit être définie avec la même valeur sur le mandataire
inverse et sur chaque serveur dorsal. Le serveur dorsal (l’émetteur) signe
chaque annonce avec un message-authentication code (un SipHash MAC) avec
clé, dérivé de la phrase secrète et avec un horodatage ; le mandataire (le
récepteur) recalcule le MAC et vérifie l’horodatage, en rejetant toute
annonce falsifiée, usurpée ou réenvoyée. Les messages réenvoyés sont
interceptés de deux manières : une fenêtre de fraîcheur (directive
ProxyBeaconMaxSkew) rejette les horodatages anciens,
et une vérification pour chaque serveur dorsal rejette toute annonce dont
l’horodatage n’avance pas strictement ; ainsi, un message capturé et renvoyé
(par exemple pour empêcher l’éviction d’un serveur dorsal éteint) sera
rejeté.
Si la directive ProxyBeaconSecret est définie sur
le mandataire, chaque annonce doit comporter un MAC valable et récent, sous
peine d’être rejetée. Si les phrases secrètes du mandataire et d’un serveur
dorsal diffèrent, les annonces de ce dernier seront rejetées silencieusement
(et journalisées), ce qui donne l’impression que le serveur dorsal n’a
jamais atteint le répartiteur de charge.
Si aucune phrase secrète n’est configurée, le canal n’est pas authentifié et le mandataire émet un avertissement lorsqu’il commence à écouter. Étant donné que la phrase secrète est stockée dans le fichier de configuration, définissez les permissions de ce dernier comme s’il s’agissait d’une clé privée.
La protection contre la réémission basée sur l’horodatage compare le
moment de l’annonce avec l’horloge du mandataire ; le mandataire et les
serveurs dorsaux doivent donc avoir des horloges correctement synchronisées
(par exemple à l’aide de NTP). Voir la directive
ProxyBeaconMaxSkew.
| Description: | Durée maximale de l’absence d’annonce d’un serveur dorsal au bout de laquelle le mandataire enlève ce dernier de la rotation |
|---|---|
| Syntaxe: | ProxyBeaconTimeout interval |
| Défaut: | ProxyBeaconTimeout 0 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_proxy_beacon |
La directive ProxyBeaconTimeout permet de définir
la durée maximale pendant laquelle le mandataire attendra une annonce en
provenance d’un serveur dorsal avant de désactiver ce dernier (en l’enlevant
de la rotation). Si ce serveur dorsal renvoie une annonce par la suite, il
est réactivé. Cette directive utilise
la syntaxe de la directive time-interval et sa valeur s’exprime
par défaut en secondes.
La valeur par défaut, 0, désactive complètement l’éviction :
les serveurs dorsaux sont ajoutés lorsqu’ils s’annoncent mais ne sont jamais
désactivés automatiquement. Définissez cette directive à un multiple de
(quelques fois) la valeur de la directive
ProxyBeaconInterval du serveur dorsal pour mettre en
œuvre une maintenance autonome des adhésions. Cette directive est définie
sur le mandataire.