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

[fox_m]

В общем, остановились на rsync. Коллега написал скрипт на Go, который запускает несколько потоков rsync. Нагрузили канал до 4 Гб/с За час примерно терабайт данных сливаем. 

[Saab95]

В 27.05.2025 в 08:34, jffulcrum сказал:

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

Это если свой ЦОД.

 

А если не свой, то заявка не демонтаж, к вечеру может снимут, выписать пропуск за день, приехать забрать, в новый ЦОД отвезти, там так же день будут подключать. Дня 3 все займет. Еще при переезде могут носители повредится.

[fox_m]

Диски не получится перенести. Мы старое СХД отдаем и переезжаем на новое. Кстати, объем оказался немного больше - 500 Тб )

[jffulcrum]

Тут уже и устойчивость ECC памяти к ошибкам получится проверить...ЕМНИП там 10 в степени -17.

[alibek]

Да уж. 500 ТБ, да на скорости 4 Гбит/с — по самым оптимистичным подсчетам это 11,6 суток.

Тот случай, когда пропускная способность Газели будет выше.

[Saab95]

8 часов назад, alibek сказал:

Да уж. 500 ТБ, да на скорости 4 Гбит/с — по самым оптимистичным подсчетам это 11,6 суток.

Вот если использовать сжатие...

[alibek]

то...

[straus]

О, нововое слово в технологиях - научились сжимать mp4.

[jffulcrum]

H.264/5 для лохов, GZip - выбор мастеров!

[passer]

mp4 - контейнер, внутри может быть и mpeg4 part2 (xvid/divx) и современные ныне H.264-265

так что сжатие/перекодирование может иметь место, если видеоархив старый

[jffulcrum]

Обычные архиваторы с видео плохо обращаются. А перекодировать 500 Тб...уф, особенно если не располагаешь ThreadRipper или батареей GPU. В ЦОД обычно за превышение лимита электричества чарджат

[straus]

13 часов назад, passer сказал:

mp4 - контейнер, внутри может быть и mpeg4 part2 (xvid/divx) и современные ныне H.264-265

так что сжатие/перекодирование может иметь место, если видеоархив старый

В любом случае обычные архиваторы, равно как и архивация на лету, не пакуют не только mp4, но и вообще любой mpeg, а также mjpeg и даже jpg.

[Saab95]

2 часа назад, straus сказал:

В любом случае обычные архиваторы, равно как и архивация на лету, не пакуют не только mp4, но и вообще любой mpeg, а также mjpeg и даже jpg.

При передачи данных есть заголовки пакетов, служебная информация, подтверждения - это все хорошо упаковывается.

Кроме всего есть всякие базы данных, текстовые элементы и прочая информация, которая сжимается.

 

Поэтому просто сжатие в канале передачи данных может увеличить общую скорость на большом объеме данных до 10-20-30 процентов, даже если там видео передается.

[straus]

21 минуту назад, Saab95 сказал:

При передачи данных есть заголовки пакетов, служебная информация, подтверждения - это все хорошо упаковывается.

Кроме всего есть всякие базы данных, текстовые элементы и прочая информация, которая сжимается.

Ну-ка ну-ка, с этого момента подробнее!

[alibek]

Не нужно, а то откроются бездны.

На это лето Сааба уже достаточно.

[sirmax]

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

Не нужно, а то откроются бездны.

На это лето Сааба уже достаточно.

Не, пусть пишет, лето ж только началось 🙂

[Saab95]

В 31.05.2025 в 01:20, straus сказал:

Ну-ка ну-ка, с этого момента подробнее!

На микротике это IP - Packing.

[sirmax]

В 02.06.2025 в 01:00, Saab95 сказал:

На микротике это IP - Packing.

Оно это каким алгоритмом делает? 
модуль там аппаратный в отдельном слоте … ?

[alibek]

Алгоритмом "нужно больше микротиков".

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

Если трафик между точками 4-6 Гбит/с (как писали выше), значит нужно будет где-то десяток микротиков, чтобы разбить каналы по 600-700 Мбит/с, которые тот сможет вытянуть.

[straus]

Наверное всё же два десятка микротиков? Ведь с другой стороны тоже должны быть микротики, которые понимают этот IP-Packing.

Гм. Интересно, процента 2-3 получится сэкономить на упаковке?

[jffulcrum]

В 02.06.2025 в 01:00, Saab95 сказал:

IP - Packing.

Это на L2 фактически работает, для варианта между стойками в одном ЦОД, а не между датацентрами через виртуальные каналы

[alibek]

Мда. Я и забыл, что у разработчиков микротика свой собственный язык и терминология.

Они think different.

IP Packing — это не архивация (сжатие), это агрегация пакетов.

То есть да, для 4-6 Гбит/с нужна будет стойка микротиков, десятком не обойтись.

[Ivan_83]

8 hours ago, straus said:

Интересно, процента 2-3 получится сэкономить на упаковке?

Нет, скорее всего экономия будет отрицательной.

Можно экономить на передаче заголовков и на агрегации:

- тут агрегировать нечего - по TCP и так полетят 99,99% полноразмерных пакетов с данными

- заголовки - тоже не подрезать, ибо они в минимальном наборе представлены

[Saab95]

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

IP Packing — это не архивация (сжатие), это агрегация пакетов.

Там и сжатие и агрегация, как настроить.

 

10 часов назад, alibek сказал:

Если трафик между точками 4-6 Гбит/с (как писали выше), значит нужно будет где-то десяток микротиков, чтобы разбить каналы по 600-700 Мбит/с, которые тот сможет вытянуть.

CCR1036 на упаковке со сжатием выдавал гиг, скорость канала была такая, больше не проверяли на реальном трафике.

 

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

Можно экономить на передаче заголовков и на агрегации:

- тут агрегировать нечего - по TCP и так полетят 99,99% полноразмерных пакетов с данными

- заголовки - тоже не подрезать, ибо они в минимальном наборе представлены

В обратную сторону прилетает пачка ответов на доставку, они же маленького размера, упаковываются в один пакет 1500 байт. Уже быстрее будет.

 

Точно так же и в сторону передачи, сами заголовки и т.п. занимают какой-то размер, экономия не менее 10-15 процентов будет.

[Ivan_83]

50 minutes ago, Saab95 said:

В обратную сторону прилетает пачка ответов на доставку, они же маленького размера, упаковываются в один пакет 1500 байт. Уже быстрее будет.

Не будет быстрее, более того TCP стёк умеет всякие SACK и прочие 100500 опций для ускорения и  оптимизации.