Modèles de services partagés Fujitsu K5

2016-12-01

Machine-translated — the English original is authoritative.

Dans la plateforme IaaS de Fujitsu K5, il existe de nombreuses façons différentes de mettre en œuvre une architecture de services partagés en fonction de vos besoins.

[Mise à jour : 09/03/2017] : Avant de continuer, laissez-moi rapidement expliquer ce que j’entends par les deux termes suivants – Plan de contrôle et Plan de données dans le contexte d’OpenStack et de la plateforme IaaS K5 de Fujitsu. Imaginons que l’on vous demande de créer un nouveau service Exchange pour une entreprise sur K5. Ce service nécessitera les composants d’infrastructure suivants : un réseau, un routeur, un pare-feu et un serveur pour héberger l’application.

Plan de contrôle, utilisé par les administrateurs de l’infrastructure K5 : Pour construire cette infrastructure, vous aurez besoin d’un accès aux services du plan de contrôle de K5 – les points de terminaison de l’API qui peuvent communiquer avec les services Keystone, Neutron et Nova. Les utilisateurs réguliers du service Exchange final n’ont pas besoin d’accéder à ce plan de contrôle.

Plan de données, utilisé par les utilisateurs finaux du service : Une fois l’infrastructure construite, l’administrateur Exchange et les utilisateurs finaux accéderont au nouveau serveur/aux nouveaux services via le plan de données – en pratique, ils communiqueront directement avec le nouveau serveur via son interface virtualisée.

Modèle de services partagés K5 – Sans isolation des utilisateurs du plan de contrôle

La conception la plus simple consisterait à placer toutes vos instances dans un seul projet et à utiliser des groupes de sécurité, et éventuellement plusieurs sous-réseaux, pour fournir une isolation du plan de données, ou plus précisément une segmentation du trafic. Bien sûr, vous pouvez également utiliser les mécanismes d’authentification standard du système d’exploitation pour contrôler l’accès aux instances virtuelles elles-mêmes.

Groupes de sécurité

L’un des composants clés de la solution ci-dessus est les groupes de sécurité. Dans OpenStack, un groupe de sécurité est un mécanisme permettant de contrôler tous les flux de trafic entrant et sortant sur une interface (port) par interface (port). Un groupe de sécurité peut contenir plusieurs règles, chacune définissant la plage d’adresses IP, les protocoles et la direction du trafic réseau autorisé. Dans un modèle de services partagés où le serveur A et le serveur B doivent être isolés mais peuvent tous deux communiquer avec un troisième serveur C, les groupes de sécurité fournissent cette isolation. Plusieurs groupes de sécurité peuvent également être attachés à une seule interface pour constituer l’ensemble de règles.

Cependant, l’inconvénient de ce modèle est que l’administrateur du projet du plan de contrôle a accès à toutes les ressources.

Modèle de services partagés K5 – Avec isolation des utilisateurs des plans de données et de contrôle

Si vous souhaitez garantir une isolation aux niveaux des plans de contrôle et de données pour vos ressources, cela peut être réalisé en utilisant l’architecture ci-dessus combinée avec le contrôle d’accès basé sur les rôles, plusieurs projets et une autre capacité de Fujitsu K5 : le routage inter-projets.

Contrôle d’accès basé sur les rôles (RBAC)

La plateforme Fujitsu K5 s’appuie sur le projet Keystone d’OpenStack pour fournir un contrôle d’accès basé sur les rôles pour les utilisateurs au sein d’un Contrat (ou Domaine en termes natifs OpenStack). Vous pouvez définir des administrateurs du plan de contrôle au cas par cas, projet par projet. Cela vous donne la capacité de répartir vos ressources (machines virtuelles, réseaux, etc.) sur plusieurs projets et de définir quels utilisateurs ont un accès administratif à ces ressources dans le plan de contrôle.

Routage inter-projets

L’indice est dans le titre : cette fonctionnalité de K5 vous permet de router le trafic entre des réseaux situés dans différents projets au sein du même Contrat.

La combinaison de toutes ces capacités de K5 nous permet de fournir aux administrateurs de domaine K5 la capacité de contrôler l’isolation des ressources aux niveaux du plan de contrôle et du plan de données.

Par exemple, avec le modèle suivant, nous pouvons définir un utilisateur qui peut administrer les ressources IaaS dans le projet A et un utilisateur différent qui peut administrer les ressources dans le projet B. Aucun de ces administrateurs n’a besoin d’un accès direct aux ressources dans les projets de l’autre ou dans le projet de services partagés. Cependant, ils pourront tous deux router vers les services disponibles dans le projet de services partagés, à condition que les règles de groupe de sécurité appropriées aient été appliquées.

Les deux modèles ci-dessus sont contenus dans une seule zone de disponibilité K5, mais ces modèles peuvent également être facilement répartis sur les deux zones de disponibilité à l’aide d’un autre composant K5 appelé Connecteur de réseau.

Connecteur de réseau K5

Le connecteur de réseau a deux cas d’utilisation fondamentaux –

• Router le trafic réseau des réseaux clients externes directement vers un projet K5.
• Router le trafic réseau entre des réseaux situés dans différentes zones de disponibilité au sein du même projet.

Ce connecteur évite la nécessité pour le trafic réseau des clients de traverser la connexion Internet lors du passage entre les zones de disponibilité.

L’exemple de pile LAMP suivant illustre l’utilisation d’un connecteur de réseau avec deux zones de disponibilité.

Happy Stacking !

Originally published on allthingscloud.eu (2016-12-01).