Comments 41
небольшой оффтоп, заинтересовало что вы за ресурс, зашел посмотреть:
На вскидку приходит вариант через поисковые системы — но ведь для этого нужно время чтобы сайт был проиндексирован ими,
в первый день быть проиндексированым и попасть в выдачу маловероятно.
О нас:Подскажите как вы добились таких результатов без рекламы?
…
В первый же день без какой-либо рекламы наш сайт посетили 180 000 человек, что делает запуск ivi.ru самым успешным стартом за всю историю существования российского интернета.
...
На вскидку приходит вариант через поисковые системы — но ведь для этого нужно время чтобы сайт был проиндексирован ими,
в первый день быть проиндексированым и попасть в выдачу маловероятно.
0
Для меня это некая данность из истории. На самом деле, там был такой своеобразный хабраэффект — об ivi.ru вышел репортаж в программе Вести. Может, кто из старожителей ответит точнее.
0
Как ни банально звучит, это всё благодаря СМИ. Ну и Хабр дал довольно много благодаря вот этому посту: habrahabr.ru/post/85650/
+1
Спасибо за статью.
Позволю себе несколько замечаний:
— для очень маленьких файлов редиректы — разумеется, зло. Время (и ресурсы) на генерацию редиректа сопоставимы с обслуживанием собственно файла. Для видео-cdn же редиректы — абсолютно нормальная практика. Сессии там длятся минутами, и несколько десятков миллисекунд на редирект мало что способны повредить. Зато на редиректоре есть полный и абсолютный контроль над трафиком — полиси доступа, балансировка загрузки на любом уровне и т.д.
— проблема с с днс-балансировкой действительно есть, но несколько преувеличена. У подавляющего большинства пользователей используется резолвер либо с квартирного роутера, либо провайдера. Проблема с крупными днс, типа гугловых 8.8.8.8 была бы значимой, если бы эти днс сами не использовали бы anycast (сюрприз ;) ). А так на Ваш днс сервер придет запрос с резолвера, который в сетевом плане близок к конечному пользователю, можете смело отдавать ему IP ближайшего сервера — пользователь не расстроится.
— anycast для cdn рулит, спору нет. До тех пор, пока есть возможность на каждом узле обслуживать все-все пришедшие запросы. Т.е. когда как минимум хватает места на винтах серверов, чтобы разместить весь контент. Иначе начинаются проблемы — надо либо найти способ обслужить запрос локально, проксируя его на другой сервер, существенно удлинняя цепочку трафика, либо возвращаться к услугам редиректов — по сути, держать две системы cdn.
Гибридное решение для видео-cdn, сглаживающее недостатки рассмотренных вариантов — использовать anycast для редиректоров, которые будут балансить трафик на нужные сервера.
Позволю себе несколько замечаний:
— для очень маленьких файлов редиректы — разумеется, зло. Время (и ресурсы) на генерацию редиректа сопоставимы с обслуживанием собственно файла. Для видео-cdn же редиректы — абсолютно нормальная практика. Сессии там длятся минутами, и несколько десятков миллисекунд на редирект мало что способны повредить. Зато на редиректоре есть полный и абсолютный контроль над трафиком — полиси доступа, балансировка загрузки на любом уровне и т.д.
— проблема с с днс-балансировкой действительно есть, но несколько преувеличена. У подавляющего большинства пользователей используется резолвер либо с квартирного роутера, либо провайдера. Проблема с крупными днс, типа гугловых 8.8.8.8 была бы значимой, если бы эти днс сами не использовали бы anycast (сюрприз ;) ). А так на Ваш днс сервер придет запрос с резолвера, который в сетевом плане близок к конечному пользователю, можете смело отдавать ему IP ближайшего сервера — пользователь не расстроится.
— anycast для cdn рулит, спору нет. До тех пор, пока есть возможность на каждом узле обслуживать все-все пришедшие запросы. Т.е. когда как минимум хватает места на винтах серверов, чтобы разместить весь контент. Иначе начинаются проблемы — надо либо найти способ обслужить запрос локально, проксируя его на другой сервер, существенно удлинняя цепочку трафика, либо возвращаться к услугам редиректов — по сути, держать две системы cdn.
Гибридное решение для видео-cdn, сглаживающее недостатки рассмотренных вариантов — использовать anycast для редиректоров, которые будут балансить трафик на нужные сервера.
+3
Да, в точку. По всем пунктам. :) Думаю, всё сойдётся, когда я напишу про устройство самого регионального узла. Там станет понятно, как именно мы всё компенсируем.
Пока что — обратите внимание: если контент на узле не найден — абонент отправляется в Москву.
Но главная проблема ДНС-балансировки — это инертность. Ждать 2 недели (!!!) пока абоненты перестанут приходить на узел — недопустимо. 2 недели — это у нас был опыт изменения адресов в ДНС. Ждали 2 недели, пока нагрузка по старым адресам пропадёт. И это при TTL 15 минут.
Пока что — обратите внимание: если контент на узле не найден — абонент отправляется в Москву.
Но главная проблема ДНС-балансировки — это инертность. Ждать 2 недели (!!!) пока абоненты перестанут приходить на узел — недопустимо. 2 недели — это у нас был опыт изменения адресов в ДНС. Ждали 2 недели, пока нагрузка по старым адресам пропадёт. И это при TTL 15 минут.
+1
гугловый 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
конечным пользователям делать ничего не надо
кешируют ответы они с учетом подсети, да
вот презентация того как акамаи стало легче жить после реализации edns-client-subnet гуглом и опенднс:
www.sanog.org/resources/sanog24/akamai-mj-end-user-mapping-sanog.pdf
0
Стройная система костылей и подпорок? ;) И проблему закэшированного ответа это всё равно не решает. Как и проблему выбора узла, куда балансировать.
А если я захочу слить зону, скажем, в RIPN DNS?
Это, конечно, моё субъективное ИМХО, но DNS-балансировка — это зло, пока что подтверждаемое практикой.
А если я захочу слить зону, скажем, в RIPN DNS?
Это, конечно, моё субъективное ИМХО, но DNS-балансировка — это зло, пока что подтверждаемое практикой.
0
Используем в CDNvideo эту фичу, прекрасно работает!
0
С редиректами есть очень неприятная проблема: локальные провайдеры не всегда пирятся друг с другом. Например, в Новосибирске есть аж 4 разных точки пиринга. Если ваш сервер не доступен напрямую хотя бы с одной из них — то пользователь будет ходить в него через Москву.
Второй момент — далеко не всегда можно по IP адресу определить регион пользователя. У тех же сотовых операторов айпишники по всей стране назначаются, блоки адресов «плавают» от Владивостока к Москве. В этом случае геобаза тоже никак не поможет.
Оба варианта закрываются редиректором, адрес которого эникастят, как вы и сказали. Так что своим комментарием я хочу добавить ваш, чтобы другие читатели ознакомились с этой гранью проблемы.
Второй момент — далеко не всегда можно по IP адресу определить регион пользователя. У тех же сотовых операторов айпишники по всей стране назначаются, блоки адресов «плавают» от Владивостока к Москве. В этом случае геобаза тоже никак не поможет.
Оба варианта закрываются редиректором, адрес которого эникастят, как вы и сказали. Так что своим комментарием я хочу добавить ваш, чтобы другие читатели ознакомились с этой гранью проблемы.
+1
Проблема с крупными днс, типа гугловых 8.8.8.8 была бы значимой, если бы эти днс сами не использовали бы anycast (сюрприз ;) )
сервис DNS это кажется самый крупный «пользователь» «услуги» AnyCast, все рутовые сервера X.root-servers.net используют anycast.
0
Ставьте TTL 1 и будет вам счастье — это раз.
Я тут писал статью про dns хак. Смысл в том чтоб dns определенного ДЦ отдает IP только своего ДЦ это два.
Рудиректить в Москву имхо криво, можнож nginx-proxy, прокачать файл локально и потом его отдавать клиенту. Заодно и контент приедет в нужный ДЦ.
Я тут писал статью про dns хак. Смысл в том чтоб dns определенного ДЦ отдает IP только своего ДЦ это два.
Рудиректить в Москву имхо криво, можнож nginx-proxy, прокачать файл локально и потом его отдавать клиенту. Заодно и контент приедет в нужный ДЦ.
0
А толку-то, если абонентское оборудование игнорирует TTL? Кстати, говорят, что гуглоднс тоже, но сам я такого в нём не видел.
Зачем проксировать? Чтобы надо было каналы регионы строить? Нет, спасибо! При архитектуре с редиректом каналы не нужны, а задержка будет та же, если не больше. К тому же, если сейчас служебный канал до узла упадёт, то обслуживание абонентов продолжится. А если проксировать — при падении этого канальчика надо будет класть весь узел, чтобы не портить обслуживание.
Зачем проксировать? Чтобы надо было каналы регионы строить? Нет, спасибо! При архитектуре с редиректом каналы не нужны, а задержка будет та же, если не больше. К тому же, если сейчас служебный канал до узла упадёт, то обслуживание абонентов продолжится. А если проксировать — при падении этого канальчика надо будет класть весь узел, чтобы не портить обслуживание.
+1
А почему не пинговать(http) свои ноды со стороны клиента ну и делать неболошой кеш списка на клиенте этих нод? Наверняка у вас не так уж и много этих нод(20-30). Получается это самое честное определение ближайшей ноды. Да, код на клиенте, но все по чесноку получается, так вроде стим работает от Valve.
0
Код будет очень тяжелый. К тому же возникнет другая проблема: где взять столько IPv4 адресов в наше нелёгкое время?
И не забывайте, Стим — это «толстый клиент», а у нас, даже приложения для ТВ — это «тонкий клиент». Javascript, конечно вырос, но всё равно.
Опять же: если с клиента «пинговать» все узлы, то как скоро начнётся кино? И ведь каждый просмотр надо будет начинать с пропинговки: как оно там сейчас? В общем, очень тяжёлое решение выйдет.
И не забывайте, Стим — это «толстый клиент», а у нас, даже приложения для ТВ — это «тонкий клиент». Javascript, конечно вырос, но всё равно.
Опять же: если с клиента «пинговать» все узлы, то как скоро начнётся кино? И ведь каждый просмотр надо будет начинать с пропинговки: как оно там сейчас? В общем, очень тяжёлое решение выйдет.
+1
Не очень понял про ipv4 адреса, а в чем с ними проблема? Вот к примеру уже написанное на Javascript speedof.me/api.html Google сервисы вроде так еще делают, скачивают картинку 1на1 пиксель.
0
Чтобы направить клиента на несколько узлов, каждый узел должен иметь свои глобально маршрутизируемые адреса (в случае anycast — нет). Чтобы анонсировать в BGP, нужно по /24 на каждый узел. Умножаем на количество узлов. Получаем, что нам столько не дадут.
Альтернативы? Провайдерские адреса. Т.е. каждый провайдер, подключенный к узлу, должен будет дать для всех серверов этого узла адреса. Уже тяжело администрировать (а в случае с IX — это просто нереально). Иначе трафик будет ходить неоптимальным маршрутом для тех провайдеров, которые своих адреса не дали. И по-любому, балансировщик должен будет учитывать не только узлы, но и откуда пользователь ломится, чтобы выбрать соответствующий IP-адрес этого узла.
Жуть с ружжом и бабка со стингером. :(
Альтернативы? Провайдерские адреса. Т.е. каждый провайдер, подключенный к узлу, должен будет дать для всех серверов этого узла адреса. Уже тяжело администрировать (а в случае с IX — это просто нереально). Иначе трафик будет ходить неоптимальным маршрутом для тех провайдеров, которые своих адреса не дали. И по-любому, балансировщик должен будет учитывать не только узлы, но и откуда пользователь ломится, чтобы выбрать соответствующий IP-адрес этого узла.
Жуть с ружжом и бабка со стингером. :(
0
/24 плохая практика, много операторов, как и Вы в прочем, имеют устаревшее оборудование, куда не лезет нынешний fv и обрезают его до /23 или /22. Что может давать неприятные сюрпризы.
0
обратите внимание на cedexis, у них код radar тега асинхронно тестирует время ответа/скорость до публичных и приватных cdn/cloud сервисов, и на основе этих и многих других (если требуется) данных их fusion dns перекидывает cname по заданной логике
но проблема с вечным ttl на домашних роутерах остается, к сожалению :(
но проблема с вечным ttl на домашних роутерах остается, к сожалению :(
0
Все бы хорошо, если бы клиент мог просто поменять url, вставив нужное имя сервера. Но обычно url в случае hls или dash (для примера) ведут на тектовой фаил, в котором указаны url (абсолютные или относительные) до сегментов. А уж тут мы не в силах их менять на стороне клиента.
+1
TTL не игнорируют — работает отлично — проверенно!!!
-3
Очень интересно!
0
CDN из Сколкова — это наверное мы (CDNvideo)? :) Если да, то у нас при определении оптимального узла, кроме скорости ping, куча другой информации используется. В том числе и информация, получаемая по BGP от операторов — правда, мы при принятии решения о маршрутизации не полагаемся только на нее, т.к. считаем, что для видео надо выбирать не самый короткий (как в случае с Anycast), а канал с наибольшей пропускной способностью и надежностью.
Было бы здорово, если бы Вы протестировали нашу CDN и сравнили результаты двух подходов. И опубликовали бы результаты на Хабре :)
Было бы здорово, если бы Вы протестировали нашу CDN и сравнили результаты двух подходов. И опубликовали бы результаты на Хабре :)
0
Ярослав, у меня дежа вю, что тестировали. ;)
Есть две мысли по вашем поводу:
1) чем больше параметров, тем сложнее расчет. Т.е. дольше. И больше точек отказа. А распасовщик, поди, централизованный, в Москве?
2) сетевики провайдеров не дураки, и сами следят за своими каналами. Поэтому (условно) BGP можно принять как источник информации о каналах. Поэтому любые навороты — не нужны. Ну кроме как в маркетинговых целях.
Да, anycast-балансировка страдает некоторой неопределённостью. Но это компенсируется простотой решения и обслуживания.
Есть две мысли по вашем поводу:
1) чем больше параметров, тем сложнее расчет. Т.е. дольше. И больше точек отказа. А распасовщик, поди, централизованный, в Москве?
2) сетевики провайдеров не дураки, и сами следят за своими каналами. Поэтому (условно) BGP можно принять как источник информации о каналах. Поэтому любые навороты — не нужны. Ну кроме как в маркетинговых целях.
Да, anycast-балансировка страдает некоторой неопределённостью. Но это компенсируется простотой решения и обслуживания.
+1
Максим, вы нас тестировали в 2011 году, когда мы еще маленькими были. Сейчас мы на существенно более продвинутом уровне находимся, по крайней мере, нам так кажется :) Рассказал бы подробнее, но маркетинг тут запрещен.
Про качество балансировки могу сказать, что, по заверению наших клиентов, у нас самый низкий процент ошибок из всех российских и зарубежных CDN при отдаче трафика на Россию. Они тестировали это под нагрузкой во время ЧМ-2014 по футболу, у нас результат был 2%, у конкурентов 3-5%. Если конкретно по замечаниям:
1 — Мы делаем много предварительных расчетов таблицы маршрутизации, чтобы в момент прихода пакета наложить на нее информацию реального времени и быстро принять решение о балансировке. Распасовщиков несколько. Единой точки отказа на сети нет.
2 — Конечно, не дураки, но иногда не успевают уследить за перегрузкой своих каналов, так что если биться за доли процента отказов, то лучше исключить и эту вероятность тоже. Хотя отсутствие наворотов в вашей схеме — это плюс, не спорю.
Про качество балансировки могу сказать, что, по заверению наших клиентов, у нас самый низкий процент ошибок из всех российских и зарубежных CDN при отдаче трафика на Россию. Они тестировали это под нагрузкой во время ЧМ-2014 по футболу, у нас результат был 2%, у конкурентов 3-5%. Если конкретно по замечаниям:
1 — Мы делаем много предварительных расчетов таблицы маршрутизации, чтобы в момент прихода пакета наложить на нее информацию реального времени и быстро принять решение о балансировке. Распасовщиков несколько. Единой точки отказа на сети нет.
2 — Конечно, не дураки, но иногда не успевают уследить за перегрузкой своих каналов, так что если биться за доли процента отказов, то лучше исключить и эту вероятность тоже. Хотя отсутствие наворотов в вашей схеме — это плюс, не спорю.
0
UFO just landed and posted this here
С трейсом всё хуже, чем с пингами. Трейс и до провайдера может не дойти. Echo request / reply чаще пропускается, чем TTL exceeded. Да и зачастую на роутерах no ip unreachables стоит, что правильно.
Опять же, трейс строить дольше, т.е. задержка перед отдачей контента ещё увеличится. В общем — мимо денег.
Опять же, трейс строить дольше, т.е. задержка перед отдачей контента ещё увеличится. В общем — мимо денег.
0
Я правильно понимаю, что такой anycast возможен только при наличии выделенных каналов? Или можно в какой-нибудь Томск пробросить кусок своей AS поверх TCP?
0
Вопрос не понял :(
У нас выделенных каналов между городами нет. Даже «тонкий» канал, по которому управление идёт, для работы узла необязателен. Поэтому получается очень высокая устойчивость всей системы.
Пробросить кусок AS — можно и без anycast.
У нас выделенных каналов между городами нет. Даже «тонкий» канал, по которому управление идёт, для работы узла необязателен. Поэтому получается очень высокая устойчивость всей системы.
Пробросить кусок AS — можно и без anycast.
0
Я был уверен, что для организации собственной AS вам нужна связность по L2 между всеми точками выхода. Я неправ?
Можно просто зарегать AS, понаарендовать /27 префиксов в разных городах и будет такая ячеистая AS-ка, которая не имеет связности?
Можно просто зарегать AS, понаарендовать /27 префиксов в разных городах и будет такая ячеистая AS-ка, которая не имеет связности?
0
нененене. Для собственной AS не нужно ничего, кроме BGP-роутера. Даже необязательно — аппаратного. :)
/27 арендовать бессмысленно, ибо по RFC какому-то префиксы длиной больше /24 положено отбрасывать.
А почему, собсно, без связности? Кто сказал, что связность не может быть через другие AS? Был вопрос, сколько AS делать, но по размышлению поняли, что одной автономки нам хватит за глаза.
/27 арендовать бессмысленно, ибо по RFC какому-то префиксы длиной больше /24 положено отбрасывать.
А почему, собсно, без связности? Кто сказал, что связность не может быть через другие AS? Был вопрос, сколько AS делать, но по размышлению поняли, что одной автономки нам хватит за глаза.
0
Т.е. фактически у вас арендован префикс /24 и вы его анонсируете в куче мест?
Я почему-то думал, что AS должна быть односвязна.
Я почему-то думал, что AS должна быть односвязна.
0
У нас свой /22. :) И из него мы /24 взяли в качестве anycast-анонса
Про автономки — в общем-то, распространённое заблуждение.
Про автономки — в общем-то, распространённое заблуждение.
0
про автономки мало публичной информации для нубов, а руками пощупать BGP просто так невозможно.
Это же не два роутера с тремя компьютерами, которые можно на столе собрать за 1000 долларов. Тут банальная аренда /22 обойдется в огого. А уж последствия неудачного анонса в мир так и того больше =)
Это же не два роутера с тремя компьютерами, которые можно на столе собрать за 1000 долларов. Тут банальная аренда /22 обойдется в огого. А уж последствия неудачного анонса в мир так и того больше =)
+1
Sign up to leave a comment.
По городам и весям или как мы балансируем между узлами CDN