 |
|
|
|
1С в контейнере. Быстро и недорого
1С в контейнере. Быстро и недорого Результаты тестирования локальной, файловой и клиент-серверной платформы 1С v8.3 в ОС Windows и Linux. Согласно тестам для групповой работы самой быстрой является клиент-серверная реализация 1С в Linux на базе контейнеров Docker Вопрос о том, в какой конфигурации ставить новую версию 1С v8.3 для малого предприятия, мне задают столь часто, что в конце концов пришлось достать старый ноутбук и сделать несколько нагрузочных тестов производительности 1С в различных конфигурациях. Отмечу сразу, что для чистоты эксперимента ни в базах данных, ни на файловых системах непроизводились никакие оптимизирующие настройки. Тестирование производилось нагрузочным тестом Гилева – TPC-1С [1]. Результат этого небольшого эксперимента оказался несовсем ожидаемым. Согласно тестам для групповой работы самой эффективной стала клиент-серверная реализация 1C на базе контейнеров Docker. Контейнерная виртуализация на основе Docker Немного теории о контейнерной виртуализации на базе Docker [2]. В реализации Docker следует различать четыре основных сущности. Первая сущность – образ. Для более легкого восприятия можно представлять образ как пакет или класс, на базе которого создаются готовые приложения (в нашем случае – контейнеры). Образ содержит окружение и необходимые библиотеки для запуска контейнера. Как правило, существует базовый образ, который скачивается с общедоступного регистра. На его основе создаются контейнеры или образы, которые формируют сами пользователи. Второй сущностью являются сами контейнеры. Сущность контейнера довольно интересна, поскольку часть окружения и доступ к системным библиотекам он получает от основной системы как обычный процесс, а часть окружения и библиотек получает из метаданных образа. Контейнер можно представить очень легкой «виртуальной машиной», безсобственной ОС, поскольку все необходимые системные библиотеки он берет от основной системы, а вот внутри с помощью метаданных и библиотек образа создается специальное окружение для работы приложений, которые, в общем случае, отличаются от приложений основной системы. Таким образом, в контейнере могут работать программы, собранные инастроенные в другой ОС на базе Linux (с ядром не ниже 2.6). Более того, пользователи сами могут добавлять программы в работающий контейнер. Эти программы и настройки записываются «поверх» образа. Третья сущность – том. Грубо говоря, том – это смонтированная в контейнер директория основной системы, куда сохраняются все данные, полученные при работе контейнера. Если этого не сделать, после выключения контейнера вся информация, созданная в нем, будет потеряна. Четвертая сущность – линки. Это связь между контейнерами внутри сети. Отмечу, что все контейнеры запускаются в отдельной подсети и получают IP-адреса случайным образом. Линки позволяют прописать в связанных контейнерах их имена и IP-адреса для межсетевого взаимодействия. На рис. 1 показана архитектура контейнерной виртуализации на основе Docker. Служба Docker формирует и запускает по запросу пользователя контейнер с готовым системным окружением. Взаимодействие между клиентом на стороне пользователя и контейнером Docker осуществляется через сокеты или RESTful API [3].
Рисунок 1. Архитектура Docker При запуске контейнера служба Docker использует пространство имен (namespaces) для изоляции контейнера и назначения ему выделенного идентификатора (PID). Контрольные группы (cgroups) используются для раздельного доступа к аппаратным ресурсам хостовой системы и определения ограничений. SELinux контролирует доступ к данным контейнера. Статью целиком читайте в журнале «Системный администратор», №06 за 2016 г. на страницах 48-51. PDF-версию данного номера можно приобрести в нашем магазине.
|
АЛЕКСАНДР ТЕТЮШЕВ, к.т.н., доцент кафедры АВТ Вологодского государственного технического университета (ВоГТУ), 
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
