Mixed Tenancy 9.1 : dessiner le pont entre VM Apps et All Apps

L’upgrade est terminé, l’organisation VM Apps répond encore, et la tentation est forte de créer All Apps sur les mêmes ressources « pour voir ». C’est précisément le moment où une décision d’architecture doit remplacer l’essai improvisé : partager vCenter et NSX ne signifie ni partager le même cluster, ni obtenir une nouvelle frontière de sécurité.

Cet article transforme le scénario WebShop en Architecture Decision Record. Il compare trois topologies, fixe l’ordre de configuration documenté par Broadcom, puis donne les contrôles réseau, capacité et sécurité à exiger avant un pilote. L’objectif n’est pas de présenter Mixed Tenancy comme une cible permanente, mais comme un pont dont la sortie est écrite avant l’entrée.

TL;DR

• Décision : utiliser Mixed Tenancy seulement si la visibilité croisée potentielle et le plan de management partagé sont acceptés ; sinon, choisir une infrastructure All Apps dédiée.
• Arbitrage coûteux : des clusters séparés isolent la capacité des workloads, mais ne séparent pas vCenter, NSX ni leur charge API.
• Lundi matin : documenter l’ordre existant des objets, mesurer le plan de management et faire signer une condition de sortie avant d’activer le feature flag.

Un partage de ressources n’est pas une isolation

À partir de VCF Automation 9.1, Broadcom documente un design bimodal où une organisation VM Apps et une organisation All Apps peuvent utiliser la même paire vCenter/NSX Local Manager. Le vCenter doit disposer d’un Supervisor avec VPC Networking et le feature flag Mixed Tenancy Mode autorise ce partage. La KB 444058 précise aussi une contrainte essentielle : VM Apps et ses cloud accounts doivent être configurés avant la Region All Apps utilisant la même paire.

Ce mécanisme répond à un besoin de transition brownfield. Il ne fusionne pas les modèles : VM Apps conserve ses allocations et réseaux historiques ; All Apps consomme une Region, des Namespaces et des VPC. Il ne promet pas non plus une isolation forte entre organisations sur le plan de management. La documentation de design Broadcom demande d’accepter les limites de visibilité et de contention associées au partage.

Schéma original fondé sur les modèles de consommation bimodale Broadcom ; aucune capture produit n’est reproduite.

Le choix ne se résume donc pas à « partage ou non ». Il faut décider ce qui peut être commun : calcul, stockage, plan de management, réseau, opérations et visibilité. Une option peut être acceptable pour WebShop non-production et interdite pour une application réglementée dans le même programme.

Question	Même cluster	Clusters séparés	Infrastructure dédiée
Capacité workload	commune	séparée	séparée
Maintenance du cluster	couplée	distincte	distincte
vCenter/NSX	communs	communs	distincts
Charge API du management	commune	commune	séparée
Coût transitoire	faible	moyen	élevé
Frontière de sécurité	la plus faible	meilleure côté workloads	la plus nette
Usage raisonnable	lab/pilote ciblé	migration contrôlée	criticité ou isolation forte

Cette table est un cadre de décision, pas une matrice de support universelle. Les compatibilités dépendent du build et de la Bill of Materials VCF ; elles doivent être recoupées avec la documentation en vigueur au moment du changement.

Respecter l’ordre supporté avant de construire la cible

La séquence n’est pas cosmétique. La KB 443541 décrit l’échec rencontré lorsqu’une organisation All Apps utilise déjà la paire vCenter/NSX et que l’on tente ensuite d’y ajouter le cloud account VM Apps. Pour le chemin partagé, Broadcom impose la direction suivante :

1. stabiliser l’organisation acme-vmapps-legacy et vérifier ses cloud accounts ;
2. confirmer le vCenter, le NSX Local Manager et les clusters réellement associés ;
3. activer Mixed Tenancy Mode dans le portail Provider Management ;
4. préparer le Supervisor avec VPC Networking ;
5. créer la Region et vérifier l’homogénéité des capacités qu’elle annonce ;
6. créer acme-all-apps, lui attribuer la Region Quota, puis construire sa landing zone.

Si l’ordre réel est inverse, ne modifie pas des champs internes pour forcer l’état attendu. Gèle la tentative, collecte le build et la chronologie, puis confronte le cas à la KB et au support Broadcom. Une manipulation qui rend l’interface verte sans rétablir un état supporté crée une dette invisible au prochain upgrade.

Écrire l’ADR avant d’activer le flag

Pour WebShop, l’option B constitue une hypothèse raisonnable : un cluster legacy reste consacré à VM Apps, un cluster Supervisor héberge All Apps, et vCenter/NSX restent communs pendant la migration. Ce choix doit néanmoins rester proposed tant que la sécurité et la capacité n’ont pas produit leurs preuves.

architecture_decision:
  id: ADR-VCFA-MIG-001
  status: proposed
  workload_topology: separate-clusters
  shared_vcenter: true
  shared_nsx_local_manager: true
  mixed_tenancy_mode: true
  source_organization: acme-vmapps-legacy
  target_organization: acme-all-apps
  security_boundary: workload-cluster-only
  required_approvals:
    - platform-capacity
    - network-security
    - application-owner
  exit_condition: all-services-decided-and-shared-rail-drained
  execution_status: not-executed

Le champ le plus important est security_boundary. « Clusters séparés » ne doit jamais être traduit en « environnements complètement isolés ». Le second est exit_condition. Une date seule peut glisser ; une condition seule peut rester indéfinie. Le bon ADR associe un jalon de revue à des critères mesurables : aucune nouvelle demande VM Apps, toutes les applications classées, exceptions transférées vers une plateforme durable et dépendances transitoires supprimées.

