Я создаю веб-приложение, в котором время безотказной работы является ключевым фактором. Я понимаю, что 100% безотказная работа - это нереально, но я бы хотел достичь пяти девяток. Я не уверен, как лучше всего это сделать.
Мой предварительный план заключался в том, чтобы веб-приложение работало в двух географически разделенных центрах обработки данных. «Главный» центр обработки данных будет содержать главный сервер, и он будет реплицироваться на неиспользуемый «подчиненный» сервер в другом месте. Если в главном центре обработки данных произойдет простой, аварийное переключение DNS переместит трафик на «подчиненный» сервер. При использовании этого метода возникают проблемы, в том числе некоторые пользователи не могут получить доступ к сайту на некоторое время из-за нечетного кэширования записей DNS и т.
Тем не менее, я прочитал много мнений о том, что отказоустойчивость DNS - не лучшее решение и что вы должны хранить все в одном центре обработки данных и сосредоточиться на резервировании там. Проблема, которую я вижу в этом, заключается в том, что даже у хороших центров обработки данных, похоже, есть странная проблема с сетью, которая может вызвать достаточно простоев, чтобы разбить ожидание в пять девяток.
Стоит ли мне использовать вариант аварийного переключения DNS? Есть варианты получше?
Мое практическое правило для клиентов: две девятки вы получаете бесплатно (т. Е. Ничего не тратите специально на высокую доступность). Каждые дополнительные девять увеличивают общую стоимость на порядок.
То есть вы можете иметь 99% времени безотказной работы, просто поместив свое приложение на полуприличный сервер в корпоративном интернет-соединении. Чтобы улучшить это, вы можете разместить в одном месте. Вы можете совместить работу с балансировкой нагрузки и быстрым отказом. Вы можете разместить в одном месте балансировку нагрузки, быстрое переключение при отказе и сайт аварийного восстановления с холодным резервом. Вы можете размещаться вместе с балансировкой нагрузки, сайтом горячего резервирования, адресным пространством PI, запускать собственный ASN и иметь пиринговые механизмы BGP, чтобы гарантировать, что ваше адресное пространство всегда имеет глобальную маршрутизацию. Вы можете исследовать оборудование с высокой доступностью, где все, включая память и процессоры, можно приостановить и заменить в горячем режиме. Если ваше приложение поддерживает это, вы можете запустить полностью распределенный хостинг или использовать аутсорсинг в сетях предоставления контента с высокой доступностью. Вам может и понадобится в пять раз больше сотрудников для управления всем этим 24 * 365, включая отпуск и страхование по болезни, а также частые живые тесты DR, которые вам нужно будет делать, чтобы быть уверенным во всем этом.
Вы можете делать много умных вещей. Но все это стоит, и большая часть этого стоит очень большая сумма денег.
Итак, мой искренний совет: определите, во сколько вам будет стоить размещение вашего приложения на одном сервере в корпоративном офисе. Если ваш работодатель не готов тратить в тысячу раз больше, забудьте пять девяток; это нереально.
Если бы пять девяток было легко, Twitter, Facebook, Gmail, Azure и Amazon, вероятно, уже были бы там. У них определенно есть деньги и самые веские бизнес-кейсы для этого. Вместо этого я бы порекомендовал вам выбрать хостинг у облачного провайдера, у которого есть опыт в предоставлении надежной инфраструктуры, чтобы они могли беспокоиться об этом, пока вы разрабатываете свой продукт.
За пять девяток вы ожидаете гораздо большего участия, чем просто одно решение аварийного переключения. Вам нужна высокая доступность в одном центре обработки данных плюс центр обработки данных с горячим (или, по крайней мере, теплым) резервом, который географически далеко, но топологически находится рядом с вашим основным центром обработки данных. И это только начало ...
Я полагаю, что здесь есть что-то вроде босса, который хочет-совместим с PowerPoint, но получить пять девяток или действительно близко к нему возможно - хотя вы должны быть осторожны с определением того, что именно нужно, чтобы получить пять девяток время безотказной работы.
Я пишу приложение, которое собирает данные с устройств IoT (также совместимых с boss / powerpoint) и представляет собранные данные конечным пользователям, выполняет интеллектуальный анализ данных и т. Д. С использованием MongoDB и т. Д.
На данный момент у нас фактически ожидаемое время безотказной работы не менее 99,9. Как? Что ж, наше время безотказной работы определяется как доступность пользовательского клиентского приложения. Эта часть выполняется в GAE, в то время как другие части (например, MongoDB) запускаются на наших собственных серверах. Связь осуществляется через REST и много криптографии. На данный момент время безотказной работы GAE составляет 99,45%, но на самом деле для тех частей, которые мы используем, оно выше - мы еще не зарегистрировали никаких сбоев.
С другой стороны, MongoDB временами немного нестабильна - не сильно - но получение 98-99% времени безотказной работы - лучшее, что мы можем сделать прямо сейчас. В дополнение к MongoDB у нас есть движок, который генерирует JSONified блоки данных - они генерируются по запросу, но также периодически. Их кэширование весьма полезно для поддержания предполагаемого времени безотказной работы всей системы. Конечные пользователи не знают, доставило ли какое-то устройство данные на серверную часть только сейчас или час назад. Таким образом, кэшированные данные кажутся такими же свежими, как и «настоящие» свежие данные.
Таким образом, получение действительно высокого времени безотказной работы, безусловно, возможно, если вы умеете изолировать те биты, которые действительно должны иметь высокое время безотказной работы. Как отмечали другие, довести весь стек до пяти девяток безотказной работы - ТРУДНО и действительно дорого. Но вы, вероятно, сможете обойтись меньшими затратами и при этом порадовать своего начальника.