Bonjour à tous,
Pour faire suite à ce thread (merci JWhy pour le déplacement, à propos
) et à quelques échanges sur le discord AF, je me suis pris par la main et ai créé une image docker pour mon usage personnel, adaptée aux GPUs et au mode de fonctionnement particulier proposés par
https://vast.ai. Mais elle est évidemment disponible pour tous ceux que ça pourrait intéresser (
https://hub.docker.com/r/gnomuz/fahclient)
Sans rentrer dans les détails techniques, dont certains me dépassent (!), une instance sur vast.ai est en fait un container docker qui tourne sur la machine hôte. C'est ce qui permet à une même machine qui comporte, par exemple, 4 GPUs, de proposer la location de 4*1,2*2 ou 1*4 GPUs associé(s) à tout ou partie des CPU cores et de la RAM.
L'image "bricolée" par mes soins a les caractéristiques suivantes :
- base Ubuntu 18.04 LTS (bionic), tous packages à jour, taille de 55 MB
- client FoldingAtHome 7.6.21 (le dernier en date)
- démarrage automatique du client
- fichier config.xml customisé inclus dans l'image
- configuration automatique du ou des slot(s) GPU en fonction de l'instance louée
- mise en pause du slot CPU au démarrage (ce qui permet de l'activer ou de le supprimer via FAHControl par la suite)
- directive "next-unit-percentage 100" intégrée au config.xml (optimisation à la marge ...)
- accès distant
sans mot de passe au client F@H possible depuis toute adresse IP. J'ai fait ce choix peu sécurisé (euphémisme) car le container n'est en fait accessible que via SSH avec authentification par clé. Ceci dit, il est tout à fait possible de rajouter un mot de passe par la suite une fois FAHControl opérationnel (cf le point 3)
Je me suis très largement inspiré de ce tuto :
https://medium.com/@zefcat_42/folding-at...f4f4c2f098
qui s'appuie lui-même sur une image malheureusement ancienne et qui n'a pas été mise à jour depuis le client F@H v7.5.1 :
https://hub.docker.com/r/ohgodatrini/fahclient
Dans la dernière version, je suis parti du container officiel (
https://github.com/FoldingAtHome/containers) et lui ai apporté les modifs nécessaires
J'ai testé le déploiement sur pas mal de machines vast, en mono comme en multi GPU, et après quelques ajustements, ça semble vraiment fonctionner sans problème, en suivant attentivement la tentative de tuto qui suit !
Les étapes pour démarrer sont donc les suivantes :
1) Compte vast
- créer un compte sur vast.ai (CB nécessaire, je conseille bien sûr une CB virtuelle, Paypal non disponible)
- associer une clé d'authentification publique à votre compte (nécessaire pour l'accès SSH et le monitoring). Voir à ce sujet le point 3 sur Bitvise.
- charger votre compte avec par ex. 10 USD
- paramétrer votre instance par défaut :
- Bouton "Edit image and config"
- choisir en bas de liste "custom image"
- custom image : gnomuz/fahclient
- choisir "Run interactive shell server, SSH"
- dans "On-start script" copier/coller le code suivant :
bash -c 'export f_user=XXXXXXX f_team=51 f_passkey=YYYYYYY f_power=full; bash ./fah_autorun.sh'
en utilisant vos propres identifiants user et passkey
- Choisir une taille de disque de l'ordre de 1 à 2 Go avec le slider. La quantité de stockage nécessaire dépend du nombre de WUs pliées simultanément, donc du nombre de slots (GPU + CPU éventuellement). Je compte 300 Mo de base + 200 Mo par slot.
- valider tout ça avec le bouton "SELECT"
2) Création de l'instance
- Louer une machine :
- Maintenant il faut chercher en mode "on-demand" la machine de vos rêves et compatible avec votre budget, en fonction des disponibilités du moment
- Vous pouvez utiliser les filtres sur la gauche pour restreindre le choix
- Eviter les machines proposant une bande passante par GPU en dessous de PCIE 3.0 4x, ce sont généralement des machines de mining qui donnent de mauvais résultats avec F@H qui sature le bus PCIE
- La quantité de RAM doit être d'au moins 4 Go par GPU, en dessous il y a des risques de plantages sur des WUs avec beaucoup d'atomes
- Choisir une machine pour laquelle "Max CUDA" est au moins 9.2.
- L'indice DLPerf est un assez bon indicateur de la performance de la machine. Par exemple dans mes tests aujourd'hui, une GTX1070 avait à peu près le même indice qu'une GTX1080Ti, et les deux instances ont effectivement généré les mêmes PPD à l'usage, autour de 1,1M.
- Les prix sont assez aléatoires, et ne reflètent pas forcément la qualité de la machine hôte.
- Cliquer sur "Rent" une fois fait votre choix
- Dans le menu de gauche : CLIENT > Instances. Vous allez voir votre instance passer par les statuts successifs "Inactive", "Creating", "Initializing", puis "Loading".
Si tout va bien elle passe en statut "Successfully loaded gnomuz/fahclient". Si le pourcentage d'utilisation GPU affiché décolle de 0 pour aller tangenter les 100%, c'est gagné, mais ça prend parfois un temps certain, en fonction de la machine, de sa connection internet (elle va télécharger les cores F@H, les WUs, ...). Vous pouvez donc avancer en parallèle sans souci.
Au passage, vous voyez en haut le serveur SSH (adresse et port) qui va nous servir à nous connecter en SSH à la machine, à la contrôler avec FAHControl, et à la monitorer depuis HFM.NET. Exemple : ssh5.vast.ai:28610.
3) Accès et monitoring
- J'utilise Bitvise SSH Client sous Windows pour les connexions SSH plutôt que Putty car il a la possibilité de relancer automatiquement les connexions qui tombent, et les serveurs SSH de vast sont parfois capricieux... Je vous conseille de faire tourner Bitvise sur la même machine que HFM.NET.
- Les étapes principales sont :
- importer ou créer sa clé d'authentification dans l'utilitaire Bitvise "Client Key Manager", la même que celle associée au compte vast au paragraphe 1.
- créer un profil de connexion en renseignant :
- Onglet "Login": "Host" : sshXXX.vast.ai et "Port" le port associés à l'instance (voir sur vast.ai les valeurs assignées à votre instance), Username : root, Initial method : publickey, Client key : choisir la clé importée ou créée
- Onglet "Options": choisir "Automatically reconnect if successful connection breaks"
- Onglet "C2S": créer et activer une entrée "Listen interface" 0.0.0.0, "Listening port" 36331 (ou tout autre port libre sur votre machine locale), "Destination Host" localhost, "Destination port" 36330. Cela crée un tunnel SSH (donc crypté) entre votre machine locale et l'instance vast distante. Une connexion au port 36331 de la machine locale "devient" une connexion au port 36330 (port de gestion habituel de FAHCLient) de l'instance vast.
- Sauvegarder le profil et tenter la connexion en cliquant sur "Log in". Accepter les clés SSH du serveur distant.
- La connexion SSH est maintenant établie, c'est presque fini !
- CLI : dans le menu de gauche, "New terminal console", ça ouvre un terminal classique (tmux) sous Linux, vous avez accès à la ligne de commande sur votre instance. Par exemple, top devrait vous montrer en haut de liste le ou les process FahCore_22 (un par GPU) à 100% de CPU. nvidia-smi vous permet de monitorer le(s) GPU(s) de l'instance (Consommation de courant, température, Utilisation GPU), comme sous Linux ou Windows.
- FAHControl : on va utiliser le tunnel SSH créé avec Bitvise pour se connecter au client F@H. Donc, "Add" pour créer un nouveau client, dans "Address" renseigner le hostname ou l'adresse IP de la machine locale sur laquelle tourne Bitvise, et dans "Port" renseigner 36331 (ou autre port d'écoute choisi pour le tunnel). A partir de là, vous avez accès depuis FAHControl au client F@H distant, vous pouvez tout faire comme d'habitude. En particulier, il est temps de choisir si vous voulez plier avec le slot CPU ou le supprimer. Un détail qui a son importance, si vous avez loué une instance avec par ex. 1 GPU sur une machine qui en propose 4, les 4 GPUs sont visibles depuis le container, mais un seul est utilisable. Donc le client F@H crée 4 slots GPU, un en statut "Running", et les 3 autres en statut "Disabled". Le statut "Disabled" faisant planter HFM.NET (bug), il est nécessaire de supprimer les slots GPU "fictifs" avec FAHControl (Configure, onglet "Slots", "Remove" sur les slots inutiles).
- HFM.NET : même principe que FAHControl, dans "Address" le hostname ou l'IP de la machine Bitvise, "Port" 36331 (ou autre port d'écoute choisi pour le tunnel), et le ou les slots apparaissent gentiment. Et si vous contribuez au monitoring de l'AF, ils seront bien sûr intégrés sans autre manipulation au prochain refresh.
Je pense n'avoir pas oublié grand chose, mais comme d'habitude, il doit en fait manquer pas mal d'infos. Si quelqu'un se lance, qu'il ou elle n'hésite pas, je sais que la rédaction d'un tuto, fut-il sommaire, est la promesse de support par la suite pour pallier tous les oublis
A l'heure où j'écris ces lignes, l'image proposée tourne sur une instance comportant 2 GTX1070, ce qui donne environ 2.3 MPPD, pour un coût de 0,48$ de l'heure, soit à peu près 10€ par jour. En décembre, c'était plus calme, j'ai fait tourner des instances avec 1x 2080Ti pour le même prix, voire moins. J'ai aussi trouvé des 1x 1080Ti à 0.20$/h, soit moins de 5€ par jour.
Sans surprise, les prix sont plutôt mauvais en ce moment, pénurie de GPUs et rentabilité du mining obligent, mais me paraissent moins élevés que ceux de leadergpu. J'ai pris des configs comparables disponibles des deux côtés (prix par jour vast vs leadergpu):
- 1x RTX3090 : 14.50 € vs 34€
- 4x RTX3090 : 74€ vs 111€
- 4x V100 : 62€ vs 195€
Le panel est un peu limité, il n'y a pas de 3070/3080 ou de 2080 Ti dispo pour le moment chez vast, mais ça donne une idée.
Après le niveau de service n'est pas le même, c'est clair. Je ne connaissais pas leadergpu et n'ai pas essayé mais je pense que c'est du cloud computing similaire à Google Cloud Platform ou Azure. Côté vast, il faut comprendre que vast n'a pas de datacenter ou de matériel propre, ce sont des entreprises ou des particuliers qui mettent à disposition moyennant finance des machines dotées de GPUs par l'intermédiaire de vast, qui prend une commission au passage. En clair, vast, c'est le Airbnb du GPU computing. Et donc, la fiabilité de la machine n'est pas du tout assurée comme chez un hébergeur classique, d'où l'importance de ne choisir que des machines avec un taux de "Host reliability" supérieur à 90%, et de ne pas inclure dans ses recherches les "Unverified Machines". vast fait quand même tourner des routines de contrôle et de benchmarking sur les machines inscrites, ce qui leur permet d'afficher pour chacune des indices de fiabilité ("Reliability") et de performance ("DLPerf") assez corrects.
Un dernier point qui a son importance, les principes de facturation:
- Les coûts sont débités en dollars US sur votre CB, attention donc aux frais que votre banquier ne manquera pas de vous facturer pour des paiements non euros. Il vaut mieux charger le compte de 100 USD en une fois que de le charger 10 fois de 10 USD, ce sera moisn couteux en frais.
- Le crédit prépayé qui reste est remis à jour très régulièrement sur le site (quelques secondes), et l'instance s'arrête net quand il tombe à zéro.
- Une instance est facturée tant qu'elle est démarrée, que le client F@H tourne ou pas.
- Lorsqu'on stoppe une instance, elle n'est plus facturée, et son image est préservée. Par contre, la machine redevient disponible à la location, et on n'a donc aucune aucune idée de quand on pourra la récupérer.
- Il y a un coût très minime pour le stockage, qui ne disparait que si l'instance est détruite. Pour 1,15 Go de stockage, le coût est de 0,6 cent par jour !
- Les volumes de données échangées sur internet sont facturés 0,02$/Go. A l'initialisation de l'instance, il y a un peu de volume de téléchargement, le pliage en lui-même, le monitoring distant et les éventuelles sessions CLI consomment très peu
par la suite.
En pratique, je vous conseille donc lorsque vous voulez en terminer avec une instance, par ex. parce que votre crédit va s'épuiser :
- de mettre le(s) slot(s) en "Finish" depuis FAHControl,
- de détruire l'instance ("Destroy") depuis la console vast.ai une fois la WU terminée et le(s) slot(s) en statut "Paused"
Recréer une nouvelle instance par la suite est beaucoup plus simple que la première fois. Il suffit de :
- louer une nouvelle machine
- changer le ssh server et le port associé (ex : ssh4.vast.ai:23612) dans le profil de connexion Bitvise avec les valeurs de la nouvelle instance créée, sauvegarder le profil de connexion, et relancer la connexion ("Log In").
- FAHControl et/ou HFM.NET vont se reconnecter sans autre intervention, puisque le tunnel SSH redevient disponible à la même adresse interne.
Voila, désolé pour ce pavé, mais ceux qui ont eu la patience d'arriver jusqu'ici ont, j'espère, la plupart des infos nécessaires pour se lancer si le cœur leur en dit. Et, au risque de me répéter, n'hésitez pas à me solliciter, il n'y a pas de question bête, et j'ai toujours pensé que les quelques connaissances que je maîtrise n'ont d'intérêt que si elles sont partagées !
PS : pour ceux qui voudraient regarder de plus près ce que je leur propose de faire tourner, et ce serait tout à fait normal, l'adresse du github à partir duquel l'image de dockerhub est construite est
https://github.com/Gnomuz/fahclient . Et toutes les suggestions sont bienvenues, c'est la première fois que je me lance dans la création d'une image docker, j'imagine qu'il y a plein d'optimisations possibles !
