VMware EVC Mode

K

KapsZ28

2[H]4U
Joined
May 29, 2009
Messages
2,114
So I understand the point to EVC mode to make different generation CPUs compatible. We are looking at ordering some new servers and creating a new cluster in vCenter. The are Xeon 2680 v2, which is Ivy Bridge. Is it worth setting EVC mode to Sandy Bridge, or just leaving it disabled? Which would give us better performance?

I was thinking of creating several clusters with at least 3 servers in each depending on the CPU architect. Just wondering if it makes more sense to use different EVC modes, or leaving it disabled. I know I won't be able to migrate between clusters, but the goal is to make sure each cluster is better load balanced and not starved for resources.
 
Do you plan to vMotion between them? If not it doesn't really matter. And why create multiple clusters? You lose resources due to overhead for VMware HA by doing that.
 
NetJunkie said:
Do you plan to vMotion between them? If not it doesn't really matter. And why create multiple clusters? You lose resources due to overhead for VMware HA by doing that.
Click to expand...

The multiple clusters was to separate the servers with different CPU architect. Right now there is a single cluster set as Penryn. The newest server is Westmere. So we are already losing out on features by having EVC set to Penryn. So I was looking for probably three clusters.

Penryn
Westmere
Sandy Bridge (or EVC disabled as these will be Ivy Bridge CPUs)

Penryn uses a FSB, so I would think that is a pretty big performance hit on our Westmere servers. I am guessing that even turbo boost will not work when set to Penryn?

I realize you can't vMotion between them without powering the VM off, but I think moving away from Penryn will be a huge improvement.

I'm just hesitant to use EVC on the Ivy Bridge CPUs as future servers we purchase will have new microarchitecture and I would most likely want to create a new cluster to accommodate those CPU changes.
 
What do you think you're losing between them? Remember..it doesn't make a new CPU run like an old one...it just masks new instruction sets that don't exist in the old ones. Odds are you aren't even using them.
 
NetJunkie said:
What do you think you're losing between them? Remember..it doesn't make a new CPU run like an old one...it just masks new instruction sets that don't exist in the old ones. Odds are you aren't even using them.
Click to expand...

This. EVC just makes sure you can VMotion between hosts in a cluster by masking instruction sets to the lowest common denominator.

OP, If Penryn is as high as you can go for EVC mode in your cluster then leave it there until you retire the hosts with the oldest CPUs then you can raise it.
 
NetJunkie said:
What do you think you're losing between them? Remember..it doesn't make a new CPU run like an old one...it just masks new instruction sets that don't exist in the old ones. Odds are you aren't even using them.
Click to expand...

Oh, I didn't realize it was just the instruction sets. I guess maybe we would benefit from AVX. Not really sure.

I am curious as to how the Turbo Boost works on ESXi...
 
KapsZ28 said:
Oh, I didn't realize it was just the instruction sets. I guess maybe we would benefit from AVX. Not really sure.

I am curious as to how the Turbo Boost works on ESXi...
Click to expand...

Just like it does on a workstation or server. All comes down to CPU load. It can help but it's hard to estimate or judge.
 
Frankly I would be more concerned about Cluster imbalance than EVC, that is, if the new servers are different in Cores/Memory than the current ones....if not..move along..nothing to see here..lol.
 
Vader said:
Frankly I would be more concerned about Cluster imbalance than EVC, that is, if the new servers are different in Cores/Memory than the current ones....if not..move along..nothing to see here..lol.
Click to expand...

Cluster imbalance as an not all the servers are identical? We definitely have that which was one of the primary reasons I wanted to split up the clusters.

Three servers have 64 GB of memory with dual Intel Xeon E5620.
One server with 80 GB of memory and dual Intel Xeon X5660.
Eleven servers have 144 GB of memory and dual Intel Xeon E5645.

Here is the specs for the new servers that are being ordered.

Three servers with 256 GB of memory and dual Intel Xeon 2680 v2.

The new servers are literally giving us a 40% increase in memory and CPU. I wanted to start a new cluster with the three new servers. Put the 11 servers in their own cluster. Possibly increase memory on the 80 GB server to 144 GB and put it in that same cluster since the CPU count is the same. And put the three small servers in their own cluster.

