Репликация данных. Настройка репликации DFS

13.04.2019

Флешка

Данные можно реплицировать как в пределах локальной сети, так и через глобальную WAN сеть. Технология DFSR была спроектирована с расчетом на медленные WAN сети и работает столь же надежно через Интернет, как и в пределах одного здания.
Возникает вопрос- чем же эта функция по сути отличается от пространства имен DFS? Основное ее отличие- это наличие функции Алгоритма дифференциальной компрессии -- Remote differential compression algorithm (RDC), который применяется для репликации изменений. Основная идея этого алгоритма состоит в том, что реплицируются только измененные части файла. Например, если есть большой текстовый документ, и мы добавили несколько страниц в середину документа, то только эти несколько страниц и будут переданы по сети во время следующего сеанса синхронизации. Тем самым наиболее предпочтительней использовать репликацию DFS в медленных сетях, например для репликации одной (нескольких) папок между удаленно расположенными офисами с медленными каналами.
Репликация данных устойчива к проблемам с сетью. Если связь с удаленной машиной прервется, то репликация, разумеется, остановится. Но как только сеть будет снова работать, то репликация начнется с того места, где она прервалась.
Рассмотрим пошаговую инструкцию настройки репликации DFS. Первое что необходимо сделать - .
После этого создаем группу репликации (группа репликации - это набор серверов, именуемых членами, которые участвуют в репликации одной или нескольких реплицируемых папок. Реплицируемая папка - это папка, для которой поддерживается синхронизация на каждом из членов), для этого нажимаем правой кнопкой мыши на «Репликации» , выбираем «Новая группа репликации…»

В типе реплицируемой группе репликации, рекомендую указать «Универсальная группа репликации» , поскольку этот тип является более гибким в использовании в дальнейшем.

В следующем окне указываем имя группы репликации, пишем комментарий (по желанию) и смотрим тот ли домен используется (если в вашей организации используется несколько доменов).

Затем указываем сервера, которые будут входить в группу репликации (их может быть два и более).

В окне выбора топологии указываем тип топологии подключения, читая комментарии под каждым типом выберите, подходящий для вас и нажмите «Далее» . В данном примере используется «Полная сетка» .

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

В окне «Основной член репликации» указываем сервер на котором хранятся данные.

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

Затем указываем папку на которую необходим реплицировать (на другом сервере).

После этого просматриваем все указанные настройки и если все указанно верно, нажимаем «Создать» .

Теперь в категории «Репликации» видим созданную репликацию Common .

Для того что бы запустить репликацию вручную, необходимо нажать на репликацию, в данном примере "Сommon" , затем зайти во вкладку "Подключения" и нажав правой кнопкой на любом подключении выбрать "Реплицировать сейчас" .

Затем указываем сервера, которые будут входить в группу репликации (их может быть два и более).

В окне «Основной член репликации» указываем сервер на котором хранятся данные.

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

Затем указываем папку на которую необходим реплицировать (на другом сервере).

После этого просматриваем все указанные настройки и если все указанно верно, нажимаем «Создать» .

Теперь в категории «Репликации» видим созданную репликацию Common .

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

Есть некая программа, которая использует базу данных и файловую папку. В базе – пути до файлов, файлы соответственно, в сетевой папке.

Папка суммарно размером более терабайта, файлов много. Файлы являют собой сжатый звук и иногда имеют не маленькие размеры.

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

Отказоустойчивость базы данных достигнута посредством использования функционала Always On Availability Groups на MS SQL 2012.

Отказоустойчивость сетевой папки проще всего достигнуть посредством репликации папки средствами DFS.

Отдельно хочу заметить, что коренную папку пространства имен DFS (DFS root) тоже необходимо защитить от отказа. В Windows Server 2008 и выше это достигается без использования технологий кластеризации. Просто после создания корня, добавляем еще один сервер пространства имен. Например – два контроллера домена, они же серверы пространства имен DFS. В случае перезагрузки или поломки одного из них, пользователи продолжат пользоваться пространством имен DFS и ни чего не заметят.

И так, создаем коренную папку DFS. Создаем виртуальную структуру папок для отделов компании. В папках отделов создаем папки указывающие на конечные файловые ресурсы на файловых серверах.

Теперь переходим к настройке репликации DFS для нужной нам папки.

Для включения репликации нам нужно заранее установить на сервера где будет находиться папка, роль “Репликация DFS” (DFS replication) и Компонент “Удаленное разностное сжатие” (Remote Differential Compression).

Затем, заходим в MMC консоль “Управление DFS” (DFS Management), выбираем папку и запускаем мастер репликации:
Указываем сервер:

Папку назначения:
Создаем группу репликации:

Выбираем сервер с основной копией данных (это актуально на время первичной репликации):

Выбираем топологию (если сервера два, то вариантов нет):
Можем выбрать скорость репликации и расписание:

Заканчиваем:
Теперь ждем завершения первичной синхронизации.

И так, репликация настроена, потираем руки и в течение суток получаем жалобу, что папки на серверах отличаются, а значит репликация не работает.

Тратим кучу времени на сравнение папок и копируем вручную отличающиеся куски информации.

Собственно поэтому не любят использовать репликацию DFS.

Всё произошло потому, что ни кто не читал руководство настройке DFS. Как я сказал, папка занимает около терабайта. Там множество файлов, с которыми работают пользователи посредством программы.

Репликация папки происходит путем использования скрытого каталога DfsrPrivate\Staging, а там задействован механизм квот. Квота кэша репликации (Staging Folder) или “Промежуточной квоты” по умолчанию равна 4 гигабайта, что катастрофически мало при объемах данных указанных выше. Потому не работает репликация.

Как повышать? Гадать не наш метод. Смотрим что пишут на Technet .

2003 сервер – Staging quota должна быть размером в девять самых больших файлов в папке репликации.

2008 и 2008 R2 – Staging quota должна быть размером в 32 самых больших файлов в папке репликации.

Тут нам поможет PowerShell.

Пишем команду (заменяем <путь> на путь до нужной папки):

“{0:N0}” -f((get-childitem <ПУТЬ> -recurse | sort-object length -descending | select-object -first 32 | measure-object -property length -sum).sum /1gb)

Получаем суммарный объем 32-х самых больших файлов в гигабайтах, округленный до целого. Идем в настройки репликации:

Применяем. Как вариант, увеличиваем еще и квоту для конфликтов и удаленных файлов.

Не забываем повторить настройку для второго сервера.

P.S: В моём случае, DFSR оказалась не применима, так как приложение выбирает мастера из рабочих машин, где запущено, путём изменения определенного файла, который лежит в файловом хранилище, вместе с данными приложения. Файл обновляется чаще чем раз в секунду незначительной информацией. В файл пишется время и имя машины-мастера. В итоге файл обновляется одновременно на всех серверах и репликация его не проходит, так как DFSR не может определить какая версия файла правильная. В добавок несколько машин одновременно считают себя мастером операций, что приводит к проблемам в приложении.
Если бы разработчики придерживались идеи “сервер-свидетель” и вынесли файл на отдельный ресурс, не совмещая его с данными приложения, то смогли бы сэкономить десятикратно на упрощении аппаратной инфраструктуры.
В итоге придется держать папку с помощью MSFT-кластера или Fault Tolerance в VSphere.

13 апреля 2015 в 09:58

Настройка репликации томов в Windows Server vNext

Блог компании Microsoft

Recovery Mode

Всем доброго времени суток!

Сегодня я хотел бы рассказать Вам про очень интересную функцию, которая будет представлена в новой версии Windows Server vNEXT, и которая уже доступна для тестирования и испытаний в предварительной версии Technical Preview, а именно про репликацию на уровне тома. В WS vNEXT эта фича сейчас называется Storage Replica. Что это за зверь и с чем его есть - подробности под катом.

Параметры и возможности репликации

Репликация хранилища, Storage Replica (SR) - это новая функция в Windows Server, которая позволяет проводить блочную синхронную (а в некоторых случаях - и асинхронную) репликацию на уровне тома между кластерами или серверами Windows Server vNEXT. В качестве транспорта используется протокол SMB3.

На текущий момент поддерживаются варианты репликации «Сервер-Сервер» и «Эластичный Кластер» (Stretch Cluster). Репликация уровня «Кластер-Кластер» пока что не реализована, но присутствует в планах. Поскольку репликация происходит на блочном уровне, то механизму нет особого дела до типа оборудования на котором развернута файловая система. Репликация может быть как синхронная, так и асинхронная (пока что только в сценарии «Сервер-Сервер»). В качестве сетевого механизма коммуникации могут использоваться TCP/IP или RDMA. Поверх реплики могут применяться механизмы дедупликации данных и шифрования на базе BitLocker. Настраивается это чудесное катастрофо- и отказоустойчивое чудо технологий пока исключительно через PowerShell. Для осуществления процесса также необходимо иметь открытыми порты TCP 445 или TCP 5445, быть членами одного домена (объект воздействия с этой точки зрения - хост, и реплицируются тома между хостами, а также возможны сценарии репликации томов в рамках одного хоста). Также важно помнить, что репликация возможна только для томов данных, но не для системного тома - проще говоря, реплицировать «Диск С:» технически не получится, да и не для этой цели разрабатывалась эта технология. Эта технология призвана обеспечить нулевой уровень потери данных (в случае синхронной репликации) или близкой к нулю уровень потери данных (асинхронный сценарий).

Также хочу сразу отметить, что требования к каналу тут также присутствуют определенные: по крайней мере одно соединение 10 Гбит/сек на каждом файловом сервере. Для надежности неплохо было бы убедиться, что отправки нефрагментированного ICMP-пакета размером 1472 байта проходят успешно без потерь на протяжении 5-ти минутного интервала.

Также стоит отметить, что использовать для репликации как в качестве цели, так и в качестве источника, съемные носители а-ля USB-накопитель, нельзя. Права на уровне встроенной группы администраторов Вам также понадобятся.
В целях тестирования Вы можете опробовать все механизмы на ВМ - только помните, что виртуальные диски в таком сценарии должны быть фиксированного типа, а не динамически расширяемые.

Настройка репликации «Сервер-Сервер»

Ну и после ознакомления с вводными по процессу настройки репликации томов, давайте же настроем репликацию «Сервер-Сервер». Только напомню Вам, что сервер в превью - и не стоит этот механизм применят для боевых данных сейчас.На каждом сервере-участнике должна быть установлена роль «File Server» и функция «Storage Replica» или «Windows Volume Replication» (в зависимости от билда сервера.

После этого на одном из серверов-участников исполните командлет PowerShell с админскими правами:

New-SRPartnership -SourceComputerName sr-srv05 -SourceRGName rg01 -SourceVolumeName d: -SourceLogVolumeName e: -DestinationComputerName sr-srv06 -DestinationRGName rg02 -DestinationVolumeName d: -DestinationLogVolumeName e: -LogSizeInBytes 8gb .
В моем примере участвуют два сервера: sr-srv05 и sr-srv06, выделен отдельный том под лог-файлы (он должен быть по размеру на один гигабайт меньше, нежели том репликации и томы-источники и томы-цели.
Для проверки успешности настройки репликации последовательно исполнина обоих серверах-участниках исполните следующий командлет:

Get-WinEvent -LogName *WVR/admin -max 20 | fl

Наличие событий 2200, 5005, 5015, 5001 и 5009 будет признаком успеха.
Если нужны более детальные данные по счетчикам (Get-Counter) , то вот их список:

\Storage Replication Statistics(*)\Total Bytes Received
\Storage Replication Statistics(*)\Total Bytes Sent
\Storage Replication Statistics(*)\Avg. Network Send Latency
\Storage Replication Statistics(*)\Replication State
\Storage Replication Statistics(*)\Avg. Network Receive Latency
\Storage Replication Statistics(*)\Last Recovery Elapsed Time
\Storage Replication Statistics(*)\Number of Flushed Recovery Transactions
\Storage Replication Statistics(*)\Number of Recovery Transactions
\Storage Replication Statistics(*)\Number of Flushed Replication Transactions
\Storage Replication Statistics(*)\Number of Replication Transactions
\Storage Replication Statistics(*)\Max. Log Sequence Number
\Storage Replication Statistics(*)\Number of Messages Received
\Storage Replication Statistics(*)\Number of Messages Sent
\Storage Replication Application I/O Statistics(*)\Number of Received App Write Irps
\Storage Replication Application I/O Statistics(*)\Avg. Number of Irps/IoContext
\Storage Replication Application I/O Statistics(*)\Avg. App Write Latency
\Storage Replication Application I/O Statistics(*)\Avg. App Read Latency

Стоит также добавить, что в Windows Server Preview настроить репликацию повторно на томах, где она была, а потом была отключена - нельзя.

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

Ну и в принципе - вот и все!

Базовая и простая настройка репликации томов в Windows Server выглядит таким вот образом!
Пробуйте и до новых встреч на IT-фронте.

С Уважением,

Человек-огонь
Георгий А. Гаджиев

Данные из удаленных офисов часто накапливаются и объединяются в центральном офисе. Аналогичным образом, можно реплицировать данные в удаленные офисы. Технология для этого называется „Репликация данных” и поддерживается продуктами Microinvest .

Основные положения

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

Виды репликации

Существует разделение репликаций по времени:

Синхронная репликация
Асинхронная репликация

Разделение репликаций по задачам:

Репликация Master-Slave
Репликация с равноправными серверами (Multi Master)

Синхронная репликация

Синхронная репликация проходит в реальном времени, информация мультиплицируется на всех серверах. Особенность синхронной репликации в том, что при потере связи между серверами никто не отражает изменения, цикл останавливается и процесс практически не может быть продолжен. Необходимо, чтобы все данные были на 100% одинаковык у всех серверов и клиентов. Этот режим не применяется в реальных торговых системах, т.к. зависим от связи.

Асинхронная репликация

Асинхронная репликация – это технология, при которой данные сохраняются в локальном сервере, который, со своей стороны, заботится об их передаче к следующему и передает только разницу. Это правильная технология для построения торговой системы, т.к. нет требований к бесперебойной связи, и данные передаются при первой возможности, но не обязательно в реальном времени.

Репликация Master-Slave

Репликация Master-Slave зависит от одного центрального Master сервера, который аккумулирует все данные и передает разницу к подчиненным Slave серверам. Таким образом, Master сервер всегда имеет актуальную копию данных, пока Slave серверы ждут изменений и подчиняются информации, отправленной от Master. Они актуализируют свои данные с опозданием. Преимущество этой технологии в простом выполнении, недостаток – записи всегда делаются в Master сервере, что требует постоянно связи с этим сервером. Если пропадет связь с центральным сервером, в системе не смогут выводиться новые операции, но можно будет делать справки. Эта технология реализована в MySQL сервере и часто используется в торговых системах. Обыкновенно, Master сервер стоит в центральном офисе фирмы.

Репликация с равноправными серверами

Репликация с равноправными серверами – прогрессивная технология, где каждый сервер является самостоятельным и, одновременно с этим, частью общей сети. При этой технологии так же существует центральный сервер, который управляет связью между остальными серверами. Преимущество технологии в полной независимости от связи в работе. Когда есть связь, данные передаются к центральному серверу. Подчиненные серверы передают только свою разницу и не загружают канал обмена данными. Когда не существует связи между серверами, данные аккумулируются локально для последующего объединения при восстановлении связи. Эта технология называется Transactional Merge и реализуется в MS SQL Server.

Репликация в Microinvest Склад Pro

Некоторые полезные ресурсы

Документация по всем продуктам;
Форум технической поддержки Microinvest , где Вы сможете быстро получить ответ на интересующий вопрос;
Примеры автоматизации ресторанов и торговли на базе Microinvest в России и странах СНГ;