Управление виртуальными ресурсами

Рожденная Internet

На вторую половину 90-х годов пришелся расцвет всевозможных доткомов, виртуальных магазинов, Internet-банкинга. В Сети стали вращаться вполне реальные деньги. Неспособность Web-сервера справиться с нагрузкой или его отказ получили реальное денежное выражение. Как следствие, появилась необходимость в создании надежных высокопроизводительных систем, способных обслуживать клиентов в режиме "24 7 365".

Наиболее эффективным решением этой проблемы оказалось не использование высокоуровневых серверных систем, а создание группы из недорогих компьютеров и распределение между ними нагрузки. Вот здесь и возникла потребность в инструменте, способном превратить серверную группу в единый виртуальный ресурс (Virtual Resource — VR) с необходимыми свойствами.

Как реакция на спрос появилось и предложение. В 1997—98 гг. целый ряд производителей — известных (Cisco, IBM) и не очень (Alteon, Resonate, F5 Networks) — представили продукты, реализующие технологию балансировки нагрузки серверов (Server Load Balancing — SLB) и ориентированные, в основном, на Web-сервис.

Однако быстро выяснилось, что SLB может быть эффективно применена и для других
TCP/UDP-сервисов, а также использована для распределения нагрузки между такими
устройствами, как маршрутизаторы, брандмауэры, кэш-серверы. По этой причине консалтинговая
компания Acuitive предложила
более общее название технологии: управление виртуальными ресурсами (Virtual
Resource Management — VRM). Acuitive определяет VRM как "метод представления
конечному пользователю множества сетевых устройств в виде единого устройства".

VRM-системы: путь к совершенству

Основополагающая идея VRM очень проста:
поток запросов направляется на расположенный между клиентами и серверной группой
менеджер виртуальных ресурсов (или, более кратко, диспетчер), который
интеллектуально распределяет его между серверами (рис. 1). Интеллектуальность
заключается в учете производительности, текущего состояния и загрузки отдельных
серверов, типа запроса, принадлежности клиента к той или иной группе и т. д. С
точки зрения клиентов сервис предоставляется непосредственно диспетчером по единственному
виртуальному IP-адресу (Virtual IP — VIP), т. е. структура и состав VRM-системы
от них полностью скрыты.

Что же дает практическая реализация этой, на первый взгляд, нехитрой идеи?

Масштабируемость. Хорошая масштабируемость — это нечто большее, чем создание системы требуемой мощности "здесь и сейчас". Это возможность поддерживать нужные характеристики на протяжении длительного времени в условиях возрастания нагрузки в десятки раз. Есть два пути решения этой проблемы. Первый — вертикальное масштабирование — заключается в замене аппаратуры на более производительную по мере необходимости. Однако здесь сразу же возникает ряд непростых вопросов. Существует ли вообще в природе сервер с требуемым быстродействием, и если да, то сколько он стоит? Даст ли применение нового оборудования реальное увеличение производительности или начнут сказываться встроенные ограничения операционной системы и прикладного ПО? Как произвести замену, если обслуживание клиентов нельзя прекратить даже на несколько минут?

Альтернативный путь — горизонтальное масштабирование, реализуемое с помощью VRM
(рис. 2). Нагрузка растет? Достаточно добавить к VRM-системе еще несколько недорогих
"средних" (на данный момент) серверов, и диспетчер тут же использует
этот дополнительный ресурс для увеличения производительности виртуальных сервисов.

Высокая доступность. Уровень доступности определяется долей времени, в течение которого система выполняет свои непосредственные функции. Например, доступность 0,99% означает, что система не работает около трех с половиной дней в год. О высокой доступности можно говорить, начиная как минимум с "трех девяток" (0,999%).

На практике достижение этого уровня требует применения специальных средств, из которых наиболее известны отказоустойчивые (Fault Tolerance — FT) и высокодоступные (High Availability — HA) кластеры. И дело здесь не только в отказах оборудования. Частой причиной недоступности сервиса являются административные простои, связанные с проведением профилактических работ, обновлением версий ПО и т. п. Вполне очевидно, что в случае одиночного сервера этих простоев не избежать, и заветные "девятки" недостижимы.

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

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

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

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

Анатомия VRM

Итак, пришло время "заглянуть под
крышечку" черного ящика с названием "менеджер виртуальных ресурсов".
Под ней скрывается достаточно сложный механизм, структура которого схематично
представлена на рис. 4. Ясно видны три основных блока: механизм перенаправления
сессий, блок выбора реального сервера и система мониторинга.

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

Все выше, и выше, и выше: L3, L4, L7

Этот механизм основывается на технологии, получившей название коммутации 4-го и 7-го уровней (L4/L7-коммутация). За цифрами скрывается очень простой смысл — они соответствуют уровню модели OSI, на котором работает устройство. Практически все знакомы с Ethernet-коммутаторами. Сейчас их все чаще называют коммутаторами уровня 2 (L2), подчеркивая, что они функционируют на канальном уровне. Появившиеся в середине 90-х коммутаторы работают уже на сетевом уровне (L3), фактически выполняя функции маршрутизаторов. L4/L7-коммутаторы работают на еще более высоком уровне, извлекая информацию из заголовков транспортных (TCP/UDP) и прикладных (HTTP, FTP, SMTP и т. д.) протоколов.

Неудивительно, что в начале 70-х создатели TCP/IP не могли предвидеть всех возможных
применений этого семейства протоколов и включить в него механизмы перенаправления
сессий. Как следствие, L4/L7-коммутаторам приходится идти на некоторые "хитрости"
(рис. 5), чтобы добиться нужного эффекта без модификации TCP/IP-стеков клиента
и сервера.

На 4-м (транспортном) уровне используются два механизма, позволяющих перенаправить клиентскую сессию выбранному реальному серверу, — это NAT (Network Address Translation, трансляция сетевых адресов) и MAT (MAC Address Translation, трансляция адресов канального уровня). В случае NAT диспетчер, получив запрос на установление сессии, подменяет адрес получателя с VIP на адрес выбранного сервера и пересылает полученный IP-пакет ему. Та же процедура выполняется со всеми последующими пакетами, принадлежащими данному соединению. Ответные пакеты, проходя через диспетчер, также подвергаются модификации — адрес источника изменяется на VIP. Таким образом, у клиента создается впечатление, что он работает непосредственно с диспетчером, хотя на самом деле его запросы обслуживает один из серверов кластера. Наиболее существенным недостатком NAT является повышенная нагрузка на диспетчер, так как модификация IP-адресов требует перерасчета контрольных сумм.

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

L7-коммутаторы применяют другой метод перенаправления, называемый транзитом TCP-соединений или отложенным связыванием (delayed binding). Он позволяет проанализировать прикладной запрос еще до выбора реального сервера. Суть метода очень проста: диспетчер самостоятельно принимает транспортное соединение, получает и анализирует запрос, выбирает сервер, устанавливает с ним соединение уже от своего имени, передает ему запрос и в дальнейшем обеспечивает прозрачную передачу данных между клиентом и сервером.

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

Распределение нагрузки: от каждого по способностям

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

Часто используемыми алгоритмами распределения являются циклическое (round-robin) и распределение по минимуму соединений (least-connections), а также их взвешенные (weighted) варианты. В первом случае новый запрос передается возглавляющему очередь серверу с последующим его перемещением в конец. Во втором выбирается сервер, обслуживающий в данный момент минимум соединений. Существуют и более сложные алгоритмы, учитывающие особенности прикладного протокола или использующие подробную информацию о состоянии серверов.

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

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

Активный мониторинг существует в нескольких вариантах: выполнение диспетчером тест-запросов с последующим анализом характеристик ответа; получение информации от функционирующей на реальном сервере программы-агента; взаимодействие с централизованной системой мониторинга. Преимуществом активного мониторинга является более оперативная и подробная информация о состоянии серверов.

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

На вкус и цвет…

В настоящее время на рынке предлагаются три класса продуктов, выполняющих функции менеджера виртуальных ресурсов: аппаратные (коммутаторы/маршрутизаторы с функциями L4/L7-коммутации), программно-аппаратные (компьютеры с предустановленным ПО) и программные.

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

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

К сожалению, потенциальный отечественный потребитель технологии VRM будет неприятно
удивлен стоимостью оборудования — для зарубежных разработок она начинается с
отметки $5000—7000 и составляет десятки тысяч долларов для старших представителей
модельных рядов. Решить ценовую проблему можно, попытавшись самостоятельно собрать
диспетчер из "кубиков" open-source (www.linuxvirtualserver.org,
www.linux-ha.org, www.keepalived.org)
либо же использовать более дешевые отечественные разработки.