Горячий запасной хост против холодного запасного хоста?

У нас есть несколько хостов, на которых у нас есть идентичный хост горячего резервирования, который исправлен и обновлен, поэтому он очень близок к тому же программному обеспечению и конфигурации. В случае сбоя сетевой кабель переключается, а DHCP-сервер обновляется новым MAC-адресом. Это лучший случай, так как обычно требуется немного больше для модификации.

Я чувствую, что иметь горячий резервный компьютер и тратить время на его обслуживание - это пустая трата электроэнергии, и, поскольку в случае сбоя необходимы изменения конфигурации, я хотел бы спросить следующее:

Являются ли горячие резервные хозяева старой школы и есть ли лучшие способы сейчас?

Вместо того, чтобы иметь хост с горячим резервом, имеет ли смысл сделать его холодным резервом, взять жесткие диски и поместить их в основной хост и изменить RAID с 1 на 1 + 1. В случае отказа все, что мне нужно сделать, это заменить сетевые кабели, обновить DHCP-сервер, взять жесткие диски и вставить их в холодный резерв и включить питание. На мой взгляд, преимущество заключается в том, что диски 2x2 всегда синхронизированы, поэтому для обслуживания требуется только один хост, и при сбое не требуется никаких изменений конфигурации.

Это хорошая идея?

Sobrique объясняет, как ручное вмешательство делает предлагаемое решение оптимальным , и рассказывает о вероятности отказа различных компонентов . Обе эти ИМО делают очень хорошие замечания и должны быть решительно рассмотрены.

Однако есть одна проблема, которую пока никто не комментирует, что меня немного удивляет. Вы предлагаете:

сделайте [текущий хост горячего резервирования] холодным резервом, возьмите жесткие диски и поместите их в основной хост и измените RAID с 1 на 1 + 1.

Это не защитит вас от действий ОС на диске.

Он только защищает вас от сбоя диска, который, перемещаясь с зеркал (RAID 1) на зеркала зеркал (RAID 1 + 1), вы значительно уменьшите влияние с самого начала. Вы можете получить тот же результат, увеличив число дисков в каждом наборе зеркал (например, перейдите с 2-дискового RAID 1 на 4-дисковый RAID 1), а также вполне вероятно, улучшив производительность чтения во время обычных операций.

Хорошо, тогда давайте посмотрим на некоторые способы, которыми это может потерпеть неудачу .

