Les etapes de la migration vers le cloud hybride

A l’attention de :
Auteur(s) :
Réf :
Date :
La migration vers le Cloud Hybride en 4 étapes
Démarche et dimensionnement de la cible
PROJET CLOUD HYBRIDE
MARS 2019
Livre blanc - Migration cloud hybride
Sylvain FRANCESCHI – Directeur Technique

Projet CLOUD HYBRIDE
Sommaire
1. Les problématiques et enjeux du cloud pour les DSI
2. Le cloud hybride : démarche de migration en 4 étapes
3. Phase n°1 : stratégie de migration
4. Phase n°2 : Conception
5. Phase n°3 : Déploiement du cloud hybride et des applications
6. Phase n°4 : L’exploitation au quotidien
La supervision
Le paiement à l’usage
Les facteurs clés de la réussite de la migration
Scénario de migration pour les applications
Plan de reprise d’activité
Les critères à prendre en compte
Les différents types de cloud
Processus de migration vers le cloud des applications
Définition des services managés - exemple de catalogue de service
Matrice d’aide à la décision pour analyser le dimensionnement du cloud par application
Synthèse du dimensionnement pour les différents types de cloud
Les étapes de la conception de son Cloud

Face aux nombreux besoins que rencontrent les SI des différents sites (explosion du volume des
données, apparition du cloud public, obsolescence matérielle, contraintes de sécurité des données, codes
sources), les directions opérationnelles se retrouvent confrontées à de nombreuses problématiques
techniques et d’exploitations.
Contexte général
Comment fournir une architecture sur
mesure aux directions opérationnelles par
projets ?
Les besoins en stockage sur des grandes
quantités de données sont souvent au cœur
des développements et des architectures big
data?
La donnée et la sécurité dans un contexte de
Cloud Hybride? Les contraintes et les limites ?
Comment faire pour choisir le type de
cloud par application , public, privé, infra-
dédiée) ?
Est-ce qu’il faut virtualiser et centraliser toute
les éléments de l’infrastructure sur un Cloud
Hybride ?
Quelles sont les critères d’éligibilité au
cloud dans l’organisation de la DSI?
Quelle approche adopter en fonction des
besoins des directions opérationnelles et des
projets pour migrer dans le cloud ?
Quelles sont les étapes de la migration
des applications éligibles au cloud Hybride?
Organisation et méthode Dimensionner et sécuriser les données

Les contraintes des directions opérationnelles
§ La puissance de calcul ou de stockage des serveurs doivent répondre à des besoins spécifiques
par projets, rapidement en fonction de cycle de vie.
§ L’augmentation du volume des données impose un rythme élevé de révision de la capacité de
stockage du système d‘information.
§ Concrètement, un équipement informatique - privé sur site - devient rapidement obsolète.
L’étude d’obsolescence met en évidence une partie du SI non éligible au Cloud. Le shadow IT
est le plus touché par l’obsolescence des composants logiciels.
§ L’architecture technique interne a des coûts informatiques qui augmentent. On doit remettre en
question cette stratégie, en optant pour des solutions plus souples et économiques. Elles vont
vers des solutions cloud public comme Azure ou Amazon
Quelsques exemples de contraintes relevées dans les projets
L’approche "Cloud" permet de passer d'un modèle économique CAPEX onéreux à un modèle
OPEX tout en garantissant plus de flexibilité et de performances aux directions opérationnelles.
La DSI centralise les éléments d’infrastructure pour mettre un modèle économique plus adapté.
La solution adoptée par la DSI et les entreprises

La solution proposée par la DSI , le cloud Hybride
L’approche « cloud hybride » s'avère dans de nombreux cas constituer la réponse la plus
pertinente car elle apporte :
Le Cloud HYBRIDE > La solution retenue par la DSI AGILE
La souplesse nécessaire tout en
garantissant la sécurité des données
Elle offre un compromis
performance/évolutivité
Elle permet de concevoir des
infrastructures dimensionnées au plus
près des besoins métiers.
L‘enjeu principal est donc de savoir comment placer au mieux le curseur des
services entre un opérateur externe et les équipes internes

