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

1 2345 6
H
На сайте с 12.05.2007
Offline
133
#31
klamas:

ну вот, а почему с проверками у вас получается что вероятность попадания следующих проверок зависит от предыдущих?

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

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

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

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

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

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

hvosting.ua (http://hvosting.ua/)
freedz
На сайте с 16.04.2007
Offline
115
#32
netwind:
для таких умников облачные сервисы тарифицируют трафик.

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

hvosting:
Опять же правильно "почти".

Вероятность успешной работы системы = произведение вероятностей успешной работы всех систем.
Вероятность сбоя сложной системы = 1 - вероятность успешной работы.

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

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

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

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

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

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

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

hvosting:
З.Ы. У меня второе высшее как раз защита информации. Включает в себя анализ рисков и т.д.
ЕСЛИ ваш проект действительно денежный - могу вам на платной основе помочь действительно корректно посчитать ваши риски и прикинуть оптимальный аптайм с средства борьбы за него.

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

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

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

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

N
На сайте с 06.05.2007
Offline
419
#33
hvosting:
Честно - не знал. Это хорошо характеризует разработчиков броузеров .

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

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

Кнопка вызова админа ()
H
На сайте с 12.05.2007
Offline
133
#34

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

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

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

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

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

C
На сайте с 06.10.2009
Offline
69
#35

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

Обращение к альтернативному решению на базе кластера основывается на вашей исходной предпосылке в высокой вероятности выпадения главной из поиска. В принципе, за свои деньги вы имеете полное право ошибаться как угодно. hvosting в своем стремлении продать вам консультацию может поддерживать вас в этом заблуждении либо из корыстного интереса, либо из-за плохого владения вопросом. Жаль, что вы вдвоем в этом топике в итоге "гарантировали" безумно высокие риски выпадение из поиска всех сайтов у всех хостеров и теперь в этом настойчиво убеждаете читателей. Но вернемся к вашему конкретному вопросу.

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

В 2000-2001 мы реализовали это в Net.Ru. Там была сложная схема их группы фронтендов и бэкендов, размещенные с взаимным резервированием в трех датацентрах. Достаточно долго мы были единственными с таким решением. Были немного похожие вещи у Зенона и Мастерхоста, но в пределах одного датацентра.

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

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

freedz:

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

В целом, эта хорошая, каноническая схема. Обратите внимание на то, что фронтены должны не только ориентироваться на доступность бэкендов, но и распознавать менее очевидные сбои - на уровне приложения или системы. Например, сломалась одна из таблиц БД и страницы генерируются с ошибками. Часто при этом страницы сайта отдаются с тем же кодом 200, как будто ошибок нет. Если у вас репликация данных между бэкендами идет по DRBD, то на дублере тоже будет сломанная таблица. Если сбой файловой системы повредит часть данных, они будут повреждены и на дублере. Также нужно предусмотреть сплитбрейт - если фронтенды из-за разной доступности стали обращаться к разным бэкендам.

С защитой от DoS не так все просто. Если это слабая атака, которая решается файерволом и http-proxy, она может решаться и без отдельного фронтенда. Если атака серьезная, то размазывание по нескольким фронтендам от нее не спасет. Да и провайдеры, если в услугу не включена защита от DoS, чаще всего просто блокируют атакуемые серверы.

---------- Добавлено 16.06.2012 в 23:48 ----------

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

С DNS вряд ли бы работало - если браузер снова запросит адрес, он его получит из кэша DNS-сервера.

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

На базе него строится простой, но не очень хороший вариант - failover на round robin DNS. Если при попытке подключиться к первому IP-адресу мы быстро получаем ошибку - host unreachable, connection refused или что-то в этом роде, переключение на следующий идет сразу же. Но если запросы на соединение уходят в пустоту и не показывают сразу же ошибки (сбой маршрутизации, аварийное отключение сервера), то клиент ждет до истечения таймаута (достаточно долго, чаще всего, не меньше минуты), прежде чем перейти к следующему адресу. Ну и второй недостаток - это не требования стандарта, это не реализуется готовыми функциями ОС (скажем, POSIX), поэтому могут быть и наверняка есть браузеры, которые такой механизм не реализуют.

H
На сайте с 12.05.2007
Offline
133
#36
cvss:
hvosting в своем стремлении продать вам консультацию может поддерживать вас в этом заблуждении либо из корыстного интереса, либо из-за плохого владения вопросом.

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

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

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

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

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

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

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

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

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

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

cvss:

Если у вас репликация данных между бэкендами идет по DRBD

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

cvss:

С DNS вряд ли бы работало - если браузер снова запросит адрес, он его получит из кэша DNS-сервера.

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

cvss:

если DNS вернул для имени несколько IP-адресов, при ошибки подключения к первому адресу пробуют поочередно подключиться ко всем остальным.
....
На базе него строится простой, но не очень хороший вариант - failover на round robin DNS.

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

-=Илья=-
На сайте с 05.12.2003
Offline
222
#37
cvss:
Простая иллюстрация вашей ошибки - обратитесь к сайту 52 раза не за год, а за минуту или за час. Вы уверены, что с вероятностью 26% получите отказ?

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

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

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

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

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

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

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

leo3331
На сайте с 07.01.2007
Offline
154
#39

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

N
На сайте с 06.05.2007
Offline
419
#40
cvss:
С DNS вряд ли бы работало - если браузер снова запросит адрес, он его получит из кэша DNS-сервера.

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

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

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

На базе него строится простой, но не очень хороший вариант - failover на round robin DNS. Если при попытке подключиться к первому IP-адресу мы быстро получаем ошибку - host unreachable, connection refused или что-то в этом роде, переключение на следующий идет сразу же.
...
наверняка есть браузеры, которые такой механизм не реализуют.

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

1 2345 6

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