Re: Comment éteindre un serveur proprement pour permettre le redémarrage automatique ?
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."
Le ven. 21 oct. 2022 à 10:36, Olivier <oza.4h07@gmail.com> a écrit :
>
> 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/
> >
Reply to: