+- Forum Folding@home - Alliance Francophone (https://forum.alliancefrancophone.org)
+-- Forum : Folding@home (https://forum.alliancefrancophone.org/forumdisplay.php?fid=1)
+--- Forum : Aide sur le client Folding@home (https://forum.alliancefrancophone.org/forumdisplay.php?fid=3)
+--- Sujet : Plier dans les nuages ? (/showthread.php?tid=297)
Pages :
1
2
Plier dans les nuages ? - Gnomuz - 26-03-2021
(25-03-2021 22:46:41)Australien a écrit : Personnellement, j'ai voulu suivre cette option > Folding on Cloud instructions (3 mil ppd)
Devant la complexité de la mise en place j'ai reculé et suivi une voie plus facile.(plus onéreuse mais je ne regrette rien et c'est mon argent, pas celui des copains).
Bonjour à tous,
Je me permets d'intervenir bien que ne pliant pas pour la miniteam PCA, mais ayant usé (voire abusé !) des différentes solutions de cloud folding.
Juste pour dire que le guide que tu as mis en lien est remarquable et régulièrement mis à jour par son auteur. Ca peut paraitre abscons ou complexe au premier coup d'œil mais justement c'est parce qu'il a tout détaillé pour quelqu'un qui voudrait se lancer et ne serait pas du tout familier avec la ligne de commande linux (ex : utiliser tab pour terminer une commande, ctrl-o/ctrl-x pour sortir de l'éditeur nano, ...)
Pour avoir mis en oeuvre une VM sur Google Cloud Platform/GCP (GPU T4, puis V100 pour épuiser les 300$ de crédit avant la limite des 90 jours), franchement je n'ai rencontré aucun souci en appliquant le guide. Azure (Cloud Microsoft) c'est une autre paire de manche, nous sommes au moins deux, Totow et moi, à avoir échoué pour de sombre raisons de quotas.
En gros, une machine virtuelle GCP avec un T4 a un coût de 2,5€ par jour, le crédit de 300$ (env. 250€) n'est donc même pas entièrement utilisable dans les 90 jours, pour une production de 1 MPPD. Et en optant pour un V100, c'est un peu moins de 15€ par jour, donc environ 17 jours de pliage avec un bon gros 6 MPPD. En synthèse, dans les deux options, c'est au final entre 90 et 100 MPPD offerts par Google à F@Home, avec un temps de déploiement que je ne vois pas supérieur à une heure en suivant le guide à la lettre, même pour un débutant.
Si cela intéresse, je n'ai pas de souci pour détailler davantage et filer un coup de main à celles et ceux qui auraient envie de se lancer !
Bon pliage à toutes et tous.
RE: Mini-team PC Astuces - GtevoOne82 - 26-03-2021
Salut Gnomuz.
Justement toTOW m'avais mis un lien pour la configuration des 2 plateformes. Vais essayer de mettre la main dessus.
https://github.com/gitHu6-newb/FoldingAtAltitude
Et d'ailleurs il à réussi avec Azure me semble -t-il.
RE: Mini-team PC Astuces - Anonyme - 26-03-2021
Hello
Tout le monde est bienvenu.
Merci Gnomuz, mais la maladie me bouffe ma capacité de concentration, c'est en grande partie pour cela que j'ai abandonné.
Si Gtev m'avait pas assisté la 1ere fois pour un serveur leadergpu.com joignable par le simple RDP Windows, ben je serais encore resté sur le banc de touche..
RE: Mini-team PC Astuces - Gnomuz - 26-03-2021
(26-03-2021 15:28:11)GtevoOne82 a écrit : Salut Gnomuz.
Justement toTOW m'avais mis un lien pour la configuration des 2 plateformes. Vais essayer de mettre la main dessus.
https://github.com/gitHu6-newb/FoldingAtAltitude
Et d'ailleurs il à réussi avec Azure me semble -t-il.
C'est bien à ce guide sur github que je faisais référence, l'auteur est vraiment super soigneux, et très sympa, ce qui ne gâte rien
En fait sur Azure, nous ne sommes pas parvenus à obtenir les quotas nécessaires à la création une VM "Spot" (equiv. "preemptible" chez Google), càd que Azure peut stopper quand ils manquent de ressources. L'avantage de ce type de VM/GPU c'est que le prix de location est de 10% env. du tarif plein pot où les ressources te sont dédiées le temps de la location.
Par contre, on peut aussi facilement que sur GCP monter une VM dédiée. C'est ce que j'ai fini par faire afin d'utiliser mon crédit de 200$, mais les 200$ ont duré une petite semaine de mémoire. Et j'ai compris d'un de ses posts sur le forum F@H que toTOW a fini par faire la même chose en désespoir de cause.
RE: Plier dans les nuages ? - JWhy - 26-03-2021
D'ailleurs, Gtev, ce tuto pour leaderGPU, il arrive bientôt ?
RE: Plier dans les nuages ? - Anonyme - 26-03-2021
Hello JWhy
la précision Suisse n'est plus ce qu'elle était, je vous le dis mon Brave Monsieur "tout se perd"
PS : merci pour ta veille et la bascule de cette discussion sur un topic dédié.
RE: Plier dans les nuages ? - GtevoOne82 - 26-03-2021
Oui je vais le faire comme il le faut.
Promis lors de ma prochaine prise de serveur.
Pas toujours le temps, mais je vais le trouver .
Merci JWhy pour le déplacement . Bien joué
RE: Plier dans les nuages ? - Gnomuz - 31-03-2021
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-home-on-vast-ai-automatic-configuration-and-local-management-fdf4f4c2f098
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
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.
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€
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"
- 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.
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 !
RE: Plier dans les nuages ? - GtevoOne82 - 31-03-2021
Merci pour toutes ces informations Gnomuz.
Très bien expliqué
RE: Plier dans les nuages ? - Gnomuz - 06-04-2021
Bonjour à tous,
J'ai mis à jour l'image sur docker hub :
- passage sur Ubuntu 18.04, qui est en principe l'OS des machines hôtes vast,
- utilisation de CUDA 9.2 afin d'être compatible avec le plus grand nombre de machines, même pas très à jour (!)
- intégration du script 'fah_autorun.sh' à l'image, ce qui permet d'avoir un startup script un peu plus simple
- diminution de la taille de l'image à 55 Mo
Le message initial a été modifié en conséquence