Comments 17
Через некоторое время после публикации статьи картинки автоматически копируются на хабрасторадж и ссылки меняются. По крайней мере с моими статьями было именно так.
Как я понял, это Local Traffic Manager от F5_Networks. Гуглится по ключевым словам "ltm network"
Расскажу про то, как у меня решена похожая задача. Картинки, в день исходящий трафик больше 14 ТБ, пиковая скорость — до 8 Гбит/с.
На AWS Route 53 создан alias для домена, указывающий на 16 адресов кэширующих серверов. По днс запросу домена отдаются multiple A-records, 8 адресов, ttl 60s, порядок меняется с каждым запросом. Для каждого адреса кэширующего сервера в Route 53 настроен health check порта 443/tcp (можно и http на liveness url, но будет чуть дороже). В случае недоступности порта на каком-то адресе, health check реагирует на это за 30-60 сек и выкидывает адрес из днс выдачи у домена. Еще до 60 сек (помним про ttl алиаса) нужно чтобы старая днс запись у клиента протухла и он сходил за новой. Таким образом время недоступности домена у 1/16 клиентов наткнувшихся на упавший адрес составит от 30 до 120 сек максимум. И то, только если ПО клиента не умеет доставать следующие адреса из днс ответа самостоятельно (браузеры например умеют, мобильные приложения насколько я знаю — тоже). Дальше, на этих 16 кэширующих серверах (8 на ДЦ) настроена в nginx балансировка по 2 стораджам из своего ДЦ + 2 стораджа из второго ДЦ указаны с опцией backup. Если ответ с ошибкой или кончился таймаут (специально поставлен небольшим) — отправляем запрос на другой сторадж. Стораджи отдают в день до 4 ТБ за счет кэширующего слоя, а клиентам уходят 14 ТБ.
В такой схеме спокойно живется как при отказе любого сервера, так и при недоступности одного ДЦ. Небольшая часть клиентов при сбоях увидит или небольшое повышение времени ответа, либо недоступность не более 1-2 мин. Ручные действия не требуются, в PagerDuty присвоен низкий приоритет на алерты. Используемое ПО — только бесплатный nginx, за Route 53 — несколько десятков $ в месяц.
Еще до 60 сек (помним про ttl алиаса) нужно чтобы старая днс запись у клиента протухла и он сходил за новой.
Зря вы в это верите, многие провайдеры не смотрят так пристально на TTL.
Но, конечно, у каждого свой подход — и свой калибр решения. Кто-то под ту же задачу проксирующий CDN юзает, кто-то простой CDN — и то, и то в каких-то случаях обоснованно, но стоит денег из-за трафика, конечно.
Мне лично запомнился пост от IVI — они там небанально выкрутились, у них трафик очень большой, проксировать его не хотели, и время сходимости решения у них хорошее, как для их ситуации (тюнинг, конечно, нужен, они про него в конце пишут — в частности, что важно не забывать про настройку BFD для ускорения определения живости нод).
Кэшировать адрес для dns записи разумно только на время равное или меньшее её TTL (chrome например принудительно ограничивает кэш минутой).
А если у клиента и кэш лежит неделю, и из списка 8 адресов в ответе он только один себе возьмет — то это только нарочно так можно сделать мне кажется :)
Если вы говорите про кеш в Хроме (я такого не знал, но поверю: у них в как бы «браузере» чего только нет своего), то его минуту к тем 10-15 минутам можете приплюсовать.
Иные рекурсивые ДНС-серверы лимитируют минимальный TTL минутой или 5 минутами, им много постоянных запросов — тоже лишний трафик.
В общем, DNS хороший механизм, но, как говорит Черномырдин, «есть и более другие».
Спасибо за ссылку, прочитал и этот пост и предыдущий, в том числе про остаточный трафик в течении 2 недель после смены записи при ttl 15 минут — это, конечно, сильно.
Но у себя такого не наблюдал (и хорошо!), если один-два устройства и засиделись на убираемом балансировщике — то я ими готов пренебречь.
Я всё равно считаю людей которые себе сами так настраивают локальный резолвер или пользуются таким от провайдера — ССЗБ.
Но случаи конечно разные бывают, может быть ситуация когда это будет неприемлемо (как те сайты интернет банков, которые десять лет таскали с собой наследие совместимости с IE 6-8).
В день исходящий трафик больше 14 ТБя что то упустил и Amazon вам дарит 14+ Тб трафика?
Используемое ПО — только бесплатный nginx, за Route 53 — несколько десятков $ в месяц.
удалено
Одному мне не хватает в статье двух-трех схем? Типа "Вот так сеть была устроена" и "Вот так сеть теперь устроена".
Как Badoo добился возможности отдавать 200k фото в секунду