• Допустим, вы устанавливаете обновления системы, и что-то вызывает сбой процесса на полпути; возможно, произошел сбой питания и ИБП , или, может быть, вы попали в странную аварию и столкнулись с серьезной ошибкой в ​​ядре (в наши дни Linux довольно надежен, но риск все же есть).
• Возможно, при обновлении возникает проблема, которую вы не уловили во время тестирования (вы делаете тестовые обновления системы, верно?), Требующий аварийного переключения на вторичную систему, пока вы исправляете первичную
• Возможно, ошибка в коде файловой системы приводит к ложной, неправильной записи на диск.
• Может быть, толстый (или даже злой) администратор делает rm -rf ../*или rm -rf /*вместо rm -rf ./*.
• Возможно, ошибка в вашем собственном программном обеспечении приводит к серьезному повреждению содержимого базы данных.
• Может быть, вирус удается проникнуть внутрь.

Может быть, может быть, возможно ... (и я уверен, что есть много других способов, с помощью которых ваш предложенный подход может потерпеть неудачу.) Однако, в конце концов, это сводится к тому, что "два набора всегда синхронизированы", "преимущество" Иногда вы не хотите, чтобы они были идеально синхронизированы.

В зависимости от того, что именно произошло, именно тогда вам понадобится либо горячий или холодный резерв, готовый для включения и переключения, либо правильное резервное копирование. В любом случае зеркала RAID зеркал (или зеркала RAID) не помогут вам, если режим сбоя включает в себя многое, кроме отказа аппаратного запоминающего устройства (сбой диска). Что-то вроде raidzN в ZFS, вероятно, может быть немного лучше в некоторых отношениях, но совсем не лучше в других.

Для меня это сделало бы ваш предложенный подход безпроблемным с самого начала, если целью является какое-либо аварийное аварийное переключение.

Да, это немного старая школа. Современное оборудование не просто так часто выходит из строя . Сосредоточьтесь либо на том, чтобы сделать ваши приложения более доступными (не всегда возможно), либо на элементах, необходимых для повышения устойчивости ваших отдельных хостов ...

Для хостов:

• Купите лучшее оборудование.
• Убедитесь, что у вас есть контракты на поддержку.
• РЕГИСТРАЦИЯ контрактов поддержки вашего сервера (запасные части хранятся локально на основе регистрационных данных!)
• Используйте резервные источники питания, (аппаратный?) RAID, резервные вентиляторы.
• Если сервер не способен вместить вышеупомянутые избыточные функции, держите под рукой запасное шасси или компоненты, чтобы иметь возможность самостоятельного ремонта в случае сбоя.

В порядке уменьшения частоты отказов я вижу: диски, оперативную память, блоки питания, вентиляторы чаще всего ... Иногда системная плата или процессор. Но последние два - то, где ваш контракт поддержки должен вступить в силу.

Это довольно неэффективно - не в последнюю очередь из-за зависимости от ручного вмешательства для переключения.

Я работал в местах, где работает горячий сайт DR - буквально, серверы, идентичные основным, готовые к работе немедленно. Однако переключение DR является автоматизированным процессом - мы не говорим о кабельной разводке, небольшом беспокойстве и переключении, а о процессе, когда мы нажимаем кнопку, переворачивая все с одного сайта на другой.

Этот подход отвратительно дорог, но это бизнес-решение - приемлемый риск в сравнении с деньгами, необходимыми для достижения цели. Как правило, существует экспоненциальная кривая для целевого времени восстановления - чем ближе к нулю, тем больше он стоит.

Но это то, что ваш вопрос, на самом деле. Что является вашей целью времени восстановления, а также то , что является наиболее эффективным способом достижения. Ожидание загрузки сервера займет несколько минут. Сколько времени нужно, чтобы кто-то выполнил настройку и «восстановление», когда он появляется в 4 часа утра?

И как долго это допустимое отключение?

Я хотел бы предложить, что если вы делаете «горячее восстановление», вы хотите думать о кластеризации. Вы можете быть довольно дешевы при кластеризации с хорошим использованием VMWare - «переключение на виртуальную машину» - даже с физической - означает, что вы не используете избыточное оборудование. (Ну, N + 1, а не 2N).

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

Тот факт, что это старая школа, не обязательно делает использование горячего резерва плохой идеей.

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

Запуск «горячего» резервирования с несколькими этапами ручного переключения при отказе займет много времени и, скорее всего, пойдет не так, но мне также кажется, что автоматическое переключение при сбое, когда наборы кластеров HA превращаются в основные кластерные узлы.

Другое дело, что горячее или холодное резервирование в одном и том же месте не обеспечивает непрерывности бизнеса в случае локального бедствия.

Концепция наличия горячего или даже холодного резерва зависит от того, как в первую очередь создаются приложения.

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

Например, стандартное веб-приложение обычно требует веб-сервера и сервера базы данных. Для веб-серверов просто загрузите баланс 2 или больше. Если кто-то умирает, не важно. База данных, как правило, более сложная, так как она должна быть спроектирована так, чтобы она была мультимастерной со всеми данными, синхронизированными на участвующих машинах. Таким образом, вместо одного сервера БД вы получаете 2 (или более), которые обслуживают ваши потребности в данных. Крупные поставщики услуг, такие как Google, Amazon, Facebook и т. Д., Пошли по этому пути. Время разработки выше, но оно платит дивиденды, если вам нужно масштабироваться.

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