Оглавление (стр. 4 )

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

Крайне желательна в аппаратных кластерах внешняя память со средствами зеркалирования (mirroring storage) для защиты от сбоев среды хранения данных. Например, в случае простого двух узлового кластера совместно используемая внешняя память может состоять из диска с двумя портами (dual-ported disk), к которому можно обращаться обоих узлов. В этом случае также могут быть нужны специальные кабели для соединения сетевых карт/коммутаторов/хабов.

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

Но ни один из этих двух (холодное, горячее) способов резервирования не исправляет повреждения корневой файловой системы (root file systems). Для разрешения этой проблемы в аппаратных кластерах иногда используют свои собственные загрузчики (boot drive), либо средства зеркалирования, реализованные на уровне аппаратуры.

Так как приложения часто становятся недоступными в результате сбоев дисков, то системные администраторы, как правило, используют запасные серверы со средствами зеркалирования дисков, а также технологию RAID (Redundant Arrays of Independent Disks). В этом случае информация хранится на нескольких дисках, которые являются зеркалами друг друга.

Важно понимать особенности различных архитектур аппаратных кластеров:

В архитектуре с совместно используемой оперативной памятью (shared-memory architecture) множество процессоров используют общую шину памяти, такие системы определяются как SMP-системы. В этой архитектуре пропускная способность шины часто становится проблемой по мере добавления узлов.

В архитектуре с совместно используемыми дисками (shared-disk architecture) множество SMP-серверов совместно используют дисковую память для повышения уровня готовности.

Архитектура без разделения ресурсов (shared-nothing architecture) предполагает, что у каждого узла своя собственная оперативная память, свои диски и процессоры. Преимуществом такого подхода является задействование большей пропускной способности по мере добавления узлов.

С течением времени аппаратные кластеры постепенно развиваются. В 80-х годах использовались векторные системы. Затем наступила эра суперкомпьютеров и MPP-систем, а теперь используются кластеры и сети распределенных вычислений (grids). Ряд поставщиков предлагают конкурирующие между собой платформы с различными уровнями поддержки для перечисленных выше архитектур аппаратных кластеров, а также параллелизма, чтобы сделать аппаратные кластеры реальностью. Но по прежнему создание больших аппаратных кластеров с N узлами требует тщательного продумывания и планирования, и немалого бюджета.

Кластеры с балансировкой нагрузки

Технологии аппаратной кластеризации называются стратегиями “пещерного человека” ("caveman"), потому что они не очень развиты, наиболее легки в применении и дешевы. Если одна их них используется как единственное кластеризированное решение, то оно применимо только для простейших приложений типа презентаций. “Пещерная” кластеризация предполагает использование множества узлов (серверов с идентичными установками вашего приложения) плюс некая дополнительная аппаратура на серверных узлах для управления и распределения нагрузки.

Например, наиболее простая “пещерная” технология – это циклическая (round-robin) служба доменных имен DNS (domain name service), которая использует маршрутизатор и DNS-сервер для циклической рассылки различных пользовательских запросов по всем серверам приложений, так что ни один узел не отягощается Так как у каждого узла есть свой IP-адрес, то легко ввести последовательные URL справочные DNS-файлы и связать их с адресами всех узлов: с 143.10.25.1, с 143.10.25.2 и т. д.

Маршрутизатор затем распределит пользовательские запросы по списку URL циклическим образом. Масштабирование в этом случае реализуется достаточно легко: чтобы добавить новый сервер, просто дайте ему последовательный URL в справочном файле DNS-сервера и затем прикрепите этот URL к IP-адресу нового сервера.

Следующим шагом за циклической DNS было применение IP-распределителя (sprayer), устройства подобного маршрутизатору, которое располагается между входящими (inbound) пользовательскими запросами и узлами серверов приложений. Этот метод похож на циклическое решение, за исключением того, что IP-распределители “разбрасывают” или перенаправляют запросы к нескольким узлам. IP-распределители более динамичны и менее произвольны в выборе, чем циклические маршрутизаторы, так что недозагруженнные серверы могут быть использованы более эффективно. Однако, IP-распределители требуют применения SSL-декодеров в случае использования протокола SSL (Secure Sockets Layer - протокол защищенных сокетов, гарантирующий безопасную передачу данных по сети).

Еще одной аппаратной альтернативой является применение реверсивных прокси (reverse-proxy) HTTP-серверов, которые используются в основном как защита от атак злоумышленников, но могут применяться и для балансировки нагрузки. Это способ требует использования кэширования, как правило, связываемого с доступом к Web-страниц в оперативной памяти HTTP-серверов, чтобы снять нагрузку, насколько это возможно, с узлов серверов приложений. Реверс-прокси метод требует использования циклической кластеризации, чтобы предохранить HTTP-серверы от перегрузки.

Другие способы балансировки нагрузки – это единый IP-образ на стороне сервера (server-side single IP image) и трансляция сетевых адресов (network-address translation); оба эти способа дороже и сложнее и требуют изменений заголовков пакетов на основе особенностей нагрузки.

Проблемы отказоустойчивости кластеров с балансировкой нагрузки

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

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

Для “пещерных” систем характерны высокие цены. Технология RAID требует много устройств для работы с дисками, и эти расходы быстро растут по мере масштабирования как ваших приложений, так и самого кластера. Время простоя пользовательских приложений может слишком дорого стоить, особенно для жизненно-важных приложений.

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

Программные решения: Web-кэшированная кластеризация

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

Создание кластеров на базе Oracle9iAS Web Cache – это замечательный пример использования программного обеспечения для преодоления сбоев и управления трафиком приложений. Web-кэш предшествует узлам-серверам и подобно обычному кэшу отвечает на все входящие HTTP-запросы и распределяет эти запросы согласно возможностям каждого Web-сервера. В гипотетическом кластере, состоящем из серверов A, B и C, мы сможем сконфигурировать Web Cache для распределения 30% всей нагрузки к Web-серверу A, других 30% к Web-серверу B и 40% к Web-серверу C.

Подобно технологии реверс-прокси сервера, данное решение обладает тем же ключевым преимуществом: если один из этих трех серверов выйдет из строя, Oracle9iAS Web Cache сможет автоматически перераспределять 50% нагрузки по двум остающимся в строю Web-серверам. Когда же засбоивший сервер вернется в строй, Web Cache вновь перераспределит нагрузку по всем трем серверам, и все это будет незаметно, прозрачно для пользователя.

Oracle9iAS Web Cache также поддерживает состояние сессий, не обременяя узлы серверов приложений. Он также обслуживает сайты, которые используют идентификаторы сессии (session ID) и жетоны (cookies). Но поддержка состояния сессий на уровне Web-сервера может быть обременительна, и лучшим решением будет обеспечение минимального, насколько это возможно, набора параметров состояния сессий и только на очень короткие промежутки времени. Для более долгих сессий и больших наборов подобных параметров стоит рассмотреть применение базы данных.