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

Каждое предприятие стремится привести производительность приложений в соответствие со своими деловыми задачами. Прежде всего это касается таких приложений, как планирование ресурсов предприятия (Enterprise Resource Planning, ERP) или передача голоса по IP (Voice over IP, VoIP), от которых зависит деятельность всех подразделений. Средние затраты на развертывание систем ERP, по оценкам Meta Group (2003 г.), составляют около 30 тыс. евро на одного пользователя в течение трех лет, что делает оптимизацию производительности абсолютно необходимой. При этом подразделение ИТ должно не только обеспечить нужную производительность приложений, но и следить за их работой. Доступность классов услуг и получение вместе с ними гарантий для столь важных приложений, как ERP, — веская причина для внедрения MPLS.

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

MPLS И COS

Стремление предприятий получить дифференцированные классы услуг MPLS в одиночку удовлетворить не может. Важное значение имеет то, каким образом предприятия реализуют и масштабируют конвергенцию приложений в своих сетях. Понятие конвергенции в последнее время часто употребляется в связи с передачей голоса или видео по инфраструктурам IP. Однако сети электронной почты, передача пакетов по SONET (Packet over SONET, POS) на базе Х.25, а также банковские приложения на базе SNA уже давно переведены на IP. Конвергенция требует дифференцированных услуг, но одновременно и усложняет их реализацию.

Рисунок 1. Развитие идет от VPN на базе сети в направлении VPN с распознаванием приложений.

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

Прежде всего необходимо идентифицировать различные характеристики сетевого трафика. Голосовой трафик предъявляет особые требования ко времени задержки и ее вариации, причем каждому пользователю нужна пропускная способность около 20 Кбит/с. Приложения ERP менее чувствительны к вариации, однако требуют малого времени задержки во избежание разрыва соединения из-за истечения периода ожидания ответа, а каждому пользователю необходима пропускная способность величиной 25 Кбит/с. Тиражирование базы данных Microsoft Exchange, напротив, не предполагает никаких ограничений по времени задержки и ее вариации, однако занимает всю имеющуюся в наличии пропускную способность в ущерб остальным приложениям. Наряду с этими тремя типичными приложениями следует учитывать и различные требования множества критичных для предприятия, но не столь важных приложений.

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

НЕЖЕЛАТЕЛЬНЫЙ ТРАФИК ВОПРЕКИ COS

Сетевые устройства, не предназначенные специально для анализа потока трафика на седьмом уровне OSI, не в состоянии различать приложения. Так появляется другая проблема: невозможность проверить факт принадлежности трафика определенного класса этому классу. Некоторые реализации трафика ERP способны осуществлять выбор между 10 тыс. номеров портов. Трафик между равноправными узлами (Peer-to-Peer, P2P), как Kazaa, напротив, ищет открытые порты в брандмауэрах и благодаря этой функции проходит под видом приложений ERP. Пользователи Media Player могут сконфигурировать свое приложение для порта 80, а он, как известно, используется трафиком Web. Если сетевое устройство идентифицирует приложения на основании только этого порта, то в сети могут начать курсировать нераспознанные приложения — некритичные для предприятия или даже нежелательные. Они не только занимают дорогостоящую пропускную способность глобальной сети, но и соперничают за производительность с трафиком более высоких классов.

Даже если назначить приложениям статичные порты, а каждому классу услуг — клиентские адреса, то все равно придется решить еще одну фундаментальную проблему: при отнесении трафика к какому-либо одному определенному классу каждый находящийся в его пределах поток может занять всю отведенную этому классу пропускную способность. Так, невидимый неклассифицированный трафик Р2Р может помешать соблюдению соглашений об уровне сервиса (Service Level Agreement, SLA) для качества услуг приложения ERP, хотя для класса в целом они выполняются. Причина затруднения находится на краю сети MPLS — в интерфейсе подключения к корпоративной сети.

Коммутация меток — а тем самым и MPLS — предназначена для решения проблем производителей маршрутизаторов при построении очень больших виртуальных частных сетей IP с поддержкой качества услуг (Quality of Service, QoS): если бы маршрутизатор должен был идентифицировать и обрабатывать каждый поток трафика в сети, то это потребовало бы очень большой процессорной мощности и сделало невозможным масштабирование обработки пакетов. Решением является маркировка потока трафика на краю сети. Для идентификации классов услуг магистральные маршрутизаторы используют простую быструю ссылку на метку.

Рисунок 2. Управление трафиком позволяет рациональным образом загрузить глобальную сеть в соответствии с важностью приложений.

Класс услуг должен кем-то назначаться. Эту задачу решают маршрутизаторы на краю сети MPLS (Label Edge Router, LER). Однако сегодня LER не способны классифицировать трафик лучше, чем до введения MPLS: маршрутизаторы занимаются классификацией главным образом на четвертом уровне OSI. Но классификация по содержащейся в данных сигнатуре приложения была бы связана с такими же — если не с более серьезными — проблемами, как реализация в маршрутизаторах обширных функций обеспечения безопасности.

МАРШРУТИЗАТОРЫ КАК ИСТОЧНИК ПРОБЛЕМ

Маршрутизаторы на краю сети могут назначать приложениям лишь грубые свойства класса услуг (Class of Service, CoS). Они не предлагают детализированное согласование между приложениями и классами услуг, в котором заинтересовано большинство предприятий. Поэтому последние снова отказываются от классов услуг MPLS и возвращаются к одному классу. Сеть MPLS их предоставляет, но почти то же самое могла бы сделать любая другая сетевая инфраструктура.

Даже если грубое согласование между приложениями и классами услуг окажется для кого-то приемлемым, еще одна проблема все равно остается: большинство сетевых устройств реализуют QoS — т. е. приоритезацию трафика — посредством механизмов организации очередей. Производители маршрутизаторов и коммутаторов уже долгие годы стремятся добиться максимально возможной пропускной способности при умеренном времени задержки — однако использование очередей для обеспечения качества услуг замедляет движение трафика непредсказуемым образом. В рамках реализации VoIP, когда маршрутизатор «искусственно» конфигурирует сеть таким образом, что размер кадра трафика не превышает 100 Кбайт, первоочередной трафик сталкивается с неопределенной задержкой. Несомненно, маршрутизатор является главным компонентом инфраструктуры, но в то же время и основной причиной, мешающей воспользоваться обещанными преимуществами классов услуг MPLS.

АЛЬТЕРНАТИВЫ

Какие же альтернативы есть у тех предприятий, где хотели бы применять MPLS для организации производительной работы ERP? Эффективное использование архитектуры MPLS на краю сети возможно, если обеспечиваются определенные функции, реализация которых способствовала бы решению названных проблем:

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

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

После идентификации приложений анализируется их производительность в сети. Получаемые при этом данные позволяют проводить детализированное планирование мощности. Каждой реализации ERP требуется разная пропускная способность: ERP с интерфейсом Web нужно больше, чем ERP с графическим пользовательским интерфейсом (Graphical User Interface, GUI). Кроме того, каждая реализация предъявляет различные требования к времени задержки. Нагрузка ERP на сеть зависит от количества пользователей, их функций и размещения вычислительного центра. Схожим образом организованы анализ и планирование пропускной способности для всех остальных приложений, когда следует учитывать всю единовременно доступную пропускную способность для широкополосных приложений: тиражирования баз данных, электронной почты и передачи видео. И наконец, до того как классифицирующее устройство передаст трафик маршрутизатору MPLS на краю сети, необходимо решить две важные задачи: ограничить пропускную способность и назначить трафику кодовое значение дифференциальных услуг (DiffServ Code Point, DSCP) — так маршрутизатор узнает, к какому классу услуг принадлежит трафик.

Управление скоростью служит в качестве механизма изменения информации заголовка ТСР в пакете данных для ограничения общей пропускной способности потока: для всякого приложения, использующего ТСР в качестве протокола управления, администратор может определять фиксированную скорость передачи вплоть до отдельно взятого потока данных. Таким образом, можно автоматически и точно указать профиль трафика для любого потока приложения. Пример: каждый сеанс ERP получает 25 Кбит/с, каждый исходящий сеанс Р2Р — 5 Кбит/с и каждый входящий Р2Р — 0,5 Кбит/с, что позволяет ограничить нежелательные загрузки. Функция контроля скорости гарантирует, что маршрутизатор никогда не окажется перегружен из-за слишком большого объема входящего трафика. В результате очереди маршрутизатора никогда не заполняются. Он не отбрасывает трафик, а трафик никогда в большом объеме не приписывается к неправильному классу услуг. Это предотвращает внезапный переход самого дорогого класса с гарантией CoS на более низкий уровень производительности. Если трафик для глобальной сети «заранее обработан», то устройство маркирует его при помощи DSCP, адаптируя поток приложения к имеющимся в сети MPLS классам услуг.

ПОВЫШЕНИЕ ЦЕННОСТИ СЕТИ MPLS

Лишь теперь становится очевидной реальная ценность сети MPLS: в глобальной сети с устройствами управления трафиком отдельные пользователи получают в точности необходимую для их приложений пропускную способность. При появлении нового приложения — а это может быть и «червь», и вирусная атака — нежелательному трафику оказывается доступен только самый низкий класс услуг с ограниченной общей пропускной способностью. Таким образом, он не сможет отобрать пропускную способность у других приложений даже этого класса. При добавлении новых пользователей ERP число сеансов ТСР, относящихся к ERP, увеличивается, а управление наложенной сетью — в его зону ответственности входят классификация, управление скоростью и маркировкой дифференциальных услуг — должно распознать повышенную активность сеансов, сообщить эту информацию в отчете и в идеальном случае адаптироваться к новому трафику путем изменения сетевых параметров.

Штефан Пикерт — региональный менеджер Packeteer. С ним можно связаться по адресу: wg@lanline.awi.de.