Отраслевой стандарт избыточности довольно высок, если не сказать больше. Чтобы проиллюстрировать мою точку зрения, вот моя текущая установка (у меня финансовая служба).
На каждом сервере есть RAID-массив на случай, если что-то пойдет не так на одном жестком диске
.... и в случае, если что-то пойдет не так на сервере, он будет зеркалирован другим запасным идентичным сервером
... и оба сервера не могут выйти из строя одновременно, потому что у меня резервное питание, резервное сетевое подключение и т. д.
... и сам мой хостинговый центр имеет двойное подключение к электричеству с двумя разными поставщиками энергии, а также резервное сетевое подключение и резервные туалеты на случай, если два охранника (извините, четыре) должны использовать его одновременно
... и на случай, если что-то пойдет не так (ядерная бомба? Не могу придумать ничего другого), у меня есть другой идентичный хостинг-объект в другой стране с точно такой же настройкой.
Другими словами, я чувствую, что мог бы разместить дешевый ноутбук в квартире моей матери, и человеческие / программные проблемы все равно были бы для меня более высоким риском.
Конечно, есть и другие вещи, которые следует учитывать, например:
Но, тем не менее, размещение двух серверов в двух разных центрах обработки данных (без дополнительных резервных серверов или удвоенного сетевого оборудования, кроме того, которое предоставляется моим хостинговым объектом), предоставит мне необходимую масштабируемость и физическую безопасность.
Я чувствую, что мы приближаемся к точке, где избыточность - просто инструмент связи. Честно говоря, в чем разница между временем безотказной работы 99,999% и временем безотказной работы 99,9999%, если вы знаете, что в 1% случаев вы будете отключаться из-за ошибок программного обеспечения?
Как далеко вы продвигаетесь ваш безумие избыточности?
Когда стоимость избыточности выше, чем стоимость простоя, в то время как то, что когда-либо сломалось, заменяется, это слишком много избыточности.
Все дело в управлении рисками. Даже если в 2 раза больше всего, вы все равно можете получить простои из-за непредвиденных проблем.
например. У моего хостинг-провайдера есть двойные резервные подключения к восходящему Интернету. Итак, в тот день, когда один из их кабелей был перерезан некоторыми строительными подрядчиками, их поставщик услуг по добыче нефти отключил другой для некоторого обслуживания. И не только это, поскольку все телефоны были SIP, никто не мог позвонить, чтобы сказать, что нет подключения, и они не осознавали, что проблема существует целую вечность.
Это был один из миллионов взломов, и его можно было предотвратить, добавив больше уровней избыточности или надзора со стороны руководства ... но вероятность того, что это произойдет, была настолько мала, что вы никогда не подумали бы, что это произойдет. будет проблемой, поэтому не стоит тратить деньги на предотвращение этого.
Другой пример: мы реализовали зеркалирование SQL Server в диспетчерской скорой помощи 999, зеркалирование БД должно было означать, что проблем не будет .. за исключением того, что мы обнаружили ошибку в SQLServer, которая замораживала основную БД и не позволяла ей переключиться на зеркало. Итак, хотя мы сделали все возможное, чтобы обеспечить непрерывную работу, нам все равно пришлось перейти на ручной вызов, пока проблема с БД была решена. В этом случае у нас было лучшее решение, которое мы могли разумно реализовать, и запасной план на случай, если это «лучшее решение» не удастся. Попытка обеспечить полную 100% -ную гарантию безотказной работы для «лучшего решения» просто не была бы рентабельной и, вероятно, все равно не дала бы нам эту 100% -ную гарантию.
Опять же, другая история: у нас есть общеевропейская сеть реплицированных серверов Active Directory с запасным ходом в случае сбоя в любой стране. Поэтому, когда некий администратор случайно удалил слишком много записей, решение заключалось в том, чтобы остановить сервер и позволить людям пройти аутентификацию в другой стране. Только репликация попала туда первой, и удаленные записи начали удаляться и с других серверов ... потребовалась неделя, с помощью экспертов Microsoft, чтобы полностью решить проблему.
Итак - все сводится к риску / стоимости. Вы сами решаете, на какой риск готовы пойти и сколько это стоит. Это быстро доходит до того, что дальнейшее снижение риска слишком дорого обходится, и на этом этапе вы должны найти альтернативные стратегии, чтобы справиться с простоями. когда такое случается.
Вы делаете то, что делаю я - я вовсе не считаю это безумием.
... и на случай, если что-то пойдет не так (ядерная бомба? Не могу придумать ничего другого), у меня есть другой идентичный хостинг-объект в другой стране с точно такой же настройкой.
Как отметили другие: это просто бизнес-кейс. Требуемый уровень избыточности напрямую зависит от требований и ожиданий ваших клиентов / пользователей. Если они платят и ожидают время безотказной работы в районе пяти девяток, вам необходимо это предоставить. Если нет, то вам следует рассматривать это как бизнес-стратегию.
Однако если я попытаюсь предположить вероятность другой проблемы (программной или человеческой), я думаю, что она на несколько порядков выше этой.
Простой ответ: это нужно решать с помощью процедуры. Не за счет физической избыточности.
Если человеческая ошибка вызывает у вас простои, вам необходимо усилить проверку ошибок, выполняемую всякий раз, когда вмешиваются люди. Это, вероятно, означает, что все поправки к платформе оформляются как запросы на изменение и подписываются второстепенным лицом. Или что эти запросы на изменение содержат более подробную информацию о задачах, которые необходимо выполнить, и что нельзя отклоняться. Или что персоналу просто необходимо дополнительное обучение тому, как осторожно работать в производственной среде.
Если программная ошибка вызывает у вас простои, возможно, вам нужно усилить процедуру постановки. Убедитесь, что у вас есть хорошая промежуточная среда, которая вполне может быть полностью виртуализирована для снижения требований к оборудованию, но при этом максимально соответствует вашим производственным средам. Любые изменения программного обеспечения должны быть протестированы в промежуточной среде в течение определенного периода времени, прежде чем они будут развернуты для общего развертывания.
Каждый дизайн и архитектура должны основываться на требованиях. Хорошая системная инженерия требует определения ограничений проекта и реализации решения, которое им соответствует. Если у вас есть соглашение об уровне обслуживания с вашими клиентами, которое требует .99999, то ваше решение с избыточностью N + N должно учитывать все те LRU (заменяемые линии), которые могут выйти из строя. Это следует учитывать при планировании RAID, PS и COOP. Кроме того, ваше соглашение об уровне обслуживания с поставщиками должно предусматривать 4-часовое время ответа или предусматривать большое количество запасных частей на месте.
Доступность (отсюда и далее) - это исследование. Если вы делаете все это, потому что это кажется правильным, то вы зря тратите свое время и деньги своих клиентов. При нажатии все захотят 5x9, но немногие могут себе это позволить. Честно обсудите доступность данных и системы с точки зрения затрат.
Вопросы и ответы, заданные до сих пор, не учитывают требования. Цепочка предполагает, что ключевым является резервирование N + N с оборудованием и политиками. Скорее, я бы сказал, позвольте требованиям ваших клиентов и SLA управлять дизайном. Может, квартиры твоей мамы и старого ноутбука хватит.
Мы, гики, иногда ищем проблему, чтобы мы могли реализовать классное решение.
Сколько стоит ваша репутация? в случае сбоя программного обеспечения вы сделали все возможное, чтобы защитить данные своих клиентов, обеспечивая наилучшее резервирование оборудования / кластера. Если вы достигли своего наилучшего результата, то пора выделить больше средств на управление изменениями / качеством.
Если у вас есть соответствующий бюджет и ваш хостинг важен для вас (как это было бы для финансового учреждения), продолжайте. Я заметил, что вы не говорите о своих резервных копиях ... может быть, там можно что-то улучшить? Я никогда не видел настройки, которая была бы настолько крутой, что я чувствовал, что она не требует дополнительной работы (иногда это просто процедуры исправления).
Я бы сделал расчет с входами:
Затем вы можете рассчитать финансовый риск:
потенциально_outage_cost = час_отход_затрат * время_восстановления * вероятность_отключения
Затем просто взвесьте стоимость избыточности с этой стоимостью.
Надеюсь, мне не нужно напоминать вам, что есть несколько типов отключений, например:
отказавший диск (очень вероятно, очень фатально, но избыточность стоит недорого)
сбой питания
отказавший сервер
сбой сетевого подключения
сбой восходящего канала ...
В любом случае сначала проведите анализ рисков, поскольку он дает вам базовые показатели.
... и на случай, если что-то все равно пойдет не так (ядерная бомба? Не могу придумать ничего другого),
Пожар в центре обработки данных может его отключить (разве это не случилось с одним общим DC в прошлом году?), Однако внутри центра существует большая избыточность.
Два DC могут помочь, но даже здесь одиночные события могут вывести их из строя. Например, в США, союзнике торнадо, два DC, достаточно близко расположенные для темного волокна, могут быть легко поражены торнадо из одной и той же суперсистемы. Этот риск можно уменьшить путем тщательного относительного географического позиционирования (начните с проверки исторических траекторий штормов), но не полностью.
У меня есть еще один идентичный хостинг в другой стране с точно такой же настройкой.
И, как говорили другие, все дело в стоимости простоя по сравнению со стоимостью избыточности, и многие из затрат на отключение являются нематериальными (потеря доверия клиентов).
Просто радуйтесь, что у вас есть бюджет, чтобы все делать правильно.
В то же время ваши действия по обновлению программного обеспечения, вероятно, сейчас потребуют некоторой работы.
Вы правы насчет "аппаратной" части настройки. Предоставление высокой доступности с помощью геоизбыточности сделает очень маловероятным, что ваши службы будут отключены из-за неисправного оборудования.
Другими словами, я чувствую, что мог бы разместить дешевый ноутбук в квартире моей матери, и человеческие / программные проблемы все равно были бы для меня более высоким риском.
Я полностью не согласен. Вы упускаете важный момент - тестирование и управление выпусками. Также существуют стратегии, которые гарантируют, что программное обеспечение никогда не подведет ваши услуги для всех клиентов.
Некоторые компании заходят так далеко, что используют не только веб-серверы одного бренда только потому, что опасаются, что ошибка в Apache может быть вызвана сразу повсюду, поэтому они развертывают несколько веб-серверов.
Что касается тестирования: должен быть определенный уровень доверия, даже с системой с полным доступом ко всем источникам у вас не может быть ресурсов для тестирования всего (или, если тестирования будет недостаточно - формально докажите правильность).
Дело в том, что у вас должны быть тесты перед ваше программное обеспечение запускается в производство. Это что-то вроде:
Что касается управления выпусками: если вы не хотите, чтобы неизвестная ошибка в новом выпуске вызвала простои: просто не выпускайте новую версию везде. Предоставьте новый выпуск только небольшой части клиентов. Если все получится, перенесите еще несколько клиентов (что-то вроде 5%, 20%, 50%, 100%). Обратите внимание, что здесь может быть такой цикл прокатки:
Таким образом, у вас не будет огромных промежутков времени между циклами выпуска, если ваше определение - позволить ему работать в течение 2 недель в каждом пакете развертывания.
Я обнаружил, что проблема не в создании такой системы, а в продаже ее руководству. Поскольку это будет стоить много времени и денег (по крайней мере, при запуске), когда процесс будет установлен, я считаю, что это еще дешевле. Наличие скользящих выпусков также является прекрасным запасным вариантом, поскольку программное обеспечение (скажем, версия 5 из последнего примера полностью сломан) просто должен быть механизм для работы со старыми и новыми данными, что опять же означает:
Насколько далеко вы зашли в своем безумии с избыточностью?
Насколько руководство готово платить, если оно того стоит, и считает, что риск простоя обходится гораздо дороже, чем стоимость (некоторого случайного уровня) высокой доступности.