Связаться по Skype: vkarabedyants
Позвонить Написать
+7 (499) 404-28-83

Блог о системном администрировании серверов и сайтов

Установка, настройка программного обеспечения Linux, Windows операционных систем

1С в контейнере. Быстро и недорого

Согласно тестам для групповой работы самой быстрой является клиент-серверная реализация 1С в Linux на базе контейнеров Docker.

Результаты тестирования локальной, файловой и клиент-серверной платформы 1С v8.3 в ОС Windows и Linux. Согласно тестам для групповой работы самой быстрой является клиент-серверная реализация 1С в Linux на базе контейнеров Docker.

docker-1

 

Предоставляем услуги администрирования серверов, установка, настройка и сопровождение docker, контакты office@system-admins.ru

При запуске контейнера служба Docker использует про­странство имен (namespaces) для изоляции контейнера и назначения ему выделенного идентификатора (PID). Кон­трольные группы (cgroups) используются для раздельного доступа к аппаратным ресурсам хостовой системы и опре­деления ограничений. SELinux контролирует доступ к дан­ным контейнера.

 Клиент-серверная реализация 1С в контейнере

Установка Docker для CentOS 7 x86_64 ничем не отличается от установки обычных служб.

Мы устанавливаем и запускаем сервис Docker и локаль­ный регистр для сохранения созданных образов:

В том случае, если сеть предприятия находится за прокси-сервером, нужно дополнительно настроить Docker для ра­боты по протоколам HTTP и HTTPS через прокси. Как оказа­лось, системные настройки им не подхватываются.

Для работы Docker по протоколу HTTP создаем файл /etc/system/system/docker.service.d/http-proxy.conf с содер­жимым:

и файл для работы по протоколу HTTPS /etc/system/system/docker.service.d/https-proxy.conf с содержимым:

Перегружаем system, чтобы принялись изменения:

Ищем готовые образы Docker на сервере по адресу www.docker.io:

Скачиваем два базовых образа, на основе которых будем конфигурировать наши контейнеры:

Просмотр скачанных образов:

Схема развертывания сервера 1C на основе контейнеров Docker показана на рис. 2.

docker-2

Порядок конфигурирования и запусков контейнеров следующий: первоначально конфигурируется и запускается
контейнер базы данных – 1с_postgres. Далее запускается контейнер 1с_server, в котором собран готовый сервер 1С.
Между контейнерами организуем линк.
Конфигурируем и запускаем контейнер 1с_postgres

В данном случае мы запускаем контейнер из образа temrdm/1c_postgres c опцией автоматической перезагруз­ки (—restart=always) в режиме службы (-d), пробрасыва­ем порт 5432 между контейнером и хостовой машиной (-p 5432:5432), где первое значение — порт хостовой маши­ны, второе — порт контейнера, создаем том /var/lib/postgres/ data и монтируем его в контейнер (теперь все данные базы данных сохраняются на хостовой машине и в случае выклю­чения контейнера они не потеряются), задаем переменную среды POSTGRES_PASSWORD, определяющую пароль ад­министратора postgres в базе данных и, наконец, даем имя контейнеру -h data.local.ru.

Проверяем проброшенные порты:

Проверяем работу базы данных PostgreSQL. Создаем тестовую табличку и смотрим, появилась ли она в списке таблиц базы данных:

 Конфигурируем и запускаем контейнер 1c_server

Создаем контейнер с именем 1с_server_data c данными окружения для сервера 1С:

Это контейнер с окружением для сервера 1С и смонти­рованными томами /var/log/1c и /home/usr1cv8. В этих дирек­ториях хранятся информация о созданных базах 1С и логи сервера. Этот контейнер не запускается. Он служит храни­лищем окружения сервера 1С.

Конфигурируем и запускам контейнер 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.
Проверка всех работающих контейнеров:

Подключение к работающему контейнеру 1c_server:

В результате мы получили готовый к работе 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

Оставить комментарий

Лимит времени истёк. Пожалуйста, перезагрузите CAPTCHA.