Bonjour,
 
Je bosse actuellement à construire une infra de calculateur pensée pour la disponibilité et la sécurité. En effet, ce type de machine tombe souvent en panne, et la présence de nombreux utilisateurs logués en ssh sur les frontales expose la configuration à un de grosses problématiques de sécurité. Il convient donc de réduire au maximum la surface d'attaque.
Comment fonctionne un calculateur : les utilisateurs se loguent en ssh sur la frontale, y compilent leur code sur un espace disque partagé avec les nodes, et envoient un job au job scheduleur qui attribuera les ressources en fonction des besoins et de la charge de la machine. Une fois le calcul démarré, il s’exécute en parallèle sur un groupe de nodes, et le résultat est écrit sur l'espace partagé. L'utilisateur accède ainsi au résultat et les rapatrie en sftp depuis la frontale.
 
Je cherche ici à construire une configuration apte à se déployer et se redéployer à partir d'un seul et unique serveur : Ansible-Master (cf shéma joint).
 
Le concept :
 
Le serveur Ansible Master possède les clés ssh de l'ensemble de la configuration. Il n'écoute sur aucun ports coté machine (et l'ensemble des ports sont fermés), son seul accès se fait par un réseau dédié d'administration. Il n'est donc potentiellement pas vulnérable.
L'ensemble des services ssh n'écoutent que l'ip d'Ansible Master, à l’exception de la frontale qui écoute aussi sur une autre interface exposée au web (entrée utilisateurs).
 
Ce serveur déploie le serveur de repository, qui contiendra l'ensemble des packages de la distribution, ainsi que les packages maisons. Cette machine possède un accès côté web, et expose un serveur http à l'ensemble de la configuration.
Puis sont déployé (PXE+DHCP, puis playbook ansible pour chacun) le reste des "pets", soit sur du dédié, soit dans des VMs : DNS, DHCP, NTP, PXE. Ces serveurs exposent leur services respectifs à l'ensemble des nodes de calcul (considérées jetables, comme en cloud, donc "catles" ), ainsi qu'à la frontale.
Le Job scheduleur est aussi déployé, sont rôle est de répartir les jobs des utilisateurs sur les nodes.
Je penses utiliser un outils comme oVirt pour passer l'ensemble de ces services en HA (en plus du modèle maitre-esclave pour chacun).
A noter que sur ce réseau "d'admin", je ne sais pas où mettre le DHCP et le PXE dédié. Pas sur Ansible master, trop risqué selon moi. Il faudra donc peut être considérer que deux serveurs sont de base nécessaires au déploiement et non un.    
 
Puis vient la frontale et les nodes. Encore une fois, déployé par PXE+DHCP, et avec un playbook ansible pour terminer. Les nodes tombent souvent en panne car nombreuses. Elles seront redéployées au fur et à mesure selon la même méthode.
 
Il manque ici le serveur de logs, ainsi que les serveurs de stockage type NFS/Lustre/Autre. J'aborderai le sujet par la suite.
 

 
Que pensez vous de cette configuration ?    
Est-elle viable dans la durée ? Et côté sécurité, y a t-il des choses anormales qui vous sautent au yeux ? A noter que certains morceaux (réseau infiniband et lustre notamment) nécessitent parfois de recompiler le kernel sur les nodes dont la frontale, rendant du coup la mise à jours pourtant cruciale de cette dernière délicate...
 
Zaft

ça ressemble fort à un exercice que j'avais eu à faire lors d'une formation serveur ça...

Après perso ton schéma c'est un peu le fouillis... en quoi tu as besoin de contacter par SSH ton serveur de temps ou ton serveur PXE ?
Ton NTP à part dire "coucou il est telle heure" quand on lui pose la question, c'est pas ultra-sensible.
Le PXE du moment que tu renseignes bien qui est qui, et que tu fonctionnes sur un réseau (physique/logique) dédié, pareil.
La partie DNS peut déjà être suffisamment sécurisé sans avoir besoin d'une connectivité SSH auprès de ses clients.

L'utilisation de VLAN me semblerait plus à même de répondre à certaines des problématiques que tu te poses, plutôt que d'utiliser du SSH partout... sauf si tes nodes sont hébergés chez un/des tiers.
Et encore, ça dépend lequel, OVH proposant par exemple du VLAN entre ses différents DC, et Online proposant un service similaire.

C'est un projet fort sympathique que je suivrais pour la mise en place d'un cluster de virtualisation (sous Proxmox ou ESXi)...

Hello
 

 
On est beaucoup à y avoir réflechi, comment concilier sécurité et HPC, et en fait, tu ne peux pas vraiment le faire.
 
Vu qu'une interruption de service de 1 min peut casser des calculs qui tournent depuis 1 semaine, tes utilisateurs vont au mieux te haïr et au pire rien comprendre si tu commences à appliquer toutes les updates de sécurité/firmware/etc, à rebooter des switchs, couper le ldap/dns, etc. C'est pas un cluster de serveur web, tu peux pas relancer les jobs en appuyant sur F5  
En plus, une perturbation sur ton infra est susceptible de fausser les résultats des utilisateurs, et ça peut avoir des conséquences assez grave...
En plus tu verras, quand tu auras réussi à fiabiliser ton infra lustre, l'envie de faire des yum update tous les matins va vite te passer    
 
Bref, sur ton cluster, quoique tu fasses, tu n'arriveras pas à maintenir un niveau de sécurité parfait.
 
La solution est de n'avoir qu'un seul point d'entrée au cluster, la frontale, de la sécuriser autant que tu peux et d'isoler ton cluster du monde extérieur en utilisant des vlans.  
Ensuite, tu dois faire confiance à tes utilisateurs, quitte à leur faire signer une charte d'utilisation sur papier prévoyant le cas d'une utilisation malveillante (ban du compte, forward aux ressources humaines   )
 

 
Les utilisateurs ne devraient pas pouvoir compiler sur la frontale, ils devraient plutôt lancer un job pour compiler leur soft sur un noeud de calcul. Sinon tu vas te retrouver avec plusieurs utilisateurs qui font des tâches de compilation lourdes sur ta frontale, et la frontale sera lente pour tout le monde.
Et pour limiter la surface d'attaque, tu installes le minimum vital sur la frontale.
 

 
Ce que tu veux faire, c'est un "bastion", un serveur d'administration qui a accès à tout au niveau réseau et peut se connecter à tous les serveurs en ssh (avec une clé ssh qui est dans tous les authorized_keys).  
C'est indépendant du serveur de déploiement à mon avis.
 

 
 
Perso j'ai fait ça avec des vlans:
 
* vlan access : le seul vlan sur lequel les connections externes sont autorisées, seule la frontale a une interface dans ce vlan
* vlan management : toutes les interfaces de management du matériel (BMC, CMC, baies de disques, etc) sont câblées dessus, le DHCP et le serveur de déploiement ont une pattes dedans (pour faire de l'IPMI).
* vlan production : tous les serveurs, la frontale, le stockage et les noeuds de calculs sont dessus, ce vlan est exposé aux utilisateurs.
 
Au niveau ACL réseau, tu filtres tout le trafic venant du vlan production vers le vlan management.
 
Ce que tu veux faire pour sécuriser encore plus, c'est un vlan supplémentaire, "admin", pour tous les services d'administration comme ssh, salt, pxe, etc.
 
D'expérience, c'est trop compliqué en pratique, j'ai fini par supprimer le vlan admin, ssh écoute sur toutes les interfaces réseaux et le déploiement se fait sur le vlan production.
 
Ensuite, j'ai un serveur de services (serveur debian+xen, avec un domU par service réseau), qui a une interface dans chaque vlan (prod et management). Ca permet de donner accès au vlan de management individuellement à chaque domU (ou pas).
 

 
Pense à fixer ton dépot debian / yum local, pour ne pas avoir des versions différentes des paquets à chaque redéploiement. Le cluster doit rester aussi homogène que possible, et il faut éviter de passer des mises à jour sans les valider...
 

 
Un conseil, pour la sécurité, si tes systèmes sont bien configurés, ça ne sert à rien de faire des choses compliquées au niveau réseau.  
Sinon tu vas finir par t'arracher les cheveux...  
Bien sûr, si tu as des contraintes légales particulières (par exemple si tes utilisateurs manipulent des données médicales), ça vaut le coup de faire un effort supplémentaire.
 

 
Perso j'utilise le support infiniband fourni par debian ou redhat/centos (pas OFED), et j'ai jamais eu besoin de recompiler quoique ce soit.
Pour lustre, j'ai généré mes packages une fois pour le kernel stable debian, et je peux appliquer les updates de sécurité du noyau sans recompiler les modules lustre. Par contre, c'est impossible de faire passer des updates kernel et rebooter les serveurs sans un créneau de maintenance sur une infra HPC en prod.

Ralala, les archis en herbe ...

Proposez mieux

Merci pour vos retours    
 

 
Je ne suis pas informaticien de formation (turbines à gaz et mécanique des fluides, cherchez le lien   ), donc disons que je refait les classiques pour progresser    
Mon idée est de prendre ce qui se fait déjà et de voir si je peux faire évoluer. J'ai pu voir des archis tellement complexes que les machines étaient tout simplement impossible à maintenir (désynchronisation, vlans dans tous les sens, topologies complètement alambiquées, etc). Il y a tellement de pannes potentielles sur ces machines qu'une archi simple et standard est souvent, selon moi, la clé du succès.
 
Le ssh me permet d'utiliser Ansible pour déployer mes nodes. En effet, une fois le kickstart terminé, la node est "générique". Elle reboot, et j'utilise un playbook ansible pour pousser dessus le nécessaire vitale (pour des raisons de performances, les nodes sont le plus léger possible) : montages réseau, clients slurm et munge (job shceduleur), quelques configurations coté usage de la RAM et du système, clients de monitoring, etc. Effectivement, un VLAN dédié est envisageable. Mais pour le moment, les switchs de ma machine de test sont un peu con, il y a beau y avoir 24 ports, ils ne sont pas ménageables... C'est une vielle dame sous nehalem. Tu suggères donc un VLAN pour la partie déploiement si je comprend bien ?
 
Les machines visées par contre sont totalement dédiées, l'hébergement chez un tiers est exclut dans ce projet.
 
 
 
Oui, j'ai bien conscience de ce problème. Je cherche surtout un moyen de libérer les frontales et les nodes de calcul, qui sont les plus exposés, de ces entraves de mises à jours. Si il était possible de faire des updates réguliers sans problèmes sur ces éléments, cela serait déjà bien sécurisé. L'OFED, si l'on verrouille la version, ne devrait pas poser de problèmes. C'est surtout Lustre qui me chagrine.
 
 
 
Pas évident, toutes les équipes n'acceptent pas la contrainte "pas de packages supplémentaires sur la frontale, compilation sur les nodes". C'est effectivement la bonne voie, mais je n'ai pas encore réussi à pousser dans ce sens. L'une des grandes difficultés du HPC, c'est qu'on est pas seul maitre à bord des machines, et que la sécurité et la stabilité ne sont pas les light-motive de tout le monde.
De même, je milite pour la non installation de packages sur les systèmes pour ne pas les alourdir (exemple : un utilisateur à besoin de la lib cairo (graphique). Déployer les rpm sur l'ensemble des nodes est à mon sens une hérésie, il convient mieux de déployer le package à la main, dans un répertoire partagé isolé avec ue arborescence de libs cohérente, et de charger la lib à la volée avec un outils comme "Modules" par la suite.).
Bref, la non compilation sur la frontale, je rejoint ton sens c'est une évidence, mais ce n'est pas encore assimilé partout.
 
 
 
Ca rejoint aussi bardiel, le cloisonnement dans des VLANs des réseau. C'est effectivement ce qui a le plus de sens. Le réseau en est simplifié car il y a peu de VLANs.
Ta frontale à une patte sur l'IB ? Ou tu fait les transferts de gros volumes par l'intermédiaire des nodes de calcul ?
 
 
 
C'est ce créneau le problème. Comme tu dis, on ne peut couper les jobs en cours. N'est t-il pas envisageable de faire évoluer les nodes par groupes ? Le job scheduleur les réservent comme pour un job et les fait évoluer. (sous réserve de tests positifs sur un jeu de nodes témoin). Idem pour les frontales.
 

 
Explique. Je suis parfaitement ouvert à la critique si elle est constructive. Que conseils tu ?    
 

 
Normalement pour infiniband, tout est packagé sous centos. Pas besoin de compiler ton OFED.
 

 
Il faut faire de la pédagogie et forcer cette approche à mon avis. Si 10 utilisateurs pénalisent les 90 autres, c'est contre productif pour tout le monde.
Tu ne vas pas redéployer ta frontale tous les jours, sa configuration va diverger de celle des noeuds de calcul, et ce que tu compileras sur la frontale ne fonctionnera pas forcément sur les noeuds...
 

 
Installer des softs en espace utilisateur, ça peut devenir casse tête si tu ne fournis pas un minimum de dépendances. Perso j'accepte d'installer des paquets, du moment que ça ne pose pas de problème de sécurité (pas de nouveau service réseau, pas de démon) et qu'il n'y a pas d'effet de bord pour les autres utilisateurs...
 
Tu peux aussi fournir une liste de modules de base dans un répertoire partagé en NFS.
Si ça t'intéresse, tu peux faire ça assez rapidement avec easybuild: http://hpcugent.github.io/easybuild/
A noter que tes utilisateurs peuvent aussi utiliser easybuild dans leur homedir.
 

 
La frontale est connectée en Infiniband pour avoir accès directement aux serveurs de stockage.
En théorie, tes utilisateurs devraient faire du stage in/stage out:
 
* ils transfèrent leurs données brutes de leur workstation vers la frontale
* ils lancent des jobs sur les noeuds de calculs pour traiter les données
* ils récupèrent leurs résultats de la frontale vers leur workstation
* une fois terminé, ils nettoient leurs fichiers du cluster.
 

 
C'est la meilleure solution pour éviter une interruption de service.  
Mais ça veut aussi dire que ton cluster est hétérogène pendant cette procédure, ça peut créer des effets de bord...

Un peu en retard    
 
Merci pour toutes ces précisions.
 
Je vais tester easybuild dans une VM. Pour le moment, je compile tout en espace utilisateur. Je n'ai pas eu de problèmes, sauf avec QT, qui s'est avéré compliqué à compiler.
J'ai fait une liste ici : http://www.spheniscus.brennik.fr/d [...] /libraries
 
Coté dépendances, j'ai même eu des problèmes avec des basiques comme zlib. Certains softs d'utilisateurs prenaient la version du système (avec bien sur aucun moyen de forcer une autre manuellement), et celle de la centos n'était pas compatible. J'ai donc fini par faire un système vierge, et je monte tout à la main avec les modules et un jeu de wrappers. C'est certes lourd à maintenir, surtout au départ, mais ensuite ça se fait plutôt bien et je gagne même du temps maintenant car je contrôle toutes les versions. Et ca me permet de tuner certaines libes (comme la fftw, ou des libs d'imagerie et de vidéo) pour le CPU du calculateur.
Même le compilateur Intel à fini en espace utilisateur    
 
Petites questions réseau : as tu tunés certains aspects du réseau IB ? Notamment la taille des frames. Je ne connais pas l'optimum, donc pour le moment c'est à 9000.  

 
T'es bien courageux de faire ça à la main from scratch
 

 
Pour l'ip over ib, j'ai juste ça dans dans le /etc/network/interfaces sur tous les noeuds:
 

 
Et dans le rc.local, je mets un nom sur /sys/class/infiniband/node_desc pour identifier les HCA dans l'output des commandes infiniband (ibnetdiscover, etc).
Il me semble que c'est tout.