Sizing a Server and Disks - SQL VM
-
@dashrender said in Sizing a Server and Disks - SQL VM:
@dustinb3403 said in Sizing a Server and Disks - SQL VM:
@dashrender said in Sizing a Server and Disks - SQL VM:
I’d say a single VMDK would be less complex than 3-4 VMDK attached.
And adjusting the size of the VMDKs from within the OS will be a pain in the ass if you have to. Changing the size of a physical drive is stupidly simple otherwise.
Power off, increase upwards and then rescale from within the VM (without having to worry about overwriting anything).
Ok there is a bit of value here, but I’m pretty sure wcool modes will let you grow all disks other than the C drive as well. What I don’t know is if you have multiple partitions, in a single drive, will it grow one not next to the free space?
@DustinB3403 does shave a good point here. Because, no, in my experience, windows will not let you grow a partition that is not next to the free space. (It's been a while since I've had to do this).
-
@hobbit666 said in Sizing a Server and Disks - SQL VM:
@dustinb3403 said in Sizing a Server and Disks - SQL VM:
If you're using SSDs than OBR5 would be perfectly fine as well.
Depends on price, would it be acceptable to have X SSD's just for the SQL VM and then the rest SAS for all other VMs?
Or would you just go for fill the server with SSD/SAS drives?Acceptable, yes. But does it make sense to get all those extra drives to be slower? It would have to save a bit of money to justify it.
-
@dafyre said in Sizing a Server and Disks - SQL VM:
For the host, OBR10 almost always. If you have an exception to this rule of thumb you'd know it (somebody here would likely say it, ha ha).
I would also do one big VMDKfor the SQL server VM, and partition the disk.... Use a 2TB disk (just throwing a number out there)...
256 GB = C:\ -- OS / Applications
1024 GB = D:\ -- SQL Server Data
512 GB = E:\ -- SQL Translogs / BAK files
256GB = F:\ -- SQL TempDBDefinitely not. You should "never" partition today. If you want partitions, that means that you actually wanted volumes. Partitions are effectively a dead technology - an "after the fact" kludge that exists for cases where voluming wasn't an option - which should never be the case today as this is solved universally. Partitions are fragile and difficult to manage and have many fewer options and less flexibility. They have no benefits, which is why they are a dead technology.
Partitions exist today only for physical Windows installs, where there is no hypervisor and no enterprise volume manager to do the work - in essence, they are for "never".
-
@dafyre said in Sizing a Server and Disks - SQL VM:
@dashrender said in Sizing a Server and Disks - SQL VM:
@dustinb3403 said in Sizing a Server and Disks - SQL VM:
@dashrender said in Sizing a Server and Disks - SQL VM:
I’d say a single VMDK would be less complex than 3-4 VMDK attached.
And adjusting the size of the VMDKs from within the OS will be a pain in the ass if you have to. Changing the size of a physical drive is stupidly simple otherwise.
Power off, increase upwards and then rescale from within the VM (without having to worry about overwriting anything).
Ok there is a bit of value here, but I’m pretty sure wcool modes will let you grow all disks other than the C drive as well. What I don’t know is if you have multiple partitions, in a single drive, will it grow one not next to the free space?
@DustinB3403 does shave a good point here. Because, no, in my experience, windows will not let you grow a partition that is not next to the free space. (It's been a while since I've had to do this).
Also, if you use multiple volumes you can see them at all levels, rather than having them hidden, you can move them to different RAID arrays in the future as needed as simply as just moving them, you can snapshot them independently, back them up independently, etc.
-
@dafyre said in Sizing a Server and Disks - SQL VM:
@dashrender said in Sizing a Server and Disks - SQL VM:
@dustinb3403 said in Sizing a Server and Disks - SQL VM:
@dashrender said in Sizing a Server and Disks - SQL VM:
I’d say a single VMDK would be less complex than 3-4 VMDK attached.
And adjusting the size of the VMDKs from within the OS will be a pain in the ass if you have to. Changing the size of a physical drive is stupidly simple otherwise.
Power off, increase upwards and then rescale from within the VM (without having to worry about overwriting anything).
Ok there is a bit of value here, but I’m pretty sure wcool modes will let you grow all disks other than the C drive as well. What I don’t know is if you have multiple partitions, in a single drive, will it grow one not next to the free space?
@DustinB3403 does shave a good point here. Because, no, in my experience, windows will not let you grow a partition that is not next to the free space. (It's been a while since I've had to do this).
Which this is the biggest issue. Moving partitions (generally is just a bad idea at least on Windows). With individual volumes though, you simply expand the partition into the newly available free space and it just works.
So many benefits to individual disks rather than a singular disk and multiple partitions (especially on windows)
-
@hobbit666 does that answer all of your best practice questions?
-
@dustinb3403 said in Sizing a Server and Disks - SQL VM:
@hobbit666 said in Sizing a Server and Disks - SQL VM:
@dustinb3403 said in Sizing a Server and Disks - SQL VM:
If you're using SSDs than OBR5 would be perfectly fine as well.
Depends on price, would it be acceptable to have X SSD's just for the SQL VM and then the rest SAS for all other VMs?
Or would you just go for fill the server with SSD/SAS drives?No, don't mix the drive types. As the array will only go as fast as the slowest drive anyways.
If you need a RAID Cache setup a few SSDs for that purpose, but don't mix.
WTF are you talking about here, no where is he talking about arrays. You are injecting pure shit.
An array may only go as fast as the slowest drive in the array, but he was talking about an array with SSD and a different array with SAS.
-
@jaredbusch said in Sizing a Server and Disks - SQL VM:
@dustinb3403 said in Sizing a Server and Disks - SQL VM:
@hobbit666 said in Sizing a Server and Disks - SQL VM:
@dustinb3403 said in Sizing a Server and Disks - SQL VM:
If you're using SSDs than OBR5 would be perfectly fine as well.
Depends on price, would it be acceptable to have X SSD's just for the SQL VM and then the rest SAS for all other VMs?
Or would you just go for fill the server with SSD/SAS drives?No, don't mix the drive types. As the array will only go as fast as the slowest drive anyways.
If you need a RAID Cache setup a few SSDs for that purpose, but don't mix.
WTF are you talking about here, no where is he talking about arrays. You are injecting pure shit.
An array may only go as fast as the slowest drive in the array, but he was talking about an array with SSD and a different array with SAS.
Clearly you didn't read the topic.
-
@dustinb3403 said in Sizing a Server and Disks - SQL VM:
@jaredbusch said in Sizing a Server and Disks - SQL VM:
@dustinb3403 said in Sizing a Server and Disks - SQL VM:
@hobbit666 said in Sizing a Server and Disks - SQL VM:
@dustinb3403 said in Sizing a Server and Disks - SQL VM:
If you're using SSDs than OBR5 would be perfectly fine as well.
Depends on price, would it be acceptable to have X SSD's just for the SQL VM and then the rest SAS for all other VMs?
Or would you just go for fill the server with SSD/SAS drives?No, don't mix the drive types. As the array will only go as fast as the slowest drive anyways.
If you need a RAID Cache setup a few SSDs for that purpose, but don't mix.
WTF are you talking about here, no where is he talking about arrays. You are injecting pure shit.
An array may only go as fast as the slowest drive in the array, but he was talking about an array with SSD and a different array with SAS.
Clearly you didn't read the topic.
No, he is talking about tiering data in an earlier post. That would mean having an array for SSDs and an array for SAS HDD.
-
@dustinb3403 said in Sizing a Server and Disks - SQL VM:
@jaredbusch said in Sizing a Server and Disks - SQL VM:
@dustinb3403 said in Sizing a Server and Disks - SQL VM:
@hobbit666 said in Sizing a Server and Disks - SQL VM:
@dustinb3403 said in Sizing a Server and Disks - SQL VM:
If you're using SSDs than OBR5 would be perfectly fine as well.
Depends on price, would it be acceptable to have X SSD's just for the SQL VM and then the rest SAS for all other VMs?
Or would you just go for fill the server with SSD/SAS drives?No, don't mix the drive types. As the array will only go as fast as the slowest drive anyways.
If you need a RAID Cache setup a few SSDs for that purpose, but don't mix.
WTF are you talking about here, no where is he talking about arrays. You are injecting pure shit.
An array may only go as fast as the slowest drive in the array, but he was talking about an array with SSD and a different array with SAS.
Clearly you didn't read the topic.
Clearly I did. FYI, his post was post 6 that you quoted, and I quoted your post that was post 8.
You injected this idiototic statement of mixing drives in an array when the OP was clearly just looking at what drives to get to create his arrays on.
-
@jaredbusch said in Sizing a Server and Disks - SQL VM:
@dustinb3403 said in Sizing a Server and Disks - SQL VM:
@jaredbusch said in Sizing a Server and Disks - SQL VM:
@dustinb3403 said in Sizing a Server and Disks - SQL VM:
@hobbit666 said in Sizing a Server and Disks - SQL VM:
@dustinb3403 said in Sizing a Server and Disks - SQL VM:
If you're using SSDs than OBR5 would be perfectly fine as well.
Depends on price, would it be acceptable to have X SSD's just for the SQL VM and then the rest SAS for all other VMs?
Or would you just go for fill the server with SSD/SAS drives?No, don't mix the drive types. As the array will only go as fast as the slowest drive anyways.
If you need a RAID Cache setup a few SSDs for that purpose, but don't mix.
WTF are you talking about here, no where is he talking about arrays. You are injecting pure shit.
An array may only go as fast as the slowest drive in the array, but he was talking about an array with SSD and a different array with SAS.
Clearly you didn't read the topic.
Clearly I did. FYI, his post was post 6 that you quoted, and I quoted your post that was post 8.
You injected this idiototic statement of mixing drives in an array when the OP was clearly just looking at what drives to get to create his arrays on.
And read what he said jackass. He is specifically asking if he should create separate arrays for separate VM's using different disks.
This is bad practice as a whole. Just get the same type of drive and use OBR10 (HDD) or OBR5 all SSD.
Mixing and matching isn't a benefit!
-
@dustinb3403 said in Sizing a Server and Disks - SQL VM:
@jaredbusch said in Sizing a Server and Disks - SQL VM:
@dustinb3403 said in Sizing a Server and Disks - SQL VM:
@jaredbusch said in Sizing a Server and Disks - SQL VM:
@dustinb3403 said in Sizing a Server and Disks - SQL VM:
@hobbit666 said in Sizing a Server and Disks - SQL VM:
@dustinb3403 said in Sizing a Server and Disks - SQL VM:
If you're using SSDs than OBR5 would be perfectly fine as well.
Depends on price, would it be acceptable to have X SSD's just for the SQL VM and then the rest SAS for all other VMs?
Or would you just go for fill the server with SSD/SAS drives?No, don't mix the drive types. As the array will only go as fast as the slowest drive anyways.
If you need a RAID Cache setup a few SSDs for that purpose, but don't mix.
WTF are you talking about here, no where is he talking about arrays. You are injecting pure shit.
An array may only go as fast as the slowest drive in the array, but he was talking about an array with SSD and a different array with SAS.
Clearly you didn't read the topic.
Clearly I did. FYI, his post was post 6 that you quoted, and I quoted your post that was post 8.
You injected this idiototic statement of mixing drives in an array when the OP was clearly just looking at what drives to get to create his arrays on.
And read what he said jackass. He is specifically asking if he should create separate arrays for separate VM's using different disks.
This is bad practice as a whole. Just get the same type of drive and use OBR10 (HDD) or OBR5 all SSD.
Mixing and matching isn't a benefit!
Bullshit. Having multiple tiers of storage (SSD and SAS) is not a bad thing.
-
@dustinb3403 said in Sizing a Server and Disks - SQL VM:
@jaredbusch said in Sizing a Server and Disks - SQL VM:
@dustinb3403 said in Sizing a Server and Disks - SQL VM:
@jaredbusch said in Sizing a Server and Disks - SQL VM:
@dustinb3403 said in Sizing a Server and Disks - SQL VM:
@hobbit666 said in Sizing a Server and Disks - SQL VM:
@dustinb3403 said in Sizing a Server and Disks - SQL VM:
If you're using SSDs than OBR5 would be perfectly fine as well.
Depends on price, would it be acceptable to have X SSD's just for the SQL VM and then the rest SAS for all other VMs?
Or would you just go for fill the server with SSD/SAS drives?No, don't mix the drive types. As the array will only go as fast as the slowest drive anyways.
If you need a RAID Cache setup a few SSDs for that purpose, but don't mix.
WTF are you talking about here, no where is he talking about arrays. You are injecting pure shit.
An array may only go as fast as the slowest drive in the array, but he was talking about an array with SSD and a different array with SAS.
Clearly you didn't read the topic.
Clearly I did. FYI, his post was post 6 that you quoted, and I quoted your post that was post 8.
You injected this idiototic statement of mixing drives in an array when the OP was clearly just looking at what drives to get to create his arrays on.
And read what he said jackass. He is specifically asking if he should create separate arrays for separate VM's using different disks.
This is bad practice as a whole. Just get the same type of drive and use OBR10 (HDD) or OBR5 all SSD.
Mixing and matching isn't a benefit!
It's tiered storage nothing bad outside of not making a lot of sense with the price of SSDs coming down so much. If he needed a ton of storage and some faster stuff he could get four SSDs in RAID5 for speed and eight 8TB spinning rust in RAID 10 for capacity. Then manually move the VMDKs between them as he needs to.
-
@jaredbusch said in Sizing a Server and Disks - SQL VM:
@dustinb3403 said in Sizing a Server and Disks - SQL VM:
@jaredbusch said in Sizing a Server and Disks - SQL VM:
@dustinb3403 said in Sizing a Server and Disks - SQL VM:
@jaredbusch said in Sizing a Server and Disks - SQL VM:
@dustinb3403 said in Sizing a Server and Disks - SQL VM:
@hobbit666 said in Sizing a Server and Disks - SQL VM:
@dustinb3403 said in Sizing a Server and Disks - SQL VM:
If you're using SSDs than OBR5 would be perfectly fine as well.
Depends on price, would it be acceptable to have X SSD's just for the SQL VM and then the rest SAS for all other VMs?
Or would you just go for fill the server with SSD/SAS drives?No, don't mix the drive types. As the array will only go as fast as the slowest drive anyways.
If you need a RAID Cache setup a few SSDs for that purpose, but don't mix.
WTF are you talking about here, no where is he talking about arrays. You are injecting pure shit.
An array may only go as fast as the slowest drive in the array, but he was talking about an array with SSD and a different array with SAS.
Clearly you didn't read the topic.
Clearly I did. FYI, his post was post 6 that you quoted, and I quoted your post that was post 8.
You injected this idiototic statement of mixing drives in an array when the OP was clearly just looking at what drives to get to create his arrays on.
And read what he said jackass. He is specifically asking if he should create separate arrays for separate VM's using different disks.
This is bad practice as a whole. Just get the same type of drive and use OBR10 (HDD) or OBR5 all SSD.
Mixing and matching isn't a benefit!
Bullshit. Having multiple tiers of storage (SSD and SAS) is not a bad thing.
It's not a good thing either, unless it's needed.
-
@dashrender said in Sizing a Server and Disks - SQL VM:
@jaredbusch said in Sizing a Server and Disks - SQL VM:
@dustinb3403 said in Sizing a Server and Disks - SQL VM:
@jaredbusch said in Sizing a Server and Disks - SQL VM:
@dustinb3403 said in Sizing a Server and Disks - SQL VM:
@jaredbusch said in Sizing a Server and Disks - SQL VM:
@dustinb3403 said in Sizing a Server and Disks - SQL VM:
@hobbit666 said in Sizing a Server and Disks - SQL VM:
@dustinb3403 said in Sizing a Server and Disks - SQL VM:
If you're using SSDs than OBR5 would be perfectly fine as well.
Depends on price, would it be acceptable to have X SSD's just for the SQL VM and then the rest SAS for all other VMs?
Or would you just go for fill the server with SSD/SAS drives?No, don't mix the drive types. As the array will only go as fast as the slowest drive anyways.
If you need a RAID Cache setup a few SSDs for that purpose, but don't mix.
WTF are you talking about here, no where is he talking about arrays. You are injecting pure shit.
An array may only go as fast as the slowest drive in the array, but he was talking about an array with SSD and a different array with SAS.
Clearly you didn't read the topic.
Clearly I did. FYI, his post was post 6 that you quoted, and I quoted your post that was post 8.
You injected this idiototic statement of mixing drives in an array when the OP was clearly just looking at what drives to get to create his arrays on.
And read what he said jackass. He is specifically asking if he should create separate arrays for separate VM's using different disks.
This is bad practice as a whole. Just get the same type of drive and use OBR10 (HDD) or OBR5 all SSD.
Mixing and matching isn't a benefit!
Bullshit. Having multiple tiers of storage (SSD and SAS) is not a bad thing.
It's not a good thing either, unless it's needed.
Right it depends on the use case.
-
So what the OP needs to do is get IOPs requirements of his environment, and build toward that.
-
@scottalanmiller said in Sizing a Server and Disks - SQL VM:
@dafyre said in Sizing a Server and Disks - SQL VM:
For the host, OBR10 almost always. If you have an exception to this rule of thumb you'd know it (somebody here would likely say it, ha ha).
I would also do one big VMDKfor the SQL server VM, and partition the disk.... Use a 2TB disk (just throwing a number out there)...
256 GB = C:\ -- OS / Applications
1024 GB = D:\ -- SQL Server Data
512 GB = E:\ -- SQL Translogs / BAK files
256GB = F:\ -- SQL TempDBDefinitely not. You should "never" partition today. If you want partitions, that means that you actually wanted volumes. Partitions are effectively a dead technology - an "after the fact" kludge that exists for cases where voluming wasn't an option - which should never be the case today as this is solved universally. Partitions are fragile and difficult to manage and have many fewer options and less flexibility. They have no benefits, which is why they are a dead technology.
Partitions exist today only for physical Windows installs, where there is no hypervisor and no enterprise volume manager to do the work - in essence, they are for "never".
While I hadn't seen/read anything definitive on this, I was kinda wondering if this was the case today.
-
@dashrender time for a video, I guess.
-
@scottalanmiller said in Sizing a Server and Disks - SQL VM:
@dashrender time for a video, I guess.
After mulling over your comments and talking it over with someone else, I see the benefits of using several smaller disks rather than one big one. Especially when you can grow a disk relatively easily. That is something I hadn't considered until now.
-
@dafyre said in Sizing a Server and Disks - SQL VM:
@scottalanmiller said in Sizing a Server and Disks - SQL VM:
@dashrender time for a video, I guess.
After mulling over your comments and talking it over with someone else, I see the benefits of using several smaller disks rather than one big one. Especially when you can grow a disk relatively easily. That is something I hadn't considered until now.
But why not just use one large disk? then you can expand that as much as you want?
