Как обеспечивается совершенно бесперебойная работа сервера?
Ситуация 1:
Сервер с очень важной программой требовательной к дискам, как по скорости, так и по объему.
Тут на сервер упал кирпич (насквозь пробил) или его осветил священник, в общем сервер помер, софт тоже не работает. Как такого избежать?
Ситуация 2:
То же самое - сервер+важное ПО.
Пришла буря, одну подстанцию поджарила молнией, от второй оторвала провода. Два хитрых охранника слили по полбака солярки из генератора каждый, ИБП отработали нормально и сохранили работу серверов и теперь остаётся молиться, чтобы электрики починили свет, глядя на то, как быстро убывает % заряда АКБ....
Как избежать и такого?
Вы по большому счёту пишете о рисках.
Самое первое, что нужно сделать - посчитать стоимость простоя. Самостоятельно или с помощью профи - решать Вам. Причём стоимость простоя на уровне сервисов. Не работает вообще всё, не работает 1С, не работает сайт, не работает почта... И так далее.
К примеру, простой в работе ХХХ стоит 10 рублей в час. Обеспечивается работоспособность ХХХ сервером и админом рядом с ним. Условно простой вероятен 2 часа в месяц (болезни админа, остановка для апгейда, вырубание искричества...). Считается он обычно исходя из документации - производителя сервера, владельца ЦОДа и тому подобное. Есть несколько методологий рассчёта, но всё сложно.
Вы смотрите и понимаете, что затраты на резервирование не стоят свеч - 20 рублей в месяц это ниачом.
Допустим, простой стоит 999999 рублей в час. ОК, можно взять специализированный сервис, который гарантирует 99.9999999999% доступности. И это будет выгодно.
Допустим, Вы насчитали нечто среднее. Обычно так и бывает. И начинается самое интересное - перечисление и оценка рисков. И тут уже мрак, потому как за Вас эту работу никто качественно и бесплатно не сделает (даже если можно делать долго). И всех рисков Вы не учтёте никогда. Можете попробовать застраховать. Говорят, зарубежом это работает. В РФ - не верю, но это во-первых ИМХО, а во-вторых предложение-то есть.
И вот только когда у Вас будет перечень рисков можно задавать вопросы. А пока всё описанное Вами сводится к тому, что к оборудованию имеют доступ безответственные идиоты.
Вариант №1 - создание отказоустойчивого кластера - два физических сервера работают в паре, при этом один сервер выполняет работу, а второй сервер работает в резерве, при этом получает актуальные копию данных с первого сервера, делается разными инструментами. В случае гибели первого сервера, второй берет нагрузку на себя.
Вариант №2 - применим для веб-сайтов - пользовательские запросы направляются на сервера по определенным правилам на несколько серверов, в случае выход из строя одного из серверов - нагрузка вырастает на оставшиеся.
Вариант №3 - географически разнесенные дубликаты сервисов - самый надежный вариант, но кластер на длинных расстояниях сделать очень сложно - возникают проблемы с пропускной способностью, задержкой передачи и временными перерывами связи - не все протоколы, работающие в локальной сети способны справиться с этой проблемой.
В целом задача решается с применением известных решений с учетом специфики решаемой задачи и существующей архитектуры сервиса.
Простого решения - панацеи от всех проблем нет.
В одном ДЦ - можно heartbeat или pacemaker https://habr.com/post/107837/
Для горячей копии данных удобно использовать DRBD или распределеннные ФС.
Для географически распределенной системы решается только с помощью архитектуры.
В простых случаях, когда нужно только раздавать контент, то можно обойтись балансировкой. Например, с помощью round robin DNS и нескольких балансеров на haproxy перед серверами с контентом. Но это тоже не панацея, если ляжет вся DNS зона. В некоторых случаях полезно завести несколько доменов в разных зонах.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
