Репликация на уровне хранилища в Windows Server 2016 - Storage Replica Дата публикации: 24.03.2017 Цель данной статьи - рассказать о новой компоненте 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, произойдет запись данных с тома журнала в том данных на обоих серверах.
Рассмотрим процесс асинхронной репликации более детально. Первый шаг - поступление данных на сервер-источник. Второй шаг - запись в журнал на отдельном томе. На третьем - оповещение приложения, что данные обработаны. Четвертый шаг - передача информации на целевой сервер. Пятый шаг - запись в журнал на целевом сервере. Шестой шаг - информирование сервера-источника об успешной записи в журнал.
Закончим теорию и начнем переходить к практике. Начнем с требований. Редакция 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"
Проверим доступность сервера:
Включим фичу с помощью PowerShell команды и перезагрузим хосты.
Теперь включим репликацию, используя PowerShell , мастер доступен только в версии для failover cluster. Результат работы команды мы видим ниже.
Хотелось бы обратить внимание, что после включения репликации на томе появляется дополнительный раздел, а также новый журнал событий, в котором содержится информация о репликации.
На данном графике видно, как происходит начальная инициализация после включения репликации. Обратите внимание на набор счетчиков производительности, которые связаны с репликацией.
Для примера скопируем данные на реплицируемый том и сразу увидим сетевой трафик.
Несмотря на то, что том с лог-файлом частично заполнен, данных там не видно. Используем команду dir с расширениями.
Как мы говорили ранее, на втором сервере диск с данными недоступен. Он в формате RAW и будет доступен после отключения или переключения репликации.
Если возникает необходимость разобрать репликацию, помним о дополнительном разделе на дисках на двух серверах и удаляем их. Запускаем DISKPART, выбираем наш диск (х, например)
На этом мы закончим краткий обзор данной технологии, которая появилась в Windows Server vNext. Ресурсы
Автор статьи: Михаил Комаров, MVP - Cloud and Datacenter Management Данный материал написан участником сообщества. В статье представлено мнение автора, которое может не совпадать с мнением корпорации Microsoft. Microsoft не несет ответственности за проблемы в работе аппаратного или программного обеспечения, которые могли возникнуть после использования материалов данной статьи. |
Технические центры
Форумы
|