Первый взгляд на функцию Hyper-V Virtual Fibre Channel (часть 1)

Введение

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

Зачем использовать виртуальный оптоволоконный канал?

Наибольшее преимущество использования виртуального Fibre Channel заключается в том, что он позволяет виртуализировать рабочие нагрузки, которые ранее не могли быть виртуализированы из-за их зависимости от хранилища Fibre Channel. Теперь виртуальные машины могут напрямую обращаться к хранилищу Fibre Channel так же, как если бы операционная система работала на физическом сервере.

Конечно, доступность хранилища — не единственное преимущество использования виртуального Fibre Channel. Эта технология также делает более практичным создание гостевых кластеров на уровне виртуальной машины.

Некоторые администраторы могут по понятным причинам неохотно использовать функцию виртуального Fibre Channel. В конце концов, Hyper-V уже давно поддерживает SCSI pass through — еще один механизм подключения виртуальной машины к физическому хранилищу. Хотя SCSI работает, он усложняет такие вещи, как резервное копирование и миграция виртуальных машин. В таком случае я хотел сразу сказать, что при правильной реализации виртуальный Fibre Channel является первоклассным компонентом Hyper-V. Вопреки слухам, вы можете выполнять живую миграцию на виртуальных машинах, использующих виртуальный Fibre Channel.

Требования к виртуальному оптоволоконному каналу

Существует ряд различных требований, которые необходимо выполнить перед использованием функции виртуального Fibre Channel. Во-первых, ваш сервер Hyper-V должен быть оснащен хотя бы одним адаптером главной шины Fibre Channel (также поддерживается использование нескольких адаптеров главной шины). Кроме того, адаптер главной шины должен поддерживать виртуализацию идентификатора N_Port (NPIV). NPIV — это стандарт виртуализации, который позволяет использовать N_Port адаптера главной шины для нескольких идентификаторов N_Port. Адаптер главной шины не только должен поддерживать NPIV, но и должна быть включена поддержка NPIV, а адаптер главной шины должен быть подключен к SAN с поддержкой NPIV.

Перечисленных выше требований достаточно, чтобы позволить Hyper-V получить доступ к вашей сети Fibre Channel. Однако ваши виртуальные машины также должны поддерживать подключение Fibre Channel. Это означает, что вам придется запускать поддерживаемую операционную систему на ваших виртуальных машинах. Если вы хотите подключить виртуальную машину к виртуальному Fibre Channel, виртуальная машина должна работать под управлением Windows Server 2008, Windows Server 2008 R2 или Windows Server 2012. Никакие другие гостевые операционные системы в настоящее время не поддерживаются для использования с виртуальным Fibre Channel.

Если вам интересно, Hyper-V 3.0 не позволяет использовать виртуальные LUN Fibre Channel в качестве загрузочного носителя.

Планирование живой миграции

Как указывалось ранее, функция динамической миграции Hyper-V совместима с виртуальным Fibre Channel. Тем не менее, облегчение живой миграции требует некоторого планирования. Как и следовало ожидать, основным требованием является то, что каждый хост Hyper-V, на который потенциально может быть перенесена виртуальная машина, должен иметь совместимый адаптер шины хоста, подключенный к SAN.

Процесс динамической миграции стал возможен благодаря тому, что Hyper-V использует глобальные имена (WWN). Hyper-V требует применения двух WWN к каждому адаптеру Fibre Channel. Как вы, несомненно, знаете, миграция виртуальной машины на другой хост Hyper-V требует, чтобы Hyper-V в конечном итоге передал подключение к хранилищу целевому хосту. Если бы каждый хост был настроен только с одним WWN, то соединение Fibre Channel было бы нарушено во время процесса передачи обслуживания. Однако использование двух разных имен WWN на каждом адаптере решает эту проблему.

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

Многоканальный ввод-вывод

Другой сетевой технологией, совместимой с виртуальным Fibre Channel, является многоканальный ввод-вывод (MPIO). Многопутевой ввод-вывод — это технология хранения, предназначенная для обеспечения непрерывного подключения к ресурсу хранилища путем маршрутизации сетевого трафика через несколько сетевых адаптеров.

Многопутевой ввод-вывод используется как способ обеспечения отказоустойчивости и повышения производительности в средах SAN. Основная идея заключается в том, что многопутевой ввод-вывод предотвращает превращение любого из компонентов SAN в единую точку отказа. Например, сервер, подключенный к хранилищу SAN, может использовать два отдельных адаптера главной шины. Эти адаптеры обычно подключаются к двум отдельным коммутаторам Fibre Channel, прежде чем в конечном итоге будут подключены к массиву хранения. Сам массив может быть даже оснащен резервными дисковыми контроллерами.

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

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

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

Технология виртуального оптоволоконного канала

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

Обычно физический порт Fibre Channel подключается к SAN. Однако один хост-сервер может содержать несколько адаптеров главной шины, и каждый адаптер главной шины может иметь несколько портов. Здесь в игру вступают виртуальные SAN. Виртуальная SAN — это именованная группа портов, подключенных к одной и той же физической SAN. Вы можете думать о виртуальной SAN как о механизме отслеживания подключений портов.

Вывод

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