Максимальный uptime

Вы неправильно запомнили и ошибаетесь.

Кажется, даже на этом форуме десяток раз обсуждали провайдеров доступа, которые игнорируют TTL отресолвенной записи и принудительно увеличивают кто досуток, кто до недели. Сейчас ищ уже не большинство, не так как 10 лет назад, но все-равно хватает. Любой владелец сайта, хоть раз переносивший его на новый IP, мог это наблюдать на практике, просматривая логи обращения к старомоу IP - там и сутки, и неделю обращения продолжаются. Даже если заблаговременно до переноса уменьшить TTL до минуты.

У клиента (веб-браузера) тоже свой взгляд на TTL. Кроме IE игнорирует TTL и firefox. Я сейчас, проверяя себя, посмотрел tcpdumpом на обращения к DNS от firefox - да, даже есть A-запись с TTL 1s, firefox это игнорирует и в течение минуты при повторных попытках открыть страницу к DNS не обращается. Вероятно, это характерно и для других браузеров, т.к. вещь, в принципе, для человеческих сайтов правильная - если на каждый HTTP-запрос делать отдельно DNS-запрос - страницы будут открываться намного медленнее. IE, кстати, и через минуту не пытается перезапросить DNS по-новой.

Напротив, работает. Проверить просто. Букв, к сожалению, много, но так случается всегда, когда нужно показывать конкретные вещи.

Вот смотрите, я включил 4 сервера:

A, 94.127.66.130 - работает, но не слушает 80 порт (connection refused)

B, 94.127.66.131 - работает, слушает 80 порт

C, 94.127.66.132 - работает, но не слушает 80 порт (connection refused)

D, 94.127.66.133 - не работает (долгая попатка соединения и connection timeout в итоге)

Завел тестовую зону test.fluid.ru. В ней 5 поддоменов

a1.test.fluid.ru - одна A-запись, на работающий сервер B, для контроля

a2.test.fluid.ru - указывает на оба включенных сервера A и C, с неработающим 80 портом

a3.test.fluid.ru - указывает на три сервера, один работающий B и два с неработающим 80 портом A и C

a4.test.fluid.ru - указывает на три неработающих сервера, один недоступный вообще D и два с неработающим 80 портом A и C

a5.test.fluid.ru - указывает на все 4 сервера - A, B, C, D

При обращении к этим адресам, что IE, что Firefox, пытаются соединиться со всеми A-записями, вернувшимися от DNS, до тех пор, пока не будет успешное соединение. Можете и самостоятельно поэкспериментировать, я на пару дней оставлю такую конфигурацию).

Зона выглядит так (можно и по axfr посмотреть)

a1.test.fluid.ru. 1 IN A 94.127.66.131

a2.test.fluid.ru. 1 IN A 94.127.66.130

a2.test.fluid.ru. 1 IN A 94.127.66.132

a3.test.fluid.ru. 1 IN A 94.127.66.130

a3.test.fluid.ru. 1 IN A 94.127.66.131

a3.test.fluid.ru. 1 IN A 94.127.66.132

a4.test.fluid.ru. 1 IN A 94.127.66.130

a4.test.fluid.ru. 1 IN A 94.127.66.132

a4.test.fluid.ru. 1 IN A 94.127.66.133

a5.test.fluid.ru. 1 IN A 94.127.66.130

a5.test.fluid.ru. 1 IN A 94.127.66.131

a5.test.fluid.ru. 1 IN A 94.127.66.132

a5.test.fluid.ru. 1 IN A 94.127.66.133

Далее открываем эти адреса в браузере и смотрим tcpdumpом, что происходит.

a1.test.fluid.ru - одна A-запись, на работающий сервер B, для контроля

открывается сразу 404 страница nginx

a2.test.fluid.ru - указывает на оба включенных сервера A и C, с неработающим 80 портом

сразу же сообщается о невозможности соединиться с сервером. В это время браузер попытался подключиться к обоим серверам.

17:09:23.340402 IP 10.0.2.9.47715 > 94.127.66.130.80: Flags
17:09:23.344985 IP 94.127.66.130.80 > 10.0.2.9.47715: Flags [R.]
17:09:23.797146 IP 10.0.2.9.47716 > 94.127.66.130.80: Flags
17:09:23.802647 IP 94.127.66.130.80 > 10.0.2.9.47716: Flags [R.]
17:09:24.344023 IP 10.0.2.9.47717 > 94.127.66.130.80: Flags
17:09:24.352582 IP 94.127.66.130.80 > 10.0.2.9.47717: Flags [R.]
17:09:24.355728 IP 10.0.2.9.52078 > 94.127.66.132.80: Flags
17:09:24.372035 IP 94.127.66.132.80 > 10.0.2.9.52078: Flags [R.]
17:09:24.781690 IP 10.0.2.9.52079 > 94.127.66.132.80: Flags
17:09:24.788593 IP 94.127.66.132.80 > 10.0.2.9.52079: Flags [R.]
17:09:25.328372 IP 10.0.2.9.52080 > 94.127.66.132.80: Flags
17:09:25.350941 IP 94.127.66.132.80 > 10.0.2.9.52080: Flags [R.]


