Virtualizing Exchange, SQL, etc and Storage Block Sizes

K

KapsZ28

2[H]4U
Joined
May 29, 2009
Messages
2,114
I am curious how others are doing this especially in a VMware environment with SAN storage.

For example. Say you are running Exchange 2010 on Windows Server 2008 R2. The OS is installed on a datastore where the LUN is using 4k blocks. I believe recommendations are still 32k for its Exchange mailbox database and 16k for logs. So would you create a 16k and 32k LUN, mount them as datastores and create separate VMDKs for each, or create the LUNs and map via iSCSI in the guest OS?

Also, at what point do these block sizes really start to have a performance impact? Meaning if you are running Exchange for only 20 users, do you even bother with the different block sizes or just run everything off a 4k LUN?

And what do you do if you are using NFS for mounting datastores?
 
KapsZ28 said:
Also, at what point do these block sizes really start to have a performance impact? Meaning if you are running Exchange for only 20 users, do you even bother with the different block sizes or just run everything off a 4k LUN?
Click to expand...

With only 20 users you shouldn't see any issue using the block size provided by the SAN. This is not to say you won't have performance issue if the SAN is over utilized or you are using slow storage to begin with.

The people I work for haven't really seen an issue performance wise and we run a lot of SQL databases off our SAN(I know we don't change block sizes for our systems.) We do though have massive IBM SANs.
 
OBR10

One Big Raid 10 :)

I have Exchange 2013 on W2012, 180 accounts about 80 active users on esxi 5.5.u2 and a single vmdk and don't have any performance issues at all with 6 cores, 18G of memory and 500G of disk space all shared with 8 other VM's

This runs on 8 x WD Black 2TB drives in raid 10.

Is it a single san? (please say no...)
 
Microsoft wants you to map the LUNs from within the guest OS, but from what I've seen, most people are not doing that.
 
Mapping a lun directly to the guest eliminates an abstraction layer which usually improves performance.
 
XmagusX said:
Mapping a lun directly to the guest eliminates an abstraction layer which usually improves performance.
Click to expand...

Maybe, maybe not. For SQL using a paravirtual SCSI driver gives you a 10-12% performance improvement and also ensuring you are using VMXNET3 adapters.

But I am only looking at block sizes right now.
 
Generally you don't start worrying at that level till you're much larger and looking for a last percentage or two of performance to make it last. I've done 5000+ mailbox exchange implementations just using multiple scsi controllers in the guest for queuing without having to worry about storage block size, especially since that's all abstracted away.
 
Yeah, I am not overly concerned about Exchange since we don't really host anything too large just curious how others are managing it.

How about SQL and Oracle databases? Those we do have over 1 TB of DB files per instance but the companies that support the applications and databases have never provided any specific storage, IOPs, or latency requirements.
 
Same thing. Start worrying about those when you're pushing the extremes - general use databases do spectacularly (oracle too) on VMware without fiddling.

Also, if you want more details on the oracle side, I can hook you up with the oracle support team at VMware - they're VERY impressive and your support there offers a lot of things you may not realize they do.
 
I'd love to hear how to properly do Oracle's per core licensing in VMware clusters where it doesn't cost a small fortune.
 
ND40oz said:
I'd love to hear how to properly do Oracle's per core licensing in VMware clusters where it doesn't cost a small fortune.
Click to expand...

That's between you and the rep, but threatening to switch to a different database product helps (especially if your app stack will run happily on postgres or sybase or the like). Oracle reps are all different on that - some will fight to the death for it, and others give in easier and just charge sane numbers.
 
lopoetve said:
That's between you and the rep, but threatening to switch to a different database product helps (especially if your app stack will run happily on postgres or sybase or the like). Oracle reps are all different on that - some will fight to the death for it, and others give in easier and just charge sane numbers.
Click to expand...

Apparently our rep just plays hardball and we really have no option to switch. OVM it is.
 
feffrey said:
We do separate clusters just for Oracle and SQL and license the hosts.
Click to expand...

We tried that with Oracle but since guests could potentially vmotion between clusters they told us we have to license every host a guest could potentially move to. Did you get around this by having your clusters totally separated on different vlans and storage without the ability to vmotion between clusters?

I know this document from VMware states you can fully license cluster or partially license clusters and use DRS to restrict guests to certain hosts and cores but that's not what we've experienced in licensing discussions with Oracle.
 
where did you read that? i was under impression since 2008 r2 it's not true anymore...

