kokou Agbedanou

Étude de cas n°1 : création d’un cloud privé

1. Problématique et cas d’usage

Dans cette étude de cas, l’objectif est de présenter les éléments de coûts à prendre en compte pour la
création d’un IaaS privé. En effet, l’entreprise est un éditeur de logiciel qui a choisi de créer une structure
d’hébergement interne et ainsi commercialiser des solutions XaaS pour ses clients.

L’entreprise souhaite pouvoir piloter son environnement legacy existant mais aussi bâtir une nouvelle
infrastructure permettant le provisionning massif de machines jetables pour les développements et
l’hébergement d’applications développées en mode cloud-ready.

a. Cas d’usage n°1

Le cas d’usage n°1 consiste à implémenter un catalogue de services qui permet aux clients de se
connecter sur un portail web, de commander un service simple de machines virtuelles nues (des
systèmes d’exploitation) avec des choix de tailles matérielles (CPU, RAM et espace disque) et de durée du
service (un mois, trois mois, six mois ou durée illimitée). Ce catalogue devra fournir, a priori, le coût du
service avant le passage de la commande. Le client recevra alors un mail avec ses identifiants de
connexion (login, password et adresse IP de connexion du serveur) et pourra être facturé de façon
mensuelle.

b. Cas d’usage n°2

Le cas d’usage n°2 consiste à implémenter un catalogue de services qui permet à l’équipe de
développement de disposer de workloads prêts à l’emploi :

ˇ
Un ensemble de machines avec un frontal web, un back-end PHP et un back-end MySQL.
ˇ
Un ensemble de machines avec un serveur applicatif ERP (selon les versions développées) et
un poste sous Windows.

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

ˇ
Un environnement de développement (IDE Eclipse, serveur d’applications Tomcat et base de
données PostgreSQL).
ˇ
Un environnement de développement LAMP (Linux Apache MySQL PHP).

2. Solution

La solution retenue est l’implémentation d’un IaaS privé à base d’une solution d’orchestration permettant
de piloter les environnements VMware, RHEV, OpenStack et Microsoft. Les solutions d’orchestration
possibles permettant ce type de IaaS sont CloudForms (Red Hat), SmartCloud Orchestrator (IBM),
Operations Orchestrator (HP OO) et System Center (Microsoft).

Schéma général du IaaS privé

3. Moyens

a. Moyens techniques

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

Les moyens techniques sont composés des éléments suivants :

ˇ
Dix serveurs hosts bi-pro 196 Go de RAM dont cinq sur l’environnement VMware et cinq sur
l’environnement RHEV.
ˇ
Les hosts VMware vont servir à héberger les applications legacy et les hosts RHEV vont servir
à provisionner les nouveaux services applicatifs destinés aux clients finaux de l’entreprise.
ˇ
Sept serveurs hosts bi-pro quad-core avec 128 Go de RAM pour la plate-forme OpenStack
destinée à héberger les VM jetables des développeurs et les environnements temporaires
d’intégration des développeurs. OpenStack va également servir à héberger les environnements
de tests pour les futures applications cloud-ready et les tests sur les environnements big data.

Les sept serveurs physiques sont installés sur le site primaire (pas de redondance sur le site B pour le
moment, puisqu’il s’agit d’une plate-forme de testing) et sont répartis de la façon suivante :

ˇ
Host 1 : serveur virtualisé pour des fonctions de contrôleur dont :

ˇ
Une VM pour le WebUI (Horizon ou Memcached)

ˇ
Une VM pour MySQL

ˇ
Une VM pour RabbitMQ

ˇ
Host 2 : serveur non virtualisé pour la gestion des identités Keystone.
ˇ
Host 3 : serveur non virtualisé de storage objet (Swift).
ˇ
Host 4 : serveur non virtualisé de storage bloc et images (Cinder et Glance).
ˇ
Host 5 : serveur non virtualisé de network (Neutron-*).
ˇ
Host 6 : serveur non virtualisé de compute (VM).
ˇ
Host 7 : serveur non virtualisé de compute (VM).

Toutes les interfaces réseau sont en 10 Gbits/s minimum.

Tous les serveurs non virtualisés sont installés sous RHEL 7 et le serveur virtualisé est équipé de
l’hyperviseur RHEV.

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

Le storage s’effectue en SAS 10 Gb via iSCSI (Internet Small Computer System Interface) sur des baies de
stockage peu intelligentes.

Schéma technique du IaaS privé

b. Moyens humains

L’équipe d’hébergement doit être constituée de personnes capables d’assurer les missions suivantes :

ˇ
Service de type helpdesk (c’est le SPOC - Single Point Of Contact - d’ITIL).
ˇ
Service de type service desk.
ˇ
Service de gestion de projet d’infrastructures.
ˇ
Service d’exploitation système.
ˇ
Service d’exploitation réseau.
ˇ
Service de sécurité des systèmes d’information (SSI).

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

Il faut donc bien se rendre à l’évidence : la création d’un IaaS privé demande de la technicité et donc du
savoir-faire qu’il est impossible de sous-traiter sur le long terme ; il faut une équipe (le noyau dur) en
interne.

 Il ne faut sous-traiter que ce qui fonctionne bien et qui est parfaitement

maîtrisé (typiquement, le helpdesk est un bon candidat).

La construction d’un IaaS ne s’improvise pas, il faut avoir recours à des prestataires spécialisés (Red Hat,
IBM, HP, Mirantis...) pour bâtir l’infrastructure de départ et réaliser le POC indispensable permettant de
faire fonctionner les use cases définis.

c. Découpage du projet

Le projet est découpé selon trois grandes phases :

1) Phase 1 (P1) : Proof Of Concept

Le POC a lieu avec trois fournisseurs sur les deux use cases précédemment identifiés. La sélection
préalable des fournisseurs doit être effectuée et cela suppose de connaître parfaitement l’écosystème du
cloud computing.

2) Phase 2 (P2)

La phase 2 concerne l’implémentation de la couche orchestrateur branchée sur les différents hyperviseurs
VMware, RHEV/KVM, Hyper-V, ainsi que sa mise en production.

3) Phase 3 (P3)

La phase 3 concerne l’implémentation d’OpenStack, ainsi que sa mise en production.

Partant de ces trois phases, il convient d’effectuer le lotissement du projet de la façon suivante (T
représente la date de démarrage du projet. Le projet s’exprime en mois) :

Phase Lot Contenu du lot Timing et durée

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

P1 Lot 1 Constitution de l’équipe projet - T

Constitution du comité de sélection
Durée = 2 semaines

P1 Lot 2 Implémentation des POC chez les T+ 4

fournisseurs sélectionnés
Durée = 4 mois

P1 Lot 3 Recettage par l’entreprise des POC T+5

livrés
Durée = 1 mois

P1 Lot 4 Choix du fournisseur selon une grille T+6

de sélection interne, en comité de
sélection Durée = 1 mois

P2 Lot 5 Implémentation de l’architecture cible T+11

-Phase 2
Durée = 5 mois

P2 Lot 6 Première formation de l’équipe T+11

technique aux outils
Durée = deux semaines

P2 Lot 7 Mise en production d’un T+12

environnement pilote
Durée = 1 mois

P2 Lot 8 Ajustement du pilote T+14

Durée = 2 mois

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

P2 Lot 9 Mise en production Phase 2 T+15

Durée = 1 mois

P2 Lot 10 Recettage générale Phase 2 T+15

Durée = 1 semaine

P3 Lot 11 Implémentation de l’architecture cible T+17

-Phase 3
Durée = 2 mois

P3 Lot 12 Seconde formation de l’équipe T+17

technique aux outils
Durée = 1 semaine

P3 Lot 12 Mise en production d’un T+18

environnement pilote
Durée = 1 mois

P3 Lot 13 Ajustement du pilote T+19

Durée = 1 mois

P3 Lot 14 Mise en production Phase 3 T+23

Durée = 4 mois

P3 Lot 15 Recettage général Phase 3 T+23

Durée = 1 semaine

P3 Lot 16 Bilan T+24

Durée = 2 semaines

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

La durée du projet est donc de deux ans. Bien entendu, chaque phase fait l’objet d’une recette et le
passage à la phase N+1 ne peut être réalisé que si la recette de la phase N est effective et validée.

d. Moyens financiers

Le tableau suivant présente une synthèse des coûts du projet :

Ordre Chapitre de coût Commentaires OPEX/CAPEX

1 Étude préalable Coût de l’étude préalable (inclure OPEX

les coûts internes et externes si
sous-traitance à un cabinet
spécialisé)

2 POC Coût interne et externe (prix du OPEX

POC)

3 Grille d’évaluation et choix Coût interne OPEX

4 Achat matériel (hosts, baies Coût achat CAPEX

de stockage, éléments
actifs...)

5 Installation matérielle Coût interne + coût prestataires OPEX

éventuels

6 Implémentation architecture
cible

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

7 Achat de licences Licences orchestrateur et CAPEX (achat)

OpenStack (version supportée)
OPEX (maintenance)

8 Formation outils phase 1 Frais de formation du personnel Budget formation

(orchestrateur) entreprise

9 Pilote phase 1 et ajustement Coût interne (équipe projet, OPEX

équipe exploitation, équipe
métier) + coûts prestataires

10 Matériels phase 2 Achat de serveur et baies de CAPEX

stockage

11 Implémentation architecture Coût interne + coût prestataire OPEX

phase 2

12 Formation outils phase 2 Frais de formation du personnel Budget formation

(OpenStack) entreprise

13 Pilote et ajustement Coût interne (équipe projet, OPEX

équipe exploitation et équipe
métier) + coût prestataire

4. Conclusion de l’étude de cas n°1

L’implémentation d’un IaaS privé pour la réalisation de deux use cases nécessite une forte mobilisation en
interne au sein de l’entreprise : sponsoring, calcul de ROI, POC, choix d’un fournisseur, achat de matériels
et licences, formation, transfert de compétences, implémentation des use cases sur la plate-forme, tests,
déploiement de sites pilotes,

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

gestion de projet, reporting, recettage, déploiement généralisé, installation d’une plate-forme de

développement et de tests, préparation budgétaire et présentation du catalogue de services aux business
units concernées...

Sans une certaine maturité dans le métier de l’hébergement (compétences en services hostés, en
virtualisation, en infrastructures système réseau, en gestion de datacenters...), il est évident que cette
transformation de traditionnal-IT vers du cloud-IT au sein de ce type d’entreprise est vouée à l’échec.

Il faut ainsi garder à l’esprit que les mises en production s’accompagnent de rédaction de documentation
pour les utilisateurs et de présentation des outils.

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