a3.test.fluid.ru - указывает на три сервера, один работающий B и два с неработающим 80 портом A и C
чуть потормозил и открыл старницу nginx. По tcpdump видно, что он несколько раз безуспешно подключался к С и A, получая в ответ tcp reset, но в итоге попал на работающий B


TCP 80
17:18:09.505944 IP 10.0.2.9.46050 > 94.127.66.132.80: Flags
17:18:09.509972 IP 94.127.66.132.80 > 10.0.2.9.46050: Flags [R.]
17:18:09.953387 IP 10.0.2.9.46051 > 94.127.66.132.80: Flags
17:18:09.957459 IP 94.127.66.132.80 > 10.0.2.9.46051: Flags [R.]
17:18:10.390885 IP 10.0.2.9.46052 > 94.127.66.132.80: Flags
17:18:10.403064 IP 94.127.66.132.80 > 10.0.2.9.46052: Flags [R.]
17:18:10.404568 IP 10.0.2.9.40674 > 94.127.66.130.80: Flags
17:18:10.413433 IP 94.127.66.130.80 > 10.0.2.9.40674: Flags [R.]
17:18:10.937773 IP 10.0.2.9.40675 > 94.127.66.130.80: Flags
17:18:10.944810 IP 94.127.66.130.80 > 10.0.2.9.40675: Flags [R.]
17:18:11.484656 IP 10.0.2.9.40676 > 94.127.66.130.80: Flags
17:18:11.493702 IP 94.127.66.130.80 > 10.0.2.9.40676: Flags [R.]
17:18:11.495066 IP 10.0.2.9.56596 > 94.127.66.131.80: Flags
17:18:11.501591 IP 94.127.66.131.80 > 10.0.2.9.56596: Flags [S.]
17:18:11.501634 IP 10.0.2.9.56596 > 94.127.66.131.80: Flags [.]
17:18:11.502301 IP 10.0.2.9.56596 > 94.127.66.131.80: Flags [P.]
17:18:11.513876 IP 94.127.66.131.80 > 10.0.2.9.56596: Flags [.]
17:18:11.514240 IP 94.127.66.131.80 > 10.0.2.9.56596: Flags [P.]
17:18:11.514255 IP 10.0.2.9.56596 > 94.127.66.131.80: Flags [.]


a4.test.fluid.ru - указывает на три неработающих сервера, один недоступный вообще D и два с неработающим 80 портом A и C
тормозил долго, потом выдал ошибку. по tcpdump видим, что обратился к серверу С, получил reset, потом не повезло обратиться к D, который в ответ ничего не дает и на попытку подключения к которому потратили в общей сумме 20 секунд, потом обратились к A, получили ошибку от него и прекратили. Здесь у firefox и IE поведение почти одинаковое, разница только в том, что IE пытается несколько раз достучаться до сервера, который отдал connection refused, а firefox после первой же ошибки переходит к следующему IP-адресу.

TCP 80 (IE)
17:23:37.207487 IP 10.0.2.9.59596 > 94.127.66.132.80: Flags
17:23:37.214559 IP 94.127.66.132.80 > 10.0.2.9.59596: Flags [R.]
17:23:37.640891 IP 10.0.2.9.59597 > 94.127.66.132.80: Flags
17:23:37.647208 IP 94.127.66.132.80 > 10.0.2.9.59597: Flags [R.]
17:23:38.187931 IP 10.0.2.9.59598 > 94.127.66.132.80: Flags
17:23:38.193570 IP 94.127.66.132.80 > 10.0.2.9.59598: Flags [R.]
17:23:38.204928 IP 10.0.2.9.37948 > 94.127.66.133.80: Flags
17:23:41.195619 IP 10.0.2.9.37948 > 94.127.66.133.80: Flags
17:23:47.195620 IP 10.0.2.9.37948 > 94.127.66.133.80: Flags
17:23:59.189879 IP 10.0.2.9.54863 > 94.127.66.130.80: Flags
17:23:59.198606 IP 94.127.66.130.80 > 10.0.2.9.54863: Flags [R.]
17:23:59.625254 IP 10.0.2.9.54864 > 94.127.66.130.80: Flags
17:23:59.637201 IP 94.127.66.130.80 > 10.0.2.9.54864: Flags [R.]
17:24:00.172148 IP 10.0.2.9.54865 > 94.127.66.130.80: Flags
17:24:00.203809 IP 94.127.66.130.80 > 10.0.2.9.54865: Flags [R.]

freedz, насколько я понял из Вашего описания задачи, пожалуй самым дешевым и простым вариантом будет 2 vps/dedicated, реплицирующие данные между собой.

Доступность и переключение по ДНС как уже писали выше. У нас есть своя готовая инфраструктура под это, вплоть до распределения серверов по пулам и привязки этих пулов к гео-локации пользователя с точностью до региона (области) любой страны.

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

