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

Во первых я так не "считаю", а только привожу наглядные примеры, для простоты понимания.

Но даже с ними все очень туго.

Во вторых - я и не знал что робот гугля (с которого начался срач) на сайт заходит 52 раза в первую неделю, а потом год на сайте не бывает.

И хосттрекер тоже проверки делает совсем не равномерно.

В общем вам надо откуда то плясать - вы и "пляшите":

посчитайте вероятность не заметить ошибку, если 50% аптайм, 100 проверок за сутки, скорость открытия страницы - 0,2 сек.

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

Да, тут Вы правы на 100%, я не правильно написал, но имел ввиду правильное :)

Выше я приводил правильный расчёт.

У Вас ошибочное понимание того, что uptime и вероятность доступности сайта одно и тоже. Эти два параметра численно равны только при стремлении времени к бесконечности. В условиях нашей задачи год можно считать достаточно большим промежутком времени; неделя или час недостаточно большие.

Т.к падения сайта вызывает финансовые потери, если сайт падает редко, но метко(то есть на часы, но редко, а не постоянно на секунды; что как раз соответствует действительности), то можно считать, что

несколько секунд(ожидание бота ПС) << час << неделя < год

И если бот будет ждать только доли секунды(типо время стремится к нулю), то вероятность к нулю стремиться не будет.

Спасибо, но в принципе я всё уже прикинул. Тема была создана под впечатлением топиков и тем про отказ дисков в серверах и прочей ерунде, которая приводит к часовым простоям, а то и больше, которые приносят ощутимые финансовые потери(потери - не обязательно убыток, но и недополученная прибыль).

Пока считаю, что двойное резервирование достаточно, чтобы гарантировать отсутствие долгих простоев.

Товарищи, давайте не будем углубляться в тервер 3 курса института и пытаться показать свои мегазнания в области подбрасывания монеток, ведь правильный расчёт по серверам уже был приведен(мной :)), а сойдёмся, что все мы учились хорошо и было это полезно, но довольно давно, а поскольку такие знания приходится редко применять, то кто-то что-то мог подзабыть :)

Давайте лучше обсудим облака и возможность их помочь при ddos атаке, хотя бы слабой. Неужели это никому не интересно или для всех ответ на этот вопрос очевиден?

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

Сейчас поставил эксперимент на ie8 - не работает.

Облака это мега сложный черный ящик, у которого есть какие то заявленные характеристики,

но сколько нибудь верить этим характеристикам с точки зрения надежности - наверное не стоит.

По делу - ваши падения фронт-эндов проще всего разрулить применением N балансеров перед, простых как апельсин. И сломать их может только канальный DDoS.

И уже эти балансеры могут очень оперативно принимать решение.

Применять облака для борьбы с DDoS это как правило ну очень дорого.

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), поэтому могут быть и наверняка есть браузеры, которые такой механизм не реализуют.

1. Я тебе задал конкретный вопрос: Посчитай по своей супер методе

вероятность того, что клиент заметит обвал своего сайта

а) плотно работая со своим сайтом, и делая к нему 100 обращений в час,

б) uptime 50% (30 минут простоя в течение часа)

в) скорость открытия страницы 0,2 сек (хотя _на самом деле_ для расчетов это не важно)

Продемонстрируй свой шикарный ответ 0,003% или 0,3% в зависимости от того

захочется тебе учесть 100 попыток или нет, и если до тебя не дойдет

бредовость обоих цифирей (еще раз повторяю - клиент не вылезая ходит по своему сайту

и с вероятностью 99,7% не замечает 30 минутного простоя)

то поможет тебе только стена.

Молодец!! Других способов репликации БД ты конечно знаешь кучу, и долго выбирал самый "подходящий" для примера.

Писатель, в теме обсуждался TTL кеша. Не читал?

Отлично. То что я ранее (бесплатнно?!) посоветовал перед фронт-эндами (вероятно протекающими и имеющими не тривиальную логику) поставить пачку тупых надежных балансеров (haproxy или подобные по простоте) тоже не прочитал?

Коллега, хвостинг сделал допущение, что периоды недоступности сайта распределены по временному отрезку равномерно. Это разумеется неверно, но когда мы берём бесконечно большой отрезок времени, это допущение работает. И когда мы берём год - оно хуже, но работает. А когда мы берём минуту, то оно работает из рук вон плохо - но это совсем не значит, что расчёт сделан плохо - он сделан при-бли-зи-тель-но.

Я,#$@!, НЕ ДЕЛАЛ ДОПУЩЕНИЯ!!!!

О чем уже 2 раза (!!!) писал.

ТС изначально все правильно посчитал. АКАДЕМИЧНО!

А я приводил НАГЛЯДНЫЕ ПРИМЕРЫ, более того не верные, приблизительные "народные" или "студенческие" методы расчета,

просто чтобы наглядно продемонстировать полную бредовость "альтернативно одаренного" метода, дающего отличие в 1000000 раз от визуального приблизительного ответа.

Чипсов не хотите?

Что-то вы, товарищ главный инженер, не понимаете.

Кеш dns-сервера и клиента уже строго придерживается TTL. С этим кешем уже нет проблем. И это могло бы быть хорошим решением, если бы не поведение IE.

Ну, учитывая, что SEO-сайты посетитель обычно закрывает сразу же после открытия, свой клиент найдется и на такую услугу.

Не работает. Вообще нет таких браузеров. Специальные службы у microsoft или jabber могут использовать разный порядок и приоритеты на основе информации из DNS, но к сожалению, не браузеры.