Comment éteindre un serveur proprement pour permettre le redémarrage automatique ?

[Olivier]

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

[Sabri KHEMISSA]

Bonjour,

Une bonne question !

A chaud, je dirai qu'il faut trouver le moyen de pooler l'onduleur afin de disposer de son état. En fonction de son état, des actions spécifiques peuvent être réalisées.

Idéalement:

- Un serveur pool périodiquement l'onduleur, par exemple via SNMP.

- Si une panne électrique est remontée, un poweroff est lancé sur l'ensemble des serveurs via ssh, mieux avec ansible qui dispose déjà d'un plugin https://docs.ansible.com/ansible/latest/collections/community/general/shutdown_module.html

Concernant ton serveur de pool :

- Tu peux décider de l'arrêter à la fin de l'arrêt des autres serveurs. L'option du BIOS permettra de démarrer le serveur. je pense que le processus n'est pas vraiment sous contrôle, car il dépend de paramètres qui ne sont pas maitrisés de bout en bout.

ou

- Le garder démarré, il continue à pooler ton onduleur. Dès que le courant est rétabli, il démarre les serveurs via Wake On LAN. Ce serveur de pool peut être un simple rasp (pour économiser l'onduleur)... et dans le pire des cas, l'option du Bios le redémarrera et le pooling repartira.

Pour échange,

/S.

[nicolas...@gmail.com]

Le 04/03/2022 17:21:22, 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.

À l’époque, j’avais un onduleur qui acceptait de causer avec nut.
> aptitude show nut
Paquet : nut
Version : 2.7.4-14
Nouveau: oui
État: non installé
Priorité : optionnel
Section : metapackages
Responsable : Laurent Bigonville <bi...@debian.org>
Architecture : all
Taille décompressée : 276 k
Dépend: nut-client, nut-server
Description : outils UPS pour réseau – métapaquet
Network UPS Tools (NUT) est un système de surveillance client/serveur permettant à des ordinateurs de partager une
alimentation électrique sans interruption (UPS) et une unité matérielle de distribution d’énergie (PDU). Les
clients ont accès au matériel grâce au serveur, et reçoivent des annonces sur toutes modifications de l’état de
l’alimentation.

Ce paquet est un métapaquet qui installe à la fois nut-server et nut-client. Dans la plupart de cas, il est
suffisant pour un système de surveillance d'onduleurs basique.
Site : https://networkupstools.org/
Étiquettes: admin::monitoring, hardware::power, hardware::power:ups, interface::daemon, network::server,
role::program, scope::utility

nicolas patrois : pts noir asocial
--
RÉALISME

M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? Un cerveau plus gros ?
P : Non... Une carte bleue suffirait...

[NoSpam]

Comme déjà proposé, nut permet la gestion des onduleurs en USB, série ou
ethernet.

[Sébastien Dinot]

nicolas...@gmail.com a écrit :

> À l’époque, j’avais un onduleur qui acceptait de causer avec nut.

Je dispose d'un onduleur Eaton Ellipse Pro 1200, connecté à mon serveur
via un câble USB. Le service « nut-driver » communique avec l'onduleur.
Lorsque l'onduleur n'est plus alimenté, il notifie le serveur. Celui-ci
ne réagit pas à ce stade, il se contente de relayer l'information
localement et aux clients (tout comme il notifie toute perte de
connexion avec l'onduleur). Lorsque sa batterie faiblit, l'onduleur
envoie un message différent au serveur et ce dernier s'arrête
proprement. Sur mon poste de travail, j'ai installé le client NUT. Il se
connecte au serveur NUT (et non à l'onduleur) qui relaie les messages de
l'onduleur.

Quant au BIOS de mon serveur, il est configuré pour booter lorsque le
courant revient.

La page ci-dessous donne des exemples de configuration des commandes
à exécuter en fonction des évènements :

https://wiki.ipfire.org/addons/nut/detailed

Il est donc possible de prévoir une commande faisant passer le serveur
en mode de fonctionnement minimal lorsque l'onduleur est sur batterie,
et de le ramener à son mode de fonctionnement normal lorsque le courant
revient.

Sébastien

--
Sébastien Dinot, sebasti...@free.fr
http://www.palabritudes.net/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !

[NoSpam]

Bonjour

Le 07/03/2022 à 09:32, Olivier a écrit :
> Le ven. 4 mars 2022 à 23:54, Sébastien Dinot <sebasti...@free.fr> a écrit :
>> nicolas...@gmail.com a écrit :
>>
>> https://wiki.ipfire.org/addons/nut/detailed
>>
> Je vais de ce pas étudier ce doc.
>
> 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" ?
Oui
> Signifie-t-elle que si pour une raison quelconque, je souhaite
> é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 ?
Non. Dans la conf de nut tu dis ce qu'il faut faire lorsque l'onduleur
est vide: shutdown -h now => tous les services sont coup;es proprement.
Lorsque le courant revient, la fonction BIOS démarre le serveur et le
tour est joué.
> 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 qui
> est éteint) ?
Tout dépend: si tu es connecté en USB ou série un seul serveur est
connecté à l'onduleur. Tu peux toutefois envoyer l'info à d'autres
machines via des scripts. Si l'onduleur est sur le réseau, toute machine
du réseau sera informée.
--
Daniel

[Olivier]

Le ven. 4 mars 2022 à 23:54, Sébastien Dinot <sebasti...@free.fr> a écrit :
>
> nicolas...@gmail.com a écrit :
>
> https://wiki.ipfire.org/addons/nut/detailed
>
Je vais de ce pas étudier ce doc.

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 souhaite
é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 ?

[Benoît SZCZYGIEL]

Bonjour,
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. Vérifie également que ton onduleur redémarre automatiquement au retour du secteur, ce n'est pas toujours le cas.
Benoît

[Olivier]

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

[Benoît SZCZYGIEL]

D'accord avec toi sauf le dernier point. Si tu n'a pas de coupure de courant sur ton ordinateur, il n'y aura pas de reboot after power failure. Tu va devoir passer par un serveur qui ne sera pas arrêté, et qui se plantera sur fin de batterie de l'onduleur. Lui aura un reboot after power failure, et il redémarrera les autres.
Ma conclusion, c'est loin d'être gagné en terme de garantie de fonctionnement

[NoSpam]

Le 07/03/2022 à 13:25, Olivier a écrit :
> @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)

L'onduleur n'arrête rien, il ne fait que remonter des infos au logiciel
de gestion. Les onduleurs digne de ce nom ont tous plus de une prise de
courant. Au bureau j'utilise 3 onduleurs: le principal de qualité avec 6
prises connecté en USB à NUT: dessus sont connectés les 2 arrivées
fibre, le serveur avec ses VM et le commutateur maitre auquel sont
connectés les différents matériels connectés (PI, écran, autres
serveurs, ...) à un onduleur de moindre autonomie, ces matériels étant
éteint par le serveur à la première alerte + x min (cas de coupures
courtes).

L'imprimante est quand à elle sur un onduleur dédié.

Important: calculer la consommation de chaque équipement afin de
connaître la puissance nécessaire de.s onduleur.s

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

Tout à 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
mes matériels de moindre importance connectés à l'onduleur B
--
Daniel

[Christophe Maquaire]

Le lundi 07 mars 2022 à 13:25 +0100, Olivier a écrit :

Bonjour,

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

Si tu es parti pour installer un Pi ( alimenté jusqu'à ce que mort s'en
suive par l'onduleur...), pourquoi ne pas piloter l'alimentation de ton
serveur via un relais branché sur un des GPIO, NUT faisant le reste?

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

Christophe

[Sébastien Dinot]

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.

[benoit szczygiel Z.Elec]

Bonjour,
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.
Benoit

----------------message d'origine-----------------
De: "Sébastien Dinot" [sebasti...@free.fr]
Pour: debian-us...@lists.debian.org
Date: Mon, 07 Mar 2022 22:23:24 +0100
-------------------------------------------------

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

Benoit SZCZYGIEL
Z.Elec
30 rue de l'abbé Bonpain
59273 FRETIN
tél 03 20 64 72 15

[Sébastien Dinot]

Bonsoir,

benoit szczygiel Z.Elec a écrit :

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

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é ?

http://pqsoftware.eaton.com/emb/66244/doc/fra/3676fraa.pdf

« 3.6.3 Coupure secteur longue, Arrêt déclenché par le Shutdown Timer,
mais retour réseau avant la fin du Shutdown Duration

Si le réseau revient avant la fin du Shutdown Duration,l’onduleur est
arrêté après le Shutdown Duration pendant un temps égal à la
temporisation de reboot forcé. »

> En même temps, si ton besoin est vraiment critique, en général, il
> y a un informaticien pas trop loin.

Pas forcément. J'ai déjà déployé des serveurs dans des bâtiments très
isolés, peu accessibles et vides de toute personne en temps normal
(radar météorologique, station de surveillance d'ouvrage hydraulique).

Je me souviens que nous utilisions des prises SNMP commandables
à distance pour pouvoir procéder en dernier ressort au reboot à froid
des systèmes. À l'époque, tout cela se faisait via un modem RTC et des
liaisons RS232. Aujourd'hui, ce type de matériel a bien évidemment pris
le virage TCP/IP :

https://www.elecdan-solutions.com/produit/commande-electrique-ip-4-prises-eps4r3/

[Sébastien Dinot]

Sébastien Dinot a écrit :

> 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é ?

Je précise que j'ai bien compris que le document en question fait
référence à du matériel qui vise les professionnels et n'a rien à voir
avec l'onduleur « domestique » qui trône à côté de mes machines.

[Daniel Caillibaud]

Bonjour,

Je reviens sur ce thread parce que :

Le 04/03/22 à 17:21, Olivier <oza....@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 !

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

[ptilou]

Les développeurs pour les vrai datacenter on fait un script si le groupe électrogène fait défaut les serveurs sauvegarde, puis sont en extinction et le bios de la carte mère se réveil, y avait quelque chose sous 2.4 en kernel sous rh6, j’ai pas suivi sous debian !
Voir un walk on wan, réveil par interface réseau ? Le français des ups aps avait fait quelque chose je crois ?


Mais bon les disques qui crachent faut modifier le firmware du disque ?

Mais ça ne crache pas …

—
Ptilou

[Mathias Dufresne]

Salut,

L'option mentionnée du BIOS pour le redémarrage automatique ne fonctionne que si l'alimentation électrique a été coupée. Ici, sur une carte mère sans doute très différente de la tienne, après un poweroff suivi d'une coupure électrique, la machine redémarre automatiquement lorsque l'électricité est à nouveau disponible... à condition d'attendre suffisamment pour que les condensateurs se vident et que la carte comprenne que l'électricité est coupée.

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

En espérant que ça puisse t'être utile ; )

[Mathias Dufresne]

Salut,

@home, je ne m'inquiète absolument pas de ça. Sans onduleur, mon mini-serveur qui fait office de NAS au passage redémarre correctement depuis des années après chaque coupure d'électricité. Juste pour te rassurer ^^

Je dirai que le risque est lié à l'utilisation des disques. Pour qu'un disque présente un problème après une coupure, soit c'est mal géré par le système (au sens très large) soit c'est que le disque n'a pas eu le temps de finir le travail d'écriture en cours. Or les SSD écrivent plutôt vite ce qui limite les risques d'une écriture non terminée.

Le risque augmente avec l'utilisation du FS mais tu parles de NAS perso, ça sert le plus souvent à la lecture et comme il est "perso", le nombre d'écriture doit être relativement restreint.

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, peut-être vérifier sur quelle partition / FS s'appliquent ces fsck, voire si ce n'est pas encore le cas, séparer les logs du reste du systèmes (en terme de partitions) afin que le risque soit cloisonné...

[Sébastien Dinot]

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/

[Olivier]

Le sam. 12 mars 2022 à 00:30, Daniel Caillibaud <m...@lairdutemps.org> a écrit :
>

> Bonjour,
>
> Je reviens sur ce thread parce que :
>
> Le 04/03/22 à 17:21, Olivier <oza....@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 !
>
>

La question est vraiment très intéressante.
Merci beaucoup de la poser.

Au 21ème siècle, j'ai eu de multiples pannes de machines refusant de
démarrer à cause d'une incohérence dans le système de fichier.
La solution était souvent de déclencher un simple fsck.
C'est une opération assez difficile sur des machines headless sans
aucun informaticien aux alentours.

Par contre, si ma mémoire ne me trompe pas, je crois n'avoir rencontré
ce cas qu'avec des disques SATA.
Je sais que j'ai eu des coupures électriques sauvages et sans
conséquence avec des disques NVMe mais je ne sais pas si on peut
attribuer l'absence de conséquence à la chance ou à autre chose.

Néanmoins, je crois que des disques NVMe ont des mécanismes qui les
protègent contre les coupures sauvages.
Couplés à des onduleurs télé-administrables et des cartes mères
supportant la fonction "Power ON: Last State", on a peut-être une
solution simple re-démarrant automatiquement même si la route est
longue (cf [1])

[1] https://www.tomshardware.com/news/sk-hynix-sabrent-rocket-ssds-data-loss

[Daniel Caillibaud]

Le 15/03/22 à 10:33, Mathias Dufresne <mathias....@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 le marbre
> ; ) 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

[Mathias Dufresne]

En provenance directe du man (7) de fstab :

   The sixth field (fs_passno).
       This field is used by fsck(8) to determine the order in which
       filesystem checks are done at boot time. The root filesystem
       should be specified with a fs_passno of 1. Other filesystems
       should have a fs_passno of 2. Filesystems within a drive will be
       checked sequentially, but filesystems on different drives will be
       checked at the same time to utilize parallelism available in the
       hardware. Defaults to zero (don’t check the filesystem) if not
       present.

Ensuite, quel fsck (fsck.ext[234], fsck.vaft, .minix ...) est réellement dépend du FS en question.

Quant à savoir si c'est lié au buffer ou non, je ne me suis simplement jamais attaqué à obtenir une réponse de ce type. Trop bas niveau à mon sens et je n'en jamais ressenti le besoin en plus de 20 à jouer les sysadmins : )

[Olivier]

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.

Le mar. 15 mars 2022 à 10:40, Sébastien Dinot
<sebasti...@free.fr> a écrit :
>

[Th.A.C]

Le 20/10/2022 à 15:27, Olivier a écrit :
> 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".

Le freeze ne fait que mettre la machine en 'pause'.
le système ne vide pas ses caches et donc couper le courant ensuite te
fera sûrement perdre des données.


Pour répondre à ton scénario en tenant compte du point 3 B, il faut
changer la façon dont ton serveur répond à un signal d'avertissement de
l'onduleur.

la commande shutdown a plusieurs options dont une qui arrête bien le
serveur mais ne coupe pas l'alimentation:
shutdown -H ........

dans ce cas, le serveur reste allumé mais le système linux est
complètement arrêté.
Quand l'onduleur coupera le courant, il n'y aura aucune 'casse'.
Et au rétablissement du courant, la machine se rallumera normalement.

Sinon, un passage en hibernation profonde est aussi valable.

>
> 2. Idem avec echo standby > /sys/power/state

normal, le système est simplement 'suspendu' et ne vide pas ses caches
ni tout le reste, c'est tout aussi risqué que le freeze.

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

Attention de bien attendre que le système ait fini sa procédure de mise
en hibernation.
Suivant ce qui est chargé en mémoire, ca peut prendre du temps pour tout
écrire dans le swap.

Si l'hibernation s'est bien déroulée, c'est que l'acpi n'est pas
correctement géré par ton système qui ne coupe alors pas l'alimentation.
Ou qu'un paramétrage est incorrect...


Un moyen de vérifier si l'hibernation fonctionne est de laisser un ou
plusieurs logiciels ouverts avant l'hibernation.

Au rallumage, tu dois voir des messages indiquant une reprise suite à
hibernation et le système doit te remettre exactement ce que tu avais
avant d'hiberner

>
> 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 ?

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.

Sinon il faut démonter les systèmes de fichiers.

Jouer avec le feu ne t'amènera que des problèmes.

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

voir ma réponse du début (point 1)

A noter que la règle est plutôt de configurer l'onduleur pour qu'il ne
rétablisse le courant qu'à partir d'un niveau de charge considéré comme
'safe'.

Si tu préfères, le niveau de charge doit garantir qu'en cas de coupure
inopinée
- il y ait assez de courant pour que ton serveur ait le temps de démarrer.
- que le service NUT soit actif pour recevoir les alertes de l'onduleur
- que ton serveur ai le temps de s'arrêter
.
Je n'ai jamais eu à travailler sur ce point, mais si l'onduleur envoie
un signal quand il tombe à 10 %, on peut considérer que qu'il en faut
bien plus pour un rallumage en toute sécurité...



Sinon, un point qui ne concerne que l'onduleur, il faut vraiment tester
la batterie:
j'ai déjà eu des onduleurs qui coupaient sauvagement bien avant
d'atteindre le seuil minimum.
Je n'ai pas eu le temps d'analyser le problème, mais cela pouvait venir:
- soit d'une batterie défectueuse
- soit d'un besoin de recalibrage de l'onduleur.

[Basile Starynkevitch]

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.sta...@cea.fr ....)


