Skopiuj duży plik z jednego serwera Linux na inny

20

Próbuję skopiować 75 gigabajtowy plik tgz (migawka mysql lvm) z serwera Linux w naszym centrum danych LA na inny serwer Linux w naszym centrum danych NY przez łącze 10 MB.

Dostaję około 20-30 Kb / s z rsync lub scp, który płynie od 200 do 300 godzin.

W tej chwili jest to stosunkowo ciche łącze, ponieważ drugie centrum danych nie jest jeszcze aktywne i uzyskałem doskonałe prędkości z małych transferów plików.

Postępowałem zgodnie z różnymi przewodnikami tuningu tcp, które znalazłem za pośrednictwem Google bezskutecznie (może czytam niewłaściwe przewodniki, mam dobry?).

Widziałem końcówkę tunelu tar + netcat, ale rozumiem, że jest to dobre tylko dla DUŻYCH małych plików i nie aktualizuje cię, gdy plik zostanie skutecznie przesłany.

Czy zanim zacznę wysyłać dysk twardy, czy ktoś ma jakiś dobry wkład?

AKTUALIZACJA: Cóż ... może to być mimo wszystko link :( Zobacz moje testy poniżej ...

Transfery z NY do LA:

Uzyskiwanie pustego pliku.

[nathan@laobnas test]$ dd if=/dev/zero of=FROM_LA_TEST bs=1k count=4700000
4700000+0 records in
4700000+0 records out
4812800000 bytes (4.8 GB) copied, 29.412 seconds, 164 MB/s
[nathan@laobnas test]$ scp -C obnas:/obbkup/test/FROM_NY_TEST .
FROM_NY_TEST                                    3%  146MB   9.4MB/s   07:52 ETA

Pobieranie tarballa migawki.

[nathan@obnas db_backup]$ ls -la db_dump.08120922.tar.gz
-rw-r--r-- 1 root root 30428904033 Aug 12 22:42 db_dump.08120922.tar.gz

[nathan@laobnas test]$ scp -C obnas:/obbkup/db_backup/db_dump.08120922.tar.gz .
db_dump.08120922.tar.gz            0%   56MB 574.3KB/s 14:20:40 ET

Transfery z LA do NY:

Uzyskiwanie pustego pliku.

[nathan@obnas test]$ dd if=/dev/zero of=FROM_NY_TEST bs=1k count=4700000
4700000+0 records in
4700000+0 records out
4812800000 bytes (4.8 GB) copied, 29.2501 seconds, 165 MB/s
[nathan@obnas test]$ scp -C laobnas:/obbkup/test/FROM_LA_TEST .
FROM_LA_TEST                                    0% 6008KB 497.1KB/s 2:37:22 ETA

Pobieranie tarballa migawki.

[nathan@laobnas db_backup]$ ls -la db_dump_08120901.tar.gz
-rw-r--r-- 1 root root 31090827509 Aug 12 21:21 db_dump_08120901.tar.gz

[nathan@obnas test]$ scp -C laobnas:/obbkup/db_backup/db_dump_08120901.tar.gz .
db_dump_08120901.tar.gz                0%  324KB  26.8KB/s 314:11:38 ETA

Myślę, że porozmawiam z ludźmi, którzy prowadzą nasze obiekty, link jest oznaczony jako łącze MPLS / Ethernet 10 MB. (wzruszać ramionami)

Nathan Milford
źródło
Tylko komentarz, niedawno otrzymałem informację od dostawcy oprogramowania na Seagate FreeAgent (dysk USB), która miała około 50 GB. Firma, o której mowa, była obecna w Internecie i zwykle prosiła klientów, aby po prostu pobrali ją ze swojej strony internetowej. Pomyślałem, że to ciekawe rozwiązanie i pomyślałem, że może to dodać trochę informacji, które mogą pomóc w podjęciu decyzji.
mdpc,
Jakie widzisz opóźnienie?
retracile
Około 80 ms przez łącze.
Nathan Milford,
Tak, teraz jestem po prostu zdezorientowany i sfrustrowany. Podzieliłem go na 50 MB i nadal działa powoli! Ale rsynchronizacja innych danych dostaje 500kb / s ... musi być coś strasznie złego, ehre brakuje mi ...
Nathan Milford,
Sprawdź swój ruch za pomocą tcpdump. Pomoże Ci dowiedzieć się, co spowalnia transfer.
lexsys

Odpowiedzi:

16

Sneakernet ktoś?

Zakładając, że jest to kopia jednorazowa, nie sądzę, że można po prostu skopiować plik na płytę CD (lub inny nośnik) i z dnia na dzień do miejsca docelowego?

To może być Twoja najszybsza opcja, ponieważ przesyłanie plików o tym rozmiarze przez to połączenie może nie zostać poprawnie skopiowane ... w takim przypadku możesz zacząć wszystko od nowa.


rsync

Moim drugim wyborem / próbą byłoby rsync, ponieważ wykrywa nieudane transfery, częściowe transfery itp. I może odebrać od miejsca, w którym zostało przerwane.

rsync --progress file1 file2 user@remotemachine:/destination/directory

Flaga --progress da ci jakieś informacje zwrotne zamiast po prostu tam siedzieć i pozostawiać cię do odgadnięcia. :-)


