Репликация с сервера в хранилище сервера

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

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

Вот обзорное видео об использовании реплики хранилища в Windows Admin Center.

Необходимые компоненты

• лес служб домен Active Directory (не требуется запускать Windows Server 2016).
• Два сервера под управлением Windows Server 2019 или Windows Server 2016, Datacenter Edition. Если вы работаете под управлением Windows Server 2019, вместо этого можно использовать выпуск Standard если вы реплицируете только один том размером до 2 ТБ.
• Два набора хранилищ со следующими компонентами: SAS JBOD, SAN на основе протокола Fibre Channel, цели iSCSI и (или) локальные хранилища SCSI или SATA. Хранилище должно включать как жесткие диски, так и твердотельные накопители. Каждой набор хранилищ должен быть доступен только для одного из этих серверов (без возможности общего доступа).
• Каждый набор хранилищ должен допускать создание по меньшей мере двух виртуальных дисков: один для реплицируемых данных и один для журналов. На всех дисках данных в физическом хранилище необходимо использовать одинаковый размер секторов. На всех дисках с журналами в физическом хранилище необходимо использовать одинаковый размер секторов.
• На каждом сервере должно быть создано по меньшей мере одно подключение Ethernet/TCP для синхронной репликации, но желательно использовать RDMA.
• Правила всех задействованных брандмауэров и маршрутизаторов должны разрешать двунаправленный трафик ICMP, SMB (порт 445, а также 5445 для SMB Direct) и WS-MAN (порт 5985) между всеми узлами.
• Сеть между серверами должна иметь достаточную пропускную способность для ваших рабочих нагрузок ввода-вывода, а средняя задержка приема-передачи должна составлять 5 мс для синхронной репликации. Асинхронная репликация не имеет рекомендации по задержке.
  При репликации между локальными серверами и виртуальными машинами Azure необходимо создать сетевую связь между локальными серверами и виртуальными машинами Azure. Для этого используйте Express Route, подключение VPN-шлюза типа "сеть — сеть" или установите программное обеспечение VPN на виртуальных машинах Azure, чтобы подключить их к локальной сети.
• Реплицируемое хранилище не может находиться на диске с папкой операционной системы Windows.

Многие из этих требований можно определить с помощью командлета Test-SRTopology cmdlet. Это средство будет доступно, если установить реплику хранилища или средства управления репликой хранилища хотя бы на один сервер. Настраивать реплику хранилища не нужно. Для использования инструмента достаточно только установить командлет. Дополнительная информация приведена ниже.

Требования к Windows Admin Center

Чтобы совместно использовать реплику хранилища и Центр администрирования Windows, вам потребуется следующее:

Условия

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

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

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

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

Шаг 1. Установка и настройка Windows Admin Center на компьютере

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

1. Скачайте и установите Windows Admin Center.

2. Скачайте и установите средства удаленного администрирования сервера.

   • Если вы используете Windows 10 версии 1809 или более поздней, установите модуль реплики хранилища для Windows PowerShell по запросу.

3. Откройте сеанс PowerShell от имени администратора, нажав кнопку "Пуск", введя PowerShell правой кнопкой мыши и выбрав "Запуск от имени администратора".

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

   winrm quickconfig
   

5. Введите Y , чтобы включить службы WinRM и включить исключение брандмауэра WinRM.

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

