Сравнение подходов к построению кластеров внутри виртуальных машин и выход Windows Storage Server 2008

Известная особенность Hyper-V (включая грядущую вторую версию) — отсутствие возможности создать общее хранилище между несколькими виртуальными машинами. Иными словами, вы не можете подключить один и тот же файл виртуального диска (VHD) к двум одновременно запущенным виртуальным машинам. Зачем это нужно? Пожалуй, есть только один сценарий, который мог бы выиграть от такой возможности. Но этот сценарий очень и очень востребован. Речь пойдёт о кластеризации с переходом по отказу — Failover Clustering. (Этот термин часто ошибочно переводят как «отказоустойчивые кластеры»). В предыдущих версиях Windows Server эта функция называлась просто «Server Clustering» — то есть кластеризация серверов.

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

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

1. Built-in Redundancy/High Availability

Я встречал пользователей и даже администраторов, уверенных в необходимости кластеризовать такие службы, как Active Directory Domain Services (ADDS) или DNS. Но реальность такова, что на самом деле надёжность этих служб обеспечивается совершенно другими методами. Эти методы реализованы в рамках собственного функционала как серверов, так и клиентов — и обычно стандартизованы в используемых ими протоколах. Например, для того, чтобы обеспечить высокую доступность службы ADDS, вам потребуется создать несколько самостоятельных серверов, которые будут выполнять роль контроллера домена. Затем необходимо правильно настроить DNS для того, чтобы клиенты могли распознавать и обращаться к любому из этих серверов. При этом важно отметить, что никакие специфические требования к оборудованию как серверов, так и клиентов здесь не предъявляются. А значит, любые из этих компонентов с успехом могут быть размещены в виртуальных машинах.

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

2. Network Load Balancing/Round Robin

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

Важная особенность этих технологий — то, что они предназначены в первую очередь для обеспечения масштабируемости службы. Разумеется, доступность службы при этом также возрастает — но это является в некотором роде «побочным эффектом». Поэтому, строго говоря, эти технологии вообще не являются кластерами с переходом по отказу (Failover). Описание этой модели — равно как и предыдущей — приводится здесь исключительно в справочных целях.

Для выполнения основной задачи — масштабирования — требуется, чтобы клиенты имели возможность доступа к нескольким серверам одновременно. А значит, эта модель хорошо подходит для тех случаев, когда мы можем обеспечить параллельную работу всех серверов с одинаковыми данными. Иными словами, технологии NLB и RR используются в тех случаях, когда служба не предоставляет никаких данных, а только обрабатывает данные клиентов (например, SMTP), или предоставляет достаточно статичные данные. В последнем случае неизменная — и потому всегда актуальная — копия данных может находиться и одновременно предоставляться со всех серверов массива. Примером такого сценария является ферма веб-серверов.

Точно так же, как и в предыдущем случае, серверы, объединённые в массив NLB или RR, могут располагаться в виртуальных машинах. С реализацией такого сценария сопряжены некоторые технические тонкости, о которых мы уже писали.

3. Guest Failover Clustering (without Shared Storage)

Существует и третья ситуаця, которая по требованиям к оборудованию совершенно не отличается от двух моделей, описанных выше. Но здесь всё-таки требуется создание кластера Windows Server с переходом по отказу (Failover). При этом используется модель кворума «Node Majority» (большинство узлов) или «Node and File Share Majority» (большинство узлов и общего файлового ресурса). В обоих случаях общее хранилище не требуется — хотя и может использоваться службами, которые работают на кластере.

Пример важного приложения, которому не требуется общее хранилище, — Microsoft Exchange Server, развёрнутый в роли сервера почтовых ящиков (Mailbox) с механизмом постоянной репликации в кластере (Cluster Continuous Replication, CCR). К слову сказать, будущая версия Exchange Server 2010 вообще не будет поддерживать развёртывание на кластере с общим хранилищем. Это ли не показатель того, что именно модель кластеров с раздельным хранилищем является наиболее успешной и надёжной?

И в этом случае узлы кластера также вполне могут располагаться в виртуальных машинах. Никаких специфических требований к системе виртуализации для этого не предъявляется. Такой подход обычно описывается как «кластеризация гостевых систем» или «Guest Clustering».

4. Host Clustering

Четвёртый подход является уникальным преимуществом виртуализации. Если вы не можете или не хотите повышать доступность одним из способов, описанных выше, — подумайте о том, чтобы разместить важную службу в… виртуальной машине! Ведь доступность самой виртуальной машины можно повысить достаточно легко. Для этого достаточно перенести её на кластер серверов, которые выполняют роль виртуализации — будь то Hyper-V, Virtual Server 2005 R2 или конкурирующие решения.

Такой подход часто описывается как «кластеризация родительских систем» или «Host Clustering». Его главное преимущество — не требуются вносить какие-либо изменения в конфигурацию самой ОС и приложений внутри виртуальной машины. Это особенно удобно, если ваше приложение или служба не способно само по себе обеспечивать высокую доступность. То есть — не имеет встроенных механизмов, аналогичных описанным в первом пункте, не совместимо с NLB или RR и не поддерживает самостоятельную кластеризацию. А если такая служба запущена в виртуальной машине — для неё не имеет значения, работает ли эта виртуальная машина на одиночном сервере виртуализации или кластере таких серверов.

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

5. Clustering with Shared Storage

Пятый способ, — собственно, традиционная кластеризация с использованием общего хранилища. В этом случае существует набор томов, которые доступны всем узлам кластера. Хотя в каждый момент времени действительно работает с томом только один из узлов. А именно — тот, который является текущим носителем кластерной группы. Исключение из этого правила — новая технология обеспечения доступа к хранилищу, которая появится в Windows Server 2008 R2 и будет работать только с ролью Hyper-V. Она называется «Cluster Shared Volume» (CSV) — общий том в кластере.

Общие тома используются как для хранения текущей информации о состоянии кластера (в моделях кворума «Node and Disk Majority» и «Disk Only»), так и для хранения собственно данных, с которыми работает кластеризованная служба. Очевидно, что общая копия данных является единой точкой отказа. Поэтому применять такой механизм кластеризации стоит с осторожностью и только тогда, когда другие сценарии повышения доступности по каким-то причинам не подходят. Хороший пример службы, которая по своей природе неспособна работать с несколькими одновременно доступными копиями данных — это Microsoft SQL Server и вообще различные базы данных. Кластер служб виртуализации является другим примером приложения такого рода. Ведь файлы виртуальных машин хранятся в единственном экземпляре вне зависимости от того, на каком узле кластера запущена та или иная ВМ.

Понятно, что описываемый здесь механизм требует повышенного внимания к надёжности хранилища, поэтому он часто оказывается самым дорогим сценарием. К слову сказать, термин «общее хранилище» не всегда обозначает в действительности единственный физический накопитель или дисковый массив. Это значит лишь что то, что кластеризованная служба будет воспринимать данные как единый экземпляр, поочерёдно доступный всем узлам кластера. Однако в реальности таких экземпляров может быть несколько. Это особенно актуально для территориально разнесённого кластера — то есть такого, узлы которого находятся на значительно отдалении друг от друга. Это необходимо в первую очередь для обеспечения высшей степени доступности службы, ибо предоставляет защиту даже от выхода из строя целого ЦОД.

Вопрос только в том — как постоянно поддерживать эти копии в актуальном состоянии, то есть обеспечивать строгую синхронизацию. И здесь на сцену выходят решения, поставляемые третьими фирмами. Причём, как правило, лучшую производительность и доступность обеспечивают решения, реализованные на аппаратном уровне и тесно интегрированные с системами хранения данных, а следовательно — разработанные самим поставщиком СХД. Хотя существуют и полностью программные реализации. Например, тем заказчикам, которых интересует построение кластеров Hyper-V без физического общего хранилища, Microsoft рекомендует обратить внимание на продукт «DataKeeper» компании SteelEye Technology, Inc.

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

6. Guest Failover Clustering (with iSCSI)

Что же делать, если общее хранилище вам не подходит из соображений цены, а важная служба не поддерживает самостоятельные механизмы повешния доступности? При этом размещать приложение в виртуальной машине тоже нежелательно из соображений производительности или консерватизма. Или возьмём для примера саму службу виртуализации. Понятно ведь, что виртуализовать её саму в отказоустойчивой виртуальной машине — это, мягко говоря, не лучший выход.

Именно для таких и подобных случаев был разработан протокол передачи сигналов работы с хранилищами (SCSI) поверх протокола TCP/IP. Вполне в духе времени этот стандарт получил название iSCSI. Самыми важными для нас здесь являются два момента. Первый: поскольку для работы iSCSI используется обычное подключение Ethernet, для него не требуется никакое специальное оборудование. (Хотя оно может применяться для повышения надёжности и производительности. И это, собственно, является предпочтительным, если такая возможность существует. С другой стороны, если вы всё же можете позволить себе приобретение специального оборудования для организации доступа к хранилищу — возможно, стоит задуматься о применении других проколов, таких как Fibre Channel). Следовательно, iSCSI без проблем работает внутри любых виртуальных машин без каких-либо ограничений. Второй момент: сам протокол позволяет одновременную работу нескольких клиентов с одним и тем же хранилищем. А значит — подходит для построения кластеров между несколькими такими клиентами. Следовательно, iSCSI — это то самое средство, которое позволяет без особых проблем строить кластеры между виртуальными машинами для любых служб и приложений. Даже тех, которые требуют использования общего хранилища.

Подробнее об iSCSI

Самое сложное для понимания iSCSI — это терминология, сбивающая с толку любого, кто только начинает своё знакомство с этой технологией. Сервер iSCSI (т.е. сторона, предоставляющая службу общего хранилища) называется «целью» (Target), а клиент (сторона, используящая общее хранилище по сети) — «инициатором» (Initiator). Оба этих компонента могут быть реализованы как программно, так и аппаратно. Причём благодаря жёсткой стандартизации протокола возможны любые комбинации. Например, схема, набравшая сегодня широкую популярность в промышленной эксплуатации, — это работа программного инициатора с аппаратной целью. Почему так?

Всё просто. Программная реализация инициатора iSCSI распространена очень широко. Для ОС семейства Windows её предоставляет сама Microsoft, причём совершенно бесплатно. Более того, в текущее поколении ОС — т.е. Windows Vista и Windows Server 2008 — инициатор не только входит в поставку, но и установлен по умолчанию. Всё, что требуется администратору, — это взять и настроить подключение. Для предыдущих поколений Windows (начиная аж с Windows 2000 Service Pack 4) инициатор также бесплатен, но его потребуется загрузить отдельно и установить.

С противоположенной стороной — целью — всё несколько сложнее. Во-первык, к серверной части традиционно предъявляются более высокие требования по надёжности и производительности. Что является причиной высокой популярности аппаратных решений. Во-вторых, существует сразу несколько широко распространённых программных решений. У Microsoft тоже есть своя программная реализация цели iSCSI. Но дело в том, что она распространяется только на коммерческой основе, причём возможности приобрести её довольно сложно назвать гибкими.

Дело в том, что Microsoft iSCSI Software Target распространяется только в составе комплексного продукта, который называется Windows Storage Server. Это отдельное издание Windows Server, специально адаптированное для работы в роли файлового сервера. Самое большое ограничение — этот продукт распространяется только по программе OEM. То есть — через поставщиков оборудования, в составе готовых программно-аппаратных комплексов (Appliance). Иными словами, приобрести Microsoft iSCSI Software Target вы можете только в составе предустановленной ОС.

До сегодняшнего дня существовало ещё одно ограничение. Цель iSCSI была встроена только в одно, самое старшее, издание Windows Storage Server, которое называлось Windows Unified Storage Server (WUDSS) 2003. Правда, его можно было приобрести отдельно для других изданий Windows Storage Server 2003 R2. В связи с этим возникает закономерный вопрос. На дворе уже 2009 год, текущее поколение Windows Server 2008 вышло больше года назад — так где же соответствющий выпуск Windows Storage Server? Как получить современную версию Microsoft iSCSI Software Target для построения кластеров внутри виртуальных машин?

Windows Storage Server 2008

Совсем недавно единственным ответом на этот вопрос могла быть унылая рекомендация приобретать оборудование с предустановленным WUDSS 2003. Доходило даже до конфузов. Так, в одной из заметок около года назад мы упомянули предварительную версию WUDSS 2008, которая тогда носила кодовое имя «Magni». Довольно быстро эту статью пришлось убрать — оказалось, что даже о самом существовании проекта говорить не следовало.

Прошу прощения у всех читателей блога, которые попадали на пустую страницу по ссылкам на форумах или из поисковых машин. Та заметка оказась довольно популярной и востребованной. (И это — одна из причин, почему я так подробно возвращаюсь к этой теме сейчас). Теперь я восстановил её на прежнем месте. Ведь именно сегодня было, наконец, объявлено о выходе окончательной версии семейства Windows Storage Server 2008.

Я позволю себе остановиться только на одном усовершенствовании. Новая версия Microsoft iSCSI Software Target 3.2 теперь поддерживает кластеризацию самого Windows Storage Server. А значит, появилась возможность создания высокодоступного хранилища, которое предоставляется клиентам по протоколу iSCSI. Понятно, что для этого придётся каким-то образом сначала обеспечить физическое общее хранилище между самими узлами кластера Windows Storage Server. Но даже два узла обеспечат уровень доступности, вполне достаточный для большинства ситуаций. А предоставить общее хранилище для двух узлов — существенно более простая задача, чем подключить к нему все серверы, которым требуется высокая доступность.

И ещё одно интересное нововведние. Теперь Windows Storage Server будет предлагаться и на русском языке. Не мне судить о востребованности этого шага — но такое внимание, как минимум, льстит.

Надеюсь, что я так или иначе смог заинтересовать вас в программной реализации цели iSCSI и новом продукте Windows Storage Server 2008. Всю остальную информацию о его новых и улучшенных функциях вы сможете узнать из обзорных страниц по ссылкам ниже. А совсем скоро основные поставщики оборудования начнут предлагать свои решения на базе нового поколения Windows Storage Server. Более того — уже сейчас вы можете загрузить ознакомительную версию продукта через подписки MSDN и TechNet. Таким образом, у вас есть возможность протестировать именно те сценарии, которые представляют для вас наибольший интерес. Надеюсь, что одним из них обязательно станет создание кластеров из виртуальных машин — Guest Clustering.