Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Коммутаторы Web: руководство для покупателя

Лори Маквитти

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

В конце 90-х годов, когда технология балансирования серверной нагрузки получила повсеместное распространение, наиболее эффективным механизмом управления трафиком считался механизм, основанный на номерах портов назначения пакетов. В те времена Web-коммутация сводилась к простому распределению по серверам всего трафика, адресуемого, например, порту с номером 80. Затем в чью-то голову внезапно пришла мысль, что было бы неплохо дифференцировать трафик не только по номерам портов, но и по конечным пунктам назначения пакетов — универсальным идентификаторам ресурсов (Universal Resource Identifier — URI).

Но в те годы уже существовали решения виртуального хостинга Web-узлов, которые позволяли учитывать идентификаторы URI при распределении трафика. Хотя подчас сразу шести и более Web-хостам мог назначаться один и тот же IP-адрес, Web-сервер правильно определял, какому из хостов предназначался запрос, и направлял его туда. Каким образом он это делал? Разумеется, просматривая заголовок пакета с запросом.

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

Однако компании Cisco Systems (купившая фирму ArrowPoint Communications), F5 Networks, Foundry Networks и Nortel Networks (купившая фирму Alteon WebSystems) предложили другую идею, действительно очень разумную. Их коммутаторы, которые могут управлять трафиком на уровне 7 — прикладном уровне модели OSI, — обеспечат, таким образом, оптимизацию работы серверных комплексов посредством маршрутизации запросов с учетом их информационного наполнения и предоставляемых сервисов.

Итак, теперь вы знаете, какими преимуществами обладают коммутаторы контента. Но как же выбрать один продукт из множества предлагаемых производителями? Сегодняшний рынок буквально завален коммутаторами производства фирм Cisco Systems, F5, Foundry и Nortel Networks, а также таких компаний, как ClickArray Networks, Extreme Networks, HydraWeb Technologies, Intel, NetScaler — и этот список можно продолжать и продолжать. Так что же должно стать критерием выбора нужного вам коммутатора в столь затруднительной ситуации?

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

Логические операции

Наиважнейшей характеристикой любого коммутатора контента является возможность определения логических операций и правил обработки трафика. Без нее эти устройства превратились бы в обычные балансировщики серверной нагрузки. Именно правила позволяют коммутаторам контента “привязывать” образцы указателей URL к тем или иным кластерам или пулам серверов. Одним из таких правил может быть, например, следующее: “Все, что содержит расширение .cgi, направляется к кластеру Х, а остальное — к кластеру Y”.

Используемые в разных коммутаторах методы конфигурирования данного правила могут весьма существенно различаться. Как показал наш опыт работы с коммутаторами контента, продукт Big-IP HA+ компании F5 Networks обладает самыми мощными функциональными возможностями конфигурирования правил. Так, использование простой синтаксической конструкции вида if-then-else позволяет обойтись одним правилом вместо двух. Другие производители коммутаторов предоставляют альтернативные методы задания правил, основанные, например, на образцах суффиксов/префиксов и регулярных выражений, или на более глубоком анализе передаваемых пакетов. В частности, продукт XML Director* фирмы Intel позволяет определять правила, основываясь на указателях URL или тегах, обнаруженных в файлах формата XML.

Есть и другие возможности определения логики работы коммутатора, на которые следует обратить внимание. Это использование операции логического отрицания и назначение порядка очередности применения правил (precedence). Последнее позволяет устанавливать порядок, в соответствии с которым правила должны применяться к запросу. Именно так используются два правила в вышеприведенном примере: сначала применяется правило, которые относится ко всем запросам с расширением .cgi, и только потом — правило, относящееся ко всем остальным запросам. При отсутствии возможности упорядочения правил данная простая конструкция выглядела бы куда более громоздкой и сложной.

Поддержка постоянных соединений (persistence) часто необходима приложениям, в которых балансировщик нагрузки играет роль внешнего интерфейса (front end). Если “виртуальная тележка покупателя” была сформирована сервером Х кластера Y, то в процессе покупки клиент обязан продолжать взаимодействовать именно с этим сервером. Многие производители коммутаторов поддерживают постоянные соединения посредством маркеров cookie.

