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

Вероятности неправильно посчитаны. Вероятность отказа для 99.5% аптайма - 0.005. Вероятность захода бота на главную страницу при периодичности раз в неделю и 10 секунд на выполнение запроса - 0.0000165. Вероятность одновременного происхождения обоих событий равна произведению - 0.0000000825. И вот теперь умножаем это на 52 и получаем 0.00000429 (0.000429%) - это вероятность выпадения страницы из индекса в течение года.

Нет, вероятности у ТС посчитаны правильно.

Второй вариант подсчета (не точный, но при высоком аптайме катит) :

при обращении к сайту вероятность получить ошибку 0,5%

обращений за год 52.

умножаем 0,5% на 52 = 26%

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

ТС посчитал более точным способом, но он с непривычки не всем понятен.

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

Сюда давайте добавим возможные проблемы с каналом и электричеством если все делать в одном дц...

Можно конечно сделать все бюджетно на базе 1 сервера в двумя бп и т.д. , разбив на виртуалки.

Хорошо, что люди, привычные к такому способу занимаются безобидным хостингом, а не строительством :)

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

Простая иллюстрация вашей ошибки - обратитесь к сайту 52 раза не за год, а за минуту. Вы уверены, что с вероятностью 26% получите отказ?

Может быть события, а не величины? :)

Дано - вероятность успешно открыть сайт = 99,5%

требуется посчитать - с какой вероятностью удасться открыть сайт успешно 52 раза подряд.

Вероятность сегодня и через неделю ну точно одинаковые, и события эти не связанные.

То что мои подсчеты не верные (но с приемлемой погрешностью) я в курсе.

При DNS+failover время переключения равно TTL + инертность самого фейловер-механизма.

В цифрах можно добиться от 30 до 60 секунд.

При переключении в HA-кластерах у нас в среднем 0.3 секунды.

Схема выглядит как 2 сервера(каждый со своим айпи,техническим)+линк между ними, внутри синхронизация данных, как правило через механизм DRBD, но в целом никто не мешает использовать дисковую полку+HBA(дороже). Внутри одного сервера пускается образ виртуальной машины со своим айпи(рабочим, где сервисы), читает/пишет данные из раздела под DRBD или из полки. При падении первой машины виртуалка подымает сервисы на второй, управление идет через HB/Peacemaker, айпи(контейнер виртуалки) перепрыгивает на соседнюю машину.

Когда 2 фронтенда, появляется избыточное резервирование, т.е уже в работе 4 машины. Теоретически чем больше точек отказа - тем нестабильнее система, плюс задача контроля какой из фронтов ловит трафик. Появляется возврат к какому либо из двух описанных мною вариантов.

Про математику:

Конечный результат правильный, но когда писал, чуть-чуть описАлся в предыдущем посте, правильно:

(99.5/100)^(52) = 0.995^52 ~ 0.77 - вероятность, что бот за год будет заходить только на доступный сайт => 1 - 0.77= 0.23, то есть 23% - вероятность, что хоть раз за год бот зайдёт на недоступный сайт.

Вероятность что при однократном случайном заходе сайт будет доступен = 0.995

Вероятность что при двух случайных заходах сайт всегда(оба раза) будет доступен = 0.995 * 0.995

и тд

Для примера: вы подкидываете монетку, какая вероятность, что у Вас 10 раз подряд выпадет орёл? Ответ: 0.5^10

А если взять не 10 секунд, а время стремящееся к нулю, то вероятность по вашему тоже будет стремиться к нулю? Но это ведь не так :)

В своих расчётах я пренебрёг временем ожидания бота, посчитав его нулевым(т.к оно составляет менее 3% от среднего недельного времени простоя, а вычисления бы сильно усложнились).

yesRuslik, по идеи чем больше фронтендов тем выше отказоустойчивость(есть 3 "слоя": dns хостинг, фронтенд, основные сервера; и по идеи вероятность отказа всей системы - произведение вероятностей отказа всех "слоёв", дублирование фронтенда улучшает отказоустойчивость "слоя" фронтендов и ведёт к увеличению общей отказоустойчивости).

Спасибо всем за помощь и советы, особенно yesRuslik'у.

Что такое TTL? Это http://ru.wikipedia.org/wiki/Time_to_live? Из википедии:

Про какое кеширование здесь идёт речь?

То есть как получается время меньше минуты?

Я так понимаю это процесс, поправьте, пожалуйста, если заблуждаюсь:

Пользователь набирает домен в браузере, его провайдер берёт и смотрим в кеш и отправляет пользователя по IP, который там указан, то есть пока провайдер не обновит свой кеш, изменений пользователь не увидит, а обновление провайдером кеша может занимать долгое время.

Пока в голове созрел вот такой вот план:

1) DNS переведём на сервис, который позволяет делать "DNS+failover"(если можно получить скорость отключения нерабочего фронтенда порядка минуты).

2) В качестве параллельных фронтендов будут два VPS

3) Фронтенды будут подтягивать сайты с двух серверов(один основной и один дублирующий).

По идеи прокси VPS(фронтенды) потребляют мало ресурсов(место на диске не занимают и тд), может быть их засунуть в облако?

Поможет ли облако для отражения ddos атаки по сравнению со слабыми VPS?

freedz, у вас и у hvosting ошибка в том, что вы стали считать аптайм вероятностью удачного захода, что неправильно. Как в анекдоте про вероятность встретить инопланетянина - 50%, либо встречу, либо нет.

Способ посчитать правильно я привел. При времени проверки, стремящемся к нулю, вероятность тоже стремится к нулю, все верно.

Не хочу пересказывать учебник тервера и разбирать с вами, где и почему вы ошиблись. Простая иллюстрация вашей ошибки - обратитесь к сайту 52 раза не за год, а за минуту или за час. Вы уверены, что с вероятностью 26% получите отказ? Обратитесь 520 раз за час - по вашей методике подсчета вероятность отказа будет 92%. Повторяйте эту серию обращений каждый час в течение года, у вас все эти разы вероятность отказа должна быть 92%. Все еще считаете, что у вас нет ошибки?

Про любое кеширование. Любые элементы DNS могут кешировать и обязаны это делать не более чем прописано в TTL ответа. И делают это. Причем, в распространенном софте типа bind принципиально нет настроек чтобы игнорировать TTL.

TTL в зонах второго уровня от 1 до 4 суток. И его поменять у клиента нет возможности. Но TTL записей на своих ns-серверах поменять можно и именно его делают маленьким.

Если один из ns-серверов домена не отвечает, ПО dns будет опрашивать другой до получения ответа.

Что касается вероятностей, то что бы вы там не насчитали, я тоже убежден что вам проще будет найти просто хороший хостинг.

для таких умников облачные сервисы тарифицируют трафик.

Берете - ВПС и нормальную контору каждый впс желательно на платформе ксен и у адекватного хостера ☝ с 24 / 7 суппортом - это обязательно !

Админы вам настраивает зеркало скажем с синхронизацией раз в час или день, или 30 минут как захотите ;) Что-то случается - переключаете на другой впс и все днсы переключит админ на хостинге либо сами. Да должен быть мониторинг впса , можно с смсками на ваш телефон если что-то случается.

Цена вопроса два впса по $20-$30 все.

По аптайму: США у нас по 5-6 лет в коннекте есть сервера - но это как повезет (+пинг оттуда дольше), Британия там за год всреднем минут 15 траблов пару раз такое было, Германия ну когда как, но тоже не долго макс 1-2 часа траблы с каналами были ...Украина - Россия ну там тоже можно один держать или резервный ;) там сумарно 99.5 % У нас за год аптайм....

Есть вариант еще всетаки сделать бекап вообще вдругой конторе - вдруг хостера убьют либо компанию закроют, либо любой другой форс мажер, но вероятность такого меньше 0,01% :)

Я по своим проектам так делал и все всегда 100% работало - по облакам там траблов не мало - они не выручат ....