Назад | Перейти на главную страницу

синхронизация серверов хранения

у нас есть сервер хранения с объемом около 20 ТБ медиафайлов, которые мы хотим синхронизировать со вторым сервером хранения для резервного копирования и восстановления после сбоя. факты таковы:

в настоящее время мы используем простой rsync на третьем сервере для выполнения синхронизации.

Я хотел бы знать, есть ли инструменты лучше для такого количества файлов - коммерческие или с открытым исходным кодом?

большое спасибо,

Вы можете увидеть повышение производительности, если бы вы просто использовали вручную свернутый сценарий, который проверял время создания файла (и, возможно, размер) и сравнивал его со списком (или реестром) файлов, которые уже были синхронизированы с сервером резервного копирования.

Rsync может тратить много времени на проверку изменений во ВСЕХ ваших файлах, когда может быть достаточно проверки одного или двух атрибутов файла.

Мы делаем нечто подобное, но в гораздо меньшем масштабе, чтобы синхронизировать фотографии между двумя серверами. Я написал сценарий bash, который поддерживает отсортированный реестр файлов, объединенных вместе с указанием времени создания и размеров файлов. Каждый раз, когда запускается сценарий, он проверяет сервер, с которого мы синхронизируем (исходный сервер), и генерирует отсортированный список файлов с указанием времени создания и размеров файлов. Затем я использую комм , чтобы сравнить эти два реестра и распечатать только те записи, которые появляются на исходном сервере. Это список файлов, которые необходимо синхронизировать с новым сервером.

Затем я просто просматриваю новые файлы. У меня есть несколько ловушек, блокировок и троттлинга, чтобы не перегружать вещи, но они работают и работают довольно быстро.

Приятно то, что вам не нужно синхронизировать все для запуска, если у вас уже есть много файлов в обоих местах. Просто создайте начальный реестр на целевом сервере, затем запустите скрипт cron, и он начнет синхронизацию с этого момента. Если в конечном итоге вам понадобится синхронизировать файл, о котором вы никогда не думали, все, что вам нужно сделать, это прикоснуться к нему (чтобы изменить информацию о дате) на исходном сервере, и он будет синхронизирован при следующем запланированном запуске.

Итак, для каталога, который выглядит так:

-rw-r----- 1 example example  38801 2010-01-21 11:45 1.JPG
-rw-r----- 1 example example  38801 2010-01-21 11:45 2.JPG
-rw-r----- 1 example example 757638 2010-01-21 11:45 3.JPG
-rw-r----- 1 example example  16218 2010-01-22 15:07 9.JPG

Этот список преобразуется скриптом в файл реестра, который выглядит следующим образом:

1.JPG_2010-01-21_11:45_38801
2.JPG_2010-01-21_11:45_38801
3.JPG_2010-01-21_11:45_757638
9.JPG_2010-01-22_15:07_16218

Я храню этот реестр (файлов исходного сервера) на целевом сервере. Каждый раз, когда задание cron выполняется на целевом сервере, я создаю список файлов, находящихся в данный момент на исходном сервере, в том же формате. Допустим, в листинге появилось несколько новых файлов 10.JPG и 11.JPG.

-rw-r----- 1 example example  38801 2010-01-21 11:45 1.JPG
-rw-r----- 1 example example  38801 2010-01-21 11:45 2.JPG
-rw-r----- 1 example example 757638 2010-01-21 11:45 3.JPG
-rw-r----- 1 example example  16218 2010-01-22 15:07 9.JPG
-rw-r----- 1 example example  16218 2010-02-24 11:00 10.JPG
-rw-r----- 1 example example  16218 2010-02-24 11:00 11.JPG

Текущий файловый реестр будет выглядеть так:

1.JPG_2010-01-21_11:45_38801
2.JPG_2010-01-21_11:45_38801
3.JPG_2010-01-21_11:45_757638
9.JPG_2010-01-22_15:07_16218
10.JPG_2010_02_24_11:00_16218
11.JPG_2010_02_24_11:00_16218

Бег комм против старого реестра и текущего реестра и вырезая первое поле (файл, который нужно скопировать), например:

comm -23 ${CURRENT_REG} ${OLD_REG} | cut -d'_' -f1 > ${SYNC_LIST}

Получит список файлов (по одному в строке), которые необходимо скопировать (я использую scp) на резервный (целевой) сервер:

10.JPG
11.JPG

Затем вы просто обрабатываете этот список файлов в цикле.

В комм команда выше в основном говорит: покажи мне все, что ТОЛЬКО существует в первом файле. Сравнения, которые он делает, также очень быстрые. В конце концов, это просто сравнение строк в текстовом файле; даже если этот файл очень большой. К счастью, вы заполнили этот текстовый файл некоторыми базовыми метаданными о своих файлах и через комм, очень быстро сравнивают эти данные.

Хорошая вещь в добавлении этих метаданных в список заключается в том, что это допускает ситуации, когда файл имеет изменилось между синхронизациями. Скажем, появилась новая версия файла или возникла проблема со старой. Имя файла будет существовать в старом реестре, но его метаданные (отметка времени создания файла и размер) будут другими. Таким образом, текущий реестр файлов покажет эту разницу и комм сравнение покажет, что эта информация существует только в первом файле. Когда вы создаете список файлов для копирования, это имя файла будет там, и ваша команда копирования перезапишет устаревший файл с тем же именем.

Остальное - просто детали:

  • Используйте блокировку файлов / семафоры, чтобы сценарий не запускался сам по себе, если последний раз он запускался не к следующему разу.
  • Используйте временные файлы для сохранения текущего списка файлов и списка процессов, а затем используйте ловушки для их очистки при выходе из скрипта.
  • Когда вы все сделаете, скопируйте текущий список файлов поверх старого списка файлов, чтобы быть готовым к следующему сравнению, но делайте это только в том случае, если в реестре есть файлы (в противном случае вы скопируете пустой реестр и синхронизируете ВСЕ в следующий раз).

Надеюсь, это поможет. Это хорошо работает в нашей ситуации, но, как и все, может не работать в рамках ограничений вашей организации или настройки. Удачи, по крайней мере, это может дать вам несколько идей.

Вот несколько вариантов, на которые стоит обратить внимание.

Смотреть в DBRD если вам не нужен доступ к обеим копиям одновременно. Это связано с ограничениями файловой системы, а не с ограничениями DBRD, и есть несколько обходных путей для доступа ко второй копии, если вам нужно. Но проект был недавно принят в ядро, поэтому поддержка его в будущем должна быть довольно простой.

Другой вариант - файловая система, например GlusterFS. Что можно настроить на 2 узла реплицированная конфигурация. Я думаю, что это было бы идеально, поскольку это должно обеспечить лучшее переключение при отказе и масштабируемость. MondoDB также выглядит интересным для такого рода вещей, используя свою GridFS, но она немного новее.