I get this question quite a bit due to the new vCloud Director 9.5 Cross-VDC networking functionality – does vCloud Availability for Cloud-to-Cloud 1.5 (C2C) work with stretched networking inside of Cross-VDC networking?
The answer is: yes!
This is another great addition for recoverability considerations as one could fail over between vCloud Director instances without modifying the guest OS IP address. Furthermore, based on the application architecture, one could have active-active applications and ensure replication/failover in the event of a disaster.
Let’s go through my example high-level design I’ve worked up in my lab –
In the above diagram, we can see I have two active vCloud Director instances, Site-A and Site-B. I have two organizations, “Daniel” that resides in Site-A along with “Daniel-B” that resides in Site-B.
C2C is deployed on each site in the combined model and I have multi-site pairing completed so I can easily manage this between my two sites –
Within my Cross-VDC networking setup, I currently have my active egress setup to Site-A as depicted in the diagram above.
Last of all, I ran a protected workflow from Site-A to Site-B for my Stretched-vApp-VM –
From there, one can either migrate or failover the workload and without any guest OS IP changes. I am going to do a video shortly, but here’s a short GIF I created that shows the ease of use of failing over between my Site-A and Site-B –
After failover, I can then access Stretched-vApp-VM from the new NAT address on Site-B.
An Organization Administrator could also configure active/active or active/passive egress points for additional resiliency. This provides further capability inside of vCloud Director, especially with stretched networking and a complementary availability solution.
Recently, I received a request from one of our aggregators regarding how Equal Cost Multipathing (ECMP) is metered within the VMware Cloud Provider Program (VCPP), specifically Tom Fojta’s recommendation on architecting Provider-managed NSX Edges and Distributed Logical Router (DLR) in ECMP mode, specifically this diagram from the Architecting a VMware vCloud Director Solution –
As shown in the diagram above – How does Usage Meter handle bill these tenant virtual machines (VMs) when we have a provider NSX architecture that utilizes ECMP?
For you TL;DR readers – any VM connected to a Tenant Edge / direct network that has ECMP enabled northbound, NSX Advanced will be charged for said VM. Read on if you want to learn how this is done.
First off, let’s talk about why this matters. Per the Usage Meter Product Detection whitepaper (this can be found on VMware Partner Central), we can see how Usage Meter detects specific NSX features based on the pattern of usage. Regarding dynamic ECMP, it is metered by the “Edge gateway” which could be a little ambiguous. If one utilizes ECMP, they would be metered for NSX Advanced within VCPP.
One of the scenarios from the whitepaper does show ECMP-enabled Edges but not an Edge that is abstracted away from the provider environment –
My initial reaction was that Usage Meter would not look at the northbound provider configuration and the interconnectivity to vCloud Director. However, I was not confident and wanted to verify this explicit configuration and expected metering. Let’s review my findings.
In the above diagram, we can see I created a similar Provider managed NSX configuration with ECMP enabled from the DLR to the two Provider Edges with dynamic routing enabled (BGP). From there, I expose a LIF/Logical Switch named “ECMP-External-Network” to vCloud Director that is then exposed to my T2 organization as a new External Network.
From there, I created a dedicated Tenant Edge named “T2-ECMP-ESG” that will be attached to this newly created network along with a VM named “T2-ECMP-VM.” The goal is to verify how T2-ECMP-VM and T2-TestVM are metered by Usage Meter with this newly created Tenant Edge.
My Edges are setup for BGP and reporting the correct routes from the southbound connected DLR (and tenant Edges) –
From the DLR, we can see that I have two active paths to my Provider Edges (Provider-Edge-1 and 2) –
Last of all, my T2-ECMP-ESG is operational and attached to the newly created ECMP External Network –
Last of all, I have my VM’s created and powered on (remember, Usage Meter will only meter powered on VM’s). We can see T2-ECMP-VM is attached to a org routed network from T2-ECMP-ESG named “T2-ECMP-Network” –
Let’s work from the north to south – start with the Provider Edges and show how Usage Meter detects and bills.
Note – I have vROps Enterprise in my lab environment, so we will see Usage Meter picking up vROps registration and placing it in the appropriate bundle.
Provider Edges / DLR
As expected, the Provider Edges and DLR are detected along with registration to vROps. By design, NSX Edges are charged for the Advanced SP Bundle as they are metered as a management component (minimum Advanced bundle / 7-point). However, in my case, we see detection, and then registration to vROps Enterprise. Therefore, since it’s a bundle ID (BND) of 12, this is correlated to Advanced Bundle with Management (10-point) –
Tenant Edge – T2-ECMP-ESG
Just like the Provider Edges and DLR, we see T2-ECMP-ESG register to UM along with vROps Enterprise registration. Same billing model as above.
Tenant VM – T2-TestVM
I would not expect any change to this VM, but wanted to showcase that having a separate Edge with standard networking (i.e. no ECMP) will bill based off the NSX SP Base level. As expected, T2-TestVM was handled by Usage Meter just as anticipated – we can see registration, NSX SP Base usage, along with registration to vROps Enterprise –
Tenant VM – T2-ECMP-VM
Finally, let’s take a look at my T2-ECMP-VM – as discussed before, this is wired to a Tenant Edge that is connected to the ECMP-enabled DLR via an External Network.
We see initial registration, registration to vROps Enterprise, then NSX Advanced usage! This would be metered at Advanced Bundle with Networking and Management due to the NSX Advanced usage (12-point).
Summary of Findings
Here’s what we learned:
Edges/DLR Control VM’s are not charged for NSX usage since UM handles them as a management component. If you are using vROps, it will place it in the most cost effective bundle.
Utilizing ECMP at the provider-level DOES impact any southbound connected VM from a billing perspective, even if an Edge sits in between the ECMP enabled configuration and the tenant VM. Per the findings, NSX Advanced will be metered.
Therefore, be aware of any NSX provider architecture and the use of NSX specific features.
Again, this shows the logic inside of Usage Meter and how it relates to metering for tenant workloads. Cheers!
Many of you may be aware of the new VMware Specialist – Cloud Provider badge. However, I am going to spend some time to highlight the effort and provide some guidance on this new badge/exam. Also, it’s officially announced with many of our other great announcements at VMware Europe!
What is it?
Well, the Specialist Cloud Provider badge is a renewed effort that the VMware Cloud Provider team is establishing a solid, fundamental certification/qualification platform for our Cloud Service Providers. This is the first step on setting a level of qualification to present solution knowledge around the VMware Cloud Provider Program (VCPP) stack and solution-set, especially VMware vCloud Director for Service Providers 9.x.
This is an online, un-proctored, exam that can be scheduled through Pearson Vue. The only prerequisite we’ve established is an active VCP certification. I was honored to be part of the team to develop this exam while Wade Holmes led the overall effort with many of my esteemed peers. It is 40 questions and you have 60 minutes for the exam.
What does it cover?
Just like with any other VMware certification – read, read, and read the blueprint: all of the answers are there. I believe the team did a great job of putting many links into this blueprint for material to prepare for. However, I’m going to highlight a few points that everyone should be aware of –
This exam covers vCloud Director 9.1 functionality. Even though 9.5 is out as of this blog post, this was written when 9.1 was the current release.
Sections 3, 5, and 6, are not present on this exam. Therefore, there are no troubleshooting questions. Be prepared to focus on core fundamentals and conceptual features of vCD.
vCloud Availability for Cloud-to-Cloud 1.5 is present also on this exam, there is no vCloud Availability for DR questions. Moreover, vCD Extender is also present.
How can I prepare?
This answer is simple – work with vCD and the VCPP stack and you’re golden! 🙂
On a serious note, there’s a lot of great material on the blueprint, but we have two great VMware Education courses on vCloud Director:
VMware vCloud Director Fundamentals [V8.x] – this is an on-demand course that goes over core fundamentals of vCD. While it is dated for 8.x, it is very applicable. This is a self-paced course and can be done in about 3 hours.
I believe this is a very fair exam for individuals that work with the VMware Cloud Provider solution set. The questions and concepts focus on the value and core fundamentals.
I’ve been receiving a lot of great and positive feedback, which is excellent. This was my first exam creation experience and I truly enjoyed the process, and look forward to the next step for our VMware Cloud Providers. If you’re at VMworld Europe, please don’t hesitate to contact me to meet up! Thank you.
The VMware Cloud Provider Software Business Unit has released the next iteration of vCloud Director – version 9.5. We’ve been holding to a six month cadence on major releases and this vCD version does not disappoint.
UI continues to get better and better for Tenants and Providers. With 9.5, I would say the UI is about 98% completed – most of the tenant functions should able to be accomplished through the H5 UI. In this release, RBAC capabilities are also introduced (more on that shortly).
As we can see here, we now have a ribbon at the top along with recent tasks.
This is a nice function that’s native to the H5 UI – we now have the concept of roles within the roles based access control. A Provider Admin can now “templatize” roles based off of specific functions and make it easier to manage specific tenant rights.
Cross-VDC Networking / Cross vCenter NSX Support
With vCD 9.5, we now have the ability to support xVC NSX objects inclusive of setting this up the vCD UI. Moreover, vCloud Director will instantiate the stretched network functionality to up to four orgVDCs.
This is done from the Provider set up by establishing a network provider scope –
And as expected, requires a single SSO domain between linked vCenters to support cross vCenter NSX. I am underway in my lab to test this out and will have a post soon on demonstrating this functionality and what’s possible.
vCloud Director Cell Appliance!
Yes, you heard that right – with this release we’ve introduced the vCloud Director cell appliance. This is pre-built PhotonOS appliance with the vCD code but still requires your backend vCD database (please use Postgres!), Cassandra, RMQ, and NFS share.
Please also deploy this with the Flex client as I have not seen success with the vSphere H5 client. This is the first iteration and I’m hoping the next version we will see a “database” appliance for the backend functions.
I love this, especially when I’m using vCloud Availability for Cloud to Cloud. With 9.5, the UI extensibility continues to grow. There are some amazing plans as it relates to plugin support for our ecosystem partners and I’m seeing MANY of our partners create plugins for vCD. The possibilities are great here to showcase value added services for your tenants.
As we can see below, this is one of my deployments with C2C and showcasing the C2C plugin for 9.5 –
Again, an exciting release for vCloud Director – and more on the way.