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
    • +11
    • 22.3k
    • 3
    Microsoft
    424.30
    Microsoft — мировой лидер в области ПО и ИТ-услуг
    Share post

    Similar posts

    Comments 3

      0
      Технология замечательная, давно присматриваемся для клиентов. Есть ли практические замеры, например в случае с репликацией снапшотов и лог-записей disk-based и in-memory баз данных? Понятно, что для SQL Server есть более специализированное решение по репликации и failover, но всё же Storage Replica как-то более commodity в этом плане, и является failover для целого приложения, а не только базы данных, что принципиально.
        0
        Я пока цифр не видел. Появятся — поделюсь.
        0
        Ждём 2016 сервер, очень ждём. Но в связи с открывшимися «фичами» по отсылке пользовательских данных из Windows 10, будем очень осторожно смотреть и тестировать будущую версию. Доверия Майкрософту как-то поубавилось.

        Only users with full accounts can post comments. Log in, please.