Lors du changement dynamique de l’adresse publique du cluster, ce dernier n’est plus accessible pendant un délai d’environ 5 minutes. Ceci est lié au temps de fermeture des sockets TCP vers l’ancienne adresse publique.

Pour rendre visible ce phénomène, un avertissement a été ajouté sur le site pour signaler l’état d’accessibilité du cluster.

« Serveurs Proxmox OK » : le cluster est accessible et dans ce cas on peut y accéder via le menu.

« Les serveurs siocachan sont momentanément indisponibles, revenez dans environ 5 minutes » : changement d’IP publique en cours, il faut attendre et rafraîchir la page de temps en temps pour avoir le dernier statut.

Conclusion : quand on rencontre un problème d’accès aux VM ou conteneurs Proxmox, ainsi qu’à GLPI, regarder d’abord le statut de changement d’IP publique en rafraîchissant la page d’accueil du site.

10 nouveaux noeuds ont été ajoutés au cluster Proxmox (pve23 à pve33), portant ainsi sa capacité de stockage en volume partagé RBD à un total de 7,64 tera octets. La difficulté a consisté à retirer complètement des noeuds du cluster pour les y réintégrer, ce qui n’est une opération triviale dans Proxmox.

Le site siocachan.fr a aussi été légèrement redessiné.

Il est possible maintenant de saisir un ticket GLPI pour toute demande ou incident affectant le réseau SIO de Cachan.

Il est accessible en interne par glpi.siocachan.fr.

Les identifiants d’accès sont les mêmes que ceux utilisés pour l’accès au SI.

Après de longues recherches concernant l’administration de Proxmox, devenu inopérant depuis sa migration vers un réseau dédié, il est de nouveau possible d’utiliser l’hyperviseur dans les conditions initiales mais avec comme amélioration notable un accès depuis internet via le site siocachan.fr

Les modifications qui ont été réalisées sont :

• Mise en place d’une connexion dédiée avec un accès extérieur (adresse publique) aux serveurs du réseau SIO
• Branchement des serveurs du cluster sur un commutateur unique
• Isolement du cluster dans un VLAN dédié pour faciliter la communication « broadcast » et pour optimiser les transferts de données (clones) entre serveurs.
• Changement du plan d’adressage, qui a occasionné des difficultés de redémarrage du cluster dans son état nominal.
• Changement du mode de transport de flux entre les serveurs (en particulier pour Corosync)
• Restauration de l’authentification AD