Большинство коммутаторов просто просматривают cookie. Однако в продукте WebOS 9.0 фирмы Nortel предусмотрен механизм вставки маркеров самим коммутатором. Ранее в решениях, ориентированных на электронную коммерцию, использовались идентификаторы сеансов SSL, но появление последней версии браузера Microsoft Internet Explorer (в которой по умолчанию каждые две минуты выполняется повторное согласование параметров сеанса SSL, а следовательно, и его идентификатора) поставило под сомнение целесообразность их применения для поддержания постоянных соединений.

Можно, конечно, использовать для этого и поле IP-адреса отправителя (Source IP) пакетов, но здесь возникают проблемы, обусловленные наличием proxy-серверов и трансляцией сетевых адресов (Network Address Translation — NAT): многие клиенты оказываются привязанными к одному серверу кластера, что приводит к неравномерному распределению нагрузки.

Когда правила сконфигурированы, их нужно привязать к конкретному кластеру или серверу. Обычно для этого применяют три метода. Два из них позволяют связывать конкретное правило с одним из кластеров. При этом либо правило привязывается к кластеру, либо кластер привязывается к правилу. Компания F5 использует первый метод, компания Foundry — второй. Третий метод, применяемый фирмами Intel и Nortel, является весьма громоздким и трудоемким — он привязывает правила непосредственно к отдельным серверам. Если ваш кластер слишком велик, этот метод может оказаться не в меру обременительным для вас. Тем не менее он позволяет легко удалять или добавлять серверы для обработки специфических запросов. Таким образом, этот метод может оказаться более предпочтительным в тех случаях, когда требуется быстрое переконфигурирование кластера.

Отказоустойчивость

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

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

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

Резервирование через сеть является более сложным процессом и часто подразумевает использование протокола маршрутизации OSPF (Open Shortest Path First), что делает его более продолжительным. Это объясняется тем, что, когда первичное устройство перестает отвечать на запросы, маршрутизатору приходится корректировать свою таблицу маршрутизации. Однако при реализации глобальной архитектуры распределения серверных нагрузок именно такое резервирование более предпочтительно, поскольку оно гарантирует непрерывность предоставления сервисов даже в таких форс-мажорных обстоятельствах, как внезапное отключение электроэнергии вследствие природных явлений или неуплаты по счету. Большинство производителей поддерживают какой-либо один вариант резервирования. Например, для связи основного и резервного устройств компании Alteon и Radware используют сеть, HydraWeb — последовательный кабель, а F5 — сразу оба варианта.

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

Управление

Как правило, ни одно сетевое устройство, в том числе и коммутаторы контента, не страдает от недостатка опций конфигурирования и управления. Большинство из них предоставляют для этих целей интерфейс командной строки (Command-Line Interface — CLI) и один из двух типов GUI-интерфейса — на основе браузера или традиционной архитектуры клиент—сервер. И проблема обычно состоит не в том, какие интерфейсы конфигурирования и управления предоставляет коммутатор, а в том, какие механизмы соединения и безопасности поддерживаются ими.

Доступ к интерфейсу CLI чаще всего осуществляется через прямое консольное соединение. Этот вид доступа является наиболее безопасным, поскольку требует непосредственного физического подключения к устройству. Но тот же самый интерфейс CLI может быть доступен и через службу telnet (а это уже не так безопасно), и через службу SSH (более безопасную, чем telnet), использующую списки контроля доступа (Access Control List — ACL) для повышения степени защиты. Интерфейсы GUI имеются в большинстве продуктов. Традиционные клиент-серверные приложения конфигурирования и управления обеспечивают более высокий уровень контроля доступа, чем клиенты, основанные на браузерах (хотя и те и другие могут контролировать доступ по IP-адресам и идентификаторам пользователей).

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

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

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

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

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

Дополнительные функции

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

Терминирование сеансов SSL является “обязательной” дополнительной функцией, без которой не может обойтись ни один Web-узел электронной коммерции. Без нее его коммутатор не сможет анализировать указатели URL и распределять трафик в соответствии с заданными вами правилами. К счастью, в коммутаторах большинства производителей, таких, как ClickArray, F5 и Intel, содержатся встроенные функции терминирования сеансов SSL. Те же производители, в коммутаторах которых эта функция не поддерживается, выпускают отдельные продукты, способные предоставлять подобный сервис, правда за дополнительную плату.