Vuze (bittorrent)

Trzeci wybór to prawdopodobnie próba użycia Vuze jako serwera torrent, a następnie zlecenie zdalnej lokalizacji korzystania ze standardowego klienta bitorrent do pobrania. Znam innych, którzy to zrobili, ale wiesz ... do czasu, gdy wszystko zaczęło działać, itd. ...

To chyba zależy od twojej sytuacji.

Powodzenia!


AKTUALIZACJA:

Wiesz, myślałem trochę o twoim problemie. Dlaczego plik musi być pojedynczym ogromnym archiwum? Tar jest w pełni zdolny do dzielenia dużych plików na mniejsze (na przykład na media), więc dlaczego nie podzielić tego ogromnego tarballa na łatwiejsze do zarządzania części, a zamiast tego przenieść je na inne?

KPWINC
źródło
3
+1, choć w tym przypadku prawdopodobnie nie jest to opłacalne. Nigdy nie lekceważ przepustowości 747 pełnej dysków twardych :)
Chad Huneycutt
2
Nie mogłem znaleźć linku, ale kilka lat temu Google szukał w okolicy skrzynek z napędami. Jeśli możesz przenieść skrzynkę napędów o łącznej pojemności 500 TB z punktu A do punktu B, w jakikolwiek sposób możesz to przeciąć, co jest bardzo dobrą przepustowością
STW
2
Być może odwołujesz się do tego artykułu: arstechnica.com/science/news/2007/03/…
KPWINC
1
Tak, skończyło się na wysyłaniu dysku twardego. Prawdziwym problemem, a przynajmniej tak mi powiedziano, była kontrola przepływu na przełączniku (przełącznikach).
Nathan Milford,
Bittorrent działa lepiej niż przelew bezpośredni, jeśli masz wiele siewników. Nawet jeśli OP instaluje BT na wielu komputerach, ma tylko jedno połączenie. I już ustalił, że wiele małych plików nie idzie szybciej niż jeden duży, co wskazuje palcem na połączenie sieciowe.
Xalorous,
7

Zrobiłem to w przeszłości z plikiem 60 GB TBZ2. Nie mam już skryptu, ale jego przepisanie powinno być łatwe.

Najpierw podziel plik na części o wielkości ~ 2 GB:

split --bytes=2000000000 your_file.tgz

Dla każdego elementu oblicz hash MD5 (to jest sprawdzenie integralności) i zapisz go gdzieś, a następnie zacznij kopiować kawałki i ich md5 do zdalnej strony za pomocą wybranego narzędzia (ja: netcat-tar-pipe na ekranie sesja).

