VMware vSphere 5
Au sein du Datacenter La configuration
et la sécurisation de l’ESX
Jérôme BEZET-TORRES Eric MAILLÉ
René-François MENNECIER livre
vidéo
2 H de vidéo
VM war e vSpher e 5
Un livre de référence sur les fonctionnalités de VMware vSphere 5 et sur toutes les clefs pour l’intégrer de façon optimale au sein du Datacenter.
Eric MAILLÉ est Consultant avant-vente chez EMC2 (après des expériences réus- sies chez IBM, NEC Computers et HP). Il intervient en phase amont des projets d’infrastructure et conseille les entreprises sur les choix et les orientations techno- logiques. Il est certifié VMware VCP, EMC Cloud Architect et a été récompensé du titre de vExpert 2011 et 2012. Il est également co-fondateur du site www.virt-now.com.
René-François MENNECIER est Cloud Architect Senior Consultant chez EMC2 et s’occupe des projets stratégiques de transformation IT et de Cloud privé pour de grandes entreprises. Il est certifié VM- ware VCP, EMC Cloud Architect et a été récompensé du titre vExpert 2012.
Un approfondissement sous forme de vidéo* (2 H)
sur l’installation et la configuration de l’hyperviseur ESX et
sa sécurisation.
Jérôme BEZET-TORRES est Consul- tant Formateur sur les technologies Systèmes et Réseau dans différents environnements. Il a suivi de près les dernières évolutions de la solution de vir- tualisation de VMware, est reconnu VM- ware Certified Professional 5 et donne régulièrement des cours sur la version 5 de vSphere.
livre vidéo
DSI, administrateur, architecte, chef de projet, consultant, technicien..., tout informaticien en charge de projets de
virtualisation de serveurs.
publicAccessible via Internet quel que soit votre support et votre navigateur (PC, tablette…) grâce à un numéro d’activation personnel.
*
ISBN : 978-2-7460-8941-9
49,99 €
Flashez-moi pour en savoir plus et découvrir un
extrait gratuit
VMware vSphere 5
Préface
Avant-propos
Chapitre 1
La virtualisation des serveurs vers le Cloud
1. La virtualisation au cœur de la transformation IT . . . 11
1.1 Les nouveaux challenges. . . 11
1.2 La virtualisation des serveurs . . . 12
1.3 Les facteurs d'adoption de la virtualisation des serveurs . . . 13
1.3.1 Gaspillage des ressources. . . 13
1.3.2 La technologie au service de la virtualisation. . . 13
1.4 Les spécificités d'un environnement virtualisé . . . 14
1.4.1 Changement de modèle au sein du Datacenter . . . 14
1.4.2 Les machines virtuelles . . . 14
1.4.3 La mobilité . . . 15
1.4.4 Le provisioning instantané . . . 15
1.4.5 Regroupement des ressources au sein des clusters . . . 16
1.4.6 Qualité de service (QoS) . . . 16
1.5 Les bénéfices de la virtualisation . . . 16
2. Les différentes phases . . . 19
2.1 Phase 1 : rationalisation IT . . . 19
2.2 Phase 2 : applications critiques . . . 20
2.3 Phase 3 : automatisation . . . 23
2.3.1 Vers le Cloud Computing . . . 24
3. L'écosystème de la virtualisation . . . 25
3.1 Les différentes solutions. . . 25
3.1.1 Virtualisation des serveurs . . . 25
3.1.2 Virtualisation du poste de travail . . . 26
3.1.3 Gestion prévisionnelle et de performance . . . 26
3.1.4 Outils de conversion P2V . . . 27
3.1.5 Sauvegarde . . . 27
3.1.6 Les offres Cloud convergées . . . 27
3.1.7 Le stockage de données dans le Cloud . . . 28
2 VMware vSphere 5
au sein du Datacenter Chapitre 2Les composants logiciels de vSphere 5
1. VMware . . . 29
1.1 En bref . . . 29
1.2 Portfolio VMware . . . 29
2. Les évolutions de l’offre VMware . . . 31
3. Les licences vSphere 5 . . . 35
3.1 Les différentes éditions . . . 35
3.2 Mode de licensing . . . 38
3.3 Les licences vCenter Server 5.0. . . 39
4. Les nouveautés de vSphere 5. . . 40
5. Les fonctionnalités existantes . . . 42
6. Les logiciels vendus séparément . . . 44
7. L'architecture technique de vSphere 5 . . . 47
7.1 vCenter Server 5 . . . 49
7.1.1 Architecture . . . 49
7.1.2 vCenter Server Database . . . 51
7.1.3 vCenter Linked Mode . . . 51
7.1.4 vCenter Server Heartbeat . . . 52
7.1.5 vSphere Update Manager (VUM). . . 52
7.1.6 Plug-in vCenter Server . . . 53
7.1.7 vCenter Server Appliance vCSA . . . 54
7.2 L'hyperviseur ESXi5 . . . 55
7.2.1 Les composants d'ESXi5 . . . 55
7.2.2 La couche de virtualisation . . . 55
7.2.3 Les machines virtuelles . . . 56
7.2.4 VMware Tools . . . 60
8. Sécurité . . . 60
8.1 VMware vShield Manager . . . 60
8.2 Les composants à surveiller . . . 61
8.2.1 Sécurité de la couche de virtualisation . . . 61
8.2.2 Sécurité des machines virtuelles . . . 61
8.2.3 Sécurité du réseau . . . 61
Chapitre 3
Le stockage sous vSphere 5
1. Introduction. . . 63
2. Représentation du stockage . . . 63
3. Les architectures de stockage disponible . . . 64
3.1 Les différents protocoles. . . 64
3.2 Le stockage local . . . 66
3.3 Le stockage centralisé . . . 66
4. Les réseaux de stockage . . . 68
4.1 Le réseau de stockage IP . . . 68
4.1.1 iSCSI sous VMware. . . 69
4.1.2 NFS sous VMware. . . 70
4.2 Le réseau Fibre Channel . . . 71
4.2.1 SAN FC. . . 71
4.2.2 Le protocole Fibre Channel . . . 74
4.2.3 NPIV . . . 74
4.2.4 WWN . . . 74
4.2.5 Buffer Credits. . . 75
4.2.6 Directeurs ou switchs ?. . . 75
4.2.7 Le câblage . . . 76
4.2.8 DWDM et CWDM . . . 76
4.2.9 LUN Masking et Zoning . . . 77
4.2.10 SAN FC sous VMware . . . 77
4.2.11 SAN FCoE sous VMware . . . 78
4.3 Synthèse . . . 79
5. Système de fichiers supportés. . . 79
5.1 VMFS. . . 79
5.1.1 Qu'est-ce que VMFS ?. . . 79
5.1.2 Les spécificités de VMFS5 . . . 80
5.1.3 Upgrade de VMFS3 vers VMFS5 . . . 81
5.1.4 La signature des datastores . . . 81
5.1.5 Pour aller plus loin dans la technique. . . 83
5.1.6 Rescan datastore . . . 84
5.1.7 Alignement. . . 84
5.1.8 Augmentation de volumétrie . . . 85
5.1.9 Peut-on créer un seul gros volume de 64 To?. . . 86
5.1.10 Bonnes pratiques VMFS . . . 86
5.2 NFS . . . 87
4 VMware vSphere 5
au sein du Datacenter6. Le disque virtuel . . . 87
6.1 Le disque vmdk . . . 87
6.2 Les différents types de disques . . . 88
6.2.1 Thick Disk . . . 88
6.2.2 Thin Disk . . . 89
6.2.3 Les différents modes . . . 90
6.3 Raw Device Mapping . . . 91
6.3.1 Les disques en RDMv. . . 91
6.3.2 Les disques en RDMp . . . 92
6.4 Le format OVF . . . 92
7. Le datastore . . . 93
8. Storage vMotion . . . 94
8.1 Dans quel cas utiliser Storage vMotion ? . . . 95
8.2 Comment fonctionne Storage vMotion ?. . . 95
9. Storage DRS (SDRS) . . . 96
9.1 Placement initial . . . 96
9.2 Équilibrage de charge . . . 97
9.3 Comment SDRS détecte-t-il les charges I/O des datastores ?. . . 98
9.4 Les règles d'affinité . . . 98
9.5 Profile Driven Storage. . . 99
10. Storage I/O Control (SIOC) . . . 99
11. vSphere Storage Appliance . . . 101
12. Les API VMware pour le stockage . . . 103
12.1 vStorage API for Array Integration (VAAI). . . 103
12.2 vSphere Storage APIs Storage Awareness . . . 105
13. Multipathing . . . 105
13.1 Pluggable Storage Architecture . . . 105
13.2 Les différents modes . . . 106
14. Considération sur les technologies disques . . . 107
14.1 Type de disques supportés . . . 107
14.2 Le RAID . . . 109
14.3 LUN . . . 109
14.4 Les pools de stockage . . . 109
14.5 Le tiering disque automatique . . . 110
14.6 Performances . . . 110
14.7 Quelques recommandations. . . 110
15. Les pilotes de périphérique . . . 111
Chapitre 4
Les serveurs et les réseaux
1. Les serveurs ESXi . . . 113
1.1 Gestion de la mémoire . . . 113
1.1.1 Memory Overcommitment . . . 113
1.1.2 Transparent Page Sharing . . . 114
1.1.3 Ballooning . . . 114
1.1.4 Swap . . . 117
1.1.5 Compression de mémoire . . . 118
1.1.6 Dimensionnement. . . 118
1.1.7 Bonnes pratiques . . . 119
1.2 Le processeur . . . 119
1.2.1 Terminologie . . . 119
1.2.2 La gestion du processeur par ESX . . . 121
1.2.3 Le multicœur et la virtualisation . . . 121
1.2.4 vSMP et le vCPU . . . 122
1.2.5 L'Hyper-Threading. . . 122
1.2.6 Les techniques de virtualisation . . . 123
1.2.7 Les indicateurs CPU. . . 126
1.2.8 Bonnes pratiques . . . 128
1.3 Déplacement de VM avec vMotion. . . 129
1.3.1 Comment fonctionne vMotion ?. . . 129
1.3.2 Dans quels cas utiliser vMotion ?. . . 131
1.3.3 Pré-requis et bonnes pratiques . . . 131
1.3.4 EVC (Enhanced vMotion Compatibility) . . . 132
1.4 vSphere DRS (Distributed Resource Scheduler). . . 133
1.4.1 L'automatisation de DRS . . . 133
1.4.2 Les règles DRS (DRS Rules) . . . 135
1.5 vSphere DPM . . . 137
2. Le réseau . . . 138
2.1 Introduction . . . 138
2.2 vSphere Standard Switch (vSS) . . . 139
2.2.1 Communication des VM avec les éléments du réseau . . . 141
2.2.2 Configuration. . . 143
2.3 vSphere Distributed Switch (vDS) . . . 150
2.3.1 Architecture vDS . . . 152
2.3.2 Network IO Control (NIOC) . . . 153
6 VMware vSphere 5
au sein du Datacenter2.4 Cisco NEXUS 1000v . . . 153
2.4.1 Qu'est-ce que le Nexus 1000v ?. . . 153
2.4.2 Architecture . . . 154
2.5 Les cartes réseau virtuelles . . . 155
2.6 Dimensionnement et bonnes pratiques. . . 155
3. Les applicatifs en environnement virtualisé. . . 156
3.1 Les bases de données Oracle, SQL . . . 156
3.1.1 Les bases Oracle sont-elles supportées sous vSphere 5 ?. . . 157
3.1.2 Le licensing d'Oracle sous VMware . . . 157
3.2 Exchange . . . 158
3.3 SAP. . . 158
3.4 Active Directory . . . 159
Chapitre 5
La continuité de service locale et distante
1. Quelques généralités . . . 1611.1 RTO/RPO . . . 161
1.2 La disponibilité de l'information . . . 162
1.3 Protection de l'infrastructure . . . 164
2. La disponibilité locale . . . 165
2.1 Suppression de SPOF (Single Point of Failure) . . . 165
2.2 Haute disponibilité . . . 166
2.3 Qu'est-ce qu’un cluster ? . . . 167
2.4 vSphere HA . . . 167
2.4.1 Les composants de vSphere HA . . . 168
2.4.2 Le maître et les esclaves . . . 168
2.4.3 Heartbeat . . . 169
2.4.4 Les différents états d'un hôte ESXi . . . 171
2.4.5 Restart Priority. . . 173
2.4.6 VM Monitoring et Application Monitoring . . . 174
2.4.7 vSphere HA remplace-t-il les services de clustering Microsoft ?. . . 175
2.4.8 Déterminer le nombre d'hôtes qui peuvent tomber en panne dans un cluster HA ?. . . 176
2.4.9 Admission Control. . . 178
2.4.10 Bonnes pratiques . . . 179
2.5 vSphere FT. . . 179
2.5.1 Qu'appelle-t-on la tolérance de panne ? . . . 179
2.5.2 Comment cela fonctionne-t-il ? . . . 180
2.5.3 Ce qu'il faut savoir sur FT. . . 180
3. Continuité d'activité . . . 182
3.1 Qu'appelle-t-on PRA, PCA, PSI ?. . . 182
3.2 Les causes de Failover . . . 182
3.3 Problématiques des PRA pour les environnements physiques. . . 183
3.4 vSphere 5 est un levier pour le PRA. . . 183
3.5 Réplication . . . 184
3.5.1 Les différentes solutions de réplication . . . 184
3.5.2 Différence entre réplication synchrone et asynchrone . . . 185
3.6 Site Recovery Manager 5 . . . 187
3.6.1 Qu'est-ce que SRM5 ? . . . 187
3.6.2 Architecture . . . 188
3.6.3 Les différents modes . . . 189
3.6.4 SRA. . . 189
3.6.5 Failover . . . 190
3.6.6 Priorité de démarrage des VM. . . 191
3.6.7 Migration planifiée . . . 192
3.6.8 Test. . . 192
3.6.9 vSphere Replication. . . 192
3.6.10 Failback. . . 194
3.6.11 Interface SRM5 . . . 195
3.7 Cluster étendu. . . 195
3.7.1 Architecture . . . 195
3.7.2 vMotion Longue distance . . . 197
3.7.3 vSphere HA dans un Cluster étendu . . . 198
Chapitre 6
La sauvegarde sous vSphere 5
1. Généralités . . . 1991.1 Qu'est-ce qu’une sauvegarde ?. . . 199
1.2 Objectifs des sauvegardes. . . 199
1.3 Impact Business . . . 200
1.4 La méthode traditionnelle de sauvegarde . . . 200
1.5 Les problématiques de sauvegarde en environnement virtuel . . . 201
1.5.1 Risques de contentions . . . 201
1.5.2 Criticité des fichiers. . . 201
1.5.3 Volumétrie importante . . . 201
8 VMware vSphere 5
au sein du Datacenter1.5.4 Meilleurs niveaux de service exigés. . . 202
2. Les méthodes de sauvegarde en environnement virtuel . . . 202
2.1 Bref historique sur VCB . . . 202
2.2 Les méthodes sous vSphere 5 . . . 202
2.2.1 L’API VADP . . . 203
2.3 Sauvegardes avec agents . . . 204
3. Les snapshots . . . 205
3.1 Différence entre snapshot baie de stockage et snapshot VMware. . . 205
3.2 Snapshots de VM . . . 205
3.2.1 À quoi sert un snapshot ? . . . 205
3.2.2 Comment cela fonctionne-t-il ? . . . 205
3.2.3 Précautions à prendre avec les snapshots . . . 206
4. La consistance applicative . . . 207
4.1 Quelles sont les méthodes pour garantir une consistance applicative ?. . . 208
4.1.1 Volume Shadow Copy Service . . . 208
4.1.2 Les scripts pre-freeze et post-thaw . . . 210
5. Les leviers pour traiter les problématiques en environnement virtuel . . . . 211
5.1 Changed Block Tracking. . . 211
5.2 La déduplication . . . 213
5.3 LAN free. . . 214
6. Processus de sauvegarde au travers des API VADP . . . 214
7. Data Recovery 2.0 . . . 215
Chapitre 7
Installation et gestion
1. Dimensionnement . . . 2172. Les différents modes d'installation . . . 218
3. Pré-installation . . . 219
3.1 Check-list. . . 219
3.2 Pré-requis . . . 219
3.2.1 Serveur ESXi5 . . . 219
3.2.2 vCenter Server 5. . . 220
3.2.3 vCenter Server Appliance vCSA . . . 221
3.2.4 vSphere Client . . . 222
3.3 Choix du matériel . . . 222
4. Préparation du serveur . . . 223
5. Installation. . . 224
5.1 Serveur ESXi5 . . . 224
5.1.1 Installation interactive . . . 224
5.1.2 Installation avec Auto Deploy . . . 225
5.2 Installation vCenter Server 5 . . . 228
6. Mise à jour vers vSphere 5 . . . 229
6.1 Mise à jour vers vCenter Server 5 . . . 230
6.2 Mise à jour de vSphere Update Manager (VUM). . . 231
6.3 Mise à jour vers ESXi5 . . . 231
6.4 Mise à jour des VM. . . 233
7. Les différentes méthodes pour se connecter . . . 234
7.1 DCUI . . . 235
7.2 vSphere Client. . . 236
7.3 vSphere Web Client . . . 236
7.4 Les outils de Scripting. . . 237
8. Configuration de vCenter Server . . . 238
8.1 Vue générale . . . 238
8.2 Licences . . . 239
8.3 Les paramètres généraux . . . 240
8.4 Hosts et clusters . . . 241
8.5 Création du Datacenter . . . 241
8.6 Gestion des permissions . . . 242
8.7 Réseau et stockage . . . 243
8.8 P2V. . . 243
8.8.1 Quelles sont les modifications après un P2V? . . . 244
8.8.2 Les bonnes pratiques . . . 245
8.8.3 Après la conversion . . . 245
9. Gestion efficace de l'environnement virtuel . . . 246
9.1 Supervision . . . 246
9.1.1 Supervision du serveur hôte . . . 246
9.2 Les alarmes et maps . . . 247
9.3 Partage de ressources . . . 248
9.3.1 VM . . . 249
9.3.2 Resource Pool . . . 253
9.4 Taux de consolidation . . . 254
9.5 Performance dans vCenter Server . . . 255
10 VMware vSphere 5
au sein du Datacenter9.6 Clone et Template . . . 258
9.6.1 Clone. . . 258
9.6.2 Template. . . 258
9.7 Les bonnes pratiques. . . 259
9.8 vApp. . . 260
Chapitre 8
Gestion d’un projet de virtualisation
1. Introduction . . . 2612. Contexte. . . 261
2.1 Objectif . . . 262
2.2 Critère de choix de la solution . . . 262
3. Les phases du projet. . . 263
4. La planification . . . 264
4.1 Découverte. . . 264
4.1.1 Les systèmes d'exploitation . . . 268
4.1.2 La collecte CPU . . . 269
4.1.3 La collecte mémoire . . . 270
4.1.4 La capacité disque . . . 271
4.1.5 Réseau . . . 273
4.1.6 Les applicatifs . . . 273
4.2 Analyse . . . 274
4.2.1 Critères d'exclusion . . . 274
5. La conception . . . 276
5.1 Architecture cible . . . 276
5.2 Dimensionnement . . . 277
6. L’implémentation . . . 279
6.1 Installation de la plateforme vSphere 5 . . . 280
6.2 Migration P2V. . . 280
6.3 Implémentation de SRM5 . . . 281
6.3.1 Les groupes de consistance . . . 281
6.3.2 Mapping de la hiérarchie des ressources. . . 282
7. La gestion . . . 283
8. Synthèse et bilan . . . 283
Glossaire . . . 287
Index . . . 291
© Editions ENI - All rights reserved
Exemples
Pour un RPO de 24 heures, une sauvegarde journalière est la technique généralement utilisée. Pour un RPO de quelques heures, les techniques employées sont les snapshots ou la réplication asynchrone. Un RPO de 0 implique la mise en place d’un mode de réplication synchrone et corres- pond à une demande 'aucune perte de données'.
– Le RTO (Recovery Time Objective) correspond à la durée maximale d'interrup- tion admissible. Le temps de redémarrage des applicatifs et leur mise en ser- vice détermine le RTO.
Exemples
Pour un RTO de 48 heures, il est possible d'utiliser des bandes situées sur un site distant protégé. Pour un RTO de 24 heures, la restauration à partir de bandes sur un site local peut être utilisée. Pour un RTO de 4 heures ou moins plusieurs techniques complémentaires doivent être mises en place : Clustering, réplication, techniques propres à VMware HA, FT, SRM, virtualisation du stockage...
La virtualisation simplifie certains process permettant d'atteindre des RTO ré- duits. Le RTO est fonction des techniques mises en place et dépend fortement du redémarrage des applications et de leur consistance applicative lorsque des arrêts brutaux surviennent sur le site de production. Si celle-ci n'est pas ga- rantie, le RTO est variable et est difficilement prévisible.
Bien évidemment, toute entreprise souhaiterait pouvoir disposer de solutions
permettant de ne perdre aucune donnée avec une remise en production la plus
rapide possible en cas de problème. Mais il n'y a pas de secret, plus les temps
de RPO et RTO sont faibles et plus la mise en place de telles solutions est coû-
teuse. Il est donc fondamental d'engager les responsables et dirigeants
afin de déterminer avec eux, les RTO et RPO qu'ils souhaitent en fonc-
tion des contraintes métiers et business. On parle également de BIA
(Business Impact Analysis) qui permet de quantifier la valeur réelle d'une don-
née pour l'entreprise. Il n'est pas rare d'avoir trop d'investissement sur la pro-
tection des mauvaises données (importantes pour l'administrateur mais pas
forcément pour l'entreprise) et pas assez sur les bonnes. Une décision collé-
giale est à privilégier pour valider ensemble les risques encourus en fonction
des solutions choisies.
213
La continuité de service locale et distante
Chapitre 5
Le SLA (Service Level Agreement) est un contrat spécifiant des niveaux de ser- vices. Il s’agit d’un engagement formel et contraignant, établi entre un presta- taire et son client. Les notions de RTO et RPO sont importantes lorsque ce contrat s'établit.
1.2 La disponibilité de l'information
Remarque
Statistiques : 93 % des entreprises ayant perdu leur Datacenter pendant dix jours ou plus à la suite d’une panne majeure ont fait faillite dans l’année sui- vante (NARA : National Archives and Records Administration).
Le système d'information est essentiel pour une entreprise. Celui-ci per- met aux utilisateurs d'être productifs et de disposer de moyens de communi- cation efficaces tels que l'usage d'une messagerie, d'outils collaboratifs, réseaux sociaux… Pour l'entreprise le système d'information fournit les appli- cations métiers pour accompagner le Business. Une indisponibilité même par- tielle de tel ou tel service peut faire perdre beaucoup d'argent à une entreprise.
Il est donc crucial de mettre en place des dispositifs qui réduisent les interrup- tions de service et de pouvoir remettre le système en fonctionnement en cas d'incidents majeurs survenant sur le site de production.
Causes de l’indisponibilité de l’information généralement constatées.
© Editions ENI - All rights reserved
Comme on peut le constater sur ce graphique, la plus grande part du temps d'indisponibilité (79 % du temps) vient de maintenances planifiées pour des opérations de sauvegarde, rajout de matériel, migration, extraction de don- nées (Datawarehouse) qui sont donc prévisibles mais qui peuvent provoquer malgré tout des indisponibilités de service. Les autres types d'indisponibilité concernent des événements imprévisibles qui ne peuvent être anticipés dont les conséquences peuvent être dramatiques si des mesures et procédures fiables ne sont pas mises en place.
La disponibilité de l'information est établie selon le calcul suivant : IA = MTBF / (MTBF + MTTR)
IA (Information Availability) : disponibilité de l’information.
MTBF (Mean Time Between Failure) : temps moyen pour un système ou un composant avant de tomber en panne.
MTTR (Mean Time To Repair) : temps moyen pour réparer un composant HS.
MTTR inclut le temps passé à détecter le composant HS, planifier l'interven- tion d'un technicien, diagnostiquer le composant, obtenir le composant de remplacement (Spare) puis réparer et remettre en production le système.
La disponibilité de l'information se mesure en pourcentage, en nombre de 9 et permet de répondre aux besoins métiers pour une durée déterminée. Plus le nombre de 9 est élevé et plus la disponibilité est haute. On parle généralement de Haute Disponibilité à partir de 99,999 %.
Voici un tableau de correspondance entre la disponibilité (en nombre de 9) et le temps d'indisponibilité que cela représente.
Pourcentage de disponibilité Temps d'indisponibilité
98 % 7,3 jours
99 % 3,65 jours
99,80 % 17 hrs 31 min
99,90 % 8 hrs 45 min
99,99 % 52,5 min
99,999 % 5,25 min
99,9999 % 31,5 sec
215
La continuité de service locale et distante
Chapitre 5
Remarque
Un système ayant une disponibilité de 99,999 représente 5,25 minutes maxi- mum d'arrêt par an. À noter que cette durée est très courte puisqu'elle repré- sente moins que le temps de reboot d'un serveur physique !
1.3 Protection de l'infrastructure
La protection du système d'information peut être classée en deux catégories : la disponibilité locale sur un site et la continuité d'activité lorsqu'un inci- dent majeur survient sur le site de production.
– La disponibilité locale a pour objet de supprimer les interruptions de ser- vice lorsqu'un composant tombe en panne, grâce à :
– La mise en place de redondance matérielle pour éliminer les SPOF (Single
Point of Failure).– La mise en place de systèmes de clustering pour remettre rapidement en
production des applications en cas de crash de serveurs.
© Editions ENI - All rights reserved
– La sécurisation des données au travers de sauvegarde pour faire face à la perte de données ou à des mécanismes de réplication pour faire face à la perte d'une baie de stockage.
– La mise en place de snapshots pour un retour arrière rapide vers un état sain lorsqu'un applicatif est corrompu.
– La continuité d'activité a pour objet de remettre en fonctionnement rapi- dement un site de production lorsqu'un événement majeur survient. Les notions de PRA (Plan de Reprise d’Activité), PCA (Plan de Continuité d’Activité) ou PSI (Plan de Secours Informatique) sur un site de secours per- mettent de faire face à ces événements survenant au niveau du Datacenter de production.
La sauvegarde faisant partie intégrante de la protection et étant un sujet important à traiter, un chapitre lui est consacré.
2. La disponibilité locale
2.1 Suppression de SPOF (Single Point of Failure)
La virtualisation de l'infrastructure engendre une consolidation sur un
nombre réduit d'équipements. Ces équipements hébergeant un nombre
important de VM, ils deviennent donc hautement critiques. Un arrêt d'un
seul de ces équipements peut engendrer une interruption de plusieurs VM
dont les conséquences pour le système d'information peuvent être drama-
tiques. Un SPOF représente un composant qui peut rendre indisponible le
système d'information s'il tombe en panne. Plusieurs techniques permettent
de se prémunir contre cette éventualité en mettant en place de la redondance
matérielle. En environnement virtualisé, les bonnes pratiques préconisent de
redonder tous les éléments matériels afin de réduire les interruptions de ser-
vice.
217
La continuité de service locale et distante
Chapitre 5
Techniques permettant de supprimer les SPOF.