Виртуальная маршрутизация -- новый уровень сетевых услуг

18 июнь, 2002 - 23:00Леонід Бараш Заказчики, арендующие доступ к Internet или виртуальные частные сети (VPN) у операторов сетевых услуг (Network Service Provider -- NSP), до недавнего времени вынуждены были мириться с общей для всех конфигурацией как фронтальных (на границе ядра сети), так и магистральных маршрутизаторов. В то же время многих не устраивали транспорт пакетов с QoS на уровне best-effort, отсутствие возможности выполнить требуемую для своих приложений конфигурацию сети, самостоятельно осуществлять мониторинг и управление. Новый технологический подход к функционированию маршрутизаторов, называемый виртуальная маршрутизация (Virtual Routing -- VR), освободит маршрутизатор от ограничений, накладываемых единой физической конструкцией. Сети с виртуальной маршрутизацией (Virtual Routed Networking -- VRN) обещают наряду с высокой масштабируемостью и гибкостью предоставить целый набор новых IP-базированных сервисов.

Термин "виртуальный маршрутизатор", вообще говоря, не новый. Так назывался маршрутизатор, который устанавливался в точке присутствия (Point Of Presence -- POP) оператора и обслуживал исключительно одного заказчика (принадлежал ему виртуально), особенно если его сеть была автономной системой. Однако в современном понимании его значение радикально изменилось. Сегодня выражение "виртуальный маршрутизатор" является, скорее, логической сущностью или даже концепцией, а не отдельным физическим устройством. С помощью технологии виртуальной маршрутизации физический маршрутизатор подразделяется на множество виртуальных. На каждом виртуальном маршрутизаторе работает своя копия набора протоколов маршрутизации, он имеет выделенные порты ввода/вывода, собственные буферную память, адресное пространство, маршрутную таблицу и управляющее ПО. Виртуальный маршрутизатор можно рассматривать как совокупность потоков (статических или динамических) в маршрутизирующем устройстве, которая обеспечивает маршрутизацию и продвижение пакетов во многом подобно обычному маршрутизатору. Виртуальный маршрутизатор, вообще говоря, не нуждается в отдельном процессе операционной системы, т. е. он не должен быть реализован в виде выполняемого приложения с собственным виртуальным адресным пространством, кодом, данными и другими ресурсами операционной системы, такими, как файлы, каналы и синхронизирующие объекты. Он просто должен обеспечить для подключенной к нему сети иллюзию выделенного маршрутизатора, который выполняет все ее запросы. Так же как и его физический аналог, виртуальный маршрутизатор является равноправным элементом маршрутного домена. Другие маршрутизаторы этого домена могут быть как физическими, так и виртуальными. Безусловно, с точки зрения пользователя виртуальный маршрутизатор должен быть эквивалентен физическому. Другими словами, с очень небольшими исключениями он должен вести себя по отношению ко всем операциям, таким, как конфигурация, управление, мониторинг, поиск и устранение неисправностей, подобно выделенному физическому маршрутизатору. Основная мотивация для таких требований заключается в том, чтобы избежать обновления или реконфигурации огромной инсталлированной базы маршрутизаторов и переподготовки сетевых администраторов.

Pro et contra

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

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

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

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

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

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

обеспечение качества услуг (QoS) на прикладном уровне. Прикладной уровень качества услуг (Application-level QoS -- AQS) позволяет выполнять динамическую классификацию трафика, фильтрацию и продвижение пакетов в соответствии с правилами. Это достигается за счет более углубленного анализа пакетов и осведомленности об изменении параметров состояния приложения;

новый подход к управлению сетью. В отличие от традиционного метода, заключавшегося в конфигурации каждого порта на каждом устройстве посредством командной строки, новый подход базируется на графическом пользовательском интерфейсе, предопределенных шаблонах и использовании помощников (wizards), автоматизации и интеграции с мощным сквозным API с другими системами администрирования сети, поддерживающими специфические функции управления (Operations Support System -- OSS).

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

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

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

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

Еще одной проблемой является объем оперативной памяти. Обычно маршрутизатор требует нескольких мегабайт для хранения копии полной таблицы BGP (Border Gateway Protocol). Он также должен хранить таблицы своих соседей, многие из которых имеют сотни ближайших транзитных маршрутизаторов. Еще ему необходима память для вычисления наилучшего в некоторой метрике маршрута. Таким образом, мы видим, что задачи маршрутизации весьма ресурсоемки по отношению к памяти, а ее объем определяется возможностями адресации микропроцессора и особенностями чипсета. Следовательно, применение виртуальных маршрутизаторов становится проблематичным в тех случаях, когда они имеют конфигурацию, требующую интенсивного использования памяти.

После всего сказанного может показаться, что виртуальные маршрутизаторы не имеют перспектив. Однако это далеко не так. Все зависит от того, где и с какой целью они применяются. Безусловно, они не годятся в качестве магистральных. Но для локальных операторов виртуальные маршрутизаторы представляют значительный интерес. Прежде всего они смогут предложить свои собственные сквозные (end-to-end) сервисы, поскольку будут в состоянии управлять всей сетью, от каналов доступа до магистралей. Они предоставят требуемый уровень сервиса (Service Level Agreement -- SLA) с оговоренными характеристиками, такими, как величина задержки и уровень стабильности синхронизации. Операторы услуг могут также строить безопасные частные виртуальные сети. Немаловажно и то, что они смогут быстро и с небольшими финансовыми затратами выполнять модификацию и расширение своих сервисов, так как виртуальная маршрутизация реализуется на программном уровне.