1C on Proxmox. General notes
After several years of using 1C in container virtualization of Proxmox, there are enough stuffed cones that I will draw here as short general notes on the stages of the implementation process.
This is not a manual or manual. If any of the points should be described in more detail - please do not hesitate to comment.
When you, with burning eyes, wrote down to the management the amount of savings, stability, scalability and other goodies - do not forget about yourself. The minimum is a good hardware, normal ride, fast drives, x64 version of 1C server. It is also desirable to claim some kind of training on the topic. So that management has an understanding that it is investing in its own infrastructure and personnel, and not just out of the blue it saves a lump sum.
It is advisable to choose someone who had at least some experience supporting linux-versions of 1C. Do not be lazy to call and ask. In the end, no one will help you anyway, and you will be left alone with all the problems, but at least without the annoying silly advice about rdp and mssql.
When working with proxmox, it’s a sin not to use the wonderful lxc.mount mechanism to mount directories from the host to containers (moreover, with acl preservation). To prevent containers from swelling from logs and backups, you need to create in advance on the host partitions and directories for these purposes, and cron-tasks for rotation and cleaning. So you will be driving backups and logs through one place, and you will see that this is good.
You, for certain, are already familiar with the classical approach of the 1s-guru, on placing the database on the same server as the application server. Now is a great chance not to do this. The fact is that if you measure the speed of the "network" data transfer between the containers, you will receive at least 25-30 Gbit / s. Feel free to drive the database from the beach, and you get a lightweight monolithic application server and several database servers that can be easily profiled, backed up and maintained.
PostgreSQL from 1C or Postgres Professional work fine in out-of-the-box containers.
Only, for convenience, I would first make an empty container template with a database server, and then clone it for each information base that is connected to the application server. In this template, you should immediately mount the log and backup directories from the host, and, accordingly, redirect the thickest logs there. It also makes sense to immediately make backup tasks, for example, via the pg_dump all mechanism to these directories. When generating output files use $ hostname. So you get a gentleman's set for any occasion.
Everything passes without features, routinely and boringly, only if you do not install an x86 server on x64 OS. But even in this case, everything can be solved. For example, if you put x86 1C on Centos7, there is an excellent repository with x86 packages mirror.centos.org/altarch/7/os/i386/Packages
From there you will definitely need: ImageMagick-c ++ - devel, fontconfig, libgsf, http, httpd -devel, as well as libpng and libpng-devel for barcode printing
Many are against software licenses and are fighting for a more expensive but reliable HASP. It's like skiing and snowboarding. It’s up to you to break a collarbone or ankle. There are also problems with throwing hasp into the container, and with the correct receipt of software licenses.
If you decide to take software licenses, be careful with the CPU cores. As stated in the documentation, you can increase (but not reduce) the number of cores and processors without relicensing. However, Proxmox, when the number of available processor cores in a container changes, changes the CoreID of the first core. That is, if you made a container with 1 core for launch and tied to CoreID 0 during licensing. You will be surprised when increasing the number of cores to 4, CoreID numbering will not be 0.1,2.3 but 1,2,2,4 . Accordingly, the licenses will fly
If this happens - do not despair. Licenses can be simply reactivated by the attached codes. And it is possible in the configuration of the container to put on one core more than the actual amount. For example, 9 for an eight-core server. Then CoreID 0 will return and will not leave you.
I hope these notes will help someone.
This is not a manual or manual. If any of the points should be described in more detail - please do not hesitate to comment.
Planning and Risk Assessment
When you, with burning eyes, wrote down to the management the amount of savings, stability, scalability and other goodies - do not forget about yourself. The minimum is a good hardware, normal ride, fast drives, x64 version of 1C server. It is also desirable to claim some kind of training on the topic. So that management has an understanding that it is investing in its own infrastructure and personnel, and not just out of the blue it saves a lump sum.
Buying software. Integrator.
It is advisable to choose someone who had at least some experience supporting linux-versions of 1C. Do not be lazy to call and ask. In the end, no one will help you anyway, and you will be left alone with all the problems, but at least without the annoying silly advice about rdp and mssql.
Host setup
When working with proxmox, it’s a sin not to use the wonderful lxc.mount mechanism to mount directories from the host to containers (moreover, with acl preservation). To prevent containers from swelling from logs and backups, you need to create in advance on the host partitions and directories for these purposes, and cron-tasks for rotation and cleaning. So you will be driving backups and logs through one place, and you will see that this is good.
Selection of application server and database server configuration
You, for certain, are already familiar with the classical approach of the 1s-guru, on placing the database on the same server as the application server. Now is a great chance not to do this. The fact is that if you measure the speed of the "network" data transfer between the containers, you will receive at least 25-30 Gbit / s. Feel free to drive the database from the beach, and you get a lightweight monolithic application server and several database servers that can be easily profiled, backed up and maintained.
Database Server Setup
PostgreSQL from 1C or Postgres Professional work fine in out-of-the-box containers.
Only, for convenience, I would first make an empty container template with a database server, and then clone it for each information base that is connected to the application server. In this template, you should immediately mount the log and backup directories from the host, and, accordingly, redirect the thickest logs there. It also makes sense to immediately make backup tasks, for example, via the pg_dump all mechanism to these directories. When generating output files use $ hostname. So you get a gentleman's set for any occasion.
Application Server Setup
Everything passes without features, routinely and boringly, only if you do not install an x86 server on x64 OS. But even in this case, everything can be solved. For example, if you put x86 1C on Centos7, there is an excellent repository with x86 packages mirror.centos.org/altarch/7/os/i386/Packages
From there you will definitely need: ImageMagick-c ++ - devel, fontconfig, libgsf, http, httpd -devel, as well as libpng and libpng-devel for barcode printing
Licensing
Many are against software licenses and are fighting for a more expensive but reliable HASP. It's like skiing and snowboarding. It’s up to you to break a collarbone or ankle. There are also problems with throwing hasp into the container, and with the correct receipt of software licenses.
If you decide to take software licenses, be careful with the CPU cores. As stated in the documentation, you can increase (but not reduce) the number of cores and processors without relicensing. However, Proxmox, when the number of available processor cores in a container changes, changes the CoreID of the first core. That is, if you made a container with 1 core for launch and tied to CoreID 0 during licensing. You will be surprised when increasing the number of cores to 4, CoreID numbering will not be 0.1,2.3 but 1,2,2,4 . Accordingly, the licenses will fly
If this happens - do not despair. Licenses can be simply reactivated by the attached codes. And it is possible in the configuration of the container to put on one core more than the actual amount. For example, 9 for an eight-core server. Then CoreID 0 will return and will not leave you.
I hope these notes will help someone.