Tuesday, December 5, 2017

Portable License Unit (PLU) License; How do they work?

A recent engagement of vCloud Suite License caught us off guard. This is because VMware has retired “Per CPU” license and replaced it with “Portable License Unit” PLU for short.

But how does PLU license convert to deprecate CPU license was a question that cropped up…
Since VMware embarked on the cloud journey jointly with AWS and other major players they had to rethink the strategy of licensing. So here is a quick primer on the PLU license.

1 PLU License can be directly converted to 1 CPU license. One PLU unit also can be converted to 15 OSI’s (Operating System Instances). These 15 OSI’s can be Physical Server instances or 15 vm’s on the cloud.



The following was extracted from VMware PLU License white paper:
“One PLU allows usage of vRealize Suite to manage unlimited OSIs/VMs deployed on one on-premises vSphere CPU or up to 15 OSIs deployed on the public cloud including vCloud Air, vCloud Air Network Partners, other supported public clouds, as well as third-party hypervisors and physical servers.”


For more info:

Monday, June 26, 2017

How NSX re-route traffic after a Stretched vMotion?

I happen to get in a discussion with a friend who is into Cisco ACI. We both were going into Pro's and Con's of both NSX and Cisco ACI. (No we didn't get into an ugly argument ;) ) but he was curious how would NSX work in an all Software environment. 

He then brought in how would NSX re-route traffic once a VM has vMotion'd the vm to secondary data center. I asked back my friend how would Cisco handle this? Cisco takes help of Locator/ID Separation Protocol (LISP) protocol or global site load balancer (GSLB).

But how does NSX takes care of this? I had to do some research of my own and I thought it's better to blog about this for my personal reference and may be I can share it with my friend too ;)

So NSX can be configured for Cross vCenter. As you would might think vCenter's will be running on either site. It has to be paired with its own NSX Managers. One of them will assume the role of being Primary NSX Manager. With the use of Primary NSX Manager we create a Universal Controller Cluster, which assumes the role of the Control Plane. Primary NSX manager is responsible in creating all the universal objects for Cross vCenter NSX to work. We create Universal Logical Switch which spans across data centers. Universal objects are spanned through services called NSX Universal Synchronization Service. You could only edit these objects from Primary NSX Manager and could only be viewed from Secondary NSX Managers. 

(Please download these pics for better view)


Detailed View




"On both primary and secondary NSX Managers, you can create objects that are local to that specific vCenter NSX environment, such as logical switches, and logical (distributed) routers. They will exist only within the vCenter NSX environment in which they were created. They will not be visible on the other NSX Managers in the cross-vCenter NSX environment."

Then we create a Universal Logical Distributed Router (UDLR) and enable local egress on it. We need to add the locale ID at both ends on UDLR.


"Locale ID;  The value is generated on the individual NSX Managers.  To Find the locale ID for a given Manager, migrate to the Manager Status page (Networking and security, NSX Managers, Choose a manger, and on the right, it will show the ID under status)




Once you have your Locale ID for each side, you need to configure your UDLR (Universal Distributed Logical Router), under NSX Edges.  (Keep in mind, you must have deployed the UDLR with local egress enabled)
be aware, when you are editing the UDLR, you must select the NSX Manager for which you are editing  (Primary / Secondary)


Add in the Locale ID for each Manager  (have to edit twice).. and put in your individual gateway IP's for each site  (NSX Edge at each site).




Also keep in mind for the IP / subnet you assign to the transport logical switch, needs to be a /29.  Need 1 IP each for the edges (Site A, site B), and two IP's for the UDLR interface (IP and protocol IP for OSPF)


Also if you are doing any static routes, the documentation (and indeed the interface) indicates you have to add a locale ID but not quite so.  In the same way you are adding different gateways to the UDLR config by entering the config under the context of whichever manager, you simply would add statics the same way  (not entering locale ID, just editing under the appropriate side)


Tuesday, February 21, 2017

Today I join the elite club of vExperts!

With great pleasure I would like to inform you that I joined the vExpert club for 2017. I might be the first to achieve this from Sri Lanka! I owe it all to Almighty God, my parents and my Alma mater (St. Joseph's College) and to all the viewers of the blog.