← На главную
Переход на работу с базами 1С в облачной инфраструктуре вызывает множество вопросов у технических специалистов и администраторов. Разберем ключевые различия между моделями предоставления сервиса, архитектуру мультитенантности на примере сервиса 1С:Фреш, а также типовые сценарии администрирования: работу с пользователями, создание резервных копий, перенос данных в тестовый контур и регламент обновлений.
Модели облачного развертывания: SaaS (1С:Фреш) против IaaS/PaaS (Аренда сервера)
Для понимания принципов администрирования разделим облачные варианты на две принципиально разные категории:
- Публичный SaaS (сервис «1С:Предприятие через Интернет» / 1С:Фреш): Пользователь получает доступ к готовому программному продукту через браузер или тонкий клиент. Физическая база данных и серверная инфраструктура находятся под управлением провайдера, а изоляция клиентов обеспечивается встроенным механизмом платформы — разделением данных (мультитенантность).
- Аренда виртуального сервера (VDS/IaaS): Клиенту предоставляется выделенная виртуальная машина с доступом по протоколу RDP или через веб-публикацию. В этом случае администратор самостоятельно устанавливает платформу «1С:Предприятие», разворачивает СУБД, администрирует базы в Конфигураторе и организует инфраструктуру точно так же, как и на локальном сервере предприятия.
- Частное облако (Private Cloud на технологии 1С:Фреш): Развертывание облачной инфраструктуры внутри закрытого контура крупного предприятия или холдинга, что позволяет централизованно управлять сотнями баз данных на собственных мощностях.
1. Создание информационных баз и заведение пользователей
Рассмотрим, как распределяются обязанности при инициализации базы в публичном сервисе 1С:Фреш:
В модели SaaS база создается через личный кабинет пользователя на портале сервиса. Администратор абонента выбирает требуемое прикладное решение (например, «1С:Бухгалтерия» или «1С:Управление нашей фирмой»), после чего сервис автоматически выделяет новую область данных (разделитель).
Пользователи заводятся непосредственно в личном кабинете облака с назначением ролей и прав доступа к конкретным базам абонента. Дополнительно можно выполнить загрузку стартовых данных из локальной базы с помощью встроенных механизмов выгрузки в XML.
В архитектуре мультитенантности сотни абонентов могут физически работать в одной базе данных SQL, но логически разделены: таблицы содержат специальную колонку разделителя (ОбластьДанныхОсновныеДанные), что исключает возможность взаимного чтения информации между независимыми организациями.
2. Резервное копирование и получение архивов
Проанализируем процесс создания бэкапов в публичном облаке:
- Автоматическое создание архивов: Провайдер сервиса выполняет регулярное резервное копирование по расписанию. В личном кабинете пользователя доступен журнал созданных точек восстановления с указанием даты и времени.
- Восстановление из архива: При необходимости восстановить состояние базы из резервной копии система обычно разворачивает архив в виде отдельной новой базы (области данных), сохраняя текущую рабочую базу в неизменном виде во избежание потери введенных позже документов.
- Локальная выгрузка: Для переноса данных на свой компьютер используется штатный функционал платформы 1С: в меню «Администрирование» выбирается пункт «Выгрузить данные для локальной версии». Платформа формирует архивный ZIP-пакет (содержащий сериализованные XML-файлы данных), который затем можно загрузить в пустую локальную конфигурацию через мастер переноса данных.
3. Создание тестовой копии информационной базы
Для тестирования нового функционала, проверки доработок или расчета сложных операций требуются копии баз. Разберем доступные варианты:
- Создание копии внутри сервиса: В личном кабинете облака можно создать резервную копию рабочей базы и сразу же восстановить её в соседний слот как временную базу для тестирования.
- Выгрузка на локальный стенд: База выгружается через стандартный XML-файл для перехода в локальный режим. На локальном компьютере или тестовом сервере создается чистая база соответствующей конфигурации (релиз конфигурации на локальном контуре должен в точности совпадать с релизом в облаке или быть выше), после чего данные загружаются стандартным мастером.
4. Обновление релизов конфигураций и особенности доработки
Выясним, как решается вопрос обновления и кастомизации функционала:
Обновление конфигураций: В публичном облаке 1С:Фреш обновление типовых конфигураций и платформы выполняется централизованно администраторами сервиса в нерабочее время. Пользователям не требуется вручную накатывать обновления (.cfu/.cf) или запускать обновление метаданных.
Доработка функционала: Прямой доступ через Конфигуратор к структуре метаданных общей базы заблокирован, так как изменение метаданных затронуло бы всех пользователей сервиса. Поэтому адаптация программы под индивидуальные требования выполняется исключительно с использованием следующих инструментов:
- Расширения конфигурации (
.cfe): Позволяют изменять формы, перехватывать модули объектов, добавлять собственные справочники и документы в рамках выделенной области данных.
- Дополнительные внешние отчеты и обработки (
.epf, .erf): Подключаются через раздел «Печатные формы, отчеты и обработки».
- Аудит безопасности: Все загружаемые пользователем расширения и внешние обработки проходят обязательную автоматическую и ручную проверку технической службой облака на отсутствие потенциально опасных вызовов (работа с файловой системой сервера, COM-объекты, системные команды ОС).
Интеграция с торговым оборудованием и внешними системами
При работе через браузер или тонкий клиент интеграционные сценарии имеют свои особенности:
- Подключение оборудования: Торговые аппараты (онлайн-кассы, сканеры, эквайринг) подключаются локально к рабочему месту пользователя через драйверы БПО (Библиотеки подключаемого оборудования) и локальные компоненты веб-браузера.
- Обмен данными с внешними сервисами: Для обмена информацией с сайтами, CRM или мобильными приложениями облачные базы предоставляют доступ через HTTP-сервисы, Web-сервисы (SOAP) и стандартный протокол OData (REST API). При обращении к таким интерфейсам в строке подключения или заголовках запроса обязательно передается номер области данных абонента.