Hyper-V и реплики хранилища

Microsoft представила концепцию реплик в Hyper-V в Windows Server 2012. В то время репликация Hyper-V предоставляла способ репликации виртуальных машин (или виртуальных жестких дисков) с одного хоста Hyper-V на другой. В то время процесс репликации был несколько ограничен и немного глючил. Реплики иногда не синхронизировались, и в некоторых из этих случаев единственным способом восстановить синхронизацию было удалить реплику и начать заново.

Однако со временем механизм репликации Microsoft стал намного лучше. В конечном итоге Microsoft исправила проблему синхронизации реплик и представила концепцию расширенных (трехсторонних) реплик в Windows Server 2012 R2.

Все это замечательно, но Windows Server 2016 предлагает нам новую форму репликации — реплики хранилища. В отличие от функции реплики Hyper-V в Windows Server 2012 и 2012 R2, функция реплики хранилища на самом деле является не функцией Hyper-V, а функцией Windows Server. Тем не менее, кажется, что он хорошо работает с Hyper-V. Кстати, функция репликации Hyper-V все еще существует в Hyper-V 2016.

Функция реплики хранилища — это именно то, что вы можете ожидать от ее названия. Это относится к способности операционной системы клонировать тома хранилища таким образом, чтобы эти копии томов могли использоваться несколькими компьютерами. Поставщики оборудования для хранения данных уже много лет предлагают такие возможности, но репликация хранилища Windows происходит на уровне операционной системы, и нет необходимости в поддержке репликации на аппаратном уровне. Действительно интересная вещь в способе, который Microsoft выбрала для реализации своей функции реплики хранилища, заключается в том, что репликация использует SMB.

В настоящее время Microsoft поддерживает три различные архитектуры для реплицированного хранилища. Самая простая из этих архитектур — сервер к серверу. Эта архитектура реплицирует хранилище одного сервера на другой сервер. Процесс репликации может происходить синхронно или асинхронно.

Прежде чем я продолжу и расскажу о двух других архитектурах синхронизированного хранения, я хочу воспользоваться моментом и ответить на один насущный вопрос. А именно, в чем преимущество использования реплицированного хранилища? Основным преимуществом является непрерывность бизнеса. Например, организация может реплицировать объем хранилища критически важного сервера на другой сервер в другом городе. Таким образом, если что-то случится с основным центром обработки данных организации, реплики можно будет использовать для ведения бизнеса.

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

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

Второй тип репликации хранилища, который поддерживается в Windows Server 2016, — это репликация хранилища кластера в кластер. Как следует из названия, этот тип репликации позволяет выполнять синхронную или асинхронную репликацию общего тома кластера.

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

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

С точки зрения репликации хранилища Windows растянутые кластеры уникальны тем, что представляют собой единственный тип собственной репликации хранилища, не требующий ручного вмешательства для аварийного переключения. Если, например, ранее упомянутый центр обработки данных в Дейтоне отключится, а центр обработки данных в Сент-Огастине все еще будет функционировать, то кластерные ресурсы (высокодоступные рабочие нагрузки) могут автоматически переключиться на центр обработки данных в Сент-Огастине.

Обратите внимание, как я это сформулировал? При сбое происходит переключение кластерных ресурсов, а не самого кластера. Причина этого в том, что в этой ситуации мы не переходим на избыточный кластер. Узлы в Daytona и узлы в St. Augustine являются частью одного и того же кластера.

Так как же репликация хранилища вступает в игру для растянутого кластера? Что ж, представьте, что основной центр обработки данных этой вымышленной организации находится в Дейтоне, и что центр обработки данных в Дейтоне содержит все хранилище для кластера. Если центр обработки данных Daytona отключится, то кластерное хранилище также выйдет из строя. Не имеет значения, что узлы кластера в St. Augustine все еще работают, потому что эти узлы не смогут обмениваться данными с общим томом кластера.

Репликация хранилища решает эту проблему, реплицируя общий том кластера в дополнительный центр обработки данных. Если произойдет сбой на уровне центра обработки данных, оставшийся центр обработки данных будет иметь доступ к локальной копии общего тома кластера.

Вывод

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