Heavy production MySQL/Percona Database in openvz container

Question

So I'm currently running a MySQL 5.1 database, with the following specs:

• Proc: Intel(R) Xeon(R) CPU E5-1620 0 @ 3.60GHz
• RAM: 64 Go
• disks: 2x 100 Go SSD (RaidSoft)

I'm planning to migrate my physical server as well as my mysql server to a percona server 5.6.

I'm using a Proxmox cluster for the rest of my infrastructure therefore I'd like to put my new MySQL server in a dedicated openvz container (only one on the host).

I already successeed to setup this and it seems to work well, however I'm still wondering if it is a good idea.

Any feedbacks?

Answer 1

Be careful about using OpenVZ (Proxmox or otherwise) for any operations where there could be a lot of disk I/O. I can tell you from experience that it is very, very slow - about half the speed of native hardware in some cases. It's especially bad with writes, and it gets worse the more containers are on the server doing reads and writes (thought the latter part of that doesn't apply in your case).

Also, keep in mind that MySQL is very resource hungry and may easily either get OOM killed or otherwise hit a container limit if you haven't set them properly. Again, from experience, this can be hard to do. There is also the fact that certain things to help MySQL perform better, such as hugepages, cannot be set from within the container, so you may end up switching back and forth from host to guest.

About the only things you're going to get out of putting MySQL into a container are process isolation (but not really), some mild assurances that the container won't take down the node (but no guarantees), a pretty interface to control your server with (not unique to OpenVZ containers), and a lot of headaches until you get it configured right. I would avoid OpenVZ for this particular use.

If you're dead-set on using Proxmox, I'd suggest using KVM for this purpose instead of an OpenVZ container. You'll have fewer headaches, trust me.

Answer 2

There are some benefits to running MySQL on a container.

PVE containers offer a few benefits: - Manage the DB server and not affect anything else - Easily move (online if using shared storage) to another physical host - backup with PVE, although, xtrabackup or Idera Hot Copy is better in my opinion - Run 2 or more of them, in a master-slave replication scenario so you have "live" backup SQL servers, but this creates a single point of failure if they are on the same physical server.

Prox is very reliable, there is not doubt about that - I have proxmox servers that have up times of 800 days+. if you run in containers, you will have only a minor hit on performance. Just make sure you allocate the cpu cores to the VM so innodb can make use of them.

Answer 3

For a heavy production server, I don't see the point of using a container. There are no real advantage in my experience. Maybe putting a slave or a few slaves on containers makes sense, but the master, I would put it on bare metal. Check out percona cluster. It rocks.

What were your reasons for wanting to use a VM? What is the business case?

Answer 4

In response to the "don't do it for performance reasons", we use Proxmox in a very write-heavy environment (70% INSERTs), with a RAID-10 backend on unremarkable disks (WD Red), and several other busy VM's (OpenVZ and KVM), and have zero write performance issues (iodelay rarely rises above 0%). If your consideration is a performance one only, then there should be zero issues if the underlying hardware is decent.

Benefits wise - online migration, snapshot backups, drivespace expansion... it's all there.

As for the reliability of proxmox, I can only echo another poster.

uptime

19:51:09 up 785 days, 22:59, 1 user, load average: 4.92, 4.81, 4.79

uptime

19:51:55 up 142 days, 4:56, 1 user, load average: 0.05, 0.07, 0.05