Распределение нагрузки с помощью коммутатора

Максим Немков

В течение последнего этапа развития вычислительных сетей системные администраторы направили все силы на борьбу с так называемыми узкими местами в сети. Коммутирование с помощью технологий Fast Ethernet и Gigabit Ethernet, функционирующих на втором и третьем уровнях модели OSI, является мощным средством для устранения «узких мест» в сетевой инфраструктуре. Сети сейчас настолько развиты, что пользователь практически не видит разницы, работает ли он на консоли сервера или в клиентском приложении на рабочей станции. Рост скорости Ethernet должен временно прекратиться — современная сеть уже работает намного быстрее, чем того требует производительность компьютеров.

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

Подходящей альтернативой кажется поддержка различных служб разными серверами — WWW на одном сервере, FTP на другом, базы данных на третьем. Однако такой метод никак не сказывается на надежности сервиса — если «лег» news-сервер, никто так и не сможет прочитать новости. Кроме того, увеличение только количества серверов не повысит производительность службы: WWW-сервер не сможет быстро обрабатывать запросы пользователей, если зашкаливает счетчик использования процессора. Даже когда серверы подключены к сети через коммутатор Gigabit Ethernet — как распределить трафик между ними?

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

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

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

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

Технология load balancing основывается на третьем и четвертом уровнях модели OSI — базовой процедурой являлось оперирование информацией, полученной из заголовков пакетов этих уровней (номер порта TCP, IP-отправитель/получатель и т.д.). Такой метод распределения трафика назвали session switching (сеансовое коммутирование), а устройство, реализующее ее, — сеансовым коммутатором.

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

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

Коммутатору присваивается виртуальный (virtual) IP-адрес для каждой из затребованных служб в сети. Затем VIP-адрес регистрируется в DNS. В нашем случае dvlp.krsk.mps — доменное имя VIP-адреса, реально же кластер состоит из трех серверов.

При поступлении запроса от клиента сеансовый коммутатор распознает начало сеанса путем идентифицирования TCP-пакета типа SYN. Затем коммутатор выбирает наилучший для обработки сеанса сервер в кластере и «привязывает» сеанс к серверу (информация о привязках каждого активного сеанса к реальному серверу запоминается в таблице) путем замены MAC-адреса коммутатора на MAC-адрес реального сервера на третьем уровне OSI (data-link) и подстановки IP-адреса реального сервера в поле «адрес получателя» пакета на четвертом (сетевом) уровне.

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

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

Важнейшим вопросом является распознавание лучшего, наиболее приемлемого сервера для приема сеанса. Для этого используется несколько алгоритмов распределения:

1. Простой (simple round-robin) — сеансы делятся поровну между серверами, независимо от их конфигурации, загрузки и т.п.
2. Распределение «по весу» (weighted round-robin) — более мощные серверы получают большее количество соединений с клиентами.
3. Наименьшее количество соединений — полученный коммутатором запрос на сеанс перенаправляется на сервер, с которым в данный момент установлено наименьшее количество соединений.
4. Процентное распределение — администратор на основе собственного опыта конфигурирует загруженность каждого сервера в процентах либо в долях от общего трафика, поступающего на коммутатор, соответственно вычислительной мощности сервера.

Имеется также еще один критерий распределения загрузки — максимальное количество соединений, который служит хорошим дополнением к алгоритмам распределения. Если максимальное количество соединений для сервера достигнуто, коммутатор вычеркивает этот сервер из списка «претендентов» на получение сеанса.

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

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

Следующим шагом в развитии технологии «load balancing» стало появление коммутаторов, функционирующих на седьмом уровне модели OSI — на уровне приложения. То есть сейчас коммутатор знает не только информацию о номере порта, получателе/отправителе пакета, но и видит содержимое пакета.

Давайте рассмотрим примеры применения данной технологии. Структура сегмента, приведенная на рис. 1, представляет модель № 1 — «Один виртуальный сервер — несколько реальных серверов». Имеется несколько серверов, подключенных через коммутатор/концентратор к распределителю загрузки, распределитель имеет IP-адрес 10.88.100.66. Серверы имеют адреса 10.88.100.80, 10.88.100.81 и 10.88.100.82. Весь сетевой трафик, направленный к адресу 10.88.100.66, распределяется между тремя указанными серверами. Требуется одно имя в доменной системе имен. Такая конфигурация актуальна, когда следует распределить сетевой трафик одного сервера на несколько серверов — значительно повысится скорость обработки пользовательских запросов. К тому же данная схема является отличным примером достаточно надежной резервной технологии — при отказе одного из серверов не произойдет потери функциональности.

Схема является типичной, но имеет несколько вариаций. В первом варианте модели (рис. 2) основной задачей является распределение сетевых пакетов по типу. Иными словами, сервисы предприятия можно разделить между несколькими станциями, хотя все будут думать, что для поддержки любых сервисов требуется один сервер. Рисунок наглядно иллюстрирует использование распределителя в этой роли. Такой прием имеет практическое значение в крупных корпоративных сетях, где общение администраторов с пользователями несколько затруднено из-за большого количества этих самых пользователей. Также распределение трафика по содержанию пакетов имеет смысл тогда, когда администраторы несколько ограничены в вычислительных ресурсах и используют один из серверов, один сервер для служб, работающих по протоколу telnet (конфигурация компьютера может быть даже P100/16RAM), другой — для WWW (более мощная станция).

Следующим шагом развития этой модели стало разделение сетевого трафика между серверами таким образом, что основной критерий — это мощность сервера в кластере. Важным преимуществом такой схемы является возможность предотвращения сбоев серверного оборудования в результате из лишней нагрузки. Например, имеется серверный пул, в нем три станции — P100/16RAM, PII-350/64RAM и PIII-600/512RAM. Нагрузку можно разделить в процентном либо в долевом соотношении (по опыту — в первом приближении «вес» следует разделять в соответствии с тактовой частотой процессора, учитывая также количество RAM).

Таблица 1

Модель № 2 — «Много виртуальных серверов — один реальный сервер». Такая структура подходит для организации WWW-сервера. На рис. 3 изображен распределитель загрузки с виртуальными адресами 10.88.100.66, 10.88.100.67, 10.88.100.68. доменные имена — соответственно dvlp.krsk.mps, saint.krsk.mps. Реальный сервер всего один — его адрес 10.88.100.80, и к разным TCP-портам привязаны WWW-каталоги, соответствующие каждому доменному имени. То есть распределитель загрузки способен перенаправить сетевой трафик, направленный к имени dvlp.krsk.mps, порт 80, — на сервер 10.88.100.80, порт 13001. Рис. 3 и таблица, приведенная ниже, показывают данный процесс более наглядно.

Таблица 2

Модель № 3 — это гибрид двух предыдущих схем: «Несколько виртуальных серверов — несколько реальных серверов». Приведенный ниже пример показывает, как можно организовать распределение трафика между несколькими виртуальными и реальными адресами таким образом, чтобы обращения к виртуальному серверу разбивались между несколькими серверами, но на одинаковые порты.

Модель № 4 — схема для поддержки нескольких серверных кластеров. Коммутатору присваивается два или более IP-адресов (в соответствии с количеством кластеров), и далее весь трафик, направленный на виртуальный IP-адрес коммутатора, распределяется между серверами соответствующего кластера.

Таблица 3

Рассмотренные схемы предназначены для распределения нагрузки между серверами. Однако всегда существует вероятность сбоя в работе любого оборудования. Это же относится и к сеансовым коммутаторам. Существует типовой метод обеспечения повышенной отказоустойчивости для предотвращения останова сервиса в случае отказа распределителя (рис. 4).

Заключение

Приведенные примеры систем с распределением нагрузки по своей сути не являются полноценными кластерами. Однако решение распределения нагрузки на серверы, маршрутизаторы или межсетевые экраны на основе коммутаторов, поддерживающих технологию load balancing, отличается достаточной привлекательностью и представляет собой известный компромисс между повышением производительности (вычислительных мощностей) и отказоустойчивости. Естественно, что большинство таких коммутаторов поддерживают технологии резервирования для достижения достаточной отказоустойчивости, обеспечивают постоянство соединений, а также позволяют распределять запросы на несколько потоков. Несомненно, такой набор качеств удовлетворит многих пользователей, которым требуется быстро и недорого нарастить мощности, например, Web-узла. Тем более что на выбор им предоставляется продукция практически всех ведущих сетевых вендоров, таких как Cisco, Foundry, RadWare, Cabletron, Alteon и других.

Таблица 4

КомпьютерПресс 10'2000