Автор статьи — Михаил Комаров, 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
This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.
Комментариев нет:
Отправить комментарий