Как перенести 1С в Yandex.Cloud: опыт компании «Протон»

ООО «Протон» — разработчик программного обеспечения. Развивает собственную систему для бережливого управления бизнесом — ПО GANDIVA. Второе направление деятельности — франчайзи 1С. Компания обслуживает крупные организации (например, автохолдинг «АГАТ»), а также средний и малый бизнес, предоставляет услуги обслуживания серверов 1С и глубокое программирование.

Заказчиком ООО «Протон» стала региональная компания с филиалами на 50 рабочих мест. В компании использовалось гибридное решение из двух серверов Windows Server (непосредственно 1С) + Linux (СУБД PostgreSQL), включая типовые и нетиповые конфигурации.

Были поставлены две главные задачи:

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

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

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

Сотрудникам компании «Протон», как франчайзи 1С, часто приходится вносить исправления у заказчиков, которые купили типовую конфигурацию 1С, разместили ее на своих серверах и заказали доработку системы у сторонних программистов. Это становится слабым местом всего решения — как показывает опыт «Протона», с типовыми конфигурациями (бухгалтерия, зарплата, управление торговлей) проблем не бывает. 99% всех проблем с 1С, включая ошибки и низкую производительность, связаны с переделанными конфигурациями и переписанными отчетами. Обнаруживается это уже в процессе эксплуатации и часто связано с использованием БД PostgreSQL, которая обходится дешевле Microsoft SQL Server. PostgreSQL более требовательна к написанию кода, но оценить это у МСБ-заказчика нет возможности. Наличие сложностей становится очевидно при появлении проблем в работе с базой 1С, зависании программы при простейших манипуляциях, отказе базы данных или неудавшемся бэкапе.

В компании «Протон» сильный штат программистов 1С и системных администраторов, поэтому миграция в облако была осуществлена собственными силами с привлечением техподдержки Yandex.Cloud. Основным используемым сервисом для запуска 1С в облаке стал Yandex Compute Cloud — СУБД PostgreSQL развернули на ВМ.

Процесс миграции занял несколько дней:

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

В процессе миграции и обслуживания специалисты «Протона» столкнулись с необходимостью попутного решения различных задач. Мы рекомендуем обратить внимание на три из них и учитывать их при переносе 1С в Yandex.Cloud.

Развертывание веб-сервераРазвертывание веб-сервера

1С работает в режиме тонкого клиента, и в качестве веб-сервиса можно использовать либо штатный IIS, который уже есть в образе Windows Server на платформе Yandex.Cloud, либо сторонний Apache. Попытка использования Apache на Windows Server 2016 привела к зависаниям, снижению скорости работы и отклика при вполне штатном конфигурационном файле. Вероятно, проблема связана с реализацией MPM под эту ОС (mpm_winnt). На Unix/Linux тестирование не проводилось. В итоге был запущен веб-сервер IIS, и это решило проблемы.

Организация сетевого взаимодействия между виртуальной сетью в облаке и локальной сетью клиентаОрганизация сетевого взаимодействия между виртуальной сетью в облаке и локальной сетью клиента

Изначально возникли затруднения при входе из корпоративной сети в 1С, так как использовалось временное решение, сложное в управлении и реализуемое только для Linux (site-to-site VPN до ВМ в облаке и построение отдельного GRE-туннеля с каждого сервера в облаке на ВМ). С помощью техподдержки Яндекса было найдено более правильное и простое решение с использованием статических маршрутов. Поэтому, если вам нужен VPN до сервера 1С в облаке, обращайтесь в поддержку за консультацией. Строго говоря, в 1С клиент подключается на внешний IP-адрес веб-сервера, описанного в предыдущем пункте. Никаких проблем с этим нет. Для работы 1С в режиме тонкого клиента site-to-site VPN не нужен, но он нужен для переноса оставшихся ролей в облако, авторизации и интеграции c инфраструктурой клиента. Кроме того, S2S VPN может быть полезен тем, кто хочет работать с 1С напрямую, минуя веб-сервер. В этом случае тонкий клиент подключается непосредственно на TCP-порты кластера 1С и публикация такого сервиса на внешнем IP может быть небезопасна.

Лицензионные ограниченияЛицензионные ограничения

Программные лицензии платформы 1С привязаны к аппаратному обеспечению, поэтому изменение версии ОС, RAM, CPU влияет на лицензирование. С учетом обращения в техподдержку 1С необходимо дополнительно закладывать 1–2 дня в план миграции.

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

Вскоре после переезда представилась возможность воспользоваться преимуществами облачных технологий. В последний день месяца резко выросла нагрузка на сервер БД. Оказалось, что все менеджеры составляли отчеты. Это стандартная практика, которая не была описана в ТЗ, а специалисты «Протона» не могли этого предусмотреть, поскольку не были глубоко погружены в бизнес-процессы компании заказчика. При возникновении проблемы через интерфейс Yandex.Cloud была оперативно изменена конфигурация СУБД. Конфигурация сервера 1С не менялась, поскольку основная проблема была именно в дефиците оперативной памяти на СУБД из-за неоптимально написанного запроса 1С:

• Было: 4 vCPU (100% гарантированной доли vCPU, Intel Cascade Lake) 8 Gb RAM.
• Стало: 8 vCPU (100% гарантированной доли vCPU, Intel Cascade Lake), 32 Gb RAM.
• Сейчас: 6 vCPU (100% гарантированной доли vCPU, Intel Cascade Lake), 18 Gb RAM.

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

Решение первой задачи продолжается. Инфраструктура заказчика продолжает трансформироваться. В сентябре в облако переедут контроллер домена, VPN-сервер.

В планах:

• Использовать Yandex.Cloud для резервного копирования архивных данных клиента — Object Storage.
• Реализовать отказоустойчивую конфигурацию СУБД. Настроить асинхронную репликацию данных между зонами Yandex.Cloud.
• Также тестируется сборка PostgreSQL 1С от Yandex.Cloud.