Для этого используется технология кластера с обработкой отказа, или Failover Clustering. В Windows Server 2008 разработчиками вводится понятие failover clustering VM (тип service), что позволяет настраивать виртуальные машины Hyper-V и делать дисковые ресурсы частью ресурсных групп, которые можно перемещать между узлами в кластере. Однако технология Failover Clustering, реализованная в Windows Server 2008, имеет ряд особенностей, о которых я и хочу рассказать подробнее.
В Windows Server 2008 R2 и Hyper-V, и Failover Clustering были доработаны с целью обеспечить высокую доступность в виртуальной среде. Целью, поставленной перед Server 2008 R2, стало достижение нулевого времени простоя при использовании запланированного процесса обработки отказа. Речь идет об унаследованных от Server 2008 следующих проблемах:
- перевод виртуальной машины в состояние «пауза» для копирования содержимого памяти виртуальной машины на целевой узел;
- необходимость перемещать владельца тома LUN с одного узла на другой, для чего требуется некоторое время из-за выполнения операций с физическим диском (операций монтирования и размонтирования).
Рассмотрим эти изменения более подробно. Надеюсь, они помогут достичь нулевого времени простоя при проведении плановой обработки отказа.
Миграция онлайн и перевод виртуальной машины в состояние «пауза»
Для решения первой проблемы, связанной с необходимостью перевода виртуальной машины в состояние suspend при копировании содержимого ее памяти, команда разработчиков Hyper-V реализовала технологию Live Migration, когда память виртуальной машины копируется на целевой узел без остановки виртуальной машины — во все время копирования она не прекращает работать. Однако это оказалось проще сказать, чем сделать.
Мы не можем просто так взять и скопировать память виртуальной машины на другой узел, поскольку пока происходит копирование, виртуальная машина продолжает работать, и часть памяти успевает измениться. И хотя копирование выполняется по высокоскоростным сетям, какое-то — пусть и очень незначительное — время этот процесс занимает. Мы также не можем просто перевести виртуальную машину в состояние pause во время копирования памяти, так как это будет означать простой. Предлагаемое решение носит итеративный характер.
Первый этап Live Migration — копирование конфигурации и параметров устройств виртуальной машины с узла-владельца на целевой узел. Таким образом на целевом узле создается оболочка виртуальной машины, некий контейнер, которому предстоит принять содержимое памяти виртуальной машины и ее состояние.
На следующем этапе выполняется перенос памяти виртуальной машины. Это большой массив данных, и перенос занимает значительное время. Виртуальная машина все это время продолжает работать, поэтому нам нужен способ отследить страницы в памяти, которые успели измениться за время копирования. В конце данного этапа некий процесс на текущем узле создает «матрицу использования» (dirty bitmap) страниц в памяти, которые продолжают использоваться, и регистрирует для этих страниц уведомление о внесении изменений.
Если страница претерпевает изменения, матрица соответствующим образом модифицируется, чтобы выделить такую страницу. После завершения первого прохода копирования на целевой узел повторно копируются только те страницы, для которых установлен признак dirty. На это уходит меньше времени, процесс протекает быстрее. Однако и за это время другие страницы в памяти могут измениться, и таким образом процесс копирования повторяется снова и снова.
В идеале с каждой итерацией количество копируемых данных и время копирования уменьшаются и в конечном счете наступает такой момент, когда вся память скопирована и можно выполнять переключение на целевой узел. В реальности, однако, дело обстоит несколько иначе: существует ограничение на число итераций копирования памяти — в противном случае копирование могло бы повторяться до бесконечности.
После того как все страницы в памяти скопированы или же достигнут предел числа итераций копирования (к моменту публикации максимальное число операций повторного копирования равнялось 8, но это значение может быть изменено), наступает момент переключения виртуальной машины на целевой узел. Для этого виртуальная машина на текущем узле переводится в состояние suspend, страницы памяти, которые не удалось скопировать на этапе переноса памяти виртуальной машины, копируются на целевой узел и туда же переносится состояние виртуальной машины, включающее состояние устройств и процессора.
Затем виртуальная машина запускается на целевом узле. Рассылается пакет протокола ARP, оповещающий о переносе IP-адреса виртуальной машины в новое место, в результате чего обновляются таблицы ARP маршрутизирующих устройств. С этого момента клиенты могут подключаться к целевому узлу.
Меня могут спросить, какие из перечисленных действий выполняются автоматически, а какие требуют вмешательства администратора. Ответ: все выполняется в автоматическом режиме. Единственное выполняемое вручную действие — собственно запуск Live Migration.
Да, небольшая приостановка виртуальной машины все же происходит — для копирования состояния виртуальной машины, но это занимает несколько миллисекунд и меньше порогового значения для установления TCP-соединения. Во время процесса Live Migration клиенты не будут отключены от виртуальной машины и пользователи вообще ничего не заметят.
После завершения миграции виртуальной машины на целевой узел предыдущий узел-владелец виртуальной машины получит уведомление о том, что среда виртуальной машины на нем может быть очищена. На рисунке 1 изображен весь процесс Live Migration: на целевом хосте создается контейнер виртуальной машины, память копируется в несколько этапов, состояние виртуальной машины переносится на новое место, виртуальная машина запускается на целевом узле.
Итак, Live Migration позволяет выполнить перенос конфигурации, памяти и состояния виртуальной машины практически без простоя. Прекрасно, но решена только первая из двух проблем. А как же LUN, в котором содержатся файлы конфигурации виртуальной машины и VHD? Нужно решить задачу перемещения LUN между узлами кластера.
Cluster Shared Volumes и перемещение LUN
Операции размонтирования, dismount, и монтирования, mount, при перемещении тома LUN означают простой, а это может привести к разрыву TCP-соединения и отключению клиентских систем. Основная проблема состоит в том, что NTFS — это файловая система без разделения ресурсов, и она не поддерживает одновременную работу нескольких экземпляров операционной системы, что является ограничением, если вспомнить, что SAN (а следовательно, и LUN) поддерживает параллельные подключения.
Чтобы том LUN в формате NTFS был доступен на чтение и запись сразу нескольким узлам кластера, разработчики Microsoft предложили концепцию общих томов кластера, Cluster Shared Volumes (CSV) (см. экран 1).
Как работает CSV
Для каждого CSV существует узел, назначенный на роль узла-координатора. У такого узла есть локальный диск, к которому он имеет полный доступ как к локально подключенному устройству. Остальные узлы кластера для каждого LUN, который является частью CSV, получают карту секторов на диске (raw sector map) интересующих их файлов. Карта дает возможность узлам, которые не являются координаторами, читать и писать на диск напрямую, без предварительного монтирования тома NTFS (так называемый прямой ввод/вывод).
Механизм прямого ввода/вывода реализован в виде фильтра CSV, который встроен непосредственно в стек драйвера файловой системы на всех узлах кластера, получающих карту секторов от узла-координатора для каждого диска CSV. Фильтр CSV обеспечивает выполнение прямых операций ввода/вывода со стороны узлов, не являющихся координаторами. При работе с VHD эти операции производятся чаще всего.
Однако узлы, не являющиеся координаторами, не могут внести изменения в метаданные и пространство имен, например создание, удаление или изменение размера файла. Данные операции требуют управления структурой NTFS, и этим занимается только узел-координатор, во избежание искажения данных. Если обычный узел хочет выполнить такую операцию, он сообщает об этом координатору, который и вносит соответствующие изменения.
Но фильтр CSV предоставляет нам еще одну замечательную возможность. В том случае когда обычный узел теряет прямой доступ к LUN, например, из-за сетевого сбоя по iSCSI, все операции ввода/вывода могут быть выполнены по сети с помощью узла-координатора. В этом случае говорят о перенаправленном вводе/выводе (redirected I/O). На рисунке 2 изображен сценарий, когда узел теряет прямой доступ к устройству хранения, и фильтр CSV перенаправляет все операции ввода/вывода через сеть NetFT. Это виртуальная сеть, которая связана с одной из физических кластерных сетей, запущенных в кластере; по сути, это эквивалент прежней служебной сети private network в Windows Server 2003, использовавшейся для межкластерных коммуникаций, например для обмена пакетами heartbeat, подтверждающими работоспособность узла кластера.
Сеть, к которой привязана NetFT, основана на автоматической метрике. Для всех остальных сетей в кластере также применяются автоматические метрики; однако для NetFT используется самый низкий приоритет. В бета-версиях Windows 2008 R2 для Live Migration по умолчанию применялись те же самые метрики, что и для NetFT, поэтому к какой бы сети ни была привязана NetFT, Live Migration оказывалась на самом верху и с той же метрикой. Такая ситуация была изменена в Release Candidate и финальном коде: разработчики Microsoft посчитали нежелательным, чтобы трафик NetFT и Live Migration порождался в одной и той же сети, из-за возможных сетевых конфликтов. В результате трафик Live Migration в настройках по умолчанию связан с сетью со второй по счету минимальной метрикой.
Следует помнить, что в процессе работы Live Migration может выбрать сеть, которая для вас окажется нежелательной с точки зрения кластерного трафика, например сеть iSCSI. Поэтому необходимо надлежащим образом задать порядок сетей и их доступность для Live Migration (см. экран 2).
Узел кластера, выполняющий роль координатора, может быть перемещен на другой сервер с минимальными накладными расходами. При перемещении координатора возникает очень незначительная пауза, сравнимая со штатной задержкой операций ввода/вывода, находящихся в очереди. Очень маловероятно, что пауза будет заметной: для CSV критически важно, чтобы узел-координатор всегда был в наличии.
Наличие нескольких узлов, напрямую пишущих на диск, может вызвать некоторые сложности, в основном из-за того, что большинство утилит просто этого «не ожидают». Когда выполняется резервное копирование или другие дисковые процедуры, такие как дефрагментация или проверка диска (chkdsk), необходимо перевести диск в режим обслуживания, при котором прямое обращение к кластерным дискам запрещено и операции ввода/вывода выполняются с использованием механизма перенаправления. Следует убедиться, что только узел-координатор имеет доступ к диску. Это помогает избежать интерференции с резервным копированием и другими дисковыми операциями. Очень удобно, что в финальной версии Server 2008 R2 консоль Failover Cluster Management содержит ссылки на операции defrag и chkdsk и все необходимые подготовительные процедуры выполнит за вас.
Реализации CSV
Сейчас CSV поддерживает только Hyper-V. В будущем планируется задействовать CSV и в других сценариях работы. Поддержка CSV избавляет от необходимости перемещать тома LUN между узлами кластера во время миграции виртуальной машины, так как в каждый момент времени LUN доступен для всех узлов, тем самым решается проблема монтирования и отключения диска.
Но CSV — нечто большее, чем просто сведение к нулю времени простоя виртуальной машины в процессе миграции. Раньше необходимо было обслуживать множество томов LUN, чтобы информация о них была доступна для всех узлов в кластере. Например, для четырехузлового кластера как минимум требовалось четыре LUN для независимого перемещения виртуальной машины с одного узла на другой. Теперь же, имея CSV, LUN являются частью кластерного хранилища, доступного сразу всему кластеру, всем его узлам, поэтому нет необходимости разделять тома LUN. А это дает возможность предоставлять свободное дисковое пространство всем виртуальным машинам на LUN и быстрее выполнять настройку, так как приходится тестировать меньшее число томов.
Отличное решение
После многочисленных, но безуспешных попыток сломать Hyper-V могу честно сказать, что работает он очень хорошо. Live Migration в сочетании с Cluster Shared Volumes и Hyper-V предоставляют технологию высокой доступности. Тех, кто использует автономное (standalone) решение Hyper-V Server, также могу порадовать: Hyper-V Server 2008 R2 встроен в версию Enterprise Edition Server 2008 R2 Server Core. Это означает, что в дополнение к бесплатной платформе виртуализации с поддержкой кластеризации мы «просто так» получаем Live Migration и CSV!
Джон Сэвилл (jsavill@windowsitpro.com) — директор по технической инфраструктуре компании Geniant, имеет сертификаты CISSP, Security и Messaging MCSE для Windows Server 2003 и звание MVP
Рисунок 1. Схема процесса Live Migration
Рисунок 2. Перенаправленный ввод/вывод