Что произойдёт, если один сервер внезапно отключится

Иллюзия непрерывности: как системы переживают аппаратные сбои

В любой информационной системе есть оборудование, которое рано или поздно выйдет из строя.

Сервер может внезапно выключиться. Диск — перестать отвечать. Сетевой интерфейс — потерять соединение. Виртуальная машина — стать недоступной. Отдельный сервис — завершить работу из-за ошибки. Сам по себе отказ одного компонента ещё не означает, что должна остановиться вся система.

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

На практике надёжность корпоративной системы складывается сразу из нескольких независимых механизмов:

• › резервирования;
• › распределения нагрузки;
• › репликации данных;
• › мониторинга;
• › автоматического переключения;
• › резервного копирования;
• › продуманного восстановления.

При этом важно понимать: ни один из этих механизмов сам по себе не делает систему отказоустойчивой.

REQUIRED_ARCHITECTURE: Требуется комплексное сквозное проектирование всего инфраструктурного контура.

Отказ одного сервера — это только начало сценария

Представим простую архитектуру:

Если сервер приложения выключается, пользователи больше не могут работать. Но что произойдёт, если добавить второй сервер?

На первый взгляд проблема решена. Но на практике возникает каскад сопутствующих вопросов:

• › Кто решает, куда направлять пользователя?
• › Что происходит, если сервер 1 перестал отвечать?
• › Как система понимает, что сервер действительно неисправен?
• › Что будет с запросами, которые уже выполнялись?
• › А если одновременно откажет база данных?
• › А если серверы работают, но между ними и пользователем исчезнет сеть?

Что вообще означает «система пережила сбой»

Это не обязательно означает, что пользователь вообще ничего не заметил. Есть несколько уровней.

Поэтому перед началом архитектурного проектирования необходимо жестко определить критерии отказов:

• › сколько простоя допустимо;
• › какие операции критичны;
• › сколько данных можно потерять;
• › сколько времени допустимо на восстановление;
• › какие компоненты должны быть резервированы;
• › какие отказы система обязана переживать автоматически.

Без фиксации этих требований невозможно правильно выбрать целевую архитектуру.

REQUIRED_SPECIFICATION: CRITICAL_METRICS_NOT_DEFINED

Отказоустойчивость и резервная копия — не одно и то же

Это одна из самых распространённых ошибок.

Представим классический линейный сценарий восстановления из бэкапа:

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

• › найти резервную копию;
• › восстановить систему;
• › восстановить данные;
• › проверить целостность;
• › запустить сервисы;
• › вернуть пользователей в работу.

А отказоустойчивая архитектура пытается сделать так, чтобы при определённых типах отказов работа продолжалась вообще без полноценного и долгого восстановления из резервной копии.

Что именно защищает систему от простоя

Условно можно разделить механизмы на несколько ключевых уровней.

Все эти механизмы предназначены для решения принципиально разных задач.

Резервирование бывает разным

Самый простой вариант — иметь запасной сервер. Но важно понять, как именно он будет использоваться.

Балансировщик не делает систему отказоустойчивой автоматически

Балансировщик распределяет запросы между серверами.

Но балансировщик должен четко понимать, какой сервер действительно работает. Для этого используются специализированные механизмы контроля — health check.

Поэтому проверки состояния инфраструктуры должны строго и глубоко соответствовать реальной архитектуре.

Есть разница между «сервер жив» и «сервис работает»

Представим физическое состояние узла в контуре:

Поэтому в серьёзных системах мониторинг обязан смотреть не только на физическое состояние серверов, но и на сквозные бизнес- и сервисные показатели.

А что будет с данными?

С приложением всё относительно просто: можно запустить второй экземпляр.

С базой данных ситуация сложнее.

Представим:

Если база является единственной, она становится единой точкой отказа.

То есть два сервера приложений не спасают систему.

Архитектура всё равно зависит от одного критического компонента.

Это называется Single Point of Failure — единая точка отказа.

Как находят единые точки отказа

Полезно мысленно пройти по всей цепочке:

Теперь для каждого компонента задаётся один вопрос:

Если ответ:

значит, найден потенциальный Single Point of Failure.

Но наличие точки отказа само по себе не всегда означает архитектурную ошибку.

Иногда резервирование слишком дорого или технически неоправданно.

Вопрос заключается в другом:

Соответствует ли уровень риска требованиям бизнеса?

Репликация базы данных не равна резервной копии

Допустим, база данных реплицируется:

Это помогает пережить отказ одного узла.

Поэтому репликация защищает прежде всего от определённых инфраструктурных отказов, но не заменяет полноценную стратегию резервного копирования и восстановления.

От каких сбоев нужно защищаться

Сбой — это не обязательно «сервер выключился».

На практике возможны:

• › отказ диска;
• › отказ сервера;
• › ошибка операционной системы;
• › повреждение базы;
• › ошибка приложения;
• › неудачный релиз;
• › ошибка конфигурации;
• › сбой сети;
• › потеря соединения с внешним сервисом;
• › ошибочное удаление данных;
• › атака;
• › отказ целого дата-центра.

И для каждого сценария может потребоваться отдельный механизм защиты.

Например:

Главное — не пытаться решить все эти проблемы одним инструментом.

Мониторинг нужен не для красивых графиков

Мониторинг часто воспринимается как набор дашбордов:

Это полезно, но недостаточно.

Представим, что:

Всё выглядит прекрасно.

Поэтому мониторинг должен отвечать на вопрос:

Работает ли система так, как ожидает бизнес?

Нужны не только метрики, но и события

Хорошая система наблюдаемости обычно объединяет:

• › метрики;
• › логи;
• › трассировку;
• › события;
• › уведомления.

Например:

Для детального разбора инцидента нужно оперативно понять:

• › какой запрос выполнялся;
• › какой сервис отвечал;
• › где возникла задержка;
• › обращался ли запрос к базе;
• › была ли ошибка;
• › повторялся ли запрос.

Чем сложнее распределённая система, тем важнее возможность пройти путь конкретной операции через несколько компонентов.

Что такое автоматическое переключение

Failover — это механизм, при котором система при отказе основного компонента переходит на резервный.

Например:

Но автоматическое переключение — не магия.

Система должна пошагово реализовать распределенный алгоритм:

• › обнаружить проблему;
• › убедиться, что это действительно отказ;
• › определить доступный узел;
• › переключить трафик;
• › обеспечить доступ к актуальным данным;
• › продолжить работу;
• › зафиксировать событие;
• › позже восстановить исходную конфигурацию.

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

Опасность ложного переключения

Система может решить, что сервер умер, хотя на самом деле он просто временно не отвечает.

Поэтому механизмы failover требуют аккуратного проектирования, таймаутов и защиты от split-brain-сценариев.

Балансировка нагрузки нужна не только при сбое

Предположим, один сервер способен обработать:

Можно добавить второй экземпляр:

Теперь система получает запас производительности.

Но важно понимать:

масштабирование и отказоустойчивость — разные задачи.

Дополнительный сервер может использоваться для увеличения производительности.

А возможность пережить его отказ — уже свойство архитектуры.

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

А если серверы стоят в одном месте?

Это ещё одна распространённая проблема.

Допустим:

Формально всё резервировано.

Но если отключится:

• › электропитание;
• › сетевой сегмент;
• › система охлаждения;
• › всё здание;
• › канал связи,

Поэтому иногда резервирование необходимо строить не только между серверами, но и между физическими площадками.

Географическое резервирование — уже другой уровень

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

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

RPO и RTO: два показателя, которые определяют требования

При проектировании восстановления особенно важны два понятия.

Условно:

Эти показатели позволяют перейти от абстрактного: «Нам нужна надёжная система» к конкретным требованиям.

Высокая доступность стоит денег

Можно построить архитектуру, которая практически не допускает простоя.

Но вопрос:

остаётся обязательным.

Поэтому отказоустойчивость — это всегда баланс между стоимостью инфраструктуры и стоимостью отказа.

Нельзя забывать о человеческом факторе

Даже идеально резервированная инфраструктура не спасёт от неправильной процедуры.

Поэтому отказоустойчивость включает не только технологии, но и процессы:

• › регламенты;
• › контроль изменений;
• › разграничение доступа;
• › тестирование;
• › документацию;
• › аварийные сценарии;
• › обучение сотрудников.

Резервная копия, которую никто не проверял, — это предположение

Очень важный принцип:

Можно ежедневно получать ложный статус в журналах:

и всё равно обнаружить во время аварии, что восстановить систему невозможно.

Причины могут быть разные:

• › повреждённый архив;
• › неправильная конфигурация;
• › отсутствующие зависимости;
• › неверные права;
• › неполная копия;
• › неизвестная последовательность восстановления.

Поэтому необходимо регулярно проводить тестовое восстановление.

Резервировать нужно не только данные

Представим, что база сохранена идеально.

Но для работы системы необходимы:

• › конфигурации;
• › секреты;
• › сертификаты;
• › файловое хранилище;
• › очереди;
• › настройки приложений;
• › инфраструктурные параметры;
• › внешние зависимости.

Поэтому хороший план восстановления описывает всю систему, а не только базу данных.

Отказоустойчивость нужно проверять отказом

Есть фундаментальная проблема:

Поэтому существуют практики контролируемого тестирования отказов.

Например, можно проверить:

• › отключение одного экземпляра приложения;
• › потерю соединения с базой;
• › отказ сетевого интерфейса;
• › недоступность внешнего API;
• › переполнение диска;
• › восстановление после сбоя;
• › работу резервного канала.

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

Важен не только отказ, но и возвращение в нормальное состояние

Допустим, сервер 1 вышел из строя. Трафик автоматически ушёл на сервер 2.

На этом задача не заканчивается.

Нужно понять:

• › почему сервер 1 отказал;
• › что с его данными;
• › можно ли безопасно вернуть его в кластер;
• › не содержит ли он устаревшее состояние;
• › как синхронизировать данные;
• › как вернуть нормальное распределение нагрузки.

Отказоустойчивая архитектура — это цепочка, а не отдельный сервер

Хорошо спроектированная система обычно выглядит примерно так:

Именно совокупность этих механизмов позволяет системе переживать разные классы отказов.

Но резервировать всё подряд тоже неправильно

Можно сделать два сервера.

В результате получится чрезвычайно сложная инфраструктура.

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

Если стоимость простоя ниже стоимости дополнительной инфраструктуры и её эксплуатации, резервирование может быть неоправданным.

Главная ошибка — думать только о железе

Отказоустойчивость часто ассоциируют с серверами.

Но в современной корпоративной системе отказать может любой слой:

Поэтому вопрос должен звучать не:

а:

Это гораздо более полезная постановка задачи.

Как проектировать систему, которая действительно переживает сбои

На практике полезно двигаться от бизнес-требований.

Самая надёжная система — не та, в которой ничего никогда не ломается

Такой системы не существует.

• › Серверы ломаются.
• › Сеть пропадает.
• › Диски выходят из строя.
• › Программное обеспечение содержит ошибки.
• › Люди допускают ошибки.
• › Внешние сервисы становятся недоступными.

Поэтому зрелая архитектура строится не вокруг предположения:

Она строится вокруг другого:

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

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

🔒 Данные и доступ к системам заказчика обрабатываются в соответствии с согласованными требованиями к безопасности и конфиденциальности. Условия доступа, хранения и обработки данных определяются архитектурой проекта и договором.

Сайт носит исключительно информационный характер и не является публичной офертой в соответствии со статьёй 437 Гражданского кодекса РФ. Цены, состав и условия предоставления услуг уточняются при проектировании решения и фиксируются в договоре. Условия технического сопровождения и уровень сервиса могут дополнительно определяться отдельным соглашением (SLA).