ITSumma corporate blog
Badoo corporate blog
High performance
Nginx
Backup
Comments 17
+5
Хорошим пруфом к такой статье было бы использование собственного хранилища вместо habrastorage
+2
А трафика столько на одну конкретную статью нагнать слабо, чтобы почувствовать разницу?:) А то пока вот например чуть больше тысячи просмотров с момента публикации. Что, в общем-то, капля в море озвученных в статье нагрузок:)
+3

Через некоторое время после публикации статьи картинки автоматически копируются на хабрасторадж и ссылки меняются. По крайней мере с моими статьями было именно так.

+2
Объяснили бы для начала, что такое LTM для тех кто в танке не в теме.
+5

Расскажу про то, как у меня решена похожая задача. Картинки, в день исходящий трафик больше 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 — несколько десятков $ в месяц.

0
Еще до 60 сек (помним про ttl алиаса) нужно чтобы старая днс запись у клиента протухла и он сходил за новой.

Зря вы в это верите, многие провайдеры не смотрят так пристально на TTL.

+1
Решение, когда DNS прячет запись, указывающую на хост, при недоступности хоста — неплохо, но очень зависит от клиентов: кто-то кеширует и тудо долбится на один хост, кто-то каждый раз делает запросы на разные хосты из тех, на которые DNS указывает. Причем первый вариант поведения выглядит на самым глупым, как с точки зрения клиента: если у него (клиент) уже были запросы на www.site.com, то логично туда же и стучаться дальше, т.к. есть шанс сэкономить из-за keepalive.

Но, конечно, у каждого свой подход — и свой калибр решения. Кто-то под ту же задачу проксирующий CDN юзает, кто-то простой CDN — и то, и то в каких-то случаях обоснованно, но стоит денег из-за трафика, конечно.

Мне лично запомнился пост от IVI — они там небанально выкрутились, у них трафик очень большой, проксировать его не хотели, и время сходимости решения у них хорошее, как для их ситуации (тюнинг, конечно, нужен, они про него в конце пишут — в частности, что важно не забывать про настройку BFD для ускорения определения живости нод).
-2

Кэшировать адрес для dns записи разумно только на время равное или меньшее её TTL (chrome например принудительно ограничивает кэш минутой).
А если у клиента и кэш лежит неделю, и из списка 8 адресов в ответе он только один себе возьмет — то это только нарочно так можно сделать мне кажется :)

+1
А вы представьте: живет себе простой юзер, где-то дома, и стоит у него wifi-роутер безродный. Считаем: у юзера есть свой кеш днс, затем на роутере свой ДНС-сервер и кеш может быть, тот запрашивает ответы у ДНС провайдера, а провайдерский может спрашивать как у авторитетного сервера для зоны, так и у своего рекурсора. В худшем случае TTL на всех этих ресурсах будут складываться, так что 5 минут TTL для записи легко вырастает до 10-15 и даже 20 минут. По крайней мере, опыт подсказывает это.
Если вы говорите про кеш в Хроме (я такого не знал, но поверю: у них в как бы «браузере» чего только нет своего), то его минуту к тем 10-15 минутам можете приплюсовать.
Иные рекурсивые ДНС-серверы лимитируют минимальный TTL минутой или 5 минутами, им много постоянных запросов — тоже лишний трафик.
В общем, DNS хороший механизм, но, как говорит Черномырдин, «есть и более другие».
+1

Спасибо за ссылку, прочитал и этот пост и предыдущий, в том числе про остаточный трафик в течении 2 недель после смены записи при ttl 15 минут — это, конечно, сильно.
Но у себя такого не наблюдал (и хорошо!), если один-два устройства и засиделись на убираемом балансировщике — то я ими готов пренебречь.
Я всё равно считаю людей которые себе сами так настраивают локальный резолвер или пользуются таким от провайдера — ССЗБ.
Но случаи конечно разные бывают, может быть ситуация когда это будет неприемлемо (как те сайты интернет банков, которые десять лет таскали с собой наследие совместимости с IE 6-8).

0
В день исходящий трафик больше 14 ТБ

Используемое ПО — только бесплатный nginx, за Route 53 — несколько десятков $ в месяц.
я что то упустил и Amazon вам дарит 14+ Тб трафика?
0

Упустили, Route 53 это dns, а указывать dns записи — совершенно не обязаны на aws хосты.

+1

Одному мне не хватает в статье двух-трех схем? Типа "Вот так сеть была устроена" и "Вот так сеть теперь устроена".

+1

Если честно, полностью про расшифровке восстановить такой доклад будет проблематично и пара лишних слайдов (в оригинале из 68) имхо не спасут ситуацию. Погляди лучше видео, пользы больше :-)

-4
Интереснее было бы прочитать про ботов и схемах обмана пользователей вашего сайта. Пилите пост, ждем.
Only those users with full accounts are able to leave comments., please.