Pages Menu
Rss
Categories Menu

Опубликовано | Нет комментариев

Реплика хранилища


Хранилища современного предприятия, состоят из традиционных массивов накопителей Fibre Channel или шельфов дисков iSCSI. Новые улучшения хранения Windows Server 2016 приносят революционные функции, доступные каждой организации с её набором определённых программных функций.

Реплика хранилища

Реплика хранилища — это новая функция Windows Server 2016, с помощью которой можно настроить для аварийного восстановления - агностику хранения, блочные, синхронные репликации между кластерами или серверами. Также с её помощью можно растянуть отказоустойчивый кластер на сайтах для более высокой доступности. Синхронная репликация позволяет вам зеркалировать данные на физических сайтах с краш-последовательными томами, обеспечивая нулевую потерю данных на уровне файловой системы.

Асинхронная репликация даёт вам возможность расширять сайты за пределы диапазонов метрополии с возможностью потери данных. Реплика хранения не работает на уровне файлов, как служба репликации DFS. Вместо этого она реплицирует блоки данных и поэтому имеет иммунитет к проблемам блокировки файлов, открытым дескрипторам, и так далее.

Подробнее. Реплика хранения — это новая функция Windows Server 2016 и программно определяемых ЦОД, там нет предыдущих усовершенствований. Для получения дополнительной информации посетите http://aka.ms/sroverview.

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

Синхронная репликация гарантирует, что приложение, до завершения операции записи, записывает данные по крайней мере в два места одновременно. Эта репликация наиболее подходит для критически важных данных, поскольку она требует сети, инвестиций в хранилище и несёт риск ухудшения производительности приложений. Синхронная репликация подходит для высокой доступности (HA) и решений аварийного восстановления (DR).

Когда запись приложения происходит в копии исходных данных (1), хранилище не сразу распознает I/O. Вместо этого эти данные изменяются на копию удалённого назначения (2) и записываются в журнал данных (3). Затем удалённый сайт возвращает подтверждение (4). Только тогда приложение получает подтверждение I/O (5). Это, в силу расширения I/O хранения по сети, гарантирует постоянную синхронизацию удалённого узла с исходным веб-сайтом. В случае сбоя исходного сайта, приложения могут отработать отказ на удалённый сайт, и возобновить операции с обеспечением нулевой потери данных.

эффективность_синхронной_репликации

Эффективность синхронной репликации в реплике хранения

Примечание. На рисунке выше буква «T» указывает, что данные сброшены на том исходного сайта, а «T1» - что данные сброшены на том удалённого сайта. Во всех случаях, журналы всегда пишут.

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

В отличие от синхронной репликации, асинхронная репликация означает, что когда приложение записывает данные, эти данные реплицируются на удалённый сайт без немедленных гарантий подтверждения. Этот режим способствует быстрому времени отклика приложения, а также DR решение, которое работает географически. С её более чем нулевой Recovery Point Objective (RPO), асинхронная репликация меньше подходит для HA решений, таких как отказоустойчивые кластеры, потому, что она предназначена для непрерывной работы с избыточностью и без потери данных.

выполняемая_асинхронная_репликация

Выполняемая репликой хранения асинхронная репликация

Как показано на рисунке, когда приложение записывает данные (1), модуль репликации захватывает и записывает журналы (2) и немедленно подтверждается в приложении (3). Собранные данные затем реплицируются в удалённое расположение (4). Удалённый узел обрабатывает копию данных, записывает данные журнала (5) и возвращает к исходной копии (6). Поскольку производительность репликации больше не находится в пути I/O приложения, ответная реакция и расстояние удалённого сайта являются менее важными факторами. Если исходные данные теряются, а целевая копия данных по-прежнему находится в буфере, не выходя из источника - существует риск потери данных.

Специфичные для реализации детали реплики хранения, в качестве надёжного высокоскоростного переноса данных для репликации, используют SMB 3.0. Это даёт все преимущества SMB 3.0, такие как многоканальность, RDMA, шифрование, подпись и безопасность на основе Kerberos. Реплика хранилища не требует каких-либо изменений в доменных службах Active Directory (AD DS) или любых административных разрешений домена.

В следующей таблице приведены конкретные сведения о реализации реплики хранилища:

Признак Детали
Тип Основной хост
Синхронизация Да
Асинхронизация Да (только сервер-на-сервер)
Агностика оборудования хранения Да
Блок репликации Том (раздел)
Windows Server Stretch Cluster creation Да
Репликация сервер-на-сервер Да
Перемещение SMB 3.0
Сеть TCP/IP or RDMA
RDMA iWARP, InfiniBand*
Требования к порту брандмауэра при репликации сети Single IANA port (TCP 445 or 5445)
Multipath/Multichannel Да (SMB 3.0)
Поддержка Kerberos Да (SMB 3.0)
Шифрование и подпись Да (SMB 3.0)
Разрешена переустановка тома Да
Интерфейс управления UI Windows PowerShell, Failover Cluster Manager
*При условии дальнейшего тестирования. InfiniBand может потребоваться дополнительное дальнемагистральное оборудование

Примечание. В Windows Server 2016, Storage Replica не реализует транзитивную репликацию, так называемую топологию «A-B-C» (то есть синхронную репликацию с сервера A на сервер B, а затем асинхронную репликацию с сервера B на сервер C). Реплика хранилища не реализует репликацию один-со-многими. Это возможно, только для виртуализированных рабочих нагрузок, использование Hyper-V Replica в качестве вторичного механизма асинхронной репликации. Это означает настройку реплики Hyper-V на томе источника «A» и репликацию на сервер, отличный от «B», который образует топологию «A-to-B + A-to-C».

Требования

Ниже приведены предварительные условия для тестирования репликации хранилища:

  • Windows Server 2016 Datacenter Edition
  • Не менее 4 ГБ физической памяти на каждом сервере и не менее двух ядер
  • AD DS (для SMB с использованием Kerberos)

Нет необходимости в обновлениях схемы, объектах AD DS, определённых функциональных уровнях AD DS и т. д.

Сеть

  • Больше или равно 1 Гбит сети между серверами
  • Открытые порты брандмауэра: SMB, WS-MAN

Хранилище

  • Один том в формате NTFS / ReFS, предназначенный для репликации на сервер/кластер с не менее чем 8 ГБ свободного места
  • Таблица разделов GUID (GPT) (не главная загрузочная запись [MBR])
  • JBOD, iSCSI, локальный DAS (некластерный) SCSI или SATA, пространство хранения данных Direct (только для кластера) или Storage Array Network (SAN)
  • Те же размеры сектора для объёма дисков данных и для томов журнала
  • Не %SystemRoot% или файл страницы, расположенный на реплицированных томах или логах

Рекомендации

Для тестирования репликации хранилища настоятельно рекомендуется следующее:

Сеть

  • Пропускная способность: ≥10 Гбит/с сеть между серверами
  • Задержка: ≤5 ms, среднее значение для синхронной репликации

Хранилище

  • Флэш-диски (твердотельный диск [SSD]) для тома журнала с, по крайней мере 8 ГБ свободного пространства

Совет. Вы можете использовать командлет Test-SRTopology Windows PowerShell, чтобы убедиться, что вы отвечаете требованиям и помогаете с рекомендуемой настройкой конфигурации для файлов журналов.

Оставить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Лимит времени истёк. Пожалуйста, перезагрузите CAPTCHA.


↓