Я ищу решение следующего:
Сервер 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 за вариантами асинхронной репликации.
Какую бы репликацию вы ни использовали, есть пара вещей, о которых стоит подумать:
Если ваша скорость изменения слишком высока на стороне источника и у вас недостаточно пропускной способности для ее преодоления, вы никогда не получите хорошей репликации.
Повторная индексация баз данных, дефрагментация и массовое перемещение / добавление / удаление файлов вызывали у меня головные боли в прошлом.
Надеюсь, моя прошлая боль поможет тому, кто это прочитает! : 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), который вы можете использовать для отслеживания скорости изменения данных, который затем сообщит вам, сколько пропускной способности вам нужно, чтобы поддерживать вторичный в пределах заданного количества изменений данных первичного.