Оригинал опубликован в журнале “Системный Администратор”, 09/2009
Как можно повысить надежность информационной системы с использованием виртуализации, и какие новые возможности для этого предоставляет новая версия ОС Microsoft Windows Server 2008 R2?

Что же такое виртуализация?

Wikipedia дает определение виртуализации: «Виртуализация в вычислениях — процесс представления набора вычислительных ресурсов, или их логического объединения, который даёт какие-либо преимущества перед оригинальной конфигурацией. Это новый виртуальный взгляд на ресурсы, не ограниченных реализацией, географическим положением или физической конфигурацией составных частей». Возможно, звучит слишком сложно для неподготовленного человека, поэтому попытаемся перевести на «человеческий язык».

Разработкой решений, основанных на виртуализации, занимаются многие вендоры, я бы даже сказал – практически все. Ведь «логические диски», представляющие собой просто разделы на одном физическом жестком диске – это тоже виртуализация. Технология SMP, позволяющая представлять для программ два или более физических процессоров как один виртуальный – это тоже виртуализация. Мы же посмотрим, что под словом «виртуализация» понимает Microsoft.

В настоящее время Microsoft различает три аспекта виртуализации: виртуализация серверов, виртуализация представлений и виртуализация приложений. С виртуализацией представлений более-менее знакомы практически все системные администраторы: самый яркий ее пример – терминальные службы Microsoft Windows Server. Виртуализация приложений – создание особой, изолированной среды внутри ОС для запуска отдельных приложений, тема очень большая и интересная, для отдельной большой статьи. Здесь же и далее под словом «виртуализация» мы будем иметь в виду виртуализацию серверов. В ОС Windows Server 2008 появилась встроенная система поддержки виртуализации (гипервизор), под названием Hyper-V. В Windows Server 2008 R2 гипервизор был существенно доработан, и получил название Hyper-V 2.0.

Давайте рассмотрим подробнее виртуализацию серверов. Что же это такое? Говоря понятным языком – это создание программно-эмулируемой среды, полностью имитирующей аппаратное обеспечение физического компьютера: процессор, оперативную память, жесткий диск, устройства ввода-вывода. Далее, на такой виртуальный сервер может быть установлена ОС (которая будет называться «гостевой ОС», «Guest OS») и некие приложения. Работать все это будет как на полноценном сервере, только его будет не видно: он будет существовать виртуально, внутри ОС на физическом сервере (применительно к этой ОС используется термин «хостовая ОС», «Host OS»). При этом, внутри одного физического сервера могут одновременно работать два и более, а иногда – даже десятки таких виртуальных серверов.

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

Самое главное: использование виртуализации позволяет более рационально распределять аппаратные ресурсы серверов. Действительно, ведь большинство серверов от силы 10% от своих ресурсов – процессорных мощностей, объемов памяти и т.д. Виртуализация позволяет вместо нескольких практически не загруженных серверов использовать один сервер, который будет загружен чуть сильнее. Понятное дело, что один сервер, пусть даже чуть более мощный – будет стоить дешевле, чем несколько отдельных. Так же вполне логично предположить, что один сервер будет потреблять намного меньше электроэнергии и занимать меньше места в стойке (или на столе, или под столом – ну это уже у кого – как). Еще одно очень важное преимущество – удобство администрирования. Любой часто администратор сталкивался с необходимостью идти в серверную и произвести какие-то манипуляции непосредственно на консоли самого сервера, в случае, если он «упал». Использование виртуализации позволяет получать доступ к консолям самих виртуальных серверов непосредственно с рабочего места администратора, и необходимость в экскурсиях в серверную практически отпадает Кроме этого – сильно упрощаются операции резервного копирования и аварийного восстановления серверов. Все администраторы знают, как бывает сложно сделать рабочую резервную копию системного раздела сервера: для этого часто приходится покупать дополнительный софт (такой, как Acronis TrueImage Server) и в некоторых случаях – перезагружать сервер. Использование виртуализации позволяет создавать резервные копии дисков серверов прямо «на лету», незаметно для пользователей, а восстановление сводится всего лишь к копированию нескольких файлов.

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

Есть и еще один недостаток, касающийся лишь виртуализации на базе Windows Server 2008: аппаратные требования включают в себя 64-битный процессор с аппаратной поддержкой виртуализации и DEP. Так что, множество старых серверов с 32-битными процессорами нам попросту не подходят. Тем не менее, купить сервер, не удовлетворяющий техническим требованиям Hyper-V в настоящее время затруднительно, поскольку серверы со старыми моделями процессоров были с недавнего времени сняты с производства всеми крупными вендорами.
Требования для использования виртуализации в Windows Server 2008

