Отказоустойчивость серверов и СХД: как выбрать резервирование по целевым показателям

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

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

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

Что означает высокая доступность серверов

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

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

Простой пример: в проекте есть два сервера. На первый взгляд похоже, что возможность резервирования есть. Но если оба сервера подключены к одному коммутатору, СХД и контуру питания, отказ общего элемента остановит все узлы. В такой схеме запасное оборудование есть, а высокой доступности сервиса может не быть.

То же самое касается кластера. Он снижает зависимость от одного узла, но работает в связке с хранилищем, сетью и питанием. Если виртуальная машина может перезапуститься на другом сервере, но данные лежат на недоступной СХД, пользователи не получат рабочее приложение.

Задайте себе вопрос: что должно оставаться доступным даже при сбое и аварии?

• для сервера: резервные блоки питания, сетевые интерфейсы и узлы кластера;
• для СХД: контроллеры, дисковые полки и несколько путей к данным;
• для сети: независимые коммутаторы и маршруты;
• для восстановления: понятный порядок переключения и проверка на реальном сервисе.

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

Вывод

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

Где нужна отказоустойчивая ИТ-инфраструктура

Речь пойдет о компаниях, где пауза в работе цифрового сервиса недопустима, так как влияет на все операции. Отказоустойчивость серверов и СХД важна для:

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

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

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

Есть процессы, которые должны иметь заранее описанный сценарий. Команда должна понимать, что отключилось, куда переводится нагрузка и когда пользователям снова открывают доступ. Без такого сценария резервные компоненты остаются набором функций, а восстановление зависит от ручного разбора.

Ключевые показатели отказоустойчивости

Расчет начинается с границ, которые задает бизнес. Сколько сервис может быть недоступен. Какие последние данные допустимо потерять. Какой уровень доступности нужен за выбранный период.

После этого требования переводят в показатели: RTO, RPO и SLA.

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

RPO показывает, какие данные компания готова потерять. Например, восстановить базу к состоянию на вчерашний вечер и восстановить ее к состоянию за несколько минут до сбоя — разные задачи. Чем меньше допустимая потеря данных, тем строже требования к копированию, репликации и хранению точек восстановления.

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

У разных систем эти показатели могут отличаться.

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

Важно!

Отказоустойчивость серверов и СХД считают не по одному показателю для всей компании, а по группам сервисов.

Механизмы для роста отказоустойчивости

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

СХД в наличии на складе в Москве

Показать варианты →

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

Что произойдет при отказе сервера

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

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

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

Останется ли доступ к СХД

Рабочий сервер бесполезен, если он потерял путь к данным. Поэтому СХД проверяют вместе с подключением от узла до хранилища.

Важны не только контроллеры на стороне СХД. Нужно посмотреть весь маршрут:

• адаптер сервера;
• кабель;
• коммутатор;
• порт хранилища;
• настройка многопутевого доступа.

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

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

Из какой точки вернутся данные

Резервная копия должна храниться отдельно от основной среды. Для критичных систем стоит предусмотреть изолированное или неизменяемое хранение. Но сама копия еще не доказывает готовность: ее нужно восстановить и проверить на реальном сервисе.

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

Где сеть и питание могут остановить всю схему

Два сервера не помогут, если оба зависят от одного коммутатора. Несколько путей к СХД тоже не спасут, если они упираются в общий адаптер. У оборудования должен быть доступный контур питания после отказа одного элемента.

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

Кто запускает переподключение

Технические моменты важны, но никто не отменял человеческий фактор. Нужно назначить того, кто принимает основные решения:

1. где лежат инструкции к восстановлению;
2. какой сервис поднимать первым;
3. как команда будет проверять результат.

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

Аварийное восстановление: что произойдет при отказе площадки

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

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

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

Типичные ошибки при резервировании и отказоустойчивости

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

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

Наличие RAID, кластера или реплики еще не показывает, как поведет себя сервис при сбое. Рабочая схема связывает каждый механизм с конкретным сценарием и подтверждает, что сервис возвращается в нужное состояние.

Начинать стоит с простых вопросов: что у нас запущено прямо сейчас? Кто владелец каждого сервиса? Каков SLO и какие ресурсы действительно необходимы для его выполнения? Соответствует ли это текущим требованиям бизнеса?

— Редакция CRABBIT

Какие данные собрать до модернизации или закупки

До выбора серверов, СХД, программного обеспечения и второго контура соберите исходные данные. Без них проект легко превращается в сравнение функций продуктов вместо проверки архитектуры.

• список сервисов и владельцев процессов;
• допустимое время простоя по каждому критичному сервису;
• допустимую потерю данных;
• требуемый уровень доступности;
• карту зависимостей: приложение, база, сервер, СХД, сеть, питание, внешние службы;
• текущую схему резервного копирования;
• результаты последних проверок восстановления;
• схему подключения серверов к СХД;
• ограничения по стойкам, питанию, охлаждению и площадке;
• требования к закупке, лицензированию и поддержке.

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

Вопросы и ответы