Grenode utilise Proxmox our gérer certains de ses hyperviseurs.

Il est existe pour l'instant un seul cluster à Grenoble-002 comprenant deux nœuds : hauban et sabord. À deux nœuds, ce cluster ne fonctionne pas en haute disponibilité. Néanmoins des réplications inter-nœuds sont faites toutes les 15 minutes et des migrations à chaud sont possibles.

Procédures

Utilisateurs et accès

Pour interagir avec Proxmox, il faut avoir un compte SSH unix sur le serveur et être enregistré dans le fichier d'utilisateur de proxmox dans le realm pam. Nous prévoyons deux types d'utilisateurs. Les admin de Grenode qui sont root sur les hyperviseurs et qui sont dans le groupe unix sudo et le groupe proxmox g_SuperAdmin, ils ont tous les droits. Les admin des structures membres qui n'ont aucun droits unix sur les hyperviseurs et qui sont dans le groupe proxmox de leur structure : g_<trigrame>-Admin. Ils ont les droits pour visualiser la console et redémarrer les vm de leur pool de resource p_<trigrame>.

Pool de ressources

Chaque structure membre dispose d'un pool de ressource qui permet de rassembler les vm qu'elle utilise. Ces pools sont nommés : p_<trigrame>.

Accès à l'interface web

L'accès à l'interface web peut se faire sur n'importe quel nœud de l'hyperviseur. Nous avons restreint l'accès à cette interface pour des raisons de sécurité.

Via de la redirection de port

ssh -L 8006:localhost:8006 hauban.grenode.net

Et ensuite dans son navigateur il faut taper l'adresse https://localhost:8006

Via du proxy socks

ssh -D 1337 hauban.grenode.net

Il faut activer le proxy socks sur son navigateur. Le plugin foxyproxy de firefox est pas mal pour active de proxy socks selon les url.

Et ensuite dans son navigateur il faut taper l'adresse https://hauban.grenode.net:8006

Pannes

coupure franche du lien réseau entre les deux nœuds

Testé en coupant les ports d'une machine sur le switch.

Les deux nœuds se considère master. Ce n'est pas grave car il n'y a pas de HA (les vm ne vont pas être démarrées deux fois en parallèle automatiquement). Par contre, dans ce type de cas, il faut être très prudent. Si sur un des deux nœuds on allume une vm (en déplacant son fichier de conf), la vm va bien être considérée comme déplacée par proxmox mais le processus de la première ne sera pas éteint. La même vm tournera deux fois.

Dans ce type de cas, il faut éteindre le nœud que l'on considère défaillant (ou au moins les vm si c'est possible). Sinon quand la communication reviendra, les mêmes vm existeront deux fois. Il y a aussi un risque que le cluster diverge et qu'il ne soit plus possible de réconcilier les nœuds. Dans un cluster avec plus de nœuds, un nœud qui n'atteint pas le quorum n'est plus modifiable (le système de fichier de proxmox passe en lecture seul). Prudence donc.

coupure franche d'un nœud

On a testé en coupant l'électricité via la carte BMC. Ce cas est plus simple, car il suffit de déplacer les vm sur le nœud restant.

~~~ ssh Y sudo mv /etc/pve/nodes/X/qemu-server/*.conf /etc/pve/nodes/Y/qemu-server/ ~~~

Lorsque que le nœud X éteint est rallumé tout se passe comme prévu pour les vm. La conf du nœud rallumé se mets à jour.

disque système HS sur nœud

Une alerte est levée par la supervision du raid mdadm. On doit évacuer toutes les vm du nœud problématique pour changer le disque car cela nécessite de l'ouvrir.

disque data HS sur un nœud

Une alerte est levée par la supervision sur le pool zfs. Il faut remplacer le disque. Cela peut se faire à chaud.

• TODO: Quelle est la procédure avec ZFS ?
• TODO: Comment identifier le disque défectueux ?

Installation

Installation du cluster à Grenoble

Cf hauban

Automatisation des comptes

TODO : écriture d'un role ansible pour la gestion des utilisateurs ?