La gestion d'un site distant

Dans mon cadre professionnel, je dois gérer à distance l'équipement informatique (ordinateurs, réseaux, serveurs...) d'un deuxième campus situé en Afrique, sans intervention physique possible sauf à prendre l'avion pour changer de continent... Cela fait cinq ans que cela dure, avec plus ou moins de bonheur. Il est temps pour moi de faire un petit retour d'expérience qui pourrait intéresser quelques lecteurs de ce blog.

La première remarque concerne la nécessaire prise de conscience de devoir faire des choix de procédures simples et fiables. Quand on ne peut pas intervenir facilement pour redémarrer un actif réseau ou pour changer un disque dur, le travail à distance peut vite devenir un vrai casse tête. J'ai le souvenir d'un système de stockage qui contenait toutes les sauvegardes, sur lequel j'intervenais via la console web d'administration. Une fois correctement paramétré, j'ai redémarré le système. Sauf qu'au lieu de cliquer sur "redémarrer", j'ai cliqué sur "éteindre". Mon système distant s'est arrêté correctement... Mais il a fallu que j'appelle une personne du site pour lui demander d'aller dans la salle serveur appuyer sur le bouton de démarrage du système de stockage. J'y ai passé plus d'une heure (décalage horaire, clef de la salle serveurs, autorisations, description du système, vérifications...). J'ai maintenant investi dans un système dont le démarrage à distance est simple et/ou programmable à heure fixe.

La deuxième remarque concerne la sécurité informatique. Il faut prévoir dès le départ un budget permettant d'avoir des actifs réseaux particulièrement performants et intelligents. Pour autant, il faut comprendre qu'un système informatique distant devant fonctionner sans informaticien est particulièrement vulnérable et fera la joie de tous les hackers passant par là. Mais la sécurité a un coût et une complexité qu'il faut nécessairement mettre en balance avec la fiabilité et le confort de l'usager. J'ai donc du faire des choix qui feront sans doute pleurer tous les informaticiens un peu sensibles sur le sujet de la sécurité...

Les réseaux :

Rien ne peut se faire à distance si les réseaux informatiques ne fonctionnement pas. Le réseau informatique filaire mis en place est un réseau classiquement encastré dans des goulottes. Il faut insister dans le cahier des charges et lors du suivi de chantier pour obtenir des goulottes suffisamment solides et d'une capacité supérieure au strict nécessaire. Il n'est pas normal qu'une goulotte fraichement installée soit pleine à craquer de câbles réseaux, empêchant l'ajout ultérieur d'une ou plusieurs prises réseaux. J'ai choisi un réseau gigabit, avec des baies de brassage intégrant les actifs réseaux. Là aussi, il faut insister pour que les baies soient suffisamment aérées pour que la chaleur dégagée par les switchs puisse s'évacuer, et qu'une climatisation soit installée, surtout lorsque la température extérieure monte très haut, ce qui est le cas en Afrique. De préférence, les actifs réseaux seront branchés sur un régulateur de tension et un onduleur. Tous les actifs réseaux doivent être configurés pour interdire le branchement de quoi que ce soit qui ne soit pas autorisé explicitement par le service informatique. Pour des raisons de coûts, j'ai choisi une gestion des autorisations d'accès basée sur l'adresse MAC du système informatique que l'on souhaite brancher sur le réseau. Que tout ceux qui connaissent l'expression "MAC Address Spoofing" arrêtent de rigoler... Il y a un VLAN pour l'administration, un VLAN pour les professeurs, un VLAN pour les salles de TP et un VLAN pour les bornes Wifi.

Une fois l'épine dorsale de votre système informatique en place, vous pouvez commencer à brancher dessus quelques éléments clefs.

Première extension: l'accès internet.
Quand un boîtier ADSL tombe en panne, la procédure la plus simple pour un membre du site distant (en général la secrétaire) est d'appeler le fournisseur d'accès pour qu'il envoie quelqu'un rapidement. Un technicien télécom débarque donc sur votre site distant, sans que vous soyez au courant, pour remplacer le modem ADSL. Autant vous dire qu'après plus rien ne marche comme prévu.

Il faut faire SIMPLE. J'ai choisi de mettre de côté le modem fourni par le FAI et d'acheter deux boîtiers que nous avons paramétrés selon nos besoins. L'un des deux sert de secours pour l'autre et est précieusement rangé dans une armoire appropriée, avec référencement précis et "formation" adhoc d'une personne de confiance sur le remplacement d'un modem par un autre. Ne pas oublier de prendre un abonnement ADSL proposant une adresse IP fixe si c'est possible.

