Технология Клиент-Сервер 2003'3

Home Поиск Издания Контакты k-press.ru


Продолжается подписка на наши издания! Вы не забыли подписаться?

Практическое упражнение с набором средств для распределённых решений**

Синг Ли (westmakaha@yahoo.com) Wrox Press, июль, 2003.

Когда платформа J2EE была «доведена» до ума, она открыла возможность развёртывания серверов в сетевые кластеры для представления Web-сервисов и Web-приложений в Web-слое. Эти серверы, объединённые в локальную сеть, могут являться относительно недорогим кластерным решением. Последним кусочком кластерной головоломки является программное обеспечение. В этих сериях я протестировал три пакета, поставляемых с открытым исходным кодом, в надежде найти высокопроизводительное решение для кластера Web-слоя. Тестирование я начал с пакета JavaGroups.

Распространение электронной коммерции породило необходимость одновременного обслуживания тысяч пользователей. В условиях жесткой конкуренции online-магазин, "падающий" от наплыва покупателей, просто не выживет. В то время как масштабируемые решения для транзакционного слоя J2EE-модели (баз данных, мониторов транзакций, очередей сообщений и т.д.) широко распространены, решения для масштабирования Web-приложений или сервисов на Web-слое только начинают появляться. В этой статье мы рассмотрим популярную open source-среду JavaGroups, которая может быть использована для масштабирования Web-приложений.

Масштабирование приложений Web-слоя

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

Рисунок 1. Масштабирование Web-слоя
на одном SMP-сервере.

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

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

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

Кластеры, что называется, "попали в струю" благодаря набору взаимосвязанных факторов:

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

Конечно, "правильное железо" – это только половина истории. Вместо создания собственного сетевого коммуникационного ПО для каждого конкретного случая, правильным представляется поиск некоторого общего "клея", служащего для объединения серверов в кластер. Это растущая область практических исследований, которая собственно и может сделать кластеры дешевых серверов реальностью. Однако прежде, чем разбираться, каким образом JavaGroups может служить таким "клеем", разберем подробнее проблему масштабирования Web-слоя.

Рисунок 2. Масштабирование Web-слоя
с помощью кластера серверов.

Проблема масштабирования Web-слоя

Представьте покупателя онлайн-магазина. Он просматривает каталоги и помещает несколько предметов в "корзину". Обычно реализация "корзины" управляет серверной сессией. Ключ к сессии либо хранится клиентским броузером как cookie, либо в виде URL с присоединенным ID сессии. Последовательные запросы от его броузера будут возвращать этот ID, заставляя сервер поддерживать данную сессию. Одновременно пользоваться магазином может множество покупателей, и сервису онлайн-магазина вынужден будет поддерживать все их сессии. Предположим, что все эти сессии не персистентны, а хранятся в памяти соответствующим Web-сервисом.

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

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

Чтобы понять, как работает такая репликация, и почему несколько open source-серверов приложений уже выбрали для этого JavaGroups, давайте рассмотрим JavaGroups подробнее...

**Полный текст статьи можно найти в печатном варианте журнала

Copyright © 1994-2016 ООО "К-Пресс"