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


Чтобы посмотреть этот PDF файл с форматированием и разметкой, скачайте его и откройте на своем компьютере.
1С в контейнере. Быстро и не дорого



Результаты тестирования локальной, файловой и клиент
-
серверной платформы 1С
v
8.3 в ОС
Windows

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

на базе

Linux

в

контейнер
е

d
ocker
.


Вопрос о том

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

TPC
-
1С[1]. Результат этого небольшого эксперимента
оказался не совсем ожидаем
.
Согласно тестам, для групповой работы самой эффективной
стала клиент
-
серверная реализация
1
C

на базе контейнеров
d
ocker
.

Контейнерная виртуализация на основе
docker

Немного теории о контейнерной виртуализации на базе
d
ocker

[
2
]
. В реализации
d
ocker

следует различать четыре основных сущности. Первая сущность
-

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


контейнеры).

Образ содержит
окружение и необход
имые библиотеки

для

запуска

контейнера
. Как правило, существуе
т
базовый образ
, который скачивае
тся с общедоступного регистра
.
На его

основе
создаются

контейнеры или

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

от основной системы

как
обычный процесс, а часть окружения
и библиотек
получает из метаданных образа.
Контейнер
можно представить

очень
легкой

«
в
иртуальной машиной
»
, без собственной
операционной
системы, поскольку все необходимые системные б
иблиотеки
он
бер
ет от
основной системы,
а вот внутри,

с помощью метаданных

и библиотек

образа
,

создается
специальное окружение для работы пр
иложений которые,

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

(
с ядром не ниже
2.6)
.
Более того, пользователи сами могут добавлять прогр
аммы в работающий контейнер.
Эти программы и настройки записываются «поверх» образа.

Третья сущность


том
.
Грубо говоря, том это смонтированная в контейнер директория
основной системы
, куда
сохраняются все данные полученные
при работе

контейнера
. Если
этого не сдела
ть, после
выключения контейнера

вся информация
,

созданная

в нем,

будет потеряна. Четвертая
сущность
-

линки
. Это связь между контейнерами внутри сети. Надо отметить, что все
контейнеры запускаются в отдельной подсети и получают
IP

адреса слу
чайным образом.
Линки позволяют прописать в связанных контейнерах их имена и
IP

адреса для
межсетевого взаимодействия.

На Рис. 1 показана архитектура контейнерной виртуализации на основе
d
ocker
.
Служба
docker

формирует и запускает по запросу
пользователя

к
онтейнер с готовым
системным окружением. Взаимодействие между клиентом

на стороне пользователя

и
контейнером
docker

осуществляется через сокеты или
RESTful

API

[
3
].


Рис.1

Архитектура
d
ocker

При запуске контейнера, служба
d
ocker

использует пространство имен (
namespaces
)
для изоляции контейнера и назначения ему выделенного идентификатора (
PID
).
Контрольные группы (
cgroups
) используется для раздельного доступа к аппаратным
ресурсам хостовой системы и определения ограничений.
SELinu
x

контролирует доступ к
данным контейнера.


Клиент
-
серверная реализация

1
C

в контейнере

Установка
d
ocker

для
CentOS

7
x
86_64 ничем не отличается от установки обычных
служб. Мы устанавливаем и запускаем сервис
docker

и локальный регистр для сохранения
созданных образов.

# yum install docker docker
-
registry

y

# systemctl enable docker; systemctl start docker

В том случае, если сеть предприятия находится за прокси
-
сервером, нужно
дополнительно настроить
d
ocker

для работы по протоколам
HTTP

и
HTTPS

через прокси.
Как оказалось, системные настройки

им

не подхватываются. Для работы
Docker

по
протоколу
HTTP

создаем файл

/
etc
/
system
/
system
/
docker
.
service
.
d
/
http
-
proxy
.
conf

с

содержимым
:

=
=============================================================