Po chwili sprawdź na md5, czy twoje kawałki są w porządku, a następnie:

cat your_file* > your_remote_file.tgz

Jeśli wykonałeś także MD5 oryginalnego pliku, sprawdź go również. Jeśli wszystko jest w porządku, możesz rozpakować plik, wszystko powinno być w porządku.

(Jeśli znajdę czas, przepiszę skrypt)

edomaur
źródło
5

Zwykle jestem wielkim zwolennikiem rsync, ale przy pierwszym przesyłaniu jednego pliku nie ma to większego sensu. Jeśli jednak ponownie przesyłasz plik z niewielkimi różnicami, rsync będzie wyraźnym zwycięzcą. Jeśli mimo wszystko zdecydujesz się na użycie rsync, zdecydowanie polecam uruchomienie jednego końca w --daemontrybie, aby wyeliminować zabijający wydajność tunel ssh. Strona manuala dość dokładnie opisuje ten tryb.

Moja rekomendacja? FTP lub HTTP z serwerami i klientami, które obsługują wznawianie przerwanych pobierania. Oba protokoły są szybkie i lekkie, unikając kary ssh-tunelowej. Apache + wget krzyczałby szybko.

Sztuczka z rurką Netcat również działałaby dobrze. Tar nie jest konieczny podczas przesyłania pojedynczego dużego pliku. Powodem, dla którego nie powiadamia Cię o zakończeniu, jest to, że mu tego nie powiedziałeś. Dodaj -q0flagę po stronie serwera, a będzie się zachowywać dokładnie tak, jak można się spodziewać.

serwer $ nc -l -p 5000> outfile.tgz

klient $ nc -q0 server.example.com 5000 <infile.tgz

Wadą podejścia Netcat jest to, że nie pozwoli ci wznowić pracy, jeśli transfer umrze 74 GB w ...

Insyte
źródło
+1 dla rsyncd. Właściwie używam go do przesyłania w mojej sieci LAN, ponieważ widzę wyższą przepustowość w porównaniu do CIFS lub NFS.
Ophidian,
1
Podczas gdy FTP i HTTP unikają „kary za tunel ssh”, należy wziąć pod uwagę „karę” za nieszyfrowanie danych.
J.Money
3

Daj szansę netcatowi (czasem nazywanemu nc). Poniższe działa na katalogu, ale powinno być wystarczająco łatwe, aby dostosować tylko kopiowanie jednego pliku.

W polu docelowym:

netcat -l -p 2342 | tar -C /target/dir -xzf -

W polu źródłowym:

tar czf * | netcat target_box 2342

Możesz spróbować usunąć opcję „z” w obu poleceniach tar, aby uzyskać nieco większą szybkość, ponieważ plik jest już skompresowany.

David
źródło
1

Domyślne SCP i Rsync (który używa SCP) są bardzo wolne w przypadku dużych plików. Chyba bym pomyślał o użyciu protokołu z niższym kosztem. Czy próbowałeś użyć prostszego szyfru szyfrującego lub wcale? Spróbuj wyszukać --rshopcję rsync, aby zmienić metodę przesyłania.

Dlaczego nie FTP lub HTTP?

cmcginty
źródło
1
Zrobiłem stary „python -m SimpleHTTPServer” z wiersza poleceń na źródle i zapisałem plik na miejscu docelowym. Nadal dostaję „18,5K / s eta 15d 3h”
Nathan Milford,
1

Chociaż dodaje to trochę narzutu do sytuacji, BitTorrent jest naprawdę bardzo dobrym rozwiązaniem do przesyłania dużych plików. BitTorrent ma wiele fajnych funkcji, takich jak natywne dzielenie plików i sprawdzanie każdego fragmentu, który może zostać przesłany ponownie w przypadku uszkodzenia.

Program taki jak Azureus [obecnie znany jako Vuze] zawiera wszystkie elementy, które musisz utworzyć, serwer i pobieranie torrentów w jednej aplikacji. Pamiętaj, że Azureus nie jest najbardziej oszczędnym rozwiązaniem dostępnym dla BitTorrenta i myślę, że wymaga również GUI - istnieje jednak wiele narzędzi torrentowych opartych na linii poleceń dla Linuksa.

DisabledLeopard
źródło
bt idzie szybciej niż transfer bezpośredni, jeśli jest wiele nasion. On ma jedno źródło. Co ważniejsze, ma sieć z jednym źródłem i złe połączenie sieciowe. Nawet skopiowanie pliku do wielu lokalizacji lokalnie, a następnie skonfigurowanie bt z wieloma nasionami jest nieproduktywne z powodu tego złego połączenia. Plus robienie wielu kopii i konfigurowanie ich jako nasion zwiększa czas kopiowania zamiast go skracać. BT może być wykonalnym rozwiązaniem, jeśli OP próbuje udostępnić duży plik wielu odbiorcom.
Xalorous,
0

Cóż, osobiście, 20-30 Kb / s wydaje się dość niski dla łącza 10 Mb (zakładając 10 Mb, a nie 10 MB).

Gdybym był tobą, zrobiłbym jedną z dwóch rzeczy (zakładając, że fizyczny dostęp nie jest dostępny) -

Niezależnie od tego, radzę podzielić duży plik na mniejsze części, około 500 MB. Tylko w przypadku uszkodzenia podczas transportu.

Gdy masz mniejsze porcje, użyj albo rsync ponownie, albo osobiście wolę użyć prywatnej Bezpiecznej sesji ftp, a następnie CRC plików po zakończeniu.

William Hilsum
źródło
0

Kilka pytań może pomóc w dyskusjach: jak ważne są dane, które mają zostać przesłane? Czy dotyczy to odzyskiwania po awarii, tworzenia kopii zapasowych na gorąco, przechowywania offline czy co? Czy zamierzasz wykonać kopię zapasową bazy danych, gdy jest ona w górę lub w dół? A co z konfigurowaniem bazy danych w systemie zdalnym i utrzymywaniem ich w synchronizacji za pomocą klastrowania lub aktualizacji za pomocą dzienników zmian (nie jestem całkowicie obeznany z możliwościami systemu bazy danych MySql). Może to pomóc w zmniejszeniu ilości danych, które należy przesłać przez łącze.

mdpc
źródło
Jest to migawka LVM innej repliki MYSQL (naszej głównej instancji MYSQL w innym miejscu). Po przeniesieniu i umieszczeniu docelowa instancja mysql może po prostu zaktualizować różnicę między tym snapshotem (użyj go jako delty) i tym, gdzie znajduje się teraz master. To, że jest to kopia zapasowa MYSQL, nie ma znaczenia, to tylko duża część danych, którą muszę przenieść tylko raz.
Nathan Milford,
0

bbcp utworzy dla ciebie plik i skopiuje z wieloma strumieniami.

Zaur
źródło
0

Późna odpowiedź dla pracowników Google:

Podczas przesyłania dużych zestawów danych można użyć rsync do porównania źródła i miejsca docelowego, a następnie zapisać plik wsadowy na lokalnym nośniku wymiennym przy użyciu flagi --only-write-batch. Następnie wysyłasz lokalne media do zdalnej lokalizacji, podłącz je i ponownie uruchom rsync, używając --read-batch, aby uwzględnić zmiany w zdalnym zbiorze danych.

Jeśli pliki źródłowe zmienią się podczas transportu fizycznego lub nośnik transportowy zapełni się, możesz po prostu powtarzać --only-write-batch | statek | - cykl odczytywania partii do momentu, aż miejsce docelowe zostanie doścignięte.

(Ref: Byłem jednym z autorów tej funkcji w rsync - więcej informacji na temat tła i zastosowań można znaleźć w dyskusji na temat implementacji prototypu: https://lists.samba.org/archive/rsync/2005-March/011964 .html )

Stevevt
źródło