Содержание
Современное развитие и возможности интернет-коммуникаций вынуждают бизнес подстраиваться под запросы общества в части доступности и качества не только самой продукции или предоставляемых услуг, но и процессов взаимодействия, их скорости и диапазона доступности: нужно всё и сразу, быстро и желательно в любое время суток и день недели.
Всё это приводит к тому, что увеличивается рабочий день не только сотрудников-представителей бизнеса, но и систем, в которых они работают и взаимодействуют как с клиентами и контрагентами, так и во внутренних бизнес-процессах (т.н. системах бекэнда). Простои сотрудников бекофиса могут приводить к неменьшим, а зачастую и бо́льшим издержкам для компании.
Так как же защитить свои системы от технических сбоев, не выдержавшего нагрузки сервера или человеческого фактора? В ход идут системы обеспечения отказоустойчивости и высокой доступности. В зависимости от требований конкретного бизнеса, процессы защиты систем имеют разные задачи и способы реализации. Давайте рассмотрим некоторые из основных практик в данном вопросе.
1. Резервное копирование
Самый дешевый и простой способ защитить свой бизнес от полной утери накопленных данных и критичных настроек. Золотое правило любого системного администратора (а в идеале — любого ИТ-грамотного специалиста): если ваша система или данные в ней регулярно меняются, значит она должна подвергаться регулярному же копированию.
Причем в зависимости от сложности, размера и критичности системы/базы данных применяются разные тактики выгрузки и хранения рез.копий: для важного Excel-файла с квартальным отчетом зачастую достаточно отправить его самому себе на почту или выгрузить на USB-флешку; для терабайтной распределенной базы данных с тысячами транзакций за короткий промежуток времени может потребоваться отдельная система выгрузки и хранения разностных (diff) копий как самой базы, так и происходящих в момент копирования транзакций в онлайн-режиме.
Самое главное тут: любая копия должна храниться в отдельном от самой «системы» месте. Чтобы в случае сбоя, отказа или случайного удаления всей папки или диска можно было «достать» последнюю актуальную копию, избежав максимальных потерь.
2. Кластеризация и отказоустойчивость
Для систем, которым критична скорость восстановления работы в случае сбоя, часто применяется политика «отказоустойчивого кластера» (failover cluster). Суть которой заключается в том, что сервер или программа управления данными развертывается на нескольких хостах (виртуальный или физический сервер, контейнер) одновременно, с идентичными настройками и, чаще всего, одинаковыми техническими характеристиками.
Часто эти системы объединяются в общий «кластер», в котором у его участников могут быть как равнозначные, так и второстепенные роли. Подключение клиентских соединений производится к одной, главной «ноде» этого кластера, которая выполняет роль «менеджера» кластера, распределяющей соединения между разными участниками кластера по своей настроенной логике либо работающей в едином числе, в то время как остальные хосты получают роль резервных систем.
Такие кластера могут выполнять сразу несколько функций: распределение и балансировка нагрузки, что позволяет разгружать ноды и снижает риск их отказа; а также позволяет организовать отказоустойчивость системы. В случае если один или несколько (но не все) участников кластера по какой-либо причине становятся недоступны, роль менеджера кластера на себя берет следующий по списку хост. Причем этот процесс может выполняться как вручную, администратором системы, так и в автоматическом режиме.
Это позволяет, во-первых, сократить возврат доступности системы для клиентских соединений с ней, что, в свою очередь, сокращает издержки бизнеса от простоя. Во-вторых, такая схема работы позволяет спокойно заниматься поиском причины сбоя и восстановлением отказавших участников кластера, в то время как сама система остается доступной для работы.
Примерами таких систем могут служить:
- Failover cluster Microsoft SQL;
- etcd и Patroni для PostgreSQL;
- VRRP (Virtual Router Redundancy Protocol) и Keepalived;
- отказоустойчивый кластер 1С и другие.
3. Системы организации высокой доступности
Данные вариации построения архитектуры систем очень похожи на предыдущий вариант отказоустойчивых кластеров с одной лишь существенной разницей: в системах высокой доступности (High availability) даже если у второй и последующих нод используется роль резервной, они не являются спящими.
То есть в таких системах все изменения данных, произошедшие в одной ноде, немедленно реплицируются на остальные ноды, а также реализован сервис контроля состояния и синхронизации репликации, консистентности узлов кластера, управления ролями.
В подобном варианте организации архитектуры системы даже в случае отказа любой ноды (или нескольких) кластера достаточно одной «живой» ноды, чтобы система не только продолжила работу, но даже не произошло разрыва соединений с ней, а значит и не терялись несохраненные действия пользователей. Это критично для документов на сотни или тысячи строк, которые ваш менеджер заводил в 1С в течение нескольких часов, или для взаимодействия с клиентами через веб-сайты, где они вводят какие-либо данные и очень не хотят делать это более одного раза.
Популярными примерами таких систем служат:
- Microsoft NLB (Network Load Balancing) для сервера IIS;
- BiHA от компании Postgres Pro;
- Microsoft AlwaysOn для MS SQL и другие.
Что выбрать
Таким образом, мы видим, что имеется масса различных вариаций построения архитектуры критически важных систем, и всё зависит от вашего желания, воображения и кошелька. Для каких-то систем высокая доступность критически необходима и жизненно важна, а для каких-то — избыточна. Самое важное тут — оценить как риски возникновения сбоя, так и его потенциальную стоимость для бизнеса. Но одно можно сказать точно: в вопросе сохранности данных и систем поговорка «скупой платит дважды» как нигде актуальна.