У этого сайта дефолтный TTL 1 час уже лет пять был и менять его отдельно не нужно. По поводу перепроверить мои слова - поставьте эксперимент самостоятельно и получайте данные из первых рук или верьте мне на слово (тратить время на согласовывание с клиентом публикации его статистики мне жалко). Для вас будет даже лучше проверить все самостоятельно, чтобы не получалось как с остальными вещами, которые вы "припоминаете" неправильно.
Запросы от мобильных операторов были нормальные, с старыми куками. Почему-то оказалось много украинских сетей для московского сайта - возможно, украинцы чаще обрезают TTL для российских DNS дополнительно. Ну и важные для SEO посетители, о которых, я думал, это всем давно известно - поисковики кэшируют DNS намного дольше, вплоть до недель.
Ок, предположим, у нас стал идеальным мир - все провайдерские DNS и все браузеры будут честно принимать TTL в 1 минуту. Что это даст для фейловера?
Практике использовать несколько IP и для балансировки, и для фейловера, уже лет двадцать. Допустим, вы про фейловер узнали только сейчас и до этого применяли бы RR только для балансинга. Вы считаете, что инженеры в гугле сказали бы друг другу: "давайте сделаем RR, но ни в коем случае не для повышения надежности, а только для балансировки."? И по нескольким ДЦ разносят оборудование ни в коем случае не для повышения надежности, а только потому что ДЦ не справляется с нагрузкой.
Наверное это вы тоже неправильно припоминаете. Документируйте сейчас. Вчера около 17:00 перенесли клиента на новый IP. TTL для всех записей - 1 час. Сегодня до полудня на новый IP около 1200 хостов, на старый - около 100. На старый идут питерский СЗТ, уральский МТС, самарский Мегафон, куча украинских провайдеров, шведы. Яндекс с Гуглем будут еще неделю обращаться.
Стоило - я специально для вас секунду сделал, чтобы поведение браузеры было хорошо видно. Так можно быстрее увидеть, что ни IE, ни FF сами по себе перезапрашивать DNS по время исполнения запроса на подключение не будут. Не смысла им так делать. Что бы вам дало, если бы IE как FF принимал TTL в 1 минуту?
Никаких сложностей. Несколько IP для хоста и яндекс с гуглем, и акамай, и сотни других используют. И как одно из средства, балансирующих нагрузку, и как одно из средств файловера. Про то, что из-за долгого ожидания неотвечающего хоста в качестве единственного универсального решения оно не годится, я уже писал раньше.
Вы неправильно запомнили и ошибаетесь.
Кажется, даже на этом форуме десяток раз обсуждали провайдеров доступа, которые игнорируют 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ом, что происходит.
открывается сразу 404 страница nginx
сразу же сообщается о невозможности соединиться с сервером. В это время браузер попытался подключиться к обоим серверам.
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, но в итоге попал на работающий BTCP 8017: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, по техническим вещам в топике достаточно хорошо рассказали, углубляться здесь в тысячу деталей, специфичных для разных случаев, мало кому интересно. Но есть важный аспект - оценка надежности и стоимости реализаций различных решений.
Обращение к альтернативному решению на базе кластера основывается на вашей исходной предпосылке в высокой вероятности выпадения главной из поиска. В принципе, за свои деньги вы имеете полное право ошибаться как угодно. hvosting в своем стремлении продать вам консультацию может поддерживать вас в этом заблуждении либо из корыстного интереса, либо из-за плохого владения вопросом. Жаль, что вы вдвоем в этом топике в итоге "гарантировали" безумно высокие риски выпадение из поиска всех сайтов у всех хостеров и теперь в этом настойчиво убеждаете читателей. Но вернемся к вашему конкретному вопросу.
Так вот в оценке того, что будет надежней для небольшого коммерческого сайта - разместиться на хорошем веб-хостинге, VDS или выделенном сервере, или собрать на нескольких серверах отказоустойчивый кластер, правильным решением будет почти всегда без кластера. Потому что хорошую, красивую, сложную систему, нужно хорошо спроектировать, хорошо реализовать, и хорошо поддерживать. Если этим вопросом будут заниматься фрилансеры на разовых контрактах без постоянной поддержки, или просто любители, ломаться система будет намного чаще, чем обычный качественный хостинг, который обслуживается хорошими специалистами.
В 2000-2001 мы реализовали это в Net.Ru. Там была сложная схема их группы фронтендов и бэкендов, размещенные с взаимным резервированием в трех датацентрах. Достаточно долго мы были единственными с таким решением. Были немного похожие вещи у Зенона и Мастерхоста, но в пределах одного датацентра.
Для того времени это решение было, действительно, оправдано, т.к. не высокая надежность ДЦ существенно ухудшалась пиринговыми войнами крупных телекомов и их следствием - долгими периодами плохой связности между крупными частями рунета. Наша схема с разными датацентрами особенно хорошо помогала для последнего.
Но примерно с 2007 эту схему мы расформировали, оставив только взаимное резервирование между двумя ДЦ. Расформировали по той причине, что исчезла необходимость - отказы стали значительно реже. Затраты на содержание в эксплуатации сложной схемы достаточно большие (в том числе на минимизацию внутренних сбоев и негативного влияния человеческого фактора). Существенного выигрыша в надежности от сложной схемы не было, и без нее оборудование и ДЦ работали уже достаточно хорошо. Да, случались аварии, приходилось переключаться на резервы, были простои по несколько часов. Но проблемы падения каналов, умирания дисков или железа проще и надежнее решались локальными техническими решениями.
В целом, эта хорошая, каноническая схема. Обратите внимание на то, что фронтены должны не только ориентироваться на доступность бэкендов, но и распознавать менее очевидные сбои - на уровне приложения или системы. Например, сломалась одна из таблиц БД и страницы генерируются с ошибками. Часто при этом страницы сайта отдаются с тем же кодом 200, как будто ошибок нет. Если у вас репликация данных между бэкендами идет по DRBD, то на дублере тоже будет сломанная таблица. Если сбой файловой системы повредит часть данных, они будут повреждены и на дублере. Также нужно предусмотреть сплитбрейт - если фронтенды из-за разной доступности стали обращаться к разным бэкендам.
С защитой от DoS не так все просто. Если это слабая атака, которая решается файерволом и http-proxy, она может решаться и без отдельного фронтенда. Если атака серьезная, то размазывание по нескольким фронтендам от нее не спасет. Да и провайдеры, если в услугу не включена защита от DoS, чаще всего просто блокируют атакуемые серверы.---------- Добавлено 16.06.2012 в 23:48 ----------
С DNS вряд ли бы работало - если браузер снова запросит адрес, он его получит из кэша DNS-сервера.
Возможно, у вас в памяти задержалось из-за другого - многие программы во время подключения к серверу по TCP, в том случае, если DNS вернул для имени несколько IP-адресов, при ошибки подключения к первому адресу пробуют поочередно подключиться ко всем остальным. Это не требования стандарта, но большинство программ, включая веб-браузеры, реализует этот механизм.
На базе него строится простой, но не очень хороший вариант - failover на round robin DNS. Если при попытке подключиться к первому IP-адресу мы быстро получаем ошибку - host unreachable, connection refused или что-то в этом роде, переключение на следующий идет сразу же. Но если запросы на соединение уходят в пустоту и не показывают сразу же ошибки (сбой маршрутизации, аварийное отключение сервера), то клиент ждет до истечения таймаута (достаточно долго, чаще всего, не меньше минуты), прежде чем перейти к следующему адресу. Ну и второй недостаток - это не требования стандарта, это не реализуется готовыми функциями ОС (скажем, POSIX), поэтому могут быть и наверняка есть браузеры, которые такой механизм не реализуют.
Если вы таким образом заявляете про свои два технических высших, то могу только с сожалением предположить, что ваши годы учебы потрачены впустую: ладно уже пробелы в математике, но вы показываете и недопустимое остутсвие навыков анализа проблем и ошибок.
Лучше не вынимайте свои дипломы и мантию академика бобруйской международной академии наук, а примите или опровергните доказательство ошибки в вашем расчете, это будет достовернее:
Простая иллюстрация вашей ошибки - обратитесь к сайту 52 раза не за год, а за минуту или за час. Вы уверены, что с вероятностью 26% получите отказ? Обратитесь 520 раз за час - по вашей методике подсчета вероятность отказа будет 92%. Повторяйте эту серию обращений каждый час в течение года, у вас все эти разы вероятность отказа должна быть 92%. Все еще считаете, что у вас нет ошибки?
freedz, у вас и у hvosting ошибка в том, что вы стали считать аптайм вероятностью удачного захода, что неправильно. Как в анекдоте про вероятность встретить инопланетянина - 50%, либо встречу, либо нет.
Способ посчитать правильно я привел. При времени проверки, стремящемся к нулю, вероятность тоже стремится к нулю, все верно.
Не хочу пересказывать учебник тервера и разбирать с вами, где и почему вы ошиблись. Простая иллюстрация вашей ошибки - обратитесь к сайту 52 раза не за год, а за минуту или за час. Вы уверены, что с вероятностью 26% получите отказ? Обратитесь 520 раз за час - по вашей методике подсчета вероятность отказа будет 92%. Повторяйте эту серию обращений каждый час в течение года, у вас все эти разы вероятность отказа должна быть 92%. Все еще считаете, что у вас нет ошибки?
Хорошо, что люди, привычные к такому способу занимаются безобидным хостингом, а не строительством :)
Вы упустили, что падение сайта и обращение к сайту - независимые случайные величины. Их совместная вероятность - произведение.
Простая иллюстрация вашей ошибки - обратитесь к сайту 52 раза не за год, а за минуту. Вы уверены, что с вероятностью 26% получите отказ?
Вероятности неправильно посчитаны. Вероятность отказа для 99.5% аптайма - 0.005. Вероятность захода бота на главную страницу при периодичности раз в неделю и 10 секунд на выполнение запроса - 0.0000165. Вероятность одновременного происхождения обоих событий равна произведению - 0.0000000825. И вот теперь умножаем это на 52 и получаем 0.00000429 (0.000429%) - это вероятность выпадения страницы из индекса в течение года.
Для новичка может быть удивительным открытием то, что массив на двух разных дисках, даже сомнительного и высокого качества, более надежен, чем на двух одинаковых, пусть и высокого качества. Рекомендую углублять знания, а не ориентироваться на ощущения. Основная причина заключается в том, что если отказ диска вызывается какими-то условиями эксплуатации, то для двух одинаковых дисков вероятность одновременного отказа по такой причине намного выше. Именно из-за того, что они эксплуатируются вместе в одинаковых условиях.
Хорошим примером может быть анализ отказов RAID 1 на Seagate 7200.11 NS , которые из-за проблемы в firmware умирали одновременно после перезагрузки и убивали массив. Еще из масштабных примеров - выход из строя IBM DTLA, которые умирали группами при небольшом перегреве.
Использование для RAID массивов дисков разных серий, а лучше, разных производителей - это один из самых простых, хотя и немного удоражающих способов повышения отказоустойчивости дисковой системы.
Напротив, для повышения надежности лучше, чтобы диски были разными, это азбука. Существенно снижается риск одновременного выхода из строя при возникновении условий, критичных для одной серии.
