Montage d'un cluster (actif/passif) demande de retour d'exp

Support Debian
#1

Salut salut

J’ai dans l’intention de mettre en oeuvre un cluster monté avec hearbeat/drbd sous débian 7.5x.
Je viens à vous pour avoir un retour quel qu’il soit (positif ou négatif) sur votre expérience dans une tel opération.
Je ne demande pas la solution, je suis en phase de documentation et de tests virtualisés, juste un retour.

récapitulatif sur mon montage - 2x machines identiques(sauf boitier et alim)

  • 1x cpu amd 2 coeur
  • 4 go ram
  • 1x hdd pour l’instant avec un disque découpé en trois partie [ / ; /drbd;/swa]
  • 4x emplacement prévu pour ajouter des disques suivant l’évolution de ma structure
  • 2x cartes réseaux
    — 1x celle de la carte mère connectée à la dorsale réseau
    — 1x ajouter en pci pour la synchro machine1/machine2

Le but est d’intégrer un cluster avec :

  • la résolution de noms avec bind9 (dns local et dns web)
  • l’adressage dynamique avec dhcpd3 pour décharger mon router
  • l’annuaire openldap
  • l’authentification avec freeradius et kerberos
  • bases de données avec Mysql ou Postgressql (pas encore statué sur l’un ou l’autre)
  • le http avec Apache2
  • le transfert de fichiers via l’extérieur avec Proftpd
  • le transfert de fichiers via l’intérieur avec samba4 (but samba AD)
  • le mail (pop/smtp/imap)
  • la supervision (pas encore décidé quelle solution)
  • la gestion des vpn avec openvpn

La première partie est de mettre en fonction le cluster en mode actif/passif avec les services cité plus haut.
La deuxième partie sera de mettre en place une machine qui devra avoir pour fonction de servir de “sorry-server”.

Donc au vu de la présentation de mon projet.
Avez vous des points où il faut que je fasse plus attention à une solution plus qu’à une autre par exemple.

Merci à vous

#2

bonjour,
architecture réalisé pour le fun!
je me bas avec pacemaker,

un point important, j’ai utilisé des adresses ip fixes genre 192.168.0.0/24 et ou 10.0.0.0/24
j’avais déjà monté un cluster sous Debian avec des machines hétérogènes (multicores + 2 RPI )

comme c’était pour le fun, je n’ai utilisé que partiellement
pour l’installation j’ai fait référence à l’architecture (du pére et du fils en GB avec les legos et les rpi)
et comme je veux la dernière Debian j’ai tout cassé sur un full update

actuellement j’essaie avec pacemaker mais j’ai des problèmes de clé
ceci avec 2 linux différents (pourqu’oi pas comme cela s’appuie sur ssh),
j’avais une multicore Debian et 2 RPIs j’avais des résultats

donc sur les divers lectures des adresses IP fixe avec nodename

avec les fonctionnalités de SGBD répliqué, on fait du cluster!!!
A+
JB1

#3 
- la résolution de noms avec bind9 (dns local et dns web)

je comprens mal la phrase,
il y a des spécialistes réseau,
normalement bind 9 défini ces divers champs
et fait pointer vers ton serveur apache
A+
JB1

#4

[quote=“tatave”]
Donc au vu de la présentation de mon projet.
Avez vous des points où il faut que je fasse plus attention à une solution plus qu’à une autre par exemple.

Merci à vous[/quote]

tu cherche à faire de la haute disponibilité, pour ça qu’as-tu commencé à lire comme documentation ?

par exemple :

http://denisrosenkranz.com/tuto-ha-un-cluster-apachemysql-avec-drbd-et-heartbeat-sur-debian-7/
http://www.pintaric.net/index.php?post/2009/04/27/MIse-en-place-d-un-cluster-Haute-Disponibilit%C3%A9
http://www.it-connect.fr/clustering-et-haute-disponibilite-sous-linux-avec-heartbeat%EF%BB%BF/

Quelles sont les technos que tu compte faire tourner pour gérer la bascule ?

#5

Re salut salut

@jb1

en faites je partais plus sur :
une zone local et des vues
une zone internet (sous domaine d’un de mes domaines) redirigé sur mon cluster

@clochette

Oui, j’ai déjà vu les sites que tu indiques.

Le but premier de la démarche est de mettre en route un cluster actif/passif en full synchro data/services.
Le tous avec les services cités dans le poste de départ.
La ou je suis en attente, c’est sur qu’est ce qui primordial d’utiliser sur de FO ou du LB voir un mixte des deux si cela est possible.

Merci pour vos participations.

#6

C’est lourd DRDB, vraiment.

Je vous conseille sincèrement GlusterFS, ça marche impec’. Filer en prod pour plusieurs sites je n’ai jamais de soucis. Ils sont monitorer et je n’ai jamais de décalage non plus, c’est vraiment un super produit. Quant à l’ipfailover j’ai toujours gérer ça avec Heartbeat, c’est assez simple pour mon usage en tout cas.

#7

[quote=“ben_raven”]C’est lourd DRDB, vraiment.

