Как мигрировать 1С в облако: обзор

Многие компании замещают приложения уходящих с рынка вендоров на решения 1С. И это часто сопровождается миграцией в облако. Я, Анжелика Захарова, менеджер облачных проектов K2 Cloud, расскажу, как и почему компании переводят приложения 1С в облако в 2024 году, и что следует учитывать при миграции.

Обзор рынка

В 2023 году мы увидели годовой прирост числа, связанных с 1С запросов, в 1,5 раза, включая 5х рост числа запросов на развёртывание 1С в К2 Облаке.

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

В контексте облачной 1С к нам обращаются по следующим вопросам:

• Миграция 1С с on-premises в облако.

• Сайзинг: обеспечение 1С необходимым количеством вычислительных ресурсов.

• Тюнинг производительности 1С.

• Замена зарубежных ERP на отечественные решения. В 2022 году доля 1С составляла 67% ERP-решений в России и продолжает расти. 

Типичные причины, по которым компании переводят 1С в облако:

• Скорость развертывания. Учитывая скорость, с которой иногда приходится выполнять импортозамещение, компании обращаются к облакам, чтобы быстро получить требуемую инфраструктуру. В облаках также запускают пилотные проекты для тестирования импортозамещающих отечественных систем. 

• Оптимизация расходов. Издержки на 1С on-premises растут. Рост стоимости лицензий и сервисов поддержки 1С составил 17%, услуг специалистов по внедрению 1С — 15% в 2023 году. Переход в облако позволяет оптимизировать эти издержки.

• Доверие в плане ИБ. Облака — полностью зрелое решение с точки зрения информационной безопасности, всё больше безопасников доверяют им. Мы видим это по числу клиентов, которые переносят в наше облако сервисы ИБ.

• Нативные возможности облака. Некоторые задачи решаются в облаке проще, чем on-premises: резервное копирование без нагрузки на продуктив, катастрофоустойчивые решения на нескольких ЦОДах.

• Оптимизация производительности. Стандартная облачная тема простого масштабирования ресурсов при пиковых нагрузках (например, формирование отчетности за большие периоды) или по мере изменения объёма проекта, поддержка провайдером высокой производительности за счет модернизации оборудования по-прежнему являются причиной миграции.

Этапы миграции 1С в облако и подводные камни

Можно выделить следующие этапы миграции 1С:

1. Тестирование облачной инфраструктуры.

2. Аудит инфраструктуры, выявление требований к сайзингу и сетевой связности.

3. Разработка и согласование архитектуры сети.

4. Согласование окон простоя для миграции.

5. Тестирование миграции.

6. Продуктивная миграция.

Рассмотрим, что следует учитывать на каждом из этапов.

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

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

Во время аудита исследуется и учитывается:

• Исходная инфраструктура, с которой планируется миграция: аппаратные сервера, собственная система виртуализации, другой облачный провайдер.

• Приложение 1С: 1С:Бухгалтерия, 1С:Управление торговлей, 1С:Зарплата и так далее. Исследуется конфигурация приложения, его код и модификации.

• СУБД, её конфигурация, наличие кластера. Некоторые СУБД есть в нашем облаке в виде PaaS, и миграцию данных можно выполнить встроенными средствами самой базы. Другие СУБД можно развернуть и поддерживать как приложения на ВМ. Иногда для упрощения администрирования параллельно с миграцией инфраструктуры 1С в облако мигрируют приложение 1С на другую СУБД, доступную в виде PaaS.

• Интеграции 1С с бизнес-приложениями. По опыту, о некоторых интеграциях ИT-департамент клиента даже не подозревает.

• Архитектура сети: топология, защита каналов связи, особенности конфигурации сети, наличие DMZ и так далее.

• Доступ пользователей, реализованный у клиента: терминальная ферма, VPN, VDI, доступ через тонкий клиент.

• Лицензирование. Лицензии, задействованные в on-premises инфраструктуре, невозможно просто взять и перенести в облако.

• Регуляторные требования, требования к обращению с ПДн.

• Инструменты надежности и аптайма: репликация, отказоустойчивость на уровне приложений, Disaster Recovery, резервное копирование.

• Мониторинг. В К2 Облаке для 1С доступен MaaS (monitoring as a service), нативные инструменты мониторинга 1С на базе APDEX. Также мы предлагаем шаблоны для Zabbix, проверенные на многих проектах.

• Разделение доступов между провайдером и клиентом. В сфере заказчика — политики, управление приложениями на терминалах пользователей, их конфигурацией. В сфере провайдера — администрирование ВМ и гипервизора, сети, инфраструктурных приложений. Это можно реализовать разными способами, например, на уровне конфигурации Active Directory.

