Infrastructure théorique
1. Dimensionnement
Serveurs AP3 :
Nombre de cœurs : 32 à 64 cœurs par serveur, pour une puissance de
calcul adéquate aux applications AP3.
Fréquence : Fréquence de base de 3,0 GHz minimum pour optimiser les
performances.
Cache : Cache L3 de 40 Mo par processeur, idéal pour les traitements
haute performance.
Mémoire : 128 Go à 512 Go par serveur pour supporter les applications
lourdes d’AP3.
Stockage : Disques SSD NVMe de 2 To pour la rapidité d’accès aux
données ; ajout de disques HDD de grande capacité (6 à 12 To) pour la
volumétrie importante.
Technologies d’interconnexion : Fibre optique 10 à 40 Gbps pour les
serveurs AP3 de production, avec connexion Ethernet 10 Gbps pour le
reste des équipements.
Nombre de ports : 4 à 6 ports par serveur AP3 pour gérer les connexions
réseau, les liens de stockage, et la redondance réseau.
Stockage centralisé AP3 :
Type de support : SSD NVMe pour les données critiques, et HDD pour le
stockage d’archives ou les données moins fréquemment consultées.
Technologie de sauvegarde : RAID 10 pour les applications critiques de
l’AP3.
Capacité : Minimum 50 To pour le stockage principal, avec une
augmentation annuelle planifiée de 25 %.
2. Emplacement
Site A (Production AP3) :
Serveurs de production : Hébergement des applications principales
d’AP3.
Stockage principal : Site de stockage centralisé pour les données
critiques d’AP3, avec sauvegarde quotidienne.
Clustering : Clustering haute disponibilité pour les applications d’AP3 qui
nécessitent un accès en continu.
Site B (Backup & Reprise d’Activité AP3) :
Serveurs de backup : Réplication des données et services critiques d’AP3
pour une reprise rapide en cas de panne sur le site A.
Stockage de secours : Copies de sauvegarde des données, mises à jour
quotidiennement.
Cloud Public / Privé (extension pour AP3) :
Services scalables : Exécution des processus qui nécessitent une
flexibilité en termes de ressources (ex. calculs intensifs temporaires ou
environnement de test).
Sauvegarde complémentaire : Redondance des sauvegardes critiques
d’AP3 dans le cloud pour plus de sécurité.
3. Identifiant
Chaque ressource de l’AP3 sera identifiée selon une nomenclature qui simplifie la
gestion des ressources et permet un suivi rapide :
ID serveur : SERV_AP3A01 (serveur AP3 sur site A, unité 01)
ID stockage : STOR_AP3B01 (stockage AP3 sur site B)
ID cluster : CLUS_AP3_PROD (cluster AP3 de production)
4. Disponibilité
Clustering AP3 :
Clustering actif-actif pour les applications AP3 critiques, avec réplication de
données en temps réel pour minimiser les interruptions.
Clustering actif-passif pour les applications non critiques mais nécessitant
tout de même une redondance.
Sauvegardes AP3 :
Sauvegarde incrémentielle quotidienne sur le site A, complète
hebdomadaire sur le site B.
Sauvegardes redondées sur le cloud pour les données les plus sensibles
d’AP3.
Load-balancing AP3 :
Load-balancer applicatif : Répartition de charge pour les applications
web et API d’AP3.
Load-balancer réseau : Répartition au niveau des ports réseau via
agrégation de cartes réseau (NIC bonding) pour les serveurs AP3 sous
Windows et Linux.
5. Réseau
Interconnexion AP3 :
Connexion entre sites (VPN, MPLS) : Interconnexion des sites A et B
via un VPN chiffré ; MPLS dédié pour les données sensibles et les
communications à faible latence.
Connexions physiques/virtuelles : Utilisation de connexions RJ45
(Ethernet) pour les serveurs standards, et fibre optique pour les serveurs
critiques d’AP3.
Débit et latence AP3 :
Débit intra-site A : Connexions 10 à 40 Gbps pour les serveurs critiques
AP3 ; connexions 1 Gbps pour le trafic moins intense.
Débit inter-sites : Lien VPN de 1 à 2 Gbps avec latence inférieure à 10
ms, nécessaire pour les synchronisations de données.
Types de liens AP3 :
Intra-site : Fibre optique et ISCSI pour les connexions de stockage et de
calcul intensif.
Inter-sites : VPN dédié avec des dispositifs de redondance pour sécuriser
les communications AP3.
Redondance AP3 :
Load-balancing réseau : Load balancing sur les cartes réseau, avec
basculement automatique en cas de panne.
Switching redondant : Chaque serveur AP3 se connecte à deux switches
redondants pour éviter les points de défaillance uniques.
Alimentation redondante : Double alimentation pour chaque serveur
critique, en plus des unités UPS.
Infrastructure Réel
1. Dimensionnement
Machines Virtuelles :
CPU : Pour chaque VM, allouer entre 2 à 4 cœurs virtuels, en fonction des
capacités des ordinateurs physiques.
Mémoire : Allouer 4 à 8 Go de RAM pour chaque VM, en ajustant selon les
applications hébergées et la mémoire disponible sur les ordinateurs.
Stockage : Utilisation de l’espace de stockage local de chaque ordinateur,
avec des disques virtuels de 20 à 50 Go par VM.
Interconnexion : Les VMs seront interconnectées via le réseau local
(LAN), utilisant la carte réseau Ethernet des ordinateurs pour faciliter les
échanges.
Applications sur VMs :
Serveur de production (VM1 sur Mulhouse) : Hébergement des
applications critiques de l’infrastructure AP3.
Serveur de secours (VM2 sur Strasbourg) : Réplication des données
critiques pour la reprise d’activité en cas de panne de la VM principale.
Stockage virtuel : Chaque VM pourra disposer d’un disque virtuel dédié
pour simuler le stockage des données.
2. Emplacement
Site Mulhouse (Ordinateur 1) :
VM principale de production : L'ordinateur de Mulhouse hébergera la
VM principale, destinée aux services critiques.
Clustering simulé : Hébergement d’une deuxième VM secondaire sur cet
ordinateur pour simuler un cluster de basculement en cas de défaillance
de la première VM.
Site Strasbourg (Ordinateur 2) :
VM de secours : Une VM dédiée pour la reprise d’activité sera installée
sur cet ordinateur. Elle hébergera une réplication des services critiques et
permettra de tester des scénarios de failover.
3. Identifiant
Chaque VM aura un identifiant unique permettant de la lier aux services
hébergés :
VM principale : VM_AP3_Mulhouse_Prod (Mulhouse, VM de production).
VM secondaire : VM_AP3_Mulhouse_Sec (Mulhouse, VM de secours).
VM de réplication : VM_AP3_Strasbourg_Backup (Strasbourg, VM de
sauvegarde).
4. Disponibilité
Clustering simulé :
Les VMs sur Mulhouse (production et secours) pourront être configurées
pour simuler un cluster actif/passif, où la VM secondaire peut être activée
manuellement si la VM principale est indisponible.
Sauvegardes :
Sauvegarde incrémentielle : Création de snapshots réguliers de chaque
VM pour simuler des sauvegardes régulières.
Redondance : Les snapshots peuvent être transférés entre Mulhouse et
Strasbourg, assurant une copie de sauvegarde sur chaque ordinateur pour
renforcer la continuité.
Load-balancing simulé :
Chaque VM aura une adresse IP distincte, et un basculement manuel peut
être configuré pour diriger les utilisateurs vers la VM de secours en cas de
panne de la VM principale.
5. Réseau
Interconnexion :
Connexion entre Mulhouse et Strasbourg : Les deux ordinateurs sont
sur le même réseau local, simplifiant les connexions entre les VMs des
deux sites.
Connexion virtuelle : Utilisation de la carte réseau Ethernet des
ordinateurs pour les connexions entre les VMs.
Débit et latence :
Les VMs partagent le débit de la connexion réseau des ordinateurs, estimé
à 1 Gbps, ce qui est suffisant pour les échanges entre VMs.
Types de liens :
Connexions virtuelles en RJ45 (Ethernet) sur réseau local pour faciliter
l’intégration.
Redondance :
Redondance des connexions réseau : La connexion réseau locale de
chaque ordinateur sera utilisée pour les transferts de données ; si un
ordinateur devient inaccessible, la VM de secours de Strasbourg prend la
relève.
Switching virtuel : Les machines virtuelles seront connectées à un switch
virtuel pour garantir la communication intra-site entre les VMs.