Ben M. wrote:
Neil Aggarwal wrote:
Ben:
Are "centralized" database (SQL) servers best left out of virtualization
...
and intensive querying, Accounting Systems and so forth.
It really depends on the hardware you allocate to the VM and how intensive the usage is.
Personally, if I have an intensively queried database server, I want it directly on hardware.
Ditto.
At my $work_place we tried to move our main database server into XEN VM, and while it kinda worked, we had to revert it to a traditional "hardware+os+db" setup, mostly because backups and maintenance operations started to cause performance problems with regular OLTP-like queries -- a situation that had not happen when we were running non-virtualized setup.
The reasons for virtulaization were that it simplifies administration, backups and disaster recovery of database servers.
(setups: "virtual": dell server, local scsi raid, Cent OS 5.x Dom0, CentOS 5.x DomU, disk as LVM volume of Dom0, + PostgreSQL 8.3, database VM is the only VM that dom0 runs) "normal": dell server, local scsi raid, Cent OS 5.x + PostgreSQL 8.3)
Neil
Neil:
What if it were the only "real" active vm? I know that might sound a bit of a waste, but I am really enjoying the backup and duplication abilities of running in a Xen hypervisor as well as its other features. It seems to be saving me a lot of time in production settings. And there is also a comfort level in uniformity on a LAN.
Would there still be a significant hit on resource performance by the hypervisor if running that database server alone in it, or alongside a few rarely used, lightweight or spurious vms? I am talking about the database activities running during the biz day and backups, batches and other maintenance in the off hours. Nothing urgent here, just trying to plan out the future, mull over the possibilities and where to head.
There are no significant hits in performance, except in one area: IO. If your database VMs will have visualized storage -- then there will be IO overhead, it will be most noticeable in "mixed IO load" scenarios, like "lot of random IO requests + 1 or 2 sequential IO streams", i.e. a common situation when OLTP database generates random IO requests, and a backup process generates a steam of sequential read requests (or re-index process, or cluster operation, etc)
Taken alone neither random nor sequential IO presents a performance problem, but the mixture of thereof does. The reason is that XEN effectively serializes all VM's IO in a single kernel thread of the Dom0. The situation, I think, can be avoided if a VM has given direct access to a storage controller as a PCI device, but I have not tested such setup.
Details: For each block device inside VM xen hypervisor creates a kernel thread (named blkback.<device id>.xvd ). All IO requests that VM generates to this device are passed via buffers inside single kernel thread which creates IO starvation and latency problems. (I think only pointers are passed, not the data, but still it does not change the situation) This old article in linux journal does a good job explaining the nature of those problems in plain terms: http://www.linuxjournal.com/article/6931
I've run a number of tests to confirm this theory: 2 setups "normal" and "virtual" (see above) perform roughly the same (normal being ~10% faster) on purely transactional or heavily-sequential workloads (transactional: pgbench tests, sequentional: pg_dump or re-index process) , but taken together (pgbench test + pg_bump in parallel) normal setup turns out to be ~50% faster. During the tests in dom0 you can observe "blkback" kernel thread sitting in IO-wait mode and in DomU you see "disk 100% busy" in atop.
Regards, -Konstantin
-- Konstantin Antselovich mailto: konstantin@antrselovich.com
- Ben
CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt