Консолидация нескольких физических серверов при помощи виртуальных машин предъявляет новые требования к готовности: отказ физического сервера затрагивает и работающие на нем виртуальные машины.

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

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

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

ВАРИАНТ 1

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

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

Целесообразность такого подхода сомнительна, поскольку подобные кластеры не предоставляют никакой защиты от отказа серверного аппаратного обеспечения, а выход из строя физического сервера может привести к общесистемному отказу (Single Point of Failure, SPOF). Тем самым эта концепция нарушает один из важнейших принципов в области высокой готовности — устранение всех потенциальных точек отказа. Кроме того, из-за использования только одного физического сервера приходится отказаться от прочих преимуществ, которые обычно предлагает кластер высокой готовности: к примеру, от проведения на кластерном узле работ по обслуживанию без остановки кластера. Возможно, данная комбинация будет востребована в качестве тестовой платформы для кластеров высокой готовности, однако вряд ли подойдет для практического применения.

ВАРИАНТ 2

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

Рисунок 2. Если кластер организован между виртуальными машинами на разных физических серверах, то при отказе одного физического сервера можно продолжать пользоваться приложениями.

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

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

ВАРИАНТ 3

Физический сервер — виртуальная машина. В этом случае кластер высокой готовности организуется между физическим сервером (активный узел) и виртуальной машиной (пассивный узел) (см. Рисунок 3). Менеджер кластера выполняется на физическом сервере непосредственно в операционной системе и на виртуальной машине на другом узле.

Рисунок 3. Кластер между физическим сервером и виртуальной машиной дает возможность сэкономить, если пассивные узлы разных кластеров работают на одном физическом сервере.

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

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

К тому же процессы обновления систем, а также резервного копирования и восстановления данных для отдельных узлов кластера могут весьма отличаться.

ВАРИАНТ 4

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

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

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

ВАРИАНТ 5

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

Рисунок 5. Кластер между двумя физическими серверами подходит в первую очередь при использовании виртуализации операционной системы.

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

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

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

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

ВОЗМОЖНЫЕ ОГРАНИЧЕНИЯ

Имеющиеся на рынке продукты для реализации кластеров высокой готовности предъявляют разные требования к серверам, сетям и системам хранения данных. Виртуальные среды подходят не для всех случаев. Так, к примеру, с осторожностью следует относиться к «изоляции» (fencing). Эта технология предотвращает одновременный доступ нескольких кластерных узлов к важным ресурсам (к примеру, если файловые системы не поддерживают работу с кластерами).

Один из способов достижения це-ли — изоляция узла, когда весь кластерный узел исключается из кластера при помощи технологии блокирования (Shoot The Other Node In The Head, STONITH — дословно: «выстрели другому узлу в голову»). Этот метод не годится, если на одной физической аппаратной системе используются несколько виртуальных машин из разных кластеров. В такой ситуации STONITH исключил бы из кластера сразу несколько «виртуальных» кластерных узлов.

Другой состоит в изоляции ресурсов. Метод гарантирует эксклюзивный доступ к важным ресурсам и на практике часто реализуется при помощи резервирования SCSI-2/SCSI-3. Применительно к виртуализации администратор должен следить за тем, чтобы эти резервирования действительно функционировали в виртуальном пространстве. Проблемы появляются при построении кластера с кластерным менеджером, который на одной стороне работает в операционной системе виртуальной машины, а на другой — непосредственно на физическом сервере.

БУДУЩЕЕ

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

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

ЗАКЛЮЧЕНИЕ

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

Христоф Миташ и Вернер Фишер много лет занимаются кластерами высокой готовности и системами хранения данных. После обучения в области компьютерной безопасности и двух лет работы на IBM они отвечают за разработку кластеров в компании Томаса Кренна.

? AWi Verlag