Dans les environnements MSP et fournisseurs de services, utiliser une appliance distincte par client est coûteux, difficile à gérer et inefficace en capacité. Mais exécuter tous les clients sur un seul appareil avec une simple séparation par nom ou par dossier ne suffit pas non plus. Si les frontières de trafic, de logs, de réseau, de ressources et de droits ne sont pas nettement séparées, les tenants peuvent s'affecter les uns les autres.
Dans les environnements soumis à la conformité, cette séparation devient encore plus critique. Si différents périmètres de sécurité comme le PCI, les données de santé ou une classification publique doivent s'exécuter sur la même ressource physique, le fait de savoir quel tenant peut accéder à quelles ressources, à quel réseau et à quels logs doit être prouvable. Le simple étiquetage logiciel ne suffit pas à inspirer confiance dans la plupart des scénarios.
Dans les structures multi-tenant, la consommation de ressources produit aussi un risque opérationnel. Le nombre de connexions, l'intensité du trafic, le volume de logs ou une mauvaise configuration d'un tenant ne doit pas affecter les performances des autres tenants. C'est pourquoi le CPU, la mémoire, le disque, l'interface réseau et les limites de flux doivent être planifiés au niveau du tenant.
La bonne approche consiste à traiter chaque tenant comme une zone de travail distincte ; à séparer les ressources, les logs, l'audit et les droits d'administration selon la frontière du tenant. L'isolation des tenants doit être appliquée non seulement au niveau de l'interface, mais aussi sur les plans du trafic et des ressources.
La Virtualisation vTenant TR7 offre ce modèle : tout en exécutant plusieurs tenants sur un seul TR7, elle rend les frontières de ressources, de réseau et d'opérations gérables séparément.
L'architecture vTenant TR7 se construit autour d'un espace de travail indépendant par tenant, de ressources réseau dédiées, d'un contexte de trafic isolé et d'une approche par quotas de ressources.
Un vTenant est un espace de travail indépendant avec sa propre frontière d'administration et de trafic au sein d'un même appareil. Chaque tenant peut utiliser ses propres services, son contexte réseau, ses logs et ses paramètres de ressources, séparés des autres tenants.
Les interfaces physiques peuvent être partagées entre les tenants via des fonctions virtuelles dédiées ou des structures de slots. Ainsi, chaque tenant reçoit son trafic sur sa propre surface réseau et ne se mélange pas au trafic des autres tenants.
Chaque tenant peut avoir son propre contexte d'IP, de route, de pare-feu et d'interface. Les mêmes plages d'IP peuvent être utilisées dans différents tenants sans collision, et le trafic est évalué selon la frontière du tenant.
Des cœurs de processeur, de la mémoire, de l'espace disque et des limites de connexion/flux peuvent être planifiés pour chaque tenant. Ce modèle réduit l'impact de la consommation de ressources d'un tenant sur les autres tenants.
La Virtualisation vTenant sépare la structure multi-tenant aux niveaux des ressources, du réseau, de l'identité, des logs et des opérations.
Chaque vTenant est géré comme un espace de travail distinct. Les vServices, certificats, règles, réseaux et structures de logs définis au sein d'un tenant restent dans ses propres frontières. Les MSP et fournisseurs de services peuvent exécuter différents clients côte à côte sur un même TR7. Ce modèle réduit le nombre d'appareils physiques tout en préservant l'isolation opérationnelle.
Chaque tenant peut être géré avec un comportement de cycle de vie distinct. Un tenant peut être démarré, arrêté, redémarré ou configuré avec un comportement de démarrage automatique. Cela garantit que les autres tenants ne sont pas affectés lors d'une maintenance sur un tenant. Les équipes d'exploitation peuvent exécuter des fenêtres de maintenance par client ou par environnement.
TR7 peut planifier les cœurs CPU attribuables aux tenants en tenant compte des cœurs réservés à l'hôte. Davantage de ressources processeur peuvent être attribuées aux tenants critiques, tandis que les tenants à faible intensité peuvent fonctionner avec des ressources plus limitées. Cela réduit l'impact d'un trafic client intense sur le plan de contrôle des autres tenants. La gestion des ressources devient une partie de la planification de capacité.
Un disque de travail et un espace de données brutes distincts peuvent être réservés pour chaque tenant. On peut démarrer à partir de valeurs par défaut et planifier par tenant à mesure que les besoins augmentent. Logs, rapports, configuration et données temporaires sont conservés dans la frontière du tenant. Cette structure est importante pour la conformité et la séparation opérationnelle des données.
Des fonctions virtuelles peuvent être attribuées aux tenants à partir des interfaces réseau physiques. Chaque tenant reçoit et envoie son trafic via son propre slot d'interface. Cette approche assure une séparation du trafic plus forte que l'étiquetage logiciel. Pour les tenants à haute intensité, performance et isolation sont préservées ensemble.
Les paramètres de confiance et de contrôle d'anti-spoofing peuvent être gérés sur les interfaces attribuées au tenant. Cela garantit que le tenant utilise son propre comportement MAC et de trafic dans les limites attendues. En particulier dans les réseaux multi-tenant, les comportements d'adresse erronés ou en collision sont maîtrisés tôt. La sécurité réseau devient une partie naturelle de la frontière du tenant.
TR7 peut générer des adresses MAC uniques pour les interfaces des tenants grâce à une structure de préfixe MAC et de slots. Ce modèle combine un préfixe de 3 octets et l'information de tenant/slot pour fournir un adressage ordonné. Lorsque de nombreux tenants et interfaces sont définis sur le même appareil, le risque de collision diminue. L'équipe réseau suit les interfaces des tenants de manière plus lisible.
TR7 planifie la capacité de tenants et d'interfaces avec des champs de bits de device, de zone et d'interface. Un champ de zone de 6 bits offre un modèle d'adressage jusqu'à 64 tenants, et un champ d'interface de 5 bits jusqu'à 32 interfaces par tenant. Cette structure assure une montée en charge ordonnée dans les grandes installations MSP et multi-environnements. La croissance des tenants est rattachée dès le départ à un modèle de capacité prévisible.
Chaque tenant peut avoir sa propre vue d'IP, de route, de pare-feu et d'interface. Les mêmes plages d'IP privées peuvent être utilisées dans différents tenants sans collision. Cela réduit le problème classique de collision d'adresses RFC1918 dans les environnements multi-client. Le trafic est évalué dans le contexte du tenant et ne se mêle pas à un mauvais espace réseau.
Le flux de logs et d'audit de chaque tenant peut être traité séparément. Les enregistrements d'exploitation d'un tenant ne sont pas visibles par un autre tenant. Cette séparation est d'une importance critique pour la confidentialité des clients, la conformité et les processus d'examen d'incident. Au niveau de l'administration centrale, les utilisateurs autorisés peuvent produire des rapports par tenant.
Grâce à l'envoi de commandes contrôlées à l'intérieur d'un tenant, des opérations de cycle de vie, de santé et de diagnostic peuvent être exécutées. Cela permet de mener les opérations sans affecter tout l'appareil lors d'un examen de problème ou d'une maintenance propre à un tenant. Les droits de commande peuvent être restreints par RBAC et audit. Les équipes de support établissent un diagnostic plus rapide dans le contexte du tenant.
Le côté Central Management peut voir et gérer les tenants de manière groupée. Avec le RBAC, on peut restreindre quel tenant chaque utilisateur peut voir ou modifier. Dans les scénarios MSP, une séparation des droits par client peut être réalisée. La facilité d'administration et la confidentialité des tenants sont préservées dans le même modèle.
L'exploitation vTenant s'opère avec des valeurs de disque par défaut, la planification CPU, les champs de bits, le modèle d'IP d'administration, l'attribution d'interfaces et la génération d'adresses MAC.
Un disque de travail et un espace de données brutes par défaut peuvent être définis pour chaque tenant. L'installation rapide se fait à partir de valeurs initiales par défaut de 20 Go pour le disque de travail et 30 Go pour l'espace de données brutes ; la capacité peut être augmentée selon l'intensité de production. Le volume de logs et de rapports doit aussi être pris en compte dans la planification du disque.
Un pool de cœurs attribuables aux tenants est constitué en soustrayant la réserve allouée à l'hôte du nombre total de cœurs. Davantage de cœurs peuvent être attribués aux tenants critiques. Ce modèle combine l'isolation des ressources avec la planification de capacité.
Les champs de bits de device, de zone et d'interface forment un modèle d'adressage total de 12 bits. Un champ de zone de 6 bits offre une capacité de 64 tenants, et un champ d'interface de 5 bits une capacité de 32 interfaces par tenant. Ces valeurs clarifient le plan de montée en charge dans les grandes installations.
Une IP locale à des fins d'administration peut être générée pour chaque tenant. Cette IP peut être utilisée dans les flux de cycle de vie, de santé et d'administration interne du tenant. Le trafic d'administration doit être traité séparément du trafic de données du tenant.
Des informations comme le slot, le nombre de VF, l'espace MAC et le MTU peuvent être conservées sur les interfaces attribuées au tenant. Ce modèle assure une répartition ordonnée des ressources réseau physiques entre les tenants. L'impact réseau doit être soigneusement évalué lors de la modification du plan de slots.
Des adresses MAC uniques peuvent être générées en ajoutant l'information de tenant et de slot au préfixe MAC de 3 octets. Cette structure réduit les collisions d'adresses et facilite le suivi de l'appartenance des interfaces à un tenant. Elle assure la lisibilité pour l'exploitation réseau.
Un fournisseur de services peut exécuter 30 clients en tant que vTenants distincts. Chaque client dispose de son propre espace de réseau, de logs, de règles et de ressources ; l'exploitation se simplifie sur un seul appareil.
Le tenant traitant les données de carte et le tenant du trafic web d'entreprise peuvent fonctionner comme des espaces de travail distincts sur le même TR7. La séparation des ressources, du réseau et de l'audit renforce la preuve de conformité.
Les établissements de santé peuvent maintenir le trafic de test, de développement et de production dans des tenants distincts. Les données patient de production et le trafic de développement sont gérés depuis le même panneau d'exploitation tout en étant séparés l'un de l'autre.
Les organismes publics peuvent exécuter des services de différents niveaux de sécurité dans des tenants distincts. En séparant le réseau, les logs et les droits d'accès par tenant, le risque d'accès erroné est réduit.
Des tenants de test, de staging et de production peuvent être créés sur le même TR7. Les modifications applicatives sont validées avec un comportement ADC/WAAP similaire avant d'être mises en production.
Une structure de tenants pour les environnements MSP, bancaires, de santé et publics, avec isolation des ressources, du réseau et des opérations. Réalisons une démonstration en direct sur votre propre installation.