Некоторые фирмы, например такие, как ClickArray, реализуют в своих устройствах нечто большее, нежели просто функциональные возможности прикладного уровня модели OSI. Сегодня, как никогда раньше, они стараются наделить свои продукты элементарными функциями межсетевого экранирования. Хотя производители, подобные Nortel, всегда предоставляли возможности фильтрации пакетов, многие коммутаторы контента, выполненные в виде отдельных устройств, до сих пор не поддерживают их. Да и так ли необходимы им эти функции фильтрации трафика? Все зависит от вашей сетевой архитектуры. Если перегруженный межсетевой экран является единственной точкой входа в вашу сеть, то вам весьма пригодится коммутатор контента, способный выполнять анализ и фильтрацию пакетов в целях более рационального распределения нагрузки. Только будьте предельно внимательны: прежде чем использовать такое устройство в качестве базового средства защиты своих кластеров, тщательно проанализируйте его функции межсетевого экранирования и впоследствии постарайтесь не перегружать его.

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

Поддержка функции QoS 802.1p — это пример еще одной дополнительной возможности. Спецификация 802.1p является расширением стандартов на протоколы ЛВС уровня MAC (Media Access Control) и предусматривает задание пакетам уровней приоритета посредством трехразрядного двоичного числа. Используя эту функцию, коммутаторы контента могут гарантировать более высокий уровень обслуживания отдельным пользователям. Эта функция реализована не во всех коммутаторах контента, но если вы считаете, что она нужна вам, то непременно подберите себе такой коммутатор, который поддерживает ее.

Больше и быстрее

Различные коммутаторы контента могут иметь самое разное число портов. Коммутаторы контента, выполненные в виде отдельных устройств, такие, как Big-IP компании F5, обычно оснащаются всего двумя портами — предполагается, что между ним и кластером серверов устанавливается коммутатор уровня 2 или уровня 3. Другие продукты, например компании Nortel, реализованные на базе обычных коммутаторов, предоставляют восемь и более портов, которые можно подключить к коммутаторам уровня 2/3 или непосредственно к серверам. Учитывая высокую стоимость аренды площадей в центрах обработки данных, плотность портов нередко становится определяющим фактором при выборе коммутатора контента.

Большинство кластерных топологий включают коммутатор контента и по меньшей мере один коммутатор уровня 2/3, обеспечивающий поддержку большого числа образующих кластер серверов. При выборе последнего проблемой является не столько число его портов (хотя общеизвестно, что, чем больше их, тем лучше), сколько их скорость. Большинство производителей предоставляют порты Fast Ethernet, но есть и такие, которые наделяют свои продукты гигабитными портами для нужд крупномасштабных центров обработки данных.

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

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





  
13 '2001
СОДЕРЖАНИЕ

колонка редактора

• Спутниковая отрасль возвращается к истокам

бизнес

• Катастрофоустойчивые корпоративные информационные системы

• Hewlett-Packard всерьез обосновывается на рынке ПО

• Профессиональная сертификация - уравнение со многими неизвестными

локальные сети

• Экранирование кабелей: практичное решение защищенной передачи сигналов

• Взаимодействие ИБП и дизель-генератора

• Еще раз о совместимости ИБП с дизель-генератором

• Руководство для покупателя серверов NAS

• Linux как рабочая платформа

корпоративные сети

• Коммутаторы Web: руководство для покупателя

• Резервирование данных для мобильных и удаленных пользователей

• Тестируем 2-Гбит/с адаптеры Fibre Channell

• Закон и ПО с открытым исходным кодом

услуги сетей связи

• VoDSL. Что над чем и зачем

• Сначала сеть - потом приложения?

• MMDS: от телевещания к высокоскоростному доступу в Интернет

• Технологическое оборудование для прокладки волоконно-оптических линий связи на ЛЭП

системы учрежденческой связи

• Call-центры в России и за рубежом

• Телефонные "лего" из Москвы и Петербурга

защита данных

• Урок функциональности

новые продукты

• Знакомьтесь: ViewStation; Очередная "пятерка" Invensys Powerware Division


• Калейдоскоп



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх