Перенести 100Тб данных

[fox_m]

Всем привет! Подскажите оптимальный способ переноса ~ 100Тб данных с одной площадки на другую. Исходные данные:

 

1. Есть две георгафически разделенные площадки (в рамках одного города), между которыми есть виртуальный канал от МегаФон ~ 2Гб/с

2. На обоих стоит по серверу с Ubuntu 20.04 (полный доступ к системе).

3. На одном из серверов - хранилище видео-контента, которое нужно перенести на вторую площадку.

 

На ум пока приходят rsync (вроде медленно из за ssh шифрования) и NFS.

 

[jffulcrum]

Вынуть диски, отвезти во второй ЦОД и вставить в новый сервер. Прямо вместе с контроллером и проводами. Два часа демонтаж, час в дороге, два часа монтаж. И я серьёзно. Одно выяснение уровня "виртуальности" канала с поддержкой зелёных займет  больше.

[passer]

Учитывая объем, можно и нужно провести тестирования скорости. Лично я бы рассмотрел бы еще шифрование файлов gpg и отправку по rsync, ftp или вообще банальный ftps.

Но если можно перевести оборудование, то согласен с коллегой, раз 5 быстрее получится.

[fox_m]

Перевезти не получится. Весь контент переезжает на новое хранилище. Старое использоваться не будет.

 

Канал стабильный, со стабильной задержкой. Это не Интернет, а VPLS

[TheUser]

1 час назад, fox_m сказал:

