Forum général.général Arrêter / Allumer un serveur quotidiennement : problèmes ?

Posté par  .
Étiquettes : aucune
0
30
avr.
2010
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  . Évalué à 6.

    Pour faire une pause, la virtualisation c'est top.

    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  (site web personnel) . Évalué à 1.

      Non, quand tu as une plateforme de calcul, tu ne fait pas de la virtualisation.
      Le processeur est la ressource que tu ne veux pas partager entre les noeuds.

      Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

    • [^] # Re: Pause = virtualisation

      Posté par  . Évalué à 0.

      Il veut faire une économie d'énergie! Donc éteindre ces machines ou même les mettre en mode veille.
      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  . Évalué à 2.

        Il veut faire une économie d'énergie! Donc éteindre ces machines ou même les mettre en mode veille.

        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  . Évalué à 5.

    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.

    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  . Évalué à 3.

      Grillé ....

      Mais est qu'un simple "ctrl+z" ne suffirait pas ?

      • [^] # Re: Une VM

        Posté par  . Évalué à 4.

        Bonjour,

        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  . Évalué à 2.

      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).

      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  . Évalué à 4.

        Bah oui, mais c'est moins pratique à migrer: il faut se lever, dévisser le rack, sortir le serveur, l'apporter dans l'autre pièce, revisser le rack, appuyer sur le bouton. Alors qu'avec une VM, une petite commande bien sentie (ou alors un coup de clicodrome), et tout roule...

  • # la virtualisation est une très bonne idée

    Posté par  . Évalué à 2.

    Comme ça ce qui devait prendre 13h en natif prendra 24h dans ta VM, et tu n'auras plus de questions à te poser.

  • # OpenVZ

    Posté par  (site web personnel) . Évalué à 3.

    OpenVZ est une technique de virtualisation de niveau système d'exploitation basée sur le noyau Linux.
    et ça prend très peu de ressources pour gérer tout ça.

  • # Plutôt que de sortir l’artillerie lourde…

    Posté par  . Évalué à 2.

    Comme déjà dit C-z marche très bien. Il y a aussi nice qui peut être noté, l’avantage est qu’on n’a plus à s’en préoccuper, le système allouera du cpu quand il sera libre.

    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).

  • # acpi

    Posté par  . Évalué à 2.

    Sinon avec l'acpi (rtc) tu peux programmer une date de réveil des pc.
    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  (site web personnel) . Évalué à 2.

      Si ce sont des serveurs, normalement avec IPMI, on les réveille proprement à distance.

      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  . Évalué à 2.

    Merci pour vos conseils!

    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.