A couple of days ago one of my colleagues released an article about Ephemeral Ports. The article explains about how Ephemeral ports could be used as a “backup” when vCenter is down. The summary of the article is in my opinion the paragraph I quoted below.
If the inability to quickly provision a new VM or to reconnect a vNIC while vCenter Server is unavailable has kept you from considering a pure vDS network architecture, ephemeral port groups may be a suitable safety net. You would not even need to use ephemeral port groups for production virtual networks — simply create a few to have as backups for accessing the most critical VLANs.
This started a discussion internally as the default setting is not Ephemeral but Static. So the question that this resulted in was should we define a new standard or are the “Static” port binding just as good as Ephemeral? I believe that many people are hesitant of using a pure vDS infrastructure due to the inability to make changes to the vDS when vCenter would be unavailable. This applies to both ephemeral and static however and actually leads to another point, which we won’t discuss now, vCenter resiliency. Now, from a virtual machine perspective even if vCenter is down, and Static is used as the port bindings, the virtual machine can be powered on and off. With Static all ports are pre-defined on the host level and when a virtual machine is assigned a port it can consume it. Now the difference between Ephemeral and Static is that Ephemeral allows you to assign “new ports” to new virtual nics or virtual machines. I guess the question is how often do you make changes to the network of your virtual machines when vCenter is down and what type of changes?
Seriously, do we really want to make substantial changes to our environment when our management platform is not available? I believe we shouldn’t and I also feel that Static portgroups are the way forward, they have more or less the same level of flexibility Ephemeral have and on top of that Static offers a lot of advantages from a scaling perspective!
Brad Clarke says
My concern is what happens when you use vDS and have vCenter in a VM. If something happens to the vCenter VM and you need to rebuild/recover that VM it would be very difficult to do so if you can’t get it attached to the network. The trick of having an ephemeral port group available “just in case” seems to give a way around this problem.
David says
Brad, protection of VC is the key here and is why vCenter Heartbeat is pushed alot.
I know we have heartbeat in every design/solution to ensure VC doesnt disappear, and cause undo mgmt headaches.
Cheers
David
Peter Linkletter says
For the poor man’s backup of vCenter, why not simply keep a clone of vCenter around. Then the static assignment guarantee’s that there is a port available. If your vCenter corrupts, then simply power on the clone.
Mihai says
Can you elaborate on the advantages of static ports?
P.S. I am also scared of vCenter down sindrome…
Duncan Epping says
like I said “scalability” (check the max config guide) and of course the fact that all ports are pre-created. With Ephemeral this will need to happen on the fly which adds overhead.
Prasenjit says
Duncan,
By specifying few critical resource (I mean portgroup) as Ephemeral are we not limiting the scalability which is first, second are we not introducing risk into our environment?
Now things get complicated when it comes to a multi tenancy cloud. We know that VLAN backed network or even vCDNI based network resources are not scalable. My point is can’t we introduce N1KV so that it will eventually create a separate layer of the mgmt and we will not have the mgmt maintained by vCenter any more? I know in vCloud we don’t support N1KV so far but then it was never said that it will never ever be supported. So we can look at the point of tackling this situation by introducing N1KV and may be it will get supported in next vCloud release and we will also get some robust scalable vCloud network resources (like MPLS) unless having vCDNI or VLAN backed networks.
Wade Holmes says
Prasenjit,
N1Kv is supported by vCloud Director today with port-group backed networks.
Prasenjit says
Wade,
Don’t get me wrong, I was actually pointing towards the scalable org networks (vCDNI) as we know that there is no point for considering port group backed or even VLAN backed network. Now interesting facts came out that even the vCDNI does not have that level of scalability.
But anywayz coming back to this point of mitigating the risk of loosing the manageability of the vDS once vCenter is down, can’t we think of having N1KV which will pass through the Control Panel to other VM?
Jeffrey Hall says
IMO, the N1KV offers an elegant solution that takes advantage of one of vSphere’s most powerful cloud-focused aspects: VMware’s APIs. The N1KV isn’t bound to the health of the vCenter Server with the VSMs being accessible as a pair of highly available virtual appliances on different ESXi hosts. Additionally, this switch is manageable as a real NX-OS switch with capabilities to create many features not possible inside of vSphere: ACLs, Netflow, SPAN, RSPAN, etc.
Duncan says
But there is a cost associated with that as well! The N1KV has dependencies, maybe different but in the end loss of certain components could mean degradation in service,
Prasenjit says
Duncan,
I have written a Blog Article on this with some more testing. Here it is (http://stretch-cloud.info/2011/06/whether-to-use-ephemeral-or-not/).
Let me know your thoughts on this.