Управление трафиком в сети хостинг-провайдера

    В сети любого большого content/eyeball провайдера возникает необходимость управления трафиком. И чем больше сеть, тем острее эта необходимость ощущается. В этой статье я попытаюсь описать основной принцип управления трафиком в сети компании, непосредственное отношение к которой я имею. Сразу оговорюсь, что в этой статье упоминается множество торговых марок, терминов и «жаргона». Здесь не будет ни примеров конфигурации роутеров, ни описания этих самых терминов.

    Мы привыкли считать, что транспортная MPLS-сеть необходима, в основном, для applications, которых существует множество: L3VPN, L2VPN/VPLS, и т.д. О Traffic Enigineer'инге в сетях MPLS вспоминают или от «хорошей» жизни, или, скорее, теоретически.

    Также принято считать, что backup capacity — это роскошь и, как правило, кариеры/транспортники биллят за backup-порт также, как за обычный. Назревает резонный вопрос: зачем покупать капасити, которые будет просто простаивать и, возможно, несколько раз в месяц на короткое время использоваться? Но, с другой стороны, говорить о том, что «backup'ы для трусов» тоже нельзя, backup'ная емкость должна быть. Как же быть? Об этом и пойдет речь в статье.


    Собственные пиринговые сети — это явление в наши дни довольно частое. Очевидно, что свой трафик, который ходит по пиринговой сети гораздо дешевле трафика, который уходит в сеть кариера. Также, как правило, кариеры продают порты с коммитом в 50% от максимальной утилизации линка (10GE линк с коммитом всего 5Gbps), таким образом, можно предполагать, что в любом момент времени у нас есть запасное капасити для нашей пиринговой сети. Зачастую кариеры используют 95% percentile для билинга трафика и выставления счёта, т.е. другими словами, 36 часов в месяц мы можем смело использовать того или иного кариера бесплатно, с остальное же время месяца пуская в него трафик в пределах оговоренного коммита.

    Но как же сделать так, чтобы максимально исключить ручное вмешательство, второпях что-то где-то не отдепиривать, быстро принимать какие-то решения (которые не всегда правильные). Ведь потери и перегруженные каналы видны сразу, а для принятия решение нужно время. Как построить минимальную по стоимости пиринговую сеть, чтобы максимально защитить от congestion'а имеющейся трафик, бегающий по сети в данный (пиковый, в особенности) момент времени?

    Рассмотрим простейшую пиринговую сеть хостинговой компании:

    image

    Несколько Point of Presence (POP), линки внутри POP условно-бесплатные, а вот за domestic/transatlantic линки нужно платить. И чем больше мы утилизируем эти линки, тем себестоимость этих самых линков становится ниже. Другими словами, цена трафика обратно пропорциональна загруженности линка.



    Как видно, из POP Далласа в AMS-IX можно попасть множеством различных маршрутов. Казалось бы, что может быть проще, указывай соответствующие метрики интерфейсов и IGP для тебя всё сделает сам, но не всё так просто. Всё работает отлично, пока не случается авария на пути. Существует несколько способов построения сети. Первый, самый простой и надежный, но далеко не самый дешевый — держать загрузку транспортных линков примерно 50% (как это делает, например, транзитный кариер). Таким образом, выход из строя одного из двух линков сети, не влечет за собой деградацию качества сервиса, даже в пиковое время. Но в самом начале мы договорились, что нас интересует сеть дешевая, построенная скорее не по книжкам, а удовлетворяющая текущим запросам рынка. Выкидывать на ветер половину емкости могут позволить себе далеко не все. Второй способ — ручной: 24х7 NOC, который будет управлять трафиком в ручном режиме в зависимости от оповещений мониторинга. Но какой способ дешевле и/или качественнее, первый или второй, мы оставим на рассуждение читателя.

    Что же предлагаем мы? Мы предлагаем построить сеть MPLS, протоколом транспортных распространения меток которой является RSVP-TE, т.е. из любой точки PE-А в любую точку PE-В сети можно попасть, используя Label Switching Path (LSP), сигнальным протоколом которого является RSVP. Соответственно, никого LDP и уж тем более IP трафика вне RSVP LSP по сети не бегает. Полдела сделали. Но в чём принципиальное отличие от сотен таких же сетей? Всё верно, отличия пока нет. Теперь мы заставим наши RSVP Tunnels резервировать Bandwidth вдоль всего LSP на каждом линке пути.

    Здесь нужно остановиться и поподробнее объяснить что имеется ввиду. Само резервирование, в данном случае, условное. Каждый LSP обладает рядом свойств, в том числе и Requested Bandwidth. RSVP Path message, передаваемое от роутера к роутеру, резервирует необходимую ёмкость, которая нужна данному конкретному LSP. Если же условие выполнено и на текущем линке есть достаточно капасити, то Path message передаётся дальше к downstream router пока не достигнет egress router PE. В конечном итоге, если LSP таки установлено, то мы уверены, что необходимое капасити вдоль всего участка пути есть в наличии в данный конкретный момент времени.

    При этом, мы заставим RSVP tunnels искать себе пути сами сами, опираясь на небольшие направляющие (ERO, setup/hold priority, link colors и тд). Чтобы наши LSP не становились слишком «жирными», мы будем примерно ограничивать LSP в пределах 1-2Gbps, т.е. мапить в этот туннель примерно ~1Gbps трафика. Это занятие мы предоставим нашим BGP RR'ам. Маппинг происходит простым способом: bgp next-hop reachability. Согласно первому пункту BGP best path selection algorithm, bgp prefix считается валидным, если валиден next-hop этого самого маршрута. Поднялся RSVP-туннель — bgp next-hop доступен, маршрут через AMS-IX, в данном случае, также доступен. Важно заметить, что эти самые bgp next-hops, которые появляются в нашем RIB/FIB при поднятии MPLS Tunnel не переносятся нашим IGP. Это ключевой момент.

    Предположим, наша сеть построена. В час пик у нас на каждом транспортном линке между POP ~9Gbps. На текущий момент мы построили сеть, фактически, ничем не отличающуюся от вышеизложенной IGP-сети.

    Но вот теперь и начинается самое основное. Один или несколько из наших транспортных линков падают из-за аварии.



    В случае с IGP, трафик смаршрутизировался бы через NY RTR1 и на 10GE стыке между POPs NY и следующим роутером на пути к Amsterdam RTR1 у нас получился бы жуткий congestion (в 10GE линк попыталось бы влезь одновременно почти 20Gbps) и куча жалоб клиентов. Что же c нашими туннелями? Те туннели, который находились на этом линке начинают активно искать себе альтернативные маршруты с достаточным capacity на всем пути. Но если таких маршрутов согласно Traffic Engineering Database (TED) нет? Те туннели, которые не нашли себе маршрута остаются в down до тех пор, пока не будет достаточно капасити. Но куда же девать этот трафик, который раньше шел по этим туннелям? Как мы уже договорились ранее, направления (per AS-PATH basis) мапятся в туннель, bgp next-hop которого поднимается этим самым туннелем. Другими словами, на нашем PE Dallas RTR3 bgp best стали те маршруты, которые пришли к нам от транзитного кариера и лишний трафик автоматически развернулся в транзит (зеленый LSP).



    Наш трафик там будет оставаться до тех пор, пока либо не поднимется наш упавший линк, либо не освободиться достаточно капасити на всём протяженности пути к конечному PE.

    В таком случае, возразит читатель, к каждому PE в схеме должен быть подключен отдельный кариер(ы). Это не совсем так. Нас интересует backup, а если так, то вендоры уже давно позаботились и придумали для нас BGP best external (Cisco и Juniper поддерживают это). Но много ручной работы с RSVP! Это опять же не так, к нам на помощь приходят RSVP automatic mesh на тех PE, в которых количество трафика незначительно. Фактически, из рутинной работы в нашей сети остаётся только мониторинг за количеством трафика, который мапится в тот или иной LSP и выравнивании его в пределах оговоренной нормы. Чтобы наша сеть отражала реальную картину (мы договорились, никакого LDP и/или IP-трафика), мы используем Autobandwidth на всех туннелях RSVP. Эта особенность есть как у Cisco, так и у Juniper.

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

    Похожие публикации

    Комментарии 16

      0
      Отличная статья.
        0
        Очень интересно.
        Чтобы наши LSP не становились слишком «жирными», мы будем примерно ограничивать LSP в пределах 1-2Gbps, т.е. мапить в этот туннель примерно ~1Gbps трафика. Это занятие мы предоставим нашим BGP RR'ам. Маппинг происходит простым способом: bgp next-hop reachability.

        Здесь речь идет про eBGP next-hop? Т.е. IP роутера в соседней AS? Не очень понимаю тогда, как нарезать туннели по 1-2 Gbps?
          0
          Нет, здесь речь идет о iBGP, т.к. маппинг происходит на ingress PE. Наш RR отдает некое, как мы его называем, «направление», например, в понятиях Juniper'а — as-path-group. Этому направлению присваиваится уникальный next-hop, известный только ingress и egress PE. Как я уже писал в статье, именно этот NH не ходит в нашем IGP. Количество же трафика, которое маппится в данный конкретный LSP и регулируется набором этих самых AS_PATH.

          Например,
          PE1-PE2-1 — as-path-group-1 — NH: 192.168.1.1
          PE1-PE2-2 — as-path-group-2 — NH: 192.168.1.2
          и тд

          Идея делать LSP «потоньше» в том, чтобы они могли найти себе пути сами, исходя из текущей загрузки. Если LSP будут довольно «жирными», то они с очень большой вероятностью не найдут себе свободной емкости и будут в down'е до тех пор, пока не починится линк.
            0
            Спасибо, теперь ясно. Интересная схема. Наверное, монструозный конфиг получается на RR с кучей policy-map. Просто интересно, сколько у вас там таких as-path-group прибито руками?
              0
              Ну не совсем много. Как я уже писал выше, это всегда challenge между толщиной LSP и динамикой поиска. Мы все понимаем, что каналы не резиновые, поэтому некоторые LSP мы специально оставляем довольно толстыми и прибитыми к одному пути (strict ERO), чтобы в случае аварии _любого_ линка на пути, трафик автоматически маршрутизировался в кариера локально (или в пределах POP).
                0
                Ну а если в какую-нибудь AS вдруг начнет литься траффика значительно больше, чем зарезервировано в туннеле? Например, у вас есть гигабитный туннель для десятка AS, вдруг траффик в одну AS значительно возрастает и суммартный траффик туннеля становится больше гига. Это как-то обрабатывается автоматически или требует ручного вмешательства?

                Я еще только изучаю rsvp-te и поэтому могу чего-то не понимать и задавать глупые вопросы. Заранее прошу прощения :)
                  0
                  Подобные ситуации крайне редки (специфика бизнеса), поэтому оставляем их на откуп NOC-у
          0
          давно пытаюсь понять суть RSVP-TE и решить нужен ли он… спасибо за понятное разъяснение. Если не трудно, то хотелось бы почитать про реализацю FRR и необходимые для этого протоколы и настройки (path profile и др.)
            0
            RSVP-TE необходим именно тогда, когда нам нужно управлять трафиком, не обращая внимание на IGP, опираясь лишь на некоторые направляющие или же просто «прибивать» наши LSP к определенному пути, например, при помощи strict ERO. В этом суть данной статьи. Таким образом, мы можем держать, фактически, все линки, за которые платим деньги, с утилизацией, близкой в 100%, максимально снижая себестоимость этой самой сети.

            К сожалению, о FRR и facility backup я могу говорить только теоретически, мы не используем это на данный момент. Пресловутая сходимость в 50ms нам не нужна, у нас нет в сети телефонии. Но и опять же, Link/Node protection нужно только для того, чтобы именно в данный момент завернуть трафик куда-то на PLR, таким образом, не потерять его (трафик). При этом, сигнализировать ingress PE что на пути авария и нужно искать срочно другой путь. Но, исходя из того, что у нас линки утилизируются на 100%, нам заворачивать этот трафик просто нету — нет капасити. Поэтому нам проще подождать максимум подождать сходимости BGP, пока необходимые маршруты не развернуться в кариера, либо минимум, пока наши LSP на найдут себе новых путей.
            0
            Мне кажется, Гугл делает все то же самое в своей сети, но не с помощью роутеров и MPLS, а с помощью коммутаторов, управлемых по OpenFlow.
              0
              Не совсем так. Вот статейка на этот счет: blog.ioshints.info/2012/05/openflow-google-brilliant-but-not.html Они все так же используют mpls, но управляют LSP другими средствами.
                0
                Мне кажется, что будь то MPLS, Carrier Ethernet или plain ip routing — не играет особой роли. Суть SDN в том, что есть некий единый brain, который видит всю сеть, как один большой свитч/роутер. И этот «brain» можно программировать как угодно, опираясь, фактически, на любые данные, совершенно наплевав на тот код и рамки, которые накладывает сейчас тот или иной вендор.

                Совершенно очевидно, что C/J теряют большую часть пирога, разрешая свои железки программировать как big dump switch, не продавая больше свои IOS/JunOS licences. Brocade, насколько я знаю, уже выпустила SDN-свитч, Juniper вроде начал об этом заикаться (насколько это далеко от реалий, а не обычный маркетинг, я затрудняюсь сказать). От Cisco мало что слышал.
                  0
                  Совершенно очевидно, что C/J теряют большую часть пирога, разрешая свои железки программировать как big dump switch, не продавая больше свои IOS/JunOS licences

                  Кто-то говорит про отсутствие проприетарных расширений?
                  SDN станет эпическим vendor lock-in. На заявления о полной открытости не обращайте внимание.
                  Ах да — где-то под SDN еще много десятилетий будут работать традиционные IGP протоколы и TE туннели, чтобы сразу подхватить трафик, как только контроллер потеряется. У Google это именно так.
                  От Cisco мало что слышал.

                  У них было нечто похожее на SDN еще до того, как это стало модно: OER/PfR.
                  А сейчас есть ONE. Работает практически на любом имеющемся оборудовании, включая ISR и многие каталисты.
                    0
                    Опередили вы меня на пару минут :))
                    0
                    Да, все верно, со всем согласен. Однако C/J могут и не потерять пирога или по крайней мере принять активное участие в его дележке. Вендоры все равно будут реализовывать свои дополнения к OpenFlow, плюс к этому они будут выпускать свои openflow контроллеры с пропиетарными «мега-фичами» используюя проприетарные расширения к OpenFlow, так что пути для монетизации еще есть, главное не упустить момент.
                  0
                  Да, вы совершенно правы, только SDN предоставляет гораздо большие возможности, учитывая то, что у Гугла еще толпа неплохих программистов, которые воплотят в реальность любые желания сетевиков. Здесь же я просто показал, как с помощью подручных средств, предоставляемых IOS/JunOS добиться более-менее 100% утилизации сети без потери качества.

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое