Bonjour à tous,
Nous sommes en train d'étudier une solution à base de cluster pour une plateforme de calcul de météo/chimie.
Les serveurs ne calculeraient en gros que 13h sur 24 et resteraient allumés le reste du temps à ne rien faire. Ca fait quand même quelque chose comme 8 serveurs qui tirent sur le courant pour rien.
Une solution serait peut être de faire du "wake up on lan" avant de lancer les jobs pour n'avoir les machines que lorsque c'est nécessaire.
Avez vous une expérience sur ce genre d'idée/problème ? Pensez vous qu'allumer / éteindre les machines tous les jours pourrait présenter des problèmes ? (usure ?)
Il est également possible que nous fassions tourner une autre application pendant les pauses de calcul. Malheureusement le temps d'exécution de cette seconde appli est supérieure à la durée des pauses quotidiennes de la plateforme et l'appli n'est pas conçue pour être arrêtée en cours de calcul. Je cherche donc une solution pour "embarquer" la seconde appli dans un environnement que je puisse mettre sur pause (si ça existe) et qui n'ai pas trop d'impact sur les performances.
Nous n'avons pas beaucoup d'expérience sur les cluster, mais j'imagine que d'autres personnes se sont déjà posé la question (google n'est pas trop au courant ou j'ai mal formulé ma recherche)
Bon week end !
Raph
# Pause = virtualisation
Posté par Kerro . Évalué à 6.
Sinon pour un système complet: http://www.tuxonice.net/ (jamais testé)
et pour un programme seul: http://cryopid.berlios.de/ http://code.google.com/p/cryopid/ pas mal, mais instable avec des applications complexes (probablement ok pour du calcul)
[^] # Re: Pause = virtualisation
Posté par lolop (site web personnel) . Évalué à 1.
Le processeur est la ressource que tu ne veux pas partager entre les noeuds.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Pause = virtualisation
Posté par NickNolte . Évalué à 0.
Et ce sont des machines de calculs, la virtualization c'est pas un choix judicieux pour cet usage.
Si vous avez une interface iLO (light out management), il est possible de faire ce que veut faire le Raphaël.
[^] # Re: Pause = virtualisation
Posté par teoB . Évalué à 2.
Vu que Kerro a commencé par Pour faire une pause, je pense qu'il répondait plutôt au deuxième usage possible de la ferme de calcul : Il est également possible que nous fassions tourner une autre application pendant les pauses de calcul. Malheureusement le temps d'exécution de cette seconde appli est supérieure à la durée des pauses quotidiennes de la plateforme et l'appli n'est pas conçue pour être arrêtée en cours de calcul..
# Une VM
Posté par William Briand . Évalué à 5.
Dans machine virtuelle, il est tout à fait possible de mette en pause le système complet, et aussi de le transférer vers une autre machine, puis de le remettre en route (migration).
[^] # Re: Une VM
Posté par William Briand . Évalué à 3.
Mais est qu'un simple "ctrl+z" ne suffirait pas ?
[^] # Re: Une VM
Posté par pma . Évalué à 4.
C'est les signaux SIGSTOP/SIGCONT que tu peux envoyer avec la commande kill au processus et ses sous-processus. C'est un peu artisanal et ça ne libère pas toutes les ressources (mémoire entre autres) qui pourraient faire défaut à l'autre application.
L'idéal est de faire du checkpointing de ton application. T'es pas forcément obligé de modifier ton programme (même si ça permet de faire les choses plus finement). Après tu peux aussi mettre dans une VM comme précisé par ailleurs.
Enfin, pour le reboot des serveurs. Je pense que les redémarrage trop fréquents doivent toujours êtres contre-indiqués par les constructeurs mais j'ai vu des clusters entiers utiliser cette technique sans soucis majeur. Il y a plusieurs techniques pour le faire: WoL, horloge RTC, fonctions IPMI (qui font plein d'autres choses intéressantes pour un cluster au passage). Il est probable qu'un bon job scheduler réponde en grande partie à ton problème.
Paul
[^] # Re: Une VM
Posté par Jllc . Évalué à 2.
Un serveur réel sous Linux peut aussi être mis en veille, comme un poste de travail. Par contre, je ne saurais s'il peut être sorti de sa veille par le réseau.
[^] # Re: Une VM
Posté par William Briand . Évalué à 4.
# la virtualisation est une très bonne idée
Posté par neologix . Évalué à 2.
[^] # Re: la virtualisation est une très bonne idée
Posté par William Briand . Évalué à 4.
# OpenVZ
Posté par err404 (site web personnel) . Évalué à 3.
et ça prend très peu de ressources pour gérer tout ça.
# Plutôt que de sortir l’artillerie lourde…
Posté par nicolas . Évalué à 2.
S’il y a un problème de mémoire, il suffit d’allouer un swap suffisamment grand, le système devrait mettre en swap la mémoire de l’application en pause (avec une petite phase de transition au pire, là pour le coup j’éviterai nice, car au moindre réveil il faudra faire de l’entrée sortie avec le disque dur).
[^] # Re: Plutôt que de sortir l’artillerie lourde…
Posté par M . Évalué à 2.
[^] # Re: Plutôt que de sortir l’artillerie lourde…
Posté par yellowiscool . Évalué à 2.
Envoyé depuis mon lapin.
[^] # Re: Plutôt que de sortir l’artillerie lourde…
Posté par Raphaël . Évalué à 1.
Par contre je n'avais pas du tout pensé à nice, c'est une excellente idée !
# acpi
Posté par M . Évalué à 2.
Donc si les taches sont à heure fixe, tu peux programmer un script cron qui programme le réveil juste avant d'éteindre la machine.
[^] # Re: acpi
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Sinon, pour votre problématique, vous pourriez avoir un dom0 Xen par machine physique, mettre en pause le domU celle concernant votre appli lors des gros calculs sur un autre domU et si un dom0 n'a plus de domU d'actif de l'arrêter.
Vous auriez une machine maitre qui réveillerait tout cela par IMPI puis via les dom0, vous prendriez le controle des appli à la carte.
# Finalement
Posté par Raphaël . Évalué à 2.
Nous allons certainement faire des tests autour de la virtualisation pour suspendre l'appli A pendant que l'appli B s'exécute. Comme ça nous donne la possibilité d'exécuter l'appli A sur le cluster plutôt que sur une machine unique comme prévu au début, le gain de performance devrait contre balancer l'impacte négatif sur le temps de calcul de la virtualisation.
Je vois un futur rempli de longues périodes de tests avant d'avoir une solution stable et maitrisée ;-)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.