- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Как удалить плохие SEO-ссылки и очистить ссылочную массу сайта
Применяем отклонение ссылок
Сервис Rookee
В 2023 году Одноклассники пресекли более 9 млн подозрительных входов в учетные записи
И выявили более 7 млн подозрительных пользователей
Оксана Мамчуева
ну вот, а почему с проверками у вас получается что вероятность попадания следующих проверок зависит от предыдущих?
Во первых я так не "считаю", а только привожу наглядные примеры, для простоты понимания.
Но даже с ними все очень туго.
Во вторых - я и не знал что робот гугля (с которого начался срач) на сайт заходит 52 раза в первую неделю, а потом год на сайте не бывает.
И хосттрекер тоже проверки делает совсем не равномерно.
В общем вам надо откуда то плясать - вы и "пляшите":
посчитайте вероятность не заметить ошибку, если 50% аптайм, 100 проверок за сутки, скорость открытия страницы - 0,2 сек.
для таких умников облачные сервисы тарифицируют трафик.
Ясное дело, тарифы я уже посмотрел, вопрос не в том, чтобы не платить за что-то, а в том, что я не очень понимаю что такое ddos и может ли супер производительный фронтенд помочь с этим справиться.
Опять же правильно "почти".
Вероятность успешной работы системы = произведение вероятностей успешной работы всех систем.
Вероятность сбоя сложной системы = 1 - вероятность успешной работы.
Да, тут Вы правы на 100%, я не правильно написал, но имел ввиду правильное :)
Простая иллюстрация вашей ошибки - обратитесь к сайту 52 раза не за год, а за минуту или за час. Вы уверены, что с вероятностью 26% получите отказ? Обратитесь 520 раз за час - по вашей методике подсчета вероятность отказа будет 92%. Повторяйте эту серию обращений каждый час в течение года, у вас все эти разы вероятность отказа должна быть 92%. Все еще считаете, что у вас нет ошибки?
Выше я приводил правильный расчёт.
У Вас ошибочное понимание того, что uptime и вероятность доступности сайта одно и тоже. Эти два параметра численно равны только при стремлении времени к бесконечности. В условиях нашей задачи год можно считать достаточно большим промежутком времени; неделя или час недостаточно большие.
Т.к падения сайта вызывает финансовые потери, если сайт падает редко, но метко(то есть на часы, но редко, а не постоянно на секунды; что как раз соответствует действительности), то можно считать, что
несколько секунд(ожидание бота ПС) << час << неделя < год
И если бот будет ждать только доли секунды(типо время стремится к нулю), то вероятность к нулю стремиться не будет.
З.Ы. У меня второе высшее как раз защита информации. Включает в себя анализ рисков и т.д.
ЕСЛИ ваш проект действительно денежный - могу вам на платной основе помочь действительно корректно посчитать ваши риски и прикинуть оптимальный аптайм с средства борьбы за него.
Спасибо, но в принципе я всё уже прикинул. Тема была создана под впечатлением топиков и тем про отказ дисков в серверах и прочей ерунде, которая приводит к часовым простоям, а то и больше, которые приносят ощутимые финансовые потери(потери - не обязательно убыток, но и недополученная прибыль).
Пока считаю, что двойное резервирование достаточно, чтобы гарантировать отсутствие долгих простоев.
Товарищи, давайте не будем углубляться в тервер 3 курса института и пытаться показать свои мегазнания в области подбрасывания монеток, ведь правильный расчёт по серверам уже был приведен(мной :)), а сойдёмся, что все мы учились хорошо и было это полезно, но довольно давно, а поскольку такие знания приходится редко применять, то кто-то что-то мог подзабыть :)
Давайте лучше обсудим облака и возможность их помочь при ddos атаке, хотя бы слабой. Неужели это никому не интересно или для всех ответ на этот вопрос очевиден?
Честно - не знал. Это хорошо характеризует разработчиков броузеров .
Что-то не могу найти. Возможно, это была просто одна из идей высказанных кем-то для разработчиков браузеров. И ведь неплохая идея, позволяющая удовлетворить всех.
Сейчас поставил эксперимент на ie8 - не работает.
Облака это мега сложный черный ящик, у которого есть какие то заявленные характеристики,
но сколько нибудь верить этим характеристикам с точки зрения надежности - наверное не стоит.
По делу - ваши падения фронт-эндов проще всего разрулить применением N балансеров перед, простых как апельсин. И сломать их может только канальный DDoS.
И уже эти балансеры могут очень оперативно принимать решение.
Применять облака для борьбы с DDoS это как правило ну очень дорого.
freedz, по техническим вещам в топике достаточно хорошо рассказали, углубляться здесь в тысячу деталей, специфичных для разных случаев, мало кому интересно. Но есть важный аспект - оценка надежности и стоимости реализаций различных решений.
Обращение к альтернативному решению на базе кластера основывается на вашей исходной предпосылке в высокой вероятности выпадения главной из поиска. В принципе, за свои деньги вы имеете полное право ошибаться как угодно. hvosting в своем стремлении продать вам консультацию может поддерживать вас в этом заблуждении либо из корыстного интереса, либо из-за плохого владения вопросом. Жаль, что вы вдвоем в этом топике в итоге "гарантировали" безумно высокие риски выпадение из поиска всех сайтов у всех хостеров и теперь в этом настойчиво убеждаете читателей. Но вернемся к вашему конкретному вопросу.
Так вот в оценке того, что будет надежней для небольшого коммерческого сайта - разместиться на хорошем веб-хостинге, VDS или выделенном сервере, или собрать на нескольких серверах отказоустойчивый кластер, правильным решением будет почти всегда без кластера. Потому что хорошую, красивую, сложную систему, нужно хорошо спроектировать, хорошо реализовать, и хорошо поддерживать. Если этим вопросом будут заниматься фрилансеры на разовых контрактах без постоянной поддержки, или просто любители, ломаться система будет намного чаще, чем обычный качественный хостинг, который обслуживается хорошими специалистами.
В 2000-2001 мы реализовали это в Net.Ru. Там была сложная схема их группы фронтендов и бэкендов, размещенные с взаимным резервированием в трех датацентрах. Достаточно долго мы были единственными с таким решением. Были немного похожие вещи у Зенона и Мастерхоста, но в пределах одного датацентра.
Для того времени это решение было, действительно, оправдано, т.к. не высокая надежность ДЦ существенно ухудшалась пиринговыми войнами крупных телекомов и их следствием - долгими периодами плохой связности между крупными частями рунета. Наша схема с разными датацентрами особенно хорошо помогала для последнего.
Но примерно с 2007 эту схему мы расформировали, оставив только взаимное резервирование между двумя ДЦ. Расформировали по той причине, что исчезла необходимость - отказы стали значительно реже. Затраты на содержание в эксплуатации сложной схемы достаточно большие (в том числе на минимизацию внутренних сбоев и негативного влияния человеческого фактора). Существенного выигрыша в надежности от сложной схемы не было, и без нее оборудование и ДЦ работали уже достаточно хорошо. Да, случались аварии, приходилось переключаться на резервы, были простои по несколько часов. Но проблемы падения каналов, умирания дисков или железа проще и надежнее решались локальными техническими решениями.
1) DNS переведём на сервис, который позволяет делать "DNS+failover"(если можно получить скорость отключения нерабочего фронтенда порядка минуты).
2) В качестве параллельных фронтендов будут два VPS
3) Фронтенды будут подтягивать сайты с двух серверов(один основной и один дублирующий).
В целом, эта хорошая, каноническая схема. Обратите внимание на то, что фронтены должны не только ориентироваться на доступность бэкендов, но и распознавать менее очевидные сбои - на уровне приложения или системы. Например, сломалась одна из таблиц БД и страницы генерируются с ошибками. Часто при этом страницы сайта отдаются с тем же кодом 200, как будто ошибок нет. Если у вас репликация данных между бэкендами идет по DRBD, то на дублере тоже будет сломанная таблица. Если сбой файловой системы повредит часть данных, они будут повреждены и на дублере. Также нужно предусмотреть сплитбрейт - если фронтенды из-за разной доступности стали обращаться к разным бэкендам.
С защитой от DoS не так все просто. Если это слабая атака, которая решается файерволом и http-proxy, она может решаться и без отдельного фронтенда. Если атака серьезная, то размазывание по нескольким фронтендам от нее не спасет. Да и провайдеры, если в услугу не включена защита от DoS, чаще всего просто блокируют атакуемые серверы.
---------- Добавлено 16.06.2012 в 23:48 ----------
Что-то не могу найти. Возможно, это была просто одна из идей высказанных кем-то для разработчиков браузеров. И ведь неплохая идея, позволяющая удовлетворить всех.
Сейчас поставил эксперимент на ie8 - не работает.
С DNS вряд ли бы работало - если браузер снова запросит адрес, он его получит из кэша DNS-сервера.
Возможно, у вас в памяти задержалось из-за другого - многие программы во время подключения к серверу по TCP, в том случае, если DNS вернул для имени несколько IP-адресов, при ошибки подключения к первому адресу пробуют поочередно подключиться ко всем остальным. Это не требования стандарта, но большинство программ, включая веб-браузеры, реализует этот механизм.
На базе него строится простой, но не очень хороший вариант - failover на round robin DNS. Если при попытке подключиться к первому IP-адресу мы быстро получаем ошибку - host unreachable, connection refused или что-то в этом роде, переключение на следующий идет сразу же. Но если запросы на соединение уходят в пустоту и не показывают сразу же ошибки (сбой маршрутизации, аварийное отключение сервера), то клиент ждет до истечения таймаута (достаточно долго, чаще всего, не меньше минуты), прежде чем перейти к следующему адресу. Ну и второй недостаток - это не требования стандарта, это не реализуется готовыми функциями ОС (скажем, POSIX), поэтому могут быть и наверняка есть браузеры, которые такой механизм не реализуют.
hvosting в своем стремлении продать вам консультацию может поддерживать вас в этом заблуждении либо из корыстного интереса, либо из-за плохого владения вопросом.
1. Я тебе задал конкретный вопрос: Посчитай по своей супер методе
вероятность того, что клиент заметит обвал своего сайта
а) плотно работая со своим сайтом, и делая к нему 100 обращений в час,
б) uptime 50% (30 минут простоя в течение часа)
в) скорость открытия страницы 0,2 сек (хотя _на самом деле_ для расчетов это не важно)
Продемонстрируй свой шикарный ответ 0,003% или 0,3% в зависимости от того
захочется тебе учесть 100 попыток или нет, и если до тебя не дойдет
бредовость обоих цифирей (еще раз повторяю - клиент не вылезая ходит по своему сайту
и с вероятностью 99,7% не замечает 30 минутного простоя)
то поможет тебе только стена.
Если у вас репликация данных между бэкендами идет по DRBD
Молодец!! Других способов репликации БД ты конечно знаешь кучу, и долго выбирал самый "подходящий" для примера.
С DNS вряд ли бы работало - если браузер снова запросит адрес, он его получит из кэша DNS-сервера.
Писатель, в теме обсуждался TTL кеша. Не читал?
если DNS вернул для имени несколько IP-адресов, при ошибки подключения к первому адресу пробуют поочередно подключиться ко всем остальным.
....
На базе него строится простой, но не очень хороший вариант - failover на round robin DNS.
Отлично. То что я ранее (бесплатнно?!) посоветовал перед фронт-эндами (вероятно протекающими и имеющими не тривиальную логику) поставить пачку тупых надежных балансеров (haproxy или подобные по простоте) тоже не прочитал?
Простая иллюстрация вашей ошибки - обратитесь к сайту 52 раза не за год, а за минуту или за час. Вы уверены, что с вероятностью 26% получите отказ?
Коллега, хвостинг сделал допущение, что периоды недоступности сайта распределены по временному отрезку равномерно. Это разумеется неверно, но когда мы берём бесконечно большой отрезок времени, это допущение работает. И когда мы берём год - оно хуже, но работает. А когда мы берём минуту, то оно работает из рук вон плохо - но это совсем не значит, что расчёт сделан плохо - он сделан при-бли-зи-тель-но.
Коллега, хвостинг сделал допущение, что периоды недоступности сайта распределены по временному отрезку равномерно. Это разумеется неверно, но когда мы берём бесконечно большой отрезок времени, это допущение работает. И когда мы берём год - оно хуже, но работает. А когда мы берём минуту, то оно работает из рук вон плохо - но это совсем не значит, что расчёт сделан плохо - он сделан при-бли-зи-тель-но.
Я,#$@!, НЕ ДЕЛАЛ ДОПУЩЕНИЯ!!!!
О чем уже 2 раза (!!!) писал.
ТС изначально все правильно посчитал. АКАДЕМИЧНО!
А я приводил НАГЛЯДНЫЕ ПРИМЕРЫ, более того не верные, приблизительные "народные" или "студенческие" методы расчета,
просто чтобы наглядно продемонстировать полную бредовость "альтернативно одаренного" метода, дающего отличие в 1000000 раз от визуального приблизительного ответа.
Чипсов не хотите?
С DNS вряд ли бы работало - если браузер снова запросит адрес, он его получит из кэша DNS-сервера.
Что-то вы, товарищ главный инженер, не понимаете.
Кеш dns-сервера и клиента уже строго придерживается TTL. С этим кешем уже нет проблем. И это могло бы быть хорошим решением, если бы не поведение IE.
Ну, учитывая, что SEO-сайты посетитель обычно закрывает сразу же после открытия, свой клиент найдется и на такую услугу.
...
наверняка есть браузеры, которые такой механизм не реализуют.
Не работает. Вообще нет таких браузеров. Специальные службы у microsoft или jabber могут использовать разный порядок и приоритеты на основе информации из DNS, но к сожалению, не браузеры.