A deeper look at vCloud Director and NSX Distributed Logical Router and Firewall Services with Usage Meter feature detection

Need to work on my titles, but that’s what I have for now. I want to spend some time reviewing how NSX Distributed, Edge, and DLR Firewall services behave in respect to vCloud Director and vCloud Usage Meter.

Some may know vCloud Usage Meter provides automated feature detection on a per-VM basis – essentially allowing granular-level billing for tenants. For example, tenant ACME may have 5 VM’s that need Distributed Firewall out of 20 – why charge them for all if they aren’t using it? Since version 3.6 of Usage Meter, this feature has been applied on a per VM level, for the most part.

There are three different versions of NSX available in the Cloud Provider Program –

We can see that your basic fundamentals are available in SP Base: your distributed switching and routing, Edge Firewall services, NAT’ing, etc. Advanced adds in Distributed Firewalling, Service Insertion and other advanced functionality while Enterprise is adding in X-vCenter NSX, HW VTEP integration.

Second, let’s take a look at the chart for NSX Editions by Feature. This comes from our vCloud Usage Meter Feature Detection whitepaper. Don’t have it? Get on VMware Partner Central and grab a copy.

Take note at the statement of “All VMs on all networks serviced by the edge” – this means even if you have a VM on that edge that does not use that feature, it will charge for it since it still has access to it. For example, if you set up a L2VPN on an Edge, be aware that any other connected networks will be charged for NSX Enterprise even though they may not be able to traverse to that tunnel!

Lab Setup

I wanted to design a DLR environment within vCD along with using Edge and Distributed Firewall rules. I came up the following design in my 9.x environment:

  1. Creating an NSX Distributed Logical Router (DLR) is pretty easy. Select the Advanced Gateway box and check Enable Distributed Routing. You can also enable Distributed Routing on any existing Advanced Edge – 
  2. The great thing about how vCloud Director creates Distributed Routing is it’s actually two Edges – a standard perimeter edge along with the DLR southbound. The transit interface is created as a /30 while applying static routes for any connected DLR interface. DLR’s default gateway is the Edge transit interface. Below is what I can see inside of NSX. 

Using the NSX Distributed Logical Router is in the NSX Base bundle and covered by Advanced SP Bundle, which is great for providers. However, Edge Firewall services are only available in the NSX Base bundle, where some providers may want to provide “high-powered” firewalling services.

The key difference between Edge and Distributed Firewall services is we do not hairpin for forwarding decisions in the DFW model: the decision is made inside of the hypervisor before the packet ever egresses anywhere. Hence, provides better throughput and capability compared to Edge or traditional firewall services – check out Wissam’s discussion on DFW capabilities here. 

vCD Access to Edge Firewall vs Distributed Firewall

I think Tomas did a great job of summarizing vCD Firewall capabilities and pointing out some of the architecture differences between the two firewall technologies.

From a vCD UI access point of view, you have to access the firewall services in two different places.

  1. Edge Firewall services are accessed by right-clicking on the Edge Gateway and selecting Edge Services. Makes sense, right? 
  2. Now Distributed Firewall management is accessed by right-clicking on the organization VDC and clicking on Manage Firewall. Not my favorite and doesn’t state DFW, but this is how it’s accessed today in the Flex UI. 

NSX Distributed Firewall Changes

Okay, let’s get into a few scenarios and test out how Usage Meter will put up the changes.

  1. I freshly created my three vApps: T1-App-1, T1-DB-01, T1-DLR-tclinux-01/02a (Web Servers). We can run a VM History Report and pick them up and see they all have been associated with the Advanced Bundle initially. I will try to point out the vROps and NSX column in the following discussion, but we will be looking for a checkmark and an “A” that refers to Advanced usage. 
  2. So let’s go ahead and crack open the DFW and start carving up some rules. This is a simple 3-tier architecture so I’m going to lay out allowing web, web to app traffic, app to DB, allowing SSH to App and DB, and blocking everything else in Web, App, and DB Tiers. 
  3. As you can see, the Applied To for my deny rule is only applied to my three Distributed Routing tiers (or routed Org VDC Networks). Not only is this a good NSX practice, this cuts down on who gets charged for NSX Advanced!
  4. Now looking at the DFW rules from vCenter, I can see vCD created the tenant folder and applied the policies in order. Very streamlined. 
  5. Now let’s check to see if my new rules work. Yep, I can still SSH to my VM’s but do not receive any ICMP replies. Perfect! 

