Storage Replica в Windows Server 2016

Автор статьи — Михаил Комаров, MVP по направлению Hyper-V

Цель данной статьи — рассказать о новой компоненте Storage Replica, которая появилась в Windows Server vNext. Появление данной технологии было ожидаемо, так как последние несколько лет Microsoft уделяет пристальное внимание системам хранения. Первой ласточкой была новая реализация протокола SMB 3.0, которая появилась с выходом Windows Server 2012 и доработана новыми возможностями к выходу Windows Server 2012 R2.



Далее в нашу копилку добавим новый тип файлового кластера, так называемый SOFS



Упомянем также такие приятные вещи как встроенный тиминг, поддержку RDMA, InfiniBand-адаптеров, Storage Space для объединения дисков пул, Storage Tiering, который позволяет эффективно использовать комбинацию SDD и HDD пулов. Уже есть решения дисковых JBOD-полок, которые можно подключать напрямую к серверам и делать системы хранения. Есть промышленные решения Dell CPS, в которых использованы данные технологии.



После всего этого можно было ожидать репликацию томов, как в других системах хранения, и с выходом Windows Server vNext TP это было реализовано.

Storage Replica — это технология репликации томов в Windows на уровне блоков с использованием протокола SMB. На данный момент реализованы два сценария репликации томов: эластичный кластер и репликация между простыми серверами.





Управление реализовано следующим образом: из оснастки Failover Cluster Manager для эластичного кластера, а также Windows PowerShell и WMI. Обратите внимание, что поддерживаются только несъемные диски. Хотелось бы подчеркнуть, что Storage Replica — это не DFSR, и что репликация идет на уровне блоков. Ниже на иллюстрации видно, что механизм реализации Storage Replica находится ниже файловой системы, поэтому блочная репликация не зависит от типа файловой системы NTFS/CSVFS/ReFS.



Рассмотрим процесс синхронной репликации более детально. Первый шаг — поступление данных на сервер-источник. Второй шаг — запись в журнал на отдельном томе и пересылка на целевой сервер. На третьем шаге — запись в журнал на целевом сервере. Четвертый шаг — передача информации на сервер-источник об успешной записи в журнал на целевом сервере. Пятый шаг- оповещение приложения, что данные обработаны. Далее, в момент времени t1, произойдет запись данных с тома журнала в том данных на обоих серверах.



Рассмотрим процесс асинхронной репликации более детально. Первый шаг — поступление данных на сервер-источник. Второй шаг — запись в журнал на отдельном томе. На третьем — оповещение приложения, что данные обработаны. Четвертый шаг — передача информации на целевой сервер. Пятый шаг — запись в журнал на целевом сервере. Шестой шаг — информирование сервера-источника об успешной записи в журнал. Далее, в момент времени t1, произойдет запись данных с тома журнала в том данных на обоих серверах.



Закончим теорию и начнем переходить к практике.

Начнем с требований.

Редакция Windows Server – Datacenter Edition. Оба компьютера должны быть членами домена. Диски обязательно GPT, не MBR. Никаких съемных носителей — внешних USB-массивов, флешек, ленточных накопителей, 5,25-дюймовых флоппи-дисков и т. п. Также необходима та же геометрия диска (между журналами, между данными) и разделы для данных. Свободное место для журналов на томе Windows NTFS/ReFS (журнал фиксированного размера, он не увеличивается и не уменьшается). Никакой репликации %SystemRoot%, файлов подкачки, файлов спящего режима, файлов DMP. Также необходимо открыть на брандмауэре порты SMB, WS-MAN.

Задержки обмена пакетами

В среднем ≤ 5 мс в обе стороны. Если взять идеальный вариант — скорость света в вакууме, то 5 мс — это примерно 1 500 км при обмене в обе стороны. В реальности оптоволокно снижает скорость примерно на 35 %, а есть еще и коммутаторы, маршрутизаторы, брандмауэры и т. д. В сухом остатке: большинство клиентов ограничиваются расстоянием 30–50 км.

Пропускная способность сети

Начальное требование — сеть ≥ 1 Гбит/с — при соединении «узел-узел» между серверами (для Windows Server нужны сетевые карты 1 Гбит/с). Все зависит от операций ввода-вывода и интенсивности совместного использования канала (возможно, SR – не единственная функция, которая будет генерировать трафик на площадку аварийного восстановления). Определите количество операций ввода- вывода (125 Мб/с объема операций ввода-вывода = ~1 Гбит/с нагрузки на сеть).

Производительность и размер тома журнала

Флеш-накопители (SSD, NVME и т. д.). Журналы большего размера позволяют быстрее восстановить систему после крупного сбоя и быстрее переключиться. Но цена этому — место на диске.

Существует командлет Test-SRTopology, который проверяет требования и рекомендации по пропускной способности сети, размеру журналов, количеству операций ввода-вывода в секунду и т. д. Работает в течение указанного времени и создает аккуратный отчет с рекомендациями в формате HTML.

Необходимо обратить внимание, что целевой том всегда отключен. Сценарий для целевого тома с возможностью записи-чтения или только чтения не используется. Подключение только «один к одному». Всегда можно использовать другие функции репликации (например, Hyper-V Replica для A-B, а SR для A-C). При изменении размера тома репликация прерывается.

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

Enable-NetFirewallRule -CimSession SR1,SR2 -DisplayGroup "Remote Desktop","File and Printer Sharing"

Результат ее работы приведен ниже. Можно сделать это из консоли.



Проверим доступность сервера:

ping SR2.contoso.com -4 -f -l 1472 -n 300

На следующем шаге подключим по 2 диска на каждый сервер и при инициализации выберем GPT раздел. Далее отформатируем в NTFS и присвоим литеры дискам. Для демонстрации я использовал динамические диски. И диск под журнал ограничил 15GB.



Включим фичу с помощью PowerShell команды и перезагрузим хосты.

$Servers = {список серверов}
$Servers | ForEach { Install-WindowsFeature –ComputerName $_ –Name WVR –IncludeManagementTools -restart }

Или используя графический интерфейс



Теперь включим репликацию, используя PowerShell, мастер доступен только в версии для failover cluster.

 
New-SRPartnership -SourceComputerName SR1 -SourceRGName rg01 -SourceVolumeName Q: -SourceLogVolumeName T: -DestinationComputerName SR2 -DestinationRGName rg02 -DestinationVolumeName Q: -DestinationLogVolumeName T: -LogSizeInBytes 8gb

Данная команда включает репликацию на серверах SR1,SR2. Определяет тома репликации Q, на которых буду лежать данные, а также задает тома для журналов T и задает размер журнала 8 GB.
Результат работы команды мы видим ниже.



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







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



Для примера скопируем данные на реплицируемый том и сразу увидим сетевой трафик.



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



Как мы говорили ранее, на втором сервере диск с данными недоступен. Он в формате RAW и будет доступен после отключения или переключения репликации.



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

Запускаем DISKPART, выбираем наш диск (х, например)

DISKPART
LIST DISK
SELECT DISK X
attribute disk clear readonly

Находим раздел (Y “unknown” размером 512KB)

LIST PARTITION
SELECT PARTITION Y

Проверяем раздел ( GUID 558d43c5-a1ac-43c0-aac8-d1472b2923d1)

DETAIL PARTITION

Удаляем раздел

DELETE PART OVERRIDE

На этом мы закончим краткий обзор данной технологии, которая появилась в Windows Server vNext.

Ресурсы
Storage Replica in Windows Server Technical Preview