Обеспечение высокой доступности и отказоустойчивости Comindware Business Application Platform

Введение

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

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

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

Достигаемый уровень доступности

Comindware Business Application Platform использует в качестве распределённого хранилища данных ПО Apache Ignite. Благодаря поддержке распределённых вычислений и хранения данных Apache Ignite обеспечивает высокий уровень доступности и отказоустойчивости. Поэтому система может оставаться доступной даже при отказе отдельных узлов. Встроенные механизмы репликации данных и автоматического восстановления позволяют достигать уровня доступности до 99,99% (время простоя не более 52 минут в год).

Для достижения таких показателей, например, можно использовать кластерную конфигурацию с балансировкой нагрузки, резервированием компонентов и регулярным мониторингом состояния системы. См. пример настройки простейшего кластера Comindware Business Application Platform и рекомендации по кластеризации в документации Apache Ignite (на английском языке).

Способы повышения доступности и отказоустойчивости

Высокая доступность и отказоустойчивость являются ключевыми аспектами при развёртывании критически важных систем. Для Comindware Business Application Platform их можно обеспечить с помощью следующих механизмов и подходов:

Резервирование компонентов: дублирование критически важных компонентов, таких как серверы приложений, баз данных и журналирования. Это позволяет системе продолжать работу в случае отказа одного из компонентов.
Балансировка нагрузки: использование балансировщика нагрузки (например, NGINX) для распределения входящих запросов между несколькими серверами приложений. Это повышает не только производительность системы, но и её устойчивость к отказам.
Географическое распределение: размещение компонентов в разных географических зонах для защиты от локальных сбоев и катастроф. Это особенно важно для крупных организаций с глобальной инфраструктурой.
Горизонтальное масштабирование: добавление новых узлов для увеличения производительности и отказоустойчивости. Это позволяет системе выдерживать растущую нагрузку по мере роста количества обрабатываемых данных, транзакций и пользователей.
Мониторинг и оповещение: внедрение систем мониторинга (например, Zabbix) для отслеживания состояния всех компонентов и своевременного оповещения администраторов о возможных проблемах. Это позволяет оперативно реагировать на инциденты и минимизировать время простоя.
Резервное копирование и восстановление: регулярное создание резервных копий данных, конфигурации системы и снимков инфраструктуры, например снимков виртуальных машин и полных резервных копий БД с прикреплёнными файлами. Резервные копии рекомендуется хранить в отдельном внешнем хранилище. В случае критического сбоя эти меры позволяют быстро восстановить работоспособность системы с минимальными потерями данных. См. «Резервное копирование. Настройка и запуск, просмотр журнала сеансов».

Определение уровня критичности проектируемой системы

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

При выборе уровня критичности информационной системы следует учитывать следующие факторы:

Характер задач: оцените, насколько система критична для выполнения основных бизнес-процессов и соблюдения обязательств перед клиентами.
Последствия простоя: определите возможные финансовые, имиджевые и операционные потери.
Требуемое время восстановления (RTO) и допустимые потери данных (RPO): чем короче RTO и RPO, тем выше требования к резервированию и инфраструктуре.

Классификация информационных систем по уровням критичности

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

Уровень 1 — Жизненно важные системы (Mission Critical) Системы с режимом работы 24х7х365, даже кратковременный отказ которых делает невозможным выполнение ключевых функций организации и приводит к невосполнимым потерям или штрафным санкциям. Рекомендации:
- Время восстановления — менее 10 минут.
- Полное многократное резервирование всех компонентов.
- Использование специализированных серверов.
- Применение кластеризации и балансировки нагрузки.
- Использование инфраструктурных решений с удалёнными и распределёнными ЦОД
Уровень 2 — Критически важные системы (Business Critical) Системы с режимом работы 24х7х365, для которых допустим краткосрочный простой, но длительный вызывает значительные финансовые или имиджевые потери. Рекомендации:
- Время восстановления — до 2 часов.
- Применение кластерных решений.
- Частичное резервирование компонентов.
Уровень 3 — Системы операционной деятельности (Business Operational) Системы с режимом работы 8х5, которые поддерживают внутренние бизнес-процессы организации, простой которых в течение нескольких часов создаёт неудобства, но не оказывает существенного влияния на обслуживание клиентов или ключевые операции. Рекомендации:
- Время восстановления — 4–6 часов.
- Полное резервирование хранения данных.
- Частичное резервирование компонентов.
Уровень 4 — Системы общего назначения (Office Productivity) Системы, используемые для повседневной офисной работы, простой которых даже в течение нескольких дней не оказывает существенного влияния на уровень обслуживания других систем. Рекомендации:
- Время восстановления — 1–2 рабочих дня.
- Использование типовых мер резервного копирования данных.
- Частичное резервирование компонентов.

Проектирование архитектуры системы

Фактическую продуктивную архитектуру системы следует определять в рамках разработки ТЗ с учётом всех технических и бизнес-факторов.

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

Определите, какие показатели наиболее важны для бизнеса, а также их приоритетность:
- производительность;
- устойчивость;
- горизонтальное масштабирование;
- географическая распределённость;
- RTO (Recovery Time Objective) — время восстановления после сбоя;
- RPO (Recovery Point Objective) — допустимый объём утраченных данных после сбоя.
Определите техническую и экономическую целесообразность достижения и поддержания целевых показателей.
Определите стоимость реализации — чем выше требуемый уровень надёжности и доступности системы, тем выше расходы на его достижение.
Выберите архитектуру системы в зависимости от выявленных целевых показателей и бизнес-задач. Используйте один из следующих подходов или их сочетание:
- Обеспечение отказоустойчивости
  - Имеется два или более узлов, из которых один является рабочим, а остальные резервными. Также предусмотрены сервер хранения данных и балансировщик нагрузки. ПО работает бесперебойно, пока сохраняют работоспособность один узел и сервер данных. Показатели RTO/RPO можно свести к минимуму. Так как на сервере данных хранятся актуальные данные, их достаточно для восстановления работоспособности узлов после сбоя.
- Распределение нагрузки
  - Имеется два или более узлов, сервер хранения данных и балансировщик нагрузки. Нагрузка равномерно распределяется между узлами, что сокращает время отклика. На сервере данных хранятся наиболее актуальные данные. ПО работает бесперебойно, пока сохраняют работоспособность все узлы кластера и сервер данных. При равномерной нагрузке время отклика можно рассчитать по формуле: Y/N+ε, где Y — время отклика при нагрузке только на один узел, N — количество узлов, ε — погрешность. Так как на сервере данных хранятся актуальные данные, их достаточно для восстановления работоспособности узлов после сбоя.
- Обеспечение высокой доступности
  - Имеется два или более узлов, сервер хранения данных и балансировщик нагрузки. ПО работает бесперебойно, пока сохраняет работоспособность хотя бы один узел и сервер данных. Даже при наличии постоянной нагрузки на балансировщике возможно выполнить поочерёдное обновление каждого из узлов до новой версии ПО. Так как на сервере данных хранятся актуальные данные, их достаточно для восстановления работоспособности узлов после сбоя.
Определите способ реализации выбранных подходов к обеспечению доступности и отказоустойчивости, например, с использованием кластеризации, контейнеризации и оркестрации или иных методов и инструментов. При выборе следует учитывать определённые ранее показатели, потребности, цели и возможности.

Практики, которых следует избегать

Для обеспечения оптимальной производительности, минимизации рисков простоев и повышения надёжности, доступности и отказоустойчивости Comindware Business Application Platform рекомендуется избегать следующих подходов:

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