У нас есть несколько хостов, на которых у нас есть идентичный хост горячего резерва, который исправлен и обновлен, поэтому он очень близок к тому же программному обеспечению и конфигурации. В случае отказа сетевой кабель переключается, и сервер DHCP обновляется новым MAC-адресом. Это лучший случай, поскольку обычно требуется немного больше.
Я считаю, что иметь хост с горячим резервом - пустая трата электроэнергии и трата времени на его обслуживание, а поскольку в случае аварийного переключения требуются модификации конфигурации, я хотел бы спросить следующее:
Являются ли хозяева горячим резервом старой школой, и теперь есть способы лучше?
Имеет ли смысл вместо хоста горячего резерва сделать его холодным, взять жесткие диски и поместить их на основной хост, а также изменить RAID с 1 на 1 + 1. В случае сбоя все, что мне нужно будет сделать, это заменить сетевые кабели, обновить DHCP-сервер, взять жесткие диски и вставить их в холодный резерв и включить питание. Преимущество, на мой взгляд, заключается в том, что диски 2x2 всегда синхронизированы, поэтому при отказе требуется поддерживать только один хост, и никаких изменений конфигурации не требуется.
Это хорошая идея?
Да, это немного старая школа. Современное оборудование не просто потерпеть неудачу так часто. Сосредоточьтесь либо на повышении доступности своих приложений (что не всегда возможно), либо на элементах, необходимых для повышения устойчивости отдельных хостов ...
Для хозяев:
В порядке уменьшения частоты отказов я вижу: чаще всего диски, ОЗУ, блоки питания, вентиляторы ... Иногда системная плата или процессор. Но именно в этих двух последних случаях должен вступить в силу ваш контракт на поддержку.
Это довольно неэффективно - не в последнюю очередь из-за необходимости ручного вмешательства для переключения.
Я работал в местах, где работает сайт горячего аварийного восстановления - буквально, серверы, идентичные первичному, готовые к работе немедленно. Однако переключение DR - это автоматизированный процесс - мы не говорим о кабельной разводке, небольшом возне и переключении, а о процессе, когда мы нажимаем кнопку, и все переводится с одного сайта на другой.
Такой подход до тошноты дорого обходится, но это бизнес-решение - приемлемый риск по сравнению с деньгами, необходимыми для достижения цели. Как правило, существует экспоненциальная кривая целевого времени восстановления - чем ближе оно к нулю, тем больше оно стоит.
Но на самом деле ваш вопрос именно об этом. какой является ваша цель по времени восстановления и каков наиболее эффективный способ ее достижения. Ожидание загрузки сервера займет несколько минут. Сколько времени нужно, чтобы кто-то выполнял настройку и «восстановление», когда в 4 часа утра вспыхивает?
И как долго это приемлемо?
Я бы посоветовал подумать о кластеризации, если вы выполняете «горячее восстановление». Вы можете довольно дешево использовать кластеризацию с хорошим использованием VMWare - «переключение на виртуальную машину» - даже с физической - означает, что вы не используете избыточное оборудование. (Ну, скорее N + 1, чем 2N).
Если ваш RTO достаточно длинный, выключите коробку. Вы можете обнаружить, что RTO достаточно, чтобы можно было выполнить холодное восстановление из резервной копии.
Sobrique объясняет, как ручное вмешательство делает предложенное вами решение оптимальным., и ewwhite говорит о вероятности выхода из строя различных компонентов. Обе эти ИМО содержат очень хорошие моменты, и их следует серьезно рассмотреть.
Однако есть одна проблема, которую, кажется, до сих пор никто не прокомментировал, что меня немного удивляет. Вы предлагаете:
сделайте [текущий хост горячего резерва] холодным, возьмите жесткие диски и поместите их на основной хост и измените RAID с 1 на 1 + 1.
Это не защищает вас от всего, что ОС делает на диске.
Это только действительно защищает вас от сбоя диска, который, переходя с зеркал (RAID 1) на зеркала зеркал (RAID 1 + 1), вы с самого начала значительно уменьшаете влияние. Вы можете получить тот же результат, увеличив количество дисков в каждом наборе зеркал (например, перейдя с 2-дискового RAID 1 на 4-дисковый RAID 1), наряду с весьма вероятным повышением производительности чтения во время обычных операций.
Что ж, давайте посмотрим, как это может потерпеть поражение.
rm -rf ../* или rm -rf /* вместо того rm -rf ./*.Может быть, может быть, может быть ... (и я уверен, что есть еще много способов, которыми предложенный вами подход может потерпеть неудачу.) Однако, в конце концов, это сводится к вашему «преимуществу» «два набора всегда синхронизированы». Иногда вы не хочу их чтобы быть идеально синхронизированным.
В зависимости от того, что именно произошло, именно тогда вам нужно, чтобы был готов к включению и переключению горячий или холодный резерв или надлежащее резервное копирование. В любом случае зеркала зеркал RAID (или зеркала RAID) не помогут вам, если режим сбоя включает в себя многое, кроме сбоя устройства хранения данных (сбой диска). Что-то вроде raidzN ZFS, вероятно, может быть немного лучше в некоторых отношениях, но совсем не лучше в других.
Для меня это сделало бы предложенный вами подход недопустимым с самого начала, если целью является какое-либо аварийное переключение.
Тот факт, что это старая школа, не обязательно означает, что использование горячего резерва - плохая идея.
Ваша главная забота должна заключаться в обосновании, каковы риски, которым вы подвергаетесь, и как использование горячего резерва снижает их. Потому что, по моему мнению, ваш горячий резерв предназначен только для устранения аппаратного сбоя, что, хотя и не редкость, не является единственным операционным риском, с которым вы сталкиваетесь, и не является наиболее вероятным. Вторая проблема заключается в том, обеспечивают ли альтернативные стратегии большее снижение риска или значительную экономию.
Запуск горячего резерва с несколькими ручными этапами переключения при отказе займет много времени и, скорее всего, выйдет из строя, но мне также кажется, что автоматическое аварийное переключение с наборами кластеров высокой доступности превращается в основные кластерные проблемы.
Другое дело, что горячее или холодное резервирование в одном месте не обеспечивает непрерывности бизнеса в случае локального бедствия.
Концепция горячего или даже холодного резерва зависит от как приложения создаются в первую очередь.
Я имею в виду, что если приложение было построено таким образом, что нагрузка данных и служб распределяется по нескольким машинам, тогда концепция любой отдельной машины, отключающей систему, должна исчезнуть. В этой ситуации вам не нужен горячий резерв. Вместо этого вам потребуется достаточная избыточная мощность для обработки, когда отдельная машина / компонент умирает.
Например, для стандартного веб-приложения обычно требуются веб-сервер и сервер базы данных. Для веб-серверов просто балансируйте нагрузку 2 или больше. Если кто-то умрет, ничего страшного. База данных обычно сложнее, так как ее нужно спроектировать так, чтобы все данные синхронизировались между участвующими машинами. Таким образом, вместо одного сервера БД вы получаете 2 (или более), которые оба обслуживают ваши потребности в данных. По этому пути пошли крупные поставщики услуг, такие как Google, Amazon, Facebook и т. Д. Время разработки требует больше первоначальных затрат, но оно приносит свои плоды, если вам необходимо масштабирование.
Теперь, если ваше приложение не структурировано таким образом или его просто невозможно подогнать заново, то да, вам, вероятно, понадобится горячий резерв.