Vraag Draag 15 TB kleine bestanden over


Ik archiveer gegevens van de ene server naar de andere. Aanvankelijk begon ik een rsync job. Het duurde twee weken om de bestandslijst te maken voor slechts 5 TB aan gegevens en nog een week om 1 TB aan gegevens over te zetten.

Toen moest ik de klus doden omdat we wat downtime nodig hebben op de nieuwe server.

Er is afgesproken dat we het targeten omdat we het waarschijnlijk niet meer nodig hebben. Ik dacht eraan om het in 500 GB-stukjes te breken. Nadat ik tar toen ging ik het overdragen ssh. Ik was aan het gebruiken tar en pigz maar het is nog steeds te langzaam.

Is er een betere manier om het te doen? Ik denk dat beide servers op Redhat zijn. Oude server is Ext4 en de nieuwe is XFS.

Bestandsgroottes variëren van enkele kb tot enkele MB en er zijn 24 miljoen jpegs in 5TB. Dus ik vermoed ongeveer 60-80 miljoen voor 15TB.

edit: Na een aantal dagen met rsync, nc, tar, mbuffer en pigz gespeeld te hebben. Het knelpunt wordt de schijf-IO. Omdat de gegevens zijn gestreept over 500 SAS-schijven en ongeveer 250 miljoen jpegs. Nu heb ik echter al deze leuke tools leren kennen die ik in de toekomst kan gebruiken.


73
2017-09-09 15:23


oorsprong


mogelijk duplicaat van linux naar linux, overdracht 10TB? - D34DM347
Een optie is om de gecomprimeerde tar-bestanden op een externe schijf te maken en die naar het nieuwe systeem te verplaatsen. De extra schijf versnelt het maken van de tar-bestanden (schrijft niet naar bestaande schijven in het systeem, mogelijk tijdens het lezen van 15TB van hen) en verbindt de nieuwe server niet. - Brian
Is er een betere manier om het te doen? - Ja, Windows Server 2012 R2 DFS-replicatie zou dat in ongeveer 10 uur voorbereiden. En het zou veranderingen synchroniseren, en verdergaan waar het gebleven was na opnieuw opstarten. - TessellatingHeckler
@TessellatingHeckler: dus u suggereert dat OP migreert van Redhat naar Windows voordat u gaat archiveren? - Thomas Weller
@ThomasWeller Ze vroegen "is er een betere manier?", En dat is er. Ik doe geen aanbeveling dat ze de betere manier gebruiken. Ze zijn vrij om commando's in een pijp te gebruiken die niet kunnen worden hersteld na een onderbreking, zullen de bestandsinhoud niet verifiëren, kunnen de kopieerstatus niet rapporteren, kunnen eerder gekopieerde blokken niet gebruiken om delen van bestanden te kopiëren, heeft geen impliciete ondersteuning van kopiëren met lage prioriteit, kan niet worden gepauzeerd, heeft geen melding van het kopiëren van ACL's en heeft iemand nodig om ingelogd te blijven om het uit te voeren. Iedereen die hierna volgt, is mogelijk geïnteresseerd - of wordt gevraagd om te zeggen "x doet dat onder Linux". - TessellatingHeckler


antwoorden:


Ik heb zeer goede resultaten gehad met tar, pigz (parallel gzip) en nc.

Bronapparaat:

tar -cf - -C /path/of/small/files . | pigz | nc -l 9876

Bestemmingsmachine:

Extraheren:

nc source_machine_ip 9876 | pigz -d | tar -xf - -C /put/stuff/here

Om archief te bewaren:

nc source_machine_ip 9876 > smallstuff.tar.gz

Als je wilt zien dat de overdrachtssnelheid er gewoon doorheen gaat pv na pigz -d!


62
2017-09-09 16:29



