Как перенести 1С в облако и увеличить ее производительность?

Сегодня программа 1С внедрена в работу более 30 тысяч компаний по всей России. У многих из них со временем возникает потребность в гибком и оперативном масштабировании, повышении надежности и отказоустойчивости бизнес-систем. Причин для этого несколько: отделение российского филиала компании от головного офиса и ИТ-инфраструктуры, локализация размещения данных, повышение надежности и доступности 1С и, следовательно, непрерывности основных бизнес-процессов компании, а также расширение бизнеса. Одним из самых удобных вариантов решения проблемы с минимальными операционными затратами может стать миграция критически важной бизнес-системы, которая охватывает основные задачи управления и учета в облачные хранилища.

– Наталия, расскажите, какова специфика размещения 1С в облаке?

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

– Изменится ли производительность 1С после миграции в облако?

– При правильном планировании и реализации миграции в облако пользователи как минимум не заметят изменений. Это подтверждают тесты, которые мы проводили. Например, в одном из проектов провели «скрытый» эксперимент: сообщили пользователям о регламентах работы по обновлению, потом собрали обратную связь. Многие пользователи отметили увеличение скорости отклика и операций в 1С. Хотя каждый проект и конфигурация имеют свои особенности, но подобное увеличение скорости может быть связано с вполне объяснимыми причинами: даже если оборудование локальное, довольно часто оно не самое последнее, тогда как в облачном хранилище провайдеры регулярно обновляют оборудование и предоставляют различные классы виртуальных машин: оптимизированные по памяти, CPU, дисковой подсистеме. Сервер 1С достаточно чувствителен к тактовой частоте процессора, поэтому рекомендуется выбирать виртуальные машины с частотой от 3Ггц, а также учитывать возможную переподписку у некоторых облачных провайдеров.

Кроме того, команда ICL Services проводила тест Гилёва, позволяющий в первом приближении оценить производительность 1С. Итог теста – это некий показатель в условных единицах 10, 15, 35 и 60, которые соответствуют оценкам «плохо», «удовлетворительно», «хорошо», «отлично». При миграции 1С в облако нам вполне удается добиться показателей 40-45. Если на этом этапе все хорошо, то уже можно провести дополнительные тесты, учитывающие реальную работу пользователей к конкретной 1С-системе и оценивающие работу 1С в условиях параллельных запросов.

Производительность дисковой подсистемы также является достаточно важным показателем. Например, в Yandex Cloud мы советуем SSD IO или High IO диски; в Cloud.ru Advanced для каких-то систем можно выбрать Extreme SSD – наиболее высокопроизводительные сетевые диски в Cloud.ru; в некоторых проектах можно обойтись обычными SSD дисками, но если 1С мигрируется с железной инфраструктуры, то предпочтительно использовать супербыстрые SSD диски – Extreme SSD в Cloud.ru или High I\O в Yandex Cloud.

– Можно ли мигрировать и импортозамещать одновременно?

При импортозамещении сервер 1С с Microsoft Windows переносится на Linux; СУБД MS SQL Server заменяется на PostgreSQL. Обратных запросов пока не встречали. Импортозамещение каждой части (сервера 1С и СУБД) может быть выполнено независимо и поэтапно.

У нас есть проекты, где удалось и мигрировать в облако, и перейти на PostgreSQL Pro и Astra Linux SE. В таких случаях доработок и «сложных» зависимостей со стороны 1С было немного.

Но иногда, после обсуждения анализа инфраструктуры и конфигурации, приходится от импортозамещения отказаться в ближайшей перспективе и выполнить миграцию как есть, т.е. на продуктах Microsoft, либо заменить только сервер СУБД на PostgreSQL. Например, наличие в 1С функциональности, зависимой от COM-объектов, осложняет или делает миграцию на Linux невозможной. В таких проектах при импортозамещении необходимо либо переписать часть кода, полагающегося на COM-объекты, либо отказаться от части функциональности при переходе на Linux.

С заменой MS SQL Server’а на PostgreSQL обычно дела обстоят несколько проще, то есть непреодолимые стоп-факторы встречаются реже. Однако производительность некоторых процессов и 1С операций, которые были доработаны самостоятельно или подрядчиками, может просесть на 15-20 %. Для увеличения производительности можно пойти разными путями: увеличить ресурсы виртуальной машины, оптимизировать операции работы с данными (например, построить индексы, не считывать ненужные поля и т.п.), использовать редакцию Postgres Pro, оптимизированную для 1С.

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

Многие облачные провайдеры предоставляют управляемый сервис PostgreSQL, поэтому в облаке тестирование замены MS SQL Server на PostgreSQL провести значительно проще – можно начать с Managed PostgreSQL. Например, в Yandex Cloud уже есть специальная версия PostgreSQL для 1С.

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

– Какое время простоя при миграции 1С в облако?

1С – это бизнес-система обычно критически важная для непрерывности бизнеса. Кроме того, бизнес-пользователи находятся в разных часовых поясах, по всей территории России. Часто не только офисы, работающие, к примеру, с 9.00 до 17.00, используют 1С, но и склады, которые уже функционируют в режиме 24х7 или близко к этому окну.

Специалисты ICL Services делают все, чтобы минимизировать окно простоя. Это достигается за счет проведения предварительно тестовой миграции реальных баз данных 1С и проверки реальными пользователями 1С ее функциональности в новой среде – облаке. После такой миграции можно скорректировать ресурсы для оптимизации производительности, проверить все потоки данных (интеграции между системами, отправку почты) и открыть все необходимые порты и протоколы для обмена данными 1С в другими системами. Далее следует продуктивная миграция. Наиболее частый подход – это продуктивная миграция с вечера пятницы на утро субботы. Уже примерно через 4 часа пользователи смогут приступить к работе с системой в облаке.

– А что можете сказать, про отказоустойчивость 1С в облаке?

– Один из пунктов, зачем идут в облако – это повышение надежности и отказоустойчивости.

Есть две основные схемы разворачивания 1С в облаке: в 1 зоне доступности (AZ) или в 2 AZ. Первый вариант обеспечивает SLA близкий, но не равный 99,95. Показатель все равно достаточно хорош, но давайте разберемся, почему он фактически ниже 99,95.

В большинстве серьёзных облаков SLA на сервис, и в том числе на виртуальную машину, – 99,95. Примеры: Yandex Cloud, Cloud.ru. Но обычно в контуре 1С несколько взаимосвязанных систем\виртуальных машин, которые совместно обеспечиваются работу контура. Поэтому SLA всех компонентов необходимо перемножить, следовательно, общий целевой SLA системы снижается. Но показатель достаточно хороший, и по нашему опыту SLA выдерживается с запасом, то есть непредвиденных сбоев, приводящих к недоступности 1С, не происходит.

Некоторым заказчикам все-таки требуется SLA гарантированно не менее 99,95. В этом случае предлагаем разворачивание контура 1С в 2 AZ облачного провайдера. Надежность увеличивается, но и затраты тоже несколько возрастают (как на облачные ресурсы, так и на лицензии 1С).

– Какие советы можете дать тем, кто планирует перенести 1С в облако?

– Никогда не забывать о безопасности! Особенно если 1С доступна не только внутри компании, но и через Интернет. Мы рекомендуем не использовать стандартные учетные записи администратора во избежание их блокировок при подборе пароля, а также настраивать SSO и мультифакторную аутентификацию для 1С через Keycloak, ADFS, EntraID и другие сервисы, когда используется веб-клиенты для доступа; Remote Desktop Gateway\Remote Desktop Web Access или аналоги, когда используется RDP\терминальные сервера для доступа к 1С.

– Спасибо за беседу!