Would that be beneficial as far as balancing the servers?
 
Oh yeah...this could reek havoc on Admission Control settings of course when this is enabled..which I HOPE it is...can't tell you how many times I see this disabled and customers scream when they have a failure because they are grossly over provisioned. Anyway, the goal is to make sure all your VM's are provided the same performance and to ensure they will be protected via HA in the event of a failure. See where i'm going here?

In larger enviornments, I usually break out INF/APP/DEV and of course VDI clusters...and make sure they are very very close, if not identical in CORE Count and Memory Capacity.
 
Vader said:
Oh yeah...this could reek havoc on Admission Control settings of course when this is enabled..which I HOPE it is...can't tell you how many times I see this disabled and customers scream when they have a failure because they are grossly over provisioned. Anyway, the goal is to make sure all your VM's are provided the same performance and to ensure they will be protected via HA in the event of a failure. See where i'm going here?

In larger enviornments, I usually break out INF/APP/DEV and of course VDI clusters...and make sure they are very very close, if not identical in CORE Count and Memory Capacity.
Click to expand...

Awesome! That is exactly what I was saying to my CTO originally. I wanted to create clusters based on what VM's are running in them. Especially since we have quite a few databases, virtual firewalls, web hosting, etc.

Interesting that you mentioned Admission Control. I noticed that it is in fact disabled on our primary cluster. I thought that was odd as the vCloud Director environment that I personally built in a different datacenter, I did enable it. Unfortunately it seems that a lot of planning and best practices didn't happen in the past. That is something I am trying to improve on and why I spend so much time researching before just implementing new servers into a broken environment.
 
KapsZ28 said:
Awesome! That is exactly what I was saying to my CTO originally. I wanted to create clusters based on what VM's are running in them. Especially since we have quite a few databases, virtual firewalls, web hosting, etc.

Interesting that you mentioned Admission Control. I noticed that it is in fact disabled on our primary cluster. I thought that was odd as the vCloud Director environment that I personally built in a different datacenter, I did enable it. Unfortunately it seems that a lot of planning and best practices didn't happen in the past. That is something I am trying to improve on and why I spend so much time researching before just implementing new servers into a broken environment.
Click to expand...

With admission control, you really have to have your head wrapped around the policies. Most people use the default, which is the host failures the cluster will tolerate policy. It uses slot sizes for admission, which are based on the largest CPU/Memory reservations. This tends to lead to problems, and why it is turned off a lot of the time... because the slot sizes end up kind of big and then there are complaints about not being able to power on VMs. Then nobody understands why... its not obvious or intuitive OOTB. Then sometimes you have the opposite effect where there are NO reservations, and admission control uses extremely small slot sizing.... then during failure there are problems getting things powered up because there isn't enough capacity properly reserved.

Go over to yellow-bricks.com, its funny, it's like there is a timely post there every time I see something being discussed. You'll see him talking about franken clusters, which appears to be the monster you're dealing with :). Differently sized hosts cause issues, but only if they're not _ACCEPTABLY_ mitigated. There are impacts to every decision, as NetJunkie pointed out, you lose capacity with each cluster you create due to failover requirements, so having a single host with a couple of extra cores isn't necessarily a horrible thing or with a little bit more memory. Just realize and plan for the capacity required during failover.

Read his HA deep dive (left side, main menu). He'll break down the admission control policies and why you probably should be using the %reserved capacity for failover vice the default admission control policy -- but read them all and understand your decisions.

As for EVC, I see most big enterprises set the EVC mode to the lowest common denominator in their environment, which lets hosts move around more freely. It becomes very difficult to admit an older host into a populated cluster if EVC is not set ahead of time for the situation. You don't lose much from the instruction sets unless you've got an actual requirement for a specific one.
 
EVC mode probably isn't really noticeable on the performance side. Unless you are really sure some special software makes use of these instruction sets mapped out in EVC mode. Could be something that makes use of AES instructions for crypto stuff for example.

But an EVC cluster with greatly differing hosts results in something Duncan Epping calls a Frankencluster - introducing a bunch of new problems.

Edit: Ahrgh...too slow:) ... see previous post
 
You must log in or register to reply here.
Back
Top