(Продолжительность занятия 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-фронте.

С Уважением,

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

Данные из удаленных офисов часто накапливаются и объединяются в центральном офисе. Аналогичным образом, можно реплицировать данные в удаленные офисы. Технология для этого называется „Репликация данных” и поддерживается продуктами 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 в России и странах СНГ;