- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Зачем быть уникальным в мире, где все можно скопировать
Почему так важна уникальность текста и как она влияет на SEO
Ingate Organic
99,5%. Если на главную страницу бот заходит раз в неделю, а в году 52 недели, то
99,5^52 = 0,77, следовательно с вероятностью 23% за год у Вас должна вылететь главная страница из индекса, что приведет минимум к недельной потери SEO трафика.
Вероятности неправильно посчитаны. Вероятность отказа для 99.5% аптайма - 0.005. Вероятность захода бота на главную страницу при периодичности раз в неделю и 10 секунд на выполнение запроса - 0.0000165. Вероятность одновременного происхождения обоих событий равна произведению - 0.0000000825. И вот теперь умножаем это на 52 и получаем 0.00000429 (0.000429%) - это вероятность выпадения страницы из индекса в течение года.
Вероятности неправильно посчитаны. Вероятность отказа для 99.5% аптайма - 0.005. Вероятность захода бота на главную страницу при периодичности раз в неделю и 10 секунд на выполнение запроса - 0.0000165. Вероятность одновременного происхождения обоих событий равна произведению - 0.0000000825. И вот теперь умножаем это на 52 и получаем 0.00000429 (0.000429%) - это вероятность выпадения страницы из индекса в течение года.
Нет, вероятности у ТС посчитаны правильно.
Второй вариант подсчета (не точный, но при высоком аптайме катит) :
при обращении к сайту вероятность получить ошибку 0,5%
обращений за год 52.
умножаем 0,5% на 52 = 26%
Это Вероятность того, что в течение года поисковый бот _хоть раз_ получит ошибку.
ТС посчитал более точным способом, но он с непривычки не всем понятен.
Смысла сооружать такое, если у вас не амазон или ебай нету... Вы прикиньте сколько это вам будет стоить и прибавьте сюда стоимость поддержки и постоянного мониторинга этой системы...
Сюда давайте добавим возможные проблемы с каналом и электричеством если все делать в одном дц...
Можно конечно сделать все бюджетно на базе 1 сервера в двумя бп и т.д. , разбив на виртуалки.
Нет, вероятности у ТС посчитаны правильно.
Второй вариант подсчета (не точный, но при высоком аптайме катит) :
при обращении к сайту вероятность получить ошибку 0,5%
обращений за год 52.
умножаем 0,5% на 52 = 26%
Это Вероятность того, что в течение года поисковый бот _хоть раз_ получит ошибку.
ТС посчитал более точным способом, но он с непривычки не всем понятен.
Хорошо, что люди, привычные к такому способу занимаются безобидным хостингом, а не строительством :)
Вы упустили, что падение сайта и обращение к сайту - независимые случайные величины. Их совместная вероятность - произведение.
Простая иллюстрация вашей ошибки - обратитесь к сайту 52 раза не за год, а за минуту. Вы уверены, что с вероятностью 26% получите отказ?
Вы упустили, что падение сайта и обращение к сайту - независимые случайные величины. Их совместная вероятность - произведение.
Простая иллюстрация вашей ошибки - обратитесь к сайту 52 раза не за год, а за минуту. Вы уверены, что с вероятностью 26% получите отказ?
Может быть события, а не величины? :)
Дано - вероятность успешно открыть сайт = 99,5%
требуется посчитать - с какой вероятностью удасться открыть сайт успешно 52 раза подряд.
Вероятность сегодня и через неделю ну точно одинаковые, и события эти не связанные.
То что мои подсчеты не верные (но с приемлемой погрешностью) я в курсе.
---------- Добавлено 14.06.2012 в 20:51 ----------
yesRuslik, огромное спасибо, что прямо по полочкам описали варианты.
Как быстро в данном случае для клиентов будет доступен сайт?
Можете посоветовать какие-нибудь сервисы?
То есть нужно в одном ДЦ имееть 2 сервера, которые будут на одном IP?
Сейчас именно так всё и устроено. Фронтенд иногда падает. Первая мысль была сделать 2 фронтенда, чтобы минимально менять всю систему.
При 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'у.
При DNS+failover время переключения равно TTL + инертность самого фейловер-механизма.
В цифрах можно добиться от 30 до 60 секунд.
Что такое TTL? Это http://ru.wikipedia.org/wiki/Time_to_live? Из википедии:
Для DNS-записей параметр «Time to live» определяет время актуальности данных при кешировании запросов. Задаётся в секундах, типичное значение составляет 86 400 секунд, т.е. 24 часа. Это означает, что при изменении записи DNS, вплоть до 24 часов после изменения DNS-серверы по всему миру могут выдавать старые данные из кеша, пока он не будет обновлён.
Про какое кеширование здесь идёт речь?
То есть как получается время меньше минуты?
Я так понимаю это процесс, поправьте, пожалуйста, если заблуждаюсь:
Пользователь набирает домен в браузере, его провайдер берёт и смотрим в кеш и отправляет пользователя по 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 будет опрашивать другой до получения ответа.
Что касается вероятностей, то что бы вы там не насчитали, я тоже убежден что вам проще будет найти просто хороший хостинг.
По идеи прокси VPS(фронтенды) потребляют мало ресурсов(
для таких умников облачные сервисы тарифицируют трафик.
Добрый день. Никак не могу разобраться что же нам нужно, поэтому решил прибегнуть к помощи всесильных гуру данного раздела :) Заранее спасибо всем, кто не останется безразличным :)
Задача: сделать максимально отказоустойчивую систему для сайта.
Трудности: сайты посещают клиенты и одновременно работают менеджеры, которые вносят изменения в БД и файлы.
Варианты:
1) Два сервера
а) Берём отказоустойчивые DNS, например, zoneedit.com или DNS хостинг Яндекса. Прописываем там IP наших серверов.
б) Делаем на каждом сервере свои DNS.
Правильно ли я понимаю, что и в пункте а) и в пункте б) при падении одного из серверов мы всё равно будем терять 50% клиентов, т.к у них будет открываться упавший сервер.
И смена NS домена(чтобы отключить неработающий сервер) происходит очень медленно(до 48 часов)+провайдеры кешируют до недели?
Можно ли как-то настроить онлайн синхронизацию между файлами и БД двух серверов?
2) Облака
Я правильно понимаю, что облака используются только если проекту нужна масштабируемость в ресурсах и к надёжности это не имеет отношение, т.к фактически всё находится на одном очень мощном сервере с котором могут случиться проблемы?
3) Кластерный хостинг
Вроде всё как нужно, один сайт сразу находится на нескольких серверах и всё дублируется автоматически. Какие подводные камни? Какие можете посоветовать?
P.S. Нагрузка небольшая, на сайт может хватить и среднего-хорошего VPS.
Берете - ВПС и нормальную контору каждый впс желательно на платформе ксен и у адекватного хостера ☝ с 24 / 7 суппортом - это обязательно !
Админы вам настраивает зеркало скажем с синхронизацией раз в час или день, или 30 минут как захотите ;) Что-то случается - переключаете на другой впс и все днсы переключит админ на хостинге либо сами. Да должен быть мониторинг впса , можно с смсками на ваш телефон если что-то случается.
Цена вопроса два впса по $20-$30 все.
По аптайму: США у нас по 5-6 лет в коннекте есть сервера - но это как повезет (+пинг оттуда дольше), Британия там за год всреднем минут 15 траблов пару раз такое было, Германия ну когда как, но тоже не долго макс 1-2 часа траблы с каналами были ...Украина - Россия ну там тоже можно один держать или резервный ;) там сумарно 99.5 % У нас за год аптайм....
Есть вариант еще всетаки сделать бекап вообще вдругой конторе - вдруг хостера убьют либо компанию закроют, либо любой другой форс мажер, но вероятность такого меньше 0,01% :)
Я по своим проектам так делал и все всегда 100% работало - по облакам там траблов не мало - они не выручат ....