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

По выполняемым функциям DNS-серверы делятся на несколько групп; сервер определённой конфигурации может относиться сразу к нескольким типам:

Мастер, или первичный сервер (в терминологии BIND) - имеет право на внесение изменений в данные зоны.
Слейв, или вторичный сервер, не имеющий права на внесение изменений в данные зоны и получающий сообщения об изменениях от мастер-сервера.

Кэширующий DNS-сервер - обслуживает запросы клиентов (получает рекурсивный запрос, выполняет его с помощью нерекурсивных запросов к авторитативным серверам или передаёт рекурсивный запрос вышестоящему DNS-серверу).

Локальный DNS-сервер - используется для обслуживания DNS-клиентов, исполняющихся на локальной машине.

Перенаправляющий DNS-сервер - перенаправляет полученные рекурсивные запросы вышестоящему кэширующему серверу в виде рекурсивных запросов.

Корневой DNS-сервер- сервер, являющийся авторитативным за корневую зону.

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

Типы зон Все DNS-зоны можно разделить на зоны прямого и обратного просмотра. Кроме того, каждая из них может быть:

основной;

дополнительной (резервная копия основной);

интегрированной в Active Directory (специальный тип зоны, рекомендованный для обслуживания доменов Windows 2000).

1. Зоны прямого просмотра служат для преобразования доменных имен в IP-адреса. 2. Зоны обратного просмотра позволяют генерировать обратные запросы на поиск имени по IP-адресу. 3. Основная зона - стандартный тип зоны. Основные зоны хранятся в виде простого текстового файла, полностью совместимого с BIND. Это позволяет легко переносить данные зоны с одного сервера на другой и вручную редактировать файлы зон.4. Дополнительная зона - резервная копия существующей зоны. 5. Зона, интегрированная в Active Directory . Данные интегрированной зоны хранятся в Active Directory (AD), что обеспечивает максимальной уровень надежности Active Directory и DNS.

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

5. Последовательность действий по конфигурированию dns-сервера. Типы ресурсных записей.

Последовательность действий по конфигурированию:

Инсталляция DNS сервера

Начальное конфигурирование DNS сервера

После установки сервера необходимо указать некоторые параметры для работы сервера. Это делается путем редактирования определенных директив в файле опций. В файле прописываются директивы.

Запуск DNS сервера

После редактирования этого файла необходимо рестартовать сервер.

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

Ресурсные записи - единицы хранения и передачи информации в DNS.

Наиболее важные типы DNS-записей:

Запись A связывает имя хоста с адресом протокола IPv4.

Запись AAAA связывает имя хоста с адресом протоколаIPv6.

Запись CNAME используется для перенаправления на другое имя.

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

Запись NS указывает наDNS-сервердля данного домена.

Запись PTR связывает IP-адрес хоста с его каноническим именем.

Запись SOA указывает на каком сервере хранится эталонная информация о данном домене.

SRV-записьуказывает на серверы для сервисов, используется, в частности, дляJabberиActive Directory.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

С Уважением,

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