C drive OS - D drive Application or Data?

[Useless1]

Hi,

This may sound nit picky but I was curious to ask.

I understand the best practices of splitting the OS and Application up into seperate VMDK's and want to follow this route. My current SAN setup offers me no advantages in terms of performance, but I like the future proofing (Next SAN with multiple storage tiers etc), and I like the ability to resize the Application drive on the fly with no downtime...

My question comes down to what do people mean by the Application drive? Do they mean the binaries of the application or the actual data of the application? Or both??

Take vCenter for example, during the install I could specify to install the application binaries into the D drive. Then I could create the database for vCenter on the D drive also. This is one way of doing it, the other could be of course to install the application onto the C drive, and create the database on the D drive... I guess this is a more classic setup where it is purely the applications working dataset which is on the seperate drive... Of course the final option is to create 3 drives, one for OS, one for application binaries, and one for application data. This one seems a bit overkill to me for my environment however.

Personally I am leaning towards the application binaries on C and actual data on D for a few reasons...

Clean seperation of data from binary

Most installs throw bits at C whether we ask them to or not, registry, Common Files or Windows directories etc...

I am looking at creating a standard and am just trying to work out the best policy and would be interested to know other people's thoughts?

[Osaili]

Hi,

I totally agree with the issue of Applications always throw bits on the system drive for Windows Environement. However, I always recommend to to install the binaries on your application and you probably will not require to seperate the binaries and the data unless your having a cluster.

The reason why you should install the application binaries on non-system drive is to leave your system drive at the minimum capacity. This will save you few Gigs on each searver and will decrease the time for backup/snapshots/clones in case of patches/changes on the OS Level.

Regards,

Ahmed

[bulletprooffool]

I try keep everything possible off of my OS drive.

Usuallu our process is

C: OS

D: Apps and Data

though, in reality, there is no reason to not extend this to

D: Apps

E: Data

as doing so will mean that if you decide to migrate your data to another machine using the same apps (you'd have to re-install apps) you can simply reconnect your VMDK to the new VM.

[AndreTheGiant]

Each can have is own idea about this.

Some use a disk for application + data

Other put the application in the C: volume.

IMHO I prefer have different volumes for different type of data:

C: for OS and application bynary

D: for data

L: (if needed) for transaction log

Andre

[Duncan Epping]

I agree with the comments above. I always separate data / apps from boot and preferably use a separate VMDK on a separate scsi channel (pick 1:0 for your new disk instead of 0:1 --> scsi identifier , will add new scsi adapter gives you "parallel channels")

Duncan (VCDX)

Available now on Amazon: vSphere 4.1 HA and DRS technical deepdive

[Icarus38376]

It seems that the consensus here is that OS/Apps and Data be split onto two drives (C:, D:),

If both drives however reside on the same Datastore, are there really any advantages (performance or otherwise) to having 2 drives verses a single drive?

I'm kinda new at this, so please forgive my ignorance.

[DSTAVERT]

The post immediately above yours is good advice. Two separate vmdks also give you flexibility for things like expanding or contracting disk space, There is no rule that you must use two vmdks and you certainly can just partition a single vmdk. I like it for the added flexibility for data recovery.