← На главную

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

Предполагается, что основной сервер 1С:Предприятия и СУБД (например, MS SQL Server) могут находиться на других серверах или даже операционных системах (например, Windows). Наша цель – перевести именно веб-сервер 1С, который обеспечивает доступ к информационным базам через веб-клиент или веб-сервисы, на платформу Linux и контейнеризировать его для работы в Kubernetes. Такой подход позволяет нам уйти от ресурсоемких терминальных серверов и получить масштабируемое решение для множества клиентов.

Возможность и преимущества развертывания веб-сервера 1С в Kubernetes

Развертывание веб-сервера 1С:Предприятия в кластере Kubernetes является вполне возможным, хотя и требует глубокого понимания как платформы 1С, так и принципов работы контейнеризации и оркестрации. Несмотря на отсутствие официальной поддержки со стороны 1С, контейнеризация приложений, включая компоненты 1С, становится де-факто стандартом архитектуры во многих областях, поскольку позволяет быстро и эффективно использовать ресурсы.

Рассмотрим ключевые преимущества, которые мы получаем при использовании Kubernetes для веб-сервера 1С:

1. Масштабируемость: Мы можем динамически выделять необходимые мощности под увеличение нагрузки. Kubernetes позволяет легко масштабировать количество подов (контейнеров) с веб-сервером 1С в зависимости от текущих потребностей, что особенно критично при пиковых нагрузках или росте числа пользователей.
2. Отказоустойчивость: В случае падения одного из экземпляров веб-сервера (пода), Kubernetes автоматически поднимет новый, обеспечивая непрерывность работы приложения и минимизируя время простоя. Это существенно повышает надежность всей системы.
3. Изоляция: Веб-процессы 1С бегут изолированно друг от друга. Это предотвращает конфликты между различными версиями платформы 1С, различными конфигурациями или их зависимостями, если бы они работали на одном физическом сервере. Каждый под представляет собой независимую среду.
4. Упрощенное управление: Контейнеризация значительно упрощает процессы управления версиями, развертывания и обновления приложений 1С. Мы можем использовать стандартизированные Docker-образы и механизмы развертывания Kubernetes для быстрого и предсказуемого деплоя.
5. Гибкая настройка ресурсов: Для каждого контейнера мы можем точно задать необходимые ресурсы (память, процессор), что позволяет оптимизировать использование инфраструктуры и избегать нехватки ресурсов для критически важных служб.
6. Быстрые перезапуски: Рестарт контейнера занимает значительно меньше времени по сравнению со стандартным перезапуском всего сервера 1С, что сокращает время восстановления после любых сбоев или для применения обновлений.
7. Переход от терминальных серверов: Главная мотивация для многих компаний – это возможность уйти от дорогостоящей и сложной в поддержке терминальной инфраструктуры. Веб-доступ через Kubernetes позволяет значительно снизить нагрузку на терминальные серверы, оптимизировать использование ресурсов и повысить масштабируемость по количеству клиентов.
8. Готовность к API-интеграции: Современные архитектуры, основанные на контейнерах и микросервисах, идеально подходят для реализации асинхронных обменов и интеграции через API, например, с Apache Kafka.

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

Наша цель – развернуть веб-сервер 1С на Ubuntu с Apache в Kubernetes. При этом основной сервер 1С будет работать на Windows и взаимодействовать с СУБД MS SQL Server. Веб-сервер в такой архитектуре выступает в роли «ретранслятора» и «упаковщика» данных, значительно снижая риск его отказа по сравнению с кластером серверов 1С.

Для эффективного управления и балансировки нагрузки в Kubernetes мы используем следующие концепции:

1. Развертывания (Deployments): Этот ресурс Kubernetes позволяет нам описать желаемое состояние нашего веб-сервера 1С – сколько копий (подов) мы хотим запустить, какой образ Docker использовать, какие ресурсы выделить и так далее. Deployment будет следить за тем, чтобы указанное количество подов всегда работало, автоматически перезапуская упавшие или создавая новые при необходимости.
2. Сервисы (Services): Service предоставляет постоянный IP-адрес и DNS-имя для набора подов. Он действует как внутренний балансировщик нагрузки, распределяя входящий трафик между всеми запущенными подами нашего веб-сервера 1С. Это гарантирует, что даже при изменении IP-адресов подов (например, при их перезапуске), клиенты всегда будут обращаться к стабильной точке входа.
3. Инструменты для балансировки веб-сервисов (Ingress): Для внешнего доступа к нашим веб-сервисам и балансировки HTTP/HTTPS трафика по множеству подов мы будем использовать контроллер Ingress. Ingress позволяет настроить правила маршрутизации трафика на основе доменного имени или пути URL, направляя запросы к соответствующим сервисам и подам. Это типичная задача для Kubernetes, и она учтена мощным ураганом возможностей платформы.

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

Лицензирование 1С при работе в Kubernetes

Вопрос лицензирования является одним из самых критичных и сложных при развертывании 1С:Предприятия в контейнерной среде (Docker/Kubernetes). У 1С на сегодняшний день нет официальных механизмов для получения пинкодов или лицензий через REST API, что затрудняет автоматическое управление лицензиями в динамически изменяемой контейнерной инфраструктуре.

Разберем основные аспекты лицензирования:

1. Серверные лицензии: Серверная лицензия 1С представляет собой ключ защиты, разрешающий одновременное подключение пользователей к информационной базе в клиент-серверном варианте. Она хранится на сервере в службе RLS (Ring License Server). Для работы сервера 1С в клиент-серверном варианте наличие серверной лицензии обязательно. В случае с Linux-версией сервера 1С есть интересный аспект: на Linux до сих пор может действовать «фича», когда на одном рабочем процессе и небольшом количестве сеансов платформа не требует серверного ключа для веб-сервисов. Это может быть весьма удобным для определенных сценариев, но всегда следует помнить о соблюдении лицензионного соглашения.
2. Клиентские лицензии: Каждое рабочее место, с которого осуществляется доступ к данным информационной базы 1С:Предприятия, должно быть обеспечено отдельной клиентской лицензией. Это правило распространяется и на доступ через веб-сервисы. Для проброса USB-ключей HASP (как серверных, так и клиентских) в кластер Kubernetes или на виртуальные машины можно использовать специальные механизмы, такие как USB Redirector для Linux. Эти инструменты позволяют организовать доступ к физическим USB-ключам через TCP/IP.

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

Подготовка 1С к контейнеризации и работа с Docker

Помещение 1С-хозяйства в Docker и, как следствие, в Kubernetes, является непростой задачей. Множество участников сообщества отмечают, что процесс настройки контейнера под 1С может быть «сложным и кривым».

Разберем основные моменты, которые следует учесть:

1. Сложность создания образа: Создание надежного и оптимизированного Docker-образа для веб-сервера 1С требует глубоких знаний платформы 1С, операционной системы Linux и Docker. Необходимо учитывать все зависимости, особенности установки компонентов Apache и модуля 1С, а также конфигурацию рабочей среды.
2. Настройка SSO (Single Sign-On) с Kerberos: Если в вашей инфраструктуре используется Kerberos для единого входа, его настройка внутри Docker-контейнера может добавить значительные сложности. Это требует корректной настройки аутентификации, работы с доменными контроллерами и выдачи необходимых разрешений.
3. Использование готовых решений и ресурсов сообщества: Многие энтузиасты и специалисты делятся своим опытом и наработками. Например, в сообществе 1С известны видеоматериалы и статьи, демонстрирующие процесс настройки контейнеров 1С. Мы рекомендуем изучить эти ресурсы для понимания общих подходов и потенциальных подводных камней.

Хотя задача сложна, она решаема при наличии достаточных компетенций и готовности к экспериментам.

Взаимодействие с базами данных (контекст 1С на Linux)

Хотя в нашем конкретном случае основной сервер 1С и СУБД (MS SQL) остаются на Windows, для полноценного понимания развертывания 1С на Linux и в Kubernetes важно рассмотреть вопросы взаимодействия с базами данных, которые часто возникают при таком переходе.

Сервер 1С:Предприятия под управлением Linux может взаимодействовать с несколькими СУБД, но фактически наиболее распространенным и основным вариантом является PostgreSQL. Oracle и DB2 также поддерживаются, но редко используются из-за высокой стоимости лицензий. Сервер 1С на Linux не может взаимодействовать с СУБД Microsoft SQL Server, что является важным ограничением, если вы планируете полный переход 1С на Linux.

Рассмотрим особенности работы с PostgreSQL для 1С:

1. Специальные версии PostgreSQL: Сервер 1С не умеет работать со стандартной «ванильной» версией PostgreSQL. Требуется использовать патченные версии, оптимизированные для 1С, например, PostgreSQL Pro, которая обновляется быстрее и проще в скачивании. Использование неподходящей версии может привести к проблемам с производительностью и стабильностью.
2. Оптимизация postgresql.conf: Для достижения максимальной производительности PostgreSQL в связке с 1С необходимо тщательно настроить конфигурационный файл postgresql.conf. Ключевые параметры для оптимизации включают:
   • max_connections: количество одновременных подключений.
   • shared_buffers: объем памяти, выделяемой для буфера данных.
   • maintenance_work_mem: объем памяти для операций обслуживания.
   • bgwriter_delay: задержка фонового писателя.
   • fsync: критически важный параметр, обеспечивающий физическую запись изменений на диск. Его отключение может дать выигрыш в скорости, но чревато неисправимой порчей данных при сбоях питания.
   • wal_sync_method: метод синхронизации WAL-логов.
   Важно не шаманить с конфигом без понимания, особенно не отключать упреждающую запись (WAL) для ускорения, так как это может привести к потере данных и ошибке "FATAL: the database system is starting up." после аварийного завершения работы.
