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

РЕЗЕРВИРУЕМЫЕ КАНАЛЫ

Перед многими предприятиями, в частности, теми, кто занимается предоставлением публичных прикладных сервисов Web, рано или поздно встает задача организации надежной, отказоустойчивой и эффективной связи с Internet. Для этого необходимо наличие как минимум двух каналов связи с сетями разных операторов (Multihoming) (см. Рисунок 1).

Рисунок 1. Пример отказоустойчивого подключения.

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

Для этой стандартной задачи традиционно предлагаются два типовых решения:

  • многоинтерфейсная трансляция адресов (Multihomed NAT);
  • протоколы динамической маршрутизации, например, протокол пограничного шлюза (Border Gateway Protocol, BGP).

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

Некоторые производители активного сетевого оборудования предлагают собственные средства, предназначенные как для направления уведомлений, так и для изменения в логике работы маршрутизирующих устройств:

  • мониторинг SLA;
  • трекинг SLA.

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

МНОГОИНТЕРФЕЙСНАЯ ТРАНСЛЯЦИЯ

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

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

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

В-третьих, в описанной конфигурации присутствует единая точка отказа, а именно — маршрутизатор, соединяющий сеть клиента с сетями операторов. Этого можно избежать за счет установки второго аналогичного устройства и их объединения в общую виртуальную систему при помощи таких средств, как Hot Standby Router Protocol (HSRP) или Virtual Router Redundancy Protocol (VRRP).

ИСПОЛЬЗОВАНИЕ BGP

Другая типичная реализация предполагает выделение блока не зависящих от провайдера (Provider Independent) IP-адресов и номера автономной системы (AS) (он используется протоколом маршрутизации BGP), а также подключение новой AS к сети Internet через двух различных провайдеров. Тем самым обеспечивается высокая надежность подключения к сети Internet.

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

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

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

  • необходимость получения диапазона IP-адресов, не входящих в блок адресов конкретного провайдера (Provider Independent, PI);
  • необходимость регистрации соб-ственной автономной системы (AS);
  • относительно длительное время сходимости протокола BGP;
  • потенциально большой объем информации, получаемой по BGP (это приводит либо к необходимости настройки ее фильтрации, либо к высоким аппаратным требованиям, а часто к тому и другому одновременно).

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

МОНИТОРИНГ SLA

Мониторинг может быть направлен на контроль нескольких основных параметров (список не полный):

  • задержка прохождения пакетов (UDP, ICMP);
  • вариация задержки (jitter) прохождения пакетов (UDP, ICMP);
  • время установления соединения TCP;
  • время загрузки тестовой страницы Web или файла по FTP;
  • время исполнения запроса к серверу DNS.

Результаты мониторинга могут быть получены при помощи SNMP и переданы в любой монитор переменных SNMP — от MRTG до
HP OpenView NNM.

Так, в маршрутизаторах Cisco Systems в качестве механизма реализации описанного решения предусмотрена функция Cisco IOS IP Service Level Agreements (SLA). Она позволяет в реальном времени осуществлять мониторинг сети и изменять правила поведения маршрутизаторов в зависимости от его результатов.

Для базового мониторинга достаточно в одной из точек сети установить маршрутизатор Cisco, а в другой — любое сетевое устройство, способное отвечать на запросы ICMP (см. Рисунок 2). Для более точного измерения указанных параметров можно воспользоваться функцией Cisco IP SLA Responder. В этом случае маршрутизаторы Cisco должны быть установлены с обеих сторон канала: как у клиента, так и у оператора.

Рисунок 2. Мониторинг SLA.

Для одновременного мониторинга нескольких Internet-ресурсов может быть создан целый ряд объектов IP SLA. При этом появляется возможность проверки не только качества связи с операторскими сетями, но и доступности основных ресурсов Internet, наиболее критичных для работы заказчика (например, сайтов головной компании, производителей оборудования, основных партнеров, обслуживающего банка и налоговой инспекции).

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

ТРЕКИНГ SLA

Более широкие возможности предоставляет так называемый трекинг. Под трекингом понимается отслеживание каких-либо параметров, заданных при конфигурировании IP SLA. При выходе за предельные значения маршрутизатор меняет поведение в соответствии с предопределенными настройками, в частности, изменяет записи в таблице маршрутизации в зависимости от состояния объектов трекинга. Так, с решениями Multihomed NAT трекинг применяется для смены активного маршрутизатора путем изменения приоритета HSRP.

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

  • наименьшему количеству соединений;
  • по принципу кругового перебора (Round Robin);
  • времени отклика (Delay);
  • загрузке канала (Bandwidth).

Входящий трафик распределяется в зависимости от загрузки канала путем указания при ответе на запрос DNS различных IP-адресов. В данном решении коммутатор прикладного уровня выполняет функции внешнего сервиса DNS (Authoritative DNS) для всех подключений к провайдерам. При получении запроса DNS выбирается наилучший канал в соответствии с заданными критериями и ответ высылается через интерфейс коммутатора, соответствующий выбранному каналу.

Для того чтобы обратный трафик следовал тем же путем (через того же провайдера), каким поступил входящий, необходимо включить функцию «возврат-к-отправителю» (Return-To-Sender, RTS). Она ассоциирует соединение с MAC-адресом маршрутизатора доступа в Internet и тем самым позволяет коммутатору прикладного уровня связать сеанс с MAC-адресом маршрутизатора глобальной сети. Это гарантирует возврат трафика по нужному каналу.

К достоинствам такой схемы относятся:

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

Теперь обратимся к варианту использования протокола BGP. Преимущества такого подхода заключаются в его стандартности, отказоустойчивости как для исходящих, так и для входящих соединений, наличии гибких средств управления маршрутами. На последнем пункте остановимся подробнее. Обеспечить резервирование доставки исходящих пакетов IP несложно при помощи того же подхода, что и в решении «Multihomed NAT + HSRP».

А вот для резервирования доставки входящих пакетов IP придется прибегнуть к более изощренным средствам. Добиться желаемого результата можно посредством манипуляций с длиной такого атрибута BGP, как AS Path. Резервному оператору корпоративная сеть анонсируется с длинным AS Path, в результате путь до целевой автономной системы логически удлиняется, что делает его менее предпочтительным, а основному оператору предлагается короткий AS Path, но только в случае выполнения условий SLA.

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

Денис Дыжин — руководитель департамента развития центра сетевых решений компании «Инфосистемы Джет». С ним можно связаться по адресу: dyzhin@jet.msk.su.