kokou Agbedanou

Architectures cloud-ready

1. Préambule

La plate-forme OpenStack offre des fonctionnalités natives : provisionning de machines virtuelles à partir
de templates, provisionning de workloads orientés applicatif ou infrastructure à base de templates.

OpenStack se présente donc uniquement comme une alternative aux suites d’hyperviseurs du marché ? La
réponse est certainement oui mais la plate-forme offre également un framework pour héberger des
applications particulières : les applications cloud-ready.

2. Applications legacy

Les applications legacy sont des applications qui sont généralement déjà en production sur des
infrastructures classiques hypervisées (RHEV, VMware ou Hyper-V). Elles ont besoin de disponibilité, de
robustesse mais pas forcément de scalabilité dans ce sens où le nombre d’utilisateurs est bien connu. Les
applications types sont par exemple : l’application de paie, de comptabilité, l’ERP de l’entreprise, la
messagerie… et bien sûr les applications web non cloud-ready, c’est-à-dire construites dans un
environnement de développement classique (LAMP, une seule machine virtuelle, parfois des mécanismes
de fail-over et de répartition de charges) et avec du code non stateless.

Les applications legacy font partie du monde de l’IT traditionnel où les mécanismes de haute disponibilité
sont gérés par les moyens d’infrastructure de virtualisation de système (HA de VMware, cluster actif/actif
de RHEV...) ou de stockage (baies Netapp, IBM, Dell Equallogic en actif/passif sur deux sites distants...).

3. Application cloud-ready

À l’opposé, les applications cloud-ready sont des applications qui respectent certaines règles de design
comme :

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou -1-
 kokou Agbedanou

ˇ
L’élasticité (scale in et scale out) : elles savent tirer parti des ressources matérielles.
ˇ
La haute disponibilité : elles sont toujours construites sur des mécanismes de HA.
ˇ
Le self-monitoring : elles se surveillent elles-mêmes et prennent des décisions.
ˇ
Le self-healing : elles se soignent elles-mêmes.

Contrairement à la HA legacy, la HA cloud-ready est gérée par l’application elle-même en s’appuyant sur la
méthode de développement Infrastructure As Code. Les applications entrent en interaction directe avec
l’infrastructure matérielle, qu’elle soit physique ou virtuelle.

4. Éligibilité cloud-ready et cartographie IT

La première étape à mener consiste à connaître le patrimoine applicatif de l’entreprise ; cela revient à faire
de la cartographie. C’est le domaine de l’urbanisation d’entreprise. En effet, migrer une application de
VMware vers OpenStack présente peu d’intérêt. Il faut impérativement regarder les applications qui sont
éligibles à la migration.

Pour bien cartographier les applications, il est possible de se baser sur le concept de plan d’occupation
des sols proposé par le CIGREF (Club informatique des grandes entreprises françaises).

Il existe quatre niveaux de plan d’occupation des sols :

ˇ
POSM : Plan d’Occupation des Sols Métiers.
ˇ
POSF : Plan d’Occupation des Sols Fonctionnels.
ˇ
POSA : Plan d’Occupation des Sols Applicatifs.
ˇ
POSI : Plan d’Occupation des Sols Infrastructures.

En général, il faut adopter une approche bottom-up et commencer à bâtir le POSI.

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou -2-
 kokou Agbedanou

Vision multicouche du CIGREF

La cartographie est un outil vivant (donc différent d’une GED statique) pour assurer la gouvernance du
système d’information au sens large. Sa présence et son utilisation au quotidien au sein d’une entreprise
témoignent de la maturité de l’organisation à produire et à consommer de l’IT.

Des outils permettent d’effectuer facilement le travail nécessaire de cartographie :

ˇ
Dans le monde propriétaire : Hopex Mega, SoluQIQ, Envision, Adonis, Visio, Aris.
ˇ
Dans le monde gratuit : ArchiMate, Adonis:CE, Aris Express.

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou -3-
 kokou Agbedanou

5. Cas pratique

a. Problématique

Dans cet exemple, l’objectif est de présenter les étapes nécessaires pour transformer une application on-
premises en une application SaaS. Il est supposé ici que la migration vers le SaaS représente une
opportunité de business.

b. L’existant

Prenons le cas d’une application installée on-premises chez des clients. Cette application contient les
éléments d’architecture suivants :

ˇ
Partie serveur local, basée sur des couches n-tiers :

ˇ
Couche front-end pour l’accès IHM.

ˇ
Couche serveur applicatif.

ˇ
Couche serveur de base de données (n tables).

ˇ
Partie client, basée sur un client lourd ou un client web de type browser.

c. Les éléments critiques

Si cette application doit être hébergée en mode SaaS, il convient d’apporter des réponses sur les points
suivants :

Gestion des accès

Pour un accès fluide à l’application en mode SaaS, les opérations suivantes doivent se produire :

1) Le client se connecte dans le cloud via un browser (https://www.my_appli.fr). L’accès en mode sécurisé
est devenu une norme dans le monde de l’Internet pour les accès applicatifs permettant le traitement de
données. Le certificat SSL est côté serveur et il est acheté auprès du registrar de l’hébergeur (software
provider).

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou -4-
 kokou Agbedanou

2) La zone DNS de my_appli.fr pointe sur les DNS publiques du software provider (DNS primaire et DNS
secondaire).

3) Le software provider dispose de plusieurs accès Internet permettant d’assurer une totale redondance
des accès externes.

4) La requête est dirigée sur un cluster d’appliances physiques ou virtuelles (de type F5 Networks par
exemple). Un système logiciel open source de type HA proxy avec Pacemaker peut également tout à fait
convenir.

5) Le load-balancer effectue une répartition de charge sur les nœuds applicatifs du cluster applicatif. Le
load-balancer est redondé d’un point de vue fail-over, en ce sens qu’il est doublé à l’identique et avec un
secours passif prêt à prendre le relais en cas d’injoignabilité du serveur primaire.

Gestion du front-end

Le front-end comprend tous les mécanismes d’affichage de l’application. Souvent, ce service est composé
d’un cluster de nœuds web identiques (par exemple, des nœuds avec Apache et des technologies de type
AngularJS/HTML5/CSS3).

Gestion du service applicatif (back-end)

Le service applicatif est fourni par des composants de middleware (Tomcat, Jboss, PHP, Java EE...) et par
les programmes d’applications eux-mêmes. Un cluster de n nœuds identiques permet de traiter les
requêtes en provenance du load-balancer.

Gestion des bases de données

Le service de bases de données est fourni par un cluster de serveurs de bases de données en mode
actif/actif ou en mode actif/passif plus simple à mettre en place. Des systèmes propriétaires comme
Oracle RAC ou libres comme Galera Clusters avec MariaDB permettent la mise en œuvre de clusters de
bases de données.

 Aucun code métier ne doit être implémenté au sein des IHM.

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou -5-
 kokou Agbedanou

d. Les scénarios pour les bases de données

D’un point de vue logique, la gestion des bases de données peut s’avérer délicate car il existe plusieurs
scénarios possibles pour la migration vers le SaaS ; en effet, il faut ici passer d’une gestion on-premises
où chaque client a sa propre base en local à un mode hébergé où les données des clients ne sont plus
chez... le client lui-même.

Définitions

Souvent, de nombreuses confusions existent sur les termes habituellement employés dans le monde des
bases de données. Il semble donc important de fournir des définitions simples des termes "moteur de
base de données", "instance", "base de données" et "schéma".

Moteur de base de données

Le moteur de base de données est le programme central permettant de faire fonctionner le logiciel de
base de données. Il existe un moteur Oracle, un moteur SQL Server, un moteur MySQL (mysql-server-
5.5)...

Instance

Une fois installé, le moteur permet la création d’instances de bases de données qui contiennent des
processus et de la mémoire. Une instance n’est pas persistante (elle n’a pas d’existence sur disque).

Plusieurs instances de bases de données peuvent être installées sur un même moteur.

Base de données

À partir de l’instance configurée lors de l’installation, il est possible de créer une (ou plusieurs) base de
données composée de fichiers assurant la persistance des données. C’est l’instance qui assure l’accès
à la base de données. La base de données contient des objets (tables, comptes utilisateurs, vues,
procédures stockées...). Dans MySQL, il y a plusieurs bases de données (databases) pour une instance,
alors que dans Oracle, il n’y a qu’une base de données par instance.

Schéma

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou -6-
 kokou Agbedanou

Un schéma (de base de données) est un compte utilisateur contenant des objets.

Les cinq scénarios

Au moment de choisir une architecture pour les bases de données des clients, cinq scénarios sont
possibles :

Scénario 1 : une base par client

Ce scénario multiplie les bases de données et les serveurs (machines virtuelles) sous-jacents. La
redondance est assurée par un mécanisme de secours passif mais cela multiplie également le nombre de
machines virtuelles.

Une alternative pour économiser de la ressource consiste à installer plusieurs bases par VM.

L’avantage du scénario 1 est le cloisonnement total des bases.

Scénario 2 : tables stand-alone - une base unique multi-client

Dans ce scénario, il n’y a qu’une seule base de données avec N tables par clients et chaque

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou -7-
 kokou Agbedanou

client dispose de ses propres tables au sein d’un cluster de base de données.

En cas de problème sur la base de données, tous les clients peuvent être impactés.

Scénario 3 : tables partagées

Dans ce scénario, il n’y a qu’une seule base de données et un seul schéma de base avec l’ensemble des
tables partagées par tous les clients.

Les clients utilisent les mêmes tables mais un numéro unique ID sur chaque ligne indique

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou -8-
 kokou Agbedanou

l’appartenance des données au client.

Le point négatif concerne la complexité de l’application qui doit gérer les lectures/écritures dans la base
de données. Il y a une quasi-absence d’isolation entre les clients, ce qui pose problème en termes de
confidentialité.

La taille des tables risque ici d’exploser rapidement entraînant une dégradation des performances
(requêtage SQL).

Scénario 4 : base de données multi-tenant

Ce scénario met en œuvre un mécanisme récent qui n’est pas encore complètement démocratisé en
entreprise. C’est possible par exemple avec la dernière version d’Oracle 12c et son option pluggable
database, mais tous les moteurs de bases de données ne permettent pas le multi-tenant (cas de SQL
Server et PostgreSQL).

Cas du multi-tenant avec Oracle 12c

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou -9-
 kokou Agbedanou

Avec le CDB (Container DataBase) et les PDB (Pluggable DataBase), Oracle permet donc désormais d’avoir
plusieurs bases de données par instance.

L’avantage est l’administration simplifiée de cette architecture ainsi qu’une utilisation de ressource
moindre puisqu’il n’y a qu’une seule instance.

Scénario 5 : base de données multi-schéma

Dans ce scénario, chaque client dispose d’un schéma propre sur une base de données partagée. Le multi-
schéma n’impose qu’une instance de base de données.

Cette solution est économique et permet d’avoir une très bonne isolation entre les différentes tables.

Il est possible de constituer des grappes par pool de clients :

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou - 10 -

 kokou Agbedanou

ˇ
Clients de la zone géographique n°1 : un cluster dédié avec une instance et n schémas
accessibles uniquement aux clients de la zone n°1.

ˇ
Clients de la zone géographique n°2 : un cluster dédié avec une instance et n schémas
accessibles uniquement aux clients de la zone n°2.

ˇ
...

ˇ
Clients de la zone géographique n°N : un cluster dédié avec une instance et n schémas
accessibles uniquement aux clients de la zone n°N.

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou - 11 -