Первые шаги: облачный
В 2018 году, когда мы приступили к развертыванию DSE одним нажатием кнопки, операторы Kubernetes только начинали набирать популярность, а операторы, специфичные для Apache Cassandra, находились в стадии предварительной альфа-версии. Поэтому мы решили придерживаться того, что знали, а именно виртуальных машин в облаке.
В базовом случае нам нужен кластер DSE с тремя узлами и небольшой кластер Kubernetes для запуска вспомогательных служб для базы данных. Из-за знакомства с платформой наш первый набег на все был на AWS. Мы приступили к созданию сценариев Terraform для предоставления экземпляров EC2, томов EBS и соответствующей сети. Это должна была быть автоматизированная система, работающая по нажатию кнопки, поэтому мы разработали сервис Golang для вызова Terraform из запроса REST, который также выполнял достаточное количество шаблонов для поддержки различных размеров баз данных и регионов.
Поскольку подготовка инфраструктуры занимает некоторое время, мы, очевидно, не могли заставить наших клиентов ждать, пока мы закончим, поэтому этот процесс должен был быть асинхронным. Для этого мы выбрали Argo в качестве механизма рабочего процесса, что позволило нам разбить подготовку инфраструктуры на несколько этапов, которые при правильном выполнении можно было бы легко повторить в случае сбоя. К этому моменту мы автоматизировали подготовку инфраструктуры, хотя это было не очень интересно, поскольку еще ничего не было развернуто.
После завершения Terraform мы смогли запустить еще один рабочий процесс для приведения базы данных в пригодное для использования состояние. Чтобы ускорить процесс, мы использовали пользовательские образы машин для создания инстансов EC2, которые содержали архив DSE и необходимые сценарии запуска.
При запуске узлов DSE важен порядок: если бы вы делали это вручную, вы бы запустили первый узел, подождали, пока он не заработает, установили начальное значение на втором IP-адресе первого, запустили второй узел и скоро. Поскольку наши узлы запускались в случайном порядке, мы не могли гарантировать такое поведение. Это означало, что нам пришлось создавать собственный механизм блокировки и координации для узлов по мере их запуска. Поскольку первоначальный запуск DSE выполнялся с помощью образа машины, наш рабочий процесс мог затем перейти к окончательной настройке и настройке, а также к развертыванию служб в небольшом кластере Kubernetes.
Некоторое время этот процесс работал у нас хорошо, но вскоре у нас начались проблемы. С самого начала мы заметили, что создание новой базы данных занимает до часа, что имеет смысл, учитывая, что мы выделяем шесть инстансов EC2 (около 45 минут) вместе с другой необходимой инфраструктурой. Еще одна проблема, с которой мы столкнулись, — это повторяемость. Этот метод создания баз данных оказался не очень надежным, поскольку мы использовали очень много элементов инфраструктуры, и нашим сценариям приходилось обрабатывать все. Например, если том EBS не был правильно подключен, наши скрипты должны были обнаружить это, а затем решить проблему самостоятельно. Это стало еще сложнее, когда мы представили новые рабочие процессы для добавления дополнительных узлов в базу данных.
После бета-тестирования мы обнаружили, что тратим слишком много времени на ручные исправления, и, наконец, поняли, что стоимость этой архитектуры несостоятельна. К счастью, к этому моменту наш собственный оператор Kubernetes, cass-operator, добился достаточного прогресса, чтобы его можно было развернуть для использования в рабочей среде.
DataStax — это открытый мультиоблачный стек для современных приложений для работы с данными. DataStax предоставляет предприятиям свободу выбора, простоту и подлинную облачную экономику для развертывания больших объемов данных, доставляемых через API, обеспечивая эффективное взаимодействие в мультиоблачных средах, с открытым исходным кодом и Kubernetes.
Состав решения
ПАК полностью состоит из компонентов отечественного производства – серверов линейки Яхонт-УВМ на российской платформе Эльбрус-8С под управлением операционной системы Astra Linux Special Edition и российского программного обеспечения. В состав ПО входят серверы ввода-вывода, система анализа режимов сети, а также сервер приложений КОТМИ-14, который позволяет создавать как автономные локальные системы управления, так и централизованные системы, автоматизирующие работу сразу нескольких связанных центров, с обеспечением единого информационного пространства и резервирования.
Релиз ОС Astra Linux Special Edition, используемый в данном ПАК, был специально разработан для вычислительных комплексов с процессорной архитектурой «Эльбрус» и успешно прошел сертификацию по требованиям безопасности информации ФСТЭК России к операционным системам типа «А» 2-го класса защиты и требованиям безопасности информации ФСБ России к СЗИ.
- Сервер приложений выполняет основные функции, необходимые как для работы комплекса в целом (обслуживание клиентских подключений, доступ к базам данных и объектам комплекса, генерация и обработка событий, резервирование данных, расчеты, топологический процессор).
- Сервер ввода-вывода КОТМИ-RDX выполняет функции сбора и ретрансляции данных телеметрии по различным протоколам.
- Система анализа режимов сети (САРС). Обеспечивается автоматическое формирование расчетной модели (узлы-ветви), запуск необходимых приложений с заданным циклом или по событиям изменения положения коммутационных аппаратов. Для целей моделирования сети имеется АРМ аналитика-режимщика, позволяющий работать как с результатами расчетов online, так и с библиотекой сохраненных режимов.
Впервые ПАК был продемонстрирован на базе учебного комплекса ПАО «Россети Ленэнерго» в период с 20 по 24 сентября 2021 года на совместном стенде компаний-разработчиков ПАК.
