Failover Jeedom

Bonjour,

Y a t-il une personne sachant faire du failover ou tout autre solution de redondance automatique entre 2 jeedom?

Merci et bonnes fêtes

Bonjour
Sujet de nombreuses fois abordé et c’est quasi impossible déjà jeedom est pas prévu pour mais ça a la limite yaurai des solutions. Le problème c’est plutôt les protocoles sur clef USB type le zwave

Hello,

Sauf erreur de ma part, certaines personnes gèrent le problème du contrôleur Z-Wave avec la clef AEOTEC que l’on peut cloner et en utilise donc une pour le Jeedom principal et une autre, cloné, pour le Jeedom secondaire.
Bien entendu, à chaque ajout de module, il faut recloner la clef. Mais bon, on ajoute pas des modules tous les jours.

Oui ça marche mais je suis sur pas sur ça soit top pour les réseaux lors de l’émission d’une info le module attend un acquittement du contrôleur la ya 2 controleur donc celui qui acquite n’est pas forcément le principal donc le module pense que c’est bon alors que ça peut ne pas l’être et l’autre doit aussi envoyé un acquittement ce qui poli le réseau zwave

Je pense que cela peut être gérable avec un peu de réflexion.
Réflexion à froid : Mettre en place un scipt/scénario/autre sur le second Jeedom qui va prendre la main s’il détecte une inactivité du Jeedom « maitre » de plus de x minutes.
A voir, suivant les machines, s’il est possible de ne pas mettre de jus sur l’alimentation USB tant que le Jeedom maitre est opérationnel pour éviter d’avoir deux contrôleurs sur le réseau.

Jeelink pourrait gérer un heartbeat et proposer de lancer une action (type action scénario) si l’autre ne réponds pas…

Après c’est à l’utilisateur à choisir des protocoles facilement redondables (si ce mot existe)

Ou quelque chose de plus pro avec Galera…

Vu que Jeedom a une vraie séparation core/plugins, la réflexion d’une solution failover ne doit pas être mise de côté juste à cause de solutions non IP-based. Surtout vu que Zwave a annoncé rejoindre les gros avec leur annonce, on va converger vers des « gateway » sur IP.

Jeedom c’est quoi ? Du MySQL, du PHP (en interface web et cron), des scripts/daemon en différents langages.
MySQL failover : checked, c’est suffisamment commun et largement possible.
PHP pour l’interface web : checked aussi
Reste le cron principal (PHP) qui se charge de lancer tous les autres scripts/daemon. Lui il faut une solution qui ne l’active que sur un noeud à la fois par exemple. C’est une tache dont est capable keepalived.

Et tout ca existe depuis longtemps, c’est meme pas né avec les microservices.
Pour ce qui est des protocoles basés sur USB, tant pis pour eux. Au moins on aurait une solution core keepalived avec des exigences pour que les plugins le soit aussi. Et ceux qui ne peuvent pas remplir les exigences ca apportera une lumière de plus sur les défauts des clefs USB.

Je suis d’accord en effet.
Si le cahier des charges initial est de faire de la HA, alors il faut partir sur un Jeedom Full IP.

Après c’est toujours pareil… la HA ca a du sens quand tout est en HA…

Dans ce cas tu redonde aussi tout tes équipements réseaux

maintenant, le besoin de HA est tout relatif à mon sens…

A part pour les entreprises qui pourrait avoir besoin de HA…
Et encore quand on est une entreprise avec ses besoins là, on souscrit chez un éditeur capable de te proposer le bon contrat de maintenance… déplacement sous 2h par exemple…

je ne vois pas trop le besoin du grand public…
A part peut etre pour les habitations de vacances ou personne est sur site… mais bon encore là, tu as toujours un contact pour aller rebrancher

Ca a du sens pour une offre professionnels aux particuliers par exemple. Ou simplement quand on veut être tranquille.
Quand on monte une infra HA tout n’est pas forcément HA, que ce soit voulu ou non. On va pas parler des arnaques (donc du cas non voulu) sur lesquels après c’est bagarre de discours et versions de lecture de contrat (exemple : la fourniture électrique de la gare Montparnasse)

Quand on doit faire du HA, il est courant, voir standard, de se demander « ai-je besoin de HA pour ce composant »
Nombre de datacenter soient disant redondés avec site de secours on un lien fibre … unique. Pour une raison de coût, c’est connu des gestionnaires, c’est un choix qui a été fait (mauvais car non technique, mais malheureusement les gestionnaires de portefeuille interviennent)

Alors pourquoi passer sa domotique en HA ?

  • je suis particulier, j’ai fait appel à un professionnel et je veux un engagement de disponibilité qui présente un risque trop fort (exemple le client souhaite que la maison le réveil avec au maximum 2 jours d’interruption par an, ou bien toutes les lampes passent par la domotique et il ne faut pas d’interruption de plus de 4h …)
  • je suis un geek, mais je pars souvent en déplacement, je veux que la maison marche toute seule sans que je sois là, au pire en changeant les composants en revenant
  • bureau tertiaire
  • usine

Et dans chaque cas, viennent les questions :

  • est-ce que je redonde …
    Et pour répondre, qu’est-ce qui existe, quel cout (achat et maintenance), quelles exigences, impact …