La création de l’organisation All Apps mérite une revue particulière. La documentation Create a VCF Automation Organization for All Applications fait de la Region et de son quota un choix structurant. Le projet doit donc valider Supervisor, classes de VM, Storage Classes, connectivité externe et blocs IP avant l’affectation, plutôt que de repousser ces écarts dans chaque Blueprint.

Relier les réseaux sans prétendre les convertir

Le réseau VM Apps reste celui du brownfield : VLAN ou segments NSX existants, adresses historiques, règles et services externes déjà consommés. La cible All Apps apporte VPC et subnets. La phase de coexistence relie ces deux modèles par des flux explicites ; elle ne transforme pas un segment legacy en VPC.

Pour la vague WebShop stateless, les VM web et applicatives cibles peuvent encore joindre la base PostgreSQL legacy. La règle transitoire doit appartenir à quelqu’un et porter sa propre fin de vie :

transitional_flow:
  id: webshop-app-aa-to-db-legacy
  source: snet-app
  destination: webshop-db-01
  protocol: tcp
  port: 5432
  purpose: wave-2-temporary-database-access
  owner_role: network-owner
  evidence: firewall-log-and-application-test
  expires_when: database-wave-accepted

Ajoute le chemin DNS/LB, les routes, les règles distribuées, les certificats et l’observabilité au même registre. Une connexion qui fonctionne depuis un compte provider ne prouve pas que le consommateur, le service account ou l’opérateur de permanence possède le bon accès.

Pour la landing zone prj-webshop-modern, démarre avec un Namespace pilote, un VPC et des quotas conservateurs. Garde le catalogue fermé au public tant que les chemins create, Day‑2 et delete n’ont pas été testés. Cela évite que des déploiements non gouvernés rendent le retrait du pilote plus complexe que sa création.

Mesurer le plan de management et la visibilité

Mixed Tenancy ajoute une nouvelle charge à des composants déjà utilisés par le legacy. Avant le pilote, enregistre une baseline représentative, puis observe les mêmes indicateurs pendant les opérations All Apps :

Domaine	Mesure avant pilote	Signal d’arrêt
vCenter	latence API, erreurs, tâches, files	dégradation persistante face à la baseline
NSX	latence API, état managers/edges, erreurs	timeout ou dette de configuration croissante
Cluster	CPU, mémoire, datastore, contention	marge sous le seuil accepté localement
Supervisor	santé, services, provisioning	état instable ou opération non déterministe
Accès	inventaire visible par rôle non-admin	exposition refusée par la sécurité

Il n’existe pas de seuil magique à recopier. Les valeurs acceptables dépendent de la taille du plan de management, du volume d’automatisation, des fenêtres de sauvegarde et du SLA. Le changement doit nommer l’autorité capable de suspendre le pilote lorsque la baseline se dégrade.

Le test de visibilité se conduit avec plusieurs personas : administrateur provider, administrateur VM Apps, utilisateur de projet VM Apps, administrateur All Apps et consommateur All Apps. On vérifie l’inventaire, les recherches, les actions et les données accessibles. Une observation en lecture ne doit être ni minimisée, ni transformée sans preuve en possibilité de modification.

Préparer le rollback et la sortie

À ce stade, le rollback ne déplace aucun workload : il arrête la construction de la cible. Conserve l’ADR, les événements et les résultats ; bloque les nouvelles demandes All Apps ; retire seulement les objets exclusifs dont les dépendances sont connues ; laisse VM Apps inchangée. Si un état partagé ne correspond plus à la documentation, ouvre un dossier support avant toute suppression.

Les conditions de sortie du pont doivent être visibles dès le premier comité :

• toutes les applications ont une décision retain, retire, rebuild, repackage ou modernize ;
• aucun nouveau catalog item VM Apps n’est accepté hors exception formelle ;
• les flux temporaires ont disparu ou disposent d’une nouvelle cible durable ;
• les applications conservées ont une plateforme et un propriétaire après le programme ;
• les preuves d’identité, d’exploitation et de rollback sont archivées ;
• la sécurité et la capacité acceptent la fin du partage, ou déclenchent plus tôt le passage à une infrastructure dédiée.

Mixed Tenancy devient alors un mécanisme gouverné : son activation, ses consommateurs et sa fermeture sont auditables.

Pièges & points de vigilance

• Ne confonds pas feature flag et mécanisme de sécurité.
• Ne déduis pas l’isolation d’un test effectué uniquement avec le rôle provider.
• Ne considère pas un cluster séparé comme un vCenter ou un NSX séparé.
• Ne crée pas la Region avant d’avoir vérifié la chronologie VM Apps sur la paire partagée.
• Ne promets aucun SLA avant d’avoir comparé les métriques au comportement réel du legacy.

Sources officielles

• Broadcom TechDocs — Bimodal Consumption Design for VM Apps and All Apps Workloads
• Broadcom TechDocs — Managing Regions in VCF Automation
• Broadcom TechDocs — Create an All Apps Organization
• Broadcom KB 444058 — Configuring a Shared vCenter and NSX Manager
• Broadcom KB 443541 — Reverse Deployment Sequence Is Unsupported

Conclusion

Le bon design n’est pas celui qui partage le plus de composants ; c’est celui qui rend explicites les frontières réellement obtenues. Pour WebShop, des clusters séparés peuvent fournir un pont économique, à condition d’accepter le management partagé, de mesurer sa charge et d’organiser sa sortie. Une exigence d’isolation stricte conduit directement vers une infrastructure dédiée.

Étape suivante : inventorier le legacy et décider quoi migrer, conserver ou retirer.