Как построить отказоустойчивый PaaS 1С и не сойти с ума

От On-Prem к PaaS: зачем бизнесу облачные платформы

Все мы привыкли к классической модели On-Premise, когда сервер стоит в собственной серверной, и вы отвечаете за все: от железа до софта.

Затем пришли облака. Сначала IaaS – инфраструктура как сервис: вы арендуете виртуальные машины, но все еще управляете операционной системой, приложениями, сетями и прочим.

Следующий шаг – это PaaS, платформа как услуга, где провайдер дает вам готовую среду для запуска приложений: кластеры баз данных, серверы приложений, балансировщики.

И наконец, SaaS – программное обеспечение как услуга. Это уже готовое приложение, например почта или CRM.

Почему бизнес все чаще выбирает PaaS?

Главная причина – он дает гибкость IaaS (вы управляете приложениями) и простоту SaaS (провайдер берет на себя инфраструктуру). Вы не заперты в коробку готового софта, но и не возитесь с железом и ОС. Из этого вырастают конкретные выгоды.

Снижение TCO – не нужно платить за администрирование серверов, не держать штат инженеров по железу.

Скорость – развернуть новую среду можно за минуты, а не недели.

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

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

На чем строить современный PaaS?

Теперь важный вопрос: на какой технологии строить PaaS для таких приложений, как 1С? Раньше платформы делали на «виртуалках» и ручных скриптах. Это работало, но было хрупким.

Сегодня де-факто стандарт для PaaS – Kubernetes. Не единственный инструмент, но он дает именно то, что нужно: автоматизацию, масштабирование, самовосстановление.

Но почему именно Kubernetes, а не просто Docker? Давайте разберемся.

Kubernetes: что это и зачем он нужен

Docker – это инструмент для запуска одного контейнера на одной машине. Если контейнер упадет – его никто не поднимет автоматически. Если нагрузка выросла – вы сами запускаете второй контейнер вручную.

Kubernetes (K8s) – это оркестратор. Он работает с целым кластером серверов и позволяет:

• запускать контейнеры там, где есть свободные ресурсы;

• автоматически перезапускать упавшие контейнеры;

• масштабировать их количество при росте нагрузки;

• обновлять версии без простоя (rolling update);

• обеспечить сетевое взаимодействие между контейнерами и подключает хранилища.

Для PaaS, где одновременно работают десятки или сотни клиентских кластеров 1С, ручное управление контейнерами невозможно. Нам нужна именно оркестрация. Поэтому мы выбрали Kubernetes.

Cloud Native принципы и почему 1С – это монолит

Cloud Native – это подход к созданию приложений, которые рождаются и живут в облаке. Он строится на нескольких принципах.

1. Микросервисная архитектура – приложение разбито на небольшие независимые сервисы.

2. Контейнеризация – каждый сервис упакован в контейнер со своим окружением.

3. Масштабируемость – можно легко нарастить мощность под выросший спрос.

4. Отказоустойчивость – система продолжает работать, даже если отказала ее часть.

5. Автоматизация CI/CD – настройка инфраструктуры, тестирование, развертывание новых версий делаются машинами.

6. Независимость от инфраструктуры – приложение не привязано к конкретному провайдеру или серверу.

Kubernetes реализует большинство этих принципов «из коробки». Поэтому для построения Cloud Native-платформы он – естественный выбор.

Но важно понимать: сама по себе 1С не становится Cloud Native-приложением, как бы мы ее ни контейнеризировали.

• Нет микросервисов – 1С это монолит.

• Контейнеризация не встроена – хотя мы научились ее делать сами.

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

• Отказоустойчивость частичная – кластер можно построить, но он не самовосстанавливается.

• Нет встроенного CI/CD – хотя это решается внешними инструментами.

• Зависимость от инфраструктуры – лицензии привязаны к железу.

Тем не менее, Kubernetes позволяет нам обойти многие из этих ограничений. Как именно – покажем дальше на примере нашей четырехуровневой архитектуры.

Четырехуровневая архитектура облака 1С

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

Самый нижний уровень – это Foundation, или базовый уровень. Он отвечает за фундаментальные элементы облачной среды: аккаунты и проекты, сетевую архитектуру, инфраструктуру, управление доступом, DNS.

Следующий уровень – платформенный. Он обеспечивает среду исполнения приложений: Kubernetes-кластеры, балансировщики нагрузки, сервисные аккаунты и toolchain Kubernetes-кластера.

Следующий уровень – Shared Services, или общие сервисы. Он предоставляет кросс-платформенные и общие сервисы: CI/CD-пайплайны, системы мониторинга, логирования, а также системы, обеспечивающие безопасность и требования комплаенса.

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

Решенные проблемы: автоматизация, мониторинг и отказоустойчивость

А теперь поговорим о некоторых проблемах, которые мы смогли решить с помощью Kubernetes.

Первое и самое основное – это, конечно, создание кластера. Благодаря контейнеризированному подходу создание нового кластера 1С занимает буквально несколько минут.

Но самое главное – не это. Kubernetes постоянно мониторит состояние основных процессов кластера 1С, сетевую доступность между компонентами кластера и в случае проблем самостоятельно их исправляет.

Мониторинг. Мы используем связку Thanos+Prometheus + Grafana для сбора метрик. Но главное – эти метрики не просто для «красивых графиков». На основе них Kubernetes (через операторы и контроллеры) автоматически принимает решения: перезапустить процесс, добавить ресурсы, увеличить диск. Так что человек смотрит на Grafana скорее для общей картины, а основную работу делают автоматы.

Например, автоскейлинг дисков в кластере 1С. Когда система мониторинга видит, что количество занятого пространства на диске доходит до 80%, она автоматически увеличивает емкость диска, предотвращая его заполнение на 100%. Это реализовано через специальный контроллер, который следит за метриками PV и по достижении порога изменяет размер PVC.

Почему это чревато? Потому что если диск заполнен на 100%, кластер переходит в read-only-режим, и его потом очень сложно восстановить.

Планируемые улучшения: логи, метрики и удаленный конфигуратор

Также хочу поделиться некоторыми нашими предстоящими нововведениями, или фичами.

Во-первых, это логи технологического журнала в сервис «Логи». Сервис «Логи» – это единая платформа в нашей компании, предназначенная для сбора логов из наших платформенных продуктов.

Сейчас мы включаем технологический журнал для наших клиентов по запросу: через тикет просто включаем или выключаем его и передаем логи в файловом формате. После этого наши клиенты смогут самостоятельно через панель управления включать и выключать технологический журнал со своим конфигом. Например, смогут направлять свой Fluent Bit на нашу точку и собирать свои ELK-stack-логи.

Метрики Prometheus – аналогично. Помимо того, что мы сами следим за состоянием кластеров, мы хотим предоставить клиентам те же самые метрики, чтобы они могли настроить их в своей Grafana.

И еще одно направление – удаленное рабочее место. В настоящее время основной способ подключения к 1С – это тонкий клиент либо веб-клиент через HTTP. Но, естественно, конфигуратор тоже всем нужен. Если подключаться с локального компьютера, то из-за большой сетевой задержки работа с конфигуратором может становиться крайне некомфортной. Поэтому мы обычно советуем поднимать виртуальную машину рядом, ставить на нее конфигуратор и уже там работать.

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

Итоги

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

• создание нового кластера 1С за минуты;

• автоматическое восстановление отказавших компонентов;

• масштабирование ресурсов (диски, CPU, память) без участия человека;

• единую платформу мониторинга и логирования для всех клиентов.

Да, Kubernetes сложен. Но для построения отказоустойчивого PaaS это оправданная сложность.

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.