Pull to refresh

Comments 41

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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