Seafile Master/slave

Support Debian
#21

Heartbeat peu s’accommoder de gérer la partie web comme la partie bdd.

De manière personnel je préfère le couple corosync et pacemaker plutôt que hartbeat et mon mais c’est affaire de goût.

La réplication mysql peu s’effectuer par le biais de mysql replicator ou alors par un mécanisme plus
velu à base de DRBD.

Exemple trouvé sur le web rapidement (pas à jour mais c’est pas bien grave il faudra simplement adapter) :
http://denisrosenkranz.com/tuto-ha-un-cluster-drbdmysql-avec-heartbeat-sur-debian-7/

Etg en exmple pour corosyncpacemaker : https://www.linux-dev.org/2016/03/debian-jessie-8-3-short-howto-for-corosyncpacemaker-activepassive-cluster-with-two-nodes-and-drbdlvm/

#22

@Theodreyz
Je voudrais savoir la différence entre la BDD et les données car du coup les données vont pas être stockées dans la BDD ?
Du coup je compte utiliser MySQL je pense et en données, j’ai vu qu’on peut faire avec NFS mais ça voudrais dire qu’il faut installer un serveur NFS sur chaque noeud ? Et je ne trouve pas de réplication de dossier ?

Merci.

#23

@valentin85
La BDD va servir essentiellement à l’indexation des fichiers, je ne l’ai jamais décortiqué donc je ne saurai pas dire avec précision elle n’a jamais été très imposante mais elle est indispensable au bon fonctionnement du service.
Pour les données, le tout est de savoir comment tu souhaites y accéder, les stockées et les sauvegarder.
Il faut que ce soit transparent pour tes utilisateurs sans qu’elles soient accessibles directement.
Il faut que ce soit dimensionné correctement sans pour autant trop en faire et que cela reste évolutif en fonction de futurs besoins.
De ce côté là, il n’y a que toi qui peut savoir de quoi tu as besoin.

#24

@Theodreyz
D’accord.
Tu peux me dire quelles solutions tu as utilisé pour ton stockage car à par le NFS je vois pas d’autre solution.
Et puis, je dois juste mettre en place la solution alors il faut pas que je fasse quelques chose de complexe non plus.

Si tu peux m’aider stp.

Merci.

#25

Par exemple avec DRBD voir avec du Glusterfs, du moment que le volume reste acceptable pour le second et que tu ne dépasse pas les trois nœuds pour le premier ça passe sans soucis l’un comme l’autre et cela reste assez simple à mettre en place, attention toute fois, il faut mettre ne place la réplication en place avant tout déploiement de données.

#26

@valentin85,
Dans mon cas comme c’était pour un test en local et afin de mettre la solution rapidement en place sans prise de tête avec les solutions de réplication un peu casse tête, j’avais opté pour un NAS en RAID1.
Cela permet de tester rapidement la solution à petits prix.
Après à plus grande échelle, il est vrai que la solution de @Clochette est plutôt bonne .
Faut voir de quels moyens tu disposes et de ce que tu vais faire au final !!

#27

Bonjour @Clochette

Merci de ta réponse.
Voici mon schéma à jour :

Est-ce que ce système me permettra de redonder le service Seafile ?
Voyez-vous des SPOF ?

Merci.

#28

Pour les ‘Single Point Of Failure’, il faut veiller a ce que les machines soient sur des alimentations redondées et surtout branchées sur deux alimentations différentes (avec des onduleur serait un plus).
La partie Switch doit elle aussi être redondé et pas brancher sur la même alimentation électrique, sinon concernant le schéma c’est d’après moi correcte.

Attention le drdb doit-être monté avant tout dépose de donnée, et à mon humble avis les fichiers de conf de seafile et la/les bases de données peuvent être mise dessus, sinon il faudra couplé une synchronisation via rsync pour les fichiers de confs et autres de seafile

Un ‘PRA’ ne serait pas non plus une chose inutile selon l’importance que tu donne à ton bouzin (un troisième machine avec un mysql-replicator serait idéale pour être maintenu sans soucis et reprendre en cas de crash monstrueux l’activité le temps de remonté l’ensemble de ta solution from scratch avec des backups.

#29

@Clochette
C’est juste un maquettage que je dois faire donc pas besoin de penser à la partie alimentation et switch.

Donc dans l’ordre d’installation, je dois :
1 - Installation de DRBD sur les 2 noeuds
2 - Installation de Seafile
3 - Installation de MySQL
4 - Installation de Heartbeat

C’est ça ?

#30

Tu peux installé le heartbeat au début t’assurer que sa gestion soit okay et ensuite procéder à la création du volume drbd sur le master et le slave.
Une fois que tu aura tester que tout soit en place tu pourra installé Seafile et la bdd.

Encore une fois la conf de Seafile pourra être synchro avec du rsync et une crontab au besoin, et conserver uniquement de la data sur drdb.

PS : Monte le drdb, puis ensuite au besoin monte un lvm dedans si tu veux conserver de la souplesse.

#31

@Clochette

Merci de ta réponse.
Je vais essayer d’installer tout ça et je vous fait un retour.

#32

@Clochette @Theodreyz

Je recherchais quelques infos sur le web quand je suis tombé sur une info : Peut-on vraiment mettre en place un cluster en HA avec la solution Seafile Community ?
Je vois qu’avec la version Pro cela est possible mais j’ai des doutes sur la version community.

Pouvez-vous m’éclaircir ?

Merci.

#33

Bonjour @Clochette

Pourrais-tu m’expliquer la différence entre Pacemaker + COROSYNC et la solution HEARBEAT seul ?
Ainsi que les avantages inconvénients de ces solutions.

A quoi cela sert de couplé Pacemaker avec Heartbeat ?

Si tu peux me répondre rapidement stp

Merci d’avance.

#34

Désolé pour le temps d’attente, je n’ai pas suivi le fil et avec les vacances :confused:

Personnellement Corosync + Pacemaker me permet de finement gérer l’état de santé de services, heartbeat fais à peu de chose la même mais de façon plus grossière et beaucoup plus simple.

Pour moi le plus gros avantages de Corosync c’est la possibilité de relance de service avant une éventuelle bascule, ce qui permet bien souvent d’éviter de se taper une rebascule plus tard lorsqu’il y a eu un gros flop réseau empêchant la réplication d’une base de donnée de se faire.

Je dirais que c’est affaire de goûts :stuck_out_tongue: