что такое репликация сервера

Репликация данных

Материал из Info

Содержание

Объединение данных с нескольких узлов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Microinvest Склад Pro поддерживает работу в режиме репликации, тем самым обеспечивает объединение данных без необходимости в дополнительной поддержке или внешних модулей. Рассчитывает на технологию, помещенную в ядро сервера, что позволяет пользоваться всеми преимуществами при работе. Сама программа даже не подозревает о существовании репликации данных.

Ссылки

Объединение данных с нескольких узлов (сервер) [1]
Обмен данными с мобильными пользователями [2]

Источник

Основы репликации в MySQL

Небольшое введение

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

Настройки мастера

Обязательно укажем уникальный ID сервера, путь для бинарных логов и имя БД для репликации в секции [mysqld]:
= 1
log-bin = /var/lib/mysql/mysql-bin
replicate-do-db = testdb
Убедитесь, что у вас достаточно места на диске для бинарных логов.

Добавим пользователя replication, под правами которого будет производится репликация. Будет достаточно привилегии «replication slave «:
mysql@master> GRANT replication slave ON «testdb».* TO «replication»@»192.168.1.102» IDENTIFIED BY «password»;

Перезагрузим MySQL, чтобы изменения в конфиге вступили в силу:
root@master# service mysqld restart

Если все прошло успешно, команда «show master status » должна показать примерно следующее:
mysql@master> SHOW MASTER STATUS\G
File: mysql-bin.000003
Position: 98
Binlog_Do_DB:
Binlog_Ignore_DB:
Значение position должно увеличиваться по мере того, как вносятся изменения в БД на мастере.

Настройки реплики

Укажем ID сервера, имя БД для репликации и путь к relay-бинлогам в секции [mysqld] конфига, затем перезагрузим MySQL:
= 2
relay-log = /var/lib/mysql/mysql-relay-bin
relay-log-index = /var/lib/mysql/mysql-relay-bin.index
replicate-do-db = testdb

root@replica# service mysqld restart

Переносим данные

Здесь нам придется заблокировать БД для записи. Для этого можно либо остановить работу приложений, либо воспользоваться установкой флажка read_only на мастере (внимание: на пользователей с привилегией SUPER этот флаг не действует). Если у нас есть таблицы MyISAM, сделаем также «flush tables»:
mysql@master> FLUSH TABLES WITH READ LOCK;
mysql@master> SET GLOBAL read_only = ON;

Посмотрим состояние мастера командой «show master status» и запомним значения File и Position (после успешной блокировки мастера они не должны изменятся):
File: mysql-bin.000003
Position: 98

Делаем дамп БД, и после завершения операции снимаем блокировку мастера:
mysql@master> SET GLOBAL read_only = OFF;

Переносим дамп на реплику и восстанавливаем из него данные.
Наконец, запускаем репликацию командами «change master to» и «start slave» и посмотрим, все ли прошло хорошо:
mysql@replica> CHANGE MASTER TO MASTER_HOST = «192.168.1.101 «, MASTER_USER = «replication «, MASTER_PASSWORD = «password «, MASTER_LOG_FILE = «mysql-bin.000003 «, MASTER_LOG_POS = 98;
mysql@replica> start slave;
Значения MASTER_LOG_FILE и MASTER_LOG_POS мы берем с мастера.

Посмотрим, как идет репликация командой «show slave status «:
mysql@replica> SHOW SLAVE STATUS\G
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.1.101
Master_User: replication
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000003
Read_Master_Log_Pos: 98
Relay_Log_File: mysql-relay-bin.001152
Relay_Log_Pos: 235
Relay_Master_Log_File: mysql-bin.000003
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB: testdb,testdb
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 98
Relay_Log_Space: 235
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 5

Наиболее интересные сейчас значения я выделил. При успешном начале репликации их значения должны быть примерно такими, как в листинге (см. описание команды «show slave status » в документации). Значение Seconds_Behind_Master может быть любым целым числом.
Если репликация идет нормально, реплика будет следовать за мастером (номер лога в Master_Log_File и позиция Exec_Master_Log_Pos будут расти). Время отставания реплики от мастера (Seconds_Behind_Master), в идеале, должно быть равно нулю. Если оно не сокращается или растет, возможно, что нагрузка на реплику слишком высока — она просто не успевает повторять изменения, происходящие на мастере.
Если же значение Slave_IO_State пусто, а Seconds_Behind_Master равно NULL, репликация не началась. Смотрите лог MySQL для выяснения причины, устраняйте её и заново запускайте репликацию:
mysql@replica> start slave;

Добавляем реплики

Пусть у нас уже есть работающие мастер и реплика, и нам нужно добавить к ним еще одну. Сделать это даже проще, чем добавить первую реплику к мастеру. И гораздо приятнее то, что нет необходимости останавливать для этого мастер.
Для начала настроим MySQL на второй реплике и убедимся, что мы внесли нужные параметры в конфиг:
= 3
replicate-do-db = testdb

Теперь остановим репликацию на первой реплике:
stop slave;

Реплика продолжит работать нормально, однако данные на ней уже не будут актуальными. Посмотрим статус и запомним позицию мастера, до которой реплика дошла перед остановкой репликации:
SHOW SLAVE STATUS\G

Нам нужные будет значения Master_Log_File и Exec_Master_Log_Pos:
Master_Log_File: mysql-bin.000004
Exec_Master_Log_Pos: 155

Создадим дамп БД и продолжим репликацию на первой реплике:
START SLAVE;

Восстановим данные из дампа на второй реплике. Затем включим репликацию:
CHANGE MASTER TO MASTER_HOST = «192.168.1.101 «, MASTER_USER = «replication «, MASTER_PASSWORD = «password «, MASTER_LOG_FILE = «mysql-bin.000004 «, MASTER_LOG_POS = 155;
START SLAVE;

Значения MASTER_LOG_FILE и MASTER_LOG_POS — это соответственно значения Master_Log_File и Exec_Master_Log_Pos из результата команды «show slave status » на первой реплике.
Репликация должна начаться с той позиции, на которой была остановлена первая реплика (и соответственно, создан дамп). Таким образом, у нас будет две реплики с идентичными данными.

Объединяем реплики

Иногда возникает такая ситуация: на мастере существует две БД, одна из которых реплицируется на одной реплике, а вторая — на другой. Как настроить репликацию двух БД на обеих репликах, не делая их дампы на мастере и не выключая его из работы? Достаточно просто, с использованием команды «start slave until «.
Итак, у нас имеется master с базами данных testdb1 и testdb2, которые реплицируются соответственно на репликах Настроим репликацию обеих БД на replica-1 без остановки мастера.
Остановим репликацию на replica-2 командой и запомним позицию мастера:
STOP SLAVE;
SHOW SLAVE STATUS\G
Master_Log_File: mysql-bin.000015
Exec_Master_Log_Pos: 231

Создадим дамп БД testdb2 и возобновим репликацию (на этом манипуляции с replica-2 закончились). Дамп восстановим

Ситуация на replica-1 такая: БД testdb1 находится на одной позиции мастера и продолжает реплицироваться, БД testdb2 восстановлена из дампа с другой позиции. Синхронизируем их.

Остановим репликацию и запомним позицию мастера:
STOP SLAVE;
SHOW SLAVE STATUS\G
Master_Log_File: mysql-bin.000016
Exec_Master_Log_Pos: 501

Убедимся, что в конфиге на секции [mysqld] указано имя второй БД:
replicate-do-db = testdb2

Перезагрузим MySQL, чтобы изменения в конфиге вступили в силу. Кстати, можно было просто перезагрузить MySQL, не останавливая репликацию — из лога мы бы узнали, на какой позиции мастера репликация остановилась.

Теперь проведем репликацию с позиции, на которой была приостановлена позиции, на которой мы только что приостановили репликацию:
CHANGE MASTER TO MASTER_HOST = «192.168.1.101 «, MASTER_USER = «replication «, MASTER_PASSWORD = «password «, MASTER_LOG_FILE = «mysql-bin.000015 «, MASTER_LOG_POS = 231;
start slave until MASTER_LOG_FILE = «mysql-bin.000016 «, MASTER_LOG_POS = 501;

Репликация закончится, как только реплика дойдет до указанной позиции в секции until, после чего обе наши БД будут соответствовать одной и той же позиции мастера (на которой мы остановили репликацию Убедимся в этом:
SHOW SLAVE STATUS\G
START SLAVE;
Master_Log_File: mysql-bin.000016
Exec_Master_Log_Pos: 501

Добавим в конфиг на секции [mysqld] имена обеих БД:
replicate-do-db = testdb1
replicate-do-db = testdb2

Важно: каждая БД должна быть указана на отдельной строке.
Перезагрузим MySQL и продолжим репликацию:
CHANGE MASTER TO MASTER_HOST = «192.168.1.101 «, MASTER_USER = «replication «, MASTER_PASSWORD = «password «, MASTER_LOG_FILE = «mysql-bin.000016 «, MASTER_LOG_POS = 501;
После того, как replica-1 догонит мастер, содержание их БД будет идентично. Объединить БД на replica-2 можно или подобным образом, или сделав полный дамп

Рокировка мастера и реплики

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

Включим ведение бинарных логов (дополнительно к relay-бинлогам) в конфиге в секции [mysqld]:
log-bin = /var/lib/mysql/mysql-bin

И добавим пользователя для ведения репликации:
mysql@master> GRANT replication slave ON ’testdb’.* TO ’replication’@’192.168.1.101′ IDENTIFIED BY «password «;

Пассивный мастер ведет репликацию как и обычная реплика, но кроме этого создает бинарные логии — то есть, мы можем начать репликацию с него. Убедимся в этом командой «show master status «:
mysql@replica> SHOW MASTER STATUS\G
File: mysql-bin.000001
Position: 61
Binlog_Do_DB:
Binlog_Ignore_DB:

Теперь, чтобы перевести пассивный мастер в активный режим, необходимо остановить репликацию на нем и включить репликацию на бывшем активном мастере. Чтобы в момент переключения данные не были утеряны, активный мастер необходимо заблокировать на запись.
mysql@master> FLUSH TABLES WITH READ LOCK
mysql@master> SET GLOBAL read_only = ON;
mysql@replica> STOP SLAVE;
mysql@replica> SHOW MASTER STATUS;
File: mysql-bin.000001
Position: 61
mysql@master> CHANGE MASTER TO MASTER_HOST = «192.168.1.102 «, MASTER_USER = «replication «, MASTER_PASSWORD = «password «, MASTER_LOG_FILE = «mysql-bin.000001 «, MASTER_LOG_POS = 61;
mysql@master> start slave;
Все, так мы поменяли активный мастер. Можно снять с бывшего мастера блокировку.

Заключение

Источник

Репликация хранилища между серверами с помощью реплики хранилища

Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016

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

для управления репликой служба хранилища можно использовать центр администрирования Windows или PowerShell.

ниже приведено обзорное видео об использовании реплики служба хранилища в центре администрирования Windows.

Предварительные требования

В этом сценарии каждый сервер должен находиться на отдельном физическом или логическом узле. Для серверов нужно настроить обмен данными через сеть.

требования к центру администрирования Windows

для совместного использования служба хранилища реплики и центра администрирования Windows необходимо следующее:

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

Термины

В этом пошаговом руководстве в качестве примера используется следующая среда:

Два сервера с именами SR-SRV05 и SR SRV06.

Два логических расположения, которые представляют два разных центра обработки данных: Redmond и Bellevue.

Рис. 1. Межсерверная репликация

шаг 1. установка и настройка центра администрирования Windows на компьютере

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

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

Шаг 2. предоставление операционной системы, компонентов, ролей, хранилища и сети

установите Windows server на обоих узлах сервера с типом установки Windows Server (возможности рабочего стола).

Сведения об использовании виртуальной машины Azure, подключенной к сети через ExpressRoute, см. в статье Добавление виртуальной машины Azure, подключенной к сети через expressroute.

начиная с Windows центра администрирования версии 1910 можно автоматически настроить целевой сервер в Azure. при выборе этого варианта установите Windows server на исходном сервере, а затем перейдите к шагу 3: настройка репликации «сервер-сервер».

добавьте сведения о сети, присоедините серверы к тому же домену, что и ваш компьютер управления Windows 10 (если вы используете его), а затем перезапустите серверы.

С этого момента вход в систему всегда нужно выполнять от имени пользователя домена, входящего в группу встроенной учетной записи администратора на всех серверах. Не забывайте повысить полномочия командных строк PowerShell и CMD, запуская их через графический интерфейс на компьютере с ОС Windows 10.

Подключение первый набор дискового корпуса JBOD, цели iSCSI, сети SAN FC или локального дискового накопителя (DAS) на сервер в сайте Redmond.

Подключение второй набор хранилища на сервер в site бельвью.

По возможности установите на обоих узлах все последние версии встроенного ПО и драйверов, предоставляемых поставщиками для полок дисков и хранилищ, HBA, BIOS или UEFI, а также для сетевых адаптеров и набора микросхем материнской платы. Перезапустите узлы при необходимости.

Для настройки общих хранилищ и сетевого оборудования обратитесь к документации поставщика оборудования.

Убедитесь, что для параметров BIOS или UEFI настроена высокая производительность, например отключено C-состояние, установлена скорость QPI, включена архитектура NUMA и установлена максимально возможная частота памяти. убедитесь, что для параметра управление питанием в Windows Server задана высокая производительность. При необходимости перезагрузите компьютер.

Настройте роли следующим образом.

метод центра администрирования Windows

Метод диспетчер сервера

Запустите ServerManager.exe и создайте группу серверов, добавив все узлы сервера.

Установите роли и компоненты файлового сервера и реплики хранилища на всех узлах и перезапустите их.

метод Windows PowerShell

На компьютере SR-SRV06 или на компьютере удаленного управления выполните следующую команду в консоли Windows PowerShell. Она установит все необходимые компоненты и роли и перезапустит их.

Настройте хранилище следующим образом:

Полки дисков JBOD

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

Подготовьте хранилище с помощью дисковых пространств, выполнив шаги 1–3 из статьи Развертывание дисковых пространств на автономном сервере с помощью Windows PowerShell или диспетчера сервера.

Для хранилища iSCSI:

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

Подготовьте хранилище в соответствии с документацией поставщика. При использовании целей iSCSI для Windows изучите статью Блочное хранилище конечного сервера iSCSI, краткое руководство.

Для хранилища Fibre Channel в сети SAN:

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

Подготовьте хранилище в соответствии с документацией поставщика.

Для локального фиксированного дискового накопителя:

Убедитесь, что хранилище не содержит системный том, файл подкачки или файлы дампа.

Подготовьте хранилище в соответствии с документацией поставщика.

Запустите Windows PowerShell и используйте командлет Test-SRTopology, чтобы определить, все ли требования для реплики хранилища выполнены. Этот командлет можно запустить в режиме быстрой проверки требований или в режиме длительной оценки производительности.

Например, следующая команда проверит предложенное узлы на наличие томов F: и G:, а также запустит тест длительностью 30 минут:

рис. 2. отчет о топологии репликации служба хранилища

Шаг 3. Настройка репликации «сервер-сервер»

Использование Windows Admin Center

Добавьте исходный сервер.

На странице все подключения выберите исходный сервер.

выберите служба хранилища реплику на панели инструментов.

Выберите создать, чтобы создать новое партнерство. Чтобы создать виртуальную машину Azure, которая будет использоваться в качестве назначения для партнерства, выполните следующие действия.

в этом видео показано, как использовать реплику служба хранилища для миграции на виртуальные машины Azure.

Укажите сведения о партнерстве и нажмите кнопку создать (как показано на рис. 3).

Рис. 3. Создание новой связи

удаление партнерства из реплики служба хранилища в центре администрирования Windows не приводит к удалению имени группы репликации.

Использование Windows PowerShell

Теперь мы перейдем к настройке межсерверной репликации с помощью PowerShell. необходимо выполнить все приведенные ниже действия на узлах непосредственно или на удаленном компьютере управления, содержащем средства удаленного администрирования сервера Windows Server.

Не забывайте, что консоль Powershell должна иметь повышенные привилегии администратора.

Настройте межсерверную репликацию, указав исходный и конечный диски, журналы источника и назначения, узлы источника и назначения, а также размер журнала.

По умолчанию размер журнала составляет 8 ГБ. В зависимости от результатов Test-SRTopology командлета вы можете использовать параметр-логсизеинбитес с более высоким или меньшим значением.

Чтобы узнать состояние источника и назначения репликации, используйте Get-SRGroup и Get-SRPartnership :

Ход репликации можно отслеживать следующим образом.

На исходном сервере введите следующую команду и изучите события 5015, 5002, 5004, 1237, 5001 и 2200.

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

Вот пример выходных данных:

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

Кроме того, целевая группа серверов для реплики постоянно сообщает о числе оставшихся байтов для копирования, и эти сведения можно запрашивать через PowerShell. Например:

Пример контроля выполнения (не завершается самостоятельно):

На конечном сервере выполните следующую команду и проверьте события 5009, 1237, 5001, 5015, 5005 и 2200 для отслеживания хода обработки события. В этой последовательности не должно быть предупреждений или ошибок. Будет много событий 1237, которые указывают ход выполнения.

Шаг 4. Управление репликацией

Теперь можно приступить к управлению инфраструктурой межсерверной репликации и ее использованию. вы можете выполнить все приведенные ниже действия на узлах непосредственно или на удаленном компьютере управления, содержащем средства удаленного администрирования сервера Windows Server.

Для измерения производительности репликации выполните командлет Get-Counter на исходном и конечном узлах. Ниже перечислены имена счетчиков.

\Статистика ввода-вывода раздела реплики хранилища(*)\Количество раз приостановки записи на диск

\Статистика ввода-вывода раздела реплики хранилища(*)\Количество вводов-выводов записи на диск в ожидании

\Статистика ввода-вывода раздела реплики хранилища(*)\Количество запросов для последней записи в журнал

\Статистика ввода-вывода раздела реплики хранилища(*)\Средняя длина очереди записи на диск

\Статистика ввода-вывода раздела реплики хранилища(*)\Текущая длина очереди записи на диск

\Статистика ввода-вывода раздела реплики хранилища(*)\Количество запросов записи приложения

\Статистика ввода-вывода раздела реплики хранилища(*)\Среднее число запросов в операции записи в журнал

\Статистика ввода-вывода раздела реплики хранилища(*)\Средняя задержка записи приложения

\Статистика ввода-вывода раздела реплики хранилища(*)\Средняя задержка чтения приложения

\Статистика реплики хранилища(*)\Целевая RPO

\Статистика реплики хранилища(*)\Текущая RPO

\Статистика реплики хранилища(*)\Средняя длина очереди журнала

\Статистика реплики хранилища(*)\Длина очереди текущего журнала

\Статистика реплики хранилища(*)\Всего байт получено

\Статистика реплики хранилища(*)\Всего байт отправлено

\Статистика реплики хранилища(*)\Средняя время задержки исходящих данных в сети

\Статистика реплики хранилища(*)\Состояние репликации

\Статистика реплики хранилища(*)\Средняя задержка приема-передачи сообщения

\Статистика реплики хранилища(*)\Время, затраченное на последнее восстановление

\Статистика реплики хранилища(*)\Количество транзакций восстановления, записанных на диск

\Статистика реплики хранилища(*)\Количество транзакций восстановления

\Статистика реплики хранилища(*)\Количество транзакций репликации, записанных на диск

\Статистика реплики хранилища(*)\Количество транзакций репликации

\Статистика реплики хранилища(*)\Максимальный порядковый номер журнала

\Статистика реплики хранилища(*)\Количество полученных сообщений

\Статистика реплики хранилища(*)\Количество отправленных сообщений

Дополнительные сведения о счетчиках производительности, доступных в Windows PowerShell, см. в статье Get-Counter.

Windows Server предотвращает переключение ролей при выполнении начальной синхронизации, так как это может привести к потери данных при попытке переключения перед выполнением начальной репликации. Не принудительно переключайтейте направления, пока не завершится начальная синхронизация.

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

Замена репликации DFS на реплику хранилища

У многих клиентов корпорации Майкрософт репликация DFS развернута в качестве решения для аварийного восстановления таких неструктурированных пользовательских данных, как домашние папки и общие папки отделов. Репликация DFS входит в состав в Windows Server 2003 R2 и всех последующих выпусков операционных систем. Она хорошо показала себя в сетях с низкой пропускной способностью, благодаря чему является привлекательным решением для сред с высокой задержкой, малыми объемами изменений и большим числом узлов. Однако при использовании для репликации данных это решение имеет существенные ограничения:

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

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

установите Windows Server на двух серверах и настройте хранилище. Вы можете обновить существующий набор серверов или установить их заново.

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

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

Включите репликацию реплики хранилища и завершите начальную синхронизацию. Репликация может быть как синхронной, так и асинхронной. а. Синхронная репликация более предпочтительна, так как она обеспечивает согласованность данных ввода-вывода на конечном сервере. b. Мы настоятельно рекомендуем включить теневое копирование томов и периодически создавать моментальные снимки с помощью VSSADMIN или других удобных для вас средств. Это гарантирует согласованную запись файлов приложений на диск. В случае аварии вы сможете восстановить из моментальных снимков на целевом сервере те файлы, для которых асинхронная репликация была выполнена лишь частично. Моментальные снимки реплицируются вместе с остальными файлами.

Теперь можно просто работать в обычном режиме, пока не случится авария.

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

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

Добавьте сервер и его общие папки в качестве целевого объекта папки пространств имен DFS.

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

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

Добавление виртуальной машины Azure, подключенной к сети через ExpressRoute

Рис. 4. ресурсы, связанные с ExpressRoute — запишите имя виртуальной сети.

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

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

Создайте виртуальную машину Azure со следующими параметрами (показаны на рис. 5):

Источник