Bonjour la liste, Ya un thread en cours qui m'a fait penser que vous pourriez peut-etre m'aider sur une problematique que j'ai. Mise en situation : un SAN d'environ 250 To, plusieurs milliards de fichiers, dont une bonne partie change quotidiennement (environ 20-30 To). Projet : migrer le SAN (d'un fabricant X) vers un nouveau SAN (fabricant Y), sans interrompre la prod. La solution la moins pourrie à laquelle on a réfléchi jusque la, c'est : - un premier "cp", bien bourrin, qui va prendre plusieurs jours vraisemblablement - suivi de plusieurs rsync, ou des "rsync par morceaux" (on rsync un "repertoire", puis on previent l'applicatif "attention, tes données sont sur le nouveau SAN"). Mais bon, on a peur avec le rsync qu'il prenne des plombes, et qu'entre le scan des repertoire et la copie réelle, yait eu du mouvement, etc... Sachant que c'est une "one-time operation", pas besoin de rester sur la durée, auriez-vous de bonnes idées à me soumettre ? Merci d'avance. Burps -- You Rock! Your E-Mail Should Too! Signup Now at Rock.com and get 2GB of Storage! http://connections.rock.com/user/displayUserRegisterPage.kickAction?as=11674...
Bonjour,
La solution la moins pourrie à laquelle on a réfléchi jusque la, c'est : - un premier "cp", bien bourrin, qui va prendre plusieurs jours vraisemblablement - suivi de plusieurs rsync, ou des "rsync par morceaux" (on rsync un "repertoire", puis on previent l'applicatif "attention, tes données sont sur le nouveau SAN").
- 1er rsync bourrin - par morceaux/dossiers : - 2ème rsync - l'applicatif fait le taf (copie, modif) sur les 2 SAN - 3eme rsync (pas de --delete) - l'applicatif fait le taf que sur le nouveau. -- Greg
----- Message d'origine ---- De : Burps Burps <burps@rock.com> À : frsag@frsag.org Envoyé le : Jeu 22 juillet 2010, 17h 10min 50s Objet : [FRsaG] Synchro en masse Bonjour la liste, Ya un thread en cours qui m'a fait penser que vous pourriez peut-etre m'aider sur une problematique que j'ai. Mise en situation : un SAN d'environ 250 To, plusieurs milliards de fichiers, dont une bonne partie change quotidiennement (environ 20-30 To). Projet : migrer le SAN (d'un fabricant X) vers un nouveau SAN (fabricant Y), sans interrompre la prod. La solution la moins pourrie à laquelle on a réfléchi jusque la, c'est : - un premier "cp", bien bourrin, qui va prendre plusieurs jours vraisemblablement - suivi de plusieurs rsync, ou des "rsync par morceaux" (on rsync un "repertoire", puis on previent l'applicatif "attention, tes données sont sur le nouveau SAN"). Mais bon, on a peur avec le rsync qu'il prenne des plombes, et qu'entre le scan des repertoire et la copie réelle, yait eu du mouvement, etc... Sachant que c'est une "one-time operation", pas besoin de rester sur la durée, auriez-vous de bonnes idées à me soumettre ? Merci d'avance. Burps -- You Rock! Your E-Mail Should Too! Signup Now at Rock.com and get 2GB of Storage! http://connections.rock.com/user/displayUserRegisterPage.kickAction?as=11674... _______________________________________________ FRsaG mailing list FRsaG@frsag.org http://www.frsag.org/mailman/listinfo/frsag Je penses que idéalement il faudrait faire de la réplication baie à baie, mais avec des baies de constructeurs différents ca me semble impossible. C'est quoi les OS qui utilisent le SAN, peut être qu'une solution possible serait de faire un mirroring LVM par exemple. Ca peut prendre du temps mais c est complètement transparent pour l'applicatif.
Le 22/07/2010 17:21, Renaud Hager a écrit :
[...]
SVP lisez la Netiquette : http://fr.wikipedia.org/wiki/N%C3%A9tiquette#Courrier_.C3.A9lectronique -- Greg
Le 22/07/10, Burps Burps<burps@rock.com> a écrit :
Bonjour la liste,
Ya un thread en cours qui m'a fait penser que vous pourriez peut-etre m'aider sur une problematique que j'ai.
Mise en situation : un SAN d'environ 250 To, plusieurs milliards de fichiers, dont une bonne partie change quotidiennement (environ 20-30 To).
Projet : migrer le SAN (d'un fabricant X) vers un nouveau SAN (fabricant Y), sans interrompre la prod.
La solution la moins pourrie à laquelle on a réfléchi jusque la, c'est : - un premier "cp", bien bourrin, qui va prendre plusieurs jours vraisemblablement
Au niveau vitesse, tar + netcat est imbattable.
La solution la moins pourrie à laquelle on a réfléchi jusque la, c'est : - un premier "cp", bien bourrin, qui va prendre plusieurs jours vraisemblablement
Au niveau vitesse, tar + netcat est imbattable.
C'est clair ou encore plus bourrin... dump + netcat // netcat + restore.. .:) On peux aussi le faire a coup de cpio :) Xavier
2010/7/22 Xavier Beaudouin <kiwi@oav.net>
La solution la moins pourrie à laquelle on a réfléchi jusque la, c'est : - un premier "cp", bien bourrin, qui va prendre plusieurs jours vraisemblablement
Au niveau vitesse, tar + netcat est imbattable.
C'est clair ou encore plus bourrin... dump + netcat // netcat + restore.. .:)
On peux aussi le faire a coup de cpio :)
Xavier
_______________________________________________ FRsaG mailing list FRsaG@frsag.org http://www.frsag.org/mailman/listinfo/frsag
je vote cpio :)
Bonsoir, Idée complètement farfelue, et pas vraiment creusée, mais j'ai un eeepc sous les yeux... et le ssd est en ro, et ils ont fait un unionfs avec de la ram pour éviter qu'on fasse gratter le ssd avec des logs et cache. Même idée : ancien SAN en RO, nouveau SAN en RW, UnionFS entre les deux. Reste faire un petit utilitaire qui lit tous les fichiers et les réécrit à l'identique. Les nouvelles écritures faites par ton application sont directement sur le nouveau SAN. J'avoue que j'ai jamais trop gratté unionfs non plus : peut etre que c'est juste pas faisable. Peut être il y a qqn de plus qualifié par ici sur cette techno et qui aurait juste pas eu l'idée. Sinon désolé pour le bruit :) Florian MAURY
Salut, LVM mirroring est souvent utilisé pour répliquer 2 SAN situés sur des sites différents. On doit pouvoir utiliser cette technique pour répliquer 2 SAN localement et ensuite supprimer le miroir (lvconvert) Dans le même genre drdb ou autre peut faire la copie Par contre ça risque de nécessiter pas mal de préparation pour maîtriser les manips... Avec rsync vu le temps qu'il met à scanner c'est obligé de perdre des fichiers. Généralement il faut arrêter l'applicatif pendant le 2ème rsync. a+ On 22/07/2010 5:10, Burps Burps wrote:
participants (8)
-
Alexandre -
Bedis 9 -
Burps Burps -
Florian MAURY -
Greg -
Renaud Hager -
Rémi Bouhl -
Xavier Beaudouin