У многих компаний 1С работает в Yandex.Cloud — это удобно, снижает инфраструктурную нагрузку на собственные вычислительные мощности. Но у каждого решения есть проблемы, которые уменьшают эффективность, а соответственно лояльность и удовлетворённость пользователей. Когда речь идёт об 1С в Yandex.Cloud, жизнь сильно осложняет резервное копирование.

Яндекс предлагает не автоматизированный вариант - делать снапшоты виртуальных дисков, но сделать backup виртуальной машины как объекта Yandex Cloud на текущий момент не позволяет. Нам было важно автоматизировать этот процесс, снизить количество рутинных операций, создать возможность гибкой настройки прав. В дальнейшем мы планируем применять решение для себя, а затем у своих клиентов, масштабировать и настроить его под их конкретные задачи. 

Уже сейчас у нас есть заказчики, у которых мы хостим 1С в YandexCloud, где упрощённый бекап остро необходим. Поэтому мы разработали решение, которое автоматизирует процессы, доступные в Yandex.Cloud в ручном режиме. Вендор анонсировал схожие функции, упрощающие жизнь при резервном копировании, но пока они не доступны пользователям. Между тем, спрос на них уже есть. Иными словами, основная цель проекта — дать пользователю удобное решение, которое исключает “танцы с бубном”, связанные с бэкапом 1С работающей в Yandex.Cloud, включая виртуальные машины. В настоящий момент мы готовим решение к запуску.

Проблемы

Настройка расписания 

Для заказчиков и для нашей компании мы используем управляемые базы данных PostgreSQL. База управляется Yandex.Cloud. Проблема состоит в том, что инструмент резервного копирования, доступный из коробки как сервис, неудобен. Он ограничен в настройках, вплоть до того, что его нельзя отключить, а кроме времени проведения бэкапа, можно настроить только желаемый период хранения от 7 до 60 дней - и всё. Более того, бэкап происходит ежедневно. Нет гибкого расписания. Например, если нужно хранить 4 еженедельные копии и 12 ежемесячных, то реализовать такое стандартным средством бэкапа от вендора пока невозможно. 

Неизбирательность восстановления

Для сервера баз данных в Yandex Cloud используем сервис Managed PostgreSQL — полуинтегрированное с YandexCloud решение, которое само разворачивает кластер, управляет его обновлениями, масштабированием, снижает затраты на администрирование, выступая в роли своеобразного сервиса. Когда речь идёт об 1С и использовании баз данных Postgre, то восстановление при помощи нативного  инструментария Yandex.Cloud возможно только целым кластером. 

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

Права доступа 

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

Все решения предполагают установку агента на хостинг, где работает СУБД. Такой хост фактический “черный ящик”  Во многом это также побудило к созданию более гибкого инструмента резервного копирования. Очевидным стал вопрос о гибкости инструмента и его способности более экономно и эффективно расходовать ресурсы.

Отсутствие уведомлений о значимых событиях 

Штатные средства не позволяют отправлять уведомления о значимых и критических событиях, что, как мы знаем из опыта, замедляет реакцию на них. 

В сухом остатке 

По сути, решение для бэкапа существует, оно даже снижает нагрузку на администрирование, но как и большинство других “коробочных” инструментов не  способно удовлетворить конечных запросов многих наших заказчиков. Кроме того, коробочное решение от вендора пока не поддерживает нативной интеграции с “чистым” PostgreSQL. 

Что мы уже сделали

Решение, которое мы предложили своим клиентам с 1С на Yandex Cloud, помогло справиться со следующими задачами:

• резервное копирование баз данных и файловых данных с серверов 1С;

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

• возможность гибкой настройки времени проведения бекапа и длительности хранения резервных копий; 

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

Инструменты реализации и график бекапа

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

Уведомления

Кроме того, появляется возможность получать уведомления об успешном или прерванном резервном копировании. Иными словами, мы привязались к Jenkins, как к промежуточной системе. позволяющей реализовать те функции, которых не было в нативном инструментарии из коробки и использовали его в качестве своеобразного шедулера. 

Хранение 

Для хранения резервных копий мы решили использовать в Yandex Cloud S3 object storage, как в наиболее бюджетной защищенной распределенной файловой системе. Кроме того, мы реализовали возможность записывать логи ошибок и вести учет успешного запуска и создать ручной интерфейс управления резервными копиями, позволяющий их запускать и восстанавливать. 

Виртуальные машины 

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

Другие функции

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

Настройка прав пользователей и их ограничений 

В Jenkins были созданы различные уровни доступа в зависимости от роли пользователя. Сетка прав настраивается при помощи “матрицы пользователей”. Сейчас с её помощью можно делегировать права на одну конкретную виртуальную машину или базу данных, а также на конкретные действия. 

Например, при необходимости конкретному сотруднику можно делегировать права на запуск и остановку виртуальной машины в облаке. В Yandex Cloud - это может быть сервисный аккаунт с более широкими возможностями, но пользователь к этим функциям доступа не получит.

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

Преимущества решения

Часть задач, которые стоят перед этим решением сервис инженер может выполнить вручную. Например написать что-то в консольной утилите Yandex Cloud. Но для этого нужны дополнительные знания и права на стороне облака. У Yandex Cloud есть специальный курс, который позволяет получить подготовку и сертифицироваться по их стандарту. 

Нашим сертифицированным архитекторам, чтобы пройти этот курс и сдать экзамены, понадобилось до 3-х недель, у обычного сотрудника техподдержки с техническим образованием на такое обучение уходит от 2-х до 3-х месяцев. И мы говорим о минимальном пуле знаний для работы с Yandex Cloud, не архитектурных, достаточно поверхностных знаний, т.е. знакомство с функциями, инструментами и получение представления о том, как ими пользоваться. Инструмент, который предлагаем мы, специалист без технического образования может освоить за 3 недели непрерывного обучения. В практике был случай, когда для работы с ним учились люди с бэкграундом сейлз-менеджера. 

Перспективы и масштабирование

Проект позволяет использовать его не только для 1С, но также для любых управляемых баз данных в Yandex Cloud. В следующей версии мы попробуем адаптировать решение для других систем. Существует возможность интеграции с service desk предприятия и мы также планируем реализовать его, чтобы ещё быстрее обрабатывать события. Мы обязательно напишем об этом на Хабре. Традиционно будем признательны за комментарии и вопросы об этом кейсе.