ND40oz said:
Microsoft wants you to map the LUNs from within the guest OS, but from what I've seen, most people are not doing that.
Click to expand...
 
Olga-SAN said:
where did you read that? i was under impression since 2008 r2 it's not true anymore...
Click to expand...

I think you're correct, it may have changed, here's the current technet on it: https://technet.microsoft.com/en-us/library/jj619301(v=exchg.150).aspx?f=255&MSPPError=-2147217396

The storage used by the Exchange guest machine for storage of Exchange data (for example, mailbox databases and transport queues) can be virtual storage of a fixed size (for example, fixed virtual hard disks (VHDs) in a Hyper-V environment), SCSI pass-through storage, or Internet SCSI (iSCSI) storage. Pass-through storage is storage that's configured at the host level and dedicated to one guest machine. All storage used by an Exchange guest machine for storage of Exchange data must be block-level storage because Exchange 2013 doesn't support the use of network attached storage (NAS) volumes, other than in the SMB 3.0 scenario outlined later in this topic. Also, NAS storage that's presented to the guest as block-level storage via the hypervisor isn't supported.
Click to expand...
 
ND40oz said:
I'd love to hear how to properly do Oracle's per core licensing in VMware clusters where it doesn't cost a small fortune.
Click to expand...

I just found out that most people seem to get the licensing model incorrect for Oracle. You do NOT need to license the entire cluster. You only license as many hosts that are needed. Apparently this has always been the policy but people tend to misinterpret it or not read the contract.

My source is from a well known VCDX that is big on database virtualization. So I would think it is pretty accurate. :)
 
:-P

KapsZ28 said:
I am curious how others are doing this especially in a VMware environment with SAN storage.

For example. Say you are running Exchange 2010 on Windows Server 2008 R2. The OS is installed on a datastore where the LUN is using 4k blocks. I believe recommendations are still 32k for its Exchange mailbox database and 16k for logs. So would you create a 16k and 32k LUN, mount them as datastores and create separate VMDKs for each, or create the LUNs and map via iSCSI in the guest OS?

Also, at what point do these block sizes really start to have a performance impact? Meaning if you are running Exchange for only 20 users, do you even bother with the different block sizes or just run everything off a 4k LUN?

And what do you do if you are using NFS for mounting datastores?
Click to expand...
 
can you quote some oracle.com hosted pdf for that?

KapsZ28 said:
I just found out that most people seem to get the licensing model incorrect for Oracle. You do NOT need to license the entire cluster. You only license as many hosts that are needed. Apparently this has always been the policy but people tend to misinterpret it or not read the contract.

My source is from a well known VCDX that is big on database virtualization. So I would think it is pretty accurate. :)
Click to expand...
 
Olga-SAN said:
can you quote some oracle.com hosted pdf for that?
Click to expand...

Nope. I can only quote the person I was talking to.

I asked, "Has Oracle changed their licensing policy when it comes to virtualization? Licensing a large host cluster can be expensive."

His response, "Nope. Policy has always been where Oracle is installed and/or running. Only license as many hosts as needed."
 
64K block size is recommended for SQL. At least on Data and Log partitions. You'll hit your storage performance limitations before block size is of concern.
 
KapsZ28 said:
Nope. I can only quote the person I was talking to.

I asked, "Has Oracle changed their licensing policy when it comes to virtualization? Licensing a large host cluster can be expensive."

His response, "Nope. Policy has always been where Oracle is installed and/or running. Only license as many hosts as needed."
Click to expand...

Do you have that in writing so when they audit you, you're covered?
 
ND40oz said:
Do you have that in writing so when they audit you, you're covered?
Click to expand...

Absolutely. It is in the contract that people are not reading. I am not saying I am right. I am saying I highly doubt the source of this information is incorrect. It is possible people are getting screwed over by the reseller or the is a misunderstanding of the terms of the licensing.

I tend to have faith in our fellow VCDX guys, especially those that even have published books about database virtualization. :D
 
Interesting to hear that, Kaps. The company I recently left had some very pointed questions asked and answered. Here was one example question/response from the latest email string I was part of:

"If we have 12 hosts in the cluster, but Oracle VMs are limited to 8 of them, how many hosts must be licensed?"

"All 12"

This was also after having our internal legal team review the contract, who came to the same conclusion.

Edit: fixed typo, too many strings of thought right now :p
 
KapsZ28 said:
Absolutely. It is in the contract that people are not reading. I am not saying I am right. I am saying I highly doubt the source of this information is incorrect. It is possible people are getting screwed over by the reseller or the is a misunderstanding of the terms of the licensing.

