Bonjour,
En lieu et place d’un serveur à tolérance de panne équipé d’une double alimentation, double carte réseau, RAID et double contrôleur de disques serait-il possible d’installer deux serveurs, un en master et l’autre en slave? Quelle solutions voyez-vous?
Au pis aller, un rsync asynchrone mais j’aimerais autant utiliser un mirroring synchrone.
en raid over Ip il existe drbd, ça te fait du raid au travers d’un réseau.
Sinon, fichier sur le premier et serveur de backup sur le second 
attention pour le synchrone,
si le slave a ses vapeurs,
le master va se mettre à mouliner,
sans faire de pub, je connaissais 2 “marques” tolérance de panne,
dont une qui avait 2µP, pour recalculer l’exactitude du travail du premier µP
A+
JB1
Je viens d’essayer glusterFS et, après une grosse prise de tête avec un switch Cisco (layer 2) qui se permet de faire du layer 3 et qui filtre certaines trames, ça tourne pas trop mal.
@jb1: une fois la réplication construite, on peut même arrêter le glusterfs-server sur le slave sans interrompre le mirroring. Je pense que c’est fuse qui prend le relais.
Je dois encore peaufiner les permissions mais je pense que ça fera l’affaire sauf si vous avez d’autres idées.
Ça dépend. Quels services tourneront sur le serveur ?
Uniquement serveur de fichiers dans un environnement Windows ainsi qu’un serveur DHCP (ISC) qui sera déjà en mode master/slave (failover). La duplication synchrone ne concernera donc que les fichiers servis par samba. En cas de faiblesse d’un des deux serveurs, le basculement ne doit pas nécessairement se faire automatiquement mais les fichiers utilisateurs doivent être à jour.
L’offre alternative est classique: Windows Server (SBS), 2 CPU Xeon, 32 Go de ram, 5 disques en RAID 5, double alim, double ethernet se monte à près de 10.000 €. Je me dis que Linux devrait proposer aussi bien pour moins cher.
Edit: J’ai continué mon marché et il semble n’y avoir que quelques joueurs dans cette cour de Distributed FS.
[ul]
[li] GlusterFS que je teste. Userspace FS (FUSE)[/li]
[li] DRBD suggéré plus haut par grigric. Limité à deux noeuds et pas plus dans la version actuelle.[/li]
[li] CephFS (kernel FS ou FUSE, au choix)[/li][/ul]
Pour du serveur de fichier, c’est effectivement vers ce type de solution qu’il faut avoir.
Comme tu l’as dit, tu peux aussi faire un rsync en boucle (ou utiliser lsyncd si tu n’as pas trop d’inodes à surveiller ou peu d’écritures), mais ça a l’inconvénient d’être asynchrone. De plus même si ça a l’avantage de pouvoir être mis en place rapidement, c’est plus emmerdant à monitorer.
Il y a aussi bittorrent sync, mais c’est AMA trop overkill pour une synchro entre deux serveurs.
Note qu’il faudra aussi synchroniser ta conf et tes comptes samba. Vois aussi comment se comportent les windows en cas de bascule (je ne suis pas persuadé que le montage se refasse automatiquement avec le slave).
rsync en boucle, tu vas brûler tes IO pour peu que le nombre de fichier soit important
rsync fait la liste des fichiers avant le transfert, et c’est parfois long
GlusterFS et CephFS ont l’air solide. Ils sont d’ailleurs tous deux candidats pour être intégrés a OpenStack.
CephFS semble plus difficile à installer. GlusterFS par contre est très simple à mettre en oeuvre. Après l’installation du paquet glusterfs-server il suffit de quelques lignes de commandes pour créer une connexion avec un ou plusieurs peer, créer les volumes, les démarrer et les monter. J’ai suivi cet excellent tuto (plusieurs parties. Bien lire la suite sur le montage et les “Related Posts” en bas de page).
Si ça vous amuse, il faut moins de 5 minutes pour créer un cluster. J’ai fait des essais concluants sur deux Raspberry Pi (256 Mo de ram!)
Doc Gluster: Admin Guide (pdf)
[quote=“grigric”]en raid over Ip il existe drbd, ça te fait du raid au travers d’un réseau.
Sinon, fichier sur le premier et serveur de backup sur le second [/quote]
Je plussoie l’utilisation de DRDB dans le cas ou l’on ne dépasse pas les deux noeud (il me semble possible dorénavant d’avoir trois noeud mais pas plus).
Sinon l’utilisation d’une crontab toute les 10 minutes avec une vérification d’unicité afin d’éviter un empilement de tâche de synchronisation reste le plus simple à mettre ne place et permet même d’exclure les dossiers qui ne seront pas à synchroniser.
Dans tous les cas le passage par deux cartes réseaux est un plus pour éviter les engorgements de bande passante dans le cas de haute disponibilité et de fort trafic.
A essayer.
C’est la solution la plus simple à mettre en place mais c’est asynchrone. Et augmenter la fréquence de synchronisation risque fort de solliciter le CPU. Rsync doit découper les fichiers (et ils sont nombreux) et faire un double calcul de checksum (MD5 + rolling checksum) sur chacun des morceaux, sur les deux serveurs.