5

Our former CTO (now "consultant") at some point warned his replacement about not virtualizing database servers, specifically our PgSQL database servers, but rather run them as actual, physical servers. The problem with this is that we are rapidly running out of physical space in our racks and capacity on our main database server.

He offered little more than vague musings on I/O speed; and although I don't have any specific reason to mistrust his judgement on this matter, it would be good to know:

Is there a real reason for this recommendation (and if so, what?), or is it mere superstition on his part?

Williham Totland
  • 187
  • 7

2 Answers2

4

Virtualizing database servers is a real no-no, and here's several reasons why

  • The biggest open as expressed by your CTO rightly is the I/O bottleneck, virtualized systems add around a 40% to 60% overlay on disk writing, which means that they'll write to disk twice as slow at least. Considering that one of the major problems with any busy database is the ability to write to disk as fast as possible this would hinder your database hardware and make the database unusable under load
  • Also it's key for a database to be able to access huge pages of memory fast, so it would starve from memory the rest of virtual machines sitting on the same node

So the smart thing to do is keep your databases on the bare metal while virtualizing other parts that are not so disk dependant (for example, web servers)

lynxman
  • 9,397
  • 3
  • 25
  • 28
4

A better answer to this question is "it depends". Depends on the hardware, configuration etc etc. Depends on service level agreements, load, well written code, application architecture, the list goes on.

I run several production database servers in PostgreSQL and MS SQL with SAN storage, which perform quite happily within the parameters expected by the organisation (and far better than the hardware solutions they replaced). And I can guarantee there are many, many more DBAs who agree.

Scott Herbert
  • 586
  • 1
  • 6
  • 13