Difference between revisions of "Arduino PDU"

From YobiWiki
Jump to navigation Jump to search
m (Reverted edits by JasonAnderson (talk) to last revision by PhilippeTeuwen)
 
(6 intermediate revisions by 2 users not shown)
Line 4: Line 4:
 
-> if you want to remotely shut down or reboot a server, You'll sure use a APC or PDU...
 
-> if you want to remotely shut down or reboot a server, You'll sure use a APC or PDU...
   
The "problem" with this system, this is a very hard way to shut down a server.
+
The "problem" with this system is that it's a very hard way to shut down a server.
it could be better to put on the power or reset button ?
+
<br>Wouldn't it be better to press the power or reset button ?
   
Yes you get the idea, a system able to put on the power button (remotely off course)
+
Now you get the idea, a system able to push on the power button (remotely of course)
   
 
=== What do we need ? / cahier des charges ===
 
=== What do we need ? / cahier des charges ===
Line 13: Line 13:
 
** pour la config
 
** pour la config
 
** pour les ordres de commande
 
** pour les ordres de commande
  +
** telnet (à condition qu'il ne soit accessible que via un réseau interne). Mettre aussi un mot de passe car les machines qui ont accès au réseau interne peuvent aussi se faire compromettre et ce serait con qu'un gugus s'amuse...
** simple telnet suffit (on sera obligatoirement sur reseaux prive)
 
 
* communication serie avec le system
 
* communication serie avec le system
 
** pour la config (IP) uniquement ?
 
** pour la config (IP) uniquement ?
** est-il vraiment utile de pouvoir commander via le port serie
+
** est-il vraiment utile de pouvoir commander via le port serie (vu qu'il ne sera raccorder a priopri qu'a une seule machine ...)
  +
** (Phil) je dirais qu'on peut s'en passer, cf point suivant
(vu qu'il ne sera raccorder a priopri qu'a une seule machine ...)
 
  +
* robustesse (Phil)
* idealement capable de commander plusieur serveur (par commande on entend ''apuiller'' sur le BP power ou reset)
 
  +
** on veut pouvoir (à distance) reprendre la main sur la bête qui se serait crashée (stack ethernet, whatever).
  +
** Une des façons sans doute la plus sûre est de reflasher l'Arduino via USB et d'injecter directement la config qu'il faut dans l'image.
  +
** Ainsi, il n'y a pas besoin de développer un module CLI série pour reconfigurer l'IP.
  +
** C'est sensé être aussi plus robuste car on est à l'abri de tout plantage ou erreur de codage si on peut simplement le reflasher à distance pour corriger le tir.
  +
** Seule condition: les commandes physiques des boutons de reset ne peuvent pas se déclencher en cas d'arrêt, de reflashage, ou de reboot de l'Arduino! Si on n'a pas le contrôle absolu des ports lors de ces opérations, une solution est de bufferiser ces sorties (charge capa) et de devoir maintenir la sortie reset haute pendant longtemps (1 ou 2 secondes) pour que le reset soit effectué. Ainsi, aucun risque de déclenchement accidentel au reflashage.
 
* idealement capable de commander plusieur serveur (par commande on entend ''appuyer'' sur le bouton power ou reset)
 
* pouvoir mettre une etiquette sur chaque serveur (evite de se tromper de serveur)
 
* pouvoir mettre une etiquette sur chaque serveur (evite de se tromper de serveur)
  +
* sans alim ou si celui si est dans le choux, les serveurs ne doivent pas se couper/rebooter ...
 
  +
==== Idee dingue ou pas ? ====
  +
* 'lecture' des diodes power et HDD ou autre ?
  +
* ssh
  +
** bon ca on n'y pense meme pas ! :-p
  +
* Extensionalisable sans trop de frais
  +
** point de vue interface ethernet
  +
*** maintenant vu le faible cout :/

Latest revision as of 16:02, 2 March 2016

PDU, APC or Server control unit or wathever you want ;-)

APC stand in the minds of IT engineer as system witch control the power supply of servers -> if you want to remotely shut down or reboot a server, You'll sure use a APC or PDU...

The "problem" with this system is that it's a very hard way to shut down a server.
Wouldn't it be better to press the power or reset button ?

Now you get the idea, a system able to push on the power button (remotely of course)

What do we need ? / cahier des charges

  • communication ethernet
    • pour la config
    • pour les ordres de commande
    • telnet (à condition qu'il ne soit accessible que via un réseau interne). Mettre aussi un mot de passe car les machines qui ont accès au réseau interne peuvent aussi se faire compromettre et ce serait con qu'un gugus s'amuse...
  • communication serie avec le system
    • pour la config (IP) uniquement ?
    • est-il vraiment utile de pouvoir commander via le port serie (vu qu'il ne sera raccorder a priopri qu'a une seule machine ...)
    • (Phil) je dirais qu'on peut s'en passer, cf point suivant
  • robustesse (Phil)
    • on veut pouvoir (à distance) reprendre la main sur la bête qui se serait crashée (stack ethernet, whatever).
    • Une des façons sans doute la plus sûre est de reflasher l'Arduino via USB et d'injecter directement la config qu'il faut dans l'image.
    • Ainsi, il n'y a pas besoin de développer un module CLI série pour reconfigurer l'IP.
    • C'est sensé être aussi plus robuste car on est à l'abri de tout plantage ou erreur de codage si on peut simplement le reflasher à distance pour corriger le tir.
    • Seule condition: les commandes physiques des boutons de reset ne peuvent pas se déclencher en cas d'arrêt, de reflashage, ou de reboot de l'Arduino! Si on n'a pas le contrôle absolu des ports lors de ces opérations, une solution est de bufferiser ces sorties (charge capa) et de devoir maintenir la sortie reset haute pendant longtemps (1 ou 2 secondes) pour que le reset soit effectué. Ainsi, aucun risque de déclenchement accidentel au reflashage.
  • idealement capable de commander plusieur serveur (par commande on entend appuyer sur le bouton power ou reset)
  • pouvoir mettre une etiquette sur chaque serveur (evite de se tromper de serveur)

Idee dingue ou pas ?

  • 'lecture' des diodes power et HDD ou autre ?
  • ssh
    • bon ca on n'y pense meme pas ! :-p
  • Extensionalisable sans trop de frais
    • point de vue interface ethernet
      • maintenant vu le faible cout :/