Централизованное распределение / синхронизация наборов больших файлов через локальную сеть
Несмотря на то, что я полностью осознаю, что версии этого вопроса задавались много раз, я постараюсь не повторять их.
У меня много наборов файлов (некоторые файлы маленькие, но некоторые большие, например, ~10-20 ГБ). У меня есть несколько серверов, каждый из которых может разместить один или несколько из этих наборов файлов. Конечно, один сервер может содержать 50% от общего числа наборов, а другие 50% могут содержать другое количество наборов.
Вы можете думать о наборе как о коллекции больших медиа-файлов, действительно больших библиотек изображений, завершенных приложений, чего угодно, это не имеет большого значения, если в наборе есть большие файлы.
Сервер может обновлять свою копию набора в любой момент времени (либо заменяя файлы в наборе совершенно новыми файлами, либо применяя исправления к некоторым файлам, что приведет к получению почти одинаковых файлов с небольшими отличиями).
С другой стороны, у меня есть много клиентов, которые должны иметь возможность получать любой заданный набор (или несколько наборов) с серверов и сохранять свои копии наборов в актуальном состоянии (синхронизированными) с наборами на сервере всякий раз, когда кто-то хочет использовать набор.
Инструменты, которые я рассмотрел, следующие:
- rsync - отлично подходит для синхронизации файлов малого и среднего размера, но не настолько идеален для синхронизации больших файлов, поскольку использует алгоритм, который считывает весь файл с обеих сторон, чтобы определить, следует ли скопировать файл или нет. Это нормально, когда файл должен быть скопирован в первый раз или когда файл полностью изменен, но не так хорошо, когда, скажем, изменен только 1% файла размером 10 ГБ.
- SVN - Это замечательно, когда дело доходит до поиска различий и передачи только тех дельт вокруг, но я не уверен, насколько он оптимален, когда речь идет об использовании диска (весь набор будет вдвое больше как на клиенте, так и на сервере, из-за чтобы однажды установить хранится в репозитории?).
- Торрент - Это может быть осуществимо в распределении. Например, создайте торрент для каждого набора на сервере, начните заполнять его там, и клиенты, которые получают эти наборы, также продолжают заполнять другие клиенты, таким образом распределяя нагрузку по каждому компьютеру, на котором хранится копия набора. Тем не менее, я не уверен, сможет ли он каким-то образом распределять различия после изменения настроек на сервере... Требуется ли создание нового торрента для каждого изменения? Кроме того, я не знаю, как торрент будет вести себя в локальной сети со скоростью (может ли он быть в состоянии передавать файлы между одним сервером и одним клиентом на максимальной скорости, ограниченной по сети, или он добавляет некоторые серьезные издержки протокола? Как насчет перегрузка сети?)
- Индивидуальное решение. Ну, не так много здесь, чтобы добавить, но это, скорее всего, будет заново изобретать колесо, и что какое-то существующее решение, скорее всего, будет соответствовать моим потребностям, если бы я только знал об этом.
Итак, вопрос: какой метод распределения / синхронизации (утилиты, подход) лучше всего подходит для моей ситуации?
4 ответа
В конце концов, я выбираю BitTorrent. Вот почему
- Он быстрый: он полностью насыщает восходящий канал сервера (хотя на самом деле он замедляет работу сети на задействованных компьютерах из-за безумного количества крошечных пакетов, которые можно несколько оптимизировать, отключив использование пакетов UDP).
- Это действительно хорошо и быстро для распределения любого набора изменений по любому набору файлов (наименьшая единица данных протокола BT - это "кусок", размер которого варьируется от 4 КБ до 4 МБ, и каждый файл разбивается на части, части проверяются суммой, и затем передаются только разные фрагменты, независимо от того, имеет ли размер рассматриваемый файл КБ или ГБ - это делается очень быстро).
- Он полностью распределен: вы можете размещать множество наборов файлов на разных исходных серверах, и клиенты могут получать файлы независимо от того, где они хранятся (я знаю, что это спорный вопрос).
- После того, как сервер загрузит свою копию контента в сеть, нагрузка на сервер резко упадет, и время для недавно развернутого клиента для получения обновленных наборов резко сократится, поскольку наборы затем принимаются из всей сети компьютеров, а не из одного централизованного сервера.,
- Он может быть использован в небольших установках с не более чем правильно настроенной клиентской программой uTorrent, которая может использоваться как для создания.torrent, так и для отслеживания начальных значений / пиров, а также для получения данных на клиентских компьютерах.
О единственных двух минусах, с которыми я столкнулся:
- Создание торрента для больших наборов данных может занять много времени (много: 5-10 минут), пока создается.torrent (весь набор читается, разбивается на части, проверяется сумма), что еще больше замедляется, если наборы недоступны локально, но вместо этого извлекается из сети. Кроме того, требуется такое же количество времени, когда кто-то хочет распределить произвольное количество изменений по большому набору - каждому компьютеру - как серверу, так и всем клиентам - необходимо выполнить часть контрольной суммы, которая, как я сказал, может быть длительной. (Здесь я должен отметить, что в моем случае изменения были действительно небольшими, и было бы нецелесообразно копировать ГБ данных только для нескольких МБ измененных данных, так что это очень приемлемый компромисс.)
- Для того, чтобы начальная сеялка разогналась до полной скорости, может потребоваться некоторое время, поэтому этот метод не подходит, если нужно просто скопировать файлы между, скажем, менее чем 5 компьютерами (но на самом деле преимущества можно заметить даже при 2-3 компьютера).
Вот, пожалуйста, я помог тому, кто столкнулся с той же дилеммой.
Если вы можете с уверенностью предположить, что все клиенты будут иметь согласованные версии, вы можете использовать готовый инструмент для бинарного исправления и развернуть свое собственное решение, чтобы распространять различия между клиентами и применять их. Однако, если у клиентов будут несовместимые версии, вам придется прочитать файл на клиенте, чтобы определить, какие различия нужно отправлять (в основном проблема rsync). Однако, если клиенты последовательны, вы можете просто вычислить различия один раз и отправить их.
Похоже, вы ищете что-то вроде реализации многоадресной rsync. Я никогда не использовал этот инструмент, но на него стоит обратить внимание. Похоже, что они только нацелены на Linux и Unix OS прямо сейчас.
Вы можете попробовать кешировать сетевые файловые системы:
Они оба кэшируют чтение и запись локально и, как таковые, не связаны производительностью сети, если у вас достаточно локального пространства для кэширования.
Вы можете использовать Windows Storage Server 2008, он продается с устройством NAS от разных провайдеров, но он очень хороший и эффективный, с хранилищем с одним экземпляром также сэкономит вам несколько ГБ. Затем у вас может быть выделенное устройство, обслуживающее такие большие файлы.
Большинство этих NAS поставляются с Dual Nic, и вы даже можете получить Quad Port nics, поэтому, если у вас есть инфраструктура Gigabit или выше, вы можете объединить / объединить эти порты в очередь для обеспечения большей пропускной способности.
Добавьте больше оперативной памяти в него, и вы должны быть готовы к работе, www.broadberry.com http://www.broadberry.com/nasstorage_servers.html
Dell также продает Window Storage Server, приобретите тот, который имеет iscsi, чтобы вы могли использовать хранилище, если позже у вас тоже будет iscsi.
надеюсь, это поможет