Как уже говорилось, основным, и обязательным требованием для использования технологии виртуализации Windows Server 2008 Hyper-V является процессор, который обязательно должен иметь 64-битную архитектуру и обязательно – аппаратную поддержку DEP и виртуализации (Intel VT или AMD-V). Остальные требования сильно зависят от задач, которые планируется выполнять. Мощность процессоров, объем оперативной памяти и дискового пространства необходимо подбирать, исходя из необходимых мощностей для запуска нужных виртуальных машин со всеми приложениями. Сайзинг виртуальной среды – тоже очень интересная и большая тема, и возможно, в скором времени я об этом напишу.
Отказоустойчивость

В газетах писали о случае, когда в США разбился истребитель-невидимка стоимостью в 250 млн. долларов. Расследование показало, что причиной катастрофы стал выход из строя одной микросхемы, стоимостью от силы в 20 долларов. Этот случай наглядно иллюстрирует необходимость повышения отказоустойчивости всех компонент системы. Пути здесь два. Первый — повышение надежности самих компонентов (например, жесткие диски, используемые в серверах, имеют намного больший срок наработки на отказ, чем те, что используются в домашних компьютерах). Второй путь — избыточное резервирование: все, или особо критичные компоненты дублируются, например – жесткие диски работают в «зеркальном режиме» (RAID1), и при выходе из строя одного жесткого диска – сервер продолжает работать на втором диске, и замечает это только системный администратор, но не пользователи системы. Надо заметить, что эти два пути являются никак не взаимоисключающими, а наоборот – взаимодополняющими. Понятное дело, что любое повышение отказоустойчивости автоматически приводит к удорожанию всей системы, иногда – в разы, и поэтому главное здесь – найти «золотую середину». В первую очередь, необходимо оценить, к какому ущербу в денежном эквиваленте может привести отказ системы, и повышать отказоустойчивость соразмерно этой сумме. К примеру, выход из строя жесткого диска на моем домашнем компьютере, где хранятся всего лишь какие-нибудь фотографии и куча разного «информационного хлама» — не приведет к большой катастрофе, максимум – я заплачу пару сотен долларов за новый жесткий диск. Мне будет достаточно периодически сохранять важную информацию, например, на другой жесткий диск или DVD-RW. А вот в самолет стоимостью в 250 млн. долларов – совсем не помешало бы поставить не одну, а две микросхемы стоимостью в 20 долларов каждая.
Отказоустойчивые кластеры

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

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

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

Процесс Failover на примере кластера из двух узлов показан на рисунке:

failover

Процесс Failover – перенос сервиса со сбойного узла

В некоторых случаях, в зависимости от настройки, при восстановлении работоспособности сбойного узла приложения могут перемещаться обратно на него – этот процесс называется Failback:

failback

Процесс Failback – перенос сервиса после восстановления работоспособности узла
Требования для создания отказоустойчивого кластера в Windows Server 2008

Итак, что же нам нужно для создания кластера в Windows Server 2008? Во-первых, нам нужен некий разделяемый дисковый ресурс, который будет использоваться в качестве кворума, а так же для хранения данных. Это может быть любая система хранения данных (СХД), поддерживающая протоколы iSCSI, SAS или FibreChannel. Разумеется, все узлы кластера должны иметь соответствующие адаптеры для подключения СХД. Все серверы, функционирующие в качестве узлов кластера, должны иметь если не полностью одинаковое аппаратное обеспечение (это идеальный вариант), то хотя бы – процессоры одного производителя. Так же очень желательно, что для функционирования кластера желательно, чтобы все узлы кластера связывались между собой более, чем по одному сетевому интерфейсу. Он будет использоваться как дополнительный канал обмена heartbeat, а в некоторых случаях – и не только для этого (к примеру, при использовании Live Migration). Если мы собираемся использовать виртуализацию – все узлы так же должны удовлетворять системным требованиям Hyper-V (в особенности – процессоры).
Комплексное решение: виртуализация+отказоустойчивый кластер

Итак, как уже было упомянуто – решение на базе виртуализации может быть развернуто на платформе отказоустойчивого кластера. Что же нам это даст? Все очень просто: мы сможем воспользоваться всеми достоинствами виртуализации, при этом избавившись от самого главного недостатка – единой точки отказа в виде самого аппаратного сервера. В случае отказа одного из серверов, или каких-либо плановых отключений – замены железа, установка обновлений ОС с перезагрузкой, и т.д. – виртуальные машины могут быть перемещены на работоспособный узел достаточно быстро, или даже незаметно для пользователей. Таким образом, время восстановления системы после сбоя будет измеряться минутами, а плановых остановов серверов пользователи не заметят вообще. Недостаток тут один: удорожание системы. Во-первых, скорее всего придется купить СХД, которая стоит определенных, а иногда и немалых денег. Во-вторых – как минимум еще один сервер. В-третьих, для работы в составе кластера понадобится более дорогая версия ОС – Enterprise или Datacenter Edition. В принципе, это компенсируется бесплатным правом на запуск определенного количества гостевых ОС (до 4 на сервер – в Enterprise и без ограничений на сервер – в Datacenter), либо же можно использовать бесплатный продукт – Microsoft Hyper-V Server R2, в версии R2 он начал поддерживать кластеры.
Способы перемещения виртуальных машин между узлами кластера

Итак, допустим, у нас имеется кластер с запущенными виртуальными машинами. Недавно пользователи начали жаловаться, что им стало не хватать быстродействия системы. Анализ производительности показал, что приложениям не хватает оперативной памяти, и иногда – мощности процессора. Было принято решение добавить в сервер несколько модулей ОЗУ и дополнительный процессор. После того, как процессор и модули памяти пришли от поставщика – встала задача, собственно, произвести замену. Как известно, для этого необходимо выключать сервер на некоторое время. Тем не менее, пользователям надо работать, и простой даже в 10 минут чреват убытками. К счастью, мы заранее подняли кластер, и поэтому оставаться после работы нам не нужно, а надо всего лишь переместить работающие виртуальные машины на другой сервер. Как это можно осуществить? Есть три способа:

1) Move – простое перемещение виртуальной машины с одного узла на другой. Сама виртуальная машина при этом переводится в состояние Offline (через завершение работы или сохранение состояния), а затем – запускается на другом узле. Наименее простой способ, но и наиболее долгий и «чувствительный» для пользователей. Перед перемещением необходимо оповестить всех пользователей, чтобы они могли сохранить свои данные и выйти из приложений.

2) Quick Migration – содержимое оперативной памяти сохраняется целиком на диск, а затем на целевом хосте происходит запуск виртуальной машины с восстановлением содержимого памяти с диска. Пользователей опять же нужно предупредить заранее – хотя процесс пройдет значительно быстрее.

3) Live Migration – одна из самых интересных новых технологий Windows Server 2008 R2. При Live Migration происходит прямое копирование содержимого памяти виртуальной машины по сети с одного хоста на другой, минуя диски. Процесс чем-то напоминает создание теневых копий открытых файлов (VSS). Вначале копируется все содержимое памяти. Затем, в случае, если за время копирования произошли какие-либо изменения – копируется содержимое измененных страниц памяти. Процесс повторяется итеративно, до тех пор, пока содержимое областей памяти на обоих хостах не станет абсолютно идентичным. Как только это произошло – виртуальная машина тут же перезапускается на новом хосте. Файлы виртуальных дисков (VHD) хранятся на общем ресурсе, и поэтому они просто «подцепляются» на новом хосте. Весь процесс перезапуска занимает доли секунды, меньше, чем таймаут TCP-соединения, и поэтому пользователи вообще ничего не замечают. Таким образом, все запланированные работы, требующие останова системы можно проводить и в нормальное рабочее время, не отвлекая пользователей от работы.

Необходимо так же отметить, что любой из перечисленных способов, и Live Migration в том числе – являются штатными возможностями Windows Server 2008 R2, и не требуют для использования покупки каких-либо дополнительных программных продуктов и лицензий каждая установленная ОС на виртуальной машине так же требует лицензий.
Заключение

Виртуализация серверов позволяет использовать один сервер там, где раньше приходилось использовать десять. Разумеется, это позволит хорошо сэкономить практически на всем: и на «железе», и на лицензиях ПО, и на накладных расходах. Тем не менее, при использовании виртуализации сильно падает общая надежность системы. В этой статье мы познакомились с тем, как повысить надежность такой системы за счет использования отказоустойчивых кластеров. Следующая статья будет целиком посвящена одной из «изюминок» Windows Server 2008 R2 – Live Migration. Будет рассказано о типовых сценариях использования Live Migration, и дано практическое руководство по развертыванию «шаг за шагом».

(источник http://itband.ru/2009/09/reliability-virtualization/)