Chapitre 27. Les architectures de référence : motifs, zones, tenants

Objectifs pédagogiques

Passer du raisonnement par machine au raisonnement par zones et par flux. Décrire les quatre motifs canoniques avec ce que chacun tolère, coûte et ne promet pas. Découper une installation en tiers. Dimensionner par les vrais moteurs de charge. Situer les namespaces Enterprise. Appliquer la grille de lecture à six colonnes.

Prérequis

Chapitre 5 (les frontières de confiance, que la grille systématise), chapitre 24 (l'arithmétique des quorums), chapitre 26 (l'actif seul porte la charge).

Cours

27.1 Changer d'unité : de la machine au flux

Jusqu'ici, le cursus a raisonné machine par machine. L'architecte raisonne autrement : son unité est la zone, un ensemble de machines au même niveau d'exposition, et le flux, une communication autorisée entre deux zones, avec un port, un sens et un besoin nommé.

Le changement n'est pas cosmétique. C'est lui qui rend une installation auditable : la question « qui peut parler à qui » a une réponse en table, pas en archéologie de pare-feu. Et défendable : chaque flux existant se justifie, chaque flux absent est un refus par défaut, le chapitre 11 appliqué au réseau.

La règle d'écriture qui en découle tiendra toute la partie : un flux est une ligne, avec source, destination, port, sens, besoin et chapitre de justification. Tout ce qui n'est pas une ligne n'existe pas. La matrice de flux devient le deuxième livrable de l'architecte, à côté du schéma.

27.2 Les quatre motifs canoniques

Toute architecture Vault réelle est une variation de quatre motifs, à connaître avec leurs promesses et leurs limites.

Motif	Tolère	Limite principale
Mono-nœud durci	aucune panne	promet une reprise, pas une continuité
Cluster simple	la panne d'une machine	l'adresse d'entrée et la perte de site restent ouvertes
Cluster à entrée répartie	idem, avec bascule invisible des clients	une pièce de plus à durcir, point unique si elle est seule
Multi-cluster répliqué	la perte de site, en édition Enterprise	licence, et complexité de gouvernance

En édition Community, l'équivalent fonctionnel de la reprise s'obtient par la restauration de snapshots sur un site secondaire, avec un objectif de reprise en heures, pas en secondes.

Le choix entre motifs n'est jamais esthétique : il se dérive de deux chiffres que la direction doit donner, l'indisponibilité tolérée et la perte de données tolérée. Le chapitre 34 leur donnera leurs noms d'exploitation.

27.3 Les tiers et les zones

Le découpage de référence distingue cinq tiers, que le fil rouge habite déjà sans les avoir nommés.

Le tier des consommateurs : les applications et les humains, demain le cluster Kubernetes. Il ne connaît qu'une adresse, l'entrée.

Le tier d'entrée : le répartiteur, seule surface que les consommateurs touchent.

Le tier des serveurs : les trois nœuds, qui ne parlent qu'entre eux, à l'entrée et au gardien.

Le tier du gardien et de l'administration : transit-01 et le poste d'administration, la zone la plus protégée, celle dont la compromission vaut le plus cher.

Le tier d'observation : monitor-01, qui reçoit journaux et métriques de tous et n'initie rien vers eux. Le chapitre 30 dira pourquoi ce sens unique est une propriété de sécurité.

Et une discipline : les flux descendent la liste plus difficilement qu'ils ne la montent. Un consommateur n'atteint jamais un nœud en direct, encore moins le gardien. L'administration atteint tout, mais depuis une seule zone et par des chemins nominatifs.

27.4 Dimensionner sans folklore

Le dimensionnement de Vault a une particularité que le chapitre 26 a établie : en édition Community, l'actif seul porte la charge. On dimensionne un serveur, répliqué trois fois pour la relève, pas un cluster de capacité.

Les moteurs de charge réels, par ordre d'importance habituel. Le rythme des baux et des logins : chaque émission dynamique, et chaque authentification qui produit un token de service, est une écriture Raft engagée à la majorité, et c'est le coût qui surprend. Les tokens batch échappent à cette écriture, puisqu'ils ne sont pas persistés (chapitre 12) : c'est le levier de dimensionnement à connaître pour les flottes à très haut volume éphémère. Les opérations Transit, du calcul par requête qui suit le trafic applicatif. Le débit d'audit, chaque requête étant journalisée. Et la taille du stockage, tirée par les objets à cycle de vie et presque jamais par KV.

L'ordre de grandeur d'entrée pour une production de la taille d'Astrea : quelques cœurs et huit à seize gigaoctets de mémoire par nœud, du disque rapide pour le journal. Puis la vérité : on commence mesuré et on révise sur métriques. Un dimensionnement sans mesure est une opinion, et la révision fait partie de l'architecture, pas de son échec.

27.5 Enterprise : les namespaces

Quand plusieurs organisations logiques doivent cohabiter, l'édition Enterprise propose les namespaces : des Vault logiques dans un même cluster, chacun avec ses montages, ses méthodes, ses policies et ses identités, et surtout son administration déléguée. L'administrateur d'un namespace gouverne son monde sans rien voir du voisin, sous un administrateur racine qui gouverne l'ensemble.

Il faut énoncer aussi nettement ce que les namespaces ne remplacent pas : ils partagent le cluster, donc la panne, la version, le seal, la juridiction et les performances. Un besoin d'isolement de destin appelle des clusters séparés, pas des namespaces.

En édition Community, la colocation se fait avec les outils des parties IV et V : montages dédiés, préfixes, policies, groupes. C'est un cloisonnement d'autorisation solide, sans délégation d'administration. La limite se connaît et se consigne.

27.6 La grille de lecture

Six colonnes, dans cet ordre, parce que chacune prépare la suivante.

Les actifs sont ce qui a de la valeur : non pas le serveur, mais les objets précis dont la perte ou la fuite coûte, le stockage chiffré, la clé d'enveloppe, les parts, les journaux, les sauvegardes.

Les menaces : qui en veut aux actifs, avec quels moyens. L'externe réseau, l'interne applicatif, l'interne administrateur, l'accès physique, la chaîne d'approvisionnement.

Les frontières de confiance : les lignes du schéma où le niveau de confiance change, et que tout flux qui les traverse doit justifier.

La surface d'attaque : l'inventaire exhaustif de ce qui est atteignable depuis chaque côté de chaque frontière, ports, endpoints, chemins d'administration.

Les contrôles : ce qui est en face, préventif, détectif ou correctif, avec le chapitre qui l'a construit.

Les risques résiduels : ce qui reste après les contrôles, nommé, chiffré quand c'est possible, accepté par quelqu'un qui a le droit de l'accepter, daté, muni d'un critère de révision.

La sixième colonne est la signature de la grille : une analyse qui n'avoue aucun risque résiduel n'est pas une analyse, c'est une publicité.

Pour fixer la méthode, appliquons-la en miniature au mono-nœud du chapitre 7. Actifs : le stockage, les cinq parts, le token racine d'amorçage. Menaces : le voleur de disque, l'administrateur système. Frontières : le port de service, la console de l'hôte. Surface : ce port, l'accès d'administration, l'hyperviseur. Contrôles : barrière, TLS, quorum, audit. Résiduels : zéro tolérance de panne, accepté pour un laboratoire, et l'administrateur de l'hôte voit la mémoire, accepté et mitigé par une liste courte. Six lignes, et le mono-nœud est lisible.

Exemple : la revue du dossier prestataire

Astrea reçoit d'un intégrateur une proposition d'architecture haute disponibilité clé en main, et l'équipe la lit avec la grille.

Le dossier propose quatre nœuds pour la symétrie des baies, un répartiteur qui termine TLS pour inspecter les requêtes, les quatre machines sur le même hyperviseur mutualisé pour la simplicité d'exploitation, et aucune section sur les risques restants.

La lecture produit quatre lignes rouges.

Quatre nœuds : majorité à trois, donc la tolérance de trois nœuds au prix de quatre. On écrit trois ou cinq.

TLS terminé à l'entrée : le répartiteur voit tous les secrets en clair. Il devient l'actif le plus précieux du dessin sans en avoir les protections.

Un seul hyperviseur : les pannes ne sont plus indépendantes, et son administrateur tient à lui seul la paire fatale du chapitre 23.

Aucun risque résiduel : la sixième colonne vide disqualifie le dossier plus sûrement que les trois erreurs. Une architecture qui n'avoue rien n'a pas été analysée.

La réponse d'Astrea tient en une page : la grille remplie à leur place, et l'invitation à revenir avec la sixième colonne écrite.

Sécurité : l'architecture comme document

Le schéma et la matrice de flux sont des documents sensibles, et la matrice est un contrat plutôt qu'une photo. Ils donnent à un attaquant la carte qu'il passerait des semaines à reconstituer, ce qui impose de les gouverner sans tomber dans le secret absolu qui empêcherait les revues. Et chaque ligne se vérifie contre la réalité, à la recette puis en revue périodique : une matrice qui diverge du réel est pire qu'absente, elle rassure à tort.

Les tiers ne valent que par leurs frontières. Découper en zones sans contrôle aux passages produit un beau dessin et aucune sécurité. Chaque frontière doit pointer vers un mécanisme réel.

Le dimensionnement est aussi une propriété de sécurité. Un actif saturé, c'est du flapping, des délais dépassés, des réessais en tempête : un déni de service auto-infligé. La marge de capacité fait partie des contrôles.

Erreurs fréquentes

Raisonner en machines et prétendre à une architecture. Douze serveurs durcis un à un et zéro matrice : l'ensemble reste inauditable (section 27.1).

Choisir le motif par imitation. Sans les deux chiffres de la direction, le motif est un habit sans corps (section 27.2).

Dimensionner le cluster comme une somme. Trois nœuds en édition Community valent la capacité d'un seul, et le dossier qui additionne les cœurs prépare une saturation surprise (sections 27.4, 26.1).

Prendre les namespaces pour des clusters. Le tenant qui exigeait un destin séparé partage la panne, la version et le seal du voisin (section 27.5).

Remplir cinq colonnes de la grille. Une sixième colonne vide, et l'analyse ment par omission (section 27.6).

Classer le schéma en documentation générale. La carte du royaume sur un wiki ouvert, c'est la reconnaissance offerte (Sécurité).

Mise en pratique : lire, découper, dériver

Sur papier ; réponses commentées en fin de partie.

1. La direction d'une PME donne une heure d'indisponibilité par an au maximum, quinze minutes de perte de données, un seul site, pas d'édition Enterprise. Dérivez le motif complet et rédigez la phrase de risque résiduel qui manque forcément.
2. Écrivez la matrice de flux du fil rouge à l'étape 4, avant le répartiteur : toutes les lignes, avec le besoin et le chapitre de justification.
3. Appliquez la grille au montage du gardien seul, en cinq lignes par colonne au maximum.

Questions de compréhension

1. Qu'est-ce qu'un flux au sens de l'architecte, et pourquoi la matrice rend-elle une installation auditable ?
2. Donnez les quatre motifs canoniques avec, pour chacun, sa tolérance et sa limite principale.
3. De quels deux chiffres le choix d'un motif se dérive-t-il, et qui doit les donner ?
4. Énumérez les cinq tiers et la discipline de sens qui les gouverne.
5. Quels sont les vrais moteurs de charge, et pourquoi la règle de l'actif unique change-t-elle le dimensionnement ?
6. Que délèguent les namespaces, et que ne remplacent-ils jamais ?
7. Récitez les six colonnes dans l'ordre, avec la fonction de chacune.
8. Pourquoi la sixième colonne est-elle la signature de la grille ?

Synthèse

L'architecte change d'unité : des zones et des flux, chaque flux étant une ligne justifiée et tout le reste un refus par défaut. Quatre motifs couvrent le réel et se dérivent de deux chiffres donnés par la direction, jamais copiés sur le voisin. Cinq tiers ordonnent le dessin, du consommateur à l'observation, avec des franchissements contrôlés. Le dimensionnement suit les vrais moteurs sur la capacité de l'actif seul, mesuré puis révisé. Les namespaces délèguent l'administration sans séparer les destins. Et la grille à six colonnes devient la langue commune du reste du cursus, avec sa règle d'or : une analyse qui n'avoue rien n'analyse rien.