I tend to have faith in our fellow VCDX guys, especially those that even have published books about database virtualization. :D
Click to expand...

I've had Oracle come in and tell us how we need to do our licensing if we want to run it in VMware. It's license every host that the vm can possibly be vmotioned to. If you want to believe people who don't work for Oracle, then that's your choice, just don't be surprised if you have an audit and Oracle tells you differently.
 
ND40oz said:
I've had Oracle come in and tell us how we need to do our licensing if we want to run it in VMware. It's license every host that the vm can possibly be vmotioned to. If you want to believe people who don't work for Oracle, then that's your choice, just don't be surprised if you have an audit and Oracle tells you differently.
Click to expand...

I can confirm this. You need to license every CPU/CORE that Oracle instance could potentially run in the cluster even with DRS rules.
 
So here is the response I received when questioning the Oracle licensing and also the VMware documentation that is not officially supported by Oracle.

http://www.vmware.com/files/pdf/tec...rtification-supportlicensing-environments.pdf

BTW, this information is coming from Michael Webster who I personally would take his word over Oracle or auditors trying to say different.

"Oracle don’t need to agree. The only thing that matters is the contract. Contract says where Oracle is installed and/or run. If it’s not installed and/or run there, it doesn’t have to be licensed. No mechanism is specified as to how. Up to customer. Customers will get audited, guaranteed. They need to know their contract and their obligations. It is up to customer to ensure compliance and provide relevant information on license compliance. With Oracle and other licensing always pays to know the contract. I always ask, where does contract say that?"

This is the part of the PDF that is not officially supported by Oracle that pertains to DRS Host Affinity and licensing.

"As long as Oracle software runs on fully licensed processor cores, customers should be able to comply with Oracle’s requirements. In particular, DRS Host Affinity rules can be used to run Oracle on a subset of the hosts within a cluster. In many cases, customers can use vSphere to achieve substantial licensing savings."

In any case, everyone has their right to an opinion and can believe what they want. Me personally, I take Mike's side and tell Oracle that I ain't using the CPUs, so I ain't paying licensing fees. :p
 
KapsZ28 said:
I tend to have faith in our fellow VCDX guys, especially those that even have published books about database virtualization. :D
Click to expand...

The issue is that it really doesn't matter at all what a VCDX says if a vendor disagrees. In the case of an audit Oracle will have the much deeper pockets and your VCDX will just say "oh, well I guess you have to go with what they say, sorry, that's not how I remember doing it!"

That gets you nowhere other than backpaying licensing as well as support & maintenance. The risk to the organization is simply too great to rely on an email from some third party that has no stake in the issue. When you are up against an audit performed on behalf of a multi-billion dollar company then you will lose 10 out of 10 times unless you comply with the license terms as stated by them, regardless of what some guy on the Internet says.

We got rid of Oracle, I hated the product, I hated the reps, I hated the superior attitude. They hated that our apps could be migrated to SQL and we were gone off of the Oracle crap that caused nothing but additional work.

On the SQL side it's easy. We license by core for the entire host, we have all the SQL blades in their own cluster, done and done.
 
I suggest you read this article.

http://longwhiteclouds.com/2012/07/21/fight-the-fud-oracle-licensing-and-support-on-vmware-vsphere/

Personally I have a lot of respect for Michael Webster and other VCDX's I have met. There are not a lot of them in the world and I would definitely consider Michael an expert when it comes to database virtualization, and much more.

http://longwhiteclouds.com/author/

But I am done trying to convince people how to properly license Oracle. If you guys want to pay more, that is on you. :p
 
KapsZ28 said:
But I am done trying to convince people how to properly license Oracle. If you guys want to pay more, that is on you. :p
Click to expand...

The liability is on you. It doesn't matter who says what. At the end of the day it's your ass on the line. If you want to assume the risk then that's your business. The risk you are assuming is, at the very least, that you will have to explain to your CFO why you need to "true-up" on the order of tens or hundreds of thousands of dollars when you didn't budget for it.

Maybe Michael is right, maybe he isn't, but it's IMHO ill advised to not do your due diligence and confirm with the only people who know for sure.

What's your plan here? The auditors determine that you are not compliant and you will make a stand saying that you are and let your legal department sort that you? That will be a resume-generating even for you because it will be much cheaper for your organization to get rid of you and put someone else in your spot rather than go through litigation over inconsequential amounts.
 
You must log in or register to reply here.
Back
Top