QUI SUIS-JE ?
Je m’appelle Alexis AMEYE, actuellement en deuxième année de BTS Services Informatiques aux Organisations (SIO), spécialité Solutions d’Infrastructure, Systèmes et Réseaux (SISR).
Ma formation est dispensée par le CFA UIMM Fab’academy, sous la supervision de mon formateur référent, Monsieur Antonin Bollin. Ce cursus m’apporte une base technique solide en administration système, gestion de réseaux et sécurisation des infrastructures numériques.
Parallèlement à mes études, j’évolue au sein de l’entreprise 85 Micro Informatique. Cette immersion me permet de mettre en pratique mes compétences théoriques à travers des missions concrètes :
Maintenance préventive et curative des parcs informatiques.
Support technique et accompagnement des utilisateurs.
Mise en œuvre de solutions de sauvegarde et de protection des données.
Configuration et sécurisation des équipements réseaux.
Passionné par la protection des systèmes d’information, mon objectif après l’obtention de mon BTS est d’intégrer une Licence Professionnelle spécialisée en Cybersécurité.
Mon expérience chez 85 Micro Informatique m’a fait prendre conscience de l’importance vitale de la sécurité informatique pour les organisations. Je souhaite donc approfondir mes connaissances en audit de sécurité, gestion des vulnérabilités et réponse aux incidents, afin de devenir un expert capable de garantir l’intégrité et la confidentialité des infrastructures critiques.
Présentation de l’entreprise
85 Micro Informatique s’impose comme un acteur de référence dans le paysage technologique vendéen, alliant expertise technique et service de proximité depuis sa création en 2009. Cette SARL, implantée à La Roche-sur-Yon, a su pérenniser son activité en développant un modèle économique polyvalent qui répond aux besoins critiques des particuliers comme des petites entreprises (TPE/PME). Son cœur de métier ne se limite pas à la simple distribution de matériel informatique ; l’entreprise se distingue par une offre de services à haute valeur ajoutée incluant l’audit d’infrastructures, la maintenance curative complexe et l’administration système. Dans un contexte de transformation numérique croissante, 85 Micro Informatique place la sécurité des données et la pérennité des équipements au centre de sa stratégie, notamment à travers des solutions de sauvegarde robustes et une démarche engagée en faveur du réemploi de matériel. Cette approche éco-responsable, couplée à une veille technologique constante, permet à la structure d’offrir des solutions réseau et système optimisées, garantissant ainsi à sa clientèle une infrastructure fiable, sécurisée et durable face aux enjeux informatiques actuels.
- Dénomination : 85 MICRO
- Création : 01/07/2009
- Adresse (Siège) : 3 passages du puy charpentreau, 85000 La Roche-sur-Yon
- Dirigeant (Gérant) : Monsieur François RODRIGUEZ
- SIREN : 513 230 698
- SIRET : 513 230 698 00013
- N° de TVA Intracommunautaire : FR48513230698
- Activité (Code NAF/APE) : 47.41Z – Commerce de détail d’ordinateurs, d’unités périphériques et de logiciels en magasin spécialisé
- Forme juridique : SARL (Société à Responsabilité Limitée)
- Capital social : 4 000 €
- Chiffre d’affaires : Donnée non publiée
- Nombre de société : 1 (Société unique)
- Nombre de salariés : 5 salariés
CFA
Présentation de la structure : L’UIMM Fab Academy de La Roche-sur-Yon est un centre de formation de pointe dédié aux métiers de l’industrie du futur. Véritable « Smart Factory », cet établissement accompagne la transformation digitale des entreprises à travers des plateaux techniques de haute technologie (Robotique, Cybersécurité, Maintenance connectée).
Mon rôle au sein de l’établissement : En tant qu’Apprenti Technicien Systèmes et Réseaux, j’évolue au cœur de cette infrastructure pour assurer la continuité de service et l’évolution des outils numériques utilisés par les formateurs et les apprenants.
Activités concrètes et environnement technique :
- Administration réseau : Gestion des accès et maintenance de l’infrastructure locale.
- Support utilisateur (Helpdesk) : Diagnostic et résolution d’incidents matériels et logiciels sur un parc informatique varié.
- Déploiement de solutions : Préparation et configuration de postes de travail et d’équipements connectés.
- Environnement : Windows Server, Active Directory, Environnements virtualisés.
Activité en formation et milieu professionnel baser sur Proxmox VE
Configuration réseau
Interfaces réseau
Afin de configurer finement le réseau, j’ai édité manuellement le fichier /etc/network/interfaces sur chaque nœud du cluster. J’ai notamment configuré les ponts virtuels (bridges) : le vmbr0 pour l’accès au réseau externe via l’interface eno1, et le vmbr1 sur un segment réseau distinct (10.0.0.10) utilisant l’interface eno2. Cette manipulation permet de séparer les flux de management et les flux de données des futures machines virtuelles.
Redémarrage du réseau
Configuration du stockage
Stockage local (ext4)
Utiliser par default lors de l’installation
Idéale pour les environnements de test
Limitation : pas de migration live sans stockage partager
Stockage partager NFS (Recommandé)
Afin de centraliser mes ressources, j’ai procédé à l’ajout d’un partage de fichiers réseau (NFS) dans l’interface de Proxmox. Pour cela, je me suis rendu dans la section « Storage » du Datacenter pour y déclarer mon serveur distant.
J’ai renseigné son adresse IP, spécifié le chemin d’exportation des dossiers et défini le type de données que ce stockage devait accueillir, comme les images ISO et les sauvegardes de machines virtuelles.
Étapes de création du cluster
| 01 | 02 | 03 |
| Crée le cluster sur le premier noeud | Ajouter les nœuds supplémentaire | Vérifier le cluster |
| Accéder à data center > Cluster Cliquer sur “create cluster” Entrer le nom du cluster (ex : uimm-cluster) Cliquer sur create Copier le token d’invitation générer | Accéder à data center > Cluster Cliquer sur “join cluster Entrer l’adresse ip du premier nœud Entrer le token d’invitation Cliquer sur “join” Attendre la synchronisation (1 à 2 minutes) | Vérifier la connectivité avec : pvecm status |
Pour fédérer mon infrastructure, je me suis rendu dans l’onglet Cluster du menu Datacenter de mon premier nœud (pmox-host1). J’ai ensuite cliqué sur le bouton « Create Cluster » afin d’initialiser la configuration qui permettra par la suite de regrouper mes différents serveurs au sein d’une interface de gestion unique
Lors de la phase de création, j’ai nommé mon cluster « proxmox-lab ». Pour assurer une communication stable entre les nœuds, j’ai configuré le premier lien réseau (Link 0) sur l’adresse 192.168.0.30. J’ai veillé à ce que ce lien soit défini comme le lien par défaut (Default link), lui conférant la priorité la plus élevée pour les échanges d’informations internes au cluster.
J’ai validé la création du cluster et suivi le déroulement de la tâche dans la fenêtre « Task viewer ». Comme le montre la capture du haut, j’ai vérifié que le statut était passé à « TASK OK », confirmant ainsi la génération réussie des clés de sécurité (authkey) et de la configuration Corosync.
Une fois l’opération terminée, je me suis rendu dans l’interface de gestion (capture du bas) pour cliquer sur le bouton « Join Information », afin de récupérer le jeton nécessaire à la jointure des autres serveurs au cluster « proxmox-lab ».
Une fois le cluster initialisé sur le premier nœud, j’ai cliqué sur le bouton « Join Information » pour afficher les paramètres de connexion sécurisée.
J’ai alors utilisé la fonction « Copy Information » pour récupérer le jeton (Join Token) ainsi que l’empreinte numérique (Fingerprint) du serveur.
Ensuite, je me suis connecté sur l’interface d’administration de mon second nœud (pmox-host2) et j’ai sélectionné l’option « Join Cluster » afin d’y coller ces informations et finaliser l’intégration du serveur au cluster.
J’ai finalisé la création de l’infrastructure en intégrant le second nœud. Pour ce faire, j’ai collé le jeton d’invitation récupéré précédemment dans le champ « Information » et j’ai renseigné le mot de passe « root » du premier serveur pour valider l’authentification.
Une fois la jointure effectuée, j’ai pu confirmer la réussite de l’opération via l’interface du Datacenter : les deux nœuds, pmox-host1 et pmox-host2, apparaissent désormais avec un statut actif, formant un cluster fonctionnel à deux membres prêts à héberger mes machines virtuelles.
Types de migration
Migration (live sans arrêt)
Déplacer une VM en cours d’exécution vers un autre nœud sans interruption
Prérequis :
Stockage partagé (NFS, Ceph, SAN)
Réseau haute performance
Ressource disponible sur le nœud source
Procédure :
Une fois le cluster opérationnel, j’ai testé la haute disponibilité en procédant à la migration à chaud d’une machine virtuelle. Depuis l’interface de gestion, j’ai sélectionné la VM concernée, puis j’ai utilisé la fonction « Migrate ». J’ai ensuite désigné le nœud cible au sein du cluster pour déplacer la machine. Cette opération m’a permis de vérifier que les services pouvaient être basculés d’un hôte à l’autre sans interruption de service pour l’utilisateur.
Pour finaliser la migration, j’ai sélectionné le nœud SupportTesting01 comme destination dans le menu déroulant. Comme le montre l’encadré rouge, j’ai impérativement coché le mode « Online » : cette manipulation est essentielle car elle permet une migration « à chaud », déplaçant l’état de la mémoire vive en temps réel pour que la VM ne s’arrête jamais durant le transfert entre les deux serveurs.
Migration hors ligne (Cold migration)
Avantages :
Fonctionne avec stockage local plus rapide que la migration live moins de ressources utilisées
Procédure :
Pour tester un second scénario de maintenance, j’ai réalisé une migration à froid (Offline). J’ai d’abord procédé à l’arrêt complet de la machine virtuelle (VM 302) comme le montrent les indicateurs de statut « stopped » sur la capture.
Une fois la VM éteinte, j’ai lancé la procédure de migration vers le nœud SupportTesting01. Contrairement à la migration « Online », ce mode est utilisé lorsque la continuité de service immédiate n’est pas requise ou pour garantir une intégrité absolue des données lors de changements structurels importants.
Une fois la machine éteinte, j’ai configuré la migration vers le nœud SupportTesting01. Comme la VM est hors-tension, le mode passe automatiquement en « Offline », ce qui simplifie le transfert puisque seul le disque virtuel doit être géré.
Après avoir cliqué sur « Migrate« , j’ai suivi l’avancement dans le « Task viewer ». Comme on le voit sur la capture, l’opération a été extrêmement rapide (durée : 02 secondes) et s’est conclue par un « TASK OK », confirmant le déplacement réussi de la VM entre les hôtes.
Configuration de la haute disponibilité
Concept HA
| Ressources HA VMs configurées pour redémarrage automatique | Groupe HA Ensemble de VMs avec priorités définies | Quorum Majorité des nœuds pour prendre des décisions |
Configuration de HA sur une VM
Pour garantir la continuité de service sans intervention manuelle, j’ai configuré la Haute Disponibilité (HA) sur mes machines virtuelles critiques. Dans un premier temps, j’ai accédé à la section Datacenter > HA pour créer un groupe de ressources. Ensuite, j’ai activé l’option « Manage HA » sur la VM sélectionnée.
J’ai enfin défini un niveau de priorité (sur une échelle de 0 à 3) pour indiquer au cluster l’ordre d’importance des services à redémarrer automatiquement sur un nœud sain en cas de défaillance matérielle de l’hôte d’origine. Afin d’organiser la répartition des machines virtuelles en cas de basculement, j’ai créé un groupe HA nommé « all-hosts ». Dans cet assistant, j’ai sélectionné l’ensemble des nœuds disponibles (pve01, pve02, pve03) pour qu’ils puissent tous servir de cibles de secours. Cette étape permet de définir un périmètre de confiance où le cluster est autorisé à relancer automatiquement les services sans intervention humaine.
Cliquer sur “Create”
Stratégie de redémarrage
| Restart Redémarrer la VM sur n’importe quel nœud | Relocate Redémarrer sur un nœud spécifique | Freeze Geler la VM (pas de redémarrage automatique) |
Monitoring HA
Bonne pratiques HA
Minimum 3 noeud pour quorum stable
Configurer les priorités selon l’importance
Tester les scénarios de défaillance
Monitorer les logs : var/log/pve/ha-manager.log
Stratégie de sauvegarde
Sauvegarde manuelle via interface
Pour sécuriser mon infrastructure, j’ai mis en place une stratégie de sauvegarde externalisée. Dans l’onglet Storage du Datacenter, j’ai ajouté un nouveau stockage de type Proxmox Backup Server (PBS).
Comme illustré, j’ai renseigné l’adresse IP du serveur cible (192.168.101.233) et les identifiants de connexion. Cette configuration est indispensable pour réaliser des sauvegardes manuelles ou planifiées de mes VMs vers un espace de stockage dédié et ainsi garantir la résilience des données.
Après avoir configuré l’accès au serveur PBS, j’ai vérifié la disponibilité du nouveau stockage dans l’interface de la VM (capture du haut). On peut constater que le stockage de destination « NewBackupLocation » est correctement monté.
Sauvegarde planifiée
Pour garantir une sécurité maximale sans intervention quotidienne, j’ai ensuite mis en place une sauvegarde planifiée. En me rendant dans Datacenter > Backup > Add, j’ai configuré un « Backup Job » en définissant le nœud source, le stockage PBS cible, ainsi que la récurrence (jour et heure). Cette automatisation assure que l’ensemble de mes données est protégé régulièrement sur une infrastructure distante.
Proxmox Backup Serveur (PBS)
| Installer PBS Installer PBS sur un serveur dédié | Configurer le Stockage Configurer le stockage de destination |
| Ajouter PBS à Proxmox Ajouter PBS comme stockage dans Proxmox | Planifier les Sauvegardes Planifier les sauvegardes vers PBS |
Restauration d’une VM
Pour valider l’intégrité de ma stratégie de sauvegarde, j’ai testé la procédure de restauration d’une machine virtuelle. Je me suis rendu dans la section Storage de mon nœud, où j’ai sélectionné l’onglet Backups. Après avoir identifié l’archive correspondante (vzdump-qemu-100…), j’ai cliqué sur le bouton « Restore ». Cette manipulation permet de redéployer rapidement une VM à partir d’un état antérieur, garantissant une reprise d’activité efficace en cas de corruption du système ou d’erreur humaine.
Pour finaliser la procédure de restauration, j’ai configuré les paramètres de réintégration de la machine virtuelle dans la fenêtre « Restore: VM ». Comme illustré, j’ai sélectionné le nœud cible et défini un nouvel ID de VM pour éviter tout conflit avec une instance existante. J’ai également pu ajuster les ressources (mémoire et cœurs CPU) avant de valider. En cliquant sur le bouton « Restore », le système a procédé à l’extraction de l’archive et à la reconstruction de la VM, confirmant ainsi que notre plan de reprise d’activité (PRA) est opérationnel.
Vérification des sauvegardes
proxmox-backup-client list
proxmox-backup-client verify
Maintenance régulière
Mise à jour du système
Redémarrage sécurisé d’un nœud
- Migrer toutes les VM vers d’autres nœuds
- Mettre le nœud en mode maintenance
- Redémarrer le nœud
- Vérifier la reconnexion au cluster
Vérification de la santé du cluster
Troubleshooting courant
| Nœud Hors Ligne Symptôme: Un nœud n’apparaît pas dans le cluster Solution: Vérifier la connectivité réseau Vérifier le service corosync: systemctl status corosync Redémarrer corosync: systemctl restart corosync Vérifier les logs: journalctl -u corosync | Migration Échouée Symptôme: La migration d’une VM échoue Vérifications: Vérifier les ressources disponibles sur le nœud cible Vérifier l’accès au stockage partagé Vérifier la connectivité réseau entre nœuds Consulter les logs: tail -f /var/log/pve/tasks | Migration Échouée Symptôme: La migration d’une VM échoue Vérifications: Vérifier les ressources disponibles sur le nœud cible Vérifier l’accès au stockage partagé Vérifier la connectivité réseau entre nœuds Consulter les logs: tail -f /var/log/pve/tasks |
journalctl –since « 2023-04-28 00:00 » –until « 2023-04-28 08:45 » > /tmp/Syslog.log
ls /etc/pve
ls /etc/pve/nodes
# if the `ls` result that there are files in the above two commands do continue with:
cat /etc/pve/corosync.conf
cat /etc/pve/.members
pveversion -v
qm start 100
