Difference between revisions of "Arduino PDU"
Jump to navigation
Jump to search
(Created page with "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 shu…") |
m (Reverted edits by JasonAnderson (talk) to last revision by PhilippeTeuwen) |
||
(8 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 |
+ | The "problem" with this system is that it's a very hard way to shut down a server. |
− | it |
+ | <br>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 :/ |
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 :/
- point de vue interface ethernet