Bonjour,
J'envisage de protéger des serveurs distants (de type NUC) avec un
"onduleur administrable". Mon objectif est d'éviter d'endommager un
disque (toujours de type SSD ou NVMe) Ã cause d'une coupure brutale de courant.
aptitude show nutPaquet : nut
Bonjour,
J'envisage de protéger des serveurs distants (de type NUC) avec un
"onduleur administrable". Mon objectif est d'éviter d'endommager un
disque (toujours de type SSD ou NVMe) Ã cause d'une coupure brutale de courant.
J'accepte que les services soient interrompus tant que dure la panne
de courant mais j'aimerai qu'idéalement, les services redémarrent sans intervention humaine quand le courant revient (si par chance, celui-ci
devait revenir sans action humaine).
Imaginons qu'un serveur distant protégé par cet onduleur
administrable, reçoive de ce dernier ou d'ailleurs, la notification
d'une panne de courant prolongée.
Quelle commande d'extinction-hibernation doit-il émettre afin :
1- qu'il consomme le minimum d'énergie tant que dure la panne de courant
2- qu'il re-démarre dès que le courant revient.
J'ai vu dans le BIOS une option "After Power Failure: Stay Off/Power
On Normal Boot/Power On PXE". Je l'ai essayé mais elle ne fonctionne
après une commande poweroff, ce qui me semble logique.
Une idée ?
Slts
À l’époque, j’avais un onduleur qui acceptait de causer avec nut.
nicolas.patrois@gmail.com a écrit :
https://wiki.ipfire.org/addons/nut/detailed
Le ven. 4 mars 2022 à 23:54, Sébastien Dinot <sebastien.dinot@free.fr> a écrit :Oui
nicolas.patrois@gmail.com a écrit :Je vais de ce pas étudier ce doc.
https://wiki.ipfire.org/addons/nut/detailed
Pour moi, avant de lire ce doc, le mystère c'est "arrêter le système proprement" et "démarrer quand le courant revient".
Est-ce que l'option du BIOS "AfterPower Failure: Power On" correspond
à "démarrer quand le courant revient" ?
Signifie-t-elle que si pour une raison quelconque, je souhaiteNon. Dans la conf de nut tu dis ce qu'il faut faire lorsque l'onduleur
éteindre le serveur, je dois arrêter ses services puis couper l'alimentation par une action sur l'onduleur et non sur l'hôte
lui-même ?
Si c'est le cas, cela implique-t-il qu'a minima, l'onduleur doive être pilotable par deux hôtes "indépendants" (un pour allumer l'hôte quiTout dépend: si tu es connecté en USB ou série un seul serveur est
est éteint) ?
Bonjour,batterie de l'onduleur, ton ordinateur ne sera pas coupé électriquement. Tu va devoir passer par un wakeonlan. Vérifie également que ton onduleur redémarre automatiquement au retour du secteur, ce n'est pas toujours le cas.
En fait tu n'aura peut-être jamais de coupure de courant sur ton ordinateur. Je m'explique, coupure secteur, l'onduleur prend le relais. Quand sa batterie va baisser, il va envoyer ton ordinateur va s'arrêter. Si le courant revient avant la fin de
Benoît
@Benoit:
C'est toute la question !
La doc de NUT détaille l'arrêt propre (par défaut à base de shutdown) mais pour le démarrage "automatique": il n'y a rien.
Je ne sais pas si le Wake-on-LAN est nécessaire pour démarrer même si jepense que non, d'après les message de Daniel et Sébastien.
À ce stade, je pense que j'ai besoin d'un onduleur:
- d'un onduleur
- capable d'arrêter ou démarrer individuellement ou successivement deux prises de courant (une prise pour les équipements vitaux
nécessaires au démarrage, une autre pour d'autres équipements
secourus)
- capable de communiquer par le réseau (ou par USB avec un Pi sur lequel NUT est installé), pour l'arrêt propre des machinesTout à fait. Et si le courant revient avant l'extinction de l'onduleur principal il n'y a rien à faire. Sauf dans mon cas ou je dois redémarrer
- de serveurs:
- capables d'exécuter les commandes d'arrêt (émises par l'onduleur
ou ses relais)
- capables de démarrer seuls quand le courant revient ( l'option
du BIOS "AfterPower Failure: Power On" ).
@Benoit:Si tu es parti pour installer un Pi ( alimenté jusqu'à ce que mort s'en
C'est toute la question !
La doc de NUT détaille l'arrêt propre (par défaut à base de shutdown) mais pour le démarrage "automatique": il n'y a rien.
Je ne sais pas si le Wake-on-LAN est nécessaire pour démarrer même si jepense que non, d'après les message de Daniel et Sébastien.
À ce stade, je pense que j'ai besoin d'un onduleur:
- d'un onduleur
   - capable d'arrêter ou démarrer individuellement ou
successivement
deux prises de courant (une prise pour les équipements vitaux
nécessaires au démarrage, une autre pour d'autres équipements
secourus)
   - capable de communiquer par le réseau (ou par USB avec un Pi sur lequel NUT est installé), pour l'arrêt propre des machines
- de serveurs:
   - capables d'exécuter les commandes d'arrêt (émises par
l'onduleur
ou ses relais)
   - capables de démarrer seuls quand le courant revient ( l'option
du BIOS "AfterPower Failure: Power On" ).
En fait tu n'aura peut-être jamais de coupure de courant sur ton
ordinateur. Je m'explique, coupure secteur, l'onduleur prend le
relais. Quand sa batterie va baisser, il va envoyer ton ordinateur va s'arrêter. Si le courant revient avant la fin de batterie de
l'onduleur, ton ordinateur ne sera pas coupé électriquement. Tu va
devoir passer par un wakeonlan.
Bonsoir,
Benoît SZCZYGIEL a écrit :
En fait tu n'aura peut-être jamais de coupure de courant sur ton
ordinateur. Je m'explique, coupure secteur, l'onduleur prend le
relais. Quand sa batterie va baisser, il va envoyer ton ordinateur va
s'arrêter. Si le courant revient avant la fin de batterie de
l'onduleur, ton ordinateur ne sera pas coupé électriquement. Tu va
devoir passer par un wakeonlan.
Voilà un cas de figure auquel je n'avais pas pensé et sur lequel je ne
suis jamais tombé. Il mérite réflexion.
Dans l'idéal, c'est l'onduleur qui devrait adapter son fonctionnement au
cas de figure. En effet, les machines auxquelles l'information est
diffusée ne s'arrêtent pas lorsque l'onduleur annonce avoir basculé sur batterie, mais lorsqu'il annonce que sa batterie est faible (et ne va
donc plus tenir très longtemps). Lorsque le courant revient, l'onduleur
sait s'il a déjà diffusé ou non le message déclenchant l'arrêt des machines. Par conséquent, si le courant revient avant qu'il ait envoyé
ce message, l'onduleur n'a rien de particulier à faire si ce n'est
signaler le retour du courant. Mais si le courant revient après l'envoi
du message de batterie faible, l'onduleur devrait couper momentanément
le courant sur les prises secourues, puis le restaurer, provoquant ainsi
le reboot des machines. Je viens de parcourir la (maigre) documentation
de mon onduleur et je n'ai trouvé aucun paramétrage de la sorte.
Dommage...
Quant à la fonction WAL, il n'est pas forcément nécessaire de disposer d'une machine non secourue pour pouvoir l'utiliser. En ce qui me
concerne, j'ai activé la fonction « Proxy WAL » sur ma Freebox. Du coup, lorsque je ne suis pas chez moi, je peux déclencher le boot de mes
machines à distance à partir du moment où la Freebox, le switch et les machines sont alimentées en courant. Depuis mon poste de travail ou une autre machine accessible sur Internet, je peux lancer la commande :
wakeonlan -i <adresse-publique-freebox> <adresse-mac-machine>
Et la machine correspondante boote.
Sébastien
Je vends des onduleurs (y compris des gros, plusieurs dizaines de
milliers de watts). Je n'en ai jamais vu ayant le comportement que tu décris.
En même temps, si ton besoin est vraiment critique, en général, il
y a un informaticien pas trop loin.
Le comportement décrit dans la section 3.6.3 du document suivant ne fournit-il pas une réponse efficace au problème évoqué ?
Mon objectif est d'éviter d'endommager un disque (toujours de type SSD ou NVMe) à cause d'une
coupure brutale de courant.
Bonjour,
J'envisage de protéger des serveurs distants (de type NUC) avec un "onduleur administrable". Mon objectif est d'éviter d'endommager un
disque (toujours de type SSD ou NVMe) Ã cause d'une coupure brutale de courant.
J'accepte que les services soient interrompus tant que dure la panne
de courant mais j'aimerai qu'idéalement, les services redémarrent sans intervention humaine quand le courant revient (si par chance, celui-ci devait revenir sans action humaine).
Imaginons qu'un serveur distant protégé par cet onduleur
administrable, reçoive de ce dernier ou d'ailleurs, la notification
d'une panne de courant prolongée.
Quelle commande d'extinction-hibernation doit-il émettre afin :
1- qu'il consomme le minimum d'énergie tant que dure la panne de courant
2- qu'il re-démarre dès que le courant revient.
J'ai vu dans le BIOS une option "After Power Failure: Stay Off/Power
On Normal Boot/Power On PXE". Je l'ai essayé mais elle ne fonctionne
après une commande poweroff, ce qui me semble logique.
Une idée ?
Slts
Comme déjà proposé, nut permet la gestion des onduleurs en USB, série ou ethernet.
Le 04/03/2022 à 17:21, Olivier a écrit :
Bonjour,
J'envisage de protéger des serveurs distants (de type NUC) avec un "onduleur administrable". Mon objectif est d'éviter d'endommager un
disque (toujours de type SSD ou NVMe) Ã cause d'une coupure brutale de courant.
J'accepte que les services soient interrompus tant que dure la panne
de courant mais j'aimerai qu'idéalement, les services redémarrent sans intervention humaine quand le courant revient (si par chance, celui-ci devait revenir sans action humaine).
Imaginons qu'un serveur distant protégé par cet onduleur
administrable, reçoive de ce dernier ou d'ailleurs, la notification
d'une panne de courant prolongée.
Quelle commande d'extinction-hibernation doit-il émettre afin :
1- qu'il consomme le minimum d'énergie tant que dure la panne de courant 2- qu'il re-démarre dès que le courant revient.
J'ai vu dans le BIOS une option "After Power Failure: Stay Off/Power
On Normal Boot/Power On PXE". Je l'ai essayé mais elle ne fonctionne après une commande poweroff, ce qui me semble logique.
Une idée ?
Slts
Bonjour,
Je reviens sur ce thread parce que :
Le 04/03/22 à 17:21, Olivier <oza.4h07@gmail.com> a écrit :
Mon objectif est d'éviter d'endommager un disque (toujours de type SSDou NVMe) à cause d'une
coupure brutale de courant.
m'étonne un peu.
Un disque ssd est vraiment sensible à une coupure brutale ?
Je me souviens™ du devoir de parquer les disques avant d'éteindre un PC, mais c’était au siècle
dernier !
Assez rapidement les constructeurs ont ajoutés du park auto à l’extinction
(j’imagine le nb de
plaintes qu’ils ont eu de gens ayant dépensé des fortunes pour un hd, parti en fumée parce que
qqun avait déplacé un PC éteint), puis du park auto à la coupure de courant (ils ont réinventé
le ressort).
Depuis les ssd y’a plus de tête risquant de se retrouver au mauvais endroit au mauvais moment,
donc en cas de coupure de courant je veux bien qu’il y ait un risque sur les datas (et encore,
avec les fs journalisés ça devrait plus trop être le cas), mais un risque sur le matériel ?
C’est toujours d’actualité ?
Si oui faut vraiment que je m’inquiète car sur mon PC actuel j’ai du reboot hard ~3×/semaine
depuis 1an 1/2, du "recovered inode" à chaque reboot après un plantage, mais heureusement les
disques sont toujours là (un nvme et un disque HD classique à plateaux, moins sollicité).
Rien d’ironique, je suis une buse en hardware et peux très bien avoir de fausses idées reçues,
si qqun qui sait peut confirmer / infirmer ça m’intéresse.
PS: ça ne remet pas en cause l’intérêt d’un onduleur, mais pour du NAS perso, ça me paraît un
peu overkill (je ne parle pas du coût environnemental, changer les
batteries tous les 2ans,
toussa, juste du coût humain pour s’occuper de l’onduleur et sa communication avec la machine,
plutôt que de laisser la machine redémarrer toute seule quand le courant revient).
--
Daniel
Lorsque j'ai été kidnappé, ma mère a réagi tout de suite: elle a sous-loué
ma chambre.
Woody Allen
Bonjour,
Je reviens sur ce thread parce que :
Le 04/03/22 à 17:21, Olivier <oza.4h07@gmail.com> a écrit :
Mon objectif est d'éviter d'endommager un disque (toujours de type SSD ou NVMe) à cause d'une
coupure brutale de courant.
m'étonne un peu.
Un disque ssd est vraiment sensible à une coupure brutale ?
Je me souviens™ du devoir de parquer les disques avant d'éteindre un PC, mais c’était au siècle
dernier !
Je suis par contre assez surpris de lire que tu as besoin de fsck régulièrement vu que (selon moi, c'est pas une vérité gravée dans le marbre
; ) le problème est forcément lié à l'écriture et que les systèmes n'écrivent pas grand chose hormis leurs logs
Le 15/03/22 Ã 10:33, Mathias Dufresne <mathias.dufresne@gmail.com> a
écrit :
Je suis par contre assez surpris de lire que tu as besoin de fsck régulièrement vu que (selon moi, c'est pas une vérité gravée dans lemarbre
; ) le problème est forcément lié à l'écriture et que les systèmes n'écrivent pas grand chose hormis leurs logs
Je sais pas si c'est fsck, mais il scanne pas le FS (ça prend qq ms lors
du boot), je pensais
que c'était juste le journal du FS qui avait encore dans son buffer des données non écrites, et
qu'il commençait par les écrire à leur place avant de monter le filesystem, d'où les messages
"recovered inode …".
--
Daniel
L'idée d'une armée européenne est vraiment intéressante,
mais pourquoi ne pas aller plus loin en créant une armée
mondiale dont le principal intérêt serait qu'elle n'aurait
pas d'ennemis.
Philippe Geluck, Le chat
Le 2022-03-15 10:16, Mathias Dufresne a écrit :
Une option peut être le wake-on-lan si le problème du redémarrage automatique ne fonctionne pas. Malheureusement ça nécessite une machine allumée donc soit par un démarrage manuelle, soit une machine qui
arrive a se réveiller toute seule après retour de l'électricité. P't'être même qu'un vieux PC qui s'allume quand le courant revient pour lancer des paquets wake-on-lan et qui s'éteigne une fois sa tâche terminée pourrait faire l'affaire : à la fin de la prochaine coupure, cette machine devrait se réveiller et lancer les paquets...
Sur mon onduleur, j'ai :
* des prises secourues et qui offrent une protection contre la foudre ;
* des prises *non* secourues, qui offrent une protection contre la
foudre.
Je pense qu'en branchant sur une prise *non* secourue une carte
minimaliste, du genre Raspberry Pi Zero W :
https://www.kubii.fr/cartes-raspberry-pi/1851-raspberry-pi-zero-w-kubii-3272496006997.html
On peut aisément – et à moindre cout – fournir le service attendu.
Si le wifi n'est pas disponible, il faudra opter pour un modèle plus « luxueux » (au regard de l'usage qui en est fait), disposant d'une
interface Ethernet, du genre Raspberry Pi 3 :
https://www.kubii.fr/home/1628-raspberry-pi-3-modele-b-1-gb-kubii-5060214370264.html
Il semblerait que l'on puisse même faire cela avec un simple ESP32 :
https://github.com/mkttanabe/ESP32_WakeOnLan
Sébastien
--
Sébastien Dinot
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer ! https://www.palabritudes.net/
Suite à une nouvelle sollicitation, je déterre ce vieux fil de discussion.
J'ai expérimenté avec un NUC, dont l'option After Power Failure du
BIOS était valorisée à Last Stateroot
1. J'exécute echo freeze > /sys/power/state
La machine s'arrête (brutalement, semble-t-il)
Je débranche puis rebranche l'alimentation (comme si un onduleur l'avait fait)
Le serveur démarre avec un boot quasi normal car il affiche
"Recovering journal".
2. Idem avec echo standby > /sys/power/state
3. L'option After Power Failure est changée à StayOn et l'hibernation
est déclenché par poweroff.
La machine est dans un état inabituel: le bouton power reste allumé
mais l'écran est quasi-vide (un simple tiret en haut à gauche).
Je débranche puis rebranche l'alimentation (comme si un onduleur l'avait fait)
Le serveur démarre avec un boot normal (il n'affiche pas "Recovering journal").
A. Existe-t-il une commande ou option de configuration sous Linux pour
que le passage à l'état freeze évite le "Recovering journal" ? Qu'en pensez-vous ?
B. Comme l'a pointé Sébastien, un point important dans mon scenario
est que dans tous les cas, l'onduleur coupe le courant en aval une
fois qu'il a avertit d'une coupure puis respecte une temporisation
avant de le rétablir en avant, même si le courant en amont est revenu
la coupure en aval.
Si tu peux exécuter une commande avant, un 'sync' devrait déja
améliorer la situation.
Il est peut-être possible de forcer le système à vider ses caches très régulièrement, mais ce n'est clairement pas propre.
On 20/10/2022 21:08, Th.A.C wrote:
Si tu peux exécuter une commande avant, un 'sync' devrait déja
améliorer la situation.
Il est peut-être possible de forcer le système à vider ses caches très régulièrement, mais ce n'est clairement pas propre.
Pourquoi ne serait-ce pas propre?
Pour ceux que ça intéresse, j'ai codé en C un petit utilitaire (sous licence GPLv3+) qui appelle sync périodiquement:
https://github.com/bstarynk/misc-basile/blob/master/sync-periodically.c
(et je cherche des partenaires intéressés par un consortium
HorizonEurope ou ANR finançant et utilisant le logiciel d'IA symbolique RefPerSys en http://refpersys.org/ - qu'ils me contactent par courriel
aussi au bureau, CEA LIST, en basile.starynkevitch@cea.fr ....)
--
Basile Starynkevitch <basile@starynkevitch.net>
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/
Côté serveur, je pense utiliser la combinaison "After Power Failure valorisée à StayOn /arrêt par Poweroff".
Pour éteindre mon serveur, il faut lui demander de s'arrêter puis
quelques secondes après lui couper sa prise de courant.
Pour le remettre en service, il faut et il suffit "d'allumer" sa prise
de courant.
Côté onduleur, il me faudrait un onduleur, outre ses qualités propres (puissance, facilité d'entretien des batteries, ...):
A- qui sache immédiatement notifier un arrêt du courant en amont
B- qui sache notifier avec un certain retard un rétablissement du
courant en amont (*)
C- qui sache alerter un serveur quand son niveau de batterie passe
sous un certain seuil et sache arrêter des prises de courant en aval,
un certain temps après l'envoi d'alerte (tant pis si l'alerte n'a pas
été reçue ou si courant en amont est revenu entre temps)
D- qui sache rétablir des prises de courant en aval quand le courant
en amont est revenu et quand la batterie est au dessus d'un certain
seuil.
Avec une interface Ethernet sur l'onduleur, les notifications
pourraient s'opérer par courriel et les alertes par SNMP ou autre
(HTTP ?). Il resterai à vérifier que les exigences ci dessus soient satisfaites.
La A me parait facile à satisfaire.
La B n'est pas si importante que cela.
La C et la D me paraissent difficile à lire sur une datasheet.
Peut-être qu'en consultant un manuel ?
(*) Si je n'ai pas de réseau hors bande, il est probable que les
moyens de transmissions des notifications ne soient pas encore
rétablis quand le courant en amont vient juste de se rétablir
Le jeu. 20 oct. 2022 à 21:16, Basile Starynkevitch <basile@starynkevitch.net> a écrit :
On 20/10/2022 21:08, Th.A.C wrote:
Si tu peux exécuter une commande avant, un 'sync' devrait déja améliorer la situation.
Il est peut-être possible de forcer le système à vider ses caches très
régulièrement, mais ce n'est clairement pas propre.
Pourquoi ne serait-ce pas propre?
Pour ceux que ça intéresse, j'ai codé en C un petit utilitaire (sous licence GPLv3+) qui appelle sync périodiquement:
https://github.com/bstarynk/misc-basile/blob/master/sync-periodically.c
(et je cherche des partenaires intéressés par un consortium
HorizonEurope ou ANR finançant et utilisant le logiciel d'IA symbolique RefPerSys en http://refpersys.org/ - qu'ils me contactent par courriel aussi au bureau, CEA LIST, en basile.starynkevitch@cea.fr ....)
--
Basile Starynkevitch <basile@starynkevitch.net>
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/
Olivier a écrit :
Dans la documentation Eaton, je découvre le paramètre Redémarrage forcé, qui activé, me semble bien correspondre à l'exigence C
Ça m'intéresse. Où as-tu trouvé cette information ? Pour ma part, je
n'ai jamais trouvé mieux qu'un succinct manuel en 9 pages.
Sébastien
--
Sébastien Dinot, sebastien.dinot@free.fr
http://www.palabritudes.net/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 79:52:14 |
| Calls: | 6,658 |
| Calls today: | 4 |
| Files: | 12,203 |
| Messages: | 5,333,178 |
| Posted today: | 1 |