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

Простой инструмент репликации томов для большого набора данных?

Я ищу решение следующего:

Сервер A (сайт A) - Win 2008 R2 - около 10 ТБ (максимум 15 ТБ) данных - более 8 миллионов файлов

Сервер B (сайт B) - Win 2008 R2

Я хочу синхронно реплицировать том сервера A на том на сервере B для избыточности данных. Что-то, что я могу сказать своим пользователям: «Идите сюда за данными», когда / если Сервер A выйдет из строя из-за проблем с машиной, катастрофы и т. Д.

В Windows 2008 R2 есть DFS, но Microsoft явно не поддерживает такой большой набор данных (или, точнее, более 8 миллионов файлов - согласно документам, которые я смог найти).

Я также посмотрел на Veritas Volume Replication, но мне кажется, что этого слишком много, так как мне также потребуется Veritas Volume Manager.

Существует множество программ "резервного копирования", которые делают резервную копию 1-1, что было бы нормально, но поскольку она будет передаваться через Интернет, я бы хотел что-то, что имеет сжатие во время передачи, как у DFS.

Есть ли у кого-нибудь предложения по этому поводу?

Я использовал Двойное движение для перемещения больших наборов данных через Интернет. Они используют репликацию на уровне байтов и отслеживают изменения в файлах. Также есть хороший планировщик пропускной способности, который позволяет меньше использовать в течение дня и активировать его ночью и в выходные. Также он неплохо восстанавливается в случае разрыва связи.

Теперь я предполагаю, что это своего рода MSA, подключенная к физическому компьютеру, но если вы используете SAN, обратитесь к поставщику SAN за вариантами асинхронной репликации.

Какую бы репликацию вы ни использовали, есть пара вещей, о которых стоит подумать:

  1. Пропускная способность на исходной и целевой стороне
  2. Скорость изменения файла

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

Повторная индексация баз данных, дефрагментация и массовое перемещение / добавление / удаление файлов вызывали у меня головные боли в прошлом.

Надеюсь, моя прошлая боль поможет тому, кто это прочитает! : D

Ключом к рассмотрению репликации является поиск «согласованного набора» данных, который реплицируется. Например: Db и соответствующие файлы журнала должны реплицироваться "согласованным" способом, чтобы данные можно было использовать на другом реплицированном сайте.

Вторая важная особенность, на которую следует обратить внимание, - это время, необходимое для восстановления в случае обрыва соединения. Репликация начинается с того места, где закончилась? Повторно запускает репликацию?

Третий - насколько хорошо (или хуже) они работают в различных условиях сети и какова степень использования полосы пропускания.

Другие важные вещи, на которые следует обратить внимание, - сохраняются ли права доступа к файлам? Поддерживаются ли другие атрибуты файла, например. что происходит со сжатыми папками? Что происходит с зашифрованными файлами? Реплицируются ли открытые файлы? и т. д. и т. д.

Учитывая все вышесказанное, решения блочной репликации намного лучше, чем репликация на основе файлов. Блочная репликация хоста будет дешевле, чем блочная репликация вне хоста.

DFSR в 2003 R2 (2008 и 2008 R2, вероятно, гораздо более масштабируемы, если не считать x64) прекрасно работал для нас с 75 серверами со всеми на разных каналах WAN (1-10 МБ), синхронизируя файлы общим объемом не менее 500 ГБ (на каждый сервер раз 75 ) на плохих, медленных или загруженных каналах WAN, которые я бы просто рекомендовал сделать все возможное, чтобы DFSR заработал. Нам было легче управлять всей организацией, чем Veritas, но это было в 2006-7, после выхода 2003 R2. BITS, контролирующий пропускную способность GPO, - ваш друг.

Одна из особенностей DFSR заключается в том, что в нем хранится папка с копиями всех измененных блоков, которые необходимо отправить, поэтому хранение - это то, к чему вы хотите относиться либерально. Мне любопытно, какие ограничения вы указываете, так как я думаю, что файлы размером 8M будут хороши в контексте большого количества ресурсов (RAM, CPU, Disk). Я не знаю, сколько у нас файлов.

Кроме того, в прошлом DFSR был несовместим с программным обеспечением для резервного копирования, аудио / видео и другим программным обеспечением. В 2008-2009 годах мы обнаружили, что Netbackup не любит DFSR и сообщал об успешном выполнении резервного копирования файлового сервера, но на самом деле НИЧЕГО не делал резервных копий. Только при тестировании восстановления мы обнаружили эту ужасную, ужасную ошибку в Netbackup. Если есть одна вещь, которую вы никогда не хотите, чтобы системы резервного копирования делали, так это сообщать об успешном резервном копировании, но действительно иметь пустую ленту.

В любом случае, я выражаю доверие DFSR, особенно в его 3-й версии с 2008 R2, поскольку вам следует попробовать, если вы не можете найти продукт поставщика, в котором прямо говорится, что они протестировали ваш сценарий. Часто то, что Microsoft официально поддерживает, гораздо более консервативно по отношению к тому, что, как они знают, будет работать. Очевидно, что ваш опыт может отличаться, и вы должны определить свой собственный уровень риска, на который вы готовы пойти.

У меня есть клиент, использующий SureSync продукт для репликации данных на файловый сервер «горячего резерва». Они копируют чуть меньше 2 ТБ, и это работает очень хорошо. Он использует журнал изменений NTFS для отслеживания обновлений файлов и выполняет дельта-репликацию.

Я не нахожу опубликованных ограничений продукта, поэтому вам, вероятно, лучше обратиться к "производителю", чтобы узнать об этом.

Хотя Veritas Volume Manager с опцией Veritas Volume Replicator стоит недешево, он может предложить некоторые преимущества, например:

  • Он работает на уровне блоков, поэтому ему не нужно реплицировать файлы целиком или ждать закрытия файлов, прежде чем можно будет реплицировать сохранения.
  • Точность порядка записи сохраняется, поэтому порядок, в котором данные изменяются на первичном сервере, совпадает с порядком изменения данных на вторичном - это хорошо для баз данных и т.п.
  • Если вам необходимо переключиться на вторичный, то ваши изменения вторичного сервера легко синхронизируются с первичным.
  • Сжатие и троттлинг передачи.

Доступен инструмент (VRAdvisor), который вы можете использовать для отслеживания скорости изменения данных, который затем сообщит вам, сколько пропускной способности вам нужно, чтобы поддерживать вторичный в пределах заданного количества изменений данных первичного.