Всем доброго времени суток!
Сегодня я хотел бы рассказать Вам про очень интересную функцию, которая будет представлена в новой версии Windows Server vNEXT, и которая уже доступна для тестирования и испытаний в предварительной версии Technical Preview, а именно про репликацию на уровне тома. В WS vNEXT эта фича сейчас называется Storage Replica. Что это за зверь и с чем его есть — подробности под катом.
Репликация хранилища, Storage Replica (SR) — это новая функция в Windows Server, которая позволяет проводить блочную синхронную (а в некоторых случаях — и асинхронную) репликацию на уровне тома между кластерами или серверами Windows Server vNEXT. В качестве транспорта используется протокол SMB3.
На текущий момент поддерживаются варианты репликации «Сервер-Сервер» и «Эластичный Кластер» (Stretch Cluster). Репликация уровня «Кластер-Кластер» пока что не реализована, но присутствует в планах. Поскольку репликация происходит на блочном уровне, то механизму нет особого дела до типа оборудования на котором развернута файловая система. Репликация может быть как синхронная, так и асинхронная (пока что только в сценарии «Сервер-Сервер»). В качестве сетевого механизма коммуникации могут использоваться TCP/IP или RDMA. Поверх реплики могут применяться механизмы дедупликации данных и шифрования на базе BitLocker. Настраивается это чудесное катастрофо- и отказоустойчивое чудо технологий пока исключительно через PowerShell. Для осуществления процесса также необходимо иметь открытыми порты TCP 445 или TCP 5445, быть членами одного домена (объект воздействия с этой точки зрения — хост, и реплицируются тома между хостами, а также возможны сценарии репликации томов в рамках одного хоста). Также важно помнить, что репликация возможна только для томов данных, но не для системного тома — проще говоря, реплицировать «Диск С:» технически не получится, да и не для этой цели разрабатывалась эта технология. Эта технология призвана обеспечить нулевой уровень потери данных (в случае синхронной репликации) или близкой к нулю уровень потери данных (асинхронный сценарий).
Также хочу сразу отметить, что требования к каналу тут также присутствуют определенные: по крайней мере одно соединение 10 Гбит/сек на каждом файловом сервере. Для надежности неплохо было бы убедиться, что отправки нефрагментированного ICMP-пакета размером 1472 байта проходят успешно без потерь на протяжении 5-ти минутного интервала.
Также стоит отметить, что использовать для репликации как в качестве цели, так и в качестве источника, съемные носители а-ля USB-накопитель, нельзя. Права на уровне встроенной группы администраторов Вам также понадобятся.
В целях тестирования Вы можете опробовать все механизмы на ВМ — только помните, что виртуальные диски в таком сценарии должны быть фиксированного типа, а не динамически расширяемые.
Ну и после ознакомления с вводными по процессу настройки репликации томов, давайте же настроем репликацию «Сервер-Сервер». Только напомню Вам, что сервер в превью — и не стоит этот механизм применят для боевых данных сейчас.На каждом сервере-участнике должна быть установлена роль «File Server» и функция «Storage Replica» или «Windows Volume Replication» (в зависимости от билда сервера.
После этого на одном из серверов-участников исполните командлет PowerShell с админскими правами:
В моем примере участвуют два сервера: sr-srv05 и sr-srv06, выделен отдельный том под лог-файлы (он должен быть по размеру на один гигабайт меньше, нежели том репликации и томы-источники и томы-цели.
Для проверки успешности настройки репликации последовательно исполнина обоих серверах-участниках исполните следующий командлет:
Наличие событий 2200, 5005, 5015, 5001 и 5009 будет признаком успеха.
Если нужны более детальные данные по счетчикам (Get-Counter), то вот их список:
• \Storage Replication Statistics(*)\Total Bytes Received
• \Storage Replication Statistics(*)\Total Bytes Sent
• \Storage Replication Statistics(*)\Avg. Network Send Latency
• \Storage Replication Statistics(*)\Replication State
• \Storage Replication Statistics(*)\Avg. Network Receive Latency
• \Storage Replication Statistics(*)\Last Recovery Elapsed Time
• \Storage Replication Statistics(*)\Number of Flushed Recovery Transactions
• \Storage Replication Statistics(*)\Number of Recovery Transactions
• \Storage Replication Statistics(*)\Number of Flushed Replication Transactions
• \Storage Replication Statistics(*)\Number of Replication Transactions
• \Storage Replication Statistics(*)\Max. Log Sequence Number
• \Storage Replication Statistics(*)\Number of Messages Received
• \Storage Replication Statistics(*)\Number of Messages Sent
• \Storage Replication Application I/O Statistics(*)\Number of Received App Write Irps
• \Storage Replication Application I/O Statistics(*)\Avg. Number of Irps/IoContext
• \Storage Replication Application I/O Statistics(*)\Avg. App Write Latency
• \Storage Replication Application I/O Statistics(*)\Avg. App Read Latency
Стоит также добавить, что в Windows Server Preview настроить репликацию повторно на томах, где она была, а потом была отключена — нельзя.
Процессы отображения хода событий могут быть неточными и не отображать полной действительности — лучше смотреть по счетчикам.
Ну и в принципе — вот и все!
Базовая и простая настройка репликации томов в Windows Server выглядит таким вот образом!
Пробуйте и до новых встреч на IT-фронте.
С Уважением,
Человек-огонь
Георгий А. Гаджиев
Сегодня я хотел бы рассказать Вам про очень интересную функцию, которая будет представлена в новой версии Windows Server vNEXT, и которая уже доступна для тестирования и испытаний в предварительной версии Technical Preview, а именно про репликацию на уровне тома. В WS vNEXT эта фича сейчас называется Storage Replica. Что это за зверь и с чем его есть — подробности под катом.
Параметры и возможности репликации
Репликация хранилища, Storage Replica (SR) — это новая функция в Windows Server, которая позволяет проводить блочную синхронную (а в некоторых случаях — и асинхронную) репликацию на уровне тома между кластерами или серверами Windows Server vNEXT. В качестве транспорта используется протокол SMB3.
На текущий момент поддерживаются варианты репликации «Сервер-Сервер» и «Эластичный Кластер» (Stretch Cluster). Репликация уровня «Кластер-Кластер» пока что не реализована, но присутствует в планах. Поскольку репликация происходит на блочном уровне, то механизму нет особого дела до типа оборудования на котором развернута файловая система. Репликация может быть как синхронная, так и асинхронная (пока что только в сценарии «Сервер-Сервер»). В качестве сетевого механизма коммуникации могут использоваться TCP/IP или RDMA. Поверх реплики могут применяться механизмы дедупликации данных и шифрования на базе BitLocker. Настраивается это чудесное катастрофо- и отказоустойчивое чудо технологий пока исключительно через PowerShell. Для осуществления процесса также необходимо иметь открытыми порты TCP 445 или TCP 5445, быть членами одного домена (объект воздействия с этой точки зрения — хост, и реплицируются тома между хостами, а также возможны сценарии репликации томов в рамках одного хоста). Также важно помнить, что репликация возможна только для томов данных, но не для системного тома — проще говоря, реплицировать «Диск С:» технически не получится, да и не для этой цели разрабатывалась эта технология. Эта технология призвана обеспечить нулевой уровень потери данных (в случае синхронной репликации) или близкой к нулю уровень потери данных (асинхронный сценарий).
Также хочу сразу отметить, что требования к каналу тут также присутствуют определенные: по крайней мере одно соединение 10 Гбит/сек на каждом файловом сервере. Для надежности неплохо было бы убедиться, что отправки нефрагментированного ICMP-пакета размером 1472 байта проходят успешно без потерь на протяжении 5-ти минутного интервала.
Также стоит отметить, что использовать для репликации как в качестве цели, так и в качестве источника, съемные носители а-ля USB-накопитель, нельзя. Права на уровне встроенной группы администраторов Вам также понадобятся.
В целях тестирования Вы можете опробовать все механизмы на ВМ — только помните, что виртуальные диски в таком сценарии должны быть фиксированного типа, а не динамически расширяемые.
Настройка репликации «Сервер-Сервер»
Ну и после ознакомления с вводными по процессу настройки репликации томов, давайте же настроем репликацию «Сервер-Сервер». Только напомню Вам, что сервер в превью — и не стоит этот механизм применят для боевых данных сейчас.На каждом сервере-участнике должна быть установлена роль «File Server» и функция «Storage Replica» или «Windows Volume Replication» (в зависимости от билда сервера.
После этого на одном из серверов-участников исполните командлет PowerShell с админскими правами:
New-SRPartnership -SourceComputerName sr-srv05 -SourceRGName rg01 -SourceVolumeName d: -SourceLogVolumeName e: -DestinationComputerName sr-srv06 -DestinationRGName rg02 -DestinationVolumeName d: -DestinationLogVolumeName e: -LogSizeInBytes 8gb.В моем примере участвуют два сервера: sr-srv05 и sr-srv06, выделен отдельный том под лог-файлы (он должен быть по размеру на один гигабайт меньше, нежели том репликации и томы-источники и томы-цели.
Для проверки успешности настройки репликации последовательно исполнина обоих серверах-участниках исполните следующий командлет:
Get-WinEvent -LogName *WVR/admin -max 20 | fl
Наличие событий 2200, 5005, 5015, 5001 и 5009 будет признаком успеха.
Если нужны более детальные данные по счетчикам (Get-Counter), то вот их список:
• \Storage Replication Statistics(*)\Total Bytes Received
• \Storage Replication Statistics(*)\Total Bytes Sent
• \Storage Replication Statistics(*)\Avg. Network Send Latency
• \Storage Replication Statistics(*)\Replication State
• \Storage Replication Statistics(*)\Avg. Network Receive Latency
• \Storage Replication Statistics(*)\Last Recovery Elapsed Time
• \Storage Replication Statistics(*)\Number of Flushed Recovery Transactions
• \Storage Replication Statistics(*)\Number of Recovery Transactions
• \Storage Replication Statistics(*)\Number of Flushed Replication Transactions
• \Storage Replication Statistics(*)\Number of Replication Transactions
• \Storage Replication Statistics(*)\Max. Log Sequence Number
• \Storage Replication Statistics(*)\Number of Messages Received
• \Storage Replication Statistics(*)\Number of Messages Sent
• \Storage Replication Application I/O Statistics(*)\Number of Received App Write Irps
• \Storage Replication Application I/O Statistics(*)\Avg. Number of Irps/IoContext
• \Storage Replication Application I/O Statistics(*)\Avg. App Write Latency
• \Storage Replication Application I/O Statistics(*)\Avg. App Read Latency
Стоит также добавить, что в Windows Server Preview настроить репликацию повторно на томах, где она была, а потом была отключена — нельзя.
Процессы отображения хода событий могут быть неточными и не отображать полной действительности — лучше смотреть по счетчикам.
Ну и в принципе — вот и все!
Базовая и простая настройка репликации томов в Windows Server выглядит таким вот образом!
Пробуйте и до новых встреч на IT-фронте.
С Уважением,
Человек-огонь
Георгий А. Гаджиев
