UNIVERSITE MOHAMMED V DE RABAT

ECOLE MOHAMMADIA D’INGENIEURS

Département : Génie électrique

Filière : Génie Réseaux et Télécommunications
Mémoire de projet de fin d’études :
N° 48/2023

Migration de pfSense vers NSX-T : pré-migration,

Setup de l’environnement cible et planification de la
migration

Réalisé par :
Mme. Amal HAKKOU

Dirigé par :
Prof. Asmaa RETBI
Prof. Marouane SEBGUI
Mr. Franck FISER

Année 2022-2023
 UNIVERSITE MOHAMMED V DE RABAT
ECOLE MOHAMMADIA D’INGENIEURS

Département : Génie Informatique

Option : Ingénierie & Qualité Logicielle
Mémoire de projet de fin d’études :
N° INF 48/2023

Migration de pfSense vers NSX-T : pré-migration,

Setup de l’environnement cible et planification de la
migration

Réalisé par :
Mr. Oualid OUHADDA

Dirigé par :
Prof. Asmaa RETBI
Prof. Marouane SEBGUI
Mr. Franck FISER

Année 2022-2023
 UNIVERSITE MOHAMMED V DE RABAT
ECOLE MOHAMMADIA D’INGENIEURS

Département : Génie électrique /Génie Informatique

Option : Réseau et télécommunications /Ingénierie & Qualité
Logicielle
Mémoire de projet de fin d’études :
N° 48/2023

Migration de pfSense vers NSX-T : pré-migration,

Setup de l’environnement cible et planification de la
migration

Réalisé par :
Mr. Oualid OUHADDA
Mme. Amal HAKKOU

Soutenu le 06/06/2023, Rabat, Maroc

Devant le jury composé de :
Prof. Mohammed SOUIDI Président, EMI
Prof. Driss ELGHANAMI Rapporteur, EMI
Prof. Asmaa RETBI Encadrante, EMI
Prof. Marouane SEBGUI Encadrant, EMI
Mr. Khalid EL MISSI Encadrant, Deloitte

Année 2022-2023
Dédicaces

Amal HAKKOU
Je dédie ce travail à mes chers parents,
C’est parce qu’on ne choisit pas ses parents que je fais chaque jour la réalisation du privilège que j’ai
de vous avoir. Je vous dois tout.
Maman, tu es la personne la plus forte que je connaisse, et cela m’a toujours appris de renaitre de
mes cendres, de me reconstruire, de me défier moi-même. Je t’admire beaucoup, et je te serais à
jamais reconnaissante pour tes sacrifices, ta protection, tes exigences, tes réveils à bonne heure, et ta
merveilleuse patience.
Papa, tu as toujours cru en moi inconditionnellement. Tu m’as appris à être libre, accomplie, et tu
m’as soutenu chaleureusement dans chaque mission et pas que j’ai entrepris dans ma vie. Je te suis
reconnaissante d’être le papa et l’ami que tu as toujours été.
Je dédie ce travail à ma soeur Marwa et mon frère Jad,
Être l’ainée a toujours mis sur moi une grande pression : Être le bon exemple. Il m’a fallu beaucoup
de temps de réaliser que vous n’êtes plus petits, et que maintenant, vous m’inspirez aussi de votre
manière. Je suis fière de vous et je serai toujours là pour vous.
Je dédie ce travail à Badr,
Tu es mon homme, mon mari, mon meilleur ami et la lumière au bout du tunnel. Tu me poussais
toujours à me surmonter ( all sets to failure),tu t’investis gracieusement dans mes ambitions et même
en me contrariant, tu arrives à élucider ma vision. We will surely conquer the world [Link]
t’aime.
Je dédie ce travail à ma grand-mère,à l’ame de mes grand-parents, à mes tantes et oncles, et à
la famille : Arrachidi et Hakkou,
Votre amour, encouragement, prières sont bien mon capital, et ce qui me remplit de force et de
persévérance. Merci à vous.
Je dédie ce travail à ma deuxième famille Amal, Ait Sab,
Je ne saurai exprimer ma reconnaissance envers vous. J’espère etre à la hauteur de votre gentillesse,
bienveillance et accueil.J’ai la chance d’avoir deux chez-moi, et je vous en remercie infiniment.
Je dédie ce travail à mes amis,
Je vous remercie d’avoir été là, vous avez rendu mon expérience beaucoup plus passionnante. Je
vous souhaite le meilleur.

1
Dédicaces

Oualid OUHADDA
À ma merveilleuse maman,
Ton amour, ton soutien inconditionnel et ta bienveillance ont été les piliers qui m’ont aidé à traverser
ce parcours de PFE. Tes encouragements incessants m’ont donné la force nécessaire pour atteindre
ce moment important de ma vie. Ce travail est dédié à toi, en témoignage de ma gratitude et de mon
amour éternel. Merci pour tout, maman.
À mon cher papa,
Ton exemple de persévérance, de détermination et de travail acharné a été ma plus grande inspiration
tout au long de ce projet de PFE. Ta sagesse et ton soutien indéfectible m’ont donné la confiance
nécessaire pour relever les défis et aller de l’avant. Ce travail est dédié à toi, en signe de
reconnaissance et d’amour. Je t’aime, papa.
À mon frère bien-aimé,
Tu as toujours été mon complice, mon confident et mon partenaire dans toutes les aventures de la
vie. Ta présence encourageante et ton esprit compétitif m’ont poussé à donner le meilleur de
moi-même dans ce projet de PFE. Cette dédicace est un témoignage de notre lien indéfectible et de
notre amour fraternel. Merci d’être là pour moi, mon frère.
À ma sœur chérie,
Tu as toujours été ma meilleure amie et ma plus grande supportrice. Tes encouragements constants,
ta gentillesse et ta perspicacité ont été essentiels pour surmonter les moments difficiles de ce
parcours de PFE. Cette dédicace est une expression de ma gratitude et de mon amour pour toi. Merci
d’être ma sœur extraordinaire. Je t’adore.
À tous mes amis qui m’ont toujours encouragés, et à qui je souhaite encore plus de succès.
À tous ceux que j’aime.

Je vous dédie le fruit de mon projet.

2
Remerciements

Il nous tient à cœur d’exprimer notre profonde gratitude à toutes les personnes qui
ont joué un rôle déterminant dans l’accomplissement de notre Projet de Fin d’Études.
Nous adressons nos sincères remerciements à nos encadrants internes Mme As-
mae Retbi , et Mr Marouane Sebgui pour leur encadrement rigoureux, leurs orienta-
tions pertinentes et leurs retours constructifs.
Nous exprimons également notre gratitude envers les membres du jury pour avoir
consacré du temps à évaluer notre travail.
Nous souhaitons également remercier chaleureusement le président du jury Mr
Mohammed SOUIDI pour son rôle essentiel dans la supervision de l’évaluation. Sa
présidence bienveillante et son soutien ont contribué à créer un environnement pro-
pice à la discussion et à la réflexion.
Un remerciement particulier au rapporteur du jury Mr Driss ELGHANAMI, dont
l’analyse minutieuse et les recommandations précieuses ont enrichi notre travail. Son
expertise et son engagement ont été d’une valeur inestimable pour notre projet.
Nous souhaitons également manifester notre respect et notre admiration à l’égard
de notre entreprise d’accueil , Deloitte Extended Services , qui nous a offert l’oppor-
tunité d’intégrer son équipe Cloud Engineering lors de cette phase cruciale de notre
formation.
Notre reconnaissance s’adresse en particulier à Younes AGNAOU dont les conseils
avisés, l’expertise remarquable et le soutien inébranlable ont grandement facilité
notre parcours.
Nos remerciements vont également à Franck Fiser, Khalid El Missi,Oussama El
Meknassi Farid Noah Nekkachi, Zakaria Fahri pour leur disponibilité et leur pré-
cieuse assistance qui ont constitué le fondement de cette expérience enrichissante.
Ce Projet de Fin d’Études est le fruit d’un travail acharné et de nombreux sa-
crifices, notamment ceux de nos professeur et l’équipe pédagogique que nous ne
remercierons jamais assez. Il représente pour nous non seulement l’achèvement de
nos études, mais aussi le début d’une nouvelle étape dans notre vie professionnelle.

3
Résumé

Le Cloud Computing a connu un tel succès ces dernières années que les entreprises
ne peuvent plus fonctionner sans sa technologie. Cependant, la gestion de l’infra-
structure informatique demeure toujours une tâche très difficile en raison du grand
nombre d’appareils informatiques et l’architecture des réseaux actuels, où le plan de
contrôle et le plan de données sont intégrés verticalement dans chaque périphérique
réseau.
Dans ce contexte, le SDN "Software-Defined-Networking" a été introduit pour
garantir que les réseaux informatiques soient flexibles et agiles, programmables et
automatisables en séparant les plans de contrôle et de données. Cette séparation crée
une abstraction de l’infrastructure physique et centralise le contrôle via des API.
Notre projet de fin d’études s’inscrit dans le cadre de l’implémentation d’une so-
lution SDN et de l’implémentation des différentes fonctionnalités que propose cette
solution.
Le stage se déroule en trois phases. Première phase de documentation de cette
solution pour découvrir les différents composants et principes de fonctionnement de
cette [Link], une deuxième phase pour la préparation de la migration vers
cette [Link] finalement, la phase de la mise en place cette solution et ses diverses
fonctionnalités (routage logique, répartition de charge logique, etc.).

Mots clés : SDN , Cloud Computing , flexibles , agile

4
Abstract

Cloud computing has been so successful in recent years that companies can no lon-
ger operate without its technology. However, managing IT infrastructure is still a
very challenging task due to the large number of computing devices and the current
network architecture, where the control plane and data plane are vertically integrated
into each network device.
In this context, SDN "Software-Defined-Networking" was introduced to ensure
that IT networks are flexible and agile, programmable and automatable by separa-
ting control and data planes. This separation creates an abstraction of the physical
infrastructure and centralizes control via APIs.
Our end of studies project focuses on the deployment of an SDN solution and the
implementation of its various functionalities.
The internship takes place in three phases. First phase concerns the study of this
solution in order to discover its different components and operating principles. Then,
a second phase to assess the current plateform. And finally, the implementation phase
of this solution and its various functionalities (logical routing, logical load balancing,
etc.).

Key words : SDN , Cloud Computing , flexible , automatable

5
6
Table des matières

Dédicaces Amal HAKKOU 1

Dédicaces Oualid OUHADDA 2

Remerciements 3

Résumé 4

Abstract 5

Molakhas 6

Introduction générale 1

1 CADRE ET CONTEXTE DU STAGE 2

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Deloitte Touche Tohmatsu . . . . . . . . . . . . . . . . . . 3
1.2.2 Deloitte Extended Services . . . . . . . . . . . . . . . . . . 4
1.2.3 Digital Factory . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.4 Les services de la firme . . . . . . . . . . . . . . . . . . . . 5
1.2.5 Les missions de la firme . . . . . . . . . . . . . . . . . . . 6
1.3 Cadre général du projet . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.1 Contexte du projet . . . . . . . . . . . . . . . . . . . . . . 7
1.3.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.3 Les objectifs du projet . . . . . . . . . . . . . . . . . . . . 9
1.3.4 Equipe de travail . . . . . . . . . . . . . . . . . . . . . . . 9

7
 TABLE DES MATIÈRES

1.3.5 Conduite et planification du projet . . . . . . . . . . . . . . 10

1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2 ETUDE DE L’EXISTANT ET BESOINS FONCTIONNELS ET TECH-

