1С в контейнере. Быстро и недорого
Согласно тестам для групповой работы самой быстрой является клиент-серверная реализация 1С в Linux на базе контейнеров Docker.
Результаты тестирования локальной, файловой и клиент-серверной платформы 1С v8.3 в ОС Windows и Linux. Согласно тестам для групповой работы самой быстрой является клиент-серверная реализация 1С в Linux на базе контейнеров Docker.
Предоставляем услуги администрирования серверов, установка, настройка и сопровождение docker, контакты [email protected]
При запуске контейнера служба Docker использует пространство имен (namespaces) для изоляции контейнера и назначения ему выделенного идентификатора (PID). Контрольные группы (cgroups) используются для раздельного доступа к аппаратным ресурсам хостовой системы и определения ограничений. SELinux контролирует доступ к данным контейнера.
Клиент-серверная реализация 1С в контейнере
Установка Docker для CentOS 7 x86_64 ничем не отличается от установки обычных служб.
Мы устанавливаем и запускаем сервис Docker и локальный регистр для сохранения созданных образов:
1 2 |
# yum install docker docker-registry –y # systemctl enable docker; systemctl start docker |
В том случае, если сеть предприятия находится за прокси-сервером, нужно дополнительно настроить Docker для работы по протоколам HTTP и HTTPS через прокси. Как оказалось, системные настройки им не подхватываются.
Для работы Docker по протоколу HTTP создаем файл /etc/system/system/docker.service.d/http-proxy.conf с содержимым:
1 2 3 |
[Service] Environment="HTTP_PROXY=http://proxy.local.ru:3128/" ↵ "NO_PROXY=localhost,127.0.0.1" |
и файл для работы по протоколу HTTPS /etc/system/system/docker.service.d/https-proxy.conf с содержимым:
1 2 3 |
[Service] Environment="HTTPS_PROXY=http://proxy.local.ru:3128/" ↵ "NO_PROXY=localhost,127.0.0.1" |
Перегружаем system, чтобы принялись изменения:
1 |
# systemctl daemon-reload |
Ищем готовые образы Docker на сервере по адресу www.docker.io:
1 |
# docker search 1с |
Скачиваем два базовых образа, на основе которых будем конфигурировать наши контейнеры:
1 2 3 4 |
//база данных PostgreSQL для 1С # docker pull temrdm/1c_postgres //сервер 1с v8.3 # docker pull temrdm/1c_server |
Просмотр скачанных образов:
1 |
#docker images |
Схема развертывания сервера 1C на основе контейнеров Docker показана на рис. 2.
Порядок конфигурирования и запусков контейнеров следующий: первоначально конфигурируется и запускается
контейнер базы данных – 1с_postgres. Далее запускается контейнер 1с_server, в котором собран готовый сервер 1С.
Между контейнерами организуем линк.
Конфигурируем и запускаем контейнер 1с_postgres
1 2 |
#docker run -d --name 1c_postgres -p 5432:5432 --restart=always -v /var/lib/postgres/data:/var/lib/postgresql/data -e POSTGRES_PASSWORD=postgres -h data.local.ru temrdm/1c_postgres |
В данном случае мы запускаем контейнер из образа temrdm/1c_postgres c опцией автоматической перезагрузки (—restart=always) в режиме службы (-d), пробрасываем порт 5432 между контейнером и хостовой машиной (-p 5432:5432), где первое значение — порт хостовой машины, второе — порт контейнера, создаем том /var/lib/postgres/ data и монтируем его в контейнер (теперь все данные базы данных сохраняются на хостовой машине и в случае выключения контейнера они не потеряются), задаем переменную среды POSTGRES_PASSWORD, определяющую пароль администратора postgres в базе данных и, наконец, даем имя контейнеру -h data.local.ru.
Проверяем проброшенные порты:
1 |
# docker port 1c_postgres |
Проверяем работу базы данных PostgreSQL. Создаем тестовую табличку и смотрим, появилась ли она в списке таблиц базы данных:
1 2 3 4 5 |
# psql -h localhost -U postgres -d postgres -c "CREATE TABLE tmp (some_id serial PRIMARY KEY, some_text text);" //интерактивный вход в базу данных #psql -h localhost -U postgres // просмотр таблиц Psql> \l |
Конфигурируем и запускаем контейнер 1c_server
Создаем контейнер с именем 1с_server_data c данными окружения для сервера 1С:
1 2 |
# mkdir /home/usr1cv8; mkdir /var/log/1c # docker create --name=1c_server_data -v /var/log/1c -v /home/usr1cv8/ temrdm/1c_server |
Это контейнер с окружением для сервера 1С и смонтированными томами /var/log/1c и /home/usr1cv8. В этих директориях хранятся информация о созданных базах 1С и логи сервера. Этот контейнер не запускается. Он служит хранилищем окружения сервера 1С.
Конфигурируем и запускам контейнер 1c_server:
1 |
#docker run --name=1c_server --restart=always -d -volumes-from 1c_server_data -v /etc/localtime:/etc/localtime:ro -p 1540-1541:1540-1541 -p 1560-1591:1560-1591 -h srv.local.ru --link=1c_postgres temrdm/1c_server |
В данном случае мы запускаем контейнер из образа temrdm/1c_server с функцией автоматического рестарта
в случае отказа (—restart=always), в режиме службы (-d) и окружением из ранее созданного контейнера (—volumes-from
1c_server_data), пробрасываем два пула портов между контейнером и хостовой системой (-p 1540:1541 и -p 1560:1591),
создаем и монтируем в контейнер том в режиме только чтения (-v /etc/localtime:/etc/localtime:ro), связываем его с уже запущенным контейнером 1с_postgres и задаем имя srv.local.ru.
Проверка всех работающих контейнеров:
1 |
#docker ps |
Подключение к работающему контейнеру 1c_server:
1 |
#docker exec -it 1c_server /bin/bash |
В результате мы получили готовый к работе 1С сервер с базой данных.
Тестирование производительности 1C
Немного об оборудовании, на котором проводилось тестирование. В качестве испытательного полигона использовался ноутбук HP Pavilion dv2000 в конфигурации (см. таблицу 1).
Компонента | Центральный процессор | Оперативная память | Жесткий диск | Сетевой адаптер |
Оборудование | Intel® Core™ 2 Duo T5500 | 2 x 2048 DRAM2 (2 потока) | SATA I | Ethernet 10/100BT |
Теоретическая пропускная способность | 1.5GHz * 64bit = 96000 Mbit/s | 667MHz * 64bit * 2 = 85376 Mbit/s | SATA I = 1200 Mbit/s | LAN100 = 100 Mbit/s |
Жесткий диск ноутбука был разбит на два раздела. На первом установлена ОС MS Windows 2008 R2 x64, а на втором — CentOS 7 x64. Клиентами служили компьютеры под управлением MS Windows 7 и PCLinuxOS в локальной сети. Обе рабочие станции имели одинаковые характеристики.
Как нетрудно заметить, слабым местом ноутбука является пропускная способность сетевого адаптера. Другими словами, производительность локальной конфигурации 1С теоретически должна быть существенно выше реализации на основе сетевого взаимодействия. Более того, ограничения сетевого адаптера могут привести к тому, что при тестировании производительность сетевых конфигураций 1С для различных конфигураций может оказаться практически одинаковой.
Чтобы сгладить недостаточную пропускную способность сетевого адаптера, на основных системах были добавлены виртуальные машины VirtualBox, и все сетевые конфигурации еще раз тестировались в них. В этом случае сетевой адаптер практически не оказывал влияние на ход тестирования.
1. Локальная конфигурация Windows и Linux
Отправной точкой послужили «классическая» схема установки толстого клиента 1С и локальная база данных. Скорость работы в однопоточном режиме, как и ожидалось, оказалась максимальной в среде Windows. Это достаточно легко объясняется более быстрой файловой системой NTFS в Windows по сравнению c XFS на Linux
2. Сетевая файловая реализация Windows и Linux
Тестирование проводилось с рабочей станции в локальной сети, на которой был установлен толстый клиент 1С. При этом ноутбук использовался как файловый сервер. При реализации сетевой конфигурации 1С для Windows 2008 использовался родной протокол SMB2, а для Linux — протокол CIFS (SMB1) (протокол NFS сразу был отброшен как «не надежный» в плане работы с 1С). Результат тестирования оказался интересным. Производительность 1С в случае Linux (SMB1) оказалась существенно выше Windows (SMB2). Более того, для Linux-сервера она превысила производительность локальной конфигурации, что вызвало дополнительное желание проверить эти конфигурации через VirtualBox.
3. Сетевая клиент-серверная реализация на базе MS SQL в Windows и PostgreSQL в Linux
Для проверки клиент-серверного взаимодействия в Windows Server 2008 была установлена нативная база данных MS SQL 2008 R2 Express Edition, а в Linux — контейнеры Docker c базой данных PostgreSQL в конфигурации для работы с 1С и сервером 1C:Enterprise Server v8.3. Подключение к серверу проводилось с рабочей станции по локальной сети. Результат показал подавляющее превосходство реализации 1C на контейнерах Docker вне зависимости от операционной системы клиента (реально клиент на базе Windows оказался чуть производительнее).
4. Тестирование через VirtualBox
Поскольку ограничивающим фактором сетевого тестирования является пропускная способность сетевого адаптера ноутбука, в состав операционных серверных операционных систем была добавлена виртуальная машина VirtualBox, с которой были повторены сетевые тесты. Однако чуда не произошло, и все сетевые конфигурации практически повторили результаты, полученные при реальном тестировании, хотя скорость обмена была выше.
В таблице 2 приведены данные по тестированию производительности 1С во всех рассмотренных конфигурациях.
Реализация | Однопоточный синтетический тест производительности TCP-A-local Throughput | Рекомендованное
количество пользователей |
Максимальная скорость 1 потока, Кб/с | Максимальная скорость обмена, Кб/с |
Локальная конфигурация Linux/Windows | 18,87/24,64 | 1 | ||
Сетевая файловая реализация Linux+CIFS / Windows+SMB | 21,83*/12,31 | 1 | ||
Сетевая файловая конфигурация Linux /Windows через VirtualBox | 18,08/12,25 | 1 | ||
Сетевая клиент-серверная конфигурация Linux + PostgreSQL /Windows + MS SQL | 13,11*/12,35 | 56*/14 | 14 247*/16 054 | 28 865*/28 497 |
Сетевая клиент-серверная конфигурация Linux+PostgreSQL /Windows+MS SQL через VirtualBox | 14,04 /11,88 | 49/14 | 16 832/14 208 | 30 795/27 359 |
Результат тестирования
Результат тестирования показал, что производительность локальной реализации 1С на базе MS Windows не имеет себе равных.
С другой стороны, если говорить о групповой работе c выделенным сервером, предпочтительным будет реализация сервера 1С в контейнерах Docker на сервере Linux c рабочими станциями под управлением Windows. На самом деле это неожиданный результат.
Производительность сервера Linux оказалась существенно выше классической реализации на Windows. Большинство источников показывает обратное. Например, [5] указывает на 45% превосходство нативной связки Windows + SQL над Linux + PostgreSQL. Но, возможно, основная причина победы Linux в нашем тесте кроется именно в контейнерной организации сервера 1C.
Отличительной особенностью контейнеров Docker со стороны ОС заключается в том, что он полностью выполняется в одном процессе. В этом случае все процессы внутри контейнера заменяются потоками, и межпроцессное взаимодействие между процессами (потоками) приложения становится гораздо более быстрым. База данных внутри контейнера работает быстрее, чем при нативной установке. Такая же замена происходит с процессами сервера 1С.
Возможно, «тест Гилева» не является достаточно точным и необходимо более глубокое тестирование по методике APDEX, но основное резюме этой статьи в том, что проект Docker постепенно перестает быть игрушкой и все больше напоминает универсальное средство корпоративного развертывания приложений. Основная идея Docker — развертывание контейнера в одном процессе существенно ускоряет «тяжелые» сервисы, такие как базы данных или серверы приложений. При этом накладные расходы виртуализации становятся просто ничтожными по сравнению с выигрышем от межпроцессного обмена внутри потоков контейнера.
Источник: Журнал системный администратор №6 2016
Как обстоят дела с програмными лицензиями для 1с? Как они работают с Docker?