Большинство бизнес-процессов в том или ином виде опираются на цифровые системы и не могут функционировать без них. Поэтому отказоустойчивость IT-систем напрямую влияет на непрерывность бизнеса в целом. Однако обеспечивать высочайшую степень отказоустойчивости для всех IT-решений, которые использует компания, нет смысла. Это значительно увеличит их стоимость и ограничит гибкость настроек, при том, что далеко не каждой системе необходимо быть на 100% отказоустойчивой.
- Как же определить необходимый уровень отказоустойчивости для конкретной системы?
- Почему всё больше компаний отдают предпочтение отказоустойчивым системам в облаке, нежели на собственных серверах?
- Как SimpleOne обеспечивает отказоустойчивость с помощью кластеризации и балансировки трафика?
Разбираемся в этой статье.
Нужна ли вам отказоустойчивая система?
Отказоустойчивость — это способность системы сохранять работоспособность после отказа определённого количества её составных частей. Чтобы система считалась отказоустойчивой, нужно как минимум два сервера, которые одновременно занимаются задачей распределения запросов/трафика без явного разделения ролей на ведущего и резервного.
Насколько важна отказоустойчивость каждой конкретной IT-системы? Существует классификация корпоративных приложений по степени критичности поддержания непрерывности их работы. Градация зависит от того, какие функции выполняет приложение и каким целям бизнеса служит:
- Mission critical. Система, работающая в режиме реального времени, без которой в краткосрочном промежутке времени невозможно функционирование предприятия. Простой любой длительности приведёт к штрафным санкциям со стороны клиентов. Рекомендованное время восстановления после отказа — до 10 минут. Для таких систем должны использоваться специализированные серверные платформы и инфраструктурные уровни с полным многократным резервированием всех компонентов, в том числе с использованием резервных удаленных ЦОД;
- Business critical. Система с режимом работы 24/7. Простой в среднесрочном периоде повлечет за собой финансовые или имиджевые потери. Однако в кратковременном промежутке времени предприятие может выполнять свои обязательства с незначительным снижением уровня сервиса. Рекомендованное время восстановления после отказа — 1-2 часа. Для таких систем должны использоваться кластерные решения и инфраструктурные уровни с частичным резервированием инфраструктурных компонентов;
- Business operational. Системы с режимом работы 8х5. Долговременный простой создает значительные неудобства пользователям. Внутренние процессы компании, не направленные на обслуживание клиентов, могут быть недоступны. Рекомендованное время восстановления после отказа — 4-6 часов. Для таких систем рекомендуется использовать резервирование хранения данных и электропитания;
- Office productivity. Локальный инструментарий эксплуатационных подразделений. Простой в среднесрочном периоде не отразится на уровне сервиса других систем. Рекомендованное время восстановления после отказа — 1-2 рабочих дня.
Класс критичности системы зависит от тяжести последствий её остановки и скорости их наступления. Этим четырём уровням соответствуют различные конфигурации IT-инфраструктуры — более и менее устойчивые. Классифицировав по такому принципу все цифровые процессы, компания может обоснованно выбирать для каждой системы то или иное инфраструктурное решение.
Классификация систем с точки зрения обеспечения непрерывности и отказоустойчивости должна быть одним из решающих факторов при выборе уровня инфраструктуры IT-системы.
Например, платформа SimpleOne предназначена для автоматизации сервисных бизнес-процессов. Enterprise-системы такого класса, как правило, внедряют для широкого спектра задач. Как минимум — для управления услугами всего департамента (IT, HR, логистический и т.д.), как максимум — для сквозной автоматизации между отделами и создания единого окна для услуг всех департаментов компании. Подобная функциональность лежит в диапазоне Mission critical – Business critical. Поэтому архитектура SimpleOne выстроена с учетом высокой доступности и отказоустойчивости системы.
Отказоустойчивость в облаке
Платформа SimpleOne, как и многие enterprise-решения, предоставляет клиентам два варианта размещения своей платформы:
- On-premise. Клиент разворачивает экземпляр приложения SimpleOne на собственном оборудовании;
- Cloud. Клиент получает доступ к решению SimpleOne, которое разворачивается на облачных мощностях вендора.
Несмотря на то, что варианту on-premise традиционно отдаётся предпочтение в случаях, когда системе предстоит работать с высокочувствительными данными, всё больше компаний начинают обращаются к облачным технологиям. Принципы облачной архитектуры соотносятся с принципами отказоустойчивости: несколько геораспределенных серверов нужны именно для того, чтобы в случае поломки одного из них, система продолжала работу.
Растущей популярности облака в качестве отказоустойчивого решения есть несколько причин:
- Систему проще поддерживать. Администрирование в облаке включено в услугу облачных поставщиков по умолчанию, в отличие от on-premise решений. Если разворачивать систему в облаке, это подразумевает меньше поддерживаемых самостоятельно информационных систем.
- Большая повседневная надежность. Непрерывная работа ПО — один из главных приоритетов поставщиков облачных решений. Главным образом непрерывность работы достигается за счёт географической распределённости облачных серверов. Отдельные предприятия не могут выделять на поддержку системы те же ресурсы, что и поставщик облачных систем, который выигрывает за счет масштабов и опыта.
- Надежное аварийное восстановление. Повышенная надежность также приводит к быстрому восстановлению в случаях, когда отключение всё же произошло. Благодаря постоянному резервному копированию, включенному в стандартную подписку SaaS, производится восстановление данных. В то время клиенты on-premise сами несут ответственность за свои меры аварийного восстановления.
Один из принципов построения облачной архитектуры, который обеспечивает платформе SimpleOne отказоустойчивость и высокую доступность — это кластеризация и балансировка. Эта тактика распределения трафика между узлами серверов повышает скорость обработки данных и обеспечивает отказоустойчивость, косвенно увеличивая и масштабируемость системы.
Как устроены кластеризация и балансировка
Кластеризация распределяет рабочую нагрузку (все запросы и данные, которые поступают в систему) по распределённым узлам и серверам.
Кластеризация обеспечивает стабильность работы оборудования и самого приложения при повышенных нагрузках, позволяет распределять потоки запросов на соседние серверы в случае, если один из них выйдет из строя. Помимо решения проблемы высоких нагрузок кластеризация помогает также обеспечить резервирование серверов друг на друга.
Распределение нагрузки между серверами в кластере происходит с помощью аппаратного либо программного устройства — балансировщика, который автоматически распределяет трафик между компонентами, входящими в один кластер. За счет этого удается избежать перегрузки всей системы и одновременно обеспечить переключение между различными серверами или виртуальными машинами. Балансировка защищает от сбоев в работе системы даже при выходе из строя одного или нескольких серверов. Рабочие нагрузки быстро перераспределяются на резервные устройства, что помогает избежать аварийной ситуации и предотвратить прерывание бизнес-процессов.
Балансировщик — это отдельный продукт, у которого могут быть самые разные характеристики в зависимости от инфраструктуры, которую запланировал для своей системы заказчик. Невозможно стандартизировать методы балансировки в единое решение, отвечающее потребностям любого клиента. Поэтому балансировщик не входит в поставку SimpleOne, клиент выбирает и внедряет его самостоятельно, отталкиваясь от требований к доступности своего приложения. Единственное требование которому должен отвечать балансировщик для платформы SimpleOne, это уровень балансировки: L4 (tcp) либо L7 (http/https).
Кластерная архитектура SimpleOne
«При разработке инфраструктурной части SimpleOne, мы обеспечили высокую доступность платформы, что позволяет безболезненно переживать отказ одного из узлов приложения. Будь то инцидент с базой данных, непредвиденная остановка виртуальной машины или падение сервера — это не повлияет на конечную работу системы»,
— Георгий Оськин, DevOps инженер SimpleOne.
Вспомогательные компоненты SimpleOne
Отказоустойчивость каждого вспомогательного компонента системы SimpleOne прорабатывается отдельно. Например, изначально в системе использовались хранилища в единственном экземпляре (single-instance). Сейчас, в зависимости от компонента, это минимум два сервера, которые работают на нескольких виртуальных или физических хостах, что позволяет при выходе одного узла из строя продолжить работу с минимальными величинами возможного простоя приложения.
Для управления базой данных в SimpleOne используется СУБД PostgreSQL. Для обеспечения высокой доступности используется репликация. С основного узла базы данных постоянно копируются (реплицируются) на один или несколько других узлов (реплики). Соответственно при выходе одного узла из строя, происходит автоматическое переключение роли основного узла базы данных, чтобы приложение продолжало работать в прежнем режиме. Средний лаг при таком переключении составляет 5-10 секунд.
Для кэширования запросов используется быстрое хранилище данных в памяти Redis. Сервер кэша работает в режиме active-passive. То есть один узел используется всегда и, в случае недоступности первого узла, все запросы на наполнение кэша переключаются на второй.
Распределение трафика на основные компоненты SimpleOne
Кластеризация основных компонентов платформы (фронтенд и API-сервер) устроена единым образом. Роль единой точки входа в приложение выполняет балансировщик, который распределяет запросы между минимум двумя прокси-серверами, которые дублируют друг друга и проксируют все запросы на основные компоненты приложения.
«Клиентам мы рекомендуем размещать прокси-сервера в разных зонах в пределах одного региона. Например, в разных дата-центрах, чтобы, при потере одного из дата-центров, приложение продолжило работу»,
— Георгий Оськин, DevOps инженер SimpleOne.
Предотвращение потери данных
Чтобы обезопасить систему от возможной потери данных, в SimpleOne была применена нетиповая архитектура.
По умолчанию репликация данных (распределение нагрузки) в SimpleOne осуществляется в режиме primary/secondary. Этот подход подразумевает два узла базы данных. Один из них назначается основным (primary), второй — дублирующим (secondary). На основной узел идут все запросы на чтение и запись данных, в то время как secondary-узел постоянно копирует все изменения с primary-узла.
Однако, любая распределённая схема баз данных неидеальна, поэтому иногда могут происходить сбои с определением роли primary. Например, одновременно может появиться два узла с ролью primary. Как правило, такое происходит из-за рассинхронизации вспомогательной базы данных, хранящей состояние каждого из узлов кластера и обеспечивающей согласованность принимаемых решений. Это редкая ситуация и предсказать её заранее невозможно.
В случае, когда оба узла считают себя основными, запросы и данные начинают балансироваться между ними двумя. Что недопустимо, так как в таком случае половина запросов пойдёт в настоящий primary-узел и будет выполнена, а другая половина будет проигнорирована и потеряна, так как пойдут на тот узел, который на самом деле основным не является.
«Эту проблему мы решили интересным способом. Если система видит более одного активного мастера в кластере, она перестает посылать и обрабатывать запросы в базе данных. Любой случай прекращения записи данных сразу становится виден на средствах мониторинга. Это позволяет быстро заметить наличие проблем в платформе, подключить инженера и исправить причину остановки записи — рассинхронизацию ролей primary/secondary. Таким образом мы настроили систему так, чтобы она намеренно создавала заметную, но не критичную ошибку, чтобы избежать более серьезных последствий — потери или расслоения данных»,
— Георгий Оськин, DevOps инженер SimpleOne.
Заключение
Отказоустойчивость системы зависит от сочетания множества факторов. Кластеризация и балансировка — один из важных кирпичиков, которые образуют то, что принято называть высокой доступностью и отказоустойчивостью системы.
Кластеризация и балансировка — это части общего подхода к разработке инфраструктуры программного обеспечения на основе облачных технологий Cloud Native. SimpleOne использует множество инструментов, причисляемых к технологиям Cloud Native — микросервисная архитектура, кластеризация, непрерывный сбор логов и метрик. В ближайших планах подключение дополнительных технологий, которые повысят не только отказоустойчивость, но и горизонтальную масштабируемость системы.
Читайте о том, как мы применяем подход Cloud Native при разработке платформы SimpleOne в нашей следующей статье «Зачем enterprise-системам Cloud Native?».
