Инфраструктура

Необходимо понимать, что сервисы Ensi не могут работать без управления. Будь то отдельно PIM, OMS, CRM — все они контейнеризированы и нуждаются в установке на кластерной платформе. А ещё бы хотелось иметь легкую масштабируемость, резервирование, возможность постоянного обновления, непрерывную интеграцию, полное взаимодействие из коробки между сервисами и легкость управления всем этим. Поэтому мы предлагаем строить решение на платформе Kubernetes.

Kubernetes — это портативная расширяемая платформа с открытым исходным кодом для управления контейнеризованными рабочими нагрузками и сервисами, которая позволяет параллельно запускать множество задач, распределённых иногда по тысячам приложений и сервисов, расположенных на различных кластерах (публичном облаке, собственном датацентре, клиентских серверах и т. д.). Вот именно поэтому, когда рассматривается вопрос размещения, мы заранее говорим, что размещать мы будем именно Kubernetes, а не сервисы Ensi. Поэтому и требования к датацентрам выставляются с учетом требований Kubernetes, а не сервисов Ensi.

Kubernetes изначально построен по технологии резервирования, по принципу master-slave, когда ведущим элементом является подсистема управления кластером, а некоторые компоненты управляют ведомыми узлами. Под узлом (node) понимается физическая или виртуальная машина, на которой работают контейнеры приложений. Каждый узел в кластере содержит инструменты для запуска контейнеризированных сервисов. Управление подами реализуется через API Kubernetes, интерфейс командной строки (Kubectl) или специализированные контроллеры.

Классический Kubernetes (k8s) построен с учетом резервирования и отказоустойчивости, когда в случае падения управляющего узла (master) кластер может переключиться на другие. То же самое касается и рабочих станций (slave), в случаях падения которых, сервисы спокойно переразвернутся на других узлах. Такое поведение сводит к минимуму время ожидания и практически не приводит к падениям на критических структурах. Однако это подразумевает и некоторую избыточность, что нередко оказывается в проигрыше в денежном эквиваленте, так как требует больше ресурсов, которые предоставляют датацентры.

Существуют и более легковесные решения, у которых есть минус резервирования, но технология работы не меняется. Например, Rancher (k3s). Rancher — это полностью совместимый дистрибутив Kubernetes, только построенный без учета резервирования. Его можно расположить даже на одном мощном физическом либо виртуальном сервере, который будет точно так же отлично работать. Конечно, в случае падения сервера данные могут быть потеряны, но в некритических системах либо в условиях жесткой экономии это вполне рабочее решение.

К рассмотрению мы рекомендуем оба варианта, однако если важна устойчивость проекта, велика его значимость для бизнеса, то вывод напрашивается сам собой: необходимо строить Kubernetes с учетом резервирования, хотя это и будет стоить дороже. И в первом случае полноценного Kubermetes (k8s) и в случае легковесного Rancher (k3s) необходимо только относительно правильно рассчитать мощности, нужные для запуска платформы Ensi с учетом нагрузок и возможного роста.

Работа всех приложений платформы Ensi подразумевает взаимодействие с изображениями, импортами и различными файлами, требующими использовать большой объём контентной информации. Поэтому в обязательном порядке необходимо использовать файловое хранилище, на котором будут физически располагаться файлы. Если инфраструктура не позволяет использовать готовое хранилище, например NetApp, мы предлагаем использовать файловую систему CEPH, которая изначально избыточна, масштабируемая и надежная. Она легко строится, к примеру, на трех баре-металл серверах, не требует специальных систем либо дисков, однако сильно зависима от локальной сети. Поэтому для CEPH имеет смысл определить в требованиях достаточно быструю сеть, отдельно для кластера 10−16 Гбит/сек и отдельно 10 Гбит/сек для работы с Kubernetes. CEPH так же легко масштабируется путем добавления дисков (OSD), поэтому начать работу можно на минимально необходимых размерах хранилища.

Следующий момент, который необходимо учитывать при развороте сервисов и платформы Ensi, это расположение серверов баз данных и поиска. Наша рекомендация, подчеркнутая долгим опытом эксплуатации: сервера БД Postgresql и Elasticsearch однозначно выводятся из кластера и ни в коем случае не разворачиваются в Kubernetes. Только в виде отдельных серверов (сервисов), на быстрых SSD-дисках, желательно реплицируемых, и опять же желательно не на сетевых хранилищах. Что касается сервисов Elasticsearch, то для них нужно организовать кластер как минимум из трех серверов (master и два slave) для уменьшения отказа. Хотя при незначительных нагрузках вполне работоспособно решение и на одном сервере.

Что касается серверов Postgresql БД, то тут тоже желательно организовать кластера с репликацией (master-slave), при том, что в коде платформы учитывается, что SELECT-запросы на идут на сервере slave, а UPDATE- INSERT на сервера master. Этим мы достигнем максимума производительности.

Как best practice для облегчения управления платформой Kubernetes и CI/ CD в контуре кластера в виде небольшой по мощности виртуальной машины разворачивается так называемый админ-сервер, на котором устанавливаются компоненты, необходимые для управления и успешного разворота: kubectl, cephadm, helm, docker и git, там же проще проводить сборку и интеграцию проекта через установленные Jenkins и helm.

Классическая схема еком-проекта из существующего кейса Greensight:

В сервисной инфраструктуре нет понятия «Сайзинг», но есть определенные параметры, которые возможно рассчитать. Например, какое количество запросов пойдет на каждый сервис, каков процент от общего трафика обработает то или иное приложение. Отсюда можно будет судить об общей нагрузке на сервисы платформы, которые будут находиться в кластере. И далее, по предварительным нагрузочным тестам, уже можно будет составить общую картину нагрузки и возможностей приложений. А так как Kubermetes легко масштабируемая платформа, то увеличение его ресурсов не занимает много времени и является вполне стандартной процедурой.

Для резервирования и отказоустойчивости критических бизнес-процессов мы рекомендуем использовать классический Kubernetes (k8s). В схеме используются 3 master node и 3 worker node. Это 6 физических либо виртуальных серверов, соединенных в единую локальную сеть, называемую «кластер». Общее количество ресурсов, необходимых для создания кластера, указано в следующей таблице:

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

Ceph — облачное отказоустойчивое файловое хранилище (Cloud Storage). Кластер Kubernetes использует хранилище для записи данных, запуска сервисов и обработки медиафайлов.

Elasticsearch — высоконадежная и высокопроизводительная поисковая система, которая используется проектом для индексации и организации релевантной поисковой выдачи.

PostgreSQL в режиме master-slave обеспечивает высокоскоростной доступ к базам данных сервисов приложения.

Kafka Apache — распределенная система обмена сообщениями между серверными приложениями в режиме реального времени. Благодаря высокой пропускной способности, масштабируемости и надежности применяется в системах, работающих с большими объемами данных.