Что такое высокодоступная инфраструктура и зачем она нужна

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

Поэтому в инфраструктурной инженерии существует простое и понятное правило: вопрос не в том, произойдёт ли сбой, а в том, когда именно он произойдёт. И тут нам, инженерам, на помощь приходит High Availability Infrastructure (высокодоступная инфраструктура).

Высокодоступная инфраструктура (High Availability Infrastructure или просто HA) - это подход к проектированию ИТ-систем, при котором отказ отдельных компонентов не приводит к остановке сервиса. Если один элемент выходит из строя, система автоматически переключается на резервные ресурсы и контуры, в результате чего пользователь часто даже не замечает возникновения проблемы.

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

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

 

 

 

 

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

Высокая доступность (High Availability, HA) - это способность системы оставаться работоспособной даже при отказе отдельных компонентов инфраструктуры. Проще говоря, сервис продолжает функционировать даже тогда, когда один из серверов, сетевых устройств или программных модулей перестаёт работать.

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

В инженерной практике доступность обычно измеряется процентом времени, в течение которого сервис остаётся доступным пользователям. Этот показатель часто закрепляется в соглашении об уровне обслуживания - SLA (Service Level Agreement) и чем выше процент доступности, тем меньше допустимое время простоя системы в течение года.

Даже небольшая разница в долях процента может означать существенное отличие в реальном времени недоступности сервиса. Например, переход от 99.9% к 99.99% снижает допустимый простой почти в десять раз.

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

 

Таблица - Типичные уровни доступности (SLA)

Доступность	Допустимый простой в год	Где обычно применяется
99%	около 3,6 дней	небольшие сайты и внутренние сервисы
99.9%	около 8,7 часов	SaaS-приложения и корпоративные системы
99.99%	около 52 минут	крупные веб-проекты и онлайн-платформы
99.999%	около 5 минут	финансовые системы и критически важные сервисы

 

Показатель 99.999% часто называют "five nines availability". Достичь такого уровня доступности можно только при тщательно продуманной архитектуре с резервированием серверов, распределёнными базами данных, отказоустойчивыми сетями и автоматическими механизмами восстановления системы.

Уровень SLA всех серверов от 3v-Hosting приближается к 99.99%

 

 

 

 

Что такое Single Point of Failure (SPOF)

Говоря о высокой доступности, невозможно обойти ещё одно ключевое понятие, такое как Single Point of Failure, или единая точка отказа.

Single Point of Failure (SPOF) - это любой компонент инфраструктуры, отказ которого приводит к остановке всего сервиса. Проще говоря, это элемент системы, от которого критически зависит работа приложения и у которого нет резервной замены. 

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

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

• один сервер приложений, на котором работает весь сайт или API;
• единственная база данных, где хранятся все данные сервиса;
• один балансировщик нагрузки, через который проходит весь входящий трафик;
• единственный сетевой коммутатор или маршрутизатор;
• один DNS-сервер, отвечающий за разрешение доменного имени;
• единственное хранилище данных (storage-сервер или файловая система);
• и т.д.

 

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

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

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

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

 

 

 

 

Причины инфраструктурных сбоев

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

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

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

 

Аппаратные сбои

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

К наиболее частым аппаратным проблемам относятся:

• выход из строя SSD или HDD;
• отказ модулей оперативной памяти;
• перегрев процессоров или других компонентов;
• неисправности блоков питания;
• сбои или деградация RAID-массивов.

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

 

Сетевые проблемы

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

Типичные сетевые инциденты могут включать:

• перегрузку сетевых каналов;
• сбои в работе маршрутизаторов или коммутаторов;
• ошибки конфигурации сетевых устройств;
• проблемы с BGP-маршрутизацией;
• неправильную работу балансировщиков нагрузки.

 

Программные ошибки

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

В данном разрезе к распространённым проблемам относятся:

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

 

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

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

 

Человеческий фактор

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

Ещё примеры таких ситуаций:

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

 

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

 

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

 

 

 

 

Базовые принципы высокодоступной архитектуры

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

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

 

Устранение единой точки отказа

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

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

На практике это означает использование:

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

 

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

 

Автоматическое переключение (Failover)

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

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

Механизмы переключения могут работать на разных уровнях инфраструктуры:

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

Главная цель failover - это свести к минимуму время недоступности сервиса в случае возникновения сбоя.

 

Репликация данных

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

На практике используются различные модели репликации:

• master–replica (primary–replica) - когда основной сервер синхронизирует данные с резервными узлами;
• multi-master архитектура - когда несколько серверов могут одновременно принимать записи;
• распределённые storage-системы - когда данные автоматически распределяются между множеством узлов.

 

 

Мониторинг и автоматическое восстановление

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

Как правило, мониторинг собирает информацию о:

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

 

Существует великое множество инструментов мониторинга, но наиболее популярными и хорошо зарекомендовавшими себя сейчас считаются Prometheus, Grafana, Zabbix и Alertmanager.

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

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

 

 

 

 

Типичные инструменты для построения HA-инфраструктуры

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

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

 

Таблица - Инструменты High Availability

Уровень инфраструктуры	Задача	Популярные инструменты
Балансировка нагрузки	Распределение входящего трафика между несколькими серверами приложений	HAProxy, Nginx, Traefik, Envoy
Failover и виртуальные IP	Автоматическое переключение трафика на резервный узел при сбое	Keepalived, Pacemaker, Corosync
Кластеризация баз данных	Репликация данных и автоматическое переключение primary-узла	Patroni, Galera Cluster, PostgreSQL Streaming Replication, MySQL Group Replication
Контейнерная оркестрация	Автоматическое управление контейнерами и перезапуск сервисов	Kubernetes, Docker Swarm, Nomad
Хранилище данных	Распределённое хранение файлов и защита от потери данных	Ceph, GlusterFS, MinIO
Мониторинг и алерты	Наблюдение за состоянием инфраструктуры и обнаружение проблем	Prometheus, Grafana, Zabbix, Alertmanager
Service Discovery	Автоматическое обнаружение сервисов в распределённой системе	Consul, etcd, ZooKeeper
Логи и наблюдаемость	Сбор и анализ логов для диагностики проблем	ELK Stack (Elasticsearch, Logstash, Kibana), Loki

 

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

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

 

 

 

 

Цена высокой доступности

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

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

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

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

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

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

 

 

 

Часто задаваемые вопросы (FAQ)

 

Что такое High Availability?

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

 

Чем High Availability отличается от Fault Tolerance?

High Availability допускает кратковременное переключение системы на резервные ресурсы.
Fault Tolerance предполагает непрерывную работу без какого-либо перерыва, даже на уровне миллисекунд.

 

Можно ли построить HA на VPS?

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

 

Сколько серверов нужно для HA?

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

 

Влияет ли высокая доступность на производительность?

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

 

Можно ли добавить HA к уже работающему проекту?

Да, но часто это требует переработки инфраструктуры - добавления балансировщиков, репликации данных и мониторинга.

 

Всегда ли высокая доступность необходима?

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

 

 

 

 

Выводы

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

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

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

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

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