Je vous conseille sincèrement GlusterFS, ça marche impec’. Filer en prod pour plusieurs sites je n’ai jamais de soucis. Ils sont monitorer et je n’ai jamais de décalage non plus, c’est vraiment un super produit. Quant à l’ipfailover j’ai toujours gérer ça avec Heartbeat, c’est assez simple pour mon usage en tout cas.[/quote]

DRDB est pour moi plus solide que GlusterFS, mais DRDB ne permet pas de dépasser trois Noeuds.

Dans un montage comme celui-ci je pense que DRDB est la solution la plus adapté.
Pour ce qui est de Heratbeat, j’ai toujours des emmerdes avec ça, Monit installé sur le slave, check à intervalle régulier que le service soit tours debout sur le master, sinon il envoi l’ordre de monté la VIP sur le slave et opère donc la bascule.

Il n’est jamais bon par contre de laisser la bascule s’opérer après coup par contre,. (avis personnel cra nous avons rarement des serveurs master capable de reprendre la main sans intervention de notre part, du coup la réplication est en générale morte et nécessite en urgence d’être revue).

Maintenant dans un cadre idéale, le top s’est de posséder un ou deux filer répliquer (l’idéale c’est trois) avec plusieurs frontaux répliquer eux même à coup de rsync le tout derrière un loadbalancer.
Mais tout ceci nécessite bien plus de machine.

Je précise à toute fin utile que je n’ai jamais utilisé de heartbeat sur des services autre que MySQL sachant que nous préférons pour nos client (au taff j’entend bien) utiliser d’autre techno pour gérer la Haute disponibilité.

#8

Salut salut

@Clochette
Tu pensais à quoi comme solution ? si ce sont des solutions non open, y a en t-il dans le libre ?
je suis d’accord avec toi, le top serait au minima de 5 machines (2 en frontal et 3 en backend), sauf pour l’instant je suis coincé avec juste 3 machines (2 cluster et 1 en sorry)

N’étant qu’un particulier qui aime s’arracher la tête avec des projets informatique comme celui là.

pour l’instant j’avais cru comprendre que drbd pouvait me servir pour la synchro data via le réseau et m’eviter de me servir de rsync, ou j ai raté qq chose.

#9

[quote=“tatave”]Salut salut

@Clochette
Tu pensais à quoi comme solution ? si ce sont des solutions non open, y a en t-il dans le libre ?
je suis d’accord avec toi, le top serait au minima de 5 machines (2 en frontal et 3 en backend), sauf pour l’instant je suis coincé avec juste 3 machines (2 cluster et 1 en sorry)

N’étant qu’un particulier qui aime s’arracher la tête avec des projets informatique comme celui là.

pour l’instant j’avais cru comprendre que drbd pouvait me servir pour la synchro data via le réseau et m’eviter de me servir de rsync, ou j ai raté qq chose.[/quote]

Pour faire simple à mon taff nous mettons en générale un heartbeat/monit en place pour les réplication Mysql entre deux machines et géront en régle générale les frontaux dérrière du loadbalancer avec une synchro via rsync entre les frontaux web.

Maintenant ce que tu cherche à faire nous le mettons en place pour mais sur des plateformes assez complexe et avec des produits pas à 100% open.

Je pense que le plus simple pour toi serait effectivement que tu puisse gérer une bascule en cas de souci sur un des deux serveurs via heartbeat surveiller avec un monit mais pour DRDB soit tu as deux noeuds qui répondront (heartbeat en version 2 uniquement) sur une VIP et feront le lien vers tes frontaux.

Je n’ai jamais pour l’instant administrer un ensemble complet de service sur deux noeuds de la manière dont tu l’entend … je ne dit pas que c’est impossible mais j’ai toujours eu l’habitude de séparé le SQL du web et après gérer la bascule ou la charge sur chaque noeuds.

Ce qui je te l’accorde ne t’avance guère dans l’état actuelle.

Par exemple gérer la charge sur un cluster de mail OK, gérer du heartbeat avec une réplication pour du serveur mail … je sèche.
Pareil pour du service VPN, qu’il y est un script de test du côté client qui relance en cas de déconnexion OK mais qu’il y est reprise de service en cas de panne sur ton master :whistle:.

En résumé je pense que’à moindre frais tu pourrais virtualisé un poil la structure pour te créer la plateforme désiré et pouvoir étudier ça, mais pour ce qui est de mettre en production ce que tu as décrit là je sèche.

#10

salut salut

@clochette

Merci pour la réponse.

J’avais bien pensé faire cela en labo de virtualisation,
j’ai du voir un ou deux tuto en ce sens, je vais creuser le truc.
Coup de bol mon labo est up depuis ce matin.

@all si vous vous avez aussi des anecdotes sur le sujet cela sera utiles à tous.

Cordialement.

#11

Re all

Pour l’instant j’ai d’opérationnel

  • drbd
  • heartbeat v1

la copie disque à disque réseau via l’interface eth1 est ok
L’ip virtuelle via heartbeat est up

la je m’attaque à bind9.
Il faut que cela soit l’ipv qui soit maitre du domaine et les deux serveurs physiques en esclave, si j’ai bien compris.