Jaki jest najszybszy sposób na skopiowanie 400G plików z woluminu magazynu elastycznych bloków ec2 na s3?

Muszę skopiować 400G plików z elastycznego magazynu bloków do wiadra s3 ... To około 300 tysięcy plików ~ 1Mb

Próbowałem s3cmd i s3fuse , oba są naprawdę, bardzo powolne .. s3cmd działał przez cały dzień, powiedział, że skończył kopiowanie, a kiedy sprawdziłem wiadro, nic się nie stało (przypuszczam, że coś poszło nie tak, ale przynajmniej s3cmd nigdy na nic nie narzekał)

S3Fuse pracuje przez kolejny pełny dzień i skopiował mniej niż 10% plików ...

Czy jest na to lepsze rozwiązanie?

Oczywiście używam Linuksa (ubuntu 12.04)

Istnieje kilka kluczowych czynników, które określają przepustowość z EC2 do S3:

• Rozmiar pliku - mniejsze pliki wymagają większej liczby żądań oraz większego obciążenia i transferu wolniej. Przyrost rozmiaru pliku (gdy pochodzi z EC2) jest nieistotny dla plików większych niż 256kB. (Podczas gdy przenoszenie z odległej lokalizacji, z większym opóźnieniem, wykazuje tendencję do dalszego wykazywania znacznej poprawy aż do poziomu między 1MiB a 2MiB).
• Liczba równoległych wątków - pojedynczy wątek wysyłania zwykle ma dość niski poziom - często poniżej 5 Mb / s. Przepustowość wzrasta wraz z liczbą współbieżnych wątków i ma tendencję szczytową między 64 a 128 wątków. Należy zauważyć, że większe instancje są w stanie obsłużyć większą liczbę współbieżnych wątków.
• Rozmiar instancji - zgodnie ze specyfikacją instancji , większe instancje mają więcej dedykowanych zasobów, w tym większą (i mniej zmienną) alokację przepustowości sieci (i ogólnie We / Wy - łącznie z odczytem z dysków efemerycznych / EBS - które są podłączone do sieci. Wartości liczbowe dla każdej kategorii to:
  • Bardzo wysoka: Teoretyczna: 10 Gb / s = 1250 MB / s; Realistyczny: 8,8 Gb / s = 1100 MB / s
  • Wysoka: Teoretyczna: 1 Gb / s = 125 MB / s; Realistyczny: 750 Mb / s = 95 MB / s
  • Umiarkowany: Teoretyczny: 250 Mb / s; Realistyczny: 80 Mb / s = 10 MB / s
  • Niski: Teoretyczny: 100 Mb / s; Realistyczne: 10-15 Mb / s = 1-2 MB / s

W przypadku przesyłania dużych ilości danych może być ekonomicznie praktyczne zastosowanie instancji obliczeń klastrowych, ponieważ efektywny wzrost przepustowości (> 10x) jest większy niż różnica kosztów (2-3x).

Chociaż powyższe pomysły są dość logiczne (chociaż ograniczenie liczby wątków może nie być), dość łatwo jest znaleźć wzorce, które je popierają. Jeden szczególnie szczegółowy można znaleźć tutaj .

Używanie od 64 do 128 równoległych (równoczesnych) przesyłanych obiektów 1 MB powinno nasycić łącze wysyłające 1 Gb / s, które ma m1.xlarge, a nawet nasycić łącze wysyłające 10 Gb / s instancji obliczeń klastra (cc1.4xlarge).

Chociaż zmiana wielkości instancji jest dość łatwa, pozostałe dwa czynniki mogą być trudniejsze do zarządzania.

• Rozmiar pliku jest zazwyczaj ustalony - nie możemy łączyć plików w EC2 i rozdzielać je na S3 (więc niewiele możemy zrobić z małymi plikami). Duże pliki możemy jednak rozdzielić po stronie EC2 i ponownie złożyć po stronie S3 (przy użyciu przesyłania częściowego S3). Zazwyczaj jest to korzystne w przypadku plików większych niż 100 MB.
• Równoległe wątki są nieco trudniejsze do zaspokojenia. Najprostsze podejście sprowadza się do napisania opakowania dla istniejącego skryptu przesyłania, który będzie uruchamiał wiele jego kopii jednocześnie. Lepsze podejścia wykorzystują API bezpośrednio do osiągnięcia czegoś podobnego. Pamiętając, że kluczem są równoległe żądania, nie jest trudno zlokalizować kilka potencjalnych skryptów, na przykład:
  • modyfikacja s3cmd - rozwidlenie wczesnej wersji s3cmd, która dodała tę funkcjonalność, ale nie była aktualizowana od kilku lat.
  • s3-parallel-put - stosunkowo nowy skrypt Pythona, który działa dobrze

Tak więc, po wielu testach s3-równolegle postawiony sposób zadziałał niesamowicie. Oczywiście rozwiązanie, jeśli musisz przesłać wiele plików do S3. Dzięki cyberx86 za komentarze.

Dostosuj wartości konfiguracji AWS CLI S3 zgodnie z http://docs.aws.amazon.com/cli/latest/topic/s3-config.html .

Poniżej zwiększono szybkość synchronizacji S3 o co najmniej 8x!

Przykład:

$ more ~/.aws/config
[default]
aws_access_key_id=foo
aws_secret_access_key=bar
s3 =
   max_concurrent_requests = 100
   max_queue_size = 30000

W tym celu napisałem zoptymalizowaną aplikację konsolową w języku C # ( CopyFasterToS3 ). Użyłem w EBS vol, i moim przypadku miał 5 folderów z ponad 2 milionami plików w ilości 20 GB. Skrypt został wykonany w mniej niż 30 minut.

W tym artykule pokazałem, jak korzystać z funkcji rekurencyjnej równolegle. Możesz zapisać go na inny język.

Powodzenia!

Są też: s3funnel , który wydaje się bardzo stary (2008) i kilka otwartych błędów, ale wciąż jest wymieniony w samej Amazon: amzn-lnk

Spróbuj s4cmd zamiast tego, to naprawdę szybsze niż s3cmd. Jego adres: https://github.com/bloomreach/s4cmd

Spróbuj użyć s3-cli zamiast s3cmd. Użyłem go zamiast s3cmd do przesyłania plików do mojego wiadra s3, dzięki czemu moje wdrożenie było szybsze prawie o 17 minut (od 21 do 4 minut)!

Oto link: https://github.com/andrewrk/node-s3-cli