--
Basile Starynkevitch <bas...@starynkevitch.net>
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/

[Olivier]

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
<bas...@starynkevitch.net> a écrit :

[Olivier]

Dans la documentation Eaton, je découvre le paramètre Redémarrage
forcé, qui activé, me semble bien correspondre à l'exigence C

"Si le réseau est rétabli pendant une séquence
d'arrêt :
- s'il est activé, la séquence d'arrêt se termine
et attend 10 secondes avant le redémarrage
- s'il est désactivé, la séquence d'arrêt ne
se termine pas et le redémarrage a lieu
immédiatement."

[Sébastien Dinot]

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, sebasti...@free.fr
http://www.palabritudes.net/

[Olivier]

https://www.eaton.com/content/dam/eaton/products/backup-power-ups-surge-it-power-distribution/backup-power-ups/eaton-5p-ups/eaton-5p-manuel-d-installation-et-d-utilisation.pdf
page 11

Le sam. 22 oct. 2022 à 01:29, Sébastien Dinot
<sebasti...@free.fr> a écrit :
>

[Sébastien Dinot]

Olivier a écrit :
> https://www.eaton.com/content/dam/eaton/products/backup-power-ups-surge-it-power-distribution/backup-power-ups/eaton-5p-ups/eaton-5p-manuel-d-installation-et-d-utilisation.pdf
> page 11

Mon onduleur Eaton (un Ellipse PRO 1200) est beaucoup plus basique, même
s'il est lui aussi de type Line Interactive. Il ne propose pas cette
fonction, c'est bien dommage.