Облако как конструктор: разворачиваем типовой проект с готовыми компонентами

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

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

• Балансировщики — принимают клиентский трафик и распределяют его между серверами, выполняют SSL-терминирование.
• Приложение — отвечает за логику и обработку запросов.
• Файловое хранилище и СУБД — здесь приложение хранит свои данные.
• Кеширование — ускоряет загрузку часто используемых элементов.
• Логирование, мониторинг, резервное копирование — сопутствующие компоненты, которые обеспечивают надёжность системы.

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

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

Процесс развёртывания обычно состоит из стандартных шагов:

• Создание VPC, подсетей и других сущностей облака.
• Генерация или загрузка SSH-ключа.
• Развёртывание набора виртуальных машин.
• Назначение Elastic IP и групп безопасности.
• Подключение к ВМ, базовая настройка и установка обновлений.
• Подключение репозиториев, установка пакетов, настройка и запуск сервисов.
• Тестирование и автоматизация запуска.

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

1. Развёртывание с помощью инструментов автоматизации

Обычно этот процесс строится так:

• Terraform создаёт облачные ресурсы.
• Cloud-init устанавливает обновления и подключает репозитории.
• Puppet настраивает ПО на виртуальных машинах.

Все эти шаги объединены в CI-пайплайн и запускаются по нажатию кнопки. Перед его запуском требуется только собрать входные данные и внести их в систему контроля версий. Такой подход позволяет развернуть хоть 16, хоть 160 ВМ с одинаковой скоростью, так как Puppet работает параллельно. Развёртывание в среднем проходит за три часа.

2. Использование готовых компонентов облака.

Этот способ развёртывания инфраструктуры позволяет ещё больше ускорить процесс и упростить дальнейшее управление.

Для этого используем следующие компоненты:

Балансировщики

В 2023 году в K2 Cloud появился балансировщик нагрузки уровня L4, а в 2024 году — уровня L7. Последний поддерживает работу с TLS-сертификатами, позволяет настраивать веб-роутинг, перенаправляет трафик на разные серверы в зависимости от пути в URL.

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

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

Приложение

Этот уровень отвечает за работу приложений. Если приложение уже контейнеризовано, его можно запустить в Kubernetes. EKS (Kubernetes as a Service) в K2 Cloud позволяет развернуть полноценный кластер в одной или сразу трёх зонах доступности. Для тестов можно использовать упрощённый Kubernetes с одним мастер-узлом.

Облачный Kubernetes поддерживает автомасштабирование узлов (node autoscaling) и позволяет развернуть ingress-контроллер. Сертификаты Kubernetes в облаке обновляются автоматически, однако само приложение нужно настраивать вручную.

Файловое хранилище и СУБД

Для хранения данных в K2 Cloud используется Elastic File System (EFS) — разделяемая файловая система на уровне платформы, доступная по NFS 4.1. Она монтируется к разным виртуальным машинам, даже если они находятся в разных зонах доступности. Благодаря этому не нужно развёртывать отдельные NFS-серверы.

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

База данных

Выбор базы данных остаётся за архитектором приложения или командой разработки. K2 Cloud предлагает PaaS-базы MySQL, PostgreSQL, Redis и MongoDB в разных версиях. Например, MySQL предоставляется в трёх вариантах: MySQL Community Edition, MariaDB и Percona.

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

Кеширование

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

Если приложение не поддерживает работу с таким режимом Redis, то можно использовать Redis Sentinel. Для простых задач предназначен сервис Memcached. Сравнительно с Redis у него скудная функциональность, и он не поддерживает кластеризацию.

Логирование

Система централизованного логирования помогает анализировать события в случае аварии. Команда K2 Cloud разработала PaaS-сервис логирования на базе Elastic Stack. Он интегрирован с другими PaaS-сервисами, что позволяет собирать в ELK логи со всех сервисов.

Мониторинг

В K2 Cloud клиенты подключают сервис мониторинга на базе экосистемы Prometheus. В него входят Alert Manager и Grafana для визуализации. Благодаря сквозной интеграции с другими PaaS-сервисами можно включить мониторинг одной галочкой, автоматически настроить алерты и использовать предустановленные дашборды в Grafana.

Бэкап

Облачное резервное копирование выполняется на уровне гипервизора, что позволяет защитить всю виртуальную машину или отдельные диски. Бэкап выполняется по расписанию: первая копия полная, последующие — инкрементальные (incremental forever backup). Скорость создания инкрементальных бэкапов выше — в хранилище отправляются только новые данные. А при при восстановлении, каждая копия является полной и не требует восстановления цепочки копий. Хранилище для бэкапов изолированно от других систем, что повышает безопасность данных.

Не все проекты можно развернуть с помощью готовых компонентов. Например, PaaS-сервисы K2 Cloud на базе AlmaLinux могут не подойти тем, кому нужна сертифицированная отечественная ОС. В таких случаях лучше выбрать развёртывание с помощью инструментов автоматизации или вручную.