По городам и весям или как мы балансируем между узлами CDN

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

    В предыдущей статье я рассказал, что CDN у нас свой, при этом тщательно избегал подробностей. Пришла пора поделиться. Рассказ будет в стиле поиска решения, каким он мог бы быть.

    В поисках идеи


    Какие могут быть критерии для гео-балансировки? Мне приходит в голову вот такой список:
    1) уменьшение задержек при загрузке контента
    2) размазывание нагрузки на серверы
    3) размазывание нагрузки на каналы

    Окей, раз на первом месте уменьшение задержек, то надо отправлять пользователя на ближайший узел. Как этого можно добиться? Ну, у нас тут завалялась Geo-IP база, которую мы используем для региональной привязки рекламы. Может, её к делу приспособить? Можно, к примеру, написать распасовщик, который будет стоять в нашем центральном ЦОДе, определять регион пришедшего на него пользователя и отвечать тому редиректом на ближайший узел. Работать будет? Будет, но хреново! Почему?
    Ну, во-первых, пользователь уже пришёл в Москву только для того, чтобы узнать, что ему в Москву не надо. А затем ему надо сделать второй заход уже на местный узел за требуемым файлом с фильмом. А если фильм нарезан чанками (chunk, это такие маленькие маленькие файлы с маленькими кусочками фильма)? Тогда будет по два запроса на каждый чанк. Ой-ой-ой! Можно, конечно, попробовать это всё оптимизировать и написать на клиенте код, который будет ходить в Москву только один раз за фильм, но это уже утяжелит этот самый код. А потом его придётся дублировать на всех типах поддерживаемых устройств. Избыточный код — это плохо, поэтому — отказать!

    Довольно много CDN, которые я наблюдал (не могу сказать, что тестировал), пользуются балансировкой редиректами. Думаю, дополнительной причиной, почему они это делают, является биллинг. Ведь они — коммерческие люди, им нужно обслужить тех и только тех, кто им заплатил. А такая проверка на балансировщике занимает дополнительное время. Я уверен, что именно такой подход и привёл к упомянутому мной прошлый раз результату — сайты с CDN грузятся медленнее. А мы этот способ полностью и с самого начала проигнорировали.

    А если по имени?


    Как мы можем сделать геобалансировку так, чтобы не надо было бегать лишний раз в Москву? Но позвольте! Мы и так по-любому ходим в Москву — чтобы разрезолвить доменное имя! А что, если ответ сервера будет учитывать местонахождение пользователя? Да запросто! Как это можно сделать? Можно, конечно, вручную: создать несколько представлений (view) и для разных пользователей возвращать разные IP-адреса для одного и того же доменного имени (сделаем для этого специально выделенный FQDN). Вариант? А то! Только поддерживать придётся вручную. Можно и автоматизировать — для bind, к примеру, есть модуль для работы с тем же MaxMind. Думаю, есть и другие варианты.

    К моему огромному изумлению, балансировка при помощи DNS сейчас является самым распространённым способом. Не только небольшие фирмы используют этот метод для своих нужды, но и крупные уважаемые производители предлагают комплексные аппаратные решения, основанные на этом методе. Так, например, работает F5 Big IP. Опять же, говорят, что так работает Netflix. Откуда изумление? Проследите мысленно цепочку прохождения запроса к DNS от пользователя.

    Куда пакет попадает с пользовательского ПК? Как правило — на провайдерский DNS-сервер. И в этом случае, если предположить, что этот сервер находится близко к пользователю, то пользователь попадёт на ближайший к нему узел. Но в значимом проценте случаев (даже простая выборка у нас по офису даёт заметный результат) это будет либо вселенское зло — Google DNS, либо Яндекс.DNS, либо ещё какой-либо DNS.

    Чем это плохо? Давайте смотреть дальше: когда такой запрос попадёт на ваш уполномоченный DNS, чей будет source IP? Сервера! Никак не клиента! Соответственно, балансирующий DNS будет по факту балансировать не пользователя, а сервер. Учитывая, что пользователь может использовать сервер не в своём регионе, то и выбор узла на основе этой информации будет неоптимальным. А дальше — хуже. Такой гуглоднс закэширует у себя ответ нашего балансирующего сервера, и будет возвращать его всем клиентам, уже без учёта региона (в нём-то не настроены view). Т.е. фиаско. Кстати, сами производители такого оборудования, при личной встрече мне вполне подтвердили наличие этих фундаментальных проблем с DNS-балансировкой.

    Сказать по правде, мы этот метод применяли на заре строительства нашего CDN. Ведь опыта с собственными узлами у нас не было. Системные интеграторы сразу пытались продать под такую задачу по много вагонов оборудования за сумму с большим количеством нулей. А решение на основе DNS в принципе понятно, и работоспособно. Из нашего опыта эксплуатации и выплыли все эти отрицательные стороны. К тому же, вывод узла на профилактику чертовски сложен: приходится ждать, пока протухнут кэши на всех устройствах по пути к пользователю (кстати, оказывается, огромное количество домашних роутеров напрочь игнорирует TTL в DNS-записях и хранят кэш до пропадания питания). А уж что будет, если узел вдруг аварийно отключится — так вообще страшно подумать! И ещё одна вещь: очень непросто понять, с которого узла абонент обслуживается, когда у него проблема. Ведь это зависит от нескольких факторов: и в каком регионе он находится, и какой DNS он использует. В общем, очень много неоднозначностей.

    Пинг или не пинг?


    И вот тут наступает «во-вторых» (на случай если кто-то удивляется, зачем я начал во-первых): в интернете географически близкие элементы могут оказаться очень далеки с точки зрения прохождения трафика (помните с прошлого раза «из Москвы в Москву — через Амстердам»?). Т.е. geo-IP базы недостаточно для принятия решения о направлении пользователя на какой-либо конкретный узел. Необходимо дополнительно учитывать связность между провайдером, к которому подключен узел CDN, и пользователем. По-моему, здесь же, на хабре, мне попадалась статья, в которой упоминалось ручное ведение базы данных по связности между провайдерами. Оно, конечно, может и работать значимую часть времени, но разумность в таком решение явно отсутствует. Каналы между провайдерами могут падать, могут забиваться, могут отключаться из-за разрыва отношений. Поэтому отслеживание качества от узла до пользователя должно быть автоматизировано.

    Как мы можем оценить качество канала до пользователя? Пропинговкой, конечно! И пинговать пользователя мы будем со всех наших узлов — ведь нам надо выбрать лучший вариант. Полученные результаты мы где-нибудь сохраним для следующего раза — ведь если ждать, пока все узлы пользователя пропингуют, он просто не дождётся кино. Так что первый раз пользователь всегда будет обслуживаться с центрального узла. А если с Чукотки до Москвы плохие каналы — ну, значит, второго раза не будет. Кстати, пользователи не всегда пингуются — новые домашние роутеры и всяческие Windows 7 по умолчанию не отвечают на эхо-запросы. Так что такие тоже будут всегда обслуживаться из Москвы. Чтобы замаскировать эти проблемы, давайте усложним наш алгоритм вычисления лучшего узла аггрегированием пользователей по подсетям. Затем запатентуем его и поедем в Сколково — больше нигде такая система не нужна в виду своей тяжести и неэффективности.

    И как ни странно, «промышленные» решения используют именно такой способ определения карты связности — пропинговку конкретных пользователей. Начисто игнорируя и то, что оконечные устройства не отвечают на ICMP пинги, и многие провайдеры (особенно на западе) вырезают весь ICMP под корень (я и сам люблю его хорошо зафильтровать). И все эти промышленные решения заполняют интернет бессмысленными пингами, фактически вынуждая провайдеров фильтровать ICMP. Не наш выбор!

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

    1. Абонент должен сначала обращаться к ближайшему узлу, и только если там нет нужного контента, тогда — к следующему, покрупнее
    2. Решение должно быть независимым от настроек у конкретного пользователя
    3. Решение должно учитывать текущую связность от пользователя до узла CDN
    4. Решение должно предоставлять техническим сотрудникам ivi возможность понять, на каком узле пользователь обслуживается

    Просветление


    И тут мне на глаза попалось слово anycast. Я его не знал. Оно чем-то напоминало известные мне unicast, broadcast и любимый multicast. Я полез гуглить и скоро стало понятно, что это наш выбор.

    Если кратко описывать anycast, то это будет так: «Хак, нарушение принципа уникальности IP-адреса в интернете». За счёт того, что одна и та же подсеть анонсируется из разных мест интернета, с учетом взаимодействия автономных систем, а если разные наши узлы контактируют с одной и той же автономкой провайдера — за счет метрики IGP или её эквивалента, выбираться будет ближайший узел. Смотрите, как собранная система (номера автономок указаны для примера, хотя и не без уважения к коллегам) выглядит на самом деле:



    И как она же выглядит с точки зрения маршрутизации BGP. Как будто бы нет никаких неуникальных IP-адресов, а есть несколько каналов связи в разных городах:



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

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

    Итоговая схема выглядит так:

    1. Пользователь обращается на выделенный для контента FQDN
    2. Это имя резолвится в адрес из anycast'ового диапазона
    3. Пользователь попадает на ближайший (с точки зрения сети) узел CDN
    4. Если такой контент на узле есть, то пользователь его получает с узла (т.е. один запрос!!!)
    5. Если такого контента на узле нет, то пользователь получает HTTP-redirect в Москву

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

    Anycast и его ограничения очень хорошо описаны в RFC4786. И это было первое и пока что последнее RFC, которое я дочитал до конца. Основное ограничение — это возможность перестроения маршрутов. Ведь если пакеты из середины TCP-сессии вдруг пойдут на другой узел, то оттуда в ответ прилетит RST. И чем длительнее TCP-сессия, тем выше вероятность этого. Для просмотра фильма это весьма критично. Как мы это обошли? По нескольким направлениям:

    1. Часть контента доступна в виде чанков. Соответственно, время TCP-сессии незначительно
    2. Если плеер не смог скачать кусочек фильма из-за разрыва сессии, то плеер не показывает ошибку, а делает ещё одну попытку. С учетом большого буфера (10-15 секунд) пользователь вообще ничего не замечает.

    Другое (и временами, крайне неприятное ограничение) заключается в том, что оператор CDN на основе anycast не имеет непосредственного управления над тем, с какого именно узла пользователь обслуживается. В большинстве случаев, это для нас хорошо (пусть оператор сам решает, где у него каналы толще). Но иногда нужно подтолкнуть в другом направлении. И самое приятное, что это возможно!

    Балансируем!


    Есть несколько способов добиться нужного распределения запросов между узлами:

    1. Написать сетевикам — долго, мучительно искать контакты (RIPE DB все как-то не хотят вести), напрягает их и приходится долго рассказывать про anycast. Но в ряде случаев — единственный способ
    2. Добавить препендов (prepend, это когда мы «визуально удлиняем маршрут в BGP») в анонсы. Тяжёлая артиллерия. Применяется только на прямых стыках и никогда — на точках обмена трафиком (IX)
    3. Управляющие community, моё любимое. У всех приличных провайдеров они есть (да, обратное верно: у кого нет — тот неприличный). Работает примерно как препенд, но гранулярнее, добавляет препенд не всем клиентам через стык, а только в конкретные направления, вплоть до закрытия анонсов.

    Естественно, со всей этой системой чёрных ящиков работать было бы невозможно, но есть такая приятная вещь, как Looking Glass (LG, переводить не буду, т.к. все переводы плохие). LG позволяет заглянуть в роутинговую таблицу провайдера, не имея доступа к его оборудованию. У всех приличных операторов есть такая штука (мы не оператор, но у нас тоже есть). И такая мелочь позволяет избегать обращений к сетевикам операторов связи в очень большом количестве случаев. Я так и свои ошибки ловил, и чужие.

    За всю нашу трёхлетнюю эксплуатацию CDN с балансировкой на основе anycast всплыл только один тяжелый случай: сеть на всю страну с централизованным роут-рефлектором (route-reflector, RR) в Москве. Фактически такая архитектура делает для провайдера бесполезными распределённые стыки: ведь RR будет выбирать лучшим ближайший к нему маршрут. И его же будет анонсировать всем. Впрочем, эта сеть по совокупности недостатков такой архитектуры уже перестраивается.

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

    Пожалуй, дам ещё один совет (впрочем, и это тоже описано в упомянутом RFC): если вы строите узел распределённой сети на основе anycast, обязательно обзаведитесь на этом узле если не FullView (в те Cisco, которые у нас стоят в регионах, 500 килопрефиксов не влезает), то маршрутом по умолчанию — обязательно! Случаи несимметричной маршрутизации в интернете встречаются сплошь и рядом, а мы совсем не хотим оставлять пользователя перед чёрным экраном из-за чёрной дыры в маршрутизации.

    Так, кажется я ещё в требованиях упоминал про возможность определения «прилипания» пользователя к узлу. Это тоже реализовано. :) Для того, чтобы провайдер мог определить, на какой узел шлёт (или может слать пользователей), анонсы со всех наших узлов помечены маркировочным community. А их значения — описаны в нашей IRR-записи в RIPE DB. Соответственно, если вы приняли префикс с меткой 57629:101, знайте, что вы ходите в Москву.

    Есть и другой способ, которым мы пользуемся: попинговать IP-адрес под вопросом с источника в anycast-сети. Если пакет вернулся (мы получили ответ на свой пинг), значит клиент обслуживается с данного узла. В теории, это означает, что надо перебрать все узлы, но на практике мы достаточно точно можем предсказать, где абонент обслуживается. А если пользователь не пингуется вообще (я же сам про это и написал выше, да?)? Не проблема! Как правило, в этой же подсети есть роутер, который пингуется. А нам этого вполне достаточно.

    Что ж, на узел мы пришли. Но ведь никто же не думает, что у нас на одном узле только один сервер? А раз так, то надо как-то распределить запросы между ними. Но эта тема — для другой статьи, если конечно это вам интересно.
    Онлайн-кинотеатр ivi
    79,00
    Компания
    Поделиться публикацией

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

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

      0
      небольшой оффтоп, заинтересовало что вы за ресурс, зашел посмотреть:
      О нас:

      В первый же день без какой-либо рекламы наш сайт посетили 180 000 человек, что делает запуск ivi.ru самым успешным стартом за всю историю существования российского интернета.
      ...
      Подскажите как вы добились таких результатов без рекламы?
      На вскидку приходит вариант через поисковые системы — но ведь для этого нужно время чтобы сайт был проиндексирован ими,
      в первый день быть проиндексированым и попасть в выдачу маловероятно.
        0
        Для меня это некая данность из истории. На самом деле, там был такой своеобразный хабраэффект — об ivi.ru вышел репортаж в программе Вести. Может, кто из старожителей ответит точнее.
          +1
          Как ни банально звучит, это всё благодаря СМИ. Ну и Хабр дал довольно много благодаря вот этому посту: habrahabr.ru/post/85650/
            +1
            Так всётаки реклама была… а я уж подумал какоето чудо :)
              0
              Формально — это не реклама, т.к. оплачено не было.
          +3
          Спасибо за статью.

          Позволю себе несколько замечаний:

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

          — проблема с с днс-балансировкой действительно есть, но несколько преувеличена. У подавляющего большинства пользователей используется резолвер либо с квартирного роутера, либо провайдера. Проблема с крупными днс, типа гугловых 8.8.8.8 была бы значимой, если бы эти днс сами не использовали бы anycast (сюрприз ;) ). А так на Ваш днс сервер придет запрос с резолвера, который в сетевом плане близок к конечному пользователю, можете смело отдавать ему IP ближайшего сервера — пользователь не расстроится.

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

          Гибридное решение для видео-cdn, сглаживающее недостатки рассмотренных вариантов — использовать anycast для редиректоров, которые будут балансить трафик на нужные сервера.
            +1
            Да, в точку. По всем пунктам. :) Думаю, всё сойдётся, когда я напишу про устройство самого регионального узла. Там станет понятно, как именно мы всё компенсируем.
            Пока что — обратите внимание: если контент на узле не найден — абонент отправляется в Москву.

            Но главная проблема ДНС-балансировки — это инертность. Ждать 2 недели (!!!) пока абоненты перестанут приходить на узел — недопустимо. 2 недели — это у нас был опыт изменения адресов в ДНС. Ждали 2 недели, пока нагрузка по старым адресам пропадёт. И это при TTL 15 минут.
              0
              гугловый 8.8.8.8 поддерживает eDNS client subnet ответы, таким образом информация об адресе клиента не теряется
                0
                Круто! Т.е. и DNS надо подстраивать под google? А кэширует ответы он тоже с учётом подсети? А другие «альтернативные» DNS тоже поддерживают такой механизм?
                Нет уж, там где стандарты кончились, стабильности и предсказуемости нет.
                  0
                  да, свой dns должен поддерживать edns-client-subnet, но поскольку для поддержки geo-dns бинд все равно надо патчить, то это не большая проблема
                  конечным пользователям делать ничего не надо
                  кешируют ответы они с учетом подсети, да

                  вот презентация того как акамаи стало легче жить после реализации edns-client-subnet гуглом и опенднс:
                  www.sanog.org/resources/sanog24/akamai-mj-end-user-mapping-sanog.pdf
                    0
                    Стройная система костылей и подпорок? ;) И проблему закэшированного ответа это всё равно не решает. Как и проблему выбора узла, куда балансировать.
                    А если я захочу слить зону, скажем, в RIPN DNS?
                    Это, конечно, моё субъективное ИМХО, но DNS-балансировка — это зло, пока что подтверждаемое практикой.
                      0
                      Используем в CDNvideo эту фичу, прекрасно работает!
                  +1
                  С редиректами есть очень неприятная проблема: локальные провайдеры не всегда пирятся друг с другом. Например, в Новосибирске есть аж 4 разных точки пиринга. Если ваш сервер не доступен напрямую хотя бы с одной из них — то пользователь будет ходить в него через Москву.

                  Второй момент — далеко не всегда можно по IP адресу определить регион пользователя. У тех же сотовых операторов айпишники по всей стране назначаются, блоки адресов «плавают» от Владивостока к Москве. В этом случае геобаза тоже никак не поможет.

                  Оба варианта закрываются редиректором, адрес которого эникастят, как вы и сказали. Так что своим комментарием я хочу добавить ваш, чтобы другие читатели ознакомились с этой гранью проблемы.
                  0
                  Проблема с крупными днс, типа гугловых 8.8.8.8 была бы значимой, если бы эти днс сами не использовали бы anycast (сюрприз ;) )

                  сервис DNS это кажется самый крупный «пользователь» «услуги» AnyCast, все рутовые сервера X.root-servers.net используют anycast.
                    0
                    Ставьте TTL 1 и будет вам счастье — это раз.
                    Я тут писал статью про dns хак. Смысл в том чтоб dns определенного ДЦ отдает IP только своего ДЦ это два.

                    Рудиректить в Москву имхо криво, можнож nginx-proxy, прокачать файл локально и потом его отдавать клиенту. Заодно и контент приедет в нужный ДЦ.

                      +1
                      А толку-то, если абонентское оборудование игнорирует TTL? Кстати, говорят, что гуглоднс тоже, но сам я такого в нём не видел.
                      Зачем проксировать? Чтобы надо было каналы регионы строить? Нет, спасибо! При архитектуре с редиректом каналы не нужны, а задержка будет та же, если не больше. К тому же, если сейчас служебный канал до узла упадёт, то обслуживание абонентов продолжится. А если проксировать — при падении этого канальчика надо будет класть весь узел, чтобы не портить обслуживание.
                      0
                      А почему не пинговать(http) свои ноды со стороны клиента ну и делать неболошой кеш списка на клиенте этих нод? Наверняка у вас не так уж и много этих нод(20-30). Получается это самое честное определение ближайшей ноды. Да, код на клиенте, но все по чесноку получается, так вроде стим работает от Valve.
                        +1
                        Код будет очень тяжелый. К тому же возникнет другая проблема: где взять столько IPv4 адресов в наше нелёгкое время?
                        И не забывайте, Стим — это «толстый клиент», а у нас, даже приложения для ТВ — это «тонкий клиент». Javascript, конечно вырос, но всё равно.
                        Опять же: если с клиента «пинговать» все узлы, то как скоро начнётся кино? И ведь каждый просмотр надо будет начинать с пропинговки: как оно там сейчас? В общем, очень тяжёлое решение выйдет.
                          0
                          Не очень понял про ipv4 адреса, а в чем с ними проблема? Вот к примеру уже написанное на Javascript speedof.me/api.html Google сервисы вроде так еще делают, скачивают картинку 1на1 пиксель.
                            0
                            Чтобы направить клиента на несколько узлов, каждый узел должен иметь свои глобально маршрутизируемые адреса (в случае anycast — нет). Чтобы анонсировать в BGP, нужно по /24 на каждый узел. Умножаем на количество узлов. Получаем, что нам столько не дадут.
                            Альтернативы? Провайдерские адреса. Т.е. каждый провайдер, подключенный к узлу, должен будет дать для всех серверов этого узла адреса. Уже тяжело администрировать (а в случае с IX — это просто нереально). Иначе трафик будет ходить неоптимальным маршрутом для тех провайдеров, которые своих адреса не дали. И по-любому, балансировщик должен будет учитывать не только узлы, но и откуда пользователь ломится, чтобы выбрать соответствующий IP-адрес этого узла.
                            Жуть с ружжом и бабка со стингером. :(
                              0
                              /24 плохая практика, много операторов, как и Вы в прочем, имеют устаревшее оборудование, куда не лезет нынешний fv и обрезают его до /23 или /22. Что может давать неприятные сюрпризы.
                                0
                                Я не говорил, что у нас устаревшее. ;) Просто памяти мало.
                                Да, есть такой риск. Но на практике пока что обнаружен не был. Ну, а если кто вдруг обрезает, тот пойдёт по /22 или default в Москву. А там — как апстрим решит.
                            0
                            обратите внимание на cedexis, у них код radar тега асинхронно тестирует время ответа/скорость до публичных и приватных cdn/cloud сервисов, и на основе этих и многих других (если требуется) данных их fusion dns перекидывает cname по заданной логике

                            но проблема с вечным ttl на домашних роутерах остается, к сожалению :(
                            +1
                            Все бы хорошо, если бы клиент мог просто поменять url, вставив нужное имя сервера. Но обычно url в случае hls или dash (для примера) ведут на тектовой фаил, в котором указаны url (абсолютные или относительные) до сегментов. А уж тут мы не в силах их менять на стороне клиента.
                            –3
                            TTL не игнорируют — работает отлично — проверенно!!!
                              +2
                              Нужно больше восклицательных знаков для пущей убедительности. ;)
                              [grammar-nazi]И, извините, но правильно писать проверено.[/grammar-nazi]
                                0
                                Увы, если б так! :(
                                0
                                Очень интересно!
                                  0
                                  CDN из Сколкова — это наверное мы (CDNvideo)? :) Если да, то у нас при определении оптимального узла, кроме скорости ping, куча другой информации используется. В том числе и информация, получаемая по BGP от операторов — правда, мы при принятии решения о маршрутизации не полагаемся только на нее, т.к. считаем, что для видео надо выбирать не самый короткий (как в случае с Anycast), а канал с наибольшей пропускной способностью и надежностью.

                                  Было бы здорово, если бы Вы протестировали нашу CDN и сравнили результаты двух подходов. И опубликовали бы результаты на Хабре :)
                                    +1
                                    Ярослав, у меня дежа вю, что тестировали. ;)
                                    Есть две мысли по вашем поводу:
                                    1) чем больше параметров, тем сложнее расчет. Т.е. дольше. И больше точек отказа. А распасовщик, поди, централизованный, в Москве?
                                    2) сетевики провайдеров не дураки, и сами следят за своими каналами. Поэтому (условно) BGP можно принять как источник информации о каналах. Поэтому любые навороты — не нужны. Ну кроме как в маркетинговых целях.

                                    Да, anycast-балансировка страдает некоторой неопределённостью. Но это компенсируется простотой решения и обслуживания.
                                      0
                                      Максим, вы нас тестировали в 2011 году, когда мы еще маленькими были. Сейчас мы на существенно более продвинутом уровне находимся, по крайней мере, нам так кажется :) Рассказал бы подробнее, но маркетинг тут запрещен.

                                      Про качество балансировки могу сказать, что, по заверению наших клиентов, у нас самый низкий процент ошибок из всех российских и зарубежных CDN при отдаче трафика на Россию. Они тестировали это под нагрузкой во время ЧМ-2014 по футболу, у нас результат был 2%, у конкурентов 3-5%. Если конкретно по замечаниям:

                                      1 — Мы делаем много предварительных расчетов таблицы маршрутизации, чтобы в момент прихода пакета наложить на нее информацию реального времени и быстро принять решение о балансировке. Распасовщиков несколько. Единой точки отказа на сети нет.
                                      2 — Конечно, не дураки, но иногда не успевают уследить за перегрузкой своих каналов, так что если биться за доли процента отказов, то лучше исключить и эту вероятность тоже. Хотя отсутствие наворотов в вашей схеме — это плюс, не спорю.
                                  • НЛО прилетело и опубликовало эту надпись здесь
                                      0
                                      С трейсом всё хуже, чем с пингами. Трейс и до провайдера может не дойти. Echo request / reply чаще пропускается, чем TTL exceeded. Да и зачастую на роутерах no ip unreachables стоит, что правильно.
                                      Опять же, трейс строить дольше, т.е. задержка перед отдачей контента ещё увеличится. В общем — мимо денег.
                                      0
                                      Я правильно понимаю, что такой anycast возможен только при наличии выделенных каналов? Или можно в какой-нибудь Томск пробросить кусок своей AS поверх TCP?
                                        0
                                        Вопрос не понял :(
                                        У нас выделенных каналов между городами нет. Даже «тонкий» канал, по которому управление идёт, для работы узла необязателен. Поэтому получается очень высокая устойчивость всей системы.
                                        Пробросить кусок AS — можно и без anycast.
                                          0
                                          Я был уверен, что для организации собственной AS вам нужна связность по L2 между всеми точками выхода. Я неправ?

                                          Можно просто зарегать AS, понаарендовать /27 префиксов в разных городах и будет такая ячеистая AS-ка, которая не имеет связности?
                                            0
                                            нененене. Для собственной AS не нужно ничего, кроме BGP-роутера. Даже необязательно — аппаратного. :)
                                            /27 арендовать бессмысленно, ибо по RFC какому-то префиксы длиной больше /24 положено отбрасывать.

                                            А почему, собсно, без связности? Кто сказал, что связность не может быть через другие AS? Был вопрос, сколько AS делать, но по размышлению поняли, что одной автономки нам хватит за глаза.
                                              0
                                              Т.е. фактически у вас арендован префикс /24 и вы его анонсируете в куче мест?

                                              Я почему-то думал, что AS должна быть односвязна.
                                                0
                                                У нас свой /22. :) И из него мы /24 взяли в качестве anycast-анонса

                                                Про автономки — в общем-то, распространённое заблуждение.
                                                  +1
                                                  про автономки мало публичной информации для нубов, а руками пощупать BGP просто так невозможно.

                                                  Это же не два роутера с тремя компьютерами, которые можно на столе собрать за 1000 долларов. Тут банальная аренда /22 обойдется в огого. А уж последствия неудачного анонса в мир так и того больше =)
                                                    0
                                                    Если есть сильное желание, вы можете поднять тестовый стенд на виртуалках, или использовать эмуляторы сети от cisco.
                                                    Есть диапазон AS с 64512 до 65534 для внутренних сетей.
                                                    Но это будет песочница, без связи с внешним миром.

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

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