Ter info, je kunt vervangen pigz met gzip of verwijder het helemaal, maar de snelheid zal aanzienlijk langzamer zijn. - h0tw1r3
Hoe kan dit worden aanvaard als OP al heeft geprobeerd tar en pigz? Ik begrijp het niet ... - Thomas Weller
@ Thomas Weller, waar heb je dat hij heeft geprobeerd pigz? Uit de vraag lijkt het erop dat hij alleen maar is geprobeerd rsync tot nu toe, en was aangezien gebruik makend van tar om de gegevens te splitsen en te bundelen. Vooral als hij de -z/--compress optie op rsync, pigz zou in theorie aanzienlijk kunnen helpen. - Doktor J
@ThomasWeller ja inderdaad ik heb al tar en pigz geprobeerd maar niet nc. Ik gebruikte ssh, dus het heeft veel meer overhead toegevoegd. - lbanz
@lbanz dat betekent dat gewoon tar produceert niet snel genoeg data voor pigz om veel CPU te gebruiken voor compressie. Het lezen van veel kleine bestanden omvat veel meer syscalls, nog veel meer schijf zoekt, en veel meer kernel overhead dan het lezen van hetzelfde aantal bytes van grotere bestanden, en het lijkt erop dat je simpelweg knelt op een fundamenteel niveau. - hobbs


Ik zou me aan de rsync-oplossing houden. Modern (3.0.0+) rsync maakt gebruik van een incrementele bestandslijst, zodat het geen volledige lijst hoeft samen te stellen voor overdracht. Dus als u het opnieuw opstart, hoeft u geen hele overdracht uit te voeren in geval van problemen. Het splitsen van de overdracht per top- of second-level directory zal dit nog verder optimaliseren. (Ik zou gebruiken rsync -a -P en voeg toe --compress als uw netwerk langzamer is dan uw schijven.)


20
2017-09-09 18:44



Ik gebruik rsync 2.6.8 op de oude server. Omdat het een van die vakjes is waar we niets mogen installeren / updaten zoals door de verkoper is aangegeven of het de garantie ongeldig maakt. Ik zou het kunnen updaten en kijken of het sneller is. - lbanz
Zoek (of bouw) een statisch gekoppeld rsync-binair bestand en voer het gewoon uit vanuit uw eigen huis. Hopelijk verprutst dat geen garantie. - Fox


Stel een VPN in (als het internet is), maak een virtueel station van een bepaald formaat op de externe server (ext4 maken), koppel het op de externe server, dan mount dat op de lokale server (met behulp van een protocol op blokniveau zoals iSCSI), en gebruik dd of een ander block-level tool om de overdracht uit te voeren. Vervolgens kunt u de bestanden op uw eigen gemak van de virtuele schijf naar de echte (XFS) schijf kopiëren.

Twee redenen:

  1. Geen bestandssysteem boven het hoofd, wat de belangrijkste boosdoener is
  2. Geen zoeken, je kijkt naar sequentiële lezen / schrijven aan beide kanten

15
2017-09-09 16:17



Het bestandssysteem omzeilen is goed. Het kopiëren van blokniveau van een op lees-schrijf gemount bestandssysteem is een heel slecht idee. Unmount of mount eerst read-only. - JB.
Een kopie van 15TB is ook heel erg. Het betekent dat de nieuwe server minimaal 30 nodig heeft. - Arthur Kay
Als de server LVM gebruikt, kan een alleen-lezen snapshot van het bestandssysteem worden gemaakt en in plaats daarvan worden gekopieerd. Ruimte alleen over voor de wijzigingen in het bestandssysteem die plaatsvinden terwijl de momentopname wordt gelezen. - liori


Als de oude server buiten gebruik wordt gesteld en de bestanden een paar minuten offline kunnen zijn, is het vaak het snelst om de schijven uit de oude doos te trekken en naar de nieuwe server te leiden, ze te koppelen (nu online) en de bestanden te kopiëren naar de nieuwe servers native schijven.


