Спустя несколько лет использования 1С в контейнерной виртуализации Proxmox, появилось достаточно набитых шишек, которые оформлю здесь в виде коротких общих заметок по этапам процесса внедрения.
Это не не руководство к действию и не мануал. Если какой-то из пунктов следует расписать более подробно — пожалуйста, не стесняйтесь в комментариях.
Когда вы с горящими глазами расписали менеджменту суммы экономии, стабильность, масштабируемость и прочие плюшки — не забудьте о себе. Минимум — это хорошее железо, нормальный райд, быстрые диски, х64-версия сервера 1С. Желательно еще стребовать какое-то обучение по теме. Чтобы у менеджмента было понимание, что он инвестирует в свою собственную инфраструктуру и персонал, а не просто на ровном месте экономит круглую сумму.
Желательно выбрать того, кто имел хоть какой-то опыт поддержки linux-версий 1С. Не поленитесь обзвонить и спросить. В итоге, вам все равно никто не поможет, и вы останетесь один на один со всеми проблемами, но хотя бы без раздражающих глупых советов про rdp и mssql.
При работе с proxmox, грех не задействовать чудесный механизм lxc.mount для монтирования каталогов с хоста в контейнеры (причем, с сохранением acl). Чтобы контейнеры не пухли от логов и бэкапов нужно заранее создать на хосте разделы и каталоги под эти цели, и cron-задания для ротации и очистки. Так вы будете рулить бэкапами и логами через одно место, и увидите, что это хорошо.
Вы, наверняка, уже знакомы с классическим подходом 1с-гуру, по размещению БД на том же сервере, что и сервер приложений. Сейчас как раз отличный шанс этого не делать. Дело в том, что если вы измерите скорость «сетевой» передачи данных между контейнерами, то получите не меньше 25-30 Гбит/с. Смело гоните БД с пляжа, и у вас получится легкий монолитный сервер приложений и несколько серверов БД, которые легко будет профилировать, бэкапить и обслуживать.
PostgreSQL от 1С или Postgres Professional прекрасно работают в контейнерах «из коробки».
Единственно, для удобства, я бы сделал сначала пустой шаблон контейнера с сервером БД, а потом клонировал его под каждую информационную базу, подключаемую к серверу приложений. В этом шаблоне стоит сразу же сделать монтирование лог и бэкап каталогов с хоста, и, соответственно, перенаправление туда наиболее толстых логов. Так же имеет смысл сразу сделать бэкап-задания, например, через механизм pg_dump all в эти каталоги. При формировании выходных файлов использовать $hostname. Так у вас получится джентельменский набор для любого случая
Все проходит без особенностей, рутинно и скучно, только если вы не ставите x86-сервер на x64 ОС. Но даже в этом случае все можно решить. Например, если вы ставите x86 1C на Centos7, есть прекрасный репозиторий с x86-пакетами mirror.centos.org/altarch/7/os/i386/Packages
Оттуда вам точно понадобятся: ImageMagick-c++-devel, fontconfig, libgsf, http, httpd-devel, а так же libpng и libpng-devel для печати штрих-кодов
Многие против программных лицензий и ратуют за более дорогой, но надежный HASP. Это как с лыжами и сноубордом. Вам решать что ломать — ключицу или лодыжку. Проблемы бывают и пробросом hasp в контейнер, и с корректным получением программных лицензий.
Если вы решили брать программные лицензии — будьте внимательны с ядрами CPU. Как сказано в документации, вы можете увеличивать (но не уменьшать) количество ядер и процессоров без перелицензирования. Однако Proxmox, при изменении количества доступных ядер процессора в контейнере, меняет CoreID первого ядра. То есть, если вы для старта сделали контейнер с 1 ядром и при лицензировании привязались к CoreID 0. Вы будете удивлены, когда увеличив число ядер до 4, нумерация CoreID будет не 0,1,2,3 а 1,2,2,4. Соответственно, лицензии слетят
Если такое произошло — не отчаивайтесь. Лицензии можно достаточно просто реактивировать по приложенным кодам. А можно в конфигурации контейнера поставить на одно ядро больше реального количества. Например, 9 для восьмиядерного сервера. Тогда CoreID 0 вернется и не покинет вас.
Надеюсь, эти заметки кому-то помогут
Это не не руководство к действию и не мануал. Если какой-то из пунктов следует расписать более подробно — пожалуйста, не стесняйтесь в комментариях.
Планирование и оценка рисков
Когда вы с горящими глазами расписали менеджменту суммы экономии, стабильность, масштабируемость и прочие плюшки — не забудьте о себе. Минимум — это хорошее железо, нормальный райд, быстрые диски, х64-версия сервера 1С. Желательно еще стребовать какое-то обучение по теме. Чтобы у менеджмента было понимание, что он инвестирует в свою собственную инфраструктуру и персонал, а не просто на ровном месте экономит круглую сумму.
Покупка ПО. Интегратор.
Желательно выбрать того, кто имел хоть какой-то опыт поддержки linux-версий 1С. Не поленитесь обзвонить и спросить. В итоге, вам все равно никто не поможет, и вы останетесь один на один со всеми проблемами, но хотя бы без раздражающих глупых советов про rdp и mssql.
Настройка хоста
При работе с proxmox, грех не задействовать чудесный механизм lxc.mount для монтирования каталогов с хоста в контейнеры (причем, с сохранением acl). Чтобы контейнеры не пухли от логов и бэкапов нужно заранее создать на хосте разделы и каталоги под эти цели, и cron-задания для ротации и очистки. Так вы будете рулить бэкапами и логами через одно место, и увидите, что это хорошо.
Выбор конфигурации сервера приложений и сервера БД
Вы, наверняка, уже знакомы с классическим подходом 1с-гуру, по размещению БД на том же сервере, что и сервер приложений. Сейчас как раз отличный шанс этого не делать. Дело в том, что если вы измерите скорость «сетевой» передачи данных между контейнерами, то получите не меньше 25-30 Гбит/с. Смело гоните БД с пляжа, и у вас получится легкий монолитный сервер приложений и несколько серверов БД, которые легко будет профилировать, бэкапить и обслуживать.
Настройка сервера БД
PostgreSQL от 1С или Postgres Professional прекрасно работают в контейнерах «из коробки».
Единственно, для удобства, я бы сделал сначала пустой шаблон контейнера с сервером БД, а потом клонировал его под каждую информационную базу, подключаемую к серверу приложений. В этом шаблоне стоит сразу же сделать монтирование лог и бэкап каталогов с хоста, и, соответственно, перенаправление туда наиболее толстых логов. Так же имеет смысл сразу сделать бэкап-задания, например, через механизм pg_dump all в эти каталоги. При формировании выходных файлов использовать $hostname. Так у вас получится джентельменский набор для любого случая
Настройка сервера приложений
Все проходит без особенностей, рутинно и скучно, только если вы не ставите x86-сервер на x64 ОС. Но даже в этом случае все можно решить. Например, если вы ставите x86 1C на Centos7, есть прекрасный репозиторий с x86-пакетами mirror.centos.org/altarch/7/os/i386/Packages
Оттуда вам точно понадобятся: ImageMagick-c++-devel, fontconfig, libgsf, http, httpd-devel, а так же libpng и libpng-devel для печати штрих-кодов
Лицензирование
Многие против программных лицензий и ратуют за более дорогой, но надежный HASP. Это как с лыжами и сноубордом. Вам решать что ломать — ключицу или лодыжку. Проблемы бывают и пробросом hasp в контейнер, и с корректным получением программных лицензий.
Если вы решили брать программные лицензии — будьте внимательны с ядрами CPU. Как сказано в документации, вы можете увеличивать (но не уменьшать) количество ядер и процессоров без перелицензирования. Однако Proxmox, при изменении количества доступных ядер процессора в контейнере, меняет CoreID первого ядра. То есть, если вы для старта сделали контейнер с 1 ядром и при лицензировании привязались к CoreID 0. Вы будете удивлены, когда увеличив число ядер до 4, нумерация CoreID будет не 0,1,2,3 а 1,2,2,4. Соответственно, лицензии слетят
Если такое произошло — не отчаивайтесь. Лицензии можно достаточно просто реактивировать по приложенным кодам. А можно в конфигурации контейнера поставить на одно ядро больше реального количества. Например, 9 для восьмиядерного сервера. Тогда CoreID 0 вернется и не покинет вас.
Надеюсь, эти заметки кому-то помогут