Par exemple, redonder la fourniture électrique est juste inaccessible au particulier

Mais au niveau fourniture d’accès internet par exemple, la question est justifiée dans beaucoup de configurations (surtout les maisons intellligentes « récentes », plus basées sur des objets connectés que du protocole domotique classique). Personnellement, je me pose vraiment la question par exemple et ca sera surement un chantier de 2020 que de passer en double connexion internet pour gagner en fiabilité et ne pas avoir à tout baser sur le cloudless.

Au niveau Jeedom la question est primordiale. C’est l’élément le moins fiable de la maison domotique, rien qui lui soit spécifique, mais c’est un « serveur ». Et ca vient avec tous les composants et les risques de panne qui vont avec. C’est juste l’histoire de l’IT, le premier composant qu’on sécurise, c’est le serveur car il est plus difficile de le répartir. En gros, on met en HA un switch par assurance, mais le serveur on le met en HA parcequ’on sait qu’il va tomber un jour.

Alors oui, une solution facile serait 2 serveurs avec VM Jeedom … mais pas forcément si facile, et pas forcément viable en solution professionnelle.
Une solution HA plus native permettrait aussi un gain de performance en mode optimal (ce qu’on trouve de plus en plus, on s’arrange pour utiliser toutes les ressources disponible, donc en cas de panne, on diminue les ressources, mais on ne met pas un équipement en sommeil en permanence)
Ca reviendrait avec Jeedom par exemple à être en capacité de load balancer les plugins sur les deux serveurs. Mais là l’impact serait plus important, une belle solution serait de les gérer en micro-services. Mais pour ca faudrait déjà un Jeedom qui tourne sur docker sans soucis :slight_smile:

Faut pas oublier docker dans l’histoire… une bonne image (ou plusieurs si on sépare web et bdd), ça remplace facilement, voire mieux une VM

Oui oui, c’est ce que je dis à la fin :slight_smile:
Mais après basé la solution HA sur docker ou mieux du kubernetes tu mets de côté les box existantes jeedom …
Pourtant, quitte à être root, une gestion en microservices basés sur des dockers aurait beaucoup de sens (les plugins devenant des containers alors, avec la possibilité d’en déployer 1 ou x suivant les besoin)

1 « J'aime »

ça aurait carrément de la gueule ! Relance des containers et pas de tout le système … Mise à jour facile des images, pas de conflit entre les containers…

Hello,

Qu’est-ce qui pose soucis sous Docker?
J’ai rencontré quelques problèmes (broadcast, tunnel VPN) mais cela est maintenant pleinement fonctionnel. Du moins, dans ma configuration et dans mon utilisation.
Il y a peut-être d’autres choses qui déconnent.

Après, ce n’est pas officiellement reconnu (contrairement à certains concurrents) mais je fais avec.

L’image docker est très franchement à refaire… Là c’est utilisé comme une VM, ça marche mais c’est monolithique au possible. Et ça embarque tout un tas de trucs inutiles de l’OS Debian.

Hello
Je me posais également la question comment faire de la redondance avec Jeedom.
J’ai déjà eu un problème matériel avec la smart (donc retour, attente de la réparation etc.). Même si le support a été réactif baaah … y a qd même eu plusieurs jours sans jeedom.
La maison connectée prenant de plus en plus d’ampleur, c’est quelque chose qui doit devenir de plus en plus fiable. La domotique s’occupe notamment de la sécurité (capteur d’ouverture, caméra etc) bref là on touche au sensible.
Et actuellement je trouve que c’est loin d’être fiable (j’ai régulièrement des problèmes de device zigbee qui disparaissent, 2x de réseau zwave surchargé qui me force a reboot etc).
De mon côté j’ai déja planifié la mise en place d’un ondulateur pour garder le système UP pendant un certains temps, en cas de panne de courant (ou de plomb qui saute, vu qu’après le réseau zwave met bcp de temps pour revenir à la normal avec les capteur sur pile etc).

Au vu des post je pense pas que le plus gros problème d’avoir un Fail over viennent de jeedom (docker, VM etc restent possible, même si faudra sans doute améliorer) mais de tout les device hardware qui stockent des données, comme clefs zwave, zigbee et j’en passe.

Pour ça est-ce que quelqu’un voit une possible solution ?
Je pense que la conbee a des fonctions de backup/restore, reste à voir si c’est possible d’automatiser ça. On aurait alors 2 conbee sur du matos différent, une inactive qui serait restaurée en cas de basculement sur le matos en spare. Pour la zigate je sais pas si ça existe ce genre de fonctionnalités.
Pour les clefs zwave je sais pas si elles stockent qque chose ?

Je suis très loin d’être un expert … je couche juste les idées que j’ai.

Kemp sait faire du load-balancing/failover jusqu’au niveau 7.
Il y a aussi possibilité de faire du Ha et gratuitement (en ne dépassant pas les limites).
En mappant directement les ports usb d’un hyperviseur/cluster sur les VM hébergeant jeedom et quelque VIp cela devrait fonctionner.
Un NUC5i5 suffit pour faire tourner un HomeLab…