VPS более чем достаточно.

---------- Добавлено 17.06.2012 в 16:04 ----------

P.S. Касательно кешей ДНС у браузера.. Как показывает наши реальная практика работы такой системы, процент таких браузеров и/или провайдеров крайне незначителен. При падение серверов, общий трафик не уменьшается. Максимум что нужно сделать пользователю - нажать кнопку обновить в браузере.

Которые верны при допущении, что аптайм - равномерен. Что собственно и называется "сделать допущение".

А аптайм и есть равномерен (как вероятность). В пределах того отрезка, где он задан.

При этом (включая ТС), все спотыкаются об тот факт, что если у нас аптайм за сутки 99,5%,

то поделив сутки на часы мы нифига не получим 24 отрезка с аптаймом 99,5%, а будем иметь некоторое распределение вероятности аптайма на каждом из отрезков. С трудом решаемую задачу.

Причем я об это не спотыкался! И каждый раз когда предлагали - давайте возьмем не год, а день (час, минуту) я соглашался - хорошо, возьмем час с аптаймом 99,5% в котором _точно есть 18 сек простоя_.

Короче - хватит меня тролить. Курсы теорвера и матстата есть в общем доступе.

Обсуждали . Но не задокументировали ни одного современного случая.

Подобные слухи возникают из-за ошибок при планировании переноса доменов.

---------- Добавлено 17.06.2012 в 22:24 ----------

А вот не стоило выставлять TTL в одну секунду. Это же совсем непрактично и программисты могут тоже так решить.

Все сложнее. Вот есть старенькое уже исследование от специального сервиса где описано поведение кеширования DNS в разных браузерах http://www.simplefailover.com/outbox/dns-caching.pdf

Хорошо, что подключение к работающим серверам из списка RR работает, но раз simple failover его не использует, наверное есть какие-то причины.

Наверное это вы тоже неправильно припоминаете. Документируйте сейчас. Вчера около 17:00 перенесли клиента на новый IP. TTL для всех записей - 1 час. Сегодня до полудня на новый IP около 1200 хостов, на старый - около 100. На старый идут питерский СЗТ, уральский МТС, самарский Мегафон, куча украинских провайдеров, шведы. Яндекс с Гуглем будут еще неделю обращаться.

Стоило - я специально для вас секунду сделал, чтобы поведение браузеры было хорошо видно. Так можно быстрее увидеть, что ни IE, ни FF сами по себе перезапрашивать DNS по время исполнения запроса на подключение не будут. Не смысла им так делать. Что бы вам дало, если бы IE как FF принимал TTL в 1 минуту?

Никаких сложностей. Несколько IP для хоста и яндекс с гуглем, и акамай, и сотни других используют. И как одно из средства, балансирующих нагрузку, и как одно из средств файловера. Про то, что из-за долгого ожидания неотвечающего хоста в качестве единственного универсального решения оно не годится, я уже писал раньше.

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

---------- Добавлено 17.06.2012 в 23:52 ----------

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

---------- Добавлено 17.06.2012 в 23:57 ----------

Я то вижу, что некоторые упомянуты хосты имеют несколько IP, но это же не значит, что задумывался именно файловер. Может у них там не хватает пропускной способности оборудования.

У этого сайта дефолтный TTL 1 час уже лет пять был и менять его отдельно не нужно. По поводу перепроверить мои слова - поставьте эксперимент самостоятельно и получайте данные из первых рук или верьте мне на слово (тратить время на согласовывание с клиентом публикации его статистики мне жалко). Для вас будет даже лучше проверить все самостоятельно, чтобы не получалось как с остальными вещами, которые вы "припоминаете" неправильно.

Запросы от мобильных операторов были нормальные, с старыми куками. Почему-то оказалось много украинских сетей для московского сайта - возможно, украинцы чаще обрезают TTL для российских DNS дополнительно. Ну и важные для SEO посетители, о которых, я думал, это всем давно известно - поисковики кэшируют DNS намного дольше, вплоть до недель.

Ок, предположим, у нас стал идеальным мир - все провайдерские DNS и все браузеры будут честно принимать TTL в 1 минуту. Что это даст для фейловера?

Практике использовать несколько IP и для балансировки, и для фейловера, уже лет двадцать. Допустим, вы про фейловер узнали только сейчас и до этого применяли бы RR только для балансинга. Вы считаете, что инженеры в гугле сказали бы друг другу: "давайте сделаем RR, но ни в коем случае не для повышения надежности, а только для балансировки."? И по нескольким ДЦ разносят оборудование ни в коем случае не для повышения надежности, а только потому что ДЦ не справляется с нагрузкой.

Возможность его осуществлять весьма скромными техническими ресурсами. Ну это без учета проблем синхронизации.

Могло и так быть, раз противное не доказано.

Как? Пожалуйста, вкратце опишите как это работало бы и чем было бы лучше классического решения на нескольких A-записях.

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