1. Установите Windows Server на обоих узлах сервера с типом установки Windows Server (рабочий стол).

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

   Примечание.

   Начиная с Windows Admin Center версии 1910, вы можете настроить целевой сервер автоматически в Azure. Если выбрать этот параметр, установите Windows Server на исходном сервере и перейдите к шагу 3. Настройка репликации между серверами.

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

   Примечание.

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

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

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

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

   Примечание.

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

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

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

   • Метод Windows Admin Center

     1. В Windows Admin Center перейдите к диспетчер сервера, а затем выберите один из серверов.
     2. Перейдите к ролям и функциям.
     3. Выберите реплику хранилища компонентов>и нажмите кнопку "Установить".
     4. Повторите на другом сервере.

   • метод диспетчер сервера

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

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

   • Метод Windows PowerShell

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

     $Servers = 'SR-SRV05','SR-SRV06'
     
     $Servers | ForEach { Install-WindowsFeature -ComputerName $_ -Name Storage-Replica,FS-FileServer -IncludeManagementTools -restart }
     

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

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

   Внимание

   • Необходимо создать два тома на каждой полке: один для данных и один для журналов.
   • Диски журналов и данных следует инициализировать как GPT, а не MBR.
   • Два тома данных должны иметь одинаковый размер.
   • Два тома журналов должны иметь одинаковый размер.
   • Все реплицируемые диски данных должны иметь одинаковый размер сектора.
   • Все диски журналов должны иметь одинаковый размер сектора.
   • Тома журнала следует располагать на твердотельных накопителях. Корпорация Майкрософт рекомендует быстрее хранить журналы, чем хранилище данных. Тома журнала никогда не должны использоваться для других рабочих нагрузок.
   • В качестве дисков данных можно использовать жесткие диски, твердотельные накопители или их многоуровневое сочетание. Диски можно организовать как зеркальные массивы, массивы с контролем четности, RAID 1 или 10, RAID 5 или RAID 50.
   • Том журнала должен иметь размер по умолчанию не менее 9 ГБ, но может отличаться как в большую, так и в меньшую сторону в зависимости от требований к ведению журнала.
   • Роль файлового сервера необходима только для работы Test-SRTopology, так как она открывает порты брандмауэра, необходимые для тестирования.

   • Для корпусов JBOD:

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

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

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

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

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

   • Для хранилища SAN fc:

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

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

   • Для локального хранилища фиксированных дисков:

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

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

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

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

   MD c:\temp
   
   Test-SRTopology -SourceComputerName SR-SRV05 -SourceVolumeName f: -SourceLogVolumeName g: -DestinationComputerName SR-SRV06 -DestinationVolumeName f: -DestinationLogVolumeName g: -DurationInMinutes 30 -ResultPath c:\temp
   

   Внимание

   Если вы используете тестовый сервер, на котором во время проверки не выполняются операции ввода-вывода для выбранного тома источника, попробуйте добавить рабочую нагрузку, иначе отчет не будет содержать полезные сведения. Чтобы получить фактические результаты и рекомендованные размеры журнала, тестовая нагрузка должна соответствовать ожидаемой рабочей нагрузке. Как вариант, во время теста просто скопируйте некоторые файлы на исходный том или загрузите и запустите средство DISKSPD для создания операций ввода-вывода на запись. Этот пример команды создает низкую рабочую нагрузку операций записи на диск D: в течение десяти минут:

   Diskspd.exe -c1g -d600 -W5 -C5 -b8k -t2 -o2 -r -w5 -i100 -j100 d:\test

10. Изучите отчет TestSrTopologyReport.html, показанный на рис. 2, чтобы убедиться, что выполнены требования реплики хранилища.

    

    Рис. 2. Отчет топологии репликации хранилища

Шаг 3. Настройка репликации между серверами

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

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

   1. Нажмите кнопку Добавить.
   2. Выберите " Добавить подключение к серверу".
   3. Введите имя сервера и нажмите кнопку "Отправить".

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

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

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

   1. В разделе "Репликация с другим сервером " выберите "Использовать новую виртуальную машину Azure" и нажмите кнопку "Далее". Если этот параметр не отображается, убедитесь, что вы используете Windows Admin Center версии 1910 или более поздней версии.
   2. Укажите сведения о исходном сервере и имя группы репликации, а затем нажмите кнопку "Далее".
      
      Это начинает процесс, который автоматически выбирает виртуальную машину Azure Windows Server 2019 или Windows Server 2016 в качестве назначения для источника миграции. Служба миграции хранилища рекомендует размеры виртуальных машин соответствовать исходному источнику, но вы можете переопределить это, выбрав пункт "Просмотреть все размеры". Данные инвентаризации используются для автоматической настройки управляемых дисков и их файловых систем, а также присоединения новой виртуальной машины Azure к домену Active Directory.
   3. После создания виртуальной машины Azure в Windows Admin Center укажите имя группы репликации и нажмите кнопку "Создать". Затем Windows Admin Center начинает обычный процесс начальной синхронизации реплики хранилища, чтобы начать защиту данных.

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

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

   Рис. 3. Создание нового партнерства

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

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

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

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

   New-SRPartnership -SourceComputerName sr-srv05 -SourceRGName rg01 -SourceVolumeName f: -SourceLogVolumeName g: -DestinationComputerName sr-srv06 -DestinationRGName rg02 -DestinationVolumeName f: -DestinationLogVolumeName g: -LogType Raw
   

   Выходные данные:

   DestinationComputerName : SR-SRV06
   DestinationRGName       : rg02
   SourceComputerName      : SR-SRV05
   PSComputerName          :
   

   Внимание

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

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

   Get-SRGroup
   Get-SRPartnership
   (Get-SRGroup).replicas
   

   Выходные данные:

   CurrentLsn             : 0
   DataVolume             : F:\
   LastInSyncTime         :
   LastKnownPrimaryLsn    : 1
   LastOutOfSyncTime      :
   NumOfBytesRecovered    : 37731958784
   NumOfBytesRemaining    : 30851203072
   PartitionId            : c3999f10-dbc9-4a8e-8f9c-dd2ee6ef3e9f
   PartitionSize          : 68583161856
   ReplicationMode        : synchronous
   ReplicationStatus      : InitialBlockCopy
   PSComputerName         :
   

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

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

      Get-WinEvent -ProviderName Microsoft-Windows-StorageReplica -max 20
      

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

      Get-WinEvent -ProviderName Microsoft-Windows-StorageReplica | Where-Object {$_.ID -eq "1215"} | fl
      

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

      TimeCreated  : 4/8/2016 4:12:37 PM
      ProviderName : Microsoft-Windows-StorageReplica
      Id           : 1215
      Message      : Block copy completed for replica.
      
      ReplicationGroupName: rg02
      ReplicationGroupId: {616F1E00-5A68-4447-830F-B0B0EFBD359C}
      ReplicaName: f:\
      ReplicaId: {00000000-0000-0000-0000-000000000000}
      End LSN in bitmap:
      LogGeneration: {00000000-0000-0000-0000-000000000000}
      LogFileId: 0
      CLSFLsn: 0xFFFFFFFF
      Number of Bytes Recovered: 68583161856
      Elapsed Time (ms): 117
      

      Примечание.

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

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

      (Get-SRGroup).Replicas | Select-Object numofbytesremaining
      

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

      while($true) {
      
       $v = (Get-SRGroup -Name "RG02").replicas | Select-Object numofbytesremaining
       [System.Console]::Write("Number of bytes remaining: {0}`r", $v.numofbytesremaining)
       Start-Sleep -s 5
      }
      

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

      Get-WinEvent -ProviderName Microsoft-Windows-StorageReplica | FL
      

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

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

1. Используйте Get-SRPartnership и Get-SRGroup, чтобы узнать источник и назначение репликации и их текущее состояние.

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

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

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

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

   • \Статистика операций ввода-вывода секции реплики хранилища(*)\Avg. Длина очереди flush

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

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

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

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

   • \Статистика операций ввода-вывода секции реплики хранилища(*)\Avg. Задержка чтения приложения

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

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

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

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

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

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

   • \Статистика реплики хранилища(*)\Avg. Задержка отправки сети

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

   • \Статистика реплики хранилища(*)\Avg. Задержка кругового пути сообщения

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

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

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

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

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

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

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

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

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

3. Чтобы изменить направление репликации из одного расположения, используйте командлет Set-SRPartnership.

   Set-SRPartnership -NewSourceComputerName sr-srv06 -SourceRGName rg02 -DestinationComputerName sr-srv05 -DestinationRGName rg01
   

   Предупреждение

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

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

4. Чтобы удалить репликацию, выполните Get-SRGroup, Get-SRPartnership, Remove-SRGroup и Remove-SRPartnership на каждом узле. Командлет Remove-SRPartnership следует выполнять только на том узле, который сейчас является источником репликации, но не на целевом сервере. Выполните Remove-SRGroup на обоих серверах. Например, вот как можно удалить репликацию на двух серверах:

   Get-SRPartnership
   Get-SRPartnership | Remove-SRPartnership
   Get-SRGroup | Remove-SRGroup
   

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

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

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

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

• Оно поддерживает только репликацию "один к одному" между томами. Можно реплицировать различные тома между несколькими серверами.
• Хотя она поддерживает асинхронную репликацию, она не предназначена для низкой пропускной способности, сетей с высокой задержкой.
• Он не разрешает пользователю доступ к защищенным данным в целевом месте во время репликации

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

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

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

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

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

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

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

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

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

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

   Примечание.

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

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

1. Создайте ExpressRoute в портал Azure.
   После утверждения ExpressRoute в подписку добавляется группа ресурсов. Перейдите к группам ресурсов, чтобы просмотреть эту новую группу. Запишите имя виртуальной сети.

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

2. Создайте новую группу ресурсов.

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

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

   • Общедоступный IP-адрес: Нет
   • Виртуальная сеть: выберите виртуальную сеть, о ней, добавленной с помощью ExpressRoute.
   • Группа безопасности сети (брандмауэр) — выберите созданную ранее группу безопасности сети. Рис. 5. Создание виртуальной машины при выборе параметров сети ExpressRoute

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

См. также

• Обзор реплики хранилища
• Репликация растянутого кластера с помощью общего хранилища
• Репликация кластера в хранилище кластеров
• Реплика хранилища: известные проблемы
• Реплика хранилища: часто задаваемые вопросы
• Локальные дисковые пространства