Sommaire
La supervision
Définition des services managed - exemple de catalogue de service

Les principales caractéristiques recherchées pour la mise en place d’un cloud hybride sont les suivantes :
Rappel des caractéristiques d’un projet cloud hybride
le choix dépend des besoins de l'utilisateur et de ses
capacités d'implication dans la mise en œuvre des
ressources. (trop de spécificité = cloud privée ou infra
dédiée)
Les ressources sont déployées automatiquement à la
demande sans avoir à passer par un opérateur, comme
cela peut être le cas lors d’une demande de forte
puissance de calcul ponctuel.
Le projet qui a besoin du service peut en faire
directement la demande via un portail de service.
Dans ce type de projet, les critères de paiement seront
à définir en fonction de la consommation et du service
utilisé par les projets.
Automatiser les demandes les plus courantes
Vers une solution du type service à la demande
Systèmes de facturation à l’usage
Solution hybride : cloud public, privé, infra dédiée
Déploiement d’un service plus rapide et réactif,
Les ressources sont immédiatement mises à
disposition par le fournisseur via un portail dédié
Le système de facturation à l’usage vous
donne l’opportunité de démarrer doucement,
et de stopper le projet en minimisant les
pertes financières.
Le Cloud embarque une fonction d’auto-
scalabilité. Les ressources utilisées seront
adaptées aux besoins réels des projets.
On supprime les frais fixes d’un forfait traditionnel.
On passe vers un paiement ajusté aux besoins
réels des directions opérationnelles.

2. Le cloud Hybride : la démarche de migration en 4 étapes
• Les 4 phases de la mise en place d’un cloud Hybride proposées par EI-Management
» Projet de migration vers le cloud Hybride
1. La stratégie de
migration
2. La conception
du cloud
3. Le déploiement
(BUILD)
4. L’exploitation
(RUN)
• Inventaire des usages
• Inventaires des
ressources
• Etude d’obsolescence
• Analyser l’existant en
fonction des contraintes
techniques et des
exigences non-
fonctionnelles
• Choisir le « bon cloud »
par application
• Identification des
« services managés »
• Choisir son fournisseur
capable d’opérer sur le
cloud Hybride
• Définir l’architecture
globale
• Dimensionner les
types de cloud
• Aux types de cloud,
ses classes d’usages
et identification des
ressources
nécessaires
• Choisir sa solution de
publication des
services managés via
un portail unique
• Mettre les enjeux de
la migration au cœur
de la construction
• Coordonner la
conduite de
changement
• Elaborer un
processus de
migration pour ces
classes d’usages et
les projets liés
• Méthodologie de
migration à adopter
en fonction des
classes d’usage
• La supervision des
projet en fonction des
type de cloud
• Définir le modèle de
paiement à l’usage
pour les directions
opérationnelles
• Déterminer les limites
des utilisateurs sur les
opérations en fonction
des types de cloud
• Ne pas pénaliser les
utilisateurs, répondre
aux besoins avec
l’agilité nécessaire

Sommaire
La supervision

le contexte et les critères à prendre en compte
Notre stratégie proposée pour migrer l’infrastructure existant vers le Cloud hybride
est basée sur les critères suivants :
Approche de migration par projet et à la demande, pour sécurisation
Analyse des classes d’usages et de la sécurité nécessaire à mettre en place autour de l’application
Identification des besoins en stockage et en puissance de calcul
Analyse et tri des applications à migrer vers les différents cloud en fonction de l’obsolescence
Définir la stratégie de la migration consiste à analyser et à trier les applications à migrer.
Ce processus de cartographie applicative est clé pour dimensionner chaque type de cloud
Il fait parti du processus de conduite de changement pour favoriser l’adoption du futur Cloud par les
directions opérationnelles
1
2
3
4

Rappel des types de cloud
Définition des types de cloud
Cloud Public
• Des infrastructures techniques en ligne
pour fournir des ressources IT en mode
IaaS, le plus souvent mutualisées
• Des infrastructures techniques mutualisées
en ligne pour fournir des ressources IT en
mode IaaS dans les centres de données
d’un fournisseur (Cloud Provider) qui a créé
son offre de services Cloud
Infrastructures techniques privées / interne
• Des infrastructures techniques dédiées
propriétés de la DSI ou en mode locatif,
localisées dans un datacenter (dans ses locaux ou
en colocation)
Cloud Privé (externalisé)
• Des infrastructures techniques en ligne
dédiées fournies en mode IaaS dans les
centres de données d’un fournisseur (Cloud
Provider)
Cloud Hybride
C’est la combinaison de l’ensemble des possibilités proposées, des
« Infrastructures techniques privées » au « Cloud Public », en passant par les « Cloud
Privé » et « Mutualisé », pour la fourniture de ressources IT
Cloud Mutualisé
• Des infrastructures techniques mutualisées
en ligne pour fournir des ressources IT en
mode IaaS dans les centres de données d’un
fournisseur (Cloud Provider) qui a créé son
offre de services Cloud

Rappel des types de cloud
Les avantages et inconvénients des différents types de cloud
Infrastructure dédiée cloud privé cloud hybride cloud public
Données sécurisées
Intégration au SI
Sur-mesure
Agilité optimale
Scalabilité étendu
Connexion
complexe entre
cloud privé et
public
Bande passante
Routage réseau
Utilisation simple
Services ﬂexibles
Paiement à l’usage
Coût d’installation
Scalabilité limitée
Données sécurisées
Exploitation possible
par les DO
Répond aux besoins
spécifiques des
bancs d’essai
Scalabilité limitée
Cout d’installation
Difficulté pour
opérer sur l’infra-
dédiée pour
l’exploitation externe
Serveurs externes
Intégration au SI
Identification du catalogue de services en fonction des types de cloud doit répondre aux
besoins des directions opérationnelles

Application
non éligible
Application
éligible
Application
obsolète
Application
nouvelle
Compatibilité cloud
Interconnexion SI
Besoin d’agilité
Besoin de scalabilité
Cout de migration
Pérennité
En fonction des cas
d'usages
24 mois + 36 mois 12 mois
Support commercial aux
clients
Etude et développement Services techniques et
d’infrastructures
Digital Factory
Gestion des ventes Système d’Information de gestion
MigrationInfra-dédiée Migration
Migration avec
transformation
Processus d’analyse de l’éligibilité aux
différents clouds

Processus d’étude d’éligibilité aux différents cloud pour une application
S’appuie t’elle sur un socle standard
(progiciel, socle logiciel, socle serveur)
Les données manipulées sont-elles soumises à un
cadre de confidentialité strict que les
fournisseurs ne peuvent respecter?
L’application est elle spécifique à l’entreprise ?
L’application est elle fortement intégrer
au SI ?
S’appuie t’elle sur un socle standardisé ?
(Progiciel, Socle logiciel, Socle Serveur ?)
Les interfaces avec les autres applications
sont-elles standardisées?
Cloud Privé
Infra dédiée
oui
non
Existe-t-il un service équivalent en
mode SaaS ?
Cloud public
Infra dédiée Cloud privé
S’appuie t’elle sur un socle
standardisé ? (Progiciel, Socle
logiciel, Socle Serveur ?)
Cloud public
1 2
2
oui
non
non
non
oui
oui
oui
oui
non
non
non
oui
oui
non
3
3
4
4
5

Classification et description des services : exemple des services
Exemple de catalogue des services d’infrastructure
La liste des services
managed sera définie
en fonction des
contraintes de la DSI
Cette cartographie
correspond à un
exemple réalisé dans le
cadre de la
centralisation des
datacenters dans un
cloud privé

Sommaire
La supervision

