Я,#$@!, НЕ ДЕЛАЛ ДОПУЩЕНИЯ!!!!
О чем уже 2 раза (!!!) писал.
ТС изначально все правильно посчитал. АКАДЕМИЧНО!
А я приводил НАГЛЯДНЫЕ ПРИМЕРЫ, более того не верные, приблизительные "народные" или "студенческие" методы расчета,
просто чтобы наглядно продемонстировать полную бредовость "альтернативно одаренного" метода, дающего отличие в 1000000 раз от визуального приблизительного ответа.
1. Я тебе задал конкретный вопрос: Посчитай по своей супер методе
вероятность того, что клиент заметит обвал своего сайта
а) плотно работая со своим сайтом, и делая к нему 100 обращений в час,
б) uptime 50% (30 минут простоя в течение часа)
в) скорость открытия страницы 0,2 сек (хотя _на самом деле_ для расчетов это не важно)
Продемонстрируй свой шикарный ответ 0,003% или 0,3% в зависимости от того
захочется тебе учесть 100 попыток или нет, и если до тебя не дойдет
бредовость обоих цифирей (еще раз повторяю - клиент не вылезая ходит по своему сайту
и с вероятностью 99,7% не замечает 30 минутного простоя)
то поможет тебе только стена.
Молодец!! Других способов репликации БД ты конечно знаешь кучу, и долго выбирал самый "подходящий" для примера.
Писатель, в теме обсуждался TTL кеша. Не читал?
Отлично. То что я ранее (бесплатнно?!) посоветовал перед фронт-эндами (вероятно протекающими и имеющими не тривиальную логику) поставить пачку тупых надежных балансеров (haproxy или подобные по простоте) тоже не прочитал?
Облака это мега сложный черный ящик, у которого есть какие то заявленные характеристики,
но сколько нибудь верить этим характеристикам с точки зрения надежности - наверное не стоит.
По делу - ваши падения фронт-эндов проще всего разрулить применением N балансеров перед, простых как апельсин. И сломать их может только канальный DDoS.
И уже эти балансеры могут очень оперативно принимать решение.
Применять облака для борьбы с DDoS это как правило ну очень дорого.
Во первых я так не "считаю", а только привожу наглядные примеры, для простоты понимания.
Но даже с ними все очень туго.
Во вторых - я и не знал что робот гугля (с которого начался срач) на сайт заходит 52 раза в первую неделю, а потом год на сайте не бывает.
И хосттрекер тоже проверки делает совсем не равномерно.
В общем вам надо откуда то плясать - вы и "пляшите":
посчитайте вероятность не заметить ошибку, если 50% аптайм, 100 проверок за сутки, скорость открытия страницы - 0,2 сек.
не 52 а 520 проверок. _в час_ . при аптайме 99.5% Хоть бы условие прочитали, о котором речь.... иксперты.
Или просто троли ? :)---------- Добавлено 15.06.2012 в 16:34 ----------
Если у монетки не 2 орла - то 49,999%.
оставим 0,002% на то, что монетка может упасть на ребро.
Да, если каждый час будет 18 секунд простоя, то каждый час я увижу хоть одну ошибку, с вероятностью 92%. Или не увижу ни одной ошибки, с вероятностью 8%.
Если за один час имеем 99,5% аптайма, то имеем простоя в этот час цельных 18 секунд.
и при этом каждые 7 секунд проверяем состояние сайта.
Вот и подумай, с какой вероятностью эти 18 секунд простоя пролетят мимо проверок, которые происходят каждые 7 секунд...
Садись, два. На пересдачу.---------- Добавлено 15.06.2012 в 16:15 ----------
Честно - не знал. Это хорошо характеризует разработчиков броузеров :).
Пруфлинк не найдете, с исследованиями?
Опять же правильно "почти".
Вероятность успешной работы системы = произведение вероятностей успешной работы всех систем.
Вероятность сбоя сложной системы = 1 - вероятность успешной работы.
====
Если сбой уже наступил - используется более дискретный подход:
Ждем поднятия этого сервиса (если не критическая ошибка бекенда)?
Переключаемся на уже поднятый запасной сервис, с отставанием по данным (синхронизация по времени)?
Поднимаемся из резервной копии на еще не запущенный запасной сервис ?
ПРИЧЕМ!!
потеря информации за дельта T может быть дороже лишних 30 минут простоя.
Потому банки категорически предпочитают "полежать" лишних 30 минут, чем раскатывать бакапы. А хостеры наоборот.
Хороший план. Коварный.
1. Получить скорость отключения порядка минуты можно....
Но на практике будет 2-4 минуты (ибо "бюрократия" :) ).
И еще момент - при каждом обращении к странице броузер не посылает новые запросы в DNS.
Если клиент УЖЕ находился на сайте в момент аварии - переключение DNS ему поможет не слишком эффективно.
При этом за минуту можно успеть поднять фронтенд.
2. Надежность VPS по определению ниже чем надежность оборудования, на котором он базируется.
Конечно его в одном месте можно быстро погасить, в другом поднять, но факт "сбоя" уже
случился и система завертелась.
А синхронная перезагрузка 2-х VPS-ов? Как себя должна вести система?
3. Синхронизация (причем, простите за тавтологию - синхронная) данных между основным и дублирующим сервером, и взаимная смена ролей - это основной гемор в вашем проекте.
З.Ы. У меня второе высшее как раз защита информации. Включает в себя анализ рисков и т.д.
ЕСЛИ ваш проект действительно денежный - могу вам на платной основе помочь действительно корректно посчитать ваши риски и прикинуть оптимальный аптайм с средства борьбы за него.
Дорогой, сдай сначала сессию, а потом компостируй мозг своими гениальными познаниями теорвера людям с двумя техническими высшими.
Может быть события, а не величины? :)
Дано - вероятность успешно открыть сайт = 99,5%
требуется посчитать - с какой вероятностью удасться открыть сайт успешно 52 раза подряд.
Вероятность сегодня и через неделю ну точно одинаковые, и события эти не связанные.
То что мои подсчеты не верные (но с приемлемой погрешностью) я в курсе.