3. Проблемы с локалью: Распространенная ошибка при установке PostgreSQL для 1С – это неверно установленная локаль в инстансе СУБД. Это может привести к ошибке "Порядок сортировки не поддерживается базой данных". Для решения проблемы необходимо переустановить кластер с русскоязычной локалью или создать второй инстанс с нужной локалью на нестандартном порту.
4. Особенности бэкапов PostgreSQL для 1С:
   • pg_dump: Эта утилита создает логические резервные копии без блокировки пользователей. Однако она имеет ряд недостатков: длительное время восстановления (особенно для больших баз) и невозможность восстановления на конкретный момент времени (Point-in-Time Recovery). pg_dump не рекомендуется для больших баз и, что критично для 1С, может вызывать проблемы при создании/модификации таблиц (изменении метаданных или обновлении конфигурации) во время бэкапа. В таких случаях база 1С может оказаться в недоделанном или "испорченном" состоянии, хотя сам PostgreSQL продолжит работать с ней. Это очень похоже на сбой при динамическом обновлении.
   • pg_basebackup: Для полноценного и надежного бэкапа кластера PostgreSQL рекомендуется использовать pg_basebackup. Эта утилита создает бинарные копии кластера и использует механизмы репликации, что обеспечивает более быструю и надежную процедуру восстановления, включая восстановление на конкретный момент времени.
   • Роль DBA: Многие проблемы с PostgreSQL, часто приписываемые его "блеску и нищете опенсорса", на самом деле являются следствием отсутствия квалифицированного DBA. В оракле тоже бывают глюки, но там их обычно эксплуатируют там, где есть штатный DBA. Опытный DBA поможет правильно настроить, тюнинговать и поддерживать PostgreSQL в продакшене.
   • Отдельные кластеры PostgreSQL: В реальном продакшене для 1С часто развертывают отдельный кластер PostgreSQL для каждой базы данных. Это позволяет обеспечить нормальные бинарные бэкапы из коробки, индивидуально тюнинговать каждую базу под её профиль нагрузки и снизить вероятность одновременного сбоя всех баз.

Интеграция с Kafka для обменов

Для организации обменов данными в современной архитектуре все чаще используются брокеры сообщений, такие как Apache Kafka. 1С:Предприятие также может быть интегрировано с Kafka, что особенно актуально для больших проектов по обменам и созданию API.

Рассмотрим возможные подходы к интеграции:

1. «1С:Шина»: Это решение от самой фирмы 1С, которое предоставляет узлы KafkaИсточник и KafkaНазначение для асинхронной интеграции. Оно упрощает взаимодействие 1С с Kafka на уровне платформы.
2. Внешние компоненты: Существуют open-source и коммерческие внешние компоненты, такие как Simple Kafka, разработанные сообществом, которые позволяют 1С взаимодействовать с Kafka. Эти компоненты расширяют функциональность платформы.
3. Kafka Rest Proxy от Confluent: Для интеграции 1С с Kafka через REST API можно использовать Kafka Rest Proxy. Этот инструмент предоставляет HTTP-интерфейс для взаимодействия с Kafka, что удобно для 1С, так как платформа хорошо работает с веб-сервисами и HTTP-запросами.

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

Сложности и риски

Несмотря на все преимущества, перевод веб-сервера 1С:Предприятия в Kubernetes сопряжен с рядом сложностей и рисков, которые мы должны учитывать:

1. Официальная неподдерживаемость: Запуск сервера 1С:Предприятия в кластере Kubernetes официально не поддерживается вендором. Это означает, что при возникновении проблем вы не сможете рассчитывать на прямую поддержку от 1С, и проект останется экспериментальным, требующим собственной экспертизы.
2. Проблемы с лицензиями: Как мы уже обсуждали, управление лицензиями 1С в контейнерной среде остается одной из самых больших проблем из-за отсутствия механизмов автоматического получения пинкодов.
3. Недостаточная протестированность: Технология работы сервера 1С в контейнерах пока недостаточно протестирована на стабильность работы в реальных высоконагруженных продакшн-средах. Возможны непредвиденные проблемы и тонкости, которые будут выявлены только в процессе эксплуатации.
4. Сложность настройки: Создание образа Docker для 1С может быть сложным, особенно при необходимости настройки SSO (Single Sign-On) с Kerberos или других специфических интеграций. Требуются глубокие знания и опыт.
5. Хранение баз данных: Рекомендуется разворачивать базы данных (будь то PostgreSQL, MS SQL или другие) вне Kubernetes, в специальных сервисах, а не внутри контейнеров. Это связано с тем, что базы данных требуют постоянного хранилища (Persistent Storage) с высокой производительностью и надежностью, что может быть сложнее обеспечить в динамической среде Kubernetes.
6. Мониторинг: Для эффективного мониторинга большого количества контейнеров 1С и всей инфраструктуры Kubernetes необходимо настраивать сбор метрик и использовать системы визуализации, такие как Grafana. Это требует дополнительных усилий по настройке и поддержке.

Внимательно оцените эти риски и сложности перед тем, как принимать решение о полномасштабном внедрении.

В заключение, развертывание веб-сервера 1С:Предприятия на Linux в Kubernetes является перспективным направлением, которое предлагает значительные преимущества в масштабируемости и отказоустойчивости. Однако оно требует серьезной подготовки, экспертных знаний и готовности к решению нестандартных задач, особенно в области лицензирования и работы с базами данных.