[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

с

содержимым

===============================================================

[Service]

Environment="HTTPS_PROXY=http://proxy.local.ru:3128/"
"NO_PROXY=localhost,127.0.0.1"

==================================================================

Перегружаем
systemd

чтобы принялись изменения.


#
systemctl

daemon
-
reload

Ищем готовые образы
d
ocker на сервере на
www
.
docker
.
io


#
docker

search



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

#docker pull temrdm/1c_postgres


база

данных

PostgreSQL
для

1
С

#docker pull temrdm/1c_server


сервер

1
с

v8.3

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

#
docker

images

Схема развертыва
ния сервера 1
C

на основе контейнеров
docker

показана на Рис.2.


Рис.2

Схема развертывания контейнеров docker

Порядок конфигурирования и запусков контейнеров следующий: первоначально
конфигурируется и запускается контейнер базы данных


1с_
postgres
. Далее
запускается контейнер 1с_
server
, в котором собран готовый сервер 1С. Между
контейнерами организуем линк.

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

#
docker

run

-
d

--
name

1
c
_
postgres

-
p

5432:5432
--
restart
=
always

-
v

/
var
/
lib
/
postgres
/
data
:/
var
/
lib
/
postgresql
/
data

-
e

POSTGRES
_
PASSWORD
=
postgres

-
h

data
.
local
.
ru

temrdm
/1
c
_
postgres

В данном случае мы запускаем контейнер из образа
temrdm
/1
c
_
postgres

c

опцией
автоматической перезагрузки (
--
restart
=
always
) в режиме службы (
-
d
), пробрасываем
порт 5432 между контейнером и хостовой машиной (
-
p

5432:5432), где первое
значение
-

порт хостовой машины, второе


порт контейнера, создаем том
/
var
/
lib
/
postgres
/
data

и монтируем его в контейнер (теперь все данные базы данных
сохраняются н
а хостовой машине и в случае выключения контейнера они не
потеряются), задаем переменную среды
POSTGRES
_
PASSWORD



определяющую
пароль администратора
postgres

в базе данных и наконец, даем имя контейнеру

h

data
.
local
.
ru
.

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

#
dock
er

port

1
c
_
postgres


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

#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



просмотр таблиц

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

Создаем контейнер с именем 1с_
server
_
data

c

данными окружения для сервера 1С

#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
/1
c

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

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

#docker run
--
name=1c_server
--
restart=always
-
d
--
volumes
-
from 1c_server_data
-
v
-
p 1540
-
1541:1540
-
1541
-
p 1560
-
1591:1560
-
1591
-
h
srv.local.ru
--
link=1c_postgres temrdm/1c_server

В данном случае мы запускаем контейнер из образа
temrdm
/1
c
_
server

с функцией
автоматическо
го рестарта в случае отказа (
--
restart
=
always
), в режиме службы (
-
d
) и
окружением из ранее созданного контейнера (
--
volumes
-
from

1
c
_
server
_
data
),
пробрасываем два пула портов между контейнером и хостовой системой (
-
p 1540:1541
и
-
p 1560:1591), создаем и мо
нтируем в контейнер том в режиме только чтения (
-
v

/
etc
/
localtime
:/
etc
/
localtime
:
ro
), связываем его с уже запущенным контейнером
1с_
postgres

и задаем имя
srv
.
local
.
ru
.

Проверка всех работающих контейнеров

#
docker

ps


Подключение к работающему контейнеру 1
c
_
server

#
docker

exec

-
it

1
c
_
server

/
bin
/
bash


В результате мы получили готовый к работе 1С сервер с базой данных.





Тестирование производительности 1С

Немного об оборудовании
, на котором проводилось тестирование.

В

качестве
испытательного полигона использовался ноутбук
HP

Pavilion

dv
2000 в конфигурации:

Компонента

Центральный
процессор

Оперативная
память

Жесткий диск

Сетевой
адаптер

Оборудование


Intel® Core™
2 Duo T5500

2 x 2048 DRAM2
(2
потока
)

SATA I


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
R
2
x
64, а на второй
-

CentOS

7
x
64. Клиент
ами

служил
и

компьютер
ы под управлением
MS

Windows

7 и
PCLinuxOS

в локальной сети.
Обе рабочие станции имели

одинаковые характеристики.

Как не трудно заметить, слабым местом ноутбука является пропускная способность
сетевого адаптера. Другими словами,
производительность локальной конфигурации

теоретически должна быть

существенно выше реализации на основе сетевого
взаимодействия. Более того, ограничения сетевого адаптера могут привести к тому, что
при тестировании производительность сетевых конфигураций 1С
для различных
конфигураций

может оказаться практически одинак
овой.

Чтобы сгладить недостаточную пропускную способность сетевого адаптера, на
основных

системах были добавлены виртуальные машины
VirtualBox

[
4
] и
все
сетевые
конфигурации ещѐ раз тестировались в них.

В этом случае, сетевой
адаптер практически
не оказыва
л

влияние на ход тести
рования
.


1.

Локальная конфигурация
Windows

и
Linux
.

Отправной точкой послужила «классическая» схема установки толстого клиента 1С
и локальная база данных. Скорость работы в однопоточном режиме, как и ожидалось,
оказалась максимальной в

среде
Windows
. Это достаточно легко объясняется более
быстрой файловой системой
NTFS

в
Windows
, по сравнению
c

XFS

на
Linux
.


Рис.3

Сравнение локальной версии на
Linux

и
Windows

2.

Сетевая файловая реализация
Windows

и
Linux

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

2008

использовался родной
протокол
SMB
2
, а для
Linux

протокол
CIFS

(
SMB
1
)

(протокол
NFS

сразу был отброшен
как «не надежный» в плане работы
с
1С). Результат тестирования
оказался интересным.

Производительность 1С в случае
Linux
(
SMB
1
)

оказалась существенно выше
Windows
(
SMB
2)
. Более того, для
Linux

сервера она превысила производительность
локальной конфигурации, что вызвало дополнительное желание проверить эти
конфигурации через
VirtualBox
.


Рис.4

Сравнение
сетевой
версии на
Linux

и
Windows


3.

Сетевая клиент
-
серверная реализация на базе
MS

SQL

в
Windows

и
PostgeSQL

в
Linux

Для проверки клиент
-
серверного взаимодействия в
Windows

Server

2008 была
установлена
нативная
база данных
MS

SQL

2008
R
2
Express

Edition
, а в
Linux

контейнеры


docker

c

базой данных

PostgreSQL

в конфигурации для работы с 1С

и

сервером

:
Enterprise

Server

v
8.3
.


Подключение к серверу проводилось с рабочей станции
по

локальной сети. Результат показал подавляющее превосходство
реализации
1
C

на

контейнерах
docker

вне зависимости от операционной системы клиента (реально, клиент
на базе
Windows

оказался ч
уть производительнее).


Рис.5

Сравнение
сетевой
версии на
Linux

и
Windows


4.

Тестирование через
VirtualBox

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

чуть

выше.

В
Т
аб.1 приведены данные по тестированию производительности 1С во всех
рассмотренных конфигураций.

Таб.1

Тестирование 1С

Реализация

Однопоточный
синтетический тест
производительности
TCP
-
A
-
local

Throughput

Рекомендованное
количество
пользователей

Максимальн
ая
скорость 1 потока
Кб/с

Максимальная
скорость обмена
Кб/с

Локальная
конфигурация
Linux

/
Windows

18,87/ 2
4
,64

1



Сетевая файловая
реализация
Linux
+
CIFS

/
Windows
+
SMB

2.0

21,83
/ 1
,3
*

1



Сетевая клиент
-
серверная конфигурация
Linux

+
PostgreSQL

14,04
**

/11,
88

49 / 14

46

832 /
25

387

9
0

795 /
24192

+
docker

/
Windows

+
MS

SQL


*
Столь
малая скорость

возможно
обусловлена использованием протоколом
SMB
2

*
*
Сервер
Linux

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

оперативную
памя
ть


Результат

тестирования

Результат тестирования показал, что
производительность локальной

реализаци
и


на базе
MS

Windows

не имеет себе равных. С другой стороны, если говорить о
групповой работе
c

выделенным сервером


предпочтительным будет

реализация сервера



в контейнерах
docker

на сервере
Linux
,
c

рабочими станциями под
управлением
Windows
. На самом деле это неожиданн
ый результат. Производительность сервера
Linux

оказалась существенно выше классической
реализации на
Windows
. Большинство
источников показывают обратное. Например [
5
], указывает на 45% превосходство
нативной связки
Windows
+
SQL

над
Linux
+
PostgreSQL
. Но
возможно, основная причина
победы

Linux

в нашем тесте, кроется

именно

в контейнерной
организации сервера 1
C
.

Отличительной особенностью контейнеров
d
ocker

со стороны операционной
системы заключается в том, что он полностью выполняется в одном процессе. В э
том
случае все процессы внутри контейнера заменяются потоками, и межпроцессное
взаимодействие между
процессами(потоками) приложения

становится гораздо более
быстрым. База данных внутри контейнера работает быстрее, чем при нативной установке.
Такая же замен
а происходит с процессами сервера 1С.

Возможно, «
тест Гилева» не является достаточно точным и необходимо более
глубокое тестирование по методике

APDEX, но основным резюме этой статьи в том, что
проект
docker

постепенно перестает быть игрушкой и все больше напоминает
универсальное средство корпоративного развертывания

приложений. Основная идея
docker

-

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


Литература

1.

Конфигурация тестирования 1С 8.3
-

http://www.gilev.ru/tpc1cgilv/

2.

Проект
docker



https://www.docker.com/

3.

REST
-

https://ru.wikipedia.org/wiki/REST

4.

Oracle VirtualBox


https://www.virtualbox.org/

5.


Сравнение производительности 1С при использовании СУБД PostgreSQL и MS
SQL
-

http://efsol.ru/articles/p
erformance
-
1s
-
postgre
-
ms
-
sql.html



Ключевые слова:
docker
, 1
C
,
linux
,
тест, производительность


Приложенные файлы

  • pdf 1667926
    Размер файла: 594 kB Загрузок: 0

Добавить комментарий