На ум пока приходят rsync (вроде медленно из за ssh шифрования

Что, даже 2 Гбит/с не тянет?

[alibek]

Это даже чисто арифметически (в идеальных условиях и без учета накладных расходов) около 5 суток.

На самом же деле это будет намного дольше.

Добавятся накладные расходы на протоколы и ошибки.

2 Гбит/с может быть не всегда, могут быть просадки, кратковременные или достаточно длительные.

Ну и наконец этот канал вряд ли пустой стоит, наверняка он используется. А значит, что на период копирования текущие процессы встанут, либо придется пропускную способность разделять и время переноса пропорционально увеличится.

 

Я тоже за физический перенос носителей, это будет намного быстрее и проще, тем более если все в одном городе.

Если возможно, я бы даже диски и контроллер не снимал, а перевез бы целиком сервер.

[fox_m]

rsync не всегда тянет столько. Но есть подозрение, что не в сети дело. А в старом хранилище. Сейчас разбираемся.

[TheUser]

1 час назад, alibek сказал:

2 Гбит/с может быть не всегда, могут быть просадки, кратковременные или достаточно длительные.

Если речь про "канал VPLS", то он почти всегда с гарантированной полосой, за исключением аварий, конечно.

Если хорошие отношения с оператором и есть ТВ, то можно на пару дней из 2 Гбит/с сделать 10 и скопировать всё за день(без учета форс-мажора)

[Savchenko]

sftp обычный, при нормальных ЦПУ с обоих сторон утилизирует канал легко + включите BBR на обоих машинках.

 

конечно при 2Гбит/с 100 ТБ будут переноситься ~5 суток, проще сервер перевести наверно 🙂

Edited May 27, 2025 by Savchenko

[fox_m]

Удалось разогнать rsync до 630 Мб/с (добавили опцию —bwlimit=0). Без нее совсем вяло было.

[TheUser]

1 час назад, fox_m сказал:

Удалось разогнать rsync до 630 Мб/с

А узкое место в чем? Диски? iowait какой?

[fox_m]

Пока разбираемся. После добавления опции bwlimit к rsync, скорость стала 630Мб/с. До этого вообще 200Мбит было. iperf3 показывает скорость в канале почти 6Гб/с (канал между площадками оказывается 5-6 Гб/с).

 

root@flussonic01:~# iperf3 -c 10.236.20.232 -t 60
Connecting to host 10.236.20.232, port 5201
[  5] local 10.100.52.3 port 37900 connected to 10.236.20.232 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   679 MBytes  5.70 Gbits/sec    0   3.94 MBytes       
[  5]   1.00-2.00   sec   729 MBytes  6.11 Gbits/sec    0   3.94 MBytes       
[  5]   2.00-3.00   sec   705 MBytes  5.91 Gbits/sec    0   3.94 MBytes       
[  5]   3.00-4.00   sec   736 MBytes  6.18 Gbits/sec    0   3.94 MBytes       
[  5]   4.00-5.00   sec   712 MBytes  5.98 Gbits/sec    0   3.94 MBytes       
[  5]   5.00-6.00   sec   724 MBytes  6.07 Gbits/sec    0   3.94 MBytes       
[  5]   6.00-7.00   sec   716 MBytes  6.01 Gbits/sec    0   3.94 MBytes       
[  5]   7.00-8.00   sec   719 MBytes  6.03 Gbits/sec    0   3.94 MBytes       
[  5]   8.00-9.00   sec   698 MBytes  5.85 Gbits/sec    0   3.94 MBytes       
[  5]   9.00-10.00  sec   722 MBytes  6.06 Gbits/sec    0   3.94 MBytes       
[  5]  10.00-11.00  sec   684 MBytes  5.74 Gbits/sec    0   3.94 MBytes       
[  5]  11.00-12.00  sec   716 MBytes  6.01 Gbits/sec    0   3.94 MBytes       
[  5]  12.00-13.00  sec   705 MBytes  5.91 Gbits/sec    0   3.94 MBytes       
[  5]  13.00-14.00  sec   730 MBytes  6.12 Gbits/sec    0   3.94 MBytes       
[  5]  14.00-15.00  sec   648 MBytes  5.43 Gbits/sec   61   2.99 MBytes       

 

[naves]

в пункте назначения ставите

s3 сервер minio.RELEASE.2022-05-26T05-48-41Z, именно эту версию, которая загруженные файлы сохранит на диск как есть без использования внутреннего формата.

c клиента заливаете через minio client он же mc, либо через rclone. Обе утилиты умеют работать в режиме синхронизации.

[fox_m]

Ага, спасибо. Посмотрим.

[anix]

Чтобы убрать ssh, можно на принимающей стороне запустить демон rsyncd, описав в конфиге rsyncd.conf модуль

uid = nobody
gid = nogroup
use chroot = yes 
max connections = 100 
pid file = /var/run/rsyncd.pid

[client]
path = /srv/client
hosts allow = 192.168.0.1
hosts deny = * 
numeric ids = yes 
read only = no
write only = yes 
list = no

на клиенте запустить примерно так: 

rsync -av /srv/video/* rsync://server/client

 

[jffulcrum]

Я бы не связывался с rsync для такой задачи даже если бы оба сервера стояли в одной стойке. А с учетом каналов... что ж, на таком объёме вполне реально выяснить, какой там BER реально, в 802.3 BER стандартизован как 10 в степени -12 вроде. 

 

Хотя бы https://rclone.org/ взять

[alibek]

Кстати, да.

Мне как-то нужно было перенести несколько терабайт между компьютерами.

Через NFS были неприятные проблемы (копирование прерывалось или вообще зависало), через rsync были проблемы со скоростью.

А вот с rclone получилось лучше всего.

[straus]

Такие объёмы надо копировать через SATA или SAS.

[murano]

DRBD не подойдет?

[Ivan_83]

13 hours ago, fox_m said:

На ум пока приходят rsync (вроде медленно из за ssh шифрования) и NFS.

Шифрование=ссш там опциональное, выше уже написали: если поднять с одной стороны рсинк сервер то будет без ссш.

Но там же AES-NI почти всегда, да и вообще 1-2 гигабита кажется даже на коредуо можно было прокачать через ссш, ну подумаешь загрузка 1 ядра на шифрование может до 100% дойти.

 

 

13 hours ago, jffulcrum said:

Вынуть диски, отвезти во второй ЦОД и вставить в новый сервер.

Тоже про это подумал, но 100тб не так уж много.

 

 

13 hours ago, passer said:

Лично я бы рассмотрел бы еще шифрование файлов gpg и отправку по rsync, ftp или вообще банальный ftps.

Нахрена там вообще шифрование?

 

 

10 hours ago, fox_m said:

Удалось разогнать rsync до 630 Мб/с (добавили опцию —bwlimit=0). Без нее совсем вяло было.

А теперь на передающей стороне загружайте htcp и выставляйте его вместо cubic.

Или hybla.

Если не поможет - возможно стоит отказаться от ссш.

Как говорили выше - можно попробовать FTP или нечто подобное 🙂

 

 

1 hour ago, jffulcrum said:

А с учетом каналов... что ж, на таком объёме вполне реально выяснить, какой там BER реально, в 802.3 BER стандартизован как 10 в степени -12 вроде. 

Если они через ssh то там есть MAC который такое не допустит.

Если нет - проще запустить rsync второй раз чтобы он ещё раз прошёлся по файлам и сравнил контрольные суммы.

[straus]

А не проще выкупить эти накопители?

Или перекинуть местами сервера?

[passer]

14 часов назад, Ivan_83 сказал:

Нахрена там вообще шифрование?

Автор его упомянул. Может там видеоархив семейный и очень конфиденциальный... 

[TheUser]

1 час назад, passer сказал:

Автор его упомянул. Может там видеоархив семейный и очень конфиденциальный... 

А может быть он ломанул какую-то базу банковскую, шифрование нужно для обхода DLP, а все здешние советчики пойдут как соучастники)

[alibek]

Банковская база в 100ТБ? На которой есть интернет-доступ?

[straus]

Наснимать 100 ТБ? Однако...