Pull to refresh

Comments 42

UFO just landed and posted this here

Если с вашим сервером может произойти жопа, то почему бы его не зарезервировать и поставить перед ним балансировщик нагрузки? Если с вашим балансировщиком может произойти жопа, то почему бы не зарезервировать балансировщики, каждый со своей DNS-записью?


Потому что денег на это нет, а на белкового админа, которые будет перетыкивать руками в три часа ночи — есть :(

UFO just landed and posted this here

А от того что хобби проект полежит час, что произойдёт?

а можно по подробней, что вы имеете ввиду
wildcard сертификат от letsencrypt можно получить только используя авторизацию через DNS. Высокий TTL — проверка будет провалена.
Let’s Encrypt при авторизации через DNS всегда проверяет запись непосредственно через непосредственное обращение к авторитативным DNS серверам домена. Запись должна быть опубликована к тому моменту, когда Let’s Encrypt придет ее проверять. TTL тут никакой роли не играет.
Если проект прямо сейчас нужен на учебном занятии или выступлении — то оно сорвётся.

На выступлении не должно быть внешних зависимостей. Все толькотлокаотно. Это пастулат.

Какой раз я говорю себе, что не нужно писать комменты с телефона. Следует читать: «Всё только локально. Это постулат.»
UFO just landed and posted this here

Если вам по какой-то причине надо срочно обновить А запись то ждать вам придется как раз весь TTL. И хорошо если у вас есть полный контроль над роутингом у себя и "плавающие" IP-адреса, а если это vps?

Кстати, при переключении ip-адреса заметил, что многие мобильные клиенты, особенно iOS, еще долго долбились на старый ip-адрес — около двух дней были редкие запросы (TTL было 5 минут). Может, конечно, какой-то провайдер закешировал или они таким способом экономят энергию.
Да, проблема есть, и она серьёзна. Я ещё в 2013 году это заметил при просмотре трафика.
Чаще всего, почему-то, проблема была заметна на доменах каких-то российских рекламных сетей (сейчас уже не вспомню кто это был). Я посчитал, что они собирают статистику на своих DNS-серверах.

Автор статьи упорно не хочет замечать проблему, которую он обозначил вскользь и не хочет предложить какой-то способ для её решения.
Современный бизнес не готов терпеть сутки убытка, пока сайт переключится если он неожиданно упадёт и его придётся подымать на другом месте. Поэтому сейчас все такие умные и стали ставить значения как можно меньше — вот и все дела. И это самый дешёвый способ способ снизить время переключения, поэтому неважно, что у вас в ближайших планах на полгода нет повода для смены хостинга: просто тупо держите TTL поменьше на всякий пожарный случай.


Все другие способы сделать более качественно страдают одним мааааленьким недостатком: они намного более дороги. Все ли готовы вкладываться в это? Не все. А требовать хотят все.
Вот отсюда и описанная ситуация.


В айти всего две действительно сложные проблемы: нейминг и инвалидация кеша. В протоколе DNS инвалидация кеша есть? Ну вот потому ситуация и не меняется.

Хочу заметить, что перечисляя две действительно сложные проблемы, вы забыли «ошибки на единицу»
UFO just landed and posted this here
> Сейчас с хостингом в облаках конечно попроще, но эту инерцию трудно сломить.
С хостингом в облаках как раз всё намного хуже.
Я до сих пор помню чудесное от digitalocean — «ну у нас кнопки reinstall пока нет, вы дроплет удалите, создайте заново с теми же параметрами, может быть повезет и он будет с тем же адресом» (кнопки reinstall на тот момент действительно не было).
UFO just landed and posted this here
У них до сих пор «ну у нас выбор ОС в reinstall есть, но на самом деле нормально реинсталлить можно только ту же ОС/версию, что была при создании, потому что cloud-init не меняется».
Многие пользуются cloudflare, там по умолчанию auto ttl, а это вроде бы 5 минут. Видимо в cf считают, что это нормально, нагрузка приемлема.
Раньше была 1 минута, если память не изменяет.
А сейчас минималка в 2 минуты на непроксируемых, и 5 минут — на proxied ресурсах

Я недавно менял ip сайта в CF, так после смены он мгновенно стал доступен. Подозреваю, что там TTL для недоступных сайтов снижается, чтобы при возобновлении работы сразу отдать его клиентам.

Загрузка одной страницы типичного сайта генерирует более 1 Мб трафика. Если ради нее приходится делать DNS-запрос, то это + 300 байт трафика — менее 0,1%.


Статья предлагает вам тратить время ради оптимизации менее 0,1% трафика. И получить проблемы при падениях, ДДОС-атаках, проблемах с хостером.


Не уж, пусть будет 5-15 минут, и вам не придется объяснять владельцу бизнеса, что поднять сайт нельзя, так как какой-то гений, начитавшись советов в Интернете, поставил TTL в 12 часов.

Только в современном мире пропускная способность часто высока (даже по сотовой связи), а вот RTT до сих пор часто бывает очень высоким (даже на проводе).
И генерируя 5 днс запросов (cname, cdn, ресурсы партнеров, счетчики) с задержкой в 200мс вы легко получаете более 1 секунды до загрузки страницы каждые { ваше/cdn/партнеров значение ttl }.

DNS-ресолвинг — для клиента это в первую задержка перед отображением страницы, а не объём трафика

поднять сайт нельзя, так как какой-то гений, начитавшись советов в Интернете, поставил TTL в 12 часов.

Я вполне себе застал времена в начале 2000-х, когда TTL обычно стоял 86400. И были постоянные факапы, когда люди пуляли ошибочное обновление в зону, которое роняло корпоративную почту или сайт на сутки.
Работал в то время в телекоме и сполна насмотрелся на эти ужасы.
Пусть уж лучше TTL в 60-120 секунд.
Первая, и самая важная ваша ошибка в рассуждениях: балансировка по DNS зависит от TTL, и это ключевой момент, довольно подробно про это было в блоге Dropbox: blogs.dropbox.com/tech/2018/10/dropbox-traffic-infrastructure-edge-network.
Вторая: в общем случае, у вас нету надёжного способа управления трафиком, кроме GeoDNS. Предупреждая вопросы, anycast — это не управление, т.к. решение в итоге принимает провайдер на основе ваших предложений, но далеко не всегда в соответствии с вашими желаниями.
Из этих двух вводных и возникает низкий TTL в большинстве CDN (включая AWS, Google Cloud и т.д.).

Про проблемы быстрого переключения на другой пул адресов/балансеров/etc уже писали выше, это уже касается не-CDN доменов.
Один, два или десяток лишних DNS запросов вносят задержки, да. Но эти задержки — капля в море по сравнению с теми секундами, пока грузится перегруженный скриптами и рекламой современный веб.
И уж тем более это добро несопоставимо с часами простоя, в случае протухшей DNS записи.
Петь песни про резервирование, кэширование и управление траффиком все горазды, а вот когда припрет — каждому клиенту на дом «сделайте, пожалуйста ipconfig /flushdns» носить не будешь.
Кэширование DNS штука, конечно, клевая, но фарш обратно не провернешь: если закэшировало — то все, жди пока протухнет.

Сейчас кэш DNS просто ушел в прошлое имхо. Для ускорения загрузки нынче куда более эффективнее кэширование на уровне CDN с проверками по 304 коду или чем-нибудь подобным.
В конце концов пропускная способность сети и скорости загрузки контента для конечного пользователя постоянно растут и влияние задержек от DNS запросов будет становится все менее и менее заметным.

а еще бывает, не оплатит бухгалтерия вовремя домен, и один крупный провайдер с названием в названии быстренько подставляет ip адреса со своей рекламой, которые кэшируются у клиентов и некоторые потом сутками жалуются на недоступность сервиса.

Когда мои коллеги-программисты где-то вкорячивают кеширование но забывают приделать к нему инвалидацию — я отрываю им руки.
Создателям DNS руки вовремя никто не оторвал, а про инвалидацию кеша они вообще были не в курсе.

Как вы это представляете? Допустим, есть популярный глобальный сервис, у его DNS запросили инфу порядка тысячи разных кэширующих резолверов — как ему надежно сбросить кэш у каждого из них?

Запонимать всех кто (и когда) спрашивал и слать «сбросить кэш»? При этом, без криптографии тут не обойдётся — все запросы на сброс кэша должны быть подписаны, а резолверы должны их валидировать, и это не считая того что эту «память» нужно хранить где-то постоянно — иначе холодный рестарт сервера (или переход на другой сервер в пуле) не сбросит кэш.

Технически это конечно реализуемо, но усложняет систему неимоверно, а если учесть что клиенты иногда запрашивают кэширующие резолверы совсем не первого уровня, да и самих резолверов могут быть не тысячи а десятки тысяч, то всё становится очень мрачно.
Нет, просто конечный резолвер должен регулярно опрашивать авторитативный сервер (каждые X запросов, но не чаще раза в N<TTL секунд) и сравнивать с данным в кеше. Для популярных записей нагрузка увеличится незначительно, а для редких почти каждый запрос будет уходить наверх, но это не проблема. Реализуемо уже сейчас, но даже если и принять стандарт, только лет через 30 оно разойдётся по сети окончательно. Но вот бьющиеся в истерике администраторы могут уже сейчас начать патчить свои резолверы, добавляя игнорирование оригинального TTL и регулярный опрос.
Современный кеширующий резолвер при обработке запроса от Клиента смотрит сколько от оригинального TTL осталось. И если осталось меньше чем время N, то асинхронно запрашивает авторитативные сервера, обновляя запись в фоне. Таким образом популярные запросы всегда находятся в Кеше. Стандартов на сколько я знаю на это не существует в природе и каждый разработчик кэширующих DNS серверов делает это по собственным алгоритмам.
По проблематике коротких TTL — текущая температура по больнице:
1) Маленькие TTL на популярных доменах не вредят телеком-провайдерам с большим количеством Абонентов. При условии того, что эти телеком-провайдеры агрегируют трафик 400+ тысяч Абонентов на сервер. Давление на кеш на таком сервере позволяет держать все популярные домены в кеше. Сервер может отвечать на запросы к популярным доменам 100% из кеша, если используются проактивное кеширование.
У телеком-провайдеров с небольшой нагрузкой на кешируюшие DNS сервера популярные домены часто вымываются из кеша, вследствии небольшого на него давления от клиентов. И проактивное кеширование при небольшом давлении на кеш уже не помогает.
2) В среднем TTL все время снижается, так как все больше ресурсов переезжает в «облака», в которых короткие TTL используются по умолчанию.

