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

Bысокая готовность в корпоративных сетях может быть реализована при помощи различных подходов и решений. К ним относятся, например, серверный кластер и сеть хранения (Storage Area Network, SAN). Однако каждый отдельно взятый подход вовсе не обязательно оказывается в состоянии удовлетворить весь спектр требований к готовности. Соответствующий дефицит восполняют расширяющие решения или комбинации различных техник. При этом для средних предприятий существует опасность, что необходимые для этого финансовые вложения превысят разумные расходы на инвестиции и администрирование. Менее затратный путь могут предложить решения по обеспечению готовности в виде программного обеспечения для серверов приложений. В статье рассматриваются основные отличия трех названных подходов.

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

SAN ОБЕСПЕЧИВАЕТ ДОСТУПНОСТЬ

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

СЕРВЕРНЫЙ КЛАСТЕР

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

Рисунок 1. Схематическое изображение серверного кластера.

Если дополнительно в кластере применяется еще и балансировка нагрузки, то в режиме нормальной эксплуатации ее можно использовать для повышения производительности соответствующих приложений. Аварийное переключение осуществляется в серверном кластере за доли секунды. Гарантом служит параллельное обслуживание виртуального IP-адреса, участие в котором может принять резервный сервер. Через этот IP-адрес доступны все API, необходимые для смены сервера. А для пользователей в сети ничего не меняется, поскольку «старый» IP-адрес исходного сервера остается действительным. Кроме того, это двойное управление IP-адресом позволяет исходному серверу позже опять взять управление на себя.

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

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

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

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

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

ВЫСОКАЯ СТЕПЕНЬ ГОТОВНОСТИ ДЛЯ МНОГИХ ПЛАТФОРМ

Однако альтернативу концепции серверной кластеризации предлагают многие специализированные программные решения для обеспечения высокой готовности, выполняющиеся на соответствующем сервере приложений (см. Рисунок 2). Этот подход обеспечивает высокую готовность как для данных, так и для приложений, и поэтому в принципе похож на серверную кластеризацию. Правда, соответствующие программные решения для обеспечения высокой степени готовности все же обладают некоторыми характерными отличиями от концепции серверных кластеров: они квазинезависимы от платформы, поскольку могут применяться на всех важнейших операционных системах — Windows NT и 2000, HP-UX, IBM, AIX, Sun Solaris или Linux.

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

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

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

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

ЗЕРКАЛИРОВАНИЕ ДАННЫХ И БАЛАНСИРОВКА НАГРУЗКИ

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

РЕЗЮМЕ

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

Вальтер Троян — консультант и специалист по маркетингу в компании Evidian. С ним можно связаться по адресу: http://www.evidian.de.