Сейчас мы, в Postgres Professional, разрабатываем новый интересный продукт — DataBase as a Service, и в этой статье хочется немного рассказать о наших успехах, узнать ваше мнение и послушать возможные пожелания. 

Но перед тем как говорить про возможности, нужно договориться что вообще такое DBaaS и что мы тут делаем. Больших новостей не будет: DBaaS — это подвид as a service услуг, который сосредоточен на избавлении администратора от болей, связанных с администрированием баз данных. В нашем случае речь пойдёт о PostgreSQL.

Если попытаться формализовать, то в классическом «я сам всё умею и могу» подходе, чтобы обзавестись работающей БД, надо пройти примерно такой путь: настроить железный сервер, накатить и настроить ОС, установить СУБД со вспомогательными пакетами, затем всё это дело сконфигурировать и наконец-то начать работать. Спустя некоторое время, а лучше сразу, придёт осознание необходимости выстроить политику резервного копирования, гибкую систему доступов и поддержания версий софта в актуальном состоянии. И где-то совсем нескоро надо задуматься ещё и о масштабировании всей этой конструкции, ибо тема эта для баз данных не самая лёгкая, и многие её старательно откладывают до последнего.

Естественно, всего этого хочется по максимуму избежать. Поэтому, абсолютно ожидаемо, инженеры придумали простую идею: дадим пользователю ту самую большую красную кнопку «Сделать хорошо», а все операции, связанные с развёртыванием и обслуживанием баз данных, мы от него скроем и автоматизируем.

Поэтому свой DBaaS мы решили делать с расчётом на то, что он будет запускаться в публичных и приватных облаках. Но, как мы все понимаем, с уходом всем известных вендоров список сильно подсократился.  А из приватных, по факту, остались только облака на OpenStack. Так что упор в разработке мы делаем именно на него.

Немного терминологии

Чтобы говорить о DBaaS, надо договориться что и как называется. Чтобы не было историй, когда у одних нода – это физический сервер, а у других — логическая сущность. 

Устроен DBaaS достаточно просто. Это некая машина, где работает сам DBaaS-сервис, к которому подключаются клиенты по API или через веб-интерфейс. Далее DBaaS создаёт виртуальные машины, устанавливает на них своего управляющего агента и разворачивает базу данных согласно запросу клиента.

 И теперь те самые термины, которые наиболее часто вызывают путаницу:

• База данных — мы поддерживаем и разрабатываем решение для PostgreSQL. Так уж получилось, что занимаемся мы именно постгресом и работаем только с ним.

• Инстанс — виртуальная машина, на которой запущена одна или несколько баз данных. То есть в рамках инстанса СУБД запущена одна, но внутри данного одного приложения постгреса может быть запущено несколько баз данных.

• Кластер — отказоустойчивая группа инстансов. Тут всё достаточно прозрачно, но надо оговориться, что у кластера может быть вырожденный случай, когда он состоит из одного инстанса. Этакий псевдокластер.

• Проект — логическая единица нашего DBaaS для управления группами кластеров. У проекта есть владелец, который создаёт внутренних пользователей и наделяет их правами доступа.

Итого, в рамках одного проекта может быть несколько кластеров. В каждом кластере может существовать один или несколько, инстансов. И в каждом инстансе работают базы данных.

Про имеющийся функционал

Работа с DBaaS начинается с создания проекта, внутри которого уже будут разворачиваться необходимые кластера и пользователи. Кластер можно сделать как с одним инстансом, так и отказоустойчивый. То есть будет создана нода с мастером и слейвы (один синхронный, другие асинхронные). За автоматическое переключение, в случае отказа мастера, отвечает Patroni, но функционал ручного переключения также имеется.

По возможностям конфигурации все самые ожидаемые вещи имеются. Можно динамически менять выделенные инстансам мощности, включая размер дисков. Теоретически можно даже на ходу изменить количество процессоров, но это приведёт к перезагрузке ноды. Это особенность OpenStack. И, что удобно, конфигурировать можно как всех участников кластера разом, так и отдельные инстансы.

Расскажу про управление расширениями. Конечному пользователю не отдаются права владельца баз данных, поэтому если расширение требует их для установки, то сделать это можно только через DBaaS.

Если такие права не нужны, пользователь может установить расширение самостоятельно. Создание пользователей и назначение им прав также производится через DBaaS.

И раз мы затронули тему учётных записей, то сейчас будет немного про их создание, авторизацию и аутентификацию. Поскольку мы изначально целились в частные облака, основным провайдером авторизации стал LDAP. С точки зрения реализации альтернатив, сложностей не наблюдается, просто он стал первым.

Пользовательская ролевая модель иерархическая. Есть всемогущий Администратор DBaaS, который управляет всем, в том числе и квотами ресурсов на проекты. Квотируются CPU, RAM и размер выделенного диска. При превышении квоты блокируется создание новых кластеров и добавления инстансов.

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

Касательно резервирования, DBaaS умеет создавать дампы (логические копии) и классические бекапы (физические копии). Их отличие в совместимости: сделав логическую копию на 14-й версии постгреса, её можно восстановить на 15-й. С физической так не получится, но у неё есть своё важное преимущество — восстановление на определённый момент времени, вплоть для конкретной транзакции.

Оба вида резервных копий хранятся внутри S3, которое уже есть в облаке. Это позволяет нам очень быстро сохранять их и так же быстро восстанавливать. Причём из дампа можно восстановить всё сразу или выбрать между восстановлением только данных или схемы.

А что касается бекапов, то для них доступны гибкая настройка расписания и политики хранения. Также есть возможность делать непрерывный бекап с архивированием журнала предзаписи, более известные как WAL-логи.

А на сладкое пусть будет вкладка Events, где в удобном виде и с массой фильтров хранятся все значимые события в рамках проекта. Детализация ведётся вплоть до инстанса, а события ранжируются по важности. Соответственно, теперь в одном месте можно узнать когда, почему и какая нода поменяла свой статус репликации, кто стал лидером, откуда появилась новая база и так далее. Событий логируется много и полный список будет в документации.

И самое интересное — как этим роскошеством можно управлять. Изначально мы подошли к этому вопросу как истинные разработчики и реализовали свой API, через который доступна любая возможная операция в DBaaS. Чуть позже был сделан web-интерфейс, стремительно развивающийся в своих возможностях. А из интересного мы реализовали terraform провайдера, позволяя создавать проекты в классическом infrastructure as a code подходе декларативного описания.

И небольшое видео с демонстрацией DBaaS вживую. Записано оно было полгода назад и какие-то моменты изменились (например, появилась возможность управлять табличными пространствами), но все основные функции там показаны.