В среднем никогда не стоит делать TTL меньше 15 секунд, иначе и проактивное кеширование на стороне резолвера ISP может не успевать обновлять кеш, до того как запись умрет по TTL.

Хм, а причем здесь серверы? Нельзя ли сделать просто долгосрочный кеш на стороне клиента? И сбрасывать его если произошла ошибка соединения.


Или я фундаментально не понимаю что нибудь?

Тогда такие клиенты будут долго не видеть изменений в DNS при, к примеру, переезде веб-сервера на новый адрес. Что для клиентов будет равнозначно ситуации «сайт лежит». Если вы будете обновлять кеш при ошибке соединения с каким-либо сервисом на целевом хосте (да, про UDP и прочие подобные stateless протоколы придётся забыть), то клиент опять же получит ситуацию «сайт лежит», если веб-сервер не знает про такой Host/SNI в HTTP(S)-запросе вследствие переезда сайта на другой адрес.
Не убедили. Плавающие ip стоят денег, и требуют обслуживания, особенно в bare-metal инфраструктуре. Да даже с ними я ставлю ttl пять минут, на всякий случай, чтобы быть точно уверенным что я смогу перенести основную часть трафика на резерв, в разумное для бизнеса время.
Bare-metal инфраструктура Packet: цена плавающего IP: $0.005/час ($3,6 в месяц) в пределах одного ДЦ, $0,15/час ($108 в месяц) между ДЦ. По мне, если это дорого для Бизнеса, но это наверное не Бизнес на котором зарабатывают деньги, а попытки экономить на спичках и на End User Experience.
Кстати, такие маленькие TTL у «конечных» записей, а у NSов экстремально низкие TTL это редкость, и кеширование всего кроме последней записи про целевой хост работает.
Sign up to leave a comment.

Articles