Fiabiliser et sécuriser les serveurs de votre collectivité
De façon basique, un poste de travail accède, à travers un réseau privé ou public, à un serveur qui lui fournit des données, logiciels et services.
Centraliser les données, logiciels et services sur un serveur permet de les fiabiliser et de les sécuriser. D’abord parce que cela facilite la sauvegarde, ensuite parce que les serveurs sont des équipements plus fiables que de simples ordinateurs. Ils sont souvent dotés de composants redondants et sont prévus pour fonctionner 24/24h.
Il existe cinq niveaux de fiabilité, dont voici l’essentiel à retenir :
Niveau 1 : serveur physique
C’est le niveau le plus bas, mais déjà mieux qu’un simple poste de travail.
Un serveur physique apporte de la fiabilité avec des composants redondants comme les alimentations électriques et les disques durs. La panne d’un disque dur par exemple n’empêche pas le serveur de continuer à fonctionner. L’installation d’un logiciel de sauvegarde sur le serveur est le niveau minimum recommandé. Cependant, en cas de panne du serveur, la remise en service peut être longue et fastidieuse.
Niveau 2 : serveur virtuel
Une bien meilleure solution consiste à utiliser des serveurs virtuels plus couramment appelés VM pour Virtual Machine. Cette solution mutualise un serveur physique pour exécuter plusieurs VM. Techniquement, cela consiste, grâce à un logiciel hyperviseur, à installer plusieurs systèmes d’exploitation serveur (comme Windows Server ou Linux) sur la même machine physique. Chaque VM fonctionne de façon totalement autonome et indépendante des autres. Cela apporte beaucoup de souplesse dans la gestion et l’utilisation des VM. Par exemple, on peut dédier une VM à un logiciel métier spécifique seul (Comptabilité, finance, RH…) pour permettre l’installation des mises à jour et le redémarrage sans perturber les autres VM.
De plus, cette technique de virtualisation de serveurs facilite grandement la sauvegarde et la restauration, avec un logiciel adapté et un espace sur le réseau dédié aux VM sauvegardées (par exemple un serveur NAS). Une VM étant un objet à part entière pour l’hyperviseur, il peut être manipulé facilement. On peut même restaurer la VM sur un autre serveur physique et la redémarrer immédiatement, ce qui est très confortable et rapide s’il faut changer le serveur physique. Il ne sera pas nécessaire de tout réinstaller.
Enfin, mutualiser un serveur physique plutôt que d’en acheter plusieurs permet de réaliser des économies.
Niveau 3 : Réplication des serveurs virtuels en différé
Le point faible du niveau précédent est la panne du serveur physique. Dans ce cas, aucune VM ne peut fonctionner. Il convient d’abord de s’assurer que le serveur est sous garantie, car il devient d’autant plus critique qu’il exécute beaucoup de VM.
Ensuite, la solution pour augmenter la fiabilité du dispositif est de mettre en service un autre serveur, en tant que serveur de secours.
En répliquant les VM sur le serveur de secours à travers le réseau, on peut ainsi les redémarrer en cas de panne du serveur principal. Les outils utilisés ici permettent une réplication en différée mais pas en temps réel. On parle alors de réplication asynchrone.
Une bonne pratique, quand c’est possible, est d’utiliser le serveur de sauvegarde comme serveur de secours. Cela permet aussi de mutualiser ce serveur et de réduire les coûts. Il faut cependant qu’il soit suffisamment dimensionné. Idéalement, on remplace alors le serveur NAS de sauvegarde utilisé dans le cas précédent par un serveur physique classique.
Niveau 4 : Mise en cluster des serveurs physiques
Le niveau précédent présente malheureusement encore une faiblesse : la perte de données. En effet, en répliquant les VM en différé toutes les 15 minutes par exemple, on perd alors jusqu’à 15 minutes de production de données dans le cas d’une panne du serveur principal. On peut diminuer la fréquence de réplication à 5 minutes, mais cela charge beaucoup l’hyperviseur au détriment de la performance des VM. Il faut donc trouver le juste équilibre.
Le dispositif peut être amélioré en regroupant les 2 serveurs physiques en « cluster ». Dans ce cas, les 2 serveurs qui forment une seule entité logique, partagent un espace disque commun pour stocker les VM et peuvent l’un comme l’autre exécuter les VM. Cette solution permet de répartir la charge des VM sur les 2 serveurs physiques et d’assurer une continuité de service. En effet, si l’un des 2 serveurs tombe en panne, les VM qu’il exécutait sont immédiatement redémarrées sur l’autre serveur par l’hyperviseur. Dans ce cas, s’il y a une indisponibilité du service pendant quelques secondes, le temps de redémarrer les VM, il n’y a aucune perte de données.
Cette solution est donc adaptée aux environnements critiques qui nécessitent une haute disponibilité des données, logiciels et services fournis par les VM.
Enfin, un cluster peut regrouper un très grand nombre de serveurs physiques, pas seulement 2. Cela dépend du nombre de VM à exécuter.
Niveau 5 : Cluster étendu sur des sites géographiques distincts
La solution idéale est de répartir le cluster (serveurs et stockage) sur 2 sites géographiques, pour s’affranchir d’un sinistre majeur (incendie, inondation…) sur l’un des sites et basculer l’ensemble des VM sur l’autre site. Les données des VM sont ici répliquées en temps réel entre les 2 sites, on parle alors de réplication synchrone.
Ce dispositif nécessite cependant :
- de disposer de liaisons fibres optiques particulières entre les 2 sites ;
- de doubler d’autres éléments de l’infrastructure technique, comme le cœur de réseau et la liaison Internet, pour permettre aux postes de travail de continuer à fonctionner normalement.
Cette solution, la plus couteuse, est donc adaptée aux grandes collectivités.
En fonctionnement normal, les VM sont réparties sur les serveurs physiques des 2 sites.
En cas de panne d’un serveur sur un site, les VM sont basculées sur les autres serveurs du site et, si besoin, sur le deuxième site géographique. C’est le logiciel hyperviseur qui se charge de la répartition des VM.
Enfin, en cas de panne complète des serveurs sur un site (par exemple une panne électrique sur le site), alors les VM du cluster redémarrent sur les serveurs de l’autre site. Puis, une fois les serveurs en panne redémarrés, l’hyperviseur assure à nouveau un équilibrage de charge en répartissant les VM sur tous les serveurs, de façon automatique.
Quel niveau de fiabilité pour votre collectivité ?
Pour conclure, le choix du niveau de fiabilité doit prendre en compte la criticité des données, des logiciels et des services fournis par les VM, mais aussi forcément le budget de la collectivité, car plus le niveau est élevé, plus la solution est coûteuse.
COGITIS recommande fortement à toute collectivité, y compris les plus petites, de choisir au moins le niveau 2 avec des serveurs virtuels, même pour une seule VM.
Un bon compromis sera le niveau 3, en essayant si possible d’utiliser le serveur de sauvegarde comme serveur de secours pour redémarrer les VM.