How did Usage Meter detect the changes?

  1. So let’s now take a look at the Usage Meter VM History Report. What’s fascinating is Usage Meter tracks every move called state change. We can see in my tclinux-vApp (or Web) that it tracked when it started using Base NSX usage, then switched to Advanced, then my vROPs Enterprise instance picked it up and added it to its inventory. All in a very short timespan. Very useful! 
  2. With the DB and App layers, we see something very similar – vROps Enterprise, however, picked up these VM’s first and then we see Advanced NSX usage. 
  3. Now, I can see a few new line items populated on my Customer Monthly Usage and Monthly Usage report. I now see Advanced Bundle with Networking, Advanced Bundle with Management, Advanced Bundle with Networking and Management.
  4. This is to be expected since my VM’s went through a few iterations – my Web VM’s initially went with NSX Advanced without vROps which falls in the Advanced with Management while DB/App started using NSX Advanced without vROps registration (Advanced with Networking bundle). Last of all, all three are now assigned to the Advanced w/Networking and Management since we are using NSX Advanced features along with vROps Enterprise.
  5. While I see the new line items, I don’t see any units to be reported. Why? Well, I have some very small VM’s (256MB in vRAM) and they just ran a few hours during this testing. Keep in mind Usage Meter averages out the usage over the entire calendar month (720 hours for a 30 day period or 744 hours in a 31 day period). Again, to be expected but was pleased that new categories were added immediately.

In summary, Usage Meter does a great job of detecting NSX feature usage and bills it accordingly based on a specific service – Distributed Firewall being one of them. Thanks!

-Daniel

New VMware Cloud Provider Hands on Labs (HOL) Available!

I’ve been bantering on vCloud Director 9 and Usage Meter for some time now – wouldn’t it be great to test out these great solutions on-demand and at no charge? VMware HOL is the way to go

Well, here you go. My esteemed colleague, Eric Stine, has been working significantly on updating the VMware Hands-on Labs (HOLs) for our VMware Cloud Provider partners to utilize and demonstrate the functionality.

For the first HOL, we have introduced our standard, multi-tenant vCloud Director stack that shows the key features of vCD. This has been updated to version 9.0 to see the new functionality that we’ve been discussing. This is a great way to experience the new tenant HTML5 interface, play with NSX Distributed Logical Router conversions inside of vCD, and many other items.

Launch the vCloud Director HOL here

Second, we have the VMware Cloud Provider Program – Tools and Offerings HOL that has a lot of other affiliated goodies. You will see the following in here:

  1. vRealize Operations with our Tenant App for vCD – check out Sean Smith’s install review of the Tenant App for vCD
    1. Another value add that provides vROps data inside of a multi-tenant and vCD hierarchy.
  2. Usage Meter
    1. Everyone’s favorite metering tool – this is inclusive of 3.6x which provides feature detection based on itemized VM billing.
  3. vCloud Availability

Launch the Tools and Offerings HOL here. 

Happy HOL’ing!

-Daniel

 

No, vCloud Director is not dead.

While my title is a little facetious, I’ve been meaning to discuss VMware vCloud Director from the big picture and what it means for our Providers and cloud consumers.

To start out, this is my opinion only and not a reflection of my employer. I am also going to stipulate that I’m bringing a newer opinion to vCloud Director as I’ve only immersed myself into vCD for the past year or so.

During my tenure at VMware, it seems there’s a common thread or opinion where many people (internally and externally) believe vCloud Director is no longer a viable or supported product. After understanding some of the past decisions, I can understand some of this perception, but this is definitely not the case. In this post, I’d like to “clear the air” on a few items I hear quite often.

This is going to be boiled down to the following points:

  1. So, is vCloud Director dead?
  2. vCloud Director is hard to use.
  3. But what about vRealize Automation / VMware Cloud on AWS vs. vCD?
  4. vCD is not about IaaS anymore.

So, is vCloud Director dead?

It is not. Currently, vCloud Director for Service Providers (vCD) is only available for new providers inside of the VMware Cloud Provider Program. There are some exceptions (entities that owned vCD before there was a directional change) but this is the only way to procure vCD at this time.

Moreover, the development lifecycle has significantly increased in the time I’ve been here. When I joined VMware, we just released vCD 8.20. Since then, we’ve had version 9.0 and 9.1 come out with some significant additions – this presents a picture that one should expect vCloud Director additions every six months. Below is what we’ve delivered in the past few years –

While I won’t comment about futures of vCD, one can already see the direction VMware is going with vCloud Director – enabling ease of consumption in a multi-tenancy architecture.

vCloud Director is hard to use.

I’ll agree with this commentary – in the past. Starting with 8.20, VMware introduced the Advanced Networking HTML5 interface as the first foray into a newer, streamlined interface that’s not based on Flash.

Within version 9.0, the first phase of the HTML5 Tenant UI was rolled out. 9.1 added additional content along with the first (albeit limited) release of the Provider UI. 9.1 added the HTML5 web console, HTML5 OVA import, and integration with the VM Remote Console – mitigates most of the complaints I hear from end-user experience.

The overall goal of the interface is to provide a streamlined user experience. Currently, there are advisory boards going on reviewing what’s needed from the provider and tenant UI experience. I can tell you this is top of mind for everyone in the team.

Here are some of the tenant experiences from the 9.x interface –

We can see the multi-site view from here – 

While 9.1 now has the Provider UI. Again, the first iteration but gives you a feel for what’s available today –

As you can see above, I’m highlighting the new integration of vRealize Orchestrator (vRO) inside of vCloud Director. This allows us to provide XaaS which many of you are well aware of its comprehensive capability inside of vRA and other automation solutions.

But what about vRealize Automation / VMware Cloud on AWS versus vCloud Director?

Let’s nip this in the bud – it should NOT be about competing solutions when we discuss use cases. Today, many of our Providers run BOTH vCD and vRA in their environment serving different use cases! Both have great use cases and are based on what the design requirements dictate. I can think of one provider I collaborate with that utilizes vRA for dedicated private cloud environments while allowing their tenants to carve out VM’s when required in their vCD environment.

With the newest release of the VMware Cloud on AWS Managed Service Provider (MSP) platform, this will also be another function for Providers.  It should not be about either-or, but more of how does it solve X…

Ultimately, this comes down to two things:

  1. Use Cases
  2. Customer Experience and Expectations

First, let’s cover vRA –

Today, vRealize Automation and vCloud Director can integrate with one another. vRA can call vCD as an endpoint and automate vApp/VM creation. Moreover, they serve two different landscapes from a provider experience. I wouldn’t disagree that vRA has refined services platform capability but today it cannot provide provider-level multi-tenancy. Let me make this clear – vRealize Automation and vCloud Director are great products. It just boils down to what you’re trying to achieve.

Below is a comparison sheet I’ve used in the past when talking to Providers about the differences between vCD and vRA – some of the points can be argued either way but gives a high-level idea of the capabilities between the two solutions. Advanced Services Designer (XaaS) has a half check mark for vCD since it’s not as comprehensive as vRA.

Let’s briefly talk about VMware on AWS. This is an amazing way of providing an entire Software-Defined Data Center (SDDC) stack inside of a hyperscale environment in a matter of a few hours – from start to finish. This also fills a need for Virtualization teams that want a vCenter-like user experience in a cloud environment.

However, in the context of vCloud Director, couldn’t this just be another Provider VDC we could call on to gain additional resources? Please do not take this as a directional statement as it’s not (and not supported today) – but the point I’m making here is vCD with VMware Cloud brings quite a bit of possibility.

The point is vCloud Director can add value to any type of elastic model. Who knows what the future can bring?

vCD is not about IaaS anymore.

Sure, vCloud Director got its start around Infrastructure as a Service. I think we can all agree that the technology field as changed quite a bit when the first iteration of vCD was released.

I see vCloud Director evolving into this Services Platform that is much more than just IaaS. I believe this is a fair term, especially on what was released with the most recent versions. Let’s go into some of the details on why I believe that.

vRealize Orchestrator Integration – XaaS anything

This is a big one. We can now provide native integration to any type of vRO workflow – think of the possibilities:

  1. Ticketing System
  2. Backup Request
  3. Provision a Service

All done through the native vCD HTML5 UI. 

I know our team is working on bringing additional examples to market, so stay tuned for those.

Container Service Extension / Python CLI and vCD CLI

To cover the Container Service Extension (CSE), vCD 9.1 introduced the ability to support lifecycle management of K8s clusters through this extension. Cluster nodes are treated the same as VM’s while adding provider and tenant authorization, authentication, and metering per tenant.

Moreover, this is another net new line of capability inside of vCloud Director that Providers can harness.

The Python SDK and vCD-CLI were revived with 9.1 and updated on the GitHub locations (Python SDK here and vCD-CLI here). This allows admins and tenants to perform operations from the command line while getting full support for these operations.

The intent was to open-source this to get community feedback. If there’s something you’d like to see, please tell us!

UI Extensibility

This will evolve as this will be a play for our ecosystem partners. As I understand it, this is an Angular framework that can allow integration for pretty much anything inside of vCloud Director. Below is an example of a Ticketing system integrated into vCloud Director.

This will continue to evolve, but a Provider can use this framework and integrate pretty much anything inside of vCloud Director to provide a seamless experience.

Summary

So for those of you that tl;dr’d this blog post, let me sum it up – #longlivevCD 🙂

In all honesty, I’m very excited to see what the VMware Cloud Provider team brings next to vCloud Director because it continues to get better and better. This isn’t just me saying it too – talk to your network of Cloud Providers.

Cheers, and long live vCD!

-Daniel

vCloud Director – Key Differences in Edge Gateway Services (1 of 2)

Two-part vCD series since it was longer than I expected!

I had a question come in from a Cloud Provider on what are the actual key differences between a standard Edge Gateway Service and an Advanced Edge inside of the vCloud Director (vCD) User Interface (UI). While I could explain a few things on my own, I decided to do a little bit of legwork to confirm my suspicions. While some of you may already know the following, I thought this was an interesting exercise and wanted to share my results.

Before I get to that, I’m sure everyone is aware vCloud Director started off with vCloud Network and Security (VCNS) and this was the network backing before NSX. With recent versions of vCloud Director, everything is backed by NSX.

With that said, the Advanced Gateway experience is what VMware will eventually migrate to. Therefore, get used to the nice HTML5 intuitive and speedy UI! 🙂

Edges

In my vCD 9.x instance, I have two edges deployed:

  1. SiteB-T1-ESG is my advanced edge. I can verify this by right-clicking on the edge and seeing that I do not have an option to Convert to Advanced Gateway 
  2. Moreover, you can see I am running version 9.x of vCD – I can convert it to a Distributed Logical Router! 
  3. However, with my SiteB-T1-ESG-2, I can see it’s not an Advanced Gateway as I’m able to convert it 

Let’s get to the comparisons now. Again, this is going to be in the context of the UI – not going to talk about the API right now. Going to state the advantage based on service in the title.

Firewall Services – Advantage: Advanced Gateway

Advanced Gateway

  1. I can create granular firewall rules using grouping objects associated with the HTML5 interface.
  2. This provides a very similar experience to NSX within vCenter. To be honest, anyone that has used NSX should be able to figure this out very quickly.

Standard Gateway

  1. From the standard interface, I can only create rules from a IP/CIDR and key words such as “any, internal, external.”
  2. Pretty limited to say the least.

DHCP Services – Advantage: Advanced Gateway

Advanced Gateway

  1. From the DHCP subtab, I am able to establish pools, bindings, and relay configurations. Moreover, configuring IP Sets and DHCP Relay Agents.

Standard Gateway

  1. We have the ability to add a DHCP pool that’s applied on an internal network that’s connected to this ESG. Pretty basic capabilities, but works.

NAT Services – Advantage: Tie

Advanced Gateway

  1. Ability to establish Destination or Source NAT’s. I see the same options between both Advanced and the Standard gateway, so it’s hard to call an advantage either way.

Standard Gateway

  1. As stated with the Advanced Gateway, I have the ability to establish a DNAT or SNAT. Seems like the same options to me.

Routing Services – Advantage: Advanced Gateway

Advanced Gateway

  1. This seems like a night and day difference in routing options. I’m able to get an NSX-like experience from an HTML5 interface (that’s been around for over 1 year or so!)
  2. Ability to set ECMP, Routing ID’s, utilize OSPF, BGP, and Route Redistribution with prefixes to boot.
  3. If you’re used to NSX and applying routing configurations to an Edge, this is a very similar experience.

Standard Gateway

  1. Yeah, how do static routes sound to you? That’s all I can apply here from the UI.

Load Balancer – Slight Advantage: Advanced Gateway

Advanced Gateway

  1. The Advanced Gateway is very similar to what we see in NSX – just in an HTML5 format.
  2. We get to see our Global Configuration, Application Profiles, Monitoring, Rules, Pools and Virtual Servers.
  3. I also see we have additional algorithms available from an LB perspective. I wouldn’t say it’s a stark difference between Advanced and Standard, but more comprehensive than the Standard Gateway.

Standard Gateway

  1. Standard Gateway has very similar options as the Advanced UI, just in a different UI format.
  2. As stated above, we don’t have UDP available as a type and fewer algos for the Pool configuration. With that said, it’s very comparable, but giving a slight advantage to Advanced for some of the other options available.

More to come on Part 2 here.