Как стать автором
Обновить

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

НЛО прилетело и опубликовало эту надпись здесь
В этом нет необходимости: при помощи bgp мы и так получаем ближайший cdn и, соответственно, dns сервер. Плюс bgp, в отличии от Geo-IP, в случае каких-любо изменений в сети перенастроит всё самостоятельно.
А как насчет того, что при anycast балансировке вы имеете погрешность на определение конечного пользователя из-за того, что он использует «далекий» резолвер?
Для наших текущих рынков (Россия и Украина) такая ситуация на практике крайне маловероятна. Возможно, в дальнейшем что-то придётся придумывать дополнительно.
Тогда к чему для такого маленького разброса сегмента делать CDN?!
1. Уменьшение времени отклика.
2. Сокращение нагрузки за счёт ещё одного уровня во всей системе (вертикальное масштабирование).
2. Защита от DDoS.
3. Обкатывание технологий. Есть планы по развитию :)
Вы имеете в виду случай, если пользователь прописал у себя, например, гугловский днс?
Тогда как раз схема с GeoIP будет страдать — т.к. она всех будет считать находящимся совсем в других местах и будет предлагать далекое «зеркало».
В данном случае у всех все резолвится одинаково, но трафик идет на более близкое зеркало — за этим следит NOC провайдера.
У GeoIP есть много своих проблем, не спорю. Как вы боретесь с тем, что по anycast вы определяете клиента на базе адреса резолвера, а не клиента?
Не очень понял вас.
С использованием anycast мне не нужно определять клиента — все клиенты получают один и тот же ip-адрес сайта, условно говоря 1.2.3.4.
Но этот адрес физически «размазан» по разным ДЦ. Клиент об этом не знает никак.
Он просто отправляет запрос на этот ip 1.2.3.4, оборудование провайдера думает где этот ip находится и видит, что в сеть 1.2.3.0/24 можно попасть разными маршрутами. Идет ближайшим и попадает на зеркало сайта.

То есть определение куда направить пользователя происходит не по адресу использованного им резолвера, а по его реальному ip адресу.
>Но этот адрес физически «размазан» по разным ДЦ.
Скорее уж логически…

Советую вам более детально изучить данный вопрос, так как это работает несколько не так как вы описали. Клиент для доступа к сайту первоначально обращается не к вам, а к резолверу своего провайдера или любому другому, который у него прописан. Резолвер в свою очередь идет на ваш anycast адрес, который один для всех. Ваш сервер принимает адрес резолвера за адрес клиента — точность позиционирования ломается. Не забывайте, что у вас только DNS Anycast, а не HTTP сервер. У вас был практический опыт использования TCP Anycast, о котором вы рассказали в своем примере.
Будут большие проблемы в регионах. Тот же Мегафон растянул свою ASку на всю страну, но, т.к. белых адресов мало, они в течение суток «мигрируют» с востока на запад страны. И как тут GeoIP пользоваться?
Если не секрет, какой минимальный размер блока IP под это дело? (/24? /22?)

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

Заранее спасибо!

BGP AS минимально /24.
/24 минимально

Основная задача — это выдавать контент целевому пользователю как можно быстрее. Наша CDN помогает реализовать эту задачу следующими методами:
1. Кеширование максимально больше данных ближе к пользователю.
2. Уменьшить нагрузку на основные сервера, соответственно выделить больше процессорных ресурсов на пользователя.
3. Снизить последствия DDoSа и, как следствие, недоступности сервиса.
краткое содержание статьи:

1, 2, 3, 4. какие клёвые технологии, почитайте про них тут, тут и тут;
5. клёвое железо; минимальный конфиг openbgp, nginx, bind.

интересно, 23 человека, плюсанувших статью, прочитали её вообще?
Все сложные вещи состоят из простых :) Вся сложность в их сочетании.
Интересно было почитать. Статья вызвала двоякие чувства.

Статья безусловно полезная если
1) основной траффик идет с одного региона
2) у вас есть BGP, но нету денег на нормальное железо
3) нужна специфическая статистика доступа по статике или Вы считаете, что сдн должна и динамика кэшировать
4) не проблема поднятие нескольких каналов с BGP линками
5) вы не интересны людям, способным сделать (D)DOS

Если же хотя бы два из этих условий не выполняется — предложенный метод не есть оптимальным.
По пунктно аргументация:
1) если трафик с разных регионов — то даже при наличии своих трансатлантических каналов (ого ;) задержки выше, чем с локального датацентра
Вывод: GeoIP + BIND + несколько серверов на разных континентах эффективнее. У компаний, которые предоставляют CDN сервисы датацентры расхоложены в о всех основных узлах связанности интернет, они как правило включены в группы обмена траффиком, у них BIND привязан даже не к GeoIP а к BGP info
2 PPS этого решения несравненно ниже железных решений с использованием человеческих раутеров и Content Service Switch, что есть уровень в выше.
3 Если не нужна специфическая статистика — то как правило себестоимость эксплуатации специализированых сервисов CDN ниже при одинаковом качестве
4) вроде и так понятно
5) Каналы входят на прямую, и не используется никаких программных или аппаратных решений по защите от DOS.

По мотивации:
Во-первых, это не наш метод ;) — ну кто бы спорил ;)
Во-вторых, эти сети уже построены, и не факт, что они подходят вам по распределенности на все сто. — ну разве что случай, если у вас большая часть посетителей находится в компактном регионе.
Фраза «В случае своей CDN мы вольны где угодно размещать её узлы.», это конечно отлично, но получить 2 AS сейчас с мотивацией «нам нужен СДН» это из области трудновыполнимого, а для одной AS
В-третьих, мы вкладываем деньги в свою инфрастурктуру, а не в чужую. — достойный аргумент. По этому у меня есть собственная AS.
В-четвёртных, настроить свою CDN мы можем как угодно. Кешировать можно не только статические данные, но и динамические, например, данные для аннонимусов или общие данные. Такой гибкости нам ни одна коммерческая сеть в полном объёме не даст.
— аргумент понятен
Но, если честно я бы переобозвал статью. То что Вы описали — это не совсем CDN.
1) Трафик действительно идёт с одного региона (Евразия). Городить несколько ЦОДов пока нет смысла.

2) PPS этого решения на практике один узел CDN выдерживает гигабитную нагрузку (как раз после матча Россия-Азербайджан испытали очередной рекорд) и pps был в районе 80к пакетов в секунду (в одну сторону) при загрузке процессора менее 10%. Используются вот эти карточки ark.intel.com/ru/products/69655/Intel-Ethernet-Converged-Network-Adapter-X520-T2

3) На данном этапе да, но по нашим планам роста такой вариант даст свой профит в будущем.

4) А какие могут быть проблемы?

5) Вот как раз это решение и помогло нам выдержать несколько DDoS-ов на практике.

Немного не понял, зачем две AS? Мы пользуемся одной, что мы делаем не так? :)
Я пару дней подумал в фоне над вопросом. И всё-таки решил полностью согласится, что для ваших условий выбранный способ оптимальный. А смысла вести терменологический спор на супертонкостях определений нет.

Немного не понял, зачем две AS? Мы пользуемся одной, что мы делаем не так? :)
Для UDP все просто великолепно. Для TCP считалось, что при anyroute их нужно несколько в зависимости от основной топографии сети для того чтобы исправить проблемы на подобии следующих: Есть площадки А, Б. Клиенты, у которых исходящий трафик балансируется таким образом, что часть пакетов маршрутизируется в А, а часть в Б. В результате аолучается ситуация, когда TCP линк устанавливается с узлом, на который пришел syn (к примеру А), но получилось много ретранзмитов, изза того, что часть трафика ушла на Б. Легко посмотреть процент подобного паразитного трафика и ретранзмитов по каунтерам системя (извините в БЗД не знаю как, но уверен, что от линухов отличия мало).

В сети не редко встречаются ситуации, когда часть пакетов одной и той-же TCP сессии бегает через разные линки. К примеру больше года наблюдал как на www.asx.com.au часть трафика бегала через японию, а часть через филипины.К сожалению сейчас ситуацию повторить не смог.

Знакомый кошковед сказал мне, что я отстал от жизни, и сейчас никто робином не балансирует пакеты, балансируют либо по хешам сессий либо по хешам сетей. Так что сейчас вполне можно использовать anyroute для TCP. И однной AS достаточно.

По поводу DDOS,
С использованием умных железяк о них можно особо не беспокоится, но и без них тоже можно прожить. Атаки уровней 1-6 страшны (свякие синкфлуды, и прочее детство лечатся настройкой оси) только 0-day (чего никак не исправишь), Атаки 7 уровня по прежнему страшны. HTTPs у Вас нет, для защиты от slow-clients (что сейчас особенно популярно) community.qualys.com/blogs/securitylabs/2011/11/02/how-to-protect-against-slow-http-attacks, даже медленную отдачу боди можно детектить. По остальным типам — тоже можно найти средства.

Снимаю шляпу. Было полезно почитать и поучится еще одной альтернатиые.
Вы крутые :) сразу подошли к вопросу роста трафика радикально, это правильно.

У меня вопросы.

1. Вы рассматривали готовые CDN для ваших задач? NGENIX, например.

2. У вас только картинки и текст или ещё и видео-контент раздаётся? Видел у вас ссылки на Ютюб только, может пропустил чего.
Отвечаю:

1. Рассматривали. Они не очень хорошо подходят по наши планы. + Два узла мы разместили прямо в своём ЦОДе, снизив вероятность заДДоСивания его самого.

2. Картинки, стили, тексты и прочая статика + общие данные и данные для анонимов — тексты и JSON-ы.
Ясно, спасибо.
А как быть с нагрузкой на MySQL?
Если так же использовать CDN, то как быть с различной информацией на серверах, ведь в реальном времени не получится всё синхронизировать?
Если вы фанат BSD, то советую varnish вместо nginx.

nginx таки скорее сервер, а не кэш.

Много клевых фич — в планэ кэш-акселлератора nginx до него далеко.
Особенно клево для принудительного кэширования динамических страниц. Повырезать из запросов левые заголовки — куки, языки, кодировку и т.п., чтобы не было отдельной одного и того же в кэше.
Вот интересно, как вы решали задачу пофайлового сброса кэша при использование proxy_cache, который хранит по ключам, а не по URL? Вам же не только статику, но и динамику сбрасывать (или на динамику вы, в конечном итоге, забили?).
Такое ощущение, что вы наступили на большое количество граблей, но не стремитесь это рассказывать. Тот же Anycast может «страдать» потерей пакетов из-за перекидывания IP-адресов, в этом плане GeoIP все же надежнее. Или вы нашли какой-то идеальный Anycast?
Спрашиваю не из праздного интереса: Айри.рф строили, исходя из почти те же предпосылок, но решение оказалось технически другим, и, скорее всего, выигрывает перед вашим по функциональности / стоимости.
Я бы смотрел в сторону IPFS. Особенно, если статики реально много и запросов на нее тоже.
Тем более нынче можно встроить ipfsJS на сайт, и даже клиент без установленной ноды становится на время нодой распределенной сети и качает с других нод эту статику по возможности.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий