Hello,
J'ai un petit projet qui aimerait bien grandir et apprendre à devenir autonome :-)
Aussi il aimerait bien intégrer une solution de clustering de service avec un algo sympa qui permettrait de faire de la répartition de charge et de la reprise sur incident.
J'ai 3 cubieboard clônés qui hébergent mon projet. Je vais prendre un cubie1 pour exemple, l'algo sera le même pour les autres…
Je voudrais que cubie1 (qui héberge mon système domotique), cubie2 (qui héberge xBMC), cubie3 (qui ne fait rien pour le moment) jouent tous un rôle pour rendre mon système domotique haute dispo.
Cubie1 héberge nginx/mariadb/php5-fcgi. C'est la partie visible de l'iceberg.
Cubie1 héberge aussi une tripotée de services perl lancé par runit (qu'il va falloir un jour migrer sous systemd grrr). Ces services sont basés sur l'interconnexion de service perl (http://xplproject.org.uk/)
Ce que j'imagine c'est :
Un service de découverte (pour que les noeuds entre eux se présentent et annoncent les services qu'ils sont en train de faire tourner. Voir qu'il y ai une priorité entre les noeuds pour que les services ne soient pas lancés en même temps sur 2 noeuds)
Un service de prise de décision (en cas de problème sur le nœud maitre) qui gère une VIP, redémarre les autres noeuds, relance les services. Voir même décider de lancer un service sur un autre noeud en cas de suractivité…
Un service de synchronisation des données en base(ça c'est pour éviter le clustering de base mariadb)…
Voilà, Pour commencer ce serait pas mal.
Pour info, :
j'ai déjà utilisé, piranha, ldirectord/heartbeat, lucci/ricci.
Je ne veux pas faire de loadbalancer frontaux. Je voudrais que chaque nœud de mon cluster soit capable de créer la VIP nécessaire pour le bon fonctionnement de l'ensemble du système.
Je développe en C/perl/bash/html/ajax/php
Je cherche des idées, d'autres projets communautaires pour faire mûrir ma réflexion et l'approche algorithmique à avoir pour concevoir l'intelligence artificielle bas niveau de mon système domotique…
Merci par avance pour vos remarques et conseils
# keepalived et ses scripts
Posté par NeoX . Évalué à 3.
tu peux avoir des VIPs pondérées pour avoir
- IPA sur machineA par defaut, si machineA tombe, machineB prend l'IP et demarre le service, si machineB tombe, machineC prend le relais et lance le service sur elle meme.
note que je n'ai jamais essayé avec plus de 2 machines, mais dans mes scenarios, j'ai souvent 2 machines, quelques VIPs, qui sont reparties sur les 2 machines, qui sont "croisées" en terme de charge IPs
l'une prenant de le relais de l'autre en cas de defaillance.
[^] # Re: keepalived et ses scripts
Posté par popof . Évalué à 1.
Mon idéal serait un code en perl car tous mes développements sont en perl.
xPL apporte tellement de potentiel à un service de ce type que mon idéal serait de tout développer dans un module Perl qui s'appuie sur les messages de découverte issu de mon réseau xPL.
Je pense de toute façon redévelopper la roue. Car je veux quelque chose d'assez customisé.
Keepalived et ses scripts, c'est un bon début. Merci Neox, je vais regarder aussi de ce côté ci
# Question à 2 balles (par curiosité)
Posté par totof2000 . Évalué à 2. Dernière modification le 13 octobre 2014 à 19:48.
Je serais curieux de savoir comment tu fais pour rendre un système domotique haute-dispo. Peux-tu décrire ce que tu as derrière tes cubies ? Tu as utilisé des GPIO direct sur la cubie, ou tu passes par une "brique" intermédiaire ?
[^] # Re: Question à 2 balles (par curiosité)
Posté par popof . Évalué à 2.
Je n'ai pour le moment pas utilisé les GPIO du cubie, mais d'autres gars de mon forum se sont lancés dans du DIY arduino et Raspberrypi
Je parle de 3 cubieboard mais j'ai aussi 3 raspberrypi qui pourraient faire parti du cluster
voici mon projet : http://wiseflat.com
La démo n'est plus à jour du tout l'IHM de la doc non plus…
Mais va voir la doc (entre autre la partie architecture)
Composé de 2 briques :
Tout es modulaire dans mon architecture. Et c'est (entre autre) grâce à xPL.
Mon objectif c'est d'installer le Core+Manager sur chaque cubieboard et de créer un nouveau plugin xPL-cluster par exemple qui se charge de gérer le contexte de haute dispo que j'ai décrit dans mon 1er message
L'intérêt évident (si tu connais xPL) c'est que chaque plugin connecté au hub xPL envoie de requêtes heartbeat toutes les 30s (ou 60s je sais plus) ainsi qu'un message de type end quand le plugin se déconnecte du hub. Chaque plugin est identifié (hostname, vendor_id, message_type, etc). Utiliser ces info simplifie grandement la gestion de tout ce qui doit tourner.
Aujourd'hui l'élément le plus critique de mon projet c'est la base de données. D'ou l'intérêt d'avoir une solution de haute dispo à bas cout… C'est ce que je veux sécuriser.
De plus, mon service xPL-cluster serait en mesure de décider de répartir l'exécution des services xPL sur cubie2 ou cubie3 pour des questions de performances
Si tu as d'autres questions/remarques n'hésites pas c'est le but de ce brainstorming ;-)
[^] # Re: Question à 2 balles (par curiosité)
Posté par totof2000 . Évalué à 2.
Merci pour ces retours intéressants.
[^] # Re: Question à 2 balles (par curiosité)
Posté par popof . Évalué à 2. Dernière modification le 13 octobre 2014 à 23:29.
Ce que je veux rendre haute dispo c'est le linux avec ses services !
J'ai évidemment des SPOF :
Mon émetteur/récepteur rfxcom Lan
Mes modules domotiques à piles
Mon alimentation électrique non redondée
Idem pour mon switch 48 ports… Je n'ai pas de switch stacké
Il y a forcément des SPOF. le matériel on met pas trop ces mains dedans contrairement au linux et ses bidouilles à gogo ;-)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.