3. Phases n°2 : Conception du cloud hybride
Les étapes de la conception
• La conception du cloud hybride se décompose en trois étapes majeures
1. Architecture globale et choix
du cloud
2. A chaque application, son
type de cloud
3. Dimensionnement par
type de cloud
• Définir l’architecture globale du
socle qui accueillera les services
applicatifs à partir de l’étude
d’obsolescence
• Définir l’architecture de chaque
application éligible au Cloud
• Choisir des services de type IaaS
pour une migration de l’application
sans transformation, ou pour une
réinstallation des applicatifs.
• Choisir des services de type PaaS
lors de la transformation d’une
application, ou une évolution de
l’architecture, ou pour une nouvelle
application (risque : sécurité des
données)
• Disposer d’une bonne
connaissance de l'architecture
et des besoins de l'application
pour identifier le service Cloud
le plus pertinent
• Identifier les besoins d’une
application: est-elle plus
gourmande en mémoire vive ou
en ressources processeurs.
• Le cloud public à l’avantage
d’offrir un large choix de
catégories de services adaptés
à vos usages.
• Cloud privé : offre surtout la
sécurité des données
• Infra-dédiée : banc d’essai
• Les critères de dimensionnement
du cloud public varient en fonction
de la nature du service et de
l’usage qui en est fait. Ces critères
ne sont plus simplement
techniques (RAM, CPU, quantité
de stockage, etc.), mais peuvent
également être fonctionnels.
• Avoir une connaissance précise
des ressources consommées par
chaque application. Pour ce faire,
il s’agira d’organiser un
rapprochement entre les équipes
d’architectes infrastructures et
d’architectes applicatifs, afin de
maîtriser les enjeux propres aux
deux parties.

6. Conception de l’architecture cible
Les types de clouds pour les applications
Matrice d’aide à décision pour classifier les applications par type de
cloud en fonction de leur besoins
Les caractéristiques des
applications / Des lots
Infra dédiée
standard
Infra dédiée
Hyper
convergence
Cloud public
Azure
Cloud privé
Non
Eligible
Pas de besoin scalabilité
Besoin de volume de stockage
Pas de besoin de stockage
Besoin données sensible
Eligible
Données non sensibles
Données sensibles
Besoin de volume de stockage
Besoin interconnexion sécurisée
Besoin interconnexion non sécurisée

Synthèse du dimensionnement de l’architecture cible
Schéma de l’architecture cible
• Liste des services
SAAS
• Type de
ressources à
consommer
• Nombre de VM
• Allocation des
ressources
processeurs,
mémoire et espace
disque
• Type de plateforme
de service
• Nombre de VM
• Allocation des
ressources
processeurs,
mémoire et espace
disque
• Hyperconvergence
• Sur l’infrastructure dédiée et
sur une infra standard
• Les applications
administratives et assurant
le bon fonctionnement des
services

Synthèse du dimensionnement de l’architecture cible
DC1
DC2
DC3
DC4
Cloud privé Cloud publicInfrastructure dédiée
standard Hyper
convergence
Lot A
Lot B
Lot C
Lot D
Lot E
Lot F
Lot G
Lot H
Lot I
Lot J
Lot K
Lot L
Cloud hybride
Etuded’obsolescencedesapplications
ProcessusdemigrationdesApplicationsverslecloudHybride
Nb VM
vCPU
RAM
DD
Nb VM
vCPU
RAM
DD
Nb VM
vCPU
RAM
DD
Nb VM
vCPU
RAM
DD
Nb VM
vCPU
RAM
DD
Nb VM
vCPU
RAM
DD
Nb VM
vCPU
RAM
DD
Nb VM
vCPU
RAM
DD
Nb VM
vCPU
RAM
DD
Nb VM
vCPU
RAM
DD
Nb VM
vCPU
RAM
DD
Nb VM
vCPU
RAM
DD
Nb VM
vCPU
RAM
DD
Nb VM
vCPU
RAM
DD
Nb VM
vCPU
RAM
DD
Nb VM
vCPU
RAM
DD

Sommaire
La supervision

5. Phase n°3 : Déploiement et migration dans le cloud
Les facteurs clés pour réussir sa migration
La phase de déploiement et de migration est soumise à 2 facteurs clés :
§ le bon choix des types de cloud et des services de migration à la disposition de la DSI
§ l’apprentissage du fonctionnement des services de migration, de façon à réduire les risques de
coupures de services. Il est recommandé d’utiliser des outils de migration des ressources vers
le cloud
Remarque : La phase de déploiement vers le cloud hybride est en effet dépendante des spécificités des plateformes
Cloud utilisées. Certains cloud publics mettent par exemple à votre disposition des outils qui facilitent la migration du
système applicatif, comme des services de transfert de bases de données ; d’autres vous permettent d’externaliser
de grandes quantités de données.
Les enjeux de la phase de déploiement et migration vers le cloud
Recommandation: On propose une migration « par lots » des applications vers le cloud. La
migration peut durer de 18 à 24 mois : une fois le socle déterminé, les applications sont à migrer
par lot

5. Phase n°3 : Déploiement et migration dans le Cloud
Les étapes de la migration d’un groupe d’application ou d’un lot
OpérationstechniquesL’adoptionducloud
• Connaissance
des outils
disponible chez
les fournisseurs
• Outiller la
migration
• Retour arrière
Maitrise des
services de
migration
• Planning de
migration des
lots
• Liste des étapes
à suivre par lot
• Gestion de tous
les paramètres
Définir le plan de
migration par lot
• Perte de
données
• Coupure de
service
• Cout des
licences des
socles logiciels
Identification des
risques
• Exécution de la
migration
• Tests de
recevabilité
• Période de VBF
• Prononcer la bon
fonctionnement
Migration-
stratégie par lot
• Définir les
supports de
communication
• Les points jalons
• Définir l’instance
de pilotage
• Réunion
d’information sur
les phases
• Désignation de
référents par lot
• Identiﬁcation de
la recette
• Mettre en place
un support
dédié à la
bascule
• Organisation sur
site Hotline
dédiée
• Dispositif
d’escalade et de
correction
Définir le plan de
de
communication
Mobilisation des
collaborateurs
Gestion de la
communication
bascule
Mise en place
d’un support
dédié
Migrationparlotd’applicationetparsite
Le projet de migration est composé de 2 chantiers qui sont à mener en parallèle

5. Phase n°3 : Déploiement et migration dans le Cloud
Les étapes de la migration d’un groupe d’applications ou d’un lot
Mise à disposition de l’usine
Durant la phase de développement des nouvelles
applications dans le hangar, « l’usine » sera mise en
œuvre avec les services d’infrastructure associés.
Par la suite, le déploiement dans l’usine pourra débuter
progressivement avec une mise à disposition
progressive aux utilisateurs. Enfin les systèmes
d’information locaux actuels seront par la suite
décommissionnés.
Lorsque toutes les applications sont déployées dans
l’usine, le hangar n’a plus d’intérêt car les solutions
retenues seront alors matures, sécurisées et en
production.
Mise à disposition du hangar
On recommande de mettre en place un « hangar », c’est-
à-dire un hébergement mutualisé et totalement virtualisé
à moindre coût afin de pouvoir débuter au plus tôt la
transformation des applications. Seuls les
environnements « hors-production » de développement,
d’intégration et de recette sont concernés.
L’ouverture de ce hangar permettra la mise en œuvre
des outils nécessaires à la production tels que l’AD, les
outils de sauvegarde, … Ainsi que les couches
« Middleware » nécessaires au fonctionnement des
applications
Le développement des nouvelles applications urbanisées
pourra par la suite débuter dans le hangar. Les tests
unitaires des interfaces et les reprises de données
utilisant les nouvelles interfaces pourront y être réalisés.
Site
Lot A
Lot B
Lot C
HANGAR – Préparation / construction USINE – Mise en production
Production Préprod Test/ recette

