Réplication entre 2 serveurs

Message par **Zedoune** » mer. 27 janv. 2016 10:09

Bonjour,

Je cherche un moyen de répliquer un répertoire entre 2 serveurs (2 et seulement 2 sans rien d'externe) situés à 2 endroits différents (donc 10 Mo/s de débit et 15 ms de ping)

Il existe plusieurs méthodes de réplication :

=> système de fichiers réseau, où chaque machine peut écrire/lire en même temps dessus, comme GlusterFS (mooseFS ne rentre pas ici car il faut 3 machines minimum)
=> réplication temps-réel à un niveau bloc : DRDB, HAST, raid 1 de 2 exports iSCSI
=> réplication "cadencée" qui consiste à utiliser un système de copie à intervalle régulier : transférer des snapshots ZFS, rsync
=> réplication asynchrone qui consiste à répliquer les données au fur et à mesure qu'elles sont écrites sur le serveur maître sans le bloquer : HammerFS stream (comme du snapshot ZFS mais en "stream"), bases de données

Je cherche principalement une méthode de réplication asynchrone puisque sur un débit faible et une grande latence il n'y a que ça qui me semble viable, mais les bases de données on peut pas s'en servir comme un système de fichiers, et hammerFS il marche que sous dragonfly BSD ..

Message par **gizmo78** » mer. 27 janv. 2016 10:35

Question:
La source des données?
Ca va directement du source vers les deux cibles?
Pas de connexion possible entre les deux serveurs destinataires?

Message par **kalistyan** » mer. 27 janv. 2016 10:44

Pour information, GlusterFS propose un mode de Geo-replication (Asynchrone).

=> https://gluster.readthedocs.org/en/late ... plication/

Message par **Zedoune** » mer. 27 janv. 2016 10:54

Question:
La source des données?
Ca va directement du source vers les deux cibles?
Pas de connexion possible entre les deux serveurs destinataires?

La source de données c'est le serveur maitre

genre un site avec une base de données et des fichiers uploadés dessus

Pour information,GlusterFS propose un mode de Geo-replication (Asynchrone).

=> https://gluster.readthedocs.org/en/late ... plication/

Intéressant

Message par **TheMartel** » mer. 27 janv. 2016 15:16

J'avais regardé fu un temps pour faire une espece de raid5 de serveurs

Histoire de pas trop faire exploser le budget "sauvegarde" sur un projet avec des centaines de To de data... et un besoin d'accès a la donné limité.

Mes souvenir c'est que c'était chaud

Message par **dsebire** » mer. 27 janv. 2016 15:26

Z, sous Windows c'est natif

Oui, ca aide pas je sais

Message par **kalistyan** » mer. 27 janv. 2016 15:30

Message par **Zedoune** » mer. 27 janv. 2016 15:42

Z, sous Windows c'est natif
Oui, ca aide pas je sais

Je suis pas sectaire !

Tu fais comment sous windows ? (je critique très très rarement les autres systèmes si tu fais bien attention ! J'ai rien contre les gens qui utilisent windows

)

Message par **kalistyan** » mer. 27 janv. 2016 15:46

dsebire soit faire allusion à la réplication DFS.
=> https://technet.microsoft.com/fr-fr/lib ... 81957.aspx

Message par **dsebire** » mer. 27 janv. 2016 15:52

Dfs pour les fichiers, ya la repli sal pouf les bdd

Message par **Zedoune** » mer. 27 janv. 2016 15:55

Dfs pour les fichiers, ya la repli sal pouf les bdd

Pour les BDD en général ils ont tous une méthode pour se synchroniser donc y a pas de problème.

Pour les fichiers, je comprends rien aux explications de DFS que j'ai pu trouver ne connaissant pas du tout Windows ^^ mais ça a l'air chouette

Message par **dsebire** » jeu. 28 janv. 2016 10:10

yop !

bon, ayant plus de temps, j'explique le principe

a la base, DFS c'est pour du système de fichiers distribués.
on crée une racine, dans laquelle on ajoute des dossiers qui peuvent être situés sur des serveurs différents.
ça permet sur le principe d'accéder a tous les filers d'une entreprise a partir d'un seul point d'entrée.
ces filers peuvent être sur des sites géographiquement différents, c'est pas un problème (ça permet d'avoir la même conf sur 2 sites d'une même entreprise et de donner accès a tout le monde a la même chose)

il y a une surcouche à DFS qui s'appelle DFSR, le R pour réplication

ce système permet de répliquer des dossiers dans une racine DFS entre 2 serveurs (n'importe ou qu'ils soient)
c'est basé sur les journaux NTFS (donc ça ne marche que sur des partitions NTFS) et ça envoie en asynchrone le chemin des fichiers à répliquer a tous les membres de la réplication. ce sont ensuite les machines recevant ces modifs qui vont aller chercher sur l'autre serveur le fichier en lui même.
sur le principe, pas besoin d'avoir une connexion permanente, tu peux même configurer la repli pour ne tourner que la nuit par exemple.
un des filers peut être éteint pendant 6 mois, il reprendra la repli la ou il s'est arrêté.

ça permet:
-- de basculer automatiquement d'un serveur sur un autre de manière transparente pour l'utilisateur en cas de panne.
-- le système est bien branlé, et sans avoir a configurer quoi que ce soit, tu pointera sur le serveur le plus proche de toi (nombre de sauts entre client et serveur) en cas des sites géographiques différents, tout en conservant la haute dispo
-- ça a 1 seul inconvénient: la réplication ne tiens pas compte des locks sur les fichiers et donc peut causer de la perte de données. cas concret: utilisateur A sur site A ouvre fichier X. utilisateur B sur site B ouvre le même fichier X. ça fonctionnera vu que pas de lock car sur 2 filers différents. c'est le dernier a sauvegarder son fichier qui écrasera les modifs de l'autre, car la réplication prendra la version la plus récente dans tous les cas (dans la pratique, un conflit sera détecté et le fichier plus ancien en conflit sera copié dans un répertoire réservé a cet effet)

le système DFSR (enfin son ancêtre NTFRS) est utilisé pour répliquer les fichiers entre les contrôleurs de domaine Windows (le répertoire sysvol et netlogon pour ceux qui connaissent)

Message par **gizmo78** » jeu. 28 janv. 2016 11:55

Dixit un collègue qui a validé ce type de replication (pour des vm), ils ont utilisés pour le PoC: quadstore

Message par **augur1** » jeu. 28 janv. 2016 16:16

Dfs pour les fichiers, ya la repli sal pouf les bdd

Sauf à mettre la bdd sur une CentOS ou autres dans un Hyper-V ; ce sera ainsi la VM qui sera répliquée.

Pour ZFS, j'avais énuméré des possibilités
-> http://smpfr.mesdiscussions.net/smpfr/S ... htm#t33275

Message par **Zedoune** » jeu. 28 janv. 2016 16:23

Sauf à mettre la bdd sur une CentOS ou autres dans un Hyper-V ; ce sera ainsi la VM qui sera répliquée.

Pour ZFS, j'avais énuméré des possibilités
-> http://smpfr.mesdiscussions.net/smpfr/S ... htm#t33275

les BDD ça se réplique parfaitement bien

Et pour ZFS j'en ai déjà parlé en autre avec un zfs send | zfs recv

Message par **TheMartel** » jeu. 28 janv. 2016 16:47

yop !

bon, ayant plus de temps, j'explique le principe

a la base, DFS c'est pour du système de fichiers distribués.
on crée une racine, dans laquelle on ajoute des dossiers qui peuvent être situés sur des serveurs différents.
ça permet sur le principe d'accéder a tous les filers d'une entreprise a partir d'un seul point d'entrée.
ces filers peuvent être sur des sites géographiquement différents, c'est pas un problème (ça permet d'avoir la même conf sur 2 sites d'une même entreprise et de donner accès a tout le monde a la même chose)

il y a une surcouche à DFS qui s'appelle DFSR, le R pour réplication
ce système permet de répliquer des dossiers dans une racine DFS entre 2 serveurs (n'importe ou qu'ils soient)
c'est basé sur les journaux NTFS (donc ça ne marche que sur des partitions NTFS) et ça envoie en asynchrone le chemin des fichiers à répliquer a tous les membres de la réplication. ce sont ensuite les machines recevant ces modifs qui vont aller chercher sur l'autre serveur le fichier en lui même.
sur le principe, pas besoin d'avoir une connexion permanente, tu peux même configurer la repli pour ne tourner que la nuit par exemple.
un des filers peut être éteint pendant 6 mois, il reprendra la repli la ou il s'est arrêté.

ça permet:
-- de basculer automatiquement d'un serveur sur un autre de manière transparente pour l'utilisateur en cas de panne.
-- le système est bien branlé, et sans avoir a configurer quoi que ce soit, tu pointera sur le serveur le plus proche de toi (nombre de sauts entre client et serveur) en cas des sites géographiques différents, tout en conservant la haute dispo
-- ça a 1 seul inconvénient: la réplication ne tiens pas compte des locks sur les fichiers et donc peut causer de la perte de données. cas concret: utilisateur A sur site A ouvre fichier X. utilisateur B sur site B ouvre le même fichier X. ça fonctionnera vu que pas de lock car sur 2 filers différents. c'est le dernier a sauvegarder son fichier qui écrasera les modifs de l'autre, car la réplication prendra la version la plus récente dans tous les cas (dans la pratique, un conflit sera détecté et le fichier plus ancien en conflit sera copié dans un répertoire réservé a cet effet)

le système DFSR (enfin son ancêtre NTFRS) est utilisé pour répliquer les fichiers entre les contrôleurs de domaine Windows (le répertoire sysvol et netlogon pour ceux qui connaissent)

ça correspond donc a un besoin:
- unification de l'ensemble des espaces de stockage d'une entité (la réplication osef

, c'est pour les anxieux )
- accès à la donnée par le chemin le plus court disponible.

Je me trompe pas?
Par contre tu accèdes à la donnée à travers quoi du coup?

Message par **Zedoune** » jeu. 28 janv. 2016 16:49

ça correspond donc a un besoin:
- unification de l'ensemble des espaces de stockage d'une entité (la réplication osef , c'est pour les anxieux )
- accès à la donnée par le chemin le plus court disponible.

Je me trompe pas?
Par contre tu accèdes à la donnée à travers quoi du coup?

faut bien répliquer tes données si tu veux qu'elles soient à plusieurs endroits [:trollface]

Message par **dsebire** » jeu. 28 janv. 2016 18:10

ça correspond donc a un besoin:
- unification de l'ensemble des espaces de stockage d'une entité (la réplication osef , c'est pour les anxieux )
- accès à la donnée par le chemin le plus court disponible.

Je me trompe pas?
Par contre tu accèdes à la donnée à travers quoi du coup?

c'est ça

tu y accede a partir de ton explorateur de fichiers habituel.
sauf qu'au lieu de monter le partage du serveur (\\serveur\partage) tu monte le partage dans la racine (\\racine\partage)
tu peux mettre les partages cachés sur les serveur et les afficher seulement sur la (les) racine(s)

faut bien répliquer tes données si tu veux qu'elles soient à plusieurs endroits [:trollface]

evidement !
c'est d'ailleurs très pratique pour le PCA par exemple

ton site de secours est up & running en permanence, et ça bascule automatiquement (mis en place chez un client depuis 2010, jamais eu de pb)

Message par **dsebire** » jeu. 28 janv. 2016 18:12

pour info, on peut donner un poids pour chaque membre dans une réplication, ce qui fait que vous pouvez avoir une réplication sur le même site, et pointer toujours sur le même serveur (pour éviter les pbs de lock de fichiers expliqués au dessus)
vous basculerez sur le serveur qui a le poids le plus faible seulement si celui qui a le poids le plus fort est injoignable

Message par **augur1** » jeu. 28 janv. 2016 19:33

=> système de fichiers réseau, où chaque machine peut écrire/lire en même temps dessus, comme GlusterFS (mooseFS ne rentre pas ici car il faut 3 machines minimum)

Et Lustre ?

Message par **Zedoune** » jeu. 28 janv. 2016 19:39

Et Lustre ?

Lustre pourrait marcher avec 2 serveurs, mais ça pompe un peu de ressources car il faut un serveur de méta données et un serveur de données, et donc les 2 machines devraient faire tourner les 2, mais ça peut marcher

Message par **augur1** » jeu. 28 janv. 2016 20:39

Ce serait risqué / envisageable d'avoir :
- 1 OS barmetal + VM Zfs ZoL & Lustre + VM mdt main sur un site
- 1 OS barmetal + VM Zfs ZoL & Lustre + VM mdt backup sur un autre site
... les 2 ensembles synchros ?

Message par **Zedoune** » jeu. 28 janv. 2016 21:11

Ce serait risqué / envisageable d'avoir :
- 1 OS barmetal + VM Zfs ZoL & Lustre + VM mdt main sur un site
- 1 OS barmetal + VM Zfs ZoL & Lustre + VM mdt backup sur un autre site
... les 2 ensembles synchros ?

ça apporte quoi de mettre les 2 services sur 2 VM plutot que les 2 services sur la même machine à part perdre des performances ?

Et pourquoi tu veux mettre du ZFS ?

Message par **augur1** » jeu. 28 janv. 2016 21:30

De ce que j'ai vu : il faudrait 4 machines physiques pour faire tourner Lustre en HA : 2 mdt + 2 san

Lustre en surcouche de Zfs : ce que propose la doc de ZoL et autres intégrateurs.

Message par **Zedoune** » jeu. 28 janv. 2016 22:02

J'ai dis dans le sujet qu'on discutait de solutions pour 2 machines seulement

Interdiction d'utiliser d'autres machines :d