Il faut ensuite mettre en place son propre serveur DHCP, avec une politique d'adressage claire. J'ai choisi de réserver ce rôle à une machine virtuelle GNU/linux de distribution Débian. J'ai choisi un masque réseau de 16 par pure habitude et un groupe d'adresses non routables (de type B donc, selon l'ancienne classification). J'ai conscience du risque de broadcasts élevés, mais le nombre total de machines restera relativement faible.

Deuxième extension réseau: le Wifi.
Là aussi, tant que faire se peut, choisir des bornes fiables et opter pour une configuration minimale. Chaque borne doit pouvoir être changée par un fournisseur/livreur qui se contentera de déballer la borne et de la brancher à la place de l'ancienne. Une fois la borne wifi branchée sur le réseau, elle obtiendra son adresse IP locale du serveur DHCP et pourra être utilisée immédiatement, en général en émettant en clair dans tout le voisinage... Pour des raisons pratiques, il est préférable de scanner régulièrement son réseau distant, car il n'est pas rare qu'une personne, toujours bien attentionnée, mette en place sa propre borne wifi. Dans une école, le BYOD est très bien ancré, et depuis longtemps. J'ai opté pour des bornes chiffrées avec un clef facile à retenir et donnée à tout le personnel et tous les étudiants. C'est un peu "open bar". Le réseau Wifi est donc très faiblement protégé. Il faut le cantonner à l'accès internet, mais les étudiants l'apprécient pleinement et apprennent à gérer leur propre sécurité. Et puis, si je peux aider quelques voisins à avoir un accès internet gratuit... Vive le partage ! Hadopi, Dadvsi et Loppsi nous ont un peu rabougri le cerveau.

Le VPN entre les deux campus.
C'est un confort pour l'administration à distance que de pouvoir contacter facilement un serveur ou un poste de travail. Après avoir testé la solution LogMeIn, toujours en place, nous avons mis en place un VPN permanent basé sur la solution OpenVPN sur serveurs Debian. Il faut garder à l'esprit que le lien entre les deux campus est basé d'un côté sur une simple liaison ADSL, donc très limité en bande passante (et asymétrique !).

Les serveurs :

Pour limiter le nombre de machines physiques, et donc le nombre de pannes matérielles, j'ai opté pour un serveur principal sous VMware ESXi contenant tous les serveurs sous forme de machines virtuelles (VM). Le serveur est changé tous les quatre ans et sert ensuite de serveur secondaire, pour héberger des répliques dormantes des VM dans le cadre du PRA. Les répliques sont réalisées toutes les nuit avec l'aide du logiciel Veeam Backup & Replication (version commerciale) qui nous donne pleine satisfaction. Un simple NAS (marque QNAP) permet de stocker les backups quotidiens, hebdomadaires et mensuels des VM sur un horizon de trois mois, largement suffisants pour les besoins de nos utilisateurs. Un backup complet est externalisé à chacun de nos déplacements sur site.

Toutes les machines doivent pouvoir être allumées en cas de problème par un WOL correctement paramétré.

Les logiciels :

Les serveurs physiques sont sous VMware ESXi.
Les serveurs virtualisés (VM) sont sous Windows 2008 R2 (AD et serveur de fichiers) et Debian (VPN, DHCP et Nagios).

Les postes clients physiques sont sous Windows 7, Windows XP SP3 ou Lubuntu, en fonction de leur ancienneté.

Tous les logiciels classiques (OS, bureautique, etc.) sont installés lors de nos déplacements sur site, en général avec le logiciel Clonezilla en mode multicast. Le but est d'avoir un poste client le plus standard possible pour qu'il puisse être remplacé facilement par un fournisseur local, sans avoir à ajouter trop de logiciels. Beaucoup de logiciels sont installés par simple glisser/déposer à partir de solutions de type "LiberKey", "Framakey" ou "PortableApps".

Tous les logiciels lourds (CAO, GPAO, simulations diverses, etc.) sont installés sur un serveur XenApp avec accès par client Citrix, ce qui nous permet de ne les installer qu'une seule fois, ce qui peut être fait à distance. Je vous laisse quand même imaginer l'installation d'un logiciel comme Catia par le mauvais côté d'une liaison ADSL...

La messagerie est externalisée sur Gmail avec un accord "Education" proposé par Google sur son produit "Google Apps". Les besoins de confidentialité sont gérés avec GnuPG pour les emails et TrueCrypt pour le stockage.

Les listes de distribution sont gérées à distance avec un serveur SYMPA qui sert pour les deux campus.

Les licences logicielles sont gérées à distance avec des serveurs FlexNet (ex FlexLM).

La supervision de tout le système est basée sur Nagios (et bientôt Centreon).

En conclusion :

Je n'ai pas la prétention d'avoir mis en place le système le plus performant, ni surtout le plus sur. Par contre, il fonctionne correctement depuis plus de cinq ans avec plus de 40 ordinateurs et 150 utilisateurs. Il semble assez bien adapté aux risques inhérents à un système d'enseignement supérieur. Il protège suffisamment, sans faire peser trop de contraintes sur l'utilisateur. En même temps, les enjeux en matière de confidentialité sont quasi inexistants, en partie parce que toutes les activités de recherches, avec dépôts de brevets, restent sur le campus français.

Beaucoup des systèmes et logiciels cités dans ce billet ont des équivalents chez d'autres éditeurs. Je n'ai pas testés toutes les solutions (Hyper-V, GVPE, etc.), et il y a aussi dans certains choix une part liée à l'histoire de mon service informatique, et aux habitudes et connaissances de mon équipe. Chacun pourra adapter mes solutions avec sa propre culture. Mais si vous avez des remarques complémentaires ou des suggestions, n'hésitez pas à les faire en commentaires pour faire un retour d'expérience pouvant bénéficier à tous. Aidez-moi à faire avancer ma roue de Deming.

Et si tout cela fonctionne, même à distance, c'est avant tout grâce aux personnes qui travaillent avec moi. Le facteur humain reste prépondérant, et ne concerne pas que l'étude des raisons aboutissant à une erreur. C'est ce qui rend notre univers technologique si passionnant, non?