Virtual Database Server

[Shadowisper]

Hello,

I'm new to this community so sorry if I posted this in the wrong place or asked this for the 5th million time.

When creating a physical database server it is recommended you place the Operating System, the DataBase files and the DataBase logs each on a seperate hard disk.

I wonder if this is still true for a virtual server? Should I assign each disk to a different datastore so that a database program can access each disk simoultaniously as each datastore has a different LUN behind it?

Thanx in advance for you're advise, it is greatly appreciated.

Regards,

Shadowisper

[Troy_Clavell]

I wonder if this is still true for a virtual server? Should I assign  each disk to a different datastore so that a database program can access  each disk simoultaniously as each datastore has a different LUN behind  it?

for us, it's best practice to create multiple HDD's within the guest OS to seperate the OS (C:) and SQL Data (D:) and Logs (E:).  However, I would leave all the HDD's presented to you guest on a single LUN(datastore)

[Shadowisper]

Thx for you're fast reply, Troy.

Could you please elaborate on why you would use this approach? I had a consultant say it is easier to manage that way, keeping disks on the same datastore. Yet I am more conserned about performance issues. Would a configuration on multiple datastores outperform you're suggested approach noticably?

[Troy_Clavell]

yes, indeed it's a managment issue for the VI Admins.  It can be a performance issue if you aren't careful with your disk I/O.  I think seperating the data from the OS, isn't a bad thing, and not the wrong thing.  It's just for us, we prefer to keep all disk files of a VM together, on the same LUN.

[vmroyale]

Hello and welcome to the forums.

Just to build off of what Troy said, I always start the separate VMDKs all in the same datastore.  I also give each disk its own controller.  The idea being to keep it simple from the start, but then if you do actually have performance issues you can start splitting the disks across separate datastores.  I'm a fan of not adding the complexity until it is required.

Good Luck!

[Shadowisper]

Thanks for you're fast responses. I'm off to create my brand new virtual database server :smileycool:

I've tried marking the answered / helpfull replies.

[Edit] Doesn't seem to have worked. When i click the link it just jumps to the top of the webpage.

[Cyberfed27]

Too add your post,

Consider a VM to be the same as a physical server. The same reasons why would seperate out your drives on a physical box (performance, redundancy ect..) still apply. If your DB server is very i/o intensive all the more reason.

Reasons to keep them all on the same datastore would be administration and a less complex configuration.

[Shadowisper]

I guess the determining factor would be the size and usage of the DB in question. At a certain size or activity level splitting the datastores in-use would be a good plan. For my new DB server when considering the old one, I don't think this would ever be the case.

Again thanks for you're help.

Regards,

Jelle