у нас есть сервер хранения с объемом около 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, но она немного новее.