• Сайзинг, в идеале учитывающий исторические данные о размере СУБД и приросте данных, утилизации ресурсов из года в год. 

Учет исторических данных для определения сайзинга при миграции осложняется тем, что ресурсы в инфраструктурах «до» и «после» сложно сопоставить. Например, если on-premises и облако задействуют разные типы и поколения процессоров, их частоты не соответствуют друг другу 1:1, а разная сетевая связность влияет на требования к скорости сети.

Решение — мониторинг базовых метрик производительности. Метрики снимаются во время аудита перед миграцией и позволяют корректно определить сайзинг для облака. Далее мониторинг выполняется по ходу эксплуатации облачного решения и позволяет корректировать выделение ресурсов. 

Разработка и согласование архитектуры сети должны обеспечивать:

• Связность в гибридной инфраструктуре. В облаке можно быстро выделить ресурсы, создать сеть, связать все части инфраструктуры между собой. Но построить правильную сетевую связность с существующими площадками — не всегда тривиальная задача.

• Бесшовный доступ пользователей к облачным сервисам.

• Безопасность, регуляторные требования, обращение с ПДн. Иногда простой запрос на миграцию 1С в облако выливается в крупный проект, поскольку ещё в изначальной инфраструктуре не были правильно выполнены все требования. Но лучше поздно, чем никогда.

Согласование окон простоя для миграции. Сама миграция может быть быстрой — несколько часов или даже минут. Но найти для неё окно с минимальными потерями от даунтайма бывает сложно. Решения о согласовании окон простоя проходят на многих уровнях, далеко за пределами ИТ-отдела. 

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

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

Продуктивная миграция. Если все предыдущие этапы выполнены тщательно, сама миграция происходит без приключений.

Тюнинг производительности 1С по ходу эксплуатации

По ходу дальнейшей эксплуатации может возникнуть задача тюнинга производительности приложения 1С. Половина запросов клиентов в облако 1С — на эту тему.

Увеличение CPU, размера физического хоста или ВМ не обязательно увеличит производительность. Узкое место, создающее просадку производительности, может находиться где угодно.

Тюнинг производительности включает:

• Поиск узкого места. Проверка сервера приложений, СУБД, терминальной фермы, конфигураций, интеграций, полосы доступа к серверу лицензирования, каналов связи и производительности устройств пользователей.

• Мониторинг вычислительных ресурсов: сервера 1С, сервера СУБД, терминалов, сети, каналов связи от пользователя до сервера. Можно даже на компьютеры пользователей поставить агенты мониторинга. 

• Проверку кода приложений и интеграций.

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

Кейс: как выглядит 1С как управляемый сервис в облаке

Приведу пример, как выглядит приложение «1С:ERP. Управление холдингом» в облаке в виде управляемого сервиса «под ключ»: клиент не вникает в то, как всё работает в облаке, мы же, со своей стороны, обеспечиваем полное сопровождение работы сервиса.

Требования:

• Доступ заказчика к дашбордам мониторинга для контроля системы, доступности компонентов. Передача управления сервисом провайдеру означает, что для заказчика состояние системы должно быть максимально прозрачным в любой момент.

• Сетевая связность облака с on-premises инфраструктурой заказчика по защищенному каналу.

• Катастрофоустойчивость: конфигурация на два партнерских ЦОДа (доступна стандартными средствами К2 Облака).

• Аутентификация пользователей с помощью учетных записей Active Directory в домене заказчика: перенос в облако не должен создать изменений в привычном поведении сотрудников.

Мы разработали архитектуру со следующими особенностями: 

• Собственная служба каталога с доверительными отношениями с доменом заказчика позволяет полностью разделить зоны ответственности: заказчик управляет приложениями и политиками, мы – инфраструктурой. Заказчик не имеет доступ в Active Directory, на базе которой работает сервис в нашем облаке, а наша служба поддержки не имеет доступа в Active Directory заказчика.

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

• Серверы — ВМ на базе Linux, СУБД — PostgreSQL от 1С. Реализованы в виде кластеров на два партнерских ЦОДа.

• Автоматизация управления инфраструктурой на базе Ansible + GitLab. Это удобно не только клиентам, но и нам для сопровождения.

• Мониторинг с помощью MaaS (monitoring aaS) К2 Облака. Наши администраторы и ИТ-отдел заказчика получают уведомления о состоянии системы и сбоях.

• Единая служба поддержки решения, без пинг-понга между вендорами и подрядчиками. Независимо от того, какая проблема возникает, клиент обращается к нам через «единое окно».

Вычислительные ресурсы облака для задач 1С

К2 Облако в Телеграм