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

1) Все не так.

2) Нет, неправильно - облако или лучше сказать отказоустойчивый и масштабируемый в реальном масштабе кластер и он состоит далеко не из одного сервера.

3) Вот это и есть то, что вам нужно :)

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

:) Не могли бы Вы объяснить подробней.

Я правильно Вас понял, что есть возможность не терять 50% клиентов в каком-то из случаев при использовании основного и дублирующего серверов?

Можете посоветовать какие-нибудь компании?

http://freehost.com.ua/cluster/index/

Когда-то пользовался их шаредом - работало стабильно. Сервера в их собственном ДЦ, в Киеве вроде

Не могли бы Вы объяснить подробней.

Я правильно Вас понял, что есть возможность не терять 50% клиентов в каком-то из случаев при использовании основного и дублирующего серверов?

Можно вообше никого не терять если у вас отказоустойчивый кластер.

Можете посоветовать какие-нибудь компании?

Любая компания которая возьмется сделать вам кластер. Для этого, помимо желания, необходиы технические возможности. Например, в hetzner.de есть возможность использовать так называемый faileover ip - на этот ай-пи адрес будут направлены А записи вашего домена. Если один сервер упадет, то резервный поднимется. И все это без смены ай-пи адреса. Поэтому и называется эта опция failover ip address. Ну а синхронизация данных между мастер и слейв сервером дело решаемое.

Вы изначально не идеально точно понимаете суть вашей задачи.

На самом деле суть - минимизировать убытки от простоя сервиса _в сумме с расходами на поддержку сервиса_.

Вот теперь давайте думать:

Добротный опытный хостинг дает достаточно высокий аптайм.

к примеру у меня 99,87% с Нового Года.

Теперь считаем - сколько это, 0,13% в месяц.

А получается это 56 минут. Не все из которых приходятся на рабочее время, большАя часть простоев все таки служебные и происходят после 22:00.

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

И какова будет скорость реакции ваших систем в случае аварии. Если ошибка возникла на 1 минуту, а ваша система перестраивается за... тоже минуту - толку в этом мало.

Начать решать задачу надо с ее постановки IMHO. Если простой проекта обходится дороже в финансовом или имиджевом плане, тогда стоит заняться отказоутойчивостью.

Есть разные уровни, на которых можно организовать отказоустойчивость. Самые популярные - это failover на базе DNS(когда внешний сервис определяет доступность сервера и меняет А-запись в случае падения на резервный),а также HA-кластер, когда переключение происходит не с помощью DNS, а через специализированное ПО типа heartbeat или peacemaker(мы переключали мигрирующий образ виртуальной машины на живую аппаратную ноду). Еще одним вариантом может быть простое проксирование запросов на уровне http-протокола на разные бекенды, но тут сложно говорить о HA(high availability), если упадет фронтенд.

Если данных много или сложная настройка каждой ноды - выход виртуальная мигрирующая машина. В других случаях можно делать комбинации. Если данных мало и изменения не очень частые - то в целом DNS+failover вполне справится с задачей.

ТС, я предлагал вот такую схему определенное время назад (/ru/forum/comment/7069575), она конечно не на 100% отвечает вашей задаче, но это яркий пример построения "фермы" в одном физическом месте, для получения отказоустойчивости. Именно данное предложение служит для раздачи картинок или любого другого статического контента который можно легко кешировать. В приведенной схеме отказоустойчивость на столько велика, что при проводимых тестах, я выключал ВСЕ бекенд сервера содержащие контент и не получил при этом ни одного сообщения от клиентов, что пропали картинки с сайтов, так как они все находились в кеше (нуу скажем так почти все.... самые актуальные и недавно запрошенные). Адаптация такой фермы под веб сайт так же возможна, возможно даже распределение запросов в базу данных и сами веб сервера. Для плотного внедрения продукта на такую платформу понадобиться несколько трикшотов из серии "синхронизации PHP сессий" да и вообще синхронизации всего того, что несет в себе одна нода на все остальные, но это отдельные участки кода которые могут быть выражены в виде доп. функций или даже модулей к движкам и.т.п

Есть определенный опыт работы с такими "фермами", если есть какие-то конкретные вопросы буду рад подсказать.

Совершенно правильно, спасибо за исправление, это я и имел ввиду.

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

Реальность не 99,87%, а 99,5%(и это неплохо) на более длинном промежутке времени.

Давайте прикинем убытки от простоя:

1) Клиенты не звонят в первый раз.

2) Клиенты, которые были в процессе выбора и общения с менеджерами, отваливаются.(не могут ничего посмотреть на сайте)

3) Менеджеры не могут пользоваться сайтом и вести клиентов.(не могут без сайта подбирать "товар").

4) Головная боль и суета вокруг серверов и тд

5) Выпад страниц из индекса и потеря SEO трафика.

Вероятность, что поисковый бот зайдет на сайт в момент его недоступности

99,5%. Если на главную страницу бот заходит раз в неделю, а в году 52 недели, то

99,5^52 = 0,77, следовательно с вероятностью 23% за год у Вас должна вылететь главная страница из индекса, что приведет минимум к недельной потери SEO трафика.

Вообще статистика довольна обманчива, всё зависит не только от uptime, но и характере простоя. Например, если каждые 30 мин в рабочее время сервер отрубается на 18 секунд(uptime 99,5%), то звонков от клиентов будет в 3 раза меньше, т.к реальные клиенты сначала довольно долго ищут на сайте сами и если сайт не доступен 18 секунд, то они просто с него уходят.

---------- Добавлено 14.06.2012 в 20:51 ----------

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

Как быстро в данном случае для клиентов будет доступен сайт?

Можете посоветовать какие-нибудь сервисы?

То есть нужно в одном ДЦ имееть 2 сервера, которые будут на одном IP?

Сейчас именно так всё и устроено. Фронтенд иногда падает. Первая мысль была сделать 2 фронтенда, чтобы минимально менять всю систему.

Разумеется "у кого как". У меня за прошлый год 99,74%. За 10 лет как то не считал :).

Это ваша забота - экспертно посчитать убытки от простоя в $$/час.

А уже из этой цифры вытекает сколько денег есть резон тратить на систему, и сколько девяток после запятой стоит достигать. 99,9 или 99,999

Пичаль.... А где тут убытки?

$$ ?

Могут выйти на связь с клиентом и через 30 минут. 90% клиентов к этому отнесется нормально.

Это вроде как не ваша головная боль, а провайдера?

Во первых при первой недоступности страницы не выпадают, иначе при каждом ребуте сервиса

был бы риск обвалить клиентов.

Бот обязательно придет чуть позже, даже если не получит корректного "revisit after".

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