Plan de reprise des activités
le plan de reprise d'activité (PRA) est un processus composé de documents et de procédures,
destinés à rétablir le fonctionnement d'une entité en cas d'incident ou de désastre. Il vise à
permettre la reprise de l'activité, en situation nominale ou en mode dégradé, au bout d'un
certain temps..
Il est nécessaire de classifier les applications par criticité afin de pouvoir définir des normes de
construction du PRA en rapport avec ce critère.
La règle à adapter pour le plan de reprise des activités
On peut distinguer 5 niveaux de criticité :
Impact Nul Faible Modéré Sérieux Extrême
Financier 0k€ ≤ xx k€ ≤ xx k€ ≤ xx k€ > Xx k€
Commercial Pas
d’impact
Impact
exclusive
ment
interne
Impact clients
faible
Impact externe
important, non-
respect d’obligations
contractuelles
Interruption d’activité significative
Interne Pas
d’impact
Pas
d’impact
Pas de risque
interne, autres
risques limités
Risque interne limité,
risque de coupure
des services
Risque interne important, risque
d’être en incapacité de faire
fonctionner les applications de
gestion critiques du groupe

Plan de reprise des activités – architecture technique
Dans le cadre d’un PRA, il est nécessaire de bénéficier d’un site de secours sur lequel les données et les applications
critiques sont synchronisées et vers lequel les utilisateurs habituels sont redirigés en cas de coupure et de
dysfonctionnement majeur
Le PRA est basé sur un mécanisme de réplication
global du stockage entre les deux datacenters.
De ce fait l’activation des serveurs sur le secours est
nécessaire, c’est-à-dire tous les serveurs contenant les
données métiers pour une application donnée doivent
être démarrés
secours
Réplication
asynchrone
des données
Applications
critiques

L'exploitation d’un cloud hybride présente des différences majeures par rapport à un SI classique.
Les différents points à prendre en compte dans l’exploitation du cloud hybride sont les suivants :
• la supervision du système d’information
• La gestion du mode de paiement à l’usage
• Déterminer le périmètre de responsabilité entre les équipes de la DSI et l’opérateur unique qui
exploitera le SI
La règles à adapter pour le run du Cloud Hybride

La supervision
• 7 étapes pour une supervision efficace des applications sur le cloud hybride
Périmètre de la
supervision
•Déterminer les
applications
critiques
Inventaire des
composants
critiques
•Dresser
l’inventaire des
éléments SI
associés à ces
applications
Communiquer
•Communiquer
avec chaque
équipe afin de
répertorier leurs
besoins
spécifiques
Vision bout
en bout
•Préparer la
vision top-
down (mise
en place
d’outillage
APM)
Supervision
technique
•Mettre en
œuvre la
supervision
bottom-up
Reporting
•Développer
des
dashboards
d’exploitation
propres à
chaque
équipe
Restitution
•Générer des
rapports
consolidés en
provenance
d’un cockpit
DSI dédié

Le suivi du budget du cloud hybride
• En matière de gestion des coûts, le passage d’un SI classique à un SI hybride s’accompagne
d’un basculement fondamental. D’un mode de paiement forfaitaire, adossé à un nombre fixe
d’unités d’œuvres, vous passez à un mode de paiement à l’usage. Plus souple, ce dernier est
aussi plus complexe. Vous devez donc modifier votre manière de piloter votre budget SI, avec
pour objectif de rationaliser vos coûts.
• Voici les 4 niveaux d’optimisation de vos dépenses dans le cadre d’un SI hybride, du plus simple
au plus complexe
1/ Piloter votre budget par périmètre applicatif
2/ Optimiser votre consommation via 3 leviers
• L’analyse du dimensionnement
• Les mécanismes d’activation et de désactivation
• Les mécanismes de scalabilité
3 /Optimiser les performances de vos applications
4/ Transformer vos applications via l’adoption d’un service PaaS

Contact
Sylvain FRANCESCHI
Partner I Conseil DSI
Mob :+33 (0)6 85 13 62 34
Mail : sylvain.franceschi@ei-technologies.com
31

Les etapes de la migration vers le cloud hybride

Contenu connexe

Similaire à Les etapes de la migration vers le cloud hybride (20)

Dernier (13)

Les etapes de la migration vers le cloud hybride