NIQUES 13
2.1 Introduction : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.2 Analyse et évaluation de l’existant . . . . . . . . . . . . . 14
[Link] Extraction de données . . . . . . . . . . . . . . 14
[Link] Analyse de données . . . . . . . . . . . . . . . . 16
2.2.3 Besoins techniques et fonctionnels . . . . . . . . . . . . . 16
[Link] Besoins fonctionnels . . . . . . . . . . . . . . . 16
[Link] Besoins techniques . . . . . . . . . . . . . . . . 17
2.2.4 Exigences critiques . . . . . . . . . . . . . . . . . . . . . . 18
2.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 TECHNOLOGIES, OUTILS ET ARCHITECTURES 20

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2 Introduction aux technologies utilisées . . . . . . . . . . . . . . . 21
3.2.1 Introduction au SDDC . . . . . . . . . . . . . . . . . . . 21
3.2.2 Technologie SDN . . . . . . . . . . . . . . . . . . . . . . 21
[Link] Réseau à définition logicielle vs Réseau classique :
. . . . . . . . . . . . . . . . . . . . . . . . . . . 21
[Link] Avantages SDN . . . . . . . . . . . . . . . . . . 22
[Link] Les composants d’un réseau à définition logicielle 23
3.3 NSX-T by VMware . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3.1 Fonctionnalités du NSX-T . . . . . . . . . . . . . . . . . . 24
[Link] Commutation logique . . . . . . . . . . . . . . . 24
[Link] Routage logique (Logical Routing) : . . . . . . . 24
[Link] Load Balancing : . . . . . . . . . . . . . . . . . 27
[Link] VPN : . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.2 Architecture de NSX-T : . . . . . . . . . . . . . . . . . . . 29

8
 TABLE DES MATIÈRES

3.4 Devops avec terraform et Gitlab . . . . . . . . . . . . . . . . . . . 30

3.4.1 Infrasctructure as code . . . . . . . . . . . . . . . . . . . . 30
3.4.2 Terraform . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.4.3 Gitlab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4 REALISATION ET VALIDATION DE LA MIGRATION 32

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2.1 Conception d’un high level design . . . . . . . . . . . . . 33
4.2.2 Scénarios du déploiement . . . . . . . . . . . . . . . . . . 33
[Link] Le premier scénario . . . . . . . . . . . . . . . 34
[Link] Le deuxième scénario . . . . . . . . . . . . . . . 35
[Link] Troisième scénario . . . . . . . . . . . . . . . . . 36
[Link] Avantages, Inconvénients et Coût de chaque scé-
nario . . . . . . . . . . . . . . . . . . . . . . . . 37
[Link] Choix du scénario . . . . . . . . . . . . . . . . . 37
4.3 Les activités de pré-migration . . . . . . . . . . . . . . . . . . . . 38
4.3.1 Cutover strategy . . . . . . . . . . . . . . . . . . . . . . . 38
[Link] Premier use case . . . . . . . . . . . . . . . . . 38
[Link] Deuxième use case . . . . . . . . . . . . . . . . 39
4.3.2 Rollback process . . . . . . . . . . . . . . . . . . . . . . . 40
4.3.3 PlayBook . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.3.4 Wave planning . . . . . . . . . . . . . . . . . . . . . . . . 42
4.4 Automatisation du setup avec Terraform et GitLab . . . . . . . . . . 43
4.4.1 Introduction à l’Automatisation du Projet . . . . . . . . . . 43
4.4.2 Les Configurations NSX-T Automatisées et pipline CI/CD . 44
4.4.3 Execution de la configuration . . . . . . . . . . . . . . . . 45
4.4.4 Illustrations des Configurations et du Processus d’Automati-
sation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
[Link] Networking . . . . . . . . . . . . . . . . . . . . 46
[Link] VPN . . . . . . . . . . . . . . . . . . . . . . . . 50
[Link] Load Balancing . . . . . . . . . . . . . . . . . . 51

9
 TABLE DES MATIÈRES

[Link] Sécurité . . . . . . . . . . . . . . . . . . . . . . 52
4.4.5 Impact de l’Automatisation sur le Projet . . . . . . . . . . . 56
4.5 Execution de la migration . . . . . . . . . . . . . . . . . . . . . . . 57
4.6 Post-Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Conclusion générale 59

Références 60

10
Table des figures

1.1 Deloitte logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Deloitte extended services new office in Casablanca . . . . . . . . . 4
1.3 Deloitte Digital Factory . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Les services de la firme . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5 Structure organisationnelle . . . . . . . . . . . . . . . . . . . . . . 6
1.6 Contexte du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.7 Equipe de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.8 Planification du projet . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1 Script python pour l’extraction des données . . . . . . . . . . . . . 15

3.1 Réseau traditionnel vs Réseau SDN . . . . . . . . . . . . . . . . . 22

3.2 Composantes SDN . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3 Connectivités entre deux VMs dans deux transport Nodes . . . . . . 24
3.4 Topologies sous NSX-T . . . . . . . . . . . . . . . . . . . . . . . 26
3.5 Composants du T0 et T1 . . . . . . . . . . . . . . . . . . . . . . . 27
3.6 fonctionnement du load balancer . . . . . . . . . . . . . . . . . . . 28
3.7 Architecture NSX-T . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.8 Terraform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.9 Gitlab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.1 Scénarios de déploiment . . . . . . . . . . . . . . . . . . . . . . . 33

4.2 High level Design : Scénario 1 . . . . . . . . . . . . . . . . . . . . 35
4.3 High level Design : Scénario 2 . . . . . . . . . . . . . . . . . . . . 36
4.4 High level design :Troisième scénario . . . . . . . . . . . . . . . . 36
4.5 Processus de Cutover : 1 use case . . . . . . . . . . . . . . . . . . . 39
4.6 Processus de Cutover : 2 use case . . . . . . . . . . . . . . . . . . . 40

11
 TABLE DES FIGURES

4.7 Structure du projet terraform . . . . . . . . . . . . . . . . . . . . . 44

4.8 Fichier [Link] pour l’automatisation . . . . . . . . . . . . . . 45
4.9 Création du T0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.10 Création du T0 au niveau NSX-T . . . . . . . . . . . . . . . . . . . 47
4.11 Création du VRF dans le T0 . . . . . . . . . . . . . . . . . . . . . 47
4.12 Création du VRF au niveau NSX-T . . . . . . . . . . . . . . . . . . 48
4.13 Création T1 avec Terraform . . . . . . . . . . . . . . . . . . . . . . 48
4.14 Création des T1 au niveau NSX-T . . . . . . . . . . . . . . . . . . 49
4.15 Création des segements . . . . . . . . . . . . . . . . . . . . . . . . 49
4.16 création de segments au niveau NSX-T . . . . . . . . . . . . . . . . 50
4.17 Création de VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.18 Création du VPN au niveau NSX-T . . . . . . . . . . . . . . . . . 51
4.19 Création de Load Balancer . . . . . . . . . . . . . . . . . . . . . . 51
4.20 Création d Load Balancer au niveau NSX-T . . . . . . . . . . . . . 52
4.21 Security groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.22 Création des security groups . . . . . . . . . . . . . . . . . . . . . 53
4.23 Set members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.24 Création des policies et règles . . . . . . . . . . . . . . . . . . . . 54
4.25 création de la policy et l’ajout des règles . . . . . . . . . . . . . . . 54
4.26 IDS/IPS and Malware prevention . . . . . . . . . . . . . . . . . . . 55
4.27 Détection d’intrusion . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.28 Dashbord des résultats . . . . . . . . . . . . . . . . . . . . . . . . 56

12
Liste des acronymes

— IaC Infrastructure as Code

— tf Terraform
— CI Continuous Integration
— CD Continuous Delivery
— HLD High level design
— LLD Low level design
— VM machine virtuelle
— QoS Quality of service
— RTO Recovery time objective
— RPO Recovery point objective
— SDC Software defined compute
— SDS Software defined storage
— API Application Programming Interface
— VRF Virtual Routing and Forwarding
— T0 Tier 0 Gateway-NSX-T
— T1 Tier 1 Gateway-NSX-T
— BGP Border Gateway Protocol
— GRE Generic Routing Encapsulation
— VPN virtual Private Network
— DNS Domain Name System
— LAN Local Area Network
— DMZ Zone démilitarisée
— VLAN Virtual local area network

13
Introduction générale

Avec l’évolution rapide des technologies de l’information et de la communication,

les entreprises cherchent constamment à améliorer l’efficacité et la flexibilité de leurs
infrastructures informatiques. Dans ce contexte, les data centers software-Defined
(SDDC) représentent une approche innovante qui permet aux organisations de ré-
pondre à ces défis en dématérialisant les différentes couches d’infrastructure et en
les gérant par logiciel. Un des aspects clés du SDDC est la virtualisation du réseau,
également connue sous le nom de SDN (Software-Defined Networking).
Dans les data centers locaux traditionnels, plusieurs problématiques sont consta-
tées, notamment une gestion décentralisée de l’infrastructure et des difficultés pour
répondre aux exigences en matière d’évolutivité, de scalabilité, de maintenance et de
sécurité. C’est pour contourner ces différentes problématiques que le SDN a apparu,
rendant ainsi la gestion des data centers plus souple et agile.
Notre projet de fin d’étude, au sein du département Cloud Engineering de De-
loitte, s’articule autour de la migration de la plateforme Cloud de Deloitte vers la
solution SDN : NSX-T de VMware. Cette solution permet à l’entreprise d’avoir une
plateforme de virtualisation efficace et robuste en termes de centralisation, scalabi-
lité, sécurité et de maintenabilité.
Le présent rapport met en exergue le déroulement de notre projet pendant la pé-
riode de stage, et cela via quatre chapitres. Le premier chapitre présentant l’orga-
nisme d’accueil, le contexte, la problématique, les objectifs et le déroulement du
projet. Ensuite, Le deuxième chapitre étale l’étude de l’existant et les besoins fonc-
tionnels et techniques du projet. Quant au troisième chapitre, celui-ci présente les
technologies et les outils utilisés . Finalement, Le quatrième chapitre contient les
étapes de la réalisation de la migration et ses modalités.

1
 Chapitre 1

CADRE ET CONTEXTE DU STAGE

1.1 Introduction

Ce premier chapitre de notre rapport débute par une présentation de l’organisme

d’accueil . Nous définissons ensuite le contexte, la problématique et les objectifs de
notre projet, et donnons un aperçu du déroulement prévu. Ce chapitre pose les bases
de notre exploration et de notre travail dans le cadre de ce stage.

2
 CHAPITRE 1. CADRE ET CONTEXTE DU STAGE

1.2 Organisme d’accueil

1.2.1 Deloitte Touche Tohmatsu

Deloitte Touche Tohmatsu Limited, également connu sous le nom de Deloitte,

est un réseau mondial de services professionnels dont le siège se trouve à Londres,
au Royaume-Uni. Avec EY, KPMG et PricewaterhouseCoopers, Deloitte est l’une
des quatre grandes sociétés comptables et possède le plus grand réseau de services
professionnels au monde en termes de chiffre d’affaires et de personnel.
William Welch Deloitte a créé l’entreprise à Londres en 1845, puis l’a étendue
aux États-Unis en 1890. En 1972, il a fusionné avec Haskins and Sells pour créer De-
loitte Haskins Sells, et en 1989, il a fusionné avec Touche Ross aux États-Unis pour
créer Deloitte Touche. La société internationale a été rebaptisée Deloitte Touche
Tohmatsu en 1993 ; Deloitte était alors utilisé comme abréviation. En 2002, le bureau
britannique d’Arthur Andersen et un certain nombre d’autres bureaux en Europe, en
Amérique du Nord et en Amérique du Sud ont décidé de s’associer à Deloitte. Le
Monitor Group, une importante société de conseil stratégique, a été l’une des ac-
quisitions ultérieures, qui a eu lieu en janvier 2013. Un réseau d’entités juridiques
distinctes soutient le cabinet mondial, une société privée britannique à responsabilité
limitée par garantie.
Avec environ 334 800 experts dans le monde, Deloitte propose des services d’au-
dit, de conseil, de conseil financier, de conseil en matière de risques, de fiscalité et
de droit. Le réseau a réalisé un chiffre d’affaires combiné de 50,2 milliards de dol-
lars au cours de l’exercice 2021. Selon Forbes, Deloitte sera la troisième plus grande
entreprise privée des États-Unis d’ici 2020[1].

F IGURE 1.1 – Deloitte logo

3
 CHAPITRE 1. CADRE ET CONTEXTE DU STAGE

1.2.2 Deloitte Extended Services

Deloitte Extended Services (anciennement connu sous le nom de Deloitte Near-

shore) a été fondé en juillet 2009 et a mis en place une plateforme opérationnelle en
octobre 2010. Selon la loi marocaine, Deloitte Extended Services est une société à
responsabilité limitée. C’est un centre de responsabilité complet au sein du reporting
de gestion de Deloitte France et une filiale à 100 % de cette société. La gestion du
temps, la gestion de la performance, le conseil et la gestion de carrière sont autant
d’aspects du management que Deloitte Extended Services a totalement intégrés à
Deloitte France[2].

F IGURE 1.2 – Deloitte extended services new office in Casablanca

1.2.3 Digital Factory

La numérisation encourage l’optimisation du cœur de métier traditionnel, ce qui

libère des fonds pour de nouveaux projets d’entreprise. D’après notre expérience,
plusieurs entreprises ont déjà abordé la question de l’industrie 4.0, mais elles ont du
mal à mettre en pratique les idées intégrées.
La demande d’une chaîne d’approvisionnement intégrée s’accroît à mesure que
les nœuds traditionnels et linéaires de la chaîne d’approvisionnement se dissolvent
dans un ensemble de réseaux dynamiques. En tant que plaque tournante d’une chaîne
d’approvisionnement intelligente en réseau, le "cœur numérique" sert de moteur aux
nouveaux modèles d’entreprise et à la production de valeur à l’avenir.
Avec l’aide de l’usine numérique, nos clients, tout au long de leur parcours, de-
viennent entièrement numérisés et, ensemble, ils récolteront d’énormes bénéfices[2].

4
 CHAPITRE 1. CADRE ET CONTEXTE DU STAGE

F IGURE 1.3 – Deloitte Digital Factory

1.2.4 Les services de la firme

Les clients peuvent choisir parmi une large gamme de services d’audit et d’assu-
rance, de conseil, de conseil financier, de risque et de fiscalité fournis par les cabinets
membres de Deloitte. Pour les entreprises opérant partout dans le monde, les équipes
de service à la clientèle travaillent sous la direction d’un Lead Client Service Partner
pour développer des solutions commerciales efficaces.
Pour aider les clients à aller au-delà de leurs attentes, cette approche intégrée
allie la connaissance du monde des affaires et de l’industrie à la perspicacité et à la
créativité d’autres disciplines[2].

F IGURE 1.4 – Les services de la firme

Ainsi, qu’une entreprise soit en phase de démarrage ou sur le point de devenir une
puissance mondiale, les professionnels des cabinets membres de Deloitte peuvent
l’aider à gérer et à soutenir sa croissance.

5
 CHAPITRE 1. CADRE ET CONTEXTE DU STAGE

1.2.5 Les missions de la firme

Deloitte Nearshore est une plateforme multi-services qui fournit des solutions
d’externalisation pour le réseau Deloitte ainsi que directement à des clients en de-
hors du réseau : Les services de back office couvrent toutes les fonctions de Deloitte,
y compris les activités internes (hotline, contrôle, comptabilité, etc.) et les activi-
tés connexes telles que l’audit, l’AR et le conseil. Les services offerts aux clients
externes sont les suivants :

F IGURE 1.5 – Structure organisationnelle

Deloitte Extended Services regroupe des personnes issues des plus grandes écoles
de commerce et d’ingénieurs, formées et accompagnées par Deloitte France. Deloitte
Extended Services propose des services de conseil et d’ITO (IT Outsourcing) ainsi
que des services partagés et de la gestion d’applications[2].

6
 CHAPITRE 1. CADRE ET CONTEXTE DU STAGE

1.3 Cadre général du projet

1.3.1 Contexte du projet

Dans le contexte actuel, un nombre croissant d’entreprises manifeste une pré-

férence marquée pour des alternatives aux centres de données locaux traditionnels.
L’un des exemples notables de cette tendance est la firme Deloitte, qui a fait le choix
stratégique de déployer son infrastructure Cloud auprès d’OVH, un prestataire euro-
péen de services Cloud renommé. Ce dernier propose une large palette de services,
parmi lesquels le Hosted Private Cloud, un service de Cloud privé hébergé spécifi-
quement conçu pour répondre aux besoins des organisations modernes.
Le Cloud de Deloitte repose actuellement sur deux plateformes de virtualisa-
tion distinctes, à savoir Proxmox et VMware. Ces deux solutions technologiques
coexistent harmonieusement au sein d’un même réseau et hébergent une variété de
projets propres à Deloitte et à sa clientèle, couvrant un large éventail d’industries et
de secteurs d’activité.
L’infrastructure Cloud de Deloitte a connu une évolution en deux étapes majeures
au cours de son déploiement et de son développement. Dans un premier temps, l’in-
frastructure s’appuyait principalement sur Proxmox, une solution de virtualisation
open source. Quant à la protection pare-feu, elle et le routage, ils étaient assurés par
l’open source pfSense qui est hébergé sur la plateforme VMware. La seconde étape
de l’évolution du Cloud de Deloitte a été marquée par la décision de migrer de Prox-
mox vers VMware, une transition facilitée par la collaboration étroite avec OVH, qui
assure la gestion de l’infrastructure VMware. Cette migration a permis à Deloitte de
bénéficier d’une plateforme de virtualisation plus robuste et plus flexible, capable de
s’adapter aux besoins changeants de l’entreprise et de ses clients.
Dans le but de simplifier la gestion de son infrastructure Cloud et de garantir
une flexibilité et une évolutivité optimales, Deloitte a choisi d’adopter le concept de
Software-Defined Data Center (SDDC). Ce modèle repose sur l’utilisation de logi-
ciels pour définir, gérer et orchestrer les ressources informatiques, ce qui permet une
gestion centralisée et une grande adaptabilité pour répondre aux besoins spécifiques
des clients.
Plus précisément, Deloitte a opté pour la solution Software-Defined Network
(SDN) NSX-T de VMware, un outil de virtualisation réseau qui offre une gestion
centralisée, une automatisation avancée et une sécurité renforcée. Cette solution per-
met à Deloitte de gérer efficacement son réseau dans le cloud et de garantir un niveau
de service optimal pour ses clients.

7
 CHAPITRE 1. CADRE ET CONTEXTE DU STAGE

En conclusion, l’évolution de l’infrastructure Cloud de Deloitte, ainsi que son

adoption de technologies innovantes telles que le SDDC et le SDN, témoignent de
la volonté de l’entreprise de rester à la pointe de l’innovation et de proposer des
solutions toujours plus performantes et adaptées aux besoins de sa clientèle. Cette
démarche s’inscrit dans une tendance plus large, où les entreprises cherchent à tirer
parti des avantages offerts par les fournisseurs de services Cloud pour optimiser leur
infrastructure et garantir une évolutivité et une flexibilité.
La figure 1.1 ci-dessous récapitule le contexte de notre projet de fin d’études, en
mettant en relief les différents intervenants et en résumant leurs interactions.

F IGURE 1.6 – Contexte du projet

1.3.2 Problématique

Le caractère décentralisé du Networking et du Firewalling de la plateforme VM-

ware rend sa gestion exhaustive, et pose plusieurs problèmes de scalabilité et d’évo-
lutivité notamment dans le contexte où les clients de Deloitte commencent à ac-
croitre.
En outre, le firewalling et le routage de la plateforme était basé essentiellement
sur les pfSense, étant une solution open source, qui n’est ni maintenue ni managée, et
que VMware ne détient pas sa propriété intellectuelle, la gestion de l’infrastructure
s’avère particulièrement ardue.
Notre mission durant le stage consiste à utiliser la solution NSX-T de VMware
comme une alternative des pfSense. Cela nécessite une conception d’une architecture
adéquate de l’environnement cible basé sur NSX-T qui est adaptée à l’existant et
réaliser un setup de l’infrastructure de cet plateforme pour assurer une migration
réussie et sécurisée de l’infrastructure existante vers la nouvelle plateforme.

8
 CHAPITRE 1. CADRE ET CONTEXTE DU STAGE

1.3.3 Les objectifs du projet

Les objectifs de notre projet PFE est la mise en place d’une plateforme basée sur
NSX-T qui répond aux critères suivants :
— évolutive et s’adapte facilement aux changements.
— scalable en fonction de la charge et la clientèle.
— reactive par rapport aux besoins avancés de sécurité.
— facilement configurable et automatisable.
— permet la gestion centralisée de l’environnement.
Afin d’atteindre ces objectifs, nous devons entreprendre plusieurs actions :
— L’étude et l’évaluation de l’existant sur VMware.
— La conception de l’architecture de l’environnement cible VMware sous
NSX-T.
— La préparation d’un plan détaillé de la pré-migration, la migration et la
post-migration.
— Le setup de l’environnement cible .
— L’automatisation du déploiement en utilisant Terraform.

1.3.4 Equipe de travail

Le projet intitulé « Setup d’un cloud privé basé sur VMware » fait partie in-
tégrante du projet global Mise en place d’une Factory de migration ». Ce dernier
implique plusieurs étapes, allant de la définition des besoins et la conception jusqu’à
la mise en place de la plateforme et les tests. Il est donc essentiel que l’équipe dédiée
soit composée de membres aux compétences variées afin d’assurer le succès et la
fluidité du projet.

9
 CHAPITRE 1. CADRE ET CONTEXTE DU STAGE

F IGURE 1.7 – Equipe de travail

1.3.5 Conduite et planification du projet

Lors de ce projet, nous avons pu tenir plusieurs réunions et échanges avec le

département Cloud engineering du pôle français et Marocain de Deloitte.
La figure 1.2 ci-dessous représente le diagramme de GANTT relatif à notre projet
de fin d’études qui montre en détail les différentes tâches exécutées et leur ordonnan-
cement.

F IGURE 1.8 – Planification du projet

10
 CHAPITRE 1. CADRE ET CONTEXTE DU STAGE

Voici une description pour chaque phase de notre projet :

1. Étude de l’existant : Cette phase consiste à analyser et à comprendre l’infra-

structure, les systèmes et les processus actuels. Il s’agit d’évaluer les points forts et
les faiblesses de l’environnement existant, afin d’identifier les opportunités d’amé-
lioration et les défis potentiels.
2. Conception d’un High Level Design (HLD) : Ici, nous définirons la structure
globale du système, en mettant l’accent sur les aspects techniques et les interactions
de haut niveau entre les différents composants. C’est l’étape où l’on décrit l’archi-
tecture globale et les principes directeurs du système.
3. Low Level Design (LLD) : Au cours de cette phase, nous détaillerons davan-
tage l’architecture du système, en se concentrant sur les détails spécifiques de chaque
composant. Cela comprend la conception de modules spécifiques, les interfaces entre
ceux-ci et les protocoles de communication.
4. Processus de migration : Dans cette étape, nous définirons et mettrons en
œuvre une stratégie pour le transfert des données et des fonctionnalités de l’ancien
système vers le nouveau.
5. Configuration de l’environnement : À ce stade, nous préparerons l’infra-
structure nécessaire pour accueillir le nouveau système. Cela implique la mise en
place de serveurs, de bases de données, de logiciels, de réseaux et d’autres éléments
essentiels.
6. Pilotage : Cette phase implique la gestion active du projet pour assurer son
bon déroulement. Cela comprend le suivi des progrès, la résolution des problèmes et
la gestion des ressources.
7. Wave planning : Dans cette phase, nous planifions le déploiement du nouveau
système en plusieurs "vagues" ou phases, ce qui permet de minimiser les interrup-
tions de service et de gérer plus efficacement les ressources.
8. Exécution de la migration : C’est là que la migration réelle a lieu. Les données
et les fonctionnalités sont transférées de l’ancien système vers le nouveau, selon le
plan établi.
9. Activités post-migration : Après la migration, nous évaluerons la performance
du nouveau système, résoudrons les problèmes éventuels et effectuerons des ajuste-
ments selon les besoins.
10. Automatisation du déploiement avec Terraform : À cette étape, nous utili-
serons l’outil Terraform pour automatiser la création et la gestion de l’infrastructure
du nouveau système. Cela permettra de gagner en efficacité et en fiabilité, et de faci-
liter la gestion de l’infrastructure à long terme.

11
 CHAPITRE 1. CADRE ET CONTEXTE DU STAGE

Weekly meetings :
Les Weekly meetings d’environ 40 minutes sont d’une importance cruciale pour
la réussite de notre projet. Elles offrent à l’équipe l’occasion de faire le point sur les
réalisations majeures de la semaine écoulée et de discuter des prochaines étapes à en-
treprendre. Ces rencontres permettent également d’identifier les obstacles éventuels
et de trouver des solutions pour les surmonter. Ces moments d’échange favorisent la
communication, la collaboration et la cohésion au sein de l’équipe, contribuant ainsi
à l’avancement harmonieux du projet et à l’atteinte des objectifs fixés.

1.4 Conclusion

En clôture de ce premier chapitre, nous avons posé le cadre de notre projet, iden-
tifié les défis, fixé nos objectifs et présenté l’équipe et le plan d’action. Cette étape
préliminaire a jeté les bases pour comprendre les enjeux et les défis à relever. Le
prochain chapitre sera dédié à une analyse minutieuse de la plateforme actuelle pour
mettre en évidence les points forts à consolider et les faiblesses à surmonter.

12
 Chapitre 2

ETUDE DE L’EXISTANT ET BESOINS

FONCTIONNELS ET TECHNIQUES

2.1 Introduction :

Avant d’entreprendre la conception de la plateforme cible avec NSX-T, il est impé-

ratif de mener une étude approfondie de l’infrastructure actuelle.
Comme mentionné dans le chapitre précédent, deux plateformes, Proxmox et
VMware cohabitent sur le même réseau , avec la solution pfSense qui gère le net-
working et la sécurité.
Dans ce chapitre, nous procéderons à une analyse minutieuse de l’existant, afin
de déterminer les éxigences et les besoins fonctionnels et techniques spécifiques.

13
 CHAPITRE 2. ETUDE DE L’EXISTANT ET BESOINS FONCTIONNELS ET TECHNIQUES

2.2 Etude de l’existant

2.2.1 Introduction

A l’heure actuelle, la plateforme de Deloitte se base sur les PfSense qui assurent
de nombreuses fonctionnalités de sécurité et de routage.
En tant que firewall, ils permettent le filtrage des paquets, la prévention des in-
trusions, la détection des virus, la redirection de port, la création des VPNs, et bien
plus encore.
En tant que routeur, PfSense prend en charge les protocoles de routage dynamique
et statique, le NAT, l’équilibrage des charges, et il permet aussi de hiérarchiser et de
contrôler le trafic du réseau pour garantir la QoS.
Dans cette partie nous allons évaluer l’éxistant et ressortir les différents besoins
fonctionnels et techniques de notre projet.

2.2.2 Analyse et évaluation de l’existant

[Link] Extraction de données

Nous avons utilisé un script Python pour simplifier grandement notre travail d’ex-
traction de données. Ce script a été conçu pour interagir avec vSphere, où il récupère
des données spécifiques sur nos machines virtuelles et d’autres ressources. Ces don-
nées sont ensuite exportées dans un fichier Excel, ce qui nous permet de manipuler
et d’analyser facilement les données, selon nos besoins spécifiques.

14
 CHAPITRE 2. ETUDE DE L’EXISTANT ET BESOINS FONCTIONNELS ET TECHNIQUES

F IGURE 2.1 – Script python pour l’extraction des données

⇒ Extraction des projet et clients :

Il existe plusieurs clients et projets sur la plateforme VMware, donc il était judi-
cieux de les lister et les classifier selon plusieurs critères à savoir :
— Le degré de confidentialité
— Le niveau de criticité de charge de travail
— Les projets par VLAN
⇒Extraction des VLANs :
Il est crucial, pour la conception de l’architecture de l’environnement cible, de
procéder à l’identification minutieuse des VLANs.
En effet, l’environnement VMware en question compte environ 65 machines vir-
tuelles actives, connectées à divers VLANs, chacun étant affecté à un projet spéci-
fique. Ces projets peuvent être associés à l’entreprise Deloitte elle-même ou à l’un
de ses clients.

15
 CHAPITRE 2. ETUDE DE L’EXISTANT ET BESOINS FONCTIONNELS ET TECHNIQUES

⇒ Paramètres VPN :
L’évaluation des paramètres du VPN au niveau des pfSense nous a donné une
grande visibilité sur le type de VPN, de l’authentification, du cryptage, des réseaux
locaux et distants autorisés à communiquer via le VPN.
⇒Règles de firewalling :
Parmi les paramètres que l’évaluation des pfSense nous a permis de récolter, on
trouve les règles du pare-feu courantes qui comprennent l’autorisation et le blocage
du trafic entrant sur des ports spécifiques d’une interface donnée, l’autorisation et le
blocage du trafic sortant vers des destinations spécifiques.

[Link] Analyse de données

Après avoir utilisé notre script Python pour extraire les informations relatives
aux projets clients de Deloitte, aux VLAN, aux règles VPN et aux règles de pare-
feu depuis vSphere, nous avons pu effectuer une évaluation approfondie de notre
infrastructure actuelle basée sur pfSense. En exploitant ces données dans un fichier
Excel, nous avons pu identifier les modèles, les tendances et les anomalies dans notre
configuration réseau. Cela a permis de mettre en lumière des limitations potentielles
de notre plateforme actuelle, notamment en termes de performances, de sécurité et de
capacité de gestion. Par exemple, nous avons constaté des configurations de pare-feu
inefficaces, des VLAN surchargés, ou des règles VPN qui pourraient être optimisées.
Grâce à cette évaluation, nous avons acquis une compréhension plus précise de l’état
actuel de notre infrastructure réseau et avons pu établir une feuille de route pour
l’amélioration et l’évolution de la nouvelle plateforme.

2.2.3 Besoins techniques et fonctionnels

[Link] Besoins fonctionnels

La nouvelle plateforme basée sur NSX-T permet de :

⇒ Centraliser la gestion des réseaux virtuels :

Centraliser la gestion des réseaux virtuels en fournissant une plateforme de vir-

tualisation de réseau qui permet de créer et de gérer des réseaux virtuels à partir
d’une interface centralisée comme suit :

16
 CHAPITRE 2. ETUDE DE L’EXISTANT ET BESOINS FONCTIONNELS ET TECHNIQUES

— Créer des réseaux virtuels

— Fournir des fonctionnalités de routage
— Fournir des fonctionnalités de sécurité
— Permettre la micro-segmentation
— Automatiser le setup
⇒ Segmenter le réseau d’une manière granulaire :

Segmenter le réseau d’une manière granulaire en fournissant une micro-segmentation

des réseaux virtuels qui consiste à diviser le réseau en segments plus petits et plus
précis, afin de limiter la propagation des menaces et de renforcer la sécurité de l’in-
frastructure. Cela doit se concrétisé comme suit :
— Définition des politiques de sécurité
— Isolation des réseaux virtuels
— Intégration de la sécurité au niveau de l’hyperviseur
— Chiffrement des données
— Surveillance et détection des menaces
⇒ Automatiser et orchestrer les configurations :

Automatiser et orchestrer les configurations en offrant une API riche et en s’inté-

grant avec des outils d’automatisation tels que Ansible, Terraform et vRealize Auto-
mation qui permettent d’automatiser les workflows et de gérer l’infrastructure.

[Link] Besoins techniques

Notre projet doit répondre aux besoins techniques suivants :

⇒ Performance :
— Capacité et dimensionnement : Supporter nombre croissant de machines
virtuelles (VM) et une bande passante minimale de 40 Gbps.
— Latence minimale : Un temps de latence inférieur à 1 ms pour les applica-
tions critiques et inférieur à 5 ms pour les autres applications.
— Scalabilité : Être capable de doubler la capacité en termes de VM et de
bande passante sans compromettre les performances.

17
 CHAPITRE 2. ETUDE DE L’EXISTANT ET BESOINS FONCTIONNELS ET TECHNIQUES

⇒ Sécurité :
— Micro-segmentation : Isoler et protéger chaque application ou groupe d’ap-
plications avec des politiques de sécurité distinctes.
— Chiffrement : Utiliser un chiffrement AES-256 pour les données en transit
et au repos.
— Conformité : Se conformer aux normes telles que GDPR, HIPAA, et PCI
DSS, selon les exigences de l’entreprise.
⇒ Disponibilité :
— Haute disponibilité : Atteindre une disponibilité de 99,99 % pour les com-
posants critiques tels que les NSX Managers et les NSX Edges.
— Continuité des opérations : Être capable de restaurer les opérations cri-
tiques dans les 4 heures suivant un incident majeur, avec une perte maxi-
male de données de 15 minutes (RTO de 4 heures et RPO de 15 minutes).
— Monitoring et alertes : Surveiller en temps réel les performances du réseau
et envoyer des alertes en cas de problèmes détectés, avec une résolution des
incidents critiques en moins de 30 minutes.
— Maintenance : Planifier des mises à jour logicielles et des correctifs de
sécurité au moins une fois par trimestre, avec des tests de validation préa-
lables pour éviter les problèmes de compatibilité.

2.2.4 Exigences critiques

Dans notre projet,d’après le cahier de charges proposé par l’entreprise, il y a cer-

taines exigences clés qui doivent absolument être respectées, sinon notre plateforme
deviendra désuète. Le tableau ci-dessous présente ces exigences essentielles.

18
 CHAPITRE 2. ETUDE DE L’EXISTANT ET BESOINS FONCTIONNELS ET TECHNIQUES

Index Exigence
R.1 La plateforme doit être scalable
R.2 La plateforme doit assurer un niveau avancé de sécurité
R.3 La plateforme doit être toujours disponible et redondante sans in-
terruption de service
R.4 La plateforme doit être maintenable en cas de panne
R.5 La plateforme doit être performante
R.6 La plateforme doit permettre l’automatisation des configuration
R.7 La plateforme doit être compatible avec les environnements mul-
ticloud
R.8 La migration vers la nouvelle plateforme ne doit pas causer une
interruption de service

TABLE 2.1 – Tableau des exigences critiques

2.3 Conclusion

En résumé du deuxième chapitre, nous avons effectué une analyse approfondie de

la plateforme existante, basée sur pfSense, pour identifier ses limitations actuelles.
Cette étape cruciale nous a permis d’acquérir une compréhension précise de l’état de
l’infrastructure, qui servira de base pour les améliorations à venir. Dans le chapitre
suivant, nous nous concentrerons sur les technologies et les outils que nous allons
utilisés dans notre projet .

19
 Chapitre 3

TECHNOLOGIES, OUTILS ET
ARCHITECTURES

3.1 Introduction

Après l’étude minutieuse de la plateforme éxistante ,ce chapitre met en relief les
différentes technologies et outils qui interviennent dans la réalisation de notre projet
de fin d’étude .

20
 CHAPITRE 3. TECHNOLOGIES, OUTILS ET ARCHITECTURES

3.2 Introduction aux technologies utilisées

3.2.1 Introduction au SDDC

SDDC (Software-Defined Data Center) , un centre de données à définition logi-

cielle, est la prochaine évolution dans les infrastructures des Datacenter, ou le logiciel
fournit des niveaux plus élevés d’intelligence et de valeur.
Le SDDC apporte plusieurs avantages à savoir [3] :
— Une gestion simplifiée
— Une grande flexibilité
— Rapport cout-efficacité
— Haute évolutivité
SDDC existe sous trois formes :
— SDC : software-defined compute
— SDS : software-defined storage
— SDN : software-defined network

3.2.2 Technologie SDN

Dans le cadre de notre projet, nous avons décidé de nous appuyer sur la techno-
logie du Software Defined Networking (SDN). Cette technologie, au cœur de l’inno-
vation en matière de gestion de réseau, permet une flexibilité et une automatisation
accrues, essentielles à l’évolution dynamique de nos besoins. En exploitant le poten-
tiel du SDN, nous visons à optimiser la gestion de nos ressources réseau, améliorer
la sécurité et accroître l’efficacité de notre infrastructure informatique[4].

[Link] Réseau à définition logicielle vs Réseau classique :

SDN est un nouveau modèle du réseau informatique qui sépare la logique de

contrôle du réseau des équipements informatiques (Switch, [Link] a vu la lumière
parce que l’ancienne architecture des réseaux est devenue obsolète.

21
 CHAPITRE 3. TECHNOLOGIES, OUTILS ET ARCHITECTURES

En effet, pour configurer un équipement dans l’ancienne architecture il faut faire

une intervention au niveau de cet équipement. Par contre, le SDN ne nécessite qu’une
seule connexion physique avec les différents équipements, et à travers une API nous
pouvons gérer, contrôler et modifier le flux d’information au fur et à mesure que les
besoins évoluent. Cela permet d’implémenter des architectures dans lesquelles les
machines virtuelles résident sur leur propre réseau, complètement isolés de l’infra-
structure physique. Ceux-ci permet l’automatisation et la programmation des réseaux
et donc une évolution avec les activités d’entreprise.
La figure 2.5 ci-dessous compare le réseau classique au réseau SDN, ce dernier
centralise sa couche de contrôle contrairement à l’ancien modèle[6].

F IGURE 3.1 – Réseau traditionnel vs Réseau SDN

[Link] Avantages SDN

Le SDN offre de nombreux avantages par rapport aux réseaux traditionnels, no-
tamment :

— Contrôle renforcé avec plus de souplesse et un débit accéléré : au lieu de pro-

grammer manuellement plusieurs dispositifs matériels spécifiques à un fournis-
seur, les développeurs peuvent contrôler le flux de trafic sur un réseau simple-
ment via la programmation d’un contrôleur logiciel standard ouvert. Les admi-
nistrateurs réseau bénéficient également de plus de souplesse dans le choix de
l’équipement réseau, dans la mesure où ils peuvent utiliser un protocole open
source pour communiquer avec un nombre quelconque de dispositifs matériels
via un contrôleur central.

22
 CHAPITRE 3. TECHNOLOGIES, OUTILS ET ARCHITECTURES

— Infrastructure réseau personnalisable : Avec le SDN, les administrateurs peuvent

personnaliser l’infrastructure réseau, configurer les services et allouer des res-
sources virtuelles en temps réel à partir d’un emplacement central. Cela permet
d’optimiser le flux de données en privilégiant les applications nécessitant une
plus grande disponibilité.
— Sécurité renforcée : Le SDN offre une visibilité complète sur le réseau, permet-
tant une meilleure identification des menaces de sécurité. Il facilite la gestion
de la sécurité avec la prolifération des terminaux connectés, en permettant la
création de zones de sécurité distinctes ou la mise en quarantaine rapide de
terminaux menacés pour protéger le reste du réseau [5].

[Link] Les composants d’un réseau à définition logicielle

Plusieurs acteurs interviennent dans le fonctionnement du SDN, chaque compo-

sant a une mission très précise. Donc nous allons par la suite nous intéresser aux
spécifications de chaque composant dans cette architecture.

— Applications : elles communiquent des demandes de ressources ou des infor-

mations sur l’ensemble du réseau
— Contrôleurs : ils utilisent les informations provenant des applications pour dé-
cider de l’acheminement d’un paquet de données
— Périphériques réseau : ils reçoivent des informations du contrôleur sur l’en-
droit où déplacer les données[7]

F IGURE 3.2 – Composantes SDN

23
 CHAPITRE 3. TECHNOLOGIES, OUTILS ET ARCHITECTURES

3.3 NSX-T by VMware

3.3.1 Fonctionnalités du NSX-T

[Link] Commutation logique

Dans NSX-T, un segment est un logical switch, les segments sont similaires aux
VLAN, c’est une représentation d’un domaine de broadcast niveau 2. Un segment
exécute les fonctions d’un commutateur logique et se connecte aux passerelles (Tier-
1, Tier-0) et aux machines virtuelles.
En effet, les machines virtuelles qui sont attachées au même segment peuvent
communiquer entre elles même si elles sont sur des hosts différents sans passer au
niveau 3 (routage)[8].

F IGURE 3.3 – Connectivités entre deux VMs dans deux transport Nodes

En fonction de la « zone de transport » sélectionnée lors de la création d’un

segment, un segment VLAN ou segment Overlay est instancié.

[Link] Routage logique (Logical Routing) :

Dans NSX-T, le routage logique offre un moyen optimisé et évolutif de gérer le

trafic Est-Ouest et Nord-Sud. Le routage logique est distribué et séparé de l’Underlay.
Les décisions de transfert de base sont prises localement sur les noeuds de transport
préparés. Nous trouvons deux types de routage : routage nord-sud et routage est-
ouest.
— Le routage Nord-Sud permet aux tenants d’accéder aux réseaux extérieurs. La
direction du trafic entre ou sort du domaine administratif du tenant.

24
 CHAPITRE 3. TECHNOLOGIES, OUTILS ET ARCHITECTURES

— Le trafic Est-Ouest circule entre différents réseaux au sein d’un même tenant. Le
trafic est envoyé entre des réseaux logiques tels que les commutateurs logiques
sous le même domaine administratif.

=⇒ Il existe deux types de passerelles dans NSX-T : Tier-0 et Tier-1 :

— Routeur T0 (Tier-0 Gateway) :

Une passerelle de niveau 0 exécute les fonctions d’un routeur logique de niveau
0. Il traite le trafic entre les réseaux logiques et physiques. Elle fournit un trafic nord-
sud et elle peut être utilisée pour le trafic est-ouest si seul le niveau 0 est utilisé sans
un niveau 1. Une passerelle de niveau 0 a des connexions de liaison descendante
(downlinks) vers des passerelles de niveau 1 et des connexions de liaison montante
(uplinks) vers des réseaux physiques [9].

— Routeur T1 (Tier-1 Gateway) :

Une passerelle de niveau 1 a des connexions de liaison descendante vers des

segments et des connexions de liaison montante vers des passerelles de niveau [Link]-
1 ne peut pas accéder au monde extérieur sans Tier-0, cette passerelle est utilisée pour
le trafic est-ouest. La liaison descendante connecte les segments aux passerelles [10].

— Notion de VRF

La notion de VRF (Virtual Routing and Forwarding) dans NSX-T est une fonc-
tionnalité qui permet de créer plusieurs instances de routage virtuelles à l’intérieur
d’un même routeur, soit physiquement, soit plus couramment dans un environnement
virtuel comme avec NSX-T. Dans le contexte de NSX-T, chaque instance VRF est
comme un routeur virtuel indépendant avec sa propre table de routage, ses propres
interfaces et son propre ensemble de règles et de configurations. Cela permet de seg-
menter un réseau en plusieurs domaines de routage indépendants, chacun avec sa
propre politique de routage[11].

25
 CHAPITRE 3. TECHNOLOGIES, OUTILS ET ARCHITECTURES

−→ Topologies :
Nous avons la possibilité d’implémenter deux types de topologies[12] :
1. Topologie à un seul niveau (Single Tier) : Dans un déploiement à un seul
niveau les segments de réseau sont connectés directement à la passerelle de niveau
0, la passerelle de niveau 1 n’existe pas.
2. Topologie à deux niveaux (Multitier) : Le concept de multi-location est intégré
au mode de [Link] structure donne aux administrateurs d’une architecture
NSX-T un contrôle total sur tous les services et politiques.

F IGURE 3.4 – Topologies sous NSX-T

=⇒ Composants du Tier-0 et Tier-1

Nous trouvons dans les passerelles Tier0 et Tier1 essentiellement : un Routeur
Distribué (DR) et un Routeur de service (SR).

26
 CHAPITRE 3. TECHNOLOGIES, OUTILS ET ARCHITECTURES

F IGURE 3.5 – Composants du T0 et T1

Routeur distribué (DR) :

Un DR est toujours créé lors de la création d’une passerelle, il fournit la fonction-
nalité du routage distribuée est-ouest. Le DR s’étend sur tous les noeuds de transport
(hyperviseurs et noeuds Edge).
Routeur de service (SR) :
Un SR est automatiquement créé sur le noeud Edge lorsqu’on configure la passe-
relle avec un Edge cluster. En fait, il fournit une fonctionnalité de routage nord-sud.
Aussi, il fournit des services de routage et des services centralisés tels que NAT,
équilibrage de charge, etc. NB : Il faut noter que le SR est créé uniquement sur les
noeuds NSX Edge faisant partie d’un Edge cluster, mais pas sur un hyperviseur.

[Link] Load Balancing :

Dans NSX-T Data Center, le load balancer distribue les demandes de service en-
trantes entre plusieurs serveurs et offre une haute disponibilité pour les applications
[13].
Nous utilisons l’équilibrage de charge lorsque :

— La redondance des serveurs est nécessaire pour éviter les pannes.

— Un temps de réponse rapide est nécessaire en répartissant les demandes des
clients sur plusieurs serveurs.

27
 CHAPITRE 3. TECHNOLOGIES, OUTILS ET ARCHITECTURES

Le Load Balancer doit être attaché à un T1. Il comprend des serveurs virtuels :
un serveur virtuel est une abstraction de service représentée par une combinaison
d’une adresse IP virtuelle, d’un port et d’un protocole. Les clients externes utilisent
cette adresse IP, ce port et ce protocole pour accéder aux serveurs derrière le Load
Balancer.

F IGURE 3.6 – fonctionnement du load balancer

[Link] VPN :

NSX-T Data Center supporte les types de VPN suivants : IPSec VPN, Layer 2
VPN. Ces types sont supportés uniquement en Tier-0 gateways et nécessitent les
NSX Edge nodes pour qu’ils fonctionnent [14].

=⇒ Types de VPN :

— IPSec VPN :

Permet aux entreprises d’interconnecter les réseaux IP distants en toute sécurité.

IPSec VPN étend les réseaux IP aux bureaux distants, fournit un canal de commu-
nication sécurisé pour d’autres tels que GRE. Lors du déploiement du VPN IPsec,
nous devons tenir compte de plusieurs facteurs :
— Les services VPN IPSec ne sont disponibles que sur les passerelles Tier-0
en mode active-standby.
— Les segments peuvent être connectés à des passerelles Tier-0 ou Tier-1 pour
tirer parti des services VPN.
— NSX-T Data Center prend en charge les VPN IPSec de site à site en mode
tunnel.
— Les tunnels IPSec tirent parti des performances accélérées par DPDK.

— L2 VPN :

28
 CHAPITRE 3. TECHNOLOGIES, OUTILS ET ARCHITECTURES

=⇒ peut être utilisé à différentes fins :

— Étend les réseaux (VLAN ou VNI) sur les sites du même domaine de diffusion
(Broadcast Domain).
— Active les cas d’utilisation de mobilité de VM tels que : Migration, reprise après
sinistre sans changement d’adresse IP.

=⇒ Dans NSX-T Data Center, le L2 VPN présente les caractéristiques suivantes :

— Les services NSX L2 VPN ne sont disponibles que sur les passerelles de niveau
0 (Tier-0).
— Les segments peuvent être connectés à des passerelles de niveau 0 (Tier-0) ou
de niveau 1 (Tier-1) pour utiliser les services L2VPN.
— Il introduit une nouvelle méthode de transport (GRE sur IPSec).

3.3.2 Architecture de NSX-T :

Fondamentalement, d’après la documentation de VMware , il y a trois compo-

sants principaux de l’architecture NSX-T : Management plane, Control plane, Data
plane [15].

F IGURE 3.7 – Architecture NSX-T

29
 CHAPITRE 3. TECHNOLOGIES, OUTILS ET ARCHITECTURES

3.4 Devops avec terraform et Gitlab

3.4.1 Infrasctructure as code

L’infrastructure en tant que code (IaC) utilise la méthodologie DevOps et le ver-

sionnage avec un modèle descriptif pour définir et déployer l’infrastructure, comme
les réseaux, les machines virtuelles, les équilibreurs de charge et les topologies de
connexion. Tout comme le même code source génère toujours le même binaire, un
modèle IaC génère le même environnement à chaque fois qu’il est déployé.
L’IaC est une pratique clé de DevOps et un composant de la livraison continue.
Avec l’IaC, les équipes DevOps peuvent travailler ensemble avec un ensemble unifié
de pratiques et d’outils pour fournir des applications et leur infrastructure de soutien
rapidement et de manière fiable à l’échelle.

3.4.2 Terraform

Terraform est un outil d’infrastructure en tant que code qui vous permet de construire,
de modifier et de mettre à jour votre infrastructure de manière sûre et efficace. Cela
inclut des composants de bas niveau comme les instances de calcul, le stockage et
le réseau, ainsi que des composants de haut niveau comme les entrées DNS et les
fonctionnalités SaaS [16].

F IGURE 3.8 – Terraform

30
 CHAPITRE 3. TECHNOLOGIES, OUTILS ET ARCHITECTURES

3.4.3 Gitlab

GitLab CI/CD est un outil de développement de logiciels utilisant les méthodo-

logies continues :
— Intégration continue (CI)
— Livraison continue (CD)
— Déploiement continu (CD)
GitLab CI/CD est Utiliseé pour détecter les bogues et les erreurs dès le début du
cycle de développement. Et pour s’assurer que tout le code déployé en production
est conforme aux normes de code que vous avez établies pour votre application.
GitLab CI/CD peut automatiquement construire, tester, déployer et surveiller les
applications en utilisant Auto DevOps[17].

F IGURE 3.9 – Gitlab

3.5 Conclusion

Ce chapitre a ouvert une fenêtres sur les différentes technologies et outils utili-
sées, dans le chapitre suivant nous présentons les différentes péripéties de la réalisa-
tion de notre projet de fin d’étude.

31
 Chapitre 4

REALISATION ET VALIDATION DE LA
MIGRATION

4.1 Introduction

Après l’introduction des différents concepts utilisés et la solution NSX-T,ce cha-

pitre portera essentiellement sur la présentation des différentes arhitectures que nous
avons proposées pour l’environnement cible, les différentes activités de pré-migration,et
le setup de l’environnement cible en utilisant Terraform .

32
 CHAPITRE 4. REALISATION ET VALIDATION DE LA MIGRATION

4.2 Architecture

4.2.1 Conception d’un high level design

Après avoir étudier l’existant , il est temps de concevoir une architecture haut-
niveau de l’environnement cible. Celle-ci permet de définir la structure et l’architec-
ture globale de l’environnement cible,et d’avoir une vue générale sur ses différents
composants, interfaces, l’intéraction avec les utilisateurs, ainsi que les différents be-
soins logiciels et matériels.

4.2.2 Scénarios du déploiement

Il existe plusieurs possibilités pour l’organisation des T0 et des VRFs :

— T0 dédié : Concerne les zones sensibles et nécessitant une haute disponibilité .

— T0 partagé : Concerne les zones moins sensibles, celui-ci contient plusieurs
VRFs devisés à leur tour en deux catégories :
— VRFs dédiés : pour les clients critiques .
— VRFs partagés : pour les clients nécessitant des services de faible criticité.

La figure ci-dessous présente les trois scénarios possibles :

F IGURE 4.1 – Scénarios de déploiment

33
 CHAPITRE 4. REALISATION ET VALIDATION DE LA MIGRATION

[Link] Le premier scénario

⇒ Deloitte Admin Zone :

Choix du T0 :
La zone d’administration de Deloitte est une zone critique qui nécessite une cer-
taine isolation des flux extérieurs , ainsi qu’une sécurité avancée , et assurer une
haute disponibilité . Pour cela il est primordial de lui préserver son propre T0 qui lui
permettra à la fois de communiquer avec des sites distants (LAN to LAN ),d’être liée
à internet en toute sécurité et d’interagir avec les différents clients.
— Accès internet : la mise en place du VPN va permettre à un utilisateur
d’accéder à la zone d’administration de Deloitte en toute sécurité.
— Liaison LAN to LAN : Pour se connecter à des sites distants, Deloitte ad-
min zone va passer par le routage.
— Connection avec les clients : pour permettre à Deloitte admin zone de se
connecter avec ses différents clients, nous allons créer un vLan chez OVH
au niveau de la couche physique et précisément sur le réseau étendu vRack
, qui va rassembler les différents T0 des clients ainsi que celui de l’admi-
nistration .
Choix des T1 :
En général , il existe deux type de flux dans la zone d’administration , un flux de
contrôle et un flux de donnée . Pour cela nous allons créer deux T1 , chacun pour un
type de flux .
— T1 Admin : C’est à ce niveau que la gestion du flux de contrôle et le firewal-
ling E-W ont lieu. Le T1 contient des Vms qui sont attachés respectivement
aux différents segments. Chaque Segment concerne un projet donné.
— T1 DMZ : est un sous-réseau séparé qui sert de tampon entre le réseau in-
terne de Deloitteet le réseau public, généralement Internet. Elle a pour prin-
cipal objectif de fournir une couche de sécurité supplémentaire. En plaçant
les systèmes exposés au public, comme les serveurs web ou de messagerie,
dans la DMZ, on réduit le risque qu’une attaque réussie contre ces systèmes
compromette le reste du réseau interne.
⇒ Les zones clients :
Choix des T0 :
Comme nous avons fait pour l’admin zone , la zone clients aura un T0 dédié.Selon
les scénarios établis précédemment et en fonction de la criticité des workloads des
clients , nous allons répartir les clients sur des VRFs au sien du même T0 :

34
 CHAPITRE 4. REALISATION ET VALIDATION DE LA MIGRATION

— VRF dédiés pour les clients dont les workloads sont de nature critique
— VRF partagés pour les autres clients .
Choix des T1 :
En outre nous allons conserver la même topologie pour les T1 des différents
tenants que celle de la zone d’admin.
Ci-dessous l’architecture du premier scénario :

F IGURE 4.2 – High level Design : Scénario 1

[Link] Le deuxième scénario

Du fait que l’environnement est managé , il arrivait souvent que les architectures
que nous proposons soient heurtées aux exigences de l’offre VMware by OVH. Ce
qui nécessite une adaptation continue de notre part. C’est pour cette raison que nous
avons proposé une deuxième architecture,figure 4.3, se composant :

— D’un unique T0 : Managé par OVH, quelques configurations sont permises de

notre part à savoir la configuration du routage, pare-feu nord-sud, ..
— De multiples VRFs séparant les différents tenants : Les VRFs permettent
d’acheminer le trafic des différents tenants d’une manière isolée.

35
 CHAPITRE 4. REALISATION ET VALIDATION DE LA MIGRATION

F IGURE 4.3 – High level Design : Scénario 2

[Link] Troisième scénario

Comme le deuxième scénario, ce scénario de déploiement consiste à utiliser un

seul T0 managé par OVH, et deux types de VRFS :

— VRF dédié : Ce VRF permet d’isoler le traffic de Deloitte Admin Zone.

— VRF partagé : Le traffic de plusieurs clients est acheminé par le meme VRF.

F IGURE 4.4 – High level design :Troisième scénario

36
 CHAPITRE 4. REALISATION ET VALIDATION DE LA MIGRATION

[Link] Avantages, Inconvénients et Coût de chaque scénario

Afin de prendre une décision par rapport au choix du scénario de déploiement,

nous avons dressé le tableau ci-dessous qui résume leur différents avantages, incon-
vénients, et compare leur couts ( De la part du Cloud Provider )
Scénario Avantage Inconvénient Coût
Scénario 1 Isolation totale du trafic des -Difficulté à lier la zone d’ad- -Elevé par rapport aux
clients de celui de la zone ministration de Deloitte avec autres scénarios.
d’administration : Très sécu- l’autre T0 des clients.
risé. -Il n’est pas approuvé par
OVH
Scénario 2 -Isolation du trafic des dif- -Moins sécurisé : Trafic des -Inclus dans l’offre
férents clients et celui de la clients et de la zone d’admi- VMware by OVH.
zone d’administration en uti- nistration n’est pas complète-
lisant les VRFs dédiées à ment isolé : Ils partagent le
chaque tenant séparément. même T0.
-Simplicité du déploiement
-Chaque client possède sa
propre VRF : Répond à l’exi-
gence de sécurité des clients.
-Approuvé par OVH

Scénario 3 -Le trafic de la zone d’admi- -Moins sécurisé pour les -Inclus dans l’offre
nistration et celui des clients clients : Le trafic des clients VMware by OVH.
est isolés dans le même T0. - est acheminé par une VRF
Approuvé par OVH partagée. Une contrainte
qui peut être refusée par les
clients.

TABLE 4.1 – Tableau de Comparaison des scénarios

[Link] Choix du scénario

Pour choisir un scénario, il fallait discuter les trois propositions avec OVH. Le
premier scénario a été réfusé car le cloud provider n’offre qu’un seul T0. Ce qui nous
a poussé à choisir le deuxième scénario, étant donné que celui-ci répond à tous les
besoins techniques et fonctionnels,cités dans le chapitre 2, et il est à l’encontre du
troisième scénario, plus flexible par rapport aux exigences de sécurité des clients.

37
 CHAPITRE 4. REALISATION ET VALIDATION DE LA MIGRATION

4.3 Les activités de pré-migration

4.3.1 Cutover strategy

La phase de cutover est une étape cruciale dans notre projet de migration de
pfSense à NSX-T. Cette phase implique le basculement de nos systèmes actuels vers
la nouvelle plateforme NSX-T.
Deux scénarios principaux sont envisagés : le premier consiste à conserver les
adresses IP existantes, tandis que le second implique un changement complet des
adresses IP. Chaque scénario nécessite une stratégie de cutover distincte pour assu-
rer une transition fluide et minimiser les perturbations. Après avoir préparé la zone
d’atterrissage, nous sommes maintenant prêts à basculer.
Il est donc essentiel de définir et de suivre un processus de cutover bien structuré
pour garantir le succès de cette migration.

[Link] Premier use case

Dans le premier scénario, où nous conservons les adresses IP existantes, le pro-

cessus de cutover se déroule comme suit :
1. Après avoir créé la zone d’atterrissage, qui comprend les T1, les segments et
les règles de pare-feu, nous commençons par basculer les groupes de ports vers
les segments. À ce stade, la communication se fait toujours via l’ancienne pas-
serelle.
2. Ensuite, nous arrêtons l’ancienne passerelle et modifions l’adresse de la passe-
relle dans les machines virtuelles.
3. Après cela, nous ajoutons une route statique dans tous les pfSense.
4. Nous procédons ensuite au nettoyage des routes statiques dans le T0.
5. Si tout fonctionne correctement, nous passons aux tests de post-migration. Si
des problèmes surviennent, nous effectuons un rollback pour revenir à l’état
précédent.
Ce processus structuré assure une transition fluide vers NSX-T tout en minimisant
les perturbations potentielles.
la figure 4.5 montre les étapes à suivre :

38
 CHAPITRE 4. REALISATION ET VALIDATION DE LA MIGRATION

F IGURE 4.5 – Processus de Cutover : 1 use case

[Link] Deuxième use case

Dans le deuxième scénario, où nous changeons les adresses IP, le processus de

cutover se déroule de la manière suivante :

1. Après avoir créé la zone d’atterrissage et basculé les groupes de ports vers les
segments, nous devons modifier la configuration IP. Cette étape dépend du sys-
tème d’exploitation de la machine.
2. Si la machine est sous Windows, nous vérifions d’abord si elle appartient à
l’Active Directory. Si c’est le cas, la configuration IP est automatique. Si ce
n’est pas le cas, nous devons mettre à jour le DNS manuellement.
3. Si la machine est sous Linux, nous devons obligatoirement changer le DNS.
4. Une fois ces modifications effectuées, nous passons aux tests de post-migration.

Ce processus structuré permet une transition en douceur vers NSX-T avec un

changement complet des adresses IP, tout en minimisant les perturbations poten-
tielles.

39
 CHAPITRE 4. REALISATION ET VALIDATION DE LA MIGRATION

F IGURE 4.6 – Processus de Cutover : 2 use case

4.3.2 Rollback process

Un processus de rollback détaillé est essentiel pour minimiser les perturbations

en cas de problèmes lors de la migration. Voici un processus de rollback détaillé pour
chaque scénario :
Scénario 1 (conservation des adresses IP existantes) :

— Nous comencons par supprimer la route statique que nous avons ajoutée dans
pfSense. et s’assurer de documenter les détails de cette route avant de la suppri-
mer pour faciliter ce processus.
— Modifier l’adresse de la passerelle dans les machines virtuelles pour revenir à
l’ancienne passerelle. Nous devons peut-être redémarrer les machines virtuelles
pour que ce changement prenne effet.
— Basculer les segments vers les groupes de ports d’origine. Cela implique de mo-
difier les paramètres de réseau de chaque machine virtuelle pour qu’elle utilise
à nouveau les groupes de ports d’origine.
— Enfin, redémarrer l’ancienne passerelle pour rétablir la communication.

Scénario 2 (changement des adresses IP) :

— Si la machine est sous Windows et n’appartient pas à l’Active Directory, Nous

allons rétablir le DNS d’origine. Cela implique de modifier les paramètres de
réseau de la machine pour qu’elle utilise à nouveau le DNS d’origine.

40
 CHAPITRE 4. REALISATION ET VALIDATION DE LA MIGRATION

— Si la machine est sous Linux, nous allons rétablir la configuration DNS d’ori-
gine.
— Basculer les segments vers les groupes de ports d’origine. Comme dans le scé-
nario 1, cela implique de modifier les paramètres de réseau de chaque machine
virtuelle.
— Enfin, rétablir la configuration IP d’origine. Cela peut nécessiter de redémarrer
les machines virtuelles pour que le changement prenne effet.

Ces processus de rollback garantissent que, en cas de problèmes lors de la migra-

tion, nous pouvons revenir à l’état précédent avec le moins de perturbations possible.

4.3.3 PlayBook

Dans le cadre de notre projet de migration, nous avons élaboré un playbook ex-
haustif qui détaille chaque étape clé du processus, garantissant ainsi une transition
fluide et efficace vers le nouveau système. Ce playbook les éléments suivants :

— Évaluer l’environnement pfSense actuel

— Collecter des informations sur les règles de pare-feu
— Cataloguer les réseaux virtuels
— Analyser les configurations de routage
— Recenser les serveurs DHCP et DNS
— Identifier tout autre service en cours d’utilisation

— Planifier la migration vers NSX-T

— Définir les réseaux logiques pour NSX-T
— Prévoir l’application des politiques de pare-feu
— Planifier le placement des charges de travail dans NSX-T

— Configurer NSX-T
— Configurer les commutateurs logiques NSX-T
— Configurer les groupes de sécurité NSX-T
— Installer et configurer les passerelles NSX-T

— Tester la configuration NSX-T

— Vérifier les fonctionnalités de NSX-T

41
 CHAPITRE 4. REALISATION ET VALIDATION DE LA MIGRATION

— Effectuer des tests de performance

— Exécuter des tests de sécurité

— Migrer les charges de travail de pfSense vers NSX-T

— Vérifications de post-migration
— Vérifier les règles de pare-feu
— Contrôler les fonctionnalités de routage
— Assurer le bon fonctionnement des autres services

— Maintenance et surveillance continues de NSX-T

— Effectuer une surveillance continue de NSX-T

— Effectuer des revues régulières de sécurité et de performance

— Désactiver pfSense
— Planifier et exécuter la désactivation de pfSense une fois que NSX-T est
opérationnel

4.3.4 Wave planning

Nous avons réparti la migration de la plateforme sur 5 vagues :

— Vague 0 : Préparation

Pour commencer, nous effectuerons une évaluation détaillée de notre infrastruc-

ture, en identifiant les dépendances, les fenêtres de maintenance, les parties prenantes
et les détails spécifiques de chaque segment.

— Vague 1 : environnements non critiques

Nous commencerons par migrer nos environnements les moins critiques, tels que
nos réseaux de développement et de test, ou ceux qui soutiennent nos services non
essentiels. Nous utiliserons ces premières migrations pour tester et affiner notre pro-
cessus.

— Vague 2 : environnements de faible criticité

Ensuite, nous passerons à des segments légèrement plus critiques. Ces segments
peuvent encore être migrés pendant les heures normales, mais nous veillerons à com-
muniquer et coordonner nos efforts avec toutes les parties prenantes pour minimiser
les perturbations.

42
 CHAPITRE 4. REALISATION ET VALIDATION DE LA MIGRATION

— Vague 3 : Nos environnements de criticité modérée

Ensuite, nous commencerons à migrer nos segments de criticité modérée. Ces

migrations nécessiteront une coordination et une planification plus rigoureuses de
notre part, et devront être effectuées pendant des fenêtres de maintenance spécifiques
pour minimiser les perturbations.

— Vague 4 : environnements de haute criticité

Avant d’aborder La zone Admin de deloitte, nous migrerons les segments de

haute criticité qui ne sont pas associés à ce dernier. Ces migrations devront être
effectuées pendant des fenêtres de maintenance soigneusement planifiées, et nous
devrons avoir un plan de reprise complet en place en cas de problèmes.

— Vague 5 : La zone Admin de Deloitte

Enfin, nous migrerons la zone Admin de Deloitte. Etant donné que ce segment
est le plus critique, nous lui accorderons la plus grande attention et la plus grande
planification. Nous veillerons à avoir une fenêtre de maintenance clairement définie,
un plan de reprise en cas de problèmes, et une communication étroite avec toutes les
parties prenantes.
Après chaque vague, nous effectuerons une évaluation post-migration pour iden-
tifier les leçons que nous avons apprises et pour apporter des améliorations à notre
processus de migration.

4.4 Automatisation du setup avec Terraform et GitLab

4.4.1 Introduction à l’Automatisation du Projet

L’automatisation joue un rôle crucial dans notre projet, permettant un déploie-

ment rapide, fiable et reproductible de l’infrastructure. Pour atteindre cet objectif,
nous avons choisi Terraform, un outil d’Infrastructure as Code (IaC) largement re-
connu pour sa flexibilité et sa capacité à gérer et orchestrer diverses ressources cloud.
En complément, nous avons utilisé GitLab, une plateforme DevOps complète, pour
automatiser le processus de déploiement. Grâce à l’intégration de GitLab avec Ter-
raform, nous avons pu mettre en place des pipelines d’intégration continue/déploie-
ment continu (CI/CD) qui permettent d’automatiser le déploiement de l’infrastruc-
ture dès qu’une modification est apportée au code. Cette combinaison de Terraform
et GitLab a grandement simplifié le processus de déploiement, rendant notre infra-
structure facilement reproductible et adaptable..

43
 CHAPITRE 4. REALISATION ET VALIDATION DE LA MIGRATION

4.4.2 Les Configurations NSX-T Automatisées et pipline CI/CD

Au cours de ce projet, nous avons automatisé plusieurs configurations clés de

NSX-T à l’aide de Terraform. Cela inclut la création et la gestion des réseaux virtuels,
la configuration des pare-feux, le paramétrage des passerelles et la mise en place des
services de routage et de commutation.
En utilisant des modules Terraform personnalisés et des fichiers de configuration
déclaratifs, nous avons pu décrire les ressources nécessaires pour chacune de ces
configurations, ainsi que les relations entre elles. Grâce à cette approche, l’ensemble
de l’infrastructure est défini par le code, ce qui facilite non seulement le processus de
déploiement, mais aussi la maintenance et l’évolutivité. De plus, l’automatisation des
configurations a permis de réduire les erreurs humaines et d’assurer une cohérence
accrue entre les déploiements, contribuant ainsi à améliorer la fiabilité et la sécurité
de notre environnement.

F IGURE 4.7 – Structure du projet terraform

Ces configurations étaient alors automatiquement déployées via notre pipeline

GitLab chaque fois qu’une modification était apportée et validée, assurant ainsi une
mise à jour rapide et fiable de notre infrastructure :

44
 CHAPITRE 4. REALISATION ET VALIDATION DE LA MIGRATION

F IGURE 4.8 – Fichier [Link] pour l’automatisation

4.4.3 Execution de la configuration

L’exécution du fichier Terraform dans le contexte du pipeline CI/CD GitLab que

nous avons implémenté suit généralement le cycle de vie suivant :
— Développement : Nous avons créer les fichiers Terraform comme montré dans
la partie précédente . Ces fichiers définissent l’infrastructure souhaitée.
— Validation : Nous avons validé les fichiers Terraform localement, en utilisant
des commandes comme ‘terraform validate‘ et ‘terraform plan‘.
— Commit et Push : Une fois que les fichiers sont validés, le développeur les
commit dans le dépôt Git, puis les pousse vers le dépôt distant sur GitLab.
— Pipeline CI/CD : Lorsque les fichiers sont poussés sur GitLab, cela déclenche
le pipeline CI/CD défini dans le fichier ‘.[Link]‘. Ce pipeline peut in-
clure des étapes pour la validation supplémentaire, le plan d’infrastructure et
l’application de l’infrastructure.
— Validation CI/CD : Dans la phase de validation du pipeline, GitLab exécute
‘terraform validate‘ sur le serveur CI/CD pour vérifier la syntaxe et la validité
des fichiers Terraform.
— Plan CI/CD : Ensuite, GitLab exécute ‘terraform plan‘ pour générer un plan
d’infrastructure. Ce plan montre ce que Terraform fera lorsque vous exécutez
‘terraform apply‘. Cela permet nous permet de vérifier le plan avant d’appliquer
les modifications.

45
 CHAPITRE 4. REALISATION ET VALIDATION DE LA MIGRATION

— Application CI/CD : Enfin, si le plan est acceptable, GitLab exécute ‘terraform

apply‘ pour appliquer les modifications à l’infrastructure. Cela crée, modifie ou
supprime les ressources pour faire correspondre l’infrastructure à la définition
dans les fichiers Terraform.
— Rétroaction : Après l’exécution de ‘terraform apply‘, le pipeline renvoie des
informations sur les modifications apportées. Si des erreurs se produisent, elles
sont également signalées à cette étape.
— Cycle de répétition : Si des modifications supplémentaires sont nécessaires,
Nous deveons revenir à l’étape 1 et le cycle recommence.

4.4.4 Illustrations des Configurations et du Processus d’Automatisation

[Link] Networking

−→ Création de T0 :
La mise en place d’un routeur de niveau 0 (T0) dans NSX-T est une étape cru-
ciale pour établir le routage et la connectivité dans votre environnement de réseau
virtuel. Le routeur T0 sert de point d’ancrage pour le trafic nord-sud, facilitant la
communication entre les réseaux virtuels internes et les réseaux physiques externes.
De plus, le routeur T0 est responsable de la distribution du trafic vers les différents
routeurs de niveau 1 (T1) qui lui sont connectés.
Un routeur T0 est généralement associé à un Edge Cluster dans NSX-T. L’Edge
Cluster est un ensemble de noeuds Edge qui collaborent pour fournir des services
de réseau et de sécurité hautement disponibles. Lors de la configuration d’un routeur
T0, il est nécessaire de spécifier plusieurs paramètres, dont l’ID du Edge Cluster
auquel le routeur sera associé.
La figure 4.7 représente la configuration avec terraform pour la création du T0 :

F IGURE 4.9 – Création du T0

Après l’éxecution du code et l’intégration dans le pipeline CI/CD , nous avons

obtenue le résultat suivant qui montre la création du T0 :

46
 CHAPITRE 4. REALISATION ET VALIDATION DE LA MIGRATION

F IGURE 4.10 – Création du T0 au niveau NSX-T

−→ Création de VRF :
Les Virtual Routing and Forwarding (VRF) instances que nous avons créées au
niveau du routeur T0 dans NSX-T jouent un rôle crucial dans la segmentation du
trafic réseau. Chaque instance VRF agit comme un routeur virtuel distinct au sein du
même routeur physique T0, permettant d’isoler le trafic de différents locataires ou
applications sans nécessiter de matériel de routage supplémentaire.
Chaque instance VRF peut avoir ses propres politiques de routage et de sécurité,
ce qui nous permet de personnaliser le comportement du réseau pour chaque locataire
ou application. Cela rend notre réseau plus adaptable aux besoins spécifiques de
chaque cas d’utilisation.
La Figure 4.9 illustre le processus de création d’un VRF ainsi que les configura-
tions associées à cette mise en place.

F IGURE 4.11 – Création du VRF dans le T0

47
 CHAPITRE 4. REALISATION ET VALIDATION DE LA MIGRATION

Suite à l’exécution du code et son intégration dans le pipeline CI/CD, le résultat

obtenu, illustrant la création du VRF, est le suivant :

F IGURE 4.12 – Création du VRF au niveau NSX-T

−→ Création des T1 :
Pour automatiser le paramétrage des passerelles dans NSX-T, nous avons utilisé
le fournisseur NSX-T de Terraform pour définir les ressources de passerelle. Nous
avons écrit un script Terraform qui crée deux passerelles de niveau 1 , T1-LB-01
et T1-VPN-01, avec une adresse IP spécifique. Ce script a également été exécuté à
l’aide de notre pipeline CI/CD sur GitLab, ce qui a assuré une mise en place rapide
et fiable de notre passerelle. La figure 4.11 montre les différentes configurations pour
la création des T1 :

F IGURE 4.13 – Création T1 avec Terraform

48
 CHAPITRE 4. REALISATION ET VALIDATION DE LA MIGRATION

En revenons vers l’interface graphique de NSX-T , nous allons constaté la créa-

tion des ressources et configurations spécifiés dans le fichier Terraform précédent :

F IGURE 4.14 – Création des T1 au niveau NSX-T

−→ Création des segments :

Dans notre projet, nous avons automatisé la création et la gestion des réseaux
virtuels dans NSX-T à l’aide de Terraform. Nous avons écrit un script Terraform qui
crée deux segments de réseau appelé "App-LS" et "DB-LS". Ce script a été exécuté
à l’aide de notre pipeline d’intégration continue/déploiement continu (CI/CD) sur
GitLab, ce qui nous a permis de déployer rapidement et de manière fiable notre
réseau virtuel.

F IGURE 4.15 – Création des segements

49
 CHAPITRE 4. REALISATION ET VALIDATION DE LA MIGRATION

En revenons vers l’interface graphique de NSX-T , nous allons constaté la créa-

tion des ressources et configurations spécifiés dans le fichier Terraform précédent :

F IGURE 4.16 – création de segments au niveau NSX-T

[Link] VPN

La création des VPN, ou réseaux privés virtuels, dans notre infrastructure NSX-T,
est une étape clé pour sécuriser la communication entre différents sites ou applica-
tions. En utilisant un VPN, nous pouvons chiffrer le trafic réseau et le faire passer de
manière sécurisée sur des réseaux publics ou non sécurisés. Cela est particulièrement
utile pour connecter des réseaux distants ou pour permettre aux utilisateurs distants
d’accéder à notre réseau de manière sécurisée.

F IGURE 4.17 – Création de VPN

Après l’éxecution du script terraform , nous avons constaté la création du VPN

"VPN-01" :

50
 CHAPITRE 4. REALISATION ET VALIDATION DE LA MIGRATION

F IGURE 4.18 – Création du VPN au niveau NSX-T

[Link] Load Balancing

Le Load Balancer que nous avons créé dans notre infrastructure NSX-T joue un
rôle crucial pour assurer la distribution équilibrée du trafic réseau entre plusieurs
instances de serveurs. En répartissant la charge de travail, le Load Balancer aide à
optimiser l’utilisation des ressources, à maximiser le débit, à minimiser les temps de
réponse et à éviter la surcharge d’un seul serveur.
La figure ci dessous montre le fichier terraform pour la création du Load Balan-
cer :

F IGURE 4.19 – Création de Load Balancer

51
 CHAPITRE 4. REALISATION ET VALIDATION DE LA MIGRATION

Suite à l’exécution du script Terraform, nous avons observé la création réussie du

Load Balancer :

F IGURE 4.20 – Création d Load Balancer au niveau NSX-T

[Link] Sécurité

Nous avons également automatisé la configuration des pare-feux dans NSX-T à

l’aide de Terraform.
Création des security groups :

F IGURE 4.21 – Security groups

Après l’éxecution du cods , nous avons obtenu le résultat suivant sur l’interface
NSX-T :

52
 CHAPITRE 4. REALISATION ET VALIDATION DE LA MIGRATION

F IGURE 4.22 – Création des security groups

Affectation des membres au niveau NSX-T :

Nous allons maintenant affecter les membres à chaque security group :

F IGURE 4.23 – Set members

53
 CHAPITRE 4. REALISATION ET VALIDATION DE LA MIGRATION

création des policies et ajout de règles :

F IGURE 4.24 – Création des policies et règles

En revenant vers l’interface NSX-T nous avons le résultat suivant :

F IGURE 4.25 – création de la policy et l’ajout des règles

54
 CHAPITRE 4. REALISATION ET VALIDATION DE LA MIGRATION

IDS/IPS and malware Prevention :

Lorsque nous mettons en œuvre un système de détection et de prévention d’intru-
sion (IDS/IPS), nous renforçons la sécurité de notre réseau. Ces systèmes surveillent
notre trafic réseau en continu, détectant et bloquant les comportements et les activités
potentiellement malveillants. L’IDS nous alerte des menaces potentielles, tandis que
l’IPS intervient pour bloquer ces menaces avant qu’elles n’atteignent notre réseau.

F IGURE 4.26 – IDS/IPS and Malware prevention

Nous allons tester le detection des menaces en utilisant PUTTY :

F IGURE 4.27 – Détection d’intrusion

55
 CHAPITRE 4. REALISATION ET VALIDATION DE LA MIGRATION

Pour avoir une vue d’ensemble sur toute les menaces d’intrusion nous avons le
dashbord ci-dessous :

F IGURE 4.28 – Dashbord des résultats

4.4.5 Impact de l’Automatisation sur le Projet

L’automatisation de notre infrastructure à l’aide de Terraform et GitLab CI/CD

a eu un impact profondément positif sur notre projet. Elle a permis une mise en
œuvre plus rapide et plus cohérente de nos environnements, réduisant ainsi considé-
rablement le temps nécessaire pour déployer et modifier l’infrastructure. En outre,
l’automatisation a réduit les erreurs humaines en standardisant les processus et en
les rendant reproductibles. De plus, le pipeline CI/CD nous a permis d’intégrer des
étapes de validation et de tests, ce qui a amélioré la qualité de notre infrastructure et
réduit les risques. Enfin, cette automatisation a favorisé une meilleure collaboration
entre les équipes de développement et d’exploitation, facilitant la mise en œuvre de
pratiques DevOps et accélérant le cycle de vie du développement logiciel. Dans l’en-
semble, l’automatisation de notre infrastructure a augmenté notre efficacité, amélioré
notre fiabilité et accéléré notre capacité à livrer de la valeur.

56
 CHAPITRE 4. REALISATION ET VALIDATION DE LA MIGRATION

4.5 Execution de la migration

La migration d’une plateforme utilisant PfSense vers une plateforme basée sur
NSX-est planifiée pour les mois suivants, étant donné que le fournisseur de services
cloud OVH n’a pas encore rendu NSX-T opérationnel. Ce dernier serait activé vers
la fin de Juillet 2023.
Toutefois, il était judicieux d’éffectuer un setup fondamental dans un environne-
ment de test simulant les conditions normales et de profiter de cette attente pour bien
préparer cette transition.

4.6 Post-Migration

Exécuter la migration d’une plateforme basée sur pfSense vers une plateforme
NSX-T est une tâche complexe qui nécessite plusieurs activités de post-migration
pour que cette transition soit réussie ,nous citons :

-Activités de surveillance intensive ou Hypercare : Il faut mettre en place des ou-

tils de surveillance pour surveiller les performances de la nouvelle plateforme. Cela
inclut la surveillance de la bande passante, la latence, l’utilisation du CPU, la mé-
moire, etc.

-Suppression des anciennes configurations : Il faut supprimer toutes les anciennes

configurations qui ne sont plus nécessaires. Cela peut inclure les règles de pare-feu
obsolètes, les anciennes règles de routage, et les configurations VPN inutilisées.

-Décommissionnement des anciens services : Une fois que nous sommes sûr que
la nouvelle plateforme fonctionne correctement, il faudrait décommissionner les ser-
vices pfSense. Cela comprend la désactivation des anciennes gateways, et les anciens
VLANs.

-Test des connectivités : Il faut s’assurer que tous les appareils et les utilisateurs
finaux peuvent se connecter à la nouvelle plateforme. Cela comprend la vérification
des connexions VPN, la connectivité à Internet, et entre les différents segments du
réseau.

57
 CHAPITRE 4. REALISATION ET VALIDATION DE LA MIGRATION

4.7 Conclusion

Pour conclure ce quatrième chapitre, nous avons détaillé la mise en œuvre de

notre projet, allant de la conception des architectures à la préparation des actions de
pré-migration. L’automatisation de l’environnement de setup avec Terraform a été
un élément clé de ce processus, rendant notre projet plus efficace et reproductible.
Enfin, nous avons discuté des activités post-migration qui sont essentielles pour as-
surer la stabilité et l’optimisation de notre nouvel environnement. Chaque étape a
été cruciale pour garantir que notre projet atteint ses objectifs tout en minimisant les
interruptions potentielles. Dans l’ensemble, ce chapitre a illustré comment une pla-
nification et une exécution soigneuses peuvent conduire à une transformation réussie
de l’infrastructure.

58
Conclusion générale

Au terme de ce projet de migration des pfSense vers NSX-T, nous avons pu répondre
aux problématiques initiales liées à la décentralisation du Networking et du Firewal-
ling sur la plateforme VMware. En outre, nous avons pu pallier les limitations de
pfSense, notamment en termes de maintenance, et de gestion .
Ainsi, grâce à l’implémentation de NSX-T, nous avons réussi à concevoir une pla-
teforme plus évolutive, scalable, sécurisée et facilement configurable. De plus, grâce
à l’automatisation avec Terraform et GitLab, nous avons facilité la gestion centrali-
sée de l’environnement, rendant ainsi notre infrastructure plus efficace et adaptée à
l’accroissement de la clientèle de Deloitte.
Tout au long de ce projet, nous avons rencontré certains défis, notamment la non
disponibilité de NSX-T chez OVH jusqu’à fin juillet, ce qui a nécessité une adapta-
tion de notre part .
En termes d’apprentissages personnels, cette expérience a renforcé notre com-
préhension des réseaux complexes et a amélioré nos compétences en matière d’auto-
matisation et de gestion de projets de migration.
Cependant, malgré les réussites significatives, il existe toujours des domaines
d’amélioration et de développement. Nous recommandons des recherches futures
pour continuer à optimiser l’utilisation de NSX-T et pour étudier d’autres outils sus-
ceptibles d’améliorer encore davantage la scalabilité et la gestion de la plateforme.
Enfin, nous tenons à exprimer notre profonde gratitude envers tous ceux qui ont
contribué à la réussite de ce projet, nous offrant une précieuse opportunité d’appren-
tissage et de croissance professionnelle.

59
Références

1. Deloitte :[Link] consulté le 14-02-2023

2. Deloitte extended services / Digital factory/service et mission de la firme : HR
team
3. Avantages SDDC : [Link]
pdf/partners/emc/[Link]
4. technologie SDN : [Link]
[Link]
5. Avantages SDN :[Link]
[Link] consulté le 14-02-2023
6. SDN vs réseau classique : [Link]
[Link]
7. Composants du réseau SDN :[Link]
[Link] consulté le 14-02-2023
8. Commutation logique :[Link]
administration/[Link]
consulté le 14-02-2023
9. T0 GW :[Link]
[Link] consulté le 14-02-
2023
10. T1 GW :[Link]
[Link] consulté le 14-02-
2023
11. VRF :[Link]
[Link] consulté le 14-02-2023
12. Topologies : VMWARE NSX ®REFERENCE DESIGN GUIDE consulté le
14-02-2023
13. Load balancer :[Link]
administration/[Link]
consulté le 14-02-2023

60
 CHAPITRE 4. REALISATION ET VALIDATION DE LA MIGRATION

14. VPN :[Link]

[Link] consulté le 14-02-
2023
15. NSX-T architecture :[Link]
architecture-technical-overview consulté le 14-02-2023
16. Terrafom : [Link]
17. GitLab : [Link]
18. Figure 3.1 : [Link]
savoir-sur-le-cisco-killer/reseau-traditionnel-reseau-sdn/
19. Figure 3.2 [Link] etworking

61