vRA and NSX – Part 1, vSphere Prep

Introduction

There are a few prerequisite steps to complete on the vSphere and NSX side before vRA can be configured to consume its services or deliver on-demand networking and security. In Part 1 of this series, we will use the vSphere Web Client to review the NSX baseline deployment and add the necessary configurations for staging. What is configured here will depend on the desired objectives and use cases…I’ll cover minimum requirements.

Note: These steps assume you have already deployed NSX Manager, registered NSX with vSphere, and prepared hosts / clusters per best practice.

Objectives:

  • Review NSX deployment in vSphere to ensure prerequisites are in tact
  • Validate Logical Network / VXLAN configuration

As mentioned previously, this guide assumes a basic NSX deployment has been completed. This section will review the lab configuration and validate NSX has been properly deployed and configured.

1.  Log in the vSphere Web Client.

2.  Navigate to Networking & Security to review the existing NSX deployment configuration.

3.  Select Installation in the Networking & Security pane.

4.  In the Management tab, verify that at least one primary NSX Manager is available and at least one NSX Controller Node has been deployed (with status: Connected):

vra7-135

5.  In the Host Preparation tab, expand the target clusters and ensure Installation status, Firewall, and VXLAN are all showing a green check mark:

vra7-133

In this example, there are two configured clusters — Cloud Cluster and Mgmt Cluster.

vRA and NSX Integration Series

It should be no surprise that VMware is putting a lot of time and energy around the benefits of vRealize Automation and NSX. The #BetterTogether campaign has taken off and just about anyone touching either of these solutions should be able to articulate that message by now. I’ve been focusing on the integrations between vRA and NSX partly because it’s within my charter, but primarily due to being huge believer in the transformative nature of the technology behind it. Whether at a VMUG, in a briefing, building internal content, or in my home office as my puppy, Millie, begs to go out and play just as I start recording a video (it’s like clockwork!), this has easily become one of my favorite topics.

While the benefits are easily articulated and demos [usually] go off without a hitch, much of the feedback I get suggests there’s a perceived complexity with the integration. “Not so!”, says I. While complex is a relative term, integrating vRA and NSX doesn’t have to be, especially if you have a basic understanding of the two solutions individually. Although I will agree on at least one thing — while documentation is generally getting better, there’s still a major gap in prescribed [how-to] content.…

vRA and NSX – Using Baseline Security Groups

vRA and NSX came together back when vRA (a.k.a. vCAC) 6.0 was released, just as VMware was transitioning from vCNS to NSX. In vRA 6.x, inventory-collected security groups must be selected (checked) per Reservation prior to being available for consumption by a multi-machine blueprint (and only MMBP’s support NSX in vRA 6.x). As I’ve highlighted several times before, the latest release of vRealize Automation (7.x) delivers deeper integrations with NSX and unified service authoring capabilities to make delivering application-centric networks the new norm. See this post for how vRA and NSX are better together…I won’t repeat those details here.

With vRA 7’s deeper integration and broader use cases, one hugely powerful feature is the ability to incorporate one or more NSX Security Groups — either Pre-Existing or On-Demand — into your service design using the new Converged Blueprint Designer (CBP). You simply drag-and-drop the security group right on to the unified canvas and bind it to the desired machine components…

vra-cbp-nsx-sg

nsx security groups in vra

As a result, the provisioned machines are automatically added to the security group (Existing Security Group) or a new security group is dynamically created and bound to an existing security policy at request (On-Demand Security Group).…

vRealize Automation and NSX – Better Together

One of the hottest topics in the world of software-defined everything is unequivocally NSX. This rocketship of a technology is fundamentally changing datacenter design — much like vSphere so effectively did (except at a greater pace). NSX redefines how networks are built, consumed, and managed. Even more importantly, security no longer has to be compromised due to the the prohibitive cost of per-application policies. And best of all, this all done with software. That’s a good thing since we’re at the start of a software-defined revolution, quickly breaking out of our hardware-defined chains.

I can go on and on, but this post isn’t about how awesome NSX is…not entirely anyway.

Making Awesome…Awesomer

So how do we take awesome up another notch? Easy…automate it (i’m sure you figured I’d say that). And not just automate in the “I’ll run a fancy custom script or workflow as soon as the request hits my desk”. While that’s neat — and congrats on putting in all the work for building those static processes (also, good luck handing those proprietary scripts over to the next admin when LinkedIn recruiters finally land you) — that’s not what I’m referring to. Automation in that sense has been around for decades and traditionally misses two of the worst choke points in IT — People and Process.…

NSX Uncovered – Part 2, Solution Overview

Network virtualization is by no means a new concept for VMware. Think about it for a moment — wherever vSphere (or any other VMware T1 or T2 hypervisor) has been implemented, a virtual switch exists and connects guest VMs to the physical world. That’s more than 500,000 customers globally, millions of vSphere hosts, and many more millions of virtual network ports backed by a standard (vSwitch) or distributed virtual switch (dvSwitch). In fact, if you count the network ports provisioned by vSphere and logically assigned to VM nics, one can argue that VMware is one of the top datalink providers on earth. Okay, perhaps that’s a stretch, but you get my point! VMware virtual networks have existed just about as long as VMware itself. And since the very beginning, there has been no shortage of innovation. The vSwitch has evolved in many ways, leading to new technologies, increased scope and scale, distributed architectures, open protocol support, ecosystem integration, and massive adoption. Over the years VMware has continued to introduce new networking technologies through organic maturity and strategic acquisition — ESXi platform security, dvSwitch (and associated services), vShield, vCloud Networking and Security (vCNS), etc. — and leveraged 3rd party integration into partner solutions, such as Cisco’s Nexus 1000v (a solution brought to market by tight collaboration between VMware and Cisco).…

ProTip – vCAC 6.1 and NSX 6.1 Integration

vCAC 6.1 added a ton of integration with NSX 6.1 using a series of vCO Workflows, UI’s, and API integration. Although the logic is in the code, there are a few steps needed to get things going…

For starters, be sure to configure a vCO Endpoint (Infrastructure tab -> Endpoints -> Endpoints). In a POC or small environment you can point to the embedded vCO instances that ships with the vCAC VA. Otherwise point to an external vCO instance (note: if using an external instance, be sure to install the NSX 6.1 vCO plugin first).

Once the vCO Endpoint is configured, it’s time to add NSX support to the vSphere (vCenter) Endpoint. In vSphere (vCenter) Endpoint configuration, check the “Specify manager for network and security platform” box and enter the appropriate address / credentials for NSX. Be sure the account used has admin permissions (you can use the default admin account, or any account that has been added as NSX Admin users.

Check the logs to make sure no errors exist. You can also check data collection status (Compute Resources -> hover over appropriate cluster -> select Data Collection) and ensure “Network and Security Inventory” shows a successful collection.

NSX Uncovered – Part 1, Introduction

VMware’s Network Virtualization Platform, NSX, is an immensely powerful technology that can transform a datacenter’s infrastructure and streamline network service delivery across the enterprise. NSX’s scope, scale, and capability will easily impress techies, CCIE’s, and IT stakeholders alike. NSX changes the topology of a traditional hardware-bound network by eliminating the dependency on all that “intelligence” baked into proprietary hardware. Instead, the logic and associated services are delivered through a software control plane. Separating the control and data planes effectively reduces the physical network to a glorified IP packet forwarder.

With that said, it is also important to understand that NSX is not a re-write of your network and the fundamental concepts it is built upon. The abstraction of the logic from the physical underpinnings is a modern approach to designing, building, and servicing network architectures, but the fundamentals — the protocols, tools, concepts, etc. — are still at play. And for that reason, i’m often baffled when I enter into a debate with a “traditional” network engineer about the ins-and-outs of physical vs. virtual networking technologies like NSX. What I quickly realize is they are not defending the concepts or technology, they are defending their skill set. It’s a fear or reluctance of straying from what they know best.…