Рекомендации по общему хранилищу для Hyper-V (часть 3)

• Рекомендации по общему хранилищу для Hyper-V (часть 1)

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

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

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

Легко предположить, что, поскольку общее хранилище больше не требуется, файлы виртуальных машин хранятся локально на каждом хост-сервере Hyper-V. Хотя использование локального хранилища действительно поддерживается, это не единственный вариант. Microsoft также впервые позволяет хранить виртуальные машины на файловых серверах. Единственная загвоздка в том, что файловый сервер должен поддерживать использование блоков сообщений сервера (SMB) 3.0, которые вводятся в Windows Server 2012.

Поддержка общего тома кластера

Хотя Microsoft по понятным причинам рекламирует тот факт, что Hyper-V больше не зависит от использования общего хранилища, те организации, которые уже вложили средства в оборудование для поддержки общего хранилища для своих существующих развертываний Hyper-V, могут задаться вопросом, будет ли Hyper-V 3.0 продолжать поддерживают использование общих томов кластера, или если Microsoft полностью отказывается от этой концепции.

Я рад сообщить, что общие тома кластера не только по-прежнему поддерживаются, но и Microsoft внесла в них ряд улучшений. Наиболее важной из этих новых функций является совершенно новая файловая система под названием CSVFS. Эта файловая система похожа на NTFS, но специально разработана для использования на общих томах кластера. Эта новая файловая система фактически позволяет поддерживаемым приложениям обнаруживать, что они работают на общем томе кластера.

Microsoft также внесла ряд улучшений в области резервного копирования и восстановления общих томов кластера и начала поддерживать конфигурации с несколькими подсетями.

Еще одно улучшение заключается в том, что отказоустойчивый кластер будет поддерживать шифрование диска BitLocker для общих томов кластера. Отдельные узлы кластера могут расшифровать и получить доступ к зашифрованному общему тому кластера с помощью объекта имени кластера.

Репликация виртуальной машины

Еще одна новая функция Hyper-V 3.0, которая повлияет на общее планирование хранения, — это репликация виртуальных машин. Репликация виртуальных машин — это совершенно новая функция Hyper-V 3.0, которая позволяет реплицировать работающие виртуальные машины на резервные серверы или даже узлы Hyper-V в удаленном центре обработки данных.

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

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

Некоторые организации рассматривают возможность использования сайтов реплик Hyper-V в рамках своей схемы резервного копирования. Основная идея заключается в том, что можно делать резервные копии виртуальных машин-реплик, а не запускать резервные копии рабочих виртуальных машин. Это избавляет производственное оборудование от необходимости выделять аппаратные ресурсы для процесса резервного копирования. Другими словами, разгружая процесс резервного копирования на непроизводственное оборудование, резервное копирование не влияет на работу конечного пользователя.

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

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

Для большинства виртуальных машин объема трафика, генерируемого текущим процессом репликации, вероятно, будет недостаточно, чтобы вызвать серьезные проблемы. Это особенно верно, учитывая тот факт, что Microsoft позволит вам создать собственный график репликации, который позволяет реплицировать содержимое виртуальной машины в периоды низкой нагрузки.

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

Виртуальный оптоволоконный канал

Еще одна новая функция Hyper-V 3.0, связанная с хранением данных, — это виртуальный Fibre Channel. Эта функция позволяет виртуальным машинам напрямую взаимодействовать с хранилищем Fibre Channel. Один из важных вопросов, который часто задают в отношении виртуального Fibre Channel, заключается в том, можно ли перенести виртуальные машины, использующие виртуальный Fibre Channel, в режиме реального времени.

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

Вывод

Хотя Hyper-V 3.0 по-прежнему поддерживает использование общих томов кластера, он обязательно изменит правила игры для Microsoft, поскольку большинство функций можно использовать без общего хранилища. Это сделает избыточность и отказоустойчивость более доступными для небольших организаций.

• Рекомендации по общему хранилищу для Hyper-V (часть 1)