9
2017-09-10 03:14



Het gaat om 1PB van 2TB-schijven, dus het is veel te veel. - lbanz


Gebruik mbuffer en als het zich op een beveiligd netwerk bevindt, kunt u de codeerstap vermijden.


3
2017-09-09 15:39





(Veel verschillende antwoorden kunnen werken. Hier is er nog een.)

Genereer de bestandslijst met find -type f (dit zou binnen een paar uur moeten eindigen), het opsplitsen in kleine stukjes en elk deel overzetten met gebruik van rsync --files-from=....


3
2017-09-10 23:34





Heb je sneakernet overwogen? Daarmee bedoel ik dat alles op dezelfde schijf wordt overgezet en vervolgens die schijf fysiek wordt verplaatst.

ongeveer een maand geleden onthulde Samsung een 16 TB-schijf (technisch gezien is het 15,36 TB), wat ook een SSD is: http://www.theverge.com/2015/8/14/9153083/samsung-worlds-largest-hard-drive-16tb

Ik denk dat deze drive hier gewoon voor zou kunnen zorgen. Je zou nog steeds alle bestanden moeten kopiëren, maar aangezien je geen netwerklatentie hebt en waarschijnlijk SATA of een vergelijkbaar snelle techniek kunt gebruiken, zou het behoorlijk veel sneller moeten zijn.


3
2017-09-12 17:56





Als er een kans is om een ​​hoge succesratio te krijgen bij deduplicatie, zou ik zoiets gebruiken borgbackup of Zolder.

Als dit niet het geval is, controleert u de netcat + tar +pbzip2 oplossing, pas de compressie-opties aan op basis van uw hardware - controleer wat de bottleneck is (CPU? netwerk? IO?). De pbzip2 zou mooi over alle CPU's kunnen overspannen en betere prestaties leveren.


2
2017-09-09 20:38



lzma (xz) decomprimeert sneller dan bzip2 en doet het goed op de meeste invoer. Helaas, xzDe multithread-optie is nog niet geïmplementeerd. - Peter Cordes
Gewoonlijk heeft de compressiefase meer pk's nodig dan decompressie, dus als de CPU de beperkende factor is, zou pbzip2 resulteren in betere algehele prestaties. Decompressie mag het proces niet beïnvloeden, als beide machines vergelijkbaar zijn. - neutrinus
Ja, mijn punt was dat het een schande is dat er geen single-stream multi-thread lzma is. Hoewel het voor deze use-case van het overzetten van hele bestandssystemen van gegevens, pigz zou prob. wees de langzaamste compressor die je zou willen gebruiken. Of zelfs lz4. (Er is een lz4mt multi-threaded-voor-een-single-stream beschikbaar. Het werkt niet erg efficiënt (spawnen heel vaak nieuwe threads), maar het krijgt een solide speedup) - Peter Cordes


U gebruikt RedHat Linux, dus dit zou niet van toepassing zijn, maar als een andere optie:

Ik heb veel succes gehad met het gebruik van ZFS om miljoenen bestanden te bewaren, omdat inodes geen probleem zijn.

Als dat een optie voor u was, kunt u vervolgens snapshots maken en zfs gebruiken om incrementele updates te verzenden. Ik heb veel succes gehad met deze methode om gegevens over te zetten en te archiveren.

ZFS is in de eerste plaats een Solaris-bestandssysteem, maar is te vinden in de illumos (open source-vork van Sun's OpenSolaris). Ik weet dat er ook wat geluk is geweest bij het gebruik van ZFS onder BSD en Linux (met FUSE?), Maar ik heb geen ervaring om dat te proberen.


2
2017-09-10 18:49



Er is al een hele tijd een niet-FUSE native Linux-poort van ZFS: zfsonlinux.org - EEAA


Start een rsync daemon op de doelcomputer. Dit versnelt het overdrachtsproces veel.


1
2017-09-11 15:50