Каковы недостатки запуска базы данных внутри виртуальной машины? Как мне их преодолеть? [closed]
Запуск чего-либо внутри виртуальной машины приведет к некоторому снижению производительности, но насколько это действительно влияет на производительность системы баз данных?
Я нашел этот академический справочник с некоторыми интересными тестами, но это был ограниченный тест с использованием только Xen и PostgreSQL. Был сделан вывод, что использование виртуальной машины «не требует высокой производительности» (хотя вы можете подумать, что фактические данные говорят об обратном).
Каковы технические, административные и другие недостатки, связанные с запуском базы данных на виртуальной машине?
Пожалуйста, публикуйте ответы, которые могут быть подкреплены объективными фактами, меня не интересуют предположения или какие-либо другие полу- религиозный аргумент (страсть компьютерных фанатов хороша во многих отношениях, но здесь нам это не поможет).
При этом,
- Какие проблемы возникают при запуске базы данных на виртуальной машине? (просьба размещать ссылки)
- Являются ли эти проблемы значительными?
- Являются ли они значимыми только при определенных сценариях?
- Каковы обходные пути?
Though many DB vendors were very slow to do this, nearly all of them now officially support their software running in a virtualized environment.
We run many Oracle 11g instances in linux on top of ESXi, and it is certainly possible to get very good performance. As with all hardware scaling, you just need to make sure that the virtualization host has plenty of resources (RAM, CPU), and that your disk layer is up to the task of delivering whatever IO performance you require.
There are two things to realize here:
- Unit of DB performance per unit of Hardware is a bit lower for a virtualized db. This means you need to buy a little more hardware to get the same level of performance.
- That doesn't mean the same level or a desired level of performance is unobtainable. The gains you get from improved management and other benefits (like easier HA) often way more than offset the marginally increased hardware costs.
That said, where I work our Sql Server installation is one of only two servers that I have no intention of virtualizing any time soon (the other is the primary DC).
There is can and then there is should. A corvette can go 150 mph, but should you on public highways? You can harm yourself unnecessarily.
Databases are guest operating systems. By design when they start they grab blocks of a resource and manage it directly for performance reasons. As soon as you make the core operating system of the database server a guest in virtualized hosting environment then you are placing an arbitration layer with the hypervisor between the block allocated element of disk and RAM and the database server. It will slow down. The more inefficient your queries, the more it will slow. These inefficiencies may be masked today on dedicated hardware, but as soon as you introduce arbitration to your dependent resource you are going to find out real fast.
What a lot of bean counters who are demanding virtualization fail to recognize is that database servers, as guest operating systems, offer their own consolidation layer. There is no reason why you cannot move consolidate multiple logical database instances on one physical server, even to the point of moving IP addresses, setting up additional host names, etc..., to allow for this natural coalescing of services to take place. And, with this model not only do you retain the cost savings that the management is pushing for reduced number of physical hosts, but you retain the block access to physical resources without the impingement of the arbitrary hypervisor, which can make beneficial decisions sometimes and not others.
The same holds true for other guest operating systems, like Java. Virtualization solutions are typically busy environments and the hypervisor has to make lots of decisions on who "gets the token" on a resource. Anytime you can eliminate that layer you are going to be better off.
Coalesce multiple instances using the natural guest operating system layer first. Odds are you will be able to hit your platform consolidation and performance targets easier.
As ErikA says, this is becoming more and more common. I'm in the SQL Server camp and don't personally have any production systems running in VM's, but I would not be hesitant to (after a little more study on the topic). There are definitely some things to take into consideration before you go down that path, though (at least for SQL Server). Disk IO (as others have mentioned) and memory allocation are just 2 examples. Things will be different between different hypervisors as well.
Brent Ozar is a recognized expert in virtualizing SQL Server, specifically in VMWare. I would highly recommend reading through his material.
http://www.brentozar.com/community/virtualization-best-practices/
Запуск SQL Server на виртуальной машине будет нормальным при условии, что вы можете предоставить виртуальной машине достаточно ресурсов для запуска вашего приложения. Если в физическом мире вам нужно 24 ядра и 256 ГБ ОЗУ, тогда вам необходимо предоставить 24 виртуальных ЦП и 256 ГБ ОЗУ в виртуальном мире.
Я только что написал статью в последние месяцы SQL Server журнал, посвященный запуску SQL Server под VMware vSphere.
Я запускаю две базы данных, одну PostgreSQL, а другую MySQL, в виртуальной среде (Xen), где dom0 очень доступны. Все файловые системы domU расположены на iSCSI SAN LUN, разделенном на логические тома LVM2. База данных MySQL предназначена исключительно для Cacti, поэтому она практически не используется и также находится на iSCSI LUN.
База данных PostgreSQL - это база данных для нашей промежуточной среды, поэтому ее использование выше, чем у MySQL db. По этой причине база данных находится на локальном наборе RAID10, а DRBD реплицируется на второй узел кластера. Однако с точки зрения реальной нагрузки эта промежуточная база данных вообще не видит очень высокой нагрузки. Что, на мой взгляд, делает его хорошим / отличным кандидатом для виртуализации.
Некоторыми из преимуществ для нашей организации было снижение энергопотребления, экономия места в стойке и меньшая нагрузка на аппаратное обеспечение.
С другой стороны, я не могу представить, чтобы наша основная производственная база данных стала виртуальной ....
I work with MSSQL and MySQL servers on numerous servers. A couple years ago I was hesitant to start setting up SQL servers on VMs because I had heard about the performance issues of running a SQL server on a VM. However, I was surprised after I setup my first couple SQL servers and saw no change in performance. More and more of the servers I work on are on VM and almost all of the larger enterprise clients I work for have virtulized SQL servers.
Yes, the VM does add some overhead cost and if you are going to be hosting multiple VMs on a single box you are going to need a nice beefy server. A common resource problem to look out for is adding additional VM's and thinning out the available resources. It's common practice to plan for some growth, but if you bought your server to host 2 or 3 VMs and now its running 10 VMs your probably going to see a performance hit.
I would be lying if I said I have never seen performance issues running a SQL server on a VM. But, I have learned that if you are seeing poor performance, there probably is something wrong with the environment.