Comments 28
А как управляется нагрузка в BGP-управляемых CDN?
К примеру, куплен порт 10Г, а пришло трафика на 15Г?
К примеру, куплен порт 10Г, а пришло трафика на 15Г?
BGP никаким образом не может реагировать на нагрузку (этого нет в протоколе). Маршрутизаторы у ISP обычно имеют крайне сложный конфиг с очень сложными преференциями между стыками (например, не принимать анонсы от кого-то, или слать трафик туда-то на такие-то направления).
Эта область либо на ручном контроле (мониторинги, предсказания и т.д.), либо управляется очень специальным софтом с кучей эвристик.
С практической точки зрения, сетевой инженер изучит источник трафика и (если это легитимный трафик со специфичного направления) постарается изменить сетевую конфигурацию так, чтобы трафик с разных направлений распространялся равномерно.
Заметим, что CDN обычно трафик не принимают, а раздают — управлять исходящим трафиком проще — можно просто использовать несколько маршрутов через несколько аплинков. Один оказался перегружен — трафик идёт на другой.
На практике же, чтобы от любого дуновения DoS'а не превращаться в тыквы, делается достаточно большая полоса (например, трафика 10Гбит/с, а стык — 40), чтобы выдержать всплески. За такие всплески чаще всего приходится переплачивать, это да.
А вот объём резервирования на точках присутствия — это ещё один из параметров качества CDN.
Эта область либо на ручном контроле (мониторинги, предсказания и т.д.), либо управляется очень специальным софтом с кучей эвристик.
С практической точки зрения, сетевой инженер изучит источник трафика и (если это легитимный трафик со специфичного направления) постарается изменить сетевую конфигурацию так, чтобы трафик с разных направлений распространялся равномерно.
Заметим, что CDN обычно трафик не принимают, а раздают — управлять исходящим трафиком проще — можно просто использовать несколько маршрутов через несколько аплинков. Один оказался перегружен — трафик идёт на другой.
На практике же, чтобы от любого дуновения DoS'а не превращаться в тыквы, делается достаточно большая полоса (например, трафика 10Гбит/с, а стык — 40), чтобы выдержать всплески. За такие всплески чаще всего приходится переплачивать, это да.
А вот объём резервирования на точках присутствия — это ещё один из параметров качества CDN.
Был бы интересен краткий обзор/сравнение российских CDN.
Если верить вики, сейчас это Ростелеком, Мегафон, CDNvideo и NGENIX.
Если верить вики, сейчас это Ростелеком, Мегафон, CDNvideo и NGENIX.
Очень и очень дорого. Цены должны начинаться с $0.01 за GB.
Не хочу показаться грубым, но кому именно поставщики услуг должны делать такие цены, и почему?
Цены и меньше $0.01 за GB есть, на самом деле, не буду рекламировать, кого интересует — тот найдет )
Долго писал зачем и расписывал калькуляцию, где 1/3 дохода сайта уплывет в CDN при самых лучших условиях, но передумал.
Короче, я бы не отказался от низких цен. А пока CloudFlare наше всё.
Короче, я бы не отказался от низких цен. А пока CloudFlare наше всё.
Любой CDN провайдер, из списка выше, может продать по $0.01. Все зависит от объемов.
Часто вижу такую картину: с сайта все практически загрузилось, а браузер ничего не показывает, т.к. висит запрос с какого-нибудь cdn.jquery.com. Может это и DNS тормозит, или еще что… Но подозреваю, что такая ситуация у многих пользователей возникает.
UFO just landed and posted this here
Помнится на MSK-IX форуме чувак из ivi довольно толково обрисовал anycast и cdn.
Eсли кому интересно недавно сделали open-source калькулятор для расчета цен www.cdncalc.com/ Cам код здесь Github
Вот сравнение распространенности CDN seomon.com/technologies/cdn/
CloudFlare всех побеждает.
Чем посещаемей вебсайты, тем чаще они используют CDN.
CloudFlare всех побеждает.
Чем посещаемей вебсайты, тем чаще они используют CDN.
А подскажие по такому юзкейзу. В целях экономии был написан свой «cdn». Nodejs сервак раздающий статику. Загрузка на его происходи следующим образом.
Отправка файла на основной домен.
Тут происходит поиск по хешу этого файла, если уже залит отдаем на него ссылку, если нет создаем новуюзапись в бд и отдаем RabbitMQ на заливку в цдн. Сами же ожидаем результат.
Воркер рэбита получив пакет с файлом загружает его пост запросом на cdn по успешному завершению шлет пакет обратно на основной сервер.
Получив пакет об успешной заливке файла оснвной сервер возвращает ссылку на фаил в cdn.
Проблема в том, что происходит грубо говря 2 пост запроса: первый от клиента на оснвной сервер и второй от воркера к cdn. Как итог крайне медленно.
Отправка файла на основной домен.
Тут происходит поиск по хешу этого файла, если уже залит отдаем на него ссылку, если нет создаем новуюзапись в бд и отдаем RabbitMQ на заливку в цдн. Сами же ожидаем результат.
Воркер рэбита получив пакет с файлом загружает его пост запросом на cdn по успешному завершению шлет пакет обратно на основной сервер.
Получив пакет об успешной заливке файла оснвной сервер возвращает ссылку на фаил в cdn.
Проблема в том, что происходит грубо говря 2 пост запроса: первый от клиента на оснвной сервер и второй от воркера к cdn. Как итог крайне медленно.
Ссылка — два хождения туда-сюда. Имеет смысл только для тяжёлого контента (например, начала видеотрансляции). Для ускорения загрузки страниц, очевидно, хуже чем «просто сходить за файлом».
Есть вариант, что б cdn сам присасывался к RabbitMQ и ожидал картинки из своей очереди, но не очень хотеслоь бы его так усложнять.
Кому интересно, лекция на тему: Особенности построения современных CDN.
А тут приходит Гугл, упоминает, что https ему теперь будет нравиться более http, мы читаем условия поддержки https в каждом cdn, и узнаем для себя много нового )
Вообще, конечно, CloudFlare, так же, как Incapsula (про которую не упомянули, что-то) с их комплексным предоставлением услуг, молодцы тем, что берут на себя не только раздачу картинок, но и ускорение работы сайта, а заодно еще порываются (если разрешить) оптимизировать код страниц, чтобы еще оптимальнее достичь конечной цели — ускорить работу с сайтом для юзера. Улучшайзеры эти, конечно, не всегда нужны (а порой и прямо вредны), но gzip сделать на текстовых файлах — почему бы и нет?
Вообще, конечно, CloudFlare, так же, как Incapsula (про которую не упомянули, что-то) с их комплексным предоставлением услуг, молодцы тем, что берут на себя не только раздачу картинок, но и ускорение работы сайта, а заодно еще порываются (если разрешить) оптимизировать код страниц, чтобы еще оптимальнее достичь конечной цели — ускорить работу с сайтом для юзера. Улучшайзеры эти, конечно, не всегда нужны (а порой и прямо вредны), но gzip сделать на текстовых файлах — почему бы и нет?
Лимит производительности серверов и потребность во всё большей и большей производительности породила ныне забытые слова: “ферма серверов”, “иерархическое кеширование”… Айтишный новояз удивительно чувствителен к возрасту — и слова вроде “servers farm” или “information superhighway” сейчас ассоциируются с тёплыми ламповыми CRT-мониторами, а не с прогрессом.
Ну кто как, я ежедневно сталкиваюсь на том же stackoverflow с терминами вроде «Sharepoint server farm»
Sign up to leave a comment.
Знакомство с Content Delivery Network