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