Является ли rsync хорошим кандидатом для реализации отработки отказа (очень большой набор данных)?
У меня есть большой набор данных (+100 ГБ), которые можно хранить в файлах. Большинство файлов будет в диапазоне от 5 до 50 тыс. (80%), затем от 50 до 500 тыс. (15%) и>500 тыс. (5%). Максимальный ожидаемый размер файла составляет 50 МБ. При необходимости большие файлы можно разбить на более мелкие части. Файлы также могут быть организованы в структуру каталогов.
Если некоторые данные должны быть изменены, мое приложение создает копию, изменяет ее и, в случае успеха, помечает ее как последнюю версию. Затем старая версия удаляется. Это безопасно при столкновении (так сказать).
Мне нужно внедрить систему аварийного переключения, чтобы эти данные были доступны. Одним из решений является использование системы баз данных Master-Slave, но они хрупкие и создают зависимость от технологии баз данных.
Я не являюсь системным администратором, но я прочитал об инструкции rsync. Это выглядит очень интересно. Мне интересно, если установка некоторых узлов отказоустойчивости и использовать rsync от моего мастера является ответственным вариантом. Кто-нибудь пробовал это раньше успешно?
я) Если да, я должен разделить мои большие файлы? Является ли rsync умным / эффективным при обнаружении файлов для копирования / удаления? Должен ли я реализовать определенную структуру каталогов, чтобы сделать эту систему эффективной?
ii) Если мастер выйдет из строя и подчиненный займет час (например), сделает ли его мастер обновленным снова так же просто, как запустить rsync наоборот (от ведомого к ведущему)?
iii) Бонусный вопрос: есть ли возможность внедрения систем с несколькими мастерами с помощью rsync? Или возможен только главный раб?
Я ищу советы, советы, опыт и т.д... Спасибо!!!
2 ответа
Является ли rsync умным / эффективным при обнаружении файлов для копирования / удаления?
Rsync чрезвычайно эффективен при обнаружении и обновлении файлов. В зависимости от того, как изменяются ваши файлы, вы можете обнаружить, что меньшее количество больших файлов гораздо проще синхронизировать, чем множество маленьких файлов. В зависимости от того, какие параметры вы выберете, при каждом запуске он будет выполнять stat() для каждого файла с обеих сторон, а затем передавать изменения, если файлы разные. Если меняется только небольшое количество ваших файлов, то этот шаг для поиска измененных файлов может быть довольно дорогим. Многие факторы влияют на то, сколько времени занимает rsync. Если вы серьезно относитесь к этому, вам следует провести много испытаний на реальных данных, чтобы увидеть, как все работает.
Если мастер выходит из строя и подчиненный в течение часа (например) вступает во владение мастером, обновляя его так же просто, как запуск rsync наоборот (от ведомого к мастеру)?
Должно быть.
Есть ли возможность реализации систем с несколькими хозяевами с помощью rsync?
Unison, который использует библиотеки rsync, позволяет осуществлять двунаправленную синхронизацию. Это должно разрешать обновления с любой стороны. При правильных настройках он может выявлять конфликты и сохранять резервные копии любых файлов, в которые были внесены изменения на обоих концах.
Не зная больше об особенностях, я не могу с уверенностью сказать вам, что это путь. Возможно, вам придется взглянуть на DRBD или какой-то другой подход кластерного устройства / файловой системы, который синхронизирует вещи на более низком уровне.
Должен ли я разделить мои большие файлы?
rsync умен, но очень большие файлы могут быть значительно менее эффективными для синхронизации. Вот почему:
Если изменяется только часть файла, то rsync достаточно умен, чтобы отправлять только эту часть. Но чтобы выяснить, какую часть отправить, нужно разделить файл на логические порции по X байт, построить контрольные суммы для каждого порции (с обеих сторон), сравнить порции, отправить различия, а затем заново создать файл на получающий конец.
С другой стороны, если у вас есть куча небольших файлов, которые не меняются, то даты и размеры будут совпадать, и rsync пропустит шаг контрольной суммы и просто предположит, что файл не изменился. Если мы говорим о большом количестве ГБ данных, вы пропускаете МНОГО ввода-вывода и экономите МНОГО времени. Таким образом, несмотря на то, что при сравнении большего количества файлов возникают дополнительные издержки, все равно получается меньше времени, необходимого для фактического чтения файлов и сравнения контрольных сумм.
Таким образом, хотя вам нужно столько файлов, сколько необходимо, вы также хотите иметь достаточно файлов, чтобы не тратить много времени на ввод-вывод, работая с неизмененными данными. Я бы рекомендовал разделить данные по логическим границам, которые использует ваше приложение.
снова обновляет мастер так же просто, как запуск rsync наоборот
С точки зрения файловой системы, да. Но у вашего приложения могут быть другие требования, которые усложняют ситуацию. И, конечно же, вы вернетесь к своему последнему контрольному пункту, на котором вы перешли к своему рабу.
Есть ли возможность реализации систем с несколькими хозяевами с помощью rsync?
Технически да, но на этом пути лежит безумие. При условии, что все работает отлично, тогда все будет хорошо. Но когда происходит сбой, вы можете начать сталкиваться с проблемами с изменениями (и особенно удаляет), синхронизируясь в неправильном направлении, перезаписывая ваши хорошие файлы вашими плохими, или удаляя вставленные файлы, или снова появляются призраки удаленных файлов. Большинство людей рекомендуют против этого, но вы можете попробовать, если хотите.
советы, советы, опыт
Если вы ищете мастер / мастер настройки с синхронизацией на лету, я бы порекомендовал DRBD. Это значительно сложнее в настройке и обслуживании, но гораздо более функционально. Он выполняет синхронизацию на уровне блоков самого диска, а не файлов на нем. Чтобы сделать это "в режиме онлайн", вам нужна файловая система, способная выдержать такой тип синхронизации, как GFS.
Rsync больше похож на систему моментальных снимков, чем на систему непрерывной синхронизации.