Najpierw upewnij się, że wolumin logiczny nie jest podłączony. Jeśli tak jest, a chcesz zrobić „kopię zapasową”, najpierw utwórz migawkę i użyj jej:
lvcreate --snapshot --name transfer_snap --size 1G
Muszę przesłać dużo danych (7 TB) między dwoma serwerami połączonymi 1 Gb, więc potrzebowałem najszybszego możliwego sposobu, aby to zrobić.
Czy powinieneś używać SSH?
Korzystanie z ssh nie wchodzi w rachubę, nie ze względu na jego szyfrowanie (jeśli masz procesor z obsługą AES-NI, nie boli tak bardzo), ale z powodu jego buforów sieciowych. Nie są dobrze skalowane. Istnieje łatana wersja Ssh, która rozwiązuje ten problem, ale ponieważ nie ma wstępnie skompilowanych pakietów, nie jest to zbyt wygodne.
Korzystanie z kompresji
Podczas przesyłania surowych obrazów dysku zawsze zaleca się stosowanie kompresji. Ale nie chcesz, aby kompresja stała się wąskim gardłem. Większość narzędzi kompresji unix, takich jak gzip, jest jednowątkowych, więc jeśli kompresja nasyca jeden procesor, będzie to wąskim gardłem. Z tego powodu zawsze używam pigz, wariantu gzip, który używa wszystkich rdzeni procesora do kompresji. A to jest konieczne, abyś chciał zwiększyć lub przekroczyć prędkości GBit.
Korzystanie z szyfrowania
Jak powiedziano wcześniej, ssh jest wolny. Jeśli masz procesor AES-NI, nie powinno to stanowić wąskiego gardła. Zamiast używać ssh, możemy użyć openssl bezpośrednio.
Prędkości
Aby dać Ci wyobrażenie o wpływie komponentów na prędkość, oto moje wyniki. Są to prędkości przesyłania między dwoma systemami produkcyjnymi odczytywającymi i zapisującymi do pamięci. Rzeczywiste wyniki zależą od prędkości sieci, prędkości dysku twardego i prędkości procesora źródłowego! Robię to, aby pokazać, że przynajmniej nie ma ogromnego spadku wydajności.
Simple nc dd:
5033164800 bytes (5.0 GB, 4.7 GiB) copied, 47.3576 s, 106 MB/s
+pigz compression level 1 (speed gain depends on actual data):
network traffic: 2.52GiB
5033164800 bytes (5.0 GB, 4.7 GiB) copied, 38.8045 s, 130 MB/s
+pigz compression level 5:
network traffic: 2.43GiB
5033164800 bytes (5.0 GB, 4.7 GiB) copied, 44.4623 s, 113 MB/s
+compression level 1 + openssl encryption:
network traffic: 2.52GiB
5033164800 bytes (5.0 GB, 4.7 GiB) copied, 43.1163 s, 117 MB/s
Wniosek: użycie kompresji daje zauważalne przyspieszenie, ponieważ znacznie zmniejsza rozmiar danych. Jest to jeszcze ważniejsze, jeśli masz wolniejsze prędkości sieciowe. Podczas korzystania z kompresji obserwuj użycie procesora. jeśli wykorzystanie zostanie maksymalne, możesz spróbować bez niego. Używając kompresji jako niewielkiego wpływu na systemy AES-NI, imho tylko dlatego, że kradnie około 30-40% procesorów z kompresji.
Korzystanie z ekranu
Jeśli przesyłasz dużo danych, takich jak ja, nie chcesz, aby zostało to przerwane przez odłączenie sieci od twojego klienta ssh, więc lepiej zacznij od ekranu po obu stronach. To tylko uwaga, nie napiszę tutaj samouczka ekranowego.
Pozwala skopiować
Zainstaluj niektóre zależności (od źródła i miejsca docelowego):
apt install pigz pv netcat-openbsd
następnie utwórz wolumin w miejscu docelowym o takim samym rozmiarze jak źródło. Jeśli nie masz pewności, użyj lvdisplay na źródle, aby uzyskać rozmiar i utworzyć cel, tj .:
lvcreate -n lvname vgname -L 50G
następnie przygotuj miejsce docelowe do odbioru danych:
nc -l -p 444 | openssl aes-256-cbc -d -salt -pass pass:asdkjn2hb | pigz -d | dd bs=16M of=/dev/vgname/lvname
a gdy będzie gotowy, rozpocznij transfer w źródle:
pv -r -t -b -p -e /dev/vgname/lvname | pigz -1 | openssl aes-256-cbc -salt -pass pass:asdkjn2hb | nc <destip/host> 444 -q 1
Uwaga: jeśli przesyłasz dane lokalnie lub nie przejmujesz się szyfrowaniem, po prostu usuń część openssl z obu stron. Jeśli cię to obchodzi, asdkjn2hb jest kluczem szyfrującym, powinieneś go zmienić.