Настройка репликации томов в Windows Server vNext. Репликация данных

Чем хорошо использование пространства имен 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.

(Продолжительность занятия 40 минут)

Все серверы WINS в объединенной сети можно настроить так, чтобы они всегда тиражирован (replicate) на другие серверы записи из своей базы данных. Это гарантирует, что имя, зарегистрированное на одном сервере WINS, будет продублировано на всех остальных. На этом занятии объясняется, каким образом база данных одного сервера WINS тиражируется на других серверах WINS.

Изучив материал этого занятия, Вы сможете:

^ объяснить, когда необходимо настроить сервер WINS в качестве передающего или принимающего партнера;

^ настроить сервер WINS для репликации базы данных.

Репликация базы данных происходит при любом ее изменении, в том числе при освобождении имени. Дублирование баз данных позволяет серверу WINS распознавать NetBIOS-имена узлов, зарегистрированных на других серверах WINS. Например, если узел из подсети 1, зарегистрированный на сервере WINS той же подсети, пытается взаимодействовать с узлом из подсети 2, зарегистрированным на другом сервере WINS, имя NetBIOS не будет разрешено до тех пор, пока оба сервера WINS не продублируют друг другу свои базы данных.

Чтобы обмениваться записями базы данных, каждый из серверов WINS должен быть настроен как передающий или принимающий партнер для хотя бы одного сервера WINS. Передающий партнер (push partner) - это сервер WINS, который при изменении записей в его базе данных посылает своим принимающим партнерам сообщения с уведомлениями. Когда принимающие партнеры сервера WINS отвечают на уведомления, сервер WINS посылает им копии новых записей (replicas) своей базы данных.

Принимающий партнер (pull partner) - это сервер WINS, который запрашивает копии элементов базы данных у своих передающих партнеров. Он запрашивает и получает версии записей более поздние, чем полученные во время последней репликации.

Примечание Серверы WINS тиражируют только обновленные записи своих баз данных. Целиком база данных при репликации не копируется.

Настройка передающего или принимающего сервера WINS

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

· сделайте сервер WINS передающим партнером, если серверы связаны высокоскоростными соединениями, поскольку передача происходит всегда при обновлении заданного числа записей;

· сделайте принимающими партнерами удаленные узлы, если они связаны низкоскоростными линиями, поскольку прием можно настроить так, чтобы он происходил через заданные промежутки времени;

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

· Предположим, в Сиднее и Сиэтле все серверы WINS всех узлов передают обновленные записи своих баз данных на один узел в своем городе.

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

Сидней Сиэтл

Примечание Настройка сервера WINS в качестве передающего или принимающего партнера осуществляется при помощи программы WINS Administration tool.

Настройка репликации базы данных

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

Вот четыре возможных условия начала репликации базы данных.

1. При запуске системы: с того момента, как настроены партнеры по репликации, при каждом запуске сервера WINS осуществляется автоматическое обновление базы данных. Сервер WINS можно настроить так, чтобы при каждом запуске он информировал приемники об изменениях в своей базе данных.

2. Через заданные промежутки времени, например через каждые пять часов.

3. Когда количество регистрации и изменений в базе данных WINS достигает заданного предела: сервер WINS информирует всех своих принимающих партнеров, и они запрашивают обновленные записи.

4. Принудительное начало репликации из диалогового окна WINS Manager Replication Partners.

Упражнения

В этих заданиях Вы настроите сервер WINS для репликации базы данных с другим сервером WINS.

Примечание Для того чтобы выполнить эти задания, сначала настройте второй компьютер (Server2) как сервер WINS. Для этого выполните задание по установке службы WINS Server,

> Настройка партнеров по репликации

В этом задании Вы настроите второй компьютер (сервер WINS) как партнера по репликации.

1. В окне WINS Manager выберите меню Server, а потом щелкните Replication Partners. Появится диалоговое окно Replication Partners.

2. Щелкните Add. Вы увидите диалоговое окно Add WINS Server.

3. В строке WINS Server введите 131.107.2.200. а затем щелкните ОК.Появится диалоговое окно Replication Partners, в котором введенный IP-адрес добавлен к списку серверов WINS.

Внимание! На этом компьютере Вы должны указать основной сервер WINS в качестве партнера по репликации.

4. В списке WINS Server щелкните Ваш IP-адрес.

5. В группе Replication Options щелкните кнопку Configure, расположенную рядом с Pull Partner.

Вы увидите диалоговое окно Pull Partner Properties.

Установленный интервал репликации - 30 минут.

Примечание Для передающего партнера в строке Update Count задайте число обновлений записей базы данных, по достижении которого сервер WINS уведомит принимающих партнеров. Конкретное значение зависит от количества регистрации, поддерживаемых сервером. Сервер WINS, который получает сотни запросов о регистрации при подключении пользователей к сети, должен быть настроен для репликации большого числа обновлений.

Также Вы можете установить флажок Push with Propagation. Это заставит выбранные серверы WINS запрашивать все новые записи базы данных у сервера WINS, пославшего это сообщение. То есть, когда выбранный сервер получит какие-либо новые записи, он в свою очередь объявит о появлении изменений всем своим принимающим партнерам. Если выбранный сервер WINS не получает ни одной новой записи, он не распространяет сообщение об изменениях.

6. Щелкните ОК.

> Принудительная репликация

В этом задании Вы заставите WINS тиражировать базу данных на другой сервер WINS.

1. В диалоговом окне Replication Partners щелкните Replicate Now.

Появится сообщение WINS Manager о получении запроса репликации.

2. Щелкните ОК.

3. Щелкните ОК, чтобы вернуться в окно WINS Manager.Вы увидите окно WINS Manager, где Ваш IP-адрес указан как WINS-сервер.

4. В списке WINS Server выберите локальный сервер WINS.

5. В меню Mappings щелкните Show Database. Появится окно Show Database. Убедитесь, что в список Select Owner добавлены имена всех серверов, известных партнеру по репликации.

Примечание Если номер версии (version ID) тиражируемой базы данных равен О, повторите пункты 1-3, чтобы произвести репликацию снова.

6. В списке Select Owner выберите Ваш IP-адрес.В списке Mappings Вы увидите список имен зарегистрированных на сервере WINS.

7. Просмотрите информацию в базах данных других серверов, а затем щелкните Close, чтобы вернуться в WINS Manager,

Автоматические партнеры репликации WINS

Если Ваша сеть поддерживает групповую адресацию, сервер WINS можно настроить на автоматический поиск других серверов WINS в сети путем регулярной посылки групповых сообщений на IP-адрес 224.0.1.24. Тогда любой найденный в сети сервер WINS будет автоматически настроен как принимающий и передающий партнер репликации, а интервал репликации приема (pull replication) будет установлен равным двум часам. В этом случае, при нормальном выключении одного из компьютеров, он исключается из списка партнеров. Если сетевые маршрутизаторы не поддерживают групповую адресацию, то данный сервер WINS сможет обнаружить только серверы WINS той же подсети.

По умолчанию автоматическое взаимодействие между серверами WINS отключено. Для ручного отключения этой функции используйте редактор реестра, чтобы установить значение параметра UseSelfFndPnrs равным 0, а значение Mcastlntvl - достаточно большим*.

Резюме

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

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-фронте.

С Уважением,

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

Репликация — одна из техник масштабирования баз данных. Состоит эта техника в том, что данные с одного сервера базы данных постоянно копируются (реплицируются) на один или несколько других (называемые репликами). Для приложения появляется возможность использовать не один сервер для обработки всех запросов, а несколько. Таким образом появляется возможность распределить нагрузку с одного сервера на несколько.

Существует два основных подхода при работе с репликацией данных:

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

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

В этом подходе выделяется один основной сервер базы данных, который называется Мастером. На нем происходят все изменения в данных (любые запросы MySQL INSERT/UPDATE/DELETE). Слейв сервер постоянно копирует все изменения с Мастера. С приложения на Слейв сервер отправляются запросы чтения данных (запросы SELECT). Таким образом Мастер сервер отвечает за изменения данных, а Слейв за чтение.

В приложении нужно использовать два соединения — одно для Мастера, второе — для Слейва:

$master = mysql_connect("10.10.0.1", "root", "pwd"); $slave = mysql_connect("10.10.0.2", "root", "pwd"); # ... mysql_query("INSERT INTO users ...", $master ); # ... $q = mysql_query("SELECT * FROM photos ...", $slave );

# Используем два соединения — для Мастера и Слейва — для записи и чтения соответственно

Несколько Слейвов

Преимущество этого типа репликации в том, что Вы можете использовать более одного Слейва. Обычно следует использовать не более 20 Слейв серверов при работе с одним Мастером.

Тогда из приложения Вы выбираете случайным образом один из Слейвов для обработки запросов:

$slaves = [ "10.10.0.2", "10.10.0.3", "10.10.0.4", ]; $slave = mysql_connect($slaves , "root", "pwd"); # ... mysql_query("INSERT INTO users ...", $master); # ... $q = mysql_query("SELECT * FROM photos ...", $slave);

Задержка репликации

Асинхронность репликации означает, что данные на Слейве могут появится с небольшой задержкой. Поэтому, в последовательных операциях необходимо использовать чтение с Мастера, чтобы получить актуальные данные:

id = 7 ", $master ); $q = mysql_query("SELECT * FROM users WHERE id = 7 ", $master ); # ... $q = mysql_query("SELECT * FROM photos ...", $slave);

# При обращении к изменяемым данным, необходимо использовать Мастер-соединение

Выход из строя

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

Если выходит из строя Мастер, нужно переключить все операции (и чтения и записи) на Слейв. Таким образом он станет новым Мастером. После восстановления старого Мастера, настроить на нем реплику, и он станет новым Слейвом.

Резервирование

Намного чаще репликацию Master-Slave используют не для масштабирования, а для резервирования. В этом случае, Мастер сервер обрабатывает все запросы от приложения. Слейв сервер работает в пассивном режиме. Но в случае выхода из строя Мастера, все операции переключаются на Слейв.

Master-Master репликация

В этой схеме, любой из серверов может использоваться как для чтения так и для записи:

При использовании такого типа репликации достаточно выбирать случайное соединение из доступных Мастеров:

$masters = [ "10.10.0.1", "10.10.0.2", "10.10.0.3", ]; $master = mysql_connect($masters , "root", "pwd"); # ... mysql_query("INSERT INTO users ...", $master);

# Выбор случайного Мастера для обработки соединений

Выход из строя

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

Используйте Master-Master репликацию только в крайнем случае. Вместо нее лучше пользоваться техникой "ручной" репликации, описанной ниже.

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

В MySQL репликация работает в асинхронном режиме. Это значит, что приложение не знает, как быстро данные появятся на Слейве.

Задержка в репликации (replication lag) может быть как очень маленькой, так и очень большой. Обычно рост задержки говорит о том, что сервера не справляются с текущей нагрузкой и их необходимо масштабировать дальше, например техниками