Zoom sur la notion de Région

Un seul cloud ne suffit pas

Une entreprise qui déploie et exploite du cloud privé ressent souvent le besoin de disposer de plusieurs clouds, ceci pour des raisons aussi variées que :

• différencier les différents types de workload,
• proposer des clouds offrant des niveaux de sécurité différents en fonction de la criticité des applications,
• isoler certaines applications sur des clouds exclusifs,
• assurer la continuité des services en cas de sinistre.

Pour illustrer ceci, nous pouvons citer un de nos clients grands comptes qui n'a pas encore terminé le déploiement de son deuxième cloud OpenStack qu'il parle déjà d'en déployer un troisième !

Il est courant de qualifier cette démarche de "multi-sites" ou de "multi-clouds".

Mais OpenStack offre-t-il d'autres possibilités plus efficaces que le simple déploiement d'une deuxième instance d'un cloud existant ?

La notion de région, qui est une façon de concrétiser une approche "multi-clouds" ou "multi-sites", offre une réponse positive à cette question.

Bien connue des utilisateurs d'Amazon Web Services, voyons comment la notion de "région" se définit et s'utilise quand il s'agit d' OpenStack.

Mutualiser Keystone, partager sa base de données

Tout d'abord, rappelons que tous les services qui composent OpenStack sont multi-tenants "by design", c'est-à-dire capables d'héberger plusieurs locataires - les "tenants" en question, également appelés "projets" - en proposant à chacun d'entre eux un environnement virtuel privé, sans contrainte explicite liée à l'approche mutualiste et avec un niveau de cloisonnement satisfaisant pour la grande majorité des cas d'usage.

Du point de vue fonctionnel, une "région" OpenStack permet de mutualiser le service d'IAM (Keystone) entre plusieurs clouds offrant les ressources virtuelles à proprement parler : instances, images, volumes, services réseau, etc. Ceci offre à l'utilisateur l'unicité trans-clouds de ses informations d'authentfication, de son rôle et de ses droits sur les projets.

Du point de vue technique, il s'agit de partager, d'une façon ou d'une autre, la base de données (souvent MySQL/MariaDB, mais pourquoi pas CockroachDB...) qui stocke les informations utilisées par le service d'IAM : utilisateurs, rôles, projets (aka tenants), domaines, catalogues, tokens, etc.

Plusieurs approches permettent de partager les informations Keystone. Nous pouvons notamment citer :

• une base centrale, les services des différentes régions accèdent à la base unique via un lien WAN. Ils ne possèdent aucune information Keystone locale.
• une base primaire et autant de bases secondaires que de régions, en réplication asynchrone depuis la base primaire.
• un cluster actif-actif, une base par région, toutes étant en réplication synchrone. La technologie MariaDB Galera Cluster permet de construire un tel cluster.

Le choix d'une approche plutôt qu'une autre peut s'avérer délicat. Quoi qu'il en soit, ce choix doit être guidé par des considérations liées à la technologie retenue, notamment sa capacité de mise à l'échelle et son niveau de résilience aux incidents. Il faut également considérer la facilité à opérer la solution au quotidien et le niveau d'automatisation souhaité. Par exemple, l'arrêt et le redémarrage d'un cluster actif-actif MariaDB Galera sont des opérations sensibles qui doivent être réalisées en suivant une recette précise.

Associer endpoints et régions

Nous avons vu plus haut que chaque région possédait son catalogue de services, par conséquent chaque région possède ses API endpoints. C'est à dire que le service Neutron sur la région A sera différent du service Neutron sur la région B. Cela permet de fournir différents services sur différentes régions mais aussi différentes versions. Ce comportement existe aussi chez Amazon Web Services : tous les services ne sont pas disponibles dans toutes les régions.

L'association entre une région et un API endpoint se réalise au moment de l'enregistrement du service concerné auprès de Keystone grâce à la commande openstack endpoint create.

Ci-dessous, on enregistre l'API endpoint du service Compute (Nova) et on l'associe à la région "SudEst01".

$ opentack endpoint create --region SudEst01 compute public http://controller:8774/v2.1

+--------------+-------------------------------------------+
| Field        | Value                                     |
+--------------+-------------------------------------------+
| enabled      | True                                      |
| id           | 3c1caa473bfe4390a11e7177894bcc7b          |
| interface    | public                                    |
| region       | SudEst01                                  |
| region_id    | SudEst01                                  |
| service_id   | 060d59eac51b4594815603d75a00aba2          |
| service_name | nova                                      |
| service_type | compute                                   |
| url          | http://controller:8774/v2.1               |
+--------------+-------------------------------------------+

L'essentiel à retenir

• une région OpenStack est, souvent mais non obligatoirement, associée à la notion de zone géographique. Elle ne doit pas être confondue avec le "domaine" qui est une entité logique permettant de définir des "namespaces" pour les projets et les utilisateurs, ni avec la "zone de disponibilité" qui est un cas particulier d'agrégat de noeuds de calcul (compute nodes).
• chaque région possède sa propre plate-forme OpenStack : serveurs d'API, ressources de calcul, ressources de stockage, ressources réseau etc.
• un seul service Keystone, mutualisé entre les régions, est déployé en central.
• un choix technique, impactant pour les équipes opérant le cloud au quotidien, doit être fait quant au partage de la base de données Keystone. Dérouler des scnéarios avec l'outil de tests d'OpenStack "at scale" Rally peut être une bonne aide dans le choix du moteur de base de données et de la stratégie de réplication.
• la latence, la stabilité et la résilience du lien inter-datacenters (i.e. inter-régions) sont déterminantes.

Rejoignez vous aussi la conversation !

** - Questions, remarques, suggestions... Contactez-nous directement sur Twitter via @osones !
- Pour discuter avec nous de vos projets, nous restons disponibles directement via contact@osones.com !
- Enfin, la communauté Francophone d'OpenStack vous attend sur http://openstack.fr/ !**

JF Taltavull