Często zdarza mi się taka sytuacja:
- Mam serwer źródłowy z dyskiem twardym o pojemności 320 GB i 16 GB pamięci RAM ( dokładne specyfikacje są dostępne tutaj , ale ponieważ jest to problem, na który często wpadam również na innych komputerach, wolałbym, aby odpowiedź działała na każdym „rozsądna” maszyna z systemem Linux)
- Mam serwer zapasowy z kilkoma terabajtami miejsca na dysku twardym ( dokładne specyfikacje tutaj , patrz wyłączenie odpowiedzialności powyżej)
Chcę przenieść 320 GB danych z serwera źródłowego na serwer docelowy (w szczególności dane z /dev/sda
).
- Dwa komputery są fizycznie obok siebie, więc mogę poprowadzić kable między nimi.
- Jestem w sieci LAN i korzystam z nowego routera , co oznacza, że prędkość mojej sieci powinna „idealnie” wynosić 1000 Mb, prawda?
- Bezpieczeństwo nie stanowi problemu. Jestem w sieci lokalnej i ufam wszystkim komputerom w sieci, w tym routerowi.
- (opcjonalnie) Niekoniecznie potrzebuję podpisanej sumy kontrolnej danych, ale podstawowe sprawdzanie błędów (takie jak upuszczone pakiety lub dysk staje się nieczytelny) powinno raczej zostać wykryte niż po prostu zniknąć w danych wyjściowych.
Szukałem tego pytania w Internecie i przetestowałem kilka poleceń. Ten, który pojawia się najczęściej, to:
ssh [email protected] 'dd bs=16M if=/dev/sda | gzip' > backup_sda.gz
Ta komenda okazała się zbyt wolna (działała przez godzinę, dane dostały tylko około 80 GB). Pakiet testowy 1 GB zajął około 1 minuty i 22 sekund, a po skompresowaniu był dwukrotnie szybszy. Wyniki mogły być również zniekształcone przez fakt, że przesłany plik jest mniejszy niż ilość pamięci RAM w systemie źródłowym.
Co więcej (i to zostało przetestowane na testowanych egzemplarzach 1 GB), mam problemy, jeśli użyję gzip
polecenia i dd
; plik wynikowy ma inną sumę kontrolną po wyodrębnieniu w celu, niż bezpośrednio w potoku. Wciąż próbuję dowiedzieć się, dlaczego tak się dzieje.
źródło
/dev/sda
jako obraz czy tylko pliki? Dlaczego rsync nie ma opcji? Jest/dev/sda
montowany podczas gdy tydd
?Odpowiedzi:
Ponieważ serwery są fizycznie obok siebie, a wspomniałeś w komentarzach, że masz do nich fizyczny dostęp, najszybszym sposobem byłoby wyjęcie dysku twardego z pierwszego komputera, umieszczenie go na drugim i przesłanie plików przez połączenie SATA.
źródło
dd
(lub kopii drzewa systemu plików).netcat
świetnie sprawdza się w sytuacjach takich jak ten, w których bezpieczeństwo nie stanowi problemu:Uwaga: jeśli używasz
dd
z GNU coreutils, możesz wysłaćSIGUSR1
do procesu, który wyśle postęp do stderr. W przypadku BSDdd
użyjSIGINFO
.pv jest jeszcze bardziej pomocny w zgłaszaniu postępów podczas kopiowania:
źródło
dd
nawet wymagane, czy możepv
/ samo dobrzenc
leczyć/dev/sda
? (Zauważyłem, że niektóre polecenia „wyrzucają” podczas próby odczytu specjalnych plików takich jak ten lub plików z0x00
bajtami)bash
jednym można używać> /dev/tcp/
IP/
portów i< /dev/tcp/
IP/
portu przekierowania zamiast rur do iz netcata odpowiednio.tar cv sourcedir | pv | nc dest_host_or_ip 9999
icd destdir ; nc -l 9999 | pv | tar xv
. Możliwych jest wiele odmian, możesz np. Chcieć zachować.tar.gz
stronę docelową zamiast kopii. Jeśli skopiujesz katalog do katalogu, dla dodatkowego bezpieczeństwa możesz później wykonać rsync, np. Z destrsync --inplace -avP [email protected]:/path/to/source/. /path/to/destination/.
gwarantuje, że wszystkie pliki są rzeczywiście dokładnymi kopiami.Czy korzystać z szybkiej kompresji.
lz4
jest twoją najlepszą opcją tutaj:Najlepiej nie szukaj niepotrzebnie.
Jeśli na urządzeniu, z którego kopiujesz, jest dużo wolnego miejsca, a urządzenie nie zostało ostatnio wyzerowane, ale wszystkie źródłowe systemy plików powinny zostać skopiowane, prawdopodobnie warto poświęcić trochę czasu coś jak:
Ale to zależy od tego, na jakim poziomie powinieneś czytać źródło. Zazwyczaj pożądane jest odczytywanie urządzenia od początku do końca z jego
/dev/
some_disk
pliku urządzenia, ponieważ czytanie na poziomie systemu plików będzie zazwyczaj wymagało niesekwencyjnego przeszukiwania dysku do przodu i do tyłu i wokół dysku. Dlatego polecenie odczytu powinno wyglądać mniej więcej tak:Jeśli jednak źródłowy system plików nie powinien zostać przesłany w całości, to czytanie na poziomie systemu plików jest dość nieuniknione, dlatego należy zebrać zawartość wejściową w strumieniu.
pax
jest ogólnie najlepszym i najprostszym rozwiązaniem w takim przypadku, ale możesz również rozważyćmksquashfs
.Czy nie szyfrować z
ssh
.Dlatego raczej powinieneś użyć
netcat
( lub, jak wolę,nmap
bardziej zdolny projektncat
) do prostej kopii sieciowej, jak sugerowano gdzie indziej:źródło
lz4
zadanie powinno z łatwością przyspieszyć nawet szeroko otwarte GIGe, a USB 2.0 nie ma szans. Poza tymlz4
został zaprojektowany tak, aby działał tylko wtedy, gdy powinien - jest częściowo tak szybki, ponieważ wie, kiedy należy próbować kompresji, a kiedy nie. A jeśli jest to przesyłany plik urządzenia, to nawet wstępnie skompresowane dane wejściowe mogą się nieco skompresować, jeśli w źródłowym systemie plików występuje fragmentacja.Istnieje kilka ograniczeń, które mogą ograniczać prędkość przesyłania.
Na potoku 1 Gb / s występuje nieodłączny narzut sieci. Zwykle zmniejsza to RZECZYWISTĄ przepustowość do 900 Mb / s lub mniej. Następnie należy pamiętać, że jest to ruch dwukierunkowy i należy oczekiwać znacznie mniej niż 900 Mb / s.
Mimo że używasz „nowego routera”, czy jesteś pewien, że router obsługuje 1 Gb / s? Nie wszystkie nowe routery obsługują 1 Gb / s. Ponadto, chyba że jest to router klasy korporacyjnej, prawdopodobnie stracisz dodatkową przepustowość transmisji, ponieważ router będzie nieefektywny. Chociaż na podstawie tego, co znalazłem poniżej, wygląda na to, że osiągasz prędkość powyżej 100 Mb / s.
Może wystąpić przeciążenie sieci z innych urządzeń współdzielących twoją sieć. Czy próbowałeś użyć bezpośrednio podłączonego kabla, tak jak powiedziałeś, że jesteś w stanie to zrobić?
Jakiej ilości IO dysku używasz? Prawdopodobnie jesteś ograniczony nie przez sieć, ale przez dysk. Większość dysków twardych o prędkości 7200 obr./min osiąga jedynie około 40 MB / s. Czy w ogóle używasz raidu? Czy używasz dysków SSD? Czego używasz na drugim końcu?
Sugeruję użycie rsync, jeśli oczekuje się, że zostanie on ponownie uruchomiony dla kopii zapasowych. Możesz także scp, ftp (s) lub http za pomocą downloadera takiego jak filezilla na drugim końcu, ponieważ zrównoleglą one połączenia ssh / http / https / ftp. Może to zwiększyć przepustowość, ponieważ inne rozwiązania działają na jednej rurze. Pojedyncza rura / wątek jest nadal ograniczony faktem, że jest jednowątkowy, co oznacza, że może być nawet związany z procesorem.
Dzięki rsync eliminujesz dużą złożoność swojego rozwiązania, a także umożliwia kompresję, zachowanie uprawnień i pozwala na częściowe transfery. Istnieje kilka innych powodów, ale ogólnie jest to preferowana metoda tworzenia kopii zapasowych (lub uruchamiania systemów tworzenia kopii zapasowych) w dużych przedsiębiorstwach. Commvault faktycznie używa rsync pod swoim oprogramowaniem jako mechanizmu dostarczania kopii zapasowych.
Na podstawie podanego przykładu 80 GB / h uzyskujesz około 177 Mb / s (22,2 MB / s). Wydaje mi się, że można łatwo podwoić to za pomocą rsync na dedykowanej linii Ethernet między dwoma urządzeniami, ponieważ udało mi się uzyskać to w moich własnych testach za pomocą rsync przez gigabit.
źródło
rsync
. Może nie być szybszy przy pierwszym uruchomieniu, ale na pewno będzie tak przez wszystkie kolejne czasy.Zajmujemy się tym regularnie.
Dwie główne metody, których używamy to:
cp
lubrsync
Pierwszy zależy od tego, czy dysk można fizycznie przenieść. Nie zawsze tak jest.
Drugi działa zaskakująco dobrze. Zasadniczo maksymalizujemy połączenie 1 Gb / s raczej łatwo dzięki bezpośrednim mocowaniom NFS. Nigdzie nie zbliżysz się do tego przy pomocy scp, dd over ssh lub czegoś podobnego (często uzyskasz maksymalną stawkę podejrzanie zbliżoną do 100mpbs). Nawet na bardzo szybkich procesorach wielordzeniowych natrafisz na wąskie gardło związane z maksymalną przepustowością kryptograficzną jednego z rdzeni na najwolniejszym z dwóch komputerów, co jest przygnębiająco powolne w porównaniu z pełnoprzepustowymi procesorami lub rsync na nieszyfrowanym montażu sieciowym. Od czasu do czasu będziesz uderzył w ścianę IOPS na chwilę i być zatrzymany na około ~ 53MB / s zamiast bardziej typowego ~ 110MB / s, ale to jest zwykle krótkotrwałe, chyba że źródło lub cel jest rzeczywiściepojedynczy dysk, możesz zostać ograniczony przez stałą szybkość samego dysku (który zmienia się wystarczająco z przypadkowych powodów, których nie poznasz, dopóki go nie wypróbujesz) - meh.
Ustawienie NFS może być trochę denerwujące, jeśli działa na nieznanej dystrybucji, ale ogólnie rzecz biorąc, był to najszybszy sposób na jak najlepsze wypełnienie rur. Ostatnim razem, gdy robiłem to z prędkością ponad 10 Gb / s, nigdy nie dowiedziałem się, czy to maksymalnie zwiększyło połączenie, ponieważ transfer został zakończony, zanim wróciłem po kawę - więc może istnieć jakiś naturalny limit, który tam osiągnąłeś. Jeśli masz kilka urządzeń sieciowych między źródłem a miejscem docelowym, możesz napotkać pewne niewielkie opóźnienia lub czkawkę z efektem slinky sieci, ale generalnie działa to w całym biurze (bez ingerencji w inny ruch) lub z jednego końca centrum danych do drugi (chyba że masz jakieś wewnętrzne filtrowanie / inspekcję, w którym to przypadku wszystkie zakłady są wyłączone ).
EDYTOWAĆ
Zauważyłem trochę gadania na temat kompresji ... nie kompresuj połączenia. Spowolni cię w taki sam sposób, jak warstwa krypto. Wąskim gardłem zawsze będzie pojedynczy rdzeń, jeśli skompresujesz połączenie (a nawet nie uzyskasz szczególnie dobrego wykorzystania magistrali tego rdzenia). Najwolniejszą rzeczą, jaką możesz zrobić w tej sytuacji, jest użycie zaszyfrowanego, skompresowanego kanału między dwoma komputerami siedzącymi obok siebie na połączeniu 1 Gb / s lub wyższym.
PRZYSZŁOŚĆ
Ta rada obowiązuje od połowy 2015 r. Prawie na pewno nie będzie tak przez wiele kolejnych lat. Więc weź wszystko z odrobiną soli, a jeśli regularnie mierzysz się z tym zadaniem, wypróbuj różne metody na rzeczywistych obciążeniach zamiast wyobrażać sobie, że uzyskasz coś zbliżonego do teoretycznych optymalnych wartości, a nawet zaobserwowane współczynniki kompresji / przepustowości kryptograficznej typowe dla takich rzeczy jak sieć ruch, z którego większość ma charakter tekstowy (protip: transfery zbiorcze zwykle składają się głównie z obrazów, audio, wideo, plików baz danych, kodu binarnego, formatów plików biurowych itp., które są już skompresowanena swój sposób i bardzo mało korzystają z przejścia przez kolejną procedurę kompresji, której rozmiar bloku kompresji prawie na pewno nie jest zgodny z już skompresowanymi danymi binarnymi ...).
Wyobrażam sobie, że w przyszłości koncepcje, takie jak SCTP, zostaną przeniesione w bardziej interesujące miejsce, w którym typowe są połączone połączenia (lub wewnętrznie połączone kanałowe połączenia światłowodowe), a każdy kanał może odbierać strumień niezależny od innych i każdy Strumień może być kompresowany / szyfrowany równolegle itp. itd. To byłoby wspaniałe! Ale dzisiaj tak nie jest w 2015 r. I chociaż fantazjowanie i teoretyzowanie jest miłe, większość z nas nie ma niestandardowych klastrów pamięci działających w komorze kriokomórkowej zasilających dane bezpośrednio do wnętrza Blue Gene / Q generujących odpowiedzi dla Watsona. To po prostu nie jest rzeczywistość. Nie mamy też czasu na wyczerpujące przeanalizowanie ładunku danych, aby dowiedzieć się, czy kompresja jest dobrym pomysłem, czy nie - sam transfer zostałby zakończony przed zakończeniem analizy,
Ale...
Czasy się zmieniają, a moje zalecenie przeciw kompresji i szyfrowaniu nie będzie ważne. Naprawdę chciałbym, aby ta rada została wkrótce obalona w typowej sprawie . Ułatwi to moje życie.
źródło
lz4
jest wystarczająco szybki, aby nie powodować wąskiego gardła, ale w zależności od tego, co chcesz zrobić z kopią, możesz potrzebować go bez kompresji. lzop też jest dość szybki. W moim i5-2500k Sandybridge (3,8 GHz)lz4 < /dev/raid0 | pv -a > /dev/null
idzie z prędkością ~ 180 MB / s, ~ 105 MB / s, w sam raz na gigE. Dekompresja po stronie odbiorczej jest jeszcze łatwiejsza na CPU.Sprytne narzędzie, którego użyłem w przeszłości to
bbcp
. Jak widać tutaj: https://www.slac.stanford.edu/~abh/bbcp/ .Zobacz także http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htm
Dzięki temu narzędziu miałem bardzo duże prędkości transferu.
źródło
Jeśli jakoś dostaniesz pierwsze przejście (przez drut / sneakernet / cokolwiek), możesz skorzystać
rsync
z niektórych opcji, które mogą znacznie przyspieszyć kolejne transfery. Bardzo dobrą drogą byłoby:Dostępne opcje: pełny, tryb archiwizacji, rekurencyjny, kompresuj, Częściowy postęp
źródło
-z
może być niewiarygodnie powolny w zależności od procesora i przetwarzanych danych. Podczas wyłączania kompresji doświadczyłem transferów z 30 MB / s do 125 MB / s.Dodano naleganie na oryginalny plakat w komentarzach do odpowiedzi Zacksego, chociaż nie jestem pewien, czy jest on najszybszy w typowych okolicznościach.
bash
ma specjalną składnię przekierowanie:dla wyjścia:
> /dev/tcp/
IP/
portudla wejścia:
< /dev/tcp/
IP/
portuIP ban być IP kropką dziesiętną lub nazwa hosta; zakaz portu może być liczbą dziesiętną lub nazwą portu z
/etc/services
.Brak rzeczywistego
/dev/tcp/
katalogu. Jest to specjalna syntaktyczna kludge, która nakazujebash
utworzenie gniazda TCP, połączenie go z określonym miejscem docelowym, a następnie wykonanie tej samej czynności, co zwykłe przekierowanie pliku (mianowicie zastąpienie odpowiedniego standardowego strumienia gniazdem za pomocą dup2 (2)).Dlatego można przesyłać strumieniowo dane z
dd
lubtar
na maszynę źródłową bezpośrednio przez TCP. Lub odwrotnie, aby przesyłać strumieniowo danetar
lub coś podobnego bezpośrednio przez TCP. W każdym razie jeden zbędny netcat jest eliminowany.Uwagi na temat netcat
Istnieje niespójność w składni między klasycznym netcat a GNU netcat . Użyję klasycznej składni, do której jestem przyzwyczajony. Wymienić
-lp
z-l
GNU netcata.Nie jestem również pewien, czy GNU netcat akceptuje
-q
przełączanie.Przesyłanie obrazu dysku
(Wzdłuż linii odpowiedzi Zackse.)
W miejscu docelowym:
U źródła:
Tworzenie archiwum tar.gz za pomocą
tar
Na miejscu:
U źródła:
Wymień
.tgz
się.tbz
icz
zecj
uzyskaćbzip2
-compressed archiwum.Przesyłanie z natychmiastowym rozszerzeniem do systemu plików
Również z
tar
.Na miejscu:
U źródła:
Będzie działał bez
-q 1
, ale netcat utknie po zakończeniu danych. Zobacz tar (1), aby uzyskać wyjaśnienie dotyczące składni i zastrzeżeńtar
. Jeśli istnieje wiele plików o wysokiej redundancji (niskiej entropii), można wypróbować kompresję (np.cz
Ixz
zamiastc
ix
), ale jeśli pliki są typowe, a sieć jest wystarczająco szybka, to tylko spowolni proces. Zobacz odpowiedź mikeserv, aby uzyskać szczegółowe informacje na temat kompresji.Alternatywny styl (docelowy port nasłuchuje)
Na miejscu:
U źródła:
źródło
Wypróbuj sugestie dotyczące bezpośrednich połączeń i unikania szyfrowanych protokołów, takich jak ssh. Następnie, jeśli nadal chcesz wycisnąć każdą wydajność, przeczytaj tę stronę: https://fasterdata.es.net/host-tuning/linux/, aby uzyskać porady dotyczące optymalizacji okien TCP.
źródło
Chciałbym użyć tego skryptu, który napisałem i który potrzebuje
socat
pakietu.Na maszynie źródłowej:
Na maszynie docelowej:
Jeśli
vbuf
pakiet (Debian, Ubuntu) już tam jest, to nadawca pliku pokaże postęp danych. Odbiornik plików pokaże, jakie pliki są odbierane. Opcji pass = można użyć tam, gdzie dane mogą zostać ujawnione (wolniej).Edytować:
Użyj
-n
opcji, aby wyłączyć kompresję, jeśli procesor jest szyjką butelki.źródło
Jeśli budżet nie jest głównym problemem, możesz spróbować podłączyć dyski za pomocą 12-rdzeniowego „złącza dysku” Intel Xeon E5. To złącze jest zwykle tak potężne, że możesz nawet uruchomić na nim obecne oprogramowanie serwera. Z obu serwerów!
To może wydawać się zabawną odpowiedzią, ale powinieneś naprawdę zastanowić się, dlaczego przenosisz dane między serwerami, a jeśli duży ze wspólną pamięcią i pamięcią masową może mieć większy sens.
Nie jesteś pewien aktualnych specyfikacji, ale powolny transfer może być ograniczony szybkością dysku, a nie siecią?
źródło
Jeśli dbasz tylko o kopie zapasowe, a nie bajt o bajtową kopię dysku twardego, polecam backupPC. http://backuppc.sourceforge.net/faq/BackupPC.html Konfiguracja jest trochę trudna, ale przenosi się bardzo szybko.
Mój początkowy czas transferu około 500G danych wynosił około 3 godzin. Kolejne kopie zapasowe mają miejsce w około 20 sekund.
Jeśli nie jesteś zainteresowany kopiami zapasowymi, ale próbujesz zsynchronizować różne rzeczy, to rsync lub unison lepiej pasują do twoich potrzeb.
Bajt dla bajtowej kopii dysku twardego jest zwykle okropnym pomysłem do tworzenia kopii zapasowych (brak przyrostów, brak oszczędności miejsca, dysk nie może być używany, musisz wykonać kopię zapasową „pustej przestrzeni” i musisz wykonać kopię zapasową śmieci (np. plik wymiany 16 G lub 200 G zrzutów rdzenia lub kilka takich). Korzystając z rsync (lub backuppc lub innych), możesz tworzyć „migawki” w czasie, dzięki czemu możesz przejść do „tego, jak wyglądał twój system plików 30 minut temu” za pomocą bardzo małe obciążenie.
To powiedziawszy, jeśli naprawdę chcesz przesłać bajt do kopiowania bajtów, to twój problem będzie leżał w transferze, a nie w pobieraniu danych z dysku. Bez 400 GB pamięci RAM transfer plików 320G zajmuje bardzo dużo czasu. Korzystanie z protokołów, które nie są zaszyfrowane, jest opcją, ale bez względu na wszystko, musisz po prostu tam usiąść i poczekać kilka godzin (przez sieć).
źródło
Niezależnie od programu zwykle stwierdziłem, że „ściąganie” plików przez sieć jest szybsze niż „wypychanie”. Oznacza to, że zalogowanie się na komputerze docelowym i wykonanie odczytu jest szybsze niż zalogowanie się na komputerze źródłowym i wykonanie zapisu.
Ponadto, jeśli zamierzasz użyć dysku pośredniego, zastanów się: Weź dysk zewnętrzny (jako pakiet lub osobny dysk podłączony do stacji dokującej), który używa eSATA zamiast USB. Następnie na każdym z dwóch komputerów albo zainstaluj kartę z portem eSATA, albo uzyskaj prosty kabel adaptera, który doprowadza jeden z wewnętrznych portów SATA do zewnętrznego złącza eSATA. Następnie podłącz dysk do komputera źródłowego, włącz dysk i poczekaj, aż się automatycznie zamontuje (możesz zamontować ręcznie, ale jeśli robisz to wielokrotnie, równie dobrze możesz umieścić go w pliku fstab). Następnie skopiuj; będziesz pisać z taką samą prędkością jak na dysku wewnętrznym. Następnie odmontuj dysk, wyłącz zasilanie, podłącz do drugiego komputera, włącz zasilanie, poczekaj na automatyczne podłączenie i czytaj.
źródło
Polecam przyjrzeć się zespołowi NIC. Wymaga to użycia wielu połączeń sieciowych działających równolegle. Zakładając, że naprawdę potrzebujesz więcej niż 1 Gb transferu, a 10 Gb jest kosztowne, 2 Gb zapewniane przez zespół NIC byłoby niewielkim kosztem, a twoje komputery mogą już mieć dodatkowe porty.
źródło
FWIW, zawsze używałem tego:
Chodzi o to, że ta metoda zachowa uprawnienia do plików / folderów między komputerami (zakładając, że na obu istnieją ci sami użytkownicy / grupy) (Zwykle robię to, aby skopiować obrazy dysków wirtualnych, ponieważ mogę używać parametru -S do obsługi rzadkich plików. )
Właśnie przetestowałem to między dwoma zajętymi serwerami i zarządzałem ~ 14 GB w 216 s (około 64 MB / s) - może lepiej poradzić sobie między dedykowanymi maszynami i / lub kompresją ... YMMV
źródło
O ile nie chcesz wykonywać analizy sądowej systemu plików, użyj programu zrzutu / przywracania dla swojego systemu plików, aby uniknąć kopiowania wolnego miejsca, którego FS nie używa. W zależności od posiadanego systemu plików zazwyczaj zachowuje to wszystkie metadane, w tym
ctime
. numery i-węzłów mogą się jednak zmieniać, zależnie od systemu plików (xfs, ext4, ufs ...).Celem przywracania może być plik w systemie docelowym.
Jeśli chcesz mieć obraz całego dysku z tablicą partycji, możesz uzyskać
dd
pierwszy 1M dysku, aby uzyskać tablicę partycji / bootloadery / rzeczy, ale potemxfsdump
partycje.Nie mogę stwierdzić na podstawie zrzutu informacji, jaki system plików faktycznie posiadasz. Jeśli jest to ufs BSD, to myślę, że ma program zrzutu / przywracania. Jeśli to ZFS, cóż, IDK, może być coś.
Generalnie dyski z pełnym kopiowaniem są zbyt wolne, by cokolwiek poza sytuacjami odzyskiwania. W ten sposób nie można również tworzyć przyrostowych kopii zapasowych.
źródło
Możesz także skonfigurować systemy tak, aby miały wspólną pamięć!
Rozważam, że są one obok siebie i prawdopodobnie zrobisz to jeszcze raz i jeszcze raz ....
źródło
Co powiesz na ethernetowy kabel skrzyżowany? Zamiast polegać na prędkościach bezprzewodowych, masz limit prędkości przewodowej karty sieciowej.
Oto podobne pytanie z kilkoma przykładami tego rodzaju rozwiązania.
Najwyraźniej wystarczy dziś typowy kabel Ethernet. Oczywiście im lepsza jest twoja karta sieciowa, tym szybszy jest transfer.
Podsumowując, jeśli konieczna jest jakakolwiek konfiguracja sieci, należy ograniczyć się do zwykłego ustawiania statycznych adresów IP serwera i komputera zapasowego za pomocą maski podsieci 255.255.255.0
Powodzenia!
Edytować:
@Khrystoph dotknął tego w swojej odpowiedzi
źródło
Kilku ludzi zaleca pominięcie ssh, ponieważ szyfrowanie cię spowolni. Nowoczesne procesory mogą być rzeczywiście wystarczająco szybkie przy 1 Gb, ale OpenSSH ma problemy z wewnętrzną implementacją okienkowania, która może drastycznie spowolnić.
Jeśli chcesz to zrobić za pomocą ssh, spójrz na HPN SSH . Rozwiązuje problemy z okienkowaniem i dodaje szyfrowanie wielowątkowe. Niestety musisz przebudować ssh zarówno na kliencie, jak i serwerze.
źródło
OK Próbowałem odpowiedzieć na to pytanie dla dwóch komputerów z „bardzo dużymi rurami” (10 Gbe), które są „blisko” siebie.
Problem, na który się tu natkniesz, to: większość kompresji spowoduje wąskie gardło w procesorze, ponieważ rury są tak duże.
wydajność przesyłania pliku 10 GB (połączenie sieciowe 6 Gb [linode], dane nieskompresowane):
I dwa pudełka na 10 Gbe, nieco starsze wersje netcat (CentOs 6.7), plik 10 GB:
Tak więc w jednym przypadku netcat użył mniej procesora, w drugim socat, więc YMMV.
Z netcat, jeśli nie ma opcji „-N -q 0”, może przesyłać obcięte pliki, bądź ostrożny ... inne opcje, takie jak „-w 10”, mogą również powodować obcięte pliki.
W prawie wszystkich tych przypadkach procesor jest maksymalizowany, a nie sieć.
scp
maksymalizuje przy około 230 MB / s, ustalając jeden rdzeń przy 100% wykorzystaniu.Iperf3 niestety tworzy uszkodzone pliki. Niektóre wersje programu netcat wydają się nie przesyłać całego pliku, co jest bardzo dziwne. Szczególnie starsze wersje.
Różne inkantacje „gzip as a pipe to netcat” lub „mbuffer” również wydawały się maksymalnie obciążać procesor przy pomocy gzip lub mbuffer, więc nie skutkowały szybszym transferem przy tak dużych rurach. lz4 może pomóc. Ponadto niektóre z rzeczy, które próbowałem w gzipie, spowodowały uszkodzenie transferu bardzo dużych plików (> 4 GB), więc bądźcie ostrożni :)
Kolejną rzeczą, która może działać szczególnie przy wyższych opóźnieniach (?), Jest dostrajanie ustawień tcp. Oto przewodnik wymieniający sugerowane wartości:
http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htm i https://fasterdata.es.net/host-tuning/linux/ (z innej odpowiedzi) ewentualnie ustawienia IRQ: https://fasterdata.es .net / host-tuning / 100g-tuning /
sugestie z linode, dodaj do /etc/sysctl.conf:
Dodatkowo chcieliby, abyś uruchomił:
warto dwukrotnie sprawdzić po poprawkach, aby upewnić się, że zmiany również nie powodują szkód.
Warto również dostroić rozmiar okna: https://iperf.fr/iperf-doc.php#tuningtcp
Jednak przy wolnych (er) połączeniach kompresja może zdecydowanie pomóc. Jeśli masz duże potoki, bardzo szybka kompresja może pomóc w łatwo kompresujących danych, nie próbowałem tego.
Standardową odpowiedzią na „synchronizowanie dysków twardych” jest synchronizacja plików, co pozwala uniknąć transferu tam, gdzie to możliwe.
Inna opcja: użyj „równoległego scp” (w taki czy inny sposób), wtedy użyje więcej rdzeni ...
źródło