Bonjour,
Je souhaiterai répliquer deux répertoires en temps réel sur deux Nas distants. Est-ce possible?
Le souhait:
Si un fichier est ajouté ou modifié sur le Nas01 sur sur le site 1, la création ou modification est effectué sur le Nas02 sur le site 2 en temps réel et inversement.
La réalité:
En créant deux taches de réplication (duplication??) distante RTRR (l'une du Nas01 vers le Nas02 et l'autre du Nas02 vers le Nas01), cela ne fonctionne pas.
Merci par avance, pour votre aide.
Réplication En Temps Réel Entre Deux Nas Ts-259 Pro+
Débuté par FredericFF, nov 07 2011 12:55
5 réponses à ce sujet
#1
Posté 07 novembre 2011 - 12:55
#2
Posté 07 novembre 2011 - 15:12
Bonjour,
Sauf erreur, la réplication temps réel, a pour but de mettre à jour une copie de fichier modifié d'un serveur vers un autre, dans un but de backup rapide de serveur en cas de crash ... cette réplication est à SENS UNIQUE, cette fonction utilise inotify (il me semble, même si il y a d'autre méthode possible).
Un fichier est surveillé (modification, création, ajout, suppression, etc.), en cas d'événement il est envoyé sur le répertoire cible, lequel si lui même est en surveillance ... sera, dans votre configuration, renvoyé vers le serveur 1, lequel voyant une modification sera envoyé vers le serveur 2 etc. etc. ... un système de détection de "deadlock" (boucle fatale) doit empêcher cela ... car on peut supposer aussi que deux même fichiers soient modifiés en même temps, donc avec un résultat non prédictible ...
Si c'est lié a des utilisateurs distincts, le mieux est de créer 2 taches de réplication PAS sur les même répertoire.
rep. READ sur A sert de source aux programmes qui écrivent sur WRITE de A ; idem READ de B sur WRITE de B
puis WRITE de A est synchronisé en temps réel sur READ de B et inversement ... mais cela demande de la discipline pour les utilisateurs.
ou alors travaillez en mode périodique avec RSYNC ...
ou utilisez UN seul répertoire pour TOUS vos utilisateur, l'un sera en local, l'autre en réseau (ou les 2 en réseau l'un en boucle TCPIP) l'altération d'un fichier déjà ouvert ne sera pas possible (au moins avec un "warning") et c'est ce répertoire que vous répliquez en temps réel, donc en cas de crash, il suffira de changer la cible des points de montage des partages réseau, pour que cela continu à fonctionner, si vous utilisez le regroupement de dossier, cela pourra être quasiment transparent ...
Dans tous les cas ne tester qu'une réplication après l'autre pour être sur que vous avez bien tout activé ...
Philippe.
Sauf erreur, la réplication temps réel, a pour but de mettre à jour une copie de fichier modifié d'un serveur vers un autre, dans un but de backup rapide de serveur en cas de crash ... cette réplication est à SENS UNIQUE, cette fonction utilise inotify (il me semble, même si il y a d'autre méthode possible).
Un fichier est surveillé (modification, création, ajout, suppression, etc.), en cas d'événement il est envoyé sur le répertoire cible, lequel si lui même est en surveillance ... sera, dans votre configuration, renvoyé vers le serveur 1, lequel voyant une modification sera envoyé vers le serveur 2 etc. etc. ... un système de détection de "deadlock" (boucle fatale) doit empêcher cela ... car on peut supposer aussi que deux même fichiers soient modifiés en même temps, donc avec un résultat non prédictible ...
Si c'est lié a des utilisateurs distincts, le mieux est de créer 2 taches de réplication PAS sur les même répertoire.
rep. READ sur A sert de source aux programmes qui écrivent sur WRITE de A ; idem READ de B sur WRITE de B
puis WRITE de A est synchronisé en temps réel sur READ de B et inversement ... mais cela demande de la discipline pour les utilisateurs.
ou alors travaillez en mode périodique avec RSYNC ...
ou utilisez UN seul répertoire pour TOUS vos utilisateur, l'un sera en local, l'autre en réseau (ou les 2 en réseau l'un en boucle TCPIP) l'altération d'un fichier déjà ouvert ne sera pas possible (au moins avec un "warning") et c'est ce répertoire que vous répliquez en temps réel, donc en cas de crash, il suffira de changer la cible des points de montage des partages réseau, pour que cela continu à fonctionner, si vous utilisez le regroupement de dossier, cela pourra être quasiment transparent ...
Dans tous les cas ne tester qu'une réplication après l'autre pour être sur que vous avez bien tout activé ...
Philippe.
QNAP TS-459, 3.6.0, Virtualbox, OpenVPN
QNAP TS-109, Debian Squeeze
QNAP TS-219P II, 3.6.1
La théorie, c’est quand on sait tout et que rien ne fonctionne. La pratique, c’est quand tout fonctionne et que personne ne sait pourquoi.
Le Raid N'EST PAS un backup (proverbe Qnapien)
QNAP TS-109, Debian Squeeze
QNAP TS-219P II, 3.6.1
La théorie, c’est quand on sait tout et que rien ne fonctionne. La pratique, c’est quand tout fonctionne et que personne ne sait pourquoi.
Le Raid N'EST PAS un backup (proverbe Qnapien)
#3
Posté 27 janvier 2012 - 23:17
Bonjour,
Je suis à la recherche (dans le cadre professionnel) d'une solution similaire à FredericFF.
Je m'explique dans mon entreprise nous avons 2 sites géographiquement différents relié par un VPN sur une ligne SDSL 2Mo.
Mon but est de mettre en place un nas sur chaque site (2xTS-412U ou 2xTS-459U-SP+) avec le contenu à l'identique, et faire en sorte que dès qu'un fichier est modifié sur un des 2 sites il est répliqué automatiquement sur l'autre site.
Je voulais savoir si la réplication tenait compte de la date/heure du fichier pour détecter que le fichier est modifié ?
Genre :
--- Config de départ : site identique ---
site 1, Fichier X (date du fichier 27-01-2012 17h05)
site 2, Fichier X (date du fichier 27-01-2012 17h05)
--- Modif du fichier sur site 1 ---
site 1, Fichier X (date du fichier 27-01-2012 22h00)
site 2, Fichier X (date du fichier 27-01-2012 17h05)
--- Réplication RTRR site 1 vers site 2 ---
site 1, Fichier X (date du fichier 27-01-2012 22h00)
site 2, Fichier X (date du fichier 27-01-2012 22h00)
--- Réplication RTRR site 2 vers site 1 ---
Vu que le fichier à été modifié sur le site 2 il va le copier sur le site 1 ... MAIS vu qu'il est identique, va t'il arreter la replication ou pas ? (et ne pas faire une boucle sans fin)
C'est peut-être un petit détail pour vous mais c'est trés important pour le projet là, ca permettrait d'avoir 2 nas physiques en 1 nas "logique" sur nos 2 sites avec un peu de décalage en fonction des fichiers modifés ou ajoutés mais nous gagnerions une souplesse et une sécurité accrue dans notre installation.
Gain de vitesse, car le site distant n'aura plus besoin d'attendre que le fichier se télécharge pour consulter des fichiers de notre site principal.
Gain de souplesse, le site distant n'aura plus besoin d'utiliser du TSE pour manipuler les fichiers trop gros (ce qui soulagera légérement notre serveur).
Gain de réactivité, en utilisant des NAS plutot que le serveur pour stocker les fichiers, si problème avec le serveur, les fichiers seraient toujours accessible
Gain de sécurité, car nous auront un "raid1" entre nos 2 sites, si un lache, l'autre ne sera pas du tout impacté et nous permettra d'avoir une sauvegarde.
Gain aussi sur la sauvegarde journalière qui engloberait directement les données des 2 sites sur une même sauvegarde (à l'heure actuelle, un seul site à droit à du raid et une sauvegarde journalière, pour le 2ème site, ben ... euh ... RIEN, alors faut vite pallier à ce problème) et si cette technique marche ca remplierait à merveille ce manque.
Après SI 2 utilisateurs différents (1 sur chaque site) modifient en même temps le même fichier sur leur NAS respectif, la il n'y a pas trop de solution, mais en même temps ca risque d'être assez rare étant donné que chaque site à sa spécificité et des besoins sur les fichiers pas tout a fait identique.
Merci d'avance pour vos réponses
Je suis à la recherche (dans le cadre professionnel) d'une solution similaire à FredericFF.
Je m'explique dans mon entreprise nous avons 2 sites géographiquement différents relié par un VPN sur une ligne SDSL 2Mo.
Mon but est de mettre en place un nas sur chaque site (2xTS-412U ou 2xTS-459U-SP+) avec le contenu à l'identique, et faire en sorte que dès qu'un fichier est modifié sur un des 2 sites il est répliqué automatiquement sur l'autre site.
Je voulais savoir si la réplication tenait compte de la date/heure du fichier pour détecter que le fichier est modifié ?
Genre :
--- Config de départ : site identique ---
site 1, Fichier X (date du fichier 27-01-2012 17h05)
site 2, Fichier X (date du fichier 27-01-2012 17h05)
--- Modif du fichier sur site 1 ---
site 1, Fichier X (date du fichier 27-01-2012 22h00)
site 2, Fichier X (date du fichier 27-01-2012 17h05)
--- Réplication RTRR site 1 vers site 2 ---
site 1, Fichier X (date du fichier 27-01-2012 22h00)
site 2, Fichier X (date du fichier 27-01-2012 22h00)
--- Réplication RTRR site 2 vers site 1 ---
Vu que le fichier à été modifié sur le site 2 il va le copier sur le site 1 ... MAIS vu qu'il est identique, va t'il arreter la replication ou pas ? (et ne pas faire une boucle sans fin)
C'est peut-être un petit détail pour vous mais c'est trés important pour le projet là, ca permettrait d'avoir 2 nas physiques en 1 nas "logique" sur nos 2 sites avec un peu de décalage en fonction des fichiers modifés ou ajoutés mais nous gagnerions une souplesse et une sécurité accrue dans notre installation.
Gain de vitesse, car le site distant n'aura plus besoin d'attendre que le fichier se télécharge pour consulter des fichiers de notre site principal.
Gain de souplesse, le site distant n'aura plus besoin d'utiliser du TSE pour manipuler les fichiers trop gros (ce qui soulagera légérement notre serveur).
Gain de réactivité, en utilisant des NAS plutot que le serveur pour stocker les fichiers, si problème avec le serveur, les fichiers seraient toujours accessible
Gain de sécurité, car nous auront un "raid1" entre nos 2 sites, si un lache, l'autre ne sera pas du tout impacté et nous permettra d'avoir une sauvegarde.
Gain aussi sur la sauvegarde journalière qui engloberait directement les données des 2 sites sur une même sauvegarde (à l'heure actuelle, un seul site à droit à du raid et une sauvegarde journalière, pour le 2ème site, ben ... euh ... RIEN, alors faut vite pallier à ce problème) et si cette technique marche ca remplierait à merveille ce manque.
Après SI 2 utilisateurs différents (1 sur chaque site) modifient en même temps le même fichier sur leur NAS respectif, la il n'y a pas trop de solution, mais en même temps ca risque d'être assez rare étant donné que chaque site à sa spécificité et des besoins sur les fichiers pas tout a fait identique.
Merci d'avance pour vos réponses
#4
Posté 28 janvier 2012 - 10:27
Bonjour,
Quelques principes pour "revoir" vos schémas ...
1 OUI la date est importante (date UTC (Universelle) pas la visible qui est "retraité" avec le Time Zone ) il est donc préférable d'utiliser sur chaque système le NTP (serveur de temps)
2 La réplication Temps Réel travaille au niveau répertoire et non fichier ... ET mono sens Système 1 vers système 2 ou l'inverse ... IL Y A toujours un maitre et un esclave ...
Il vaut mieux (dans votre cas, que les répertoires modifiés a dupliquer de chacun soient différents) ..
... sinon, en effet il peut y avoir des "boucles" infernales ....
3 votre demande est plutôt sur la distribution de file system ... ce qui est un chouïa plus complexe ... une ligne VDSL symétrique a 2 Mb/s est limite ... mais si c'est 2 Moct/s ... là cela devient jouable ...
4 ) si des utilisateurs, peuvent potentiellement modifier un fichier des deux cotés ... là cela ne va pas être facile ... sans une stratégie de priorités ... une bonne solution consiste, si possible a gérer des "versions" ou via un journal de modification a collationner plus tard ... mais c'est toujours très complexe ...
OU alors utiliser les partages (regroupement) et faites travailler les utilisateurs sur le même fichier (répliqué plus tard) un seul (sauf autorisation spéciale) aura le droit de le modifier ... à la fois.
5 ) si vous mettez les fichiers dans des répertoires différents, il sera possible de traiter en différé (localement) la resynchronisation du tout, n'oubliez pas qu'il est possible via les outils Linux de copier, déplacer, sauvegardé (tar) en maintenant les attributs originels ...
6 ) quand on a pas (et même si on en a) le backup est TOUJOURS un bien ...
... vous pouvez utiliser la réplication temps réel ... vers un disque externe ... et "enlever / emmener" le disque le soir, cela au moins sauvera les données de la journée ... et pourra être, en cas de malheur, emmené sur le second site ...
7 ) un conseil (donc a ne pas suivre ... ) c'est de revoir le besoin réel, pour ne pas "monter" une usine à gaz ... alors qu'une solution avec un délai raisonnable (heure) suffirait a ne pas "bloquer" votre activité ...
Philippe.
Quelques principes pour "revoir" vos schémas ...
1 OUI la date est importante (date UTC (Universelle) pas la visible qui est "retraité" avec le Time Zone ) il est donc préférable d'utiliser sur chaque système le NTP (serveur de temps)
2 La réplication Temps Réel travaille au niveau répertoire et non fichier ... ET mono sens Système 1 vers système 2 ou l'inverse ... IL Y A toujours un maitre et un esclave ...
Il vaut mieux (dans votre cas, que les répertoires modifiés a dupliquer de chacun soient différents) ..
... sinon, en effet il peut y avoir des "boucles" infernales ....
3 votre demande est plutôt sur la distribution de file system ... ce qui est un chouïa plus complexe ... une ligne VDSL symétrique a 2 Mb/s est limite ... mais si c'est 2 Moct/s ... là cela devient jouable ...
4 ) si des utilisateurs, peuvent potentiellement modifier un fichier des deux cotés ... là cela ne va pas être facile ... sans une stratégie de priorités ... une bonne solution consiste, si possible a gérer des "versions" ou via un journal de modification a collationner plus tard ... mais c'est toujours très complexe ...
OU alors utiliser les partages (regroupement) et faites travailler les utilisateurs sur le même fichier (répliqué plus tard) un seul (sauf autorisation spéciale) aura le droit de le modifier ... à la fois.
5 ) si vous mettez les fichiers dans des répertoires différents, il sera possible de traiter en différé (localement) la resynchronisation du tout, n'oubliez pas qu'il est possible via les outils Linux de copier, déplacer, sauvegardé (tar) en maintenant les attributs originels ...
6 ) quand on a pas (et même si on en a) le backup est TOUJOURS un bien ...
... vous pouvez utiliser la réplication temps réel ... vers un disque externe ... et "enlever / emmener" le disque le soir, cela au moins sauvera les données de la journée ... et pourra être, en cas de malheur, emmené sur le second site ...
7 ) un conseil (donc a ne pas suivre ... ) c'est de revoir le besoin réel, pour ne pas "monter" une usine à gaz ... alors qu'une solution avec un délai raisonnable (heure) suffirait a ne pas "bloquer" votre activité ...
Philippe.
QNAP TS-459, 3.6.0, Virtualbox, OpenVPN
QNAP TS-109, Debian Squeeze
QNAP TS-219P II, 3.6.1
La théorie, c’est quand on sait tout et que rien ne fonctionne. La pratique, c’est quand tout fonctionne et que personne ne sait pourquoi.
Le Raid N'EST PAS un backup (proverbe Qnapien)
QNAP TS-109, Debian Squeeze
QNAP TS-219P II, 3.6.1
La théorie, c’est quand on sait tout et que rien ne fonctionne. La pratique, c’est quand tout fonctionne et que personne ne sait pourquoi.
Le Raid N'EST PAS un backup (proverbe Qnapien)
#5
Posté 28 janvier 2012 - 13:34
Quand la replication travaille sur la date (UTC) du fichier, si on copie un fichier sur le 2eme site, la date (UTC) du fichier prend la date (UTC) qu'il a été copié sur le 2eme NAS ou alors il garde la date (UTC) de la dernière modif fait au fichier sur le 1er NAS ?
Après niveau personnel, ca reste une petite structure site 1 (environ 15-20 personnes dont 7 nomades pouvant travailler occasionnellement sur le 2eme site) et le site 2 (8 personnes dont 3 nomades pouvant travailler egalement sur le site 1) et beaucoup de personnes travaillent sur une base de données qui reste et resterait sur le site 1 et accessible au site 2 uniquement en TSE, c'est juste pour les fichiers reseaux annexes.
Après chaque site utilise des fichiers et dossiers différents concernant leurs domaines, il y a juste la gestion documentaire qui est lié aux 2 sites, ce qui m'interesse c'est surtout au niveau des utilisateurs nomades qu'ils puissent modifier ou créer des fichiers depuis n'importe quel site et avoir la souplesse et la vitesse d'un LAN et la repercussion sur les 2 sites
Cette semaine je vais suivre l'évolution des fichiers sur une semaine pour detecter les fichiers modifiés ou ajoutés pour quantifier le nombre de données qui auraient a transferer d'un site à l'autre, j'estime avoir un débit moyen de 50ko/s pendant les heures de bureau et avoir 150ko/s hors horaires de bureau, ce qui represente environ 1.5Go en journée et environ 6Go de nuit, ce qui donnent environ 7.5 Go de données possible à transferer, ce qui me parait enorme vu l'activité qu'on a, je ne pense pas les atteindre mais je verrais bien cette semaine.
Après y'aurait-il une autre solution exploitable pour faire ce que je souhaite "2 NAS physiques en 1 NAS logique" (j'ai bien mis entre guillemets) quitte a utiliser un système concurrent ... ?
Après niveau personnel, ca reste une petite structure site 1 (environ 15-20 personnes dont 7 nomades pouvant travailler occasionnellement sur le 2eme site) et le site 2 (8 personnes dont 3 nomades pouvant travailler egalement sur le site 1) et beaucoup de personnes travaillent sur une base de données qui reste et resterait sur le site 1 et accessible au site 2 uniquement en TSE, c'est juste pour les fichiers reseaux annexes.
Après chaque site utilise des fichiers et dossiers différents concernant leurs domaines, il y a juste la gestion documentaire qui est lié aux 2 sites, ce qui m'interesse c'est surtout au niveau des utilisateurs nomades qu'ils puissent modifier ou créer des fichiers depuis n'importe quel site et avoir la souplesse et la vitesse d'un LAN et la repercussion sur les 2 sites
Cette semaine je vais suivre l'évolution des fichiers sur une semaine pour detecter les fichiers modifiés ou ajoutés pour quantifier le nombre de données qui auraient a transferer d'un site à l'autre, j'estime avoir un débit moyen de 50ko/s pendant les heures de bureau et avoir 150ko/s hors horaires de bureau, ce qui represente environ 1.5Go en journée et environ 6Go de nuit, ce qui donnent environ 7.5 Go de données possible à transferer, ce qui me parait enorme vu l'activité qu'on a, je ne pense pas les atteindre mais je verrais bien cette semaine.
Après y'aurait-il une autre solution exploitable pour faire ce que je souhaite "2 NAS physiques en 1 NAS logique" (j'ai bien mis entre guillemets) quitte a utiliser un système concurrent ... ?
#6
Posté 28 janvier 2012 - 18:06
Bonjour,
Je ne sais pas pour 2 NAS en 1 ... toutes les solutions (dont certaines applicable au QNAP) demande un lien Ethernet de bon débit ... ce qui risque de ne pas être votre cas ...
La réplication se faisant au fur et à mesure, si elle est ciblé ... ne devrait pas impacter trop durement vos performances ... j'ai répliquer entre 2 sites en France distant de 600 Kms (2 Qnap) un fichier iso de 2,2GB en 40 mns (log de RTRR) ... soit presque 1MB/sec ... mais j'ai des abonnements assez "forts" et bien sur dans le meilleur sens, puisque Dissymétrique comme tout opérateurs ADSL ou Câble ...
Philippe.
Je ne sais pas pour 2 NAS en 1 ... toutes les solutions (dont certaines applicable au QNAP) demande un lien Ethernet de bon débit ... ce qui risque de ne pas être votre cas ...
La réplication se faisant au fur et à mesure, si elle est ciblé ... ne devrait pas impacter trop durement vos performances ... j'ai répliquer entre 2 sites en France distant de 600 Kms (2 Qnap) un fichier iso de 2,2GB en 40 mns (log de RTRR) ... soit presque 1MB/sec ... mais j'ai des abonnements assez "forts" et bien sur dans le meilleur sens, puisque Dissymétrique comme tout opérateurs ADSL ou Câble ...
Philippe.
QNAP TS-459, 3.6.0, Virtualbox, OpenVPN
QNAP TS-109, Debian Squeeze
QNAP TS-219P II, 3.6.1
La théorie, c’est quand on sait tout et que rien ne fonctionne. La pratique, c’est quand tout fonctionne et que personne ne sait pourquoi.
Le Raid N'EST PAS un backup (proverbe Qnapien)
QNAP TS-109, Debian Squeeze
QNAP TS-219P II, 3.6.1
La théorie, c’est quand on sait tout et que rien ne fonctionne. La pratique, c’est quand tout fonctionne et que personne ne sait pourquoi.
Le Raid N'EST PAS un backup (proverbe Qnapien)
1 utilisateur(s) li(sen)t ce sujet
0 membre(s), 1 invité(s), 0 utilisateur(s) anonyme(s)














