Résumé
- Dans RFC 3384, les répliques multimaîtres devaient finir par exposer le même état, sans pour autant faire disparaître l’information qu’une résolution de conflit avait évincée.
- La valeur perdante devait être stockée, le conflit signalé à un administrateur et une reprise rester possible ; l’ordre d’arrivée des changements ne pouvait pas décider du résultat final.
Imaginons deux administrateurs modifiant le même attribut pendant une coupure réseau. Chacun travaille sur un maître autorisé à recevoir des écritures. À la reconnexion, les deux opérations sont valides dans leur histoire locale, mais toutes les répliques ne peuvent conserver deux réponses différentes si le système promet la convergence. Il faut choisir un état actif. C’est précisément au moment où le choix paraît terminé que RFC 3384 introduit une deuxième obligation : ne pas confondre un gagnant opérationnel avec l’effacement de l’alternative.
Publié en octobre 2002 dans la catégorie Informational, le texte rassemblait des exigences fondamentales pour une réplication LDAPv3 interopérable. Il ne livrait ni protocole complet ni algorithme universel de conflit. Son rôle était de tracer une frontière de conception : certaines solutions resteraient insuffisantes même si elles produisaient, à la fin, des écrans identiques.
LDAP normalisait déjà les échanges entre clients et serveurs. La réplication entre serveurs posait un problème différent. Elle pouvait rapprocher les données des utilisateurs, améliorer la disponibilité et permettre plusieurs points d’écriture, mais elle devait aussi transporter schéma, espace de noms, politiques d’accès et historique de changement à travers des pannes, des reprises et des topologies partielles.
RFC 3384 appelait « area of replication » une portion configurable de l’arbre d’information de l’annuaire. Les zones pouvaient se chevaucher ou s’imbriquer. Une réplique était une instance d’une zone, et un groupe de répliques rassemblait les serveurs qui la détenaient. L’accord de réplication devait préciser la zone, les paramètres d’accès, les identifiants, la confidentialité et le comportement de propagation. La convergence n’était donc pas un attribut abstrait du produit : elle dépendait d’un périmètre et d’un accord précis.
Le document examinait cinq modèles de cohérence. La cohérence transactionnelle évoquait les propriétés ACID, mais le coût et la complexité d’un commit distribué à deux phases conduisaient les auteurs à ne pas la poursuivre alors. Les exigences centrales visaient plutôt la cohérence éventuelle et la cohérence éventuelle à effort limité. Une divergence temporaire devenait une condition admise, non la preuve automatique d’un échec.
Cette latitude n’autorisait pas n’importe quel résultat. M3 demandait qu’un attribut converge vers le même ensemble de valeurs sur toutes les répliques qui détenaient l’entrée. MM6 formulait l’exigence pour les attributs et les entrées en contexte multimaître. Une panne pouvait retarder l’accord ; elle ne pouvait pas rendre l’accord facultatif.
Le multimaître rendait pourtant le conflit structurel. Plusieurs maîtres pouvaient accepter des écritures sans se consulter au préalable. Cette autonomie protégeait la disponibilité locale, mais créait deux histoires concurrentes quand des changements touchaient la même donnée avant leur échange. Une résolution déterministe devenait nécessaire.
Déterministe ne signifiait pas « dernier paquet reçu ». Deux répliques peuvent observer les mêmes mises à jour dans des ordres différents. Si chacune élit ce qu’elle a reçu en dernier, elles peuvent rester durablement en désaccord. MM7 interdisait donc de faire dépendre la convergence de l’arrivée ordonnée des changements. Le réseau transportait les décisions ; son calendrier accidentel ne devait pas leur attribuer l’autorité.
RFC 3384 ne choisissait ni horloge logique, ni format d’horodatage, ni priorité de serveur. Il imposait une propriété plus profonde : le mécanisme retenu devait permettre à des observateurs indépendants d’aboutir au même état dans le modèle annoncé. Le texte laissait les choix futurs ouverts tout en excluant les mécanismes dont la correction reposait sur une séquence incontrôlable.
MM5 ajoutait alors la contrainte décisive. La réplication multimaître ne devait pas perdre d’information. Si la résolution d’un conflit conduisait malgré tout à retirer une information de l’annuaire convergé, le processus devait la stocker, prévenir l’administrateur du conflit et de la perte, puis offrir un mécanisme permettant éventuellement de renverser la décision.
Cela ne voulait pas dire que les deux valeurs devaient rester simultanément actives. Une telle solution repousserait le conflit au lecteur. L’exigence séparait plutôt deux plans : un état courant unique, utilisable par les clients, et une capsule de preuve contenant ce que la règle automatique avait déplacé. L’administrateur pouvait comparer, comprendre et, si nécessaire, remplacer le gagnant.
Cette séparation rend la notion de cohérence plus exigeante qu’une égalité visuelle. Dix répliques affichant la même valeur prouvent que la propagation a produit un état commun. Elles ne prouvent pas que l’état est juste, que le conflit a été expliqué ou que la voie de retour subsiste. Une mesure « toutes les répliques sont vertes » couvre la couche visible, pas l’intégrité de l’historique.
M12 traitait une autre source de faux changement : la répétition. Un consommateur recevant deux fois la même mise à jour devait aboutir au même résultat que s’il ne l’avait reçue qu’une fois. Une connexion peut tomber après l’application mais avant l’accusé de réception. Sans idempotence, la reprise transformerait une incertitude de transport en mutation supplémentaire.
P6 demandait également de préserver l’atomicité promise par les opérations LDAP. Une opération composée ne pouvait apparaître à moitié appliquée simplement parce que ses éléments voyageaient entre serveurs. Toutefois, deux opérations atomiques concurrentes pouvaient encore être incompatibles. L’atomicité empêchait une écriture déchirée ; elle ne supprimait pas la coexistence de deux intentions valides.
Le document distinguait aussi conflit de données et conflit d’initiation. Si plusieurs maîtres tentaient simultanément d’ouvrir un cycle avec la même réplique, MM4 exigeait une résolution ou un évitement automatique. Une réplique occupée, une liaison perdue et une reprise planifiée relevaient de la coordination de session, pas nécessairement de la sémantique des valeurs.
L’observabilité appartenait à l’interopérabilité. AM2 imposait à chaque réplique un historique d’audit des serveurs avec lesquels elle avait échangé. AM4 et AM5 recommandaient de comparer deux répliques et de réparer leurs différences sans déclencher de nouveaux cycles. Initialiser une réplique vide, vérifier une divergence et remettre l’ensemble en cohérence ne devaient pas rester des promesses invisibles.
Certaines séquences gardaient néanmoins un sens causal. AM6 demandait de préserver l’ordre entre une information de contrôle d’accès et les données qu’elle gouvernait. Recevoir la donnée avant la règle qui l’autorise ou la protège peut créer un état provisoire doté d’une autre signification de sécurité. L’ordre d’arrivée général ne choisissait pas le gagnant, mais une relation explicite entre politique et donnée devait survivre.
Les incompatibilités de schéma devaient être détectées et signalées. La réplication couvrait définitions de schéma, attributs, valeurs, informations de contrôle d’accès, connaissances de l’annuaire et espace de noms, tout en excluant comme telles certaines données opérationnelles propres au DSA. Une réplique partielle restait possible, à condition que son périmètre ne soit pas ambigu.
Les exigences de sécurité séparaient authentification, autorisation, intégrité et confidentialité. Les sessions devaient prendre en charge l’authentification mutuelle et la vérification mutuelle des autorisations, ainsi que la protection des transferts. Le texte demandait aussi la prise en charge de sessions anonymes. Il ne les déclarait pas équivalentes ; il exigeait que le protocole puisse représenter des conditions de politique différentes.
La chronologie ultérieure aide à situer le document sans lui prêter des succès qu’il ne revendiquait pas. Les RFC 4510, 4511 et 4512 ont réorganisé la spécification technique LDAP. RFC 4533 a défini une opération de synchronisation de contenu, et RFC 5805 des transactions. Cette proximité ne démontre pas que les exigences multimaîtres de RFC 3384 furent toutes réalisées par ces mécanismes ou par un produit donné.
Le rapprochement avec RFC 3383, paru juste avant, clarifie deux surfaces de gouvernance. RFC 3383 répartissait les procédures d’enregistrement des identifiants d’extension LDAP afin de limiter les collisions dans l’espace de noms. RFC 3384 demandait comment réconcilier des copies quand des changements légitimes entraient en collision dans le temps. L’un organisait l’entrée des noms ; l’autre rendait le désaccord sur l’état traçable.
Le principe de spécification initiale minimale de Lu Heng éclaire la valeur d’un texte qui ne choisissait pas chaque algorithme. La spécification pouvait fixer le dommage interdit — convergence dépendante de l’arrivée, perte silencieuse, absence de recours — puis laisser aux travaux ultérieurs le choix local du mécanisme. La liberté technique restait réelle, mais elle ne comprenait pas la permission de détruire l’alternative.
Sa grille des couches de réalité rend le cœur de RFC 3384 particulièrement net. Écriture acceptée, mise à jour propagée, conflit détecté, gagnant actif, valeur déplacée conservée, administrateur averti et décision humaine finale sont sept faits distincts. Un tableau de bord qui les réduit à « synchronisé » transforme une chaîne de gouvernance en voyant vert.
La leçon historique tient donc en une inquiétude simple : un système distribué peut converger trop proprement. Il peut parvenir à une seule réponse en supprimant l’histoire qui permettrait de la contester. En exigeant la conservation de la valeur perdante, RFC 3384 faisait du conflit une décision auditable. Les répliques pouvaient s’accorder sans prétendre qu’elles n’avaient jamais divergé.
Sources
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance
