Обзор компонента Storage Replica в Windows Sever 2016 - Часть 1.

Если обратить внимание на то, что компания Microsft делала последнии годы в области развития систем хранения данных, то появление технологии SR было ожидаемо. Анонс протокола SMB 3.0 в Windows Sever 2012 уже намекал на то, что компания не собирается оставлять разработки в такой перспективной области, и мы будем наблюдать развитие этого направления в новых релизах серверной ОС.

В основе данной технологии лежит репликации томов на уровне блоков, работает на версии протокола SMB v3.1.1, и применяется практически к любым конфигурациям систем хранения данных. Компонент Storage Replica может управляться из Failover Cluster Manager (FCM), PowerShell, Windows Management Instrumentation (WMI), and Azure Site Recovery. Поддерживается два сценария репликации томов: эластичный кластер и репликация между простыми серверами.

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

Синхронная репликация.

Если мы взглянем на схему, приведенную выше, то процесс репликации начинается с поступления данных на сервер источник (от любого приложения). Вторым шагом - происходит запись в журнал на отдельном томе и пересылка на целевой сервер. Третьим шагом - будет запись в журнал на целевом сервере. Четвертый шаг - оповещение источника об успешной записи в журнал на целевом сервере. Пятый шаг - оповещение приложения что данные успешно обработаны. Далее происходит запись данных с тома журнала в том данных на обоих серверах.

Асинхронная репликация.

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

Если кто не заметил разницы, то поясню. В первом случае необходимо оповещение сервера источника об успешной записи в журнал целевым сервером, и только после этого произойдет оповещение приложения о том, что данные обработаны. Во-втором случае этого не требуется. Как вы понимаете в первом случае ужесточаются требования к сети передачи данных. Так как задержки сети могут существенно сказываться на работу приложений. Для такого режима рекомендуется использовать RDMA.

Требования:

1. Windows Server 2016 - Datacenter Edition "туда-обратно".
2. Серверы обязательно должны быть членами домена.
3. На обоих серверах должен быть определен том под журналы данных.
4. Тома должны иметь разметку GPT, и иметь одинаковый размер.
5. Объем данных не должен превышать 10 Tb.
6. Никаких съемных носителей.

Приступаем к настройке SR на серверах.

Для тестирования будем использовать два (srv1,srv2) Windows Server 2016 Datacenter включенных в домен "Home.loc".

1. Устанавливаем необходимые компоненты:

"srv1", "srv2" | %{ Install-WindowsFeature -ComputerName $_ -Name Storage-Replica, FS-FileServer -Restart –IncludeManagementTools }

2. Включаем репликацию на серверах.

New-SRPartnership -SourceComputerName SRV1 -SourceRGName Node01 -SourceVolumeName E: -SourceLogVolumeName F: -DestinationComputerName SRV2 -DestinationRGName Node02 -DestinationVolumeName E: -DestinationLogVolumeName F: -LogSizeInBytes 9Gb

Этой командой мы определяем том с данными, том для журналов, и ограничиваем размер журнала 9Gb.

Далее попробуем посмотреть статистику по счетчикам производительности. Откройте perfmon, выберите счетчики производительности относящиеся к Storage Replica. Создаем файл в томе для данных на исходном сервере :

fsutil file createnew e:\test.txt 104857600

Стоит также отметить что диск с данными на целевом сервере будет не доступен до момента пока вы не удалите репликацию между партнерами.

Для Storage Replica имеется отдельный журнал событий в который не забываем заглядывать для более подробного анализа и выявления ошибок.

На этом всё. До новый встреч.