Мне нужно перенести около 1 ТБ данных, состоящих из файлов меньшего размера (большинство из которых менее 100 КБ), на другой сервер. Я даже не перечислил полностью файлы, но по оценкам 1-2 миллиона.
Первоначальная копия с использованием SCP заняла больше недели. Теперь нам нужно синхронизировать изменения. Ежедневно добавляются сотни и тысячи файлов.
Я пытался использовать rsync (v3), но это занимает слишком много времени. К тому времени, когда он закончится, мы снова увидим несинхронизацию данных.
Я видел здесь похожие вопросы, но они немного старше и задаются вопросом, есть ли какие-нибудь новые инструменты, которые помогут в этом процессе.
Проблемы еще больше усложняются тем, что исходные данные находятся в общей системе iSCSI с низкой производительностью чтения.
Последняя стратегия может заключаться в том, чтобы повторить миграцию данных и попросить разработчиков написать инструмент для регистрации всех новых файлов, добавленных в процессе миграции. Ключи структуры каталогов с уникальным идентификатором очень широкие и глубокие, поэтому новые файлы разбросаны внутри этой структуры, и переписать приложение, чтобы поместить новые файлы в конкретный каталог, не сработает.
Любые стратегии приветствуются.
ОС - это RHEL 5, переходящая в RHEL 6.
Я бы хотел ответить: «Прекратите злоупотреблять файловой системой, обращаясь с ней как с базой данных», но я уверен, что это вам не очень поможет;)
Во-первых, вы должны понимать, что если ваше ограничение связано с полосой пропускания, доступной для чтения, вы ничего не можете сделать для повышения производительности с помощью простой команды синхронизации. В таком случае вам придется разделить данные, когда они будут записаны, либо изменив способ создания файлов (что означает, как вы правильно догадались, попросив разработчиков изменить исходную программу), либо с помощью продукта, который делает геозеркальное отображение (например, двойной дубль: посмотри вокруг, я уверен, ты найдешь альтернативы, это всего лишь пример).
В подобных случаях основной причиной проблемы обычно являются не данные файла, а доступ к метаданным. Поэтому ваша первая стратегия будет заключаться в том, чтобы разделить нагрузку на несколько процессов, которые воздействуют на (полностью) разные каталоги: это должно помочь файловой системе не отставать от предоставления вам необходимых метаданных.
Другая стратегия - использовать для этого вашу систему резервного копирования: воспроизвести ваши последние инкрементные резервные копии на целевом сервере, чтобы синхронизировать базу данных.
Наконец, есть и другие экзотические стратегии, которые можно применить в конкретных случаях. Например, я решил аналогичную проблему на сайте Windows, написав программу, которая загружала файлы в файловую систему каждые несколько минут, таким образом поддерживая чистоту FS.
Я не думаю, что что-то изменилось. Если вы можете заморозить данные в исходной системе, я думаю, что некоторые вариант tar будет самым быстрым. В противном случае rsync по-прежнему является следующим лучшим способом, при этом обязательно используйте переключатель всего файла и алгоритм сжатия с меньшей нагрузкой на ЦП (например, arcfour). Есть ли у вас возможность выполнить копирование на уровне блоков? Вы упомянули хранилище iSCSI. Будет ли новая система иметь хранилище, подключенное к iSCSI?
Это делается поэтапно:
1) начальный транслятор с использованием scp 2) некоторые данные обновлены с помощью rsync 3) разработчики пишут сценарий для извлечения файлов, добавленных с шага 1 в систему 4) будут прокси-данные с исходного сервера на новый сервер во время изменения DNS 5) изменить DNS и получить избавиться от недостаточной производительности общих служб iSCSI.