If you are looking to try out vRA7 integration with NSX make sure you upgrade your NSX deployment. This update include support for the NSX 1.0.3 vRO plugin needed for vRA integration.
New in 6.2.1
The 6.2.1 release delivers a number of bug fixes that have been documented in the Resolved Issues section.
6.1.5 fixes: Release includes the same critical fixes as NSX-vSphere 6.1.5 content.
Introduced new ‘show control-cluster network ipsec status’ command that allows uses to inspect the Internet Protocol Security (IPsec) state.
Connectivity status: NSX Manager user interface now shows the connectivity status of the NSX Controller cluster.
Support for vRealize Orchestrator Plug-in for NSX 1.0.3: With NSX 6.2.1 release, NSX-vRO plugin version 1.0.3 is introduced for use with vRealize Automation 7.0.0. This plugin includes fixes that improve performance when vRealize Automation 7.0 uses NSX for vSphere 6.2.1 as a networking and security end point.
Starting in 6.2.1, NSX Manager queries each Controller node in the cluster to get the connection information between that controller and the other controllers in the cluster. This is provided in the output of the NSX REST API (“GET https://[NSX-MANAGER-IP-ADDRESS]/api/2.0/vdn/controller” command), which now shows the peer connection status among the controller nodes. If NSX Manager finds the connection between any two controller nodes is broken, a system event is generated to alert the user.
Service Composer now exposes an API that enables users to configure auto creation of Firewall drafts for Service Composer workflows. This setting can be turned on/off using REST API and the changes can be saved across reboot. When disabled, no draft is created in the Distributed Firewall (DFW) for policy workflows. This limits the number of drafts that are auto-created in the system and provides better performance.
Many of you have already heard the news about vRA7. Now that it has been officially announced I can start to share some useful information regarding this transformative release of vRealize Automation. I want to start by stating I cannot discuss anything related to GA release date so don’t expect to find anything related to when this will be released. This article is aimed to give you an overview of some of the great new features coming in version 7 and as the starting point for a series of vRA7 walk-through articles.
vRealize Automation 7 Installation
I think you are all going to be very pleased with the new installation wizard. It takes 98% of the pain out of deploying vRA, and let’s face it, it wasn’t that difficult in the 6.x release. To start much like the vRA 6.x installation process you will need a Windows Server available, but you no longer have to make sure you have all the pre-requisites completed. The only pre-requisite you will need is to install a simple installation agent on server and that’s it. The installation will not only check for the pre-requisites, but it will allow you to resolve them if they are not met.
The installation also now let’s you choose between a simple installation and a fully distributed installation. This is huge. If you have ever done a distributed installation this is where most of the pain was felt. VMware has truly raised the bar and done a fantastic job with the installer.
Identity Management
Not a fan of the SSO solution in previous releases of vRA? Then you are in luck. vRA7 no longer uses the Identity Appliance and VMware SSO. It leverage VMware Identity Manager. There are so many great aspects to this welcomed change starting with one less virtual appliance to deploy. That’s correct Identity Management is built in to the vRA virtual appliance. Besides simplifying the installation it will also simplify integrations giving you the ability to authenticate a user via an external source and pass that token to vRA preventing the need for the user to login yet again. Look for some more in-depth articles coming on this soon.
Unified Blueprints
Blueprint creation just got a whole lot easier and a whole lot more feature rich. For those of you who have been using vRA 6.x you are going to really appreciate the new Blueprint designer. Drag and drop templates, networks, applications, XaaS workflows on the canvas and build your blueprint visually. This is just the start. Remember the 6.x NSX integration? Remember how it only worked with multi-machine blueprints? Guess what? That is no longer the case. Add one machine add ten is doesn’t matter. Use existing networks, create new ones, assign securty tags, security groups, load balancers, and more. It’s like those old Prego commercials…..”It’s in there”. Are you an application services user? Remember having to pull in the single machine vRA blueprints to use with App Services and then publish them to the vRA catalog? Guess what? You guessed it. If you want to deploy an application to a template on your cancase, you just drop the application on to the template. Look for a lot of great articles to come on this.
Blueprints as Code
Ever wish you could export and import blueprints? Wish no more! vRA7 features the ability to export you blueprints as code. Once exported you can manipulate the file is needed and import into another vRA7 or the same vRA7 instance. Imagine exporting your bleuprints checking it into GIT for version control and running those bleuprints builds through Jenkins to facilitate new “builds” and then importing it back into vRA7. Well no need to image because it’s all possible. Another feature to help with the transformation to DevOps.
Enhanced Extensibility
Just when you thought it couldn’t get any better, it does. The new event broker system in vRA completely transforms how you will integrate to 3rd party systems in vRA7. Some of the features here include dynamically assigning workflows to builds based on filters. Remember how complicated it could be get the right workflows to run based on custom properties? Well this if the possibilities, trigger a workflow based on the requestor, the machine name, the blueprint, and more…..and this is just one of the cool features of event broker. Use event topics such as Post Approval, Pre Approval, Blueprint configuration, resource reclamation, Business Group Configuration, XaaS, Machine LIfecycle, and Machine Provisioning. Look for a whole ton of articles on this as well as new releases of workflows based on this new event broker.
These are just some of the great new features in vRA7, I can’t wait to start posting new articles on how to works with the awesome new features.
There is not really much I can add to the debate on NSX vs ACI except to share my opinion on a few things.
Let’s look at the world as it is today. It is a virtual world. At least 80% of workloads in most datacenters today are virtualized. So that leaves roughly 20% of workloads as physical. How often do physical workloads move to different servers, racks, datacenters etc? Not very often right? You rack them, you cable them, you plug them in, you configure the port(s) and that is basically where it lives for the rest of it days. Any rules or policies you need for those machines get created and that’s it.
For all of you that have been patiently waiting for NSX 6.1.3 so you can upgrade to vSphere 6, your wait is over! VMware has relaeased NSX 6.1.3 today and it is now live for download. On top of support for vSPhere 6 it also includes a number od security and bug fixes details can be found in the release notes.
NSX vSphere 6.1.3 introduces the following features:
Dynamic routing protocols are supported on sub-interfaces.
ECMP and Logical Firewall are supported at the same time with logical routing.
So vSphere 6 launched last week and you want to kick the tires in your lab. Hopefully before you install you head on over to VMware and check out the Interoperability Matrixes. I’ve been reading posts online about folks jumping in with both feet and just straight out upgrading to vSphere 6. Of course I may have been one of those people myself.
I being who I am got all excited over the vSphere 6 release and all the new features it offers cracked open the upgrade guide and went all in with the vSphere 6 migration utility and migrated my vCenter 5.5 server to vCenter 6. That’s half the battle right. Get through the migration and everything will be golden. Not quiet. After the migration, (which went fairly smooth by the way) I launched the vSphere web client and went to login and noticed I was not able to login as myself. Luckily the administrator@vsphere.local account was able to login with no issues. I then started poking around and noticed I no longer had a link for Networking and Security.
This is something that has been long sought after by many. The hardening guide is 38 pages long packed with hardening information for the vRA Appliance, IaaS Server, Identity Appliance, and Application services appliance. This document takes you through the hardening of the SLES 11, PostgresSQL, Windows Host including SQL Server, IIS, and Microsoft .Net. The hardening guide also covers the network security and securing communications between the vRA components.
The network security section of the guide includes a complete list of all the vRA components and the ports/protocols that are used by the component. Even if you are not ready to start creating a fully hardened deployment it’s worth taking a look at the guide and becoming familiar with the the communications between the different components.
If you are currently running NSX for vSphere 6.1 you will be happy to hear that that NSX 6.1.2 for vSphere has been released. In it is a number of bug fixes that I am particularly happy about. One fix in particular that I am very happy to see is:
vNICs get ejected because of insufficient ESXi heap memory – I ran into this in the MoaC Lab and of course it took some time to track down and get resolved. Aside from being a difficult bug to diagnose it caused secondary issues that were just a pain. So glad to see this one is taken care of.
Poodle Vulnerability – This release includes an API call that you can use to diable SSL v3 on specified NSX Edges.
OpenSSL – Has been upgraded to the 101j release
UI Fixes – Not yet sure which ones.
Security Group Parallel Creation – has been added. This should help in the over time it takes to deploy App Services in vRealize Automation.
VPN Fixes – I’m not sure on what these fixes are, but I hope there is a fix for OSPF updates over Layer2 VPN. I will surely let you know once I find out.
There is more details on the the NSX for vSphere 6.1.2 release in the release notes.
One-to-One NAT environments allow you to perform both SNAT and DNAT for all machines provisioned behind and NSX Edge Gateway. For each machine provisioned onto the One-to-One NAT network an External IP is added to the Edge gateway for the NAT translation. The External IP is assigned from the External Network Profile that is assigned to the One-to One NAT Network Profile. Although the One-To-One NAT network will use NAT translation to communicate with the upstream networks (North – South) it is routed to other networks connected to the same NSX Edge Gateway. When deploying a multi-tier application that has multiple network tiers attached to an NSX Edge Gateway all the back-end networks are routable so it’s important no to re-use IP space across different Network Profiles.
In the below diagram there are three Multi-Machine apps. Each one has three web servers, two app servers, and two database servers. The database servers are on a private network, no NAT translation to the upstream networks. The App servers are using a One-to-Many NAT network where they are using SNAT to get access to the upstream network, and the Web Servers are using DNAT for both inbound and outbound traffic. You will notice that each of the Multi-Machine Apps are using the same Up address on the backend, however the IP’s assigned to the NSX Edge Gateway’s external interfaces are different. Notice for the One-to-One NAT that there is an equal number of external IP address. Lao notice in this scenario where we are using both One-to-One and One-To Many the external IP’s are on the same subnet. They all should come from the same External Network Profile that the related to the network that the NSX Edge Uplink interface is provisioned to.
Private networks have no upstream (North – South) NAT or routing when they are deployed. They are networks attached to the deployed NSX Edge Gateway that have East – West routing to other netowrks attached to the same NSX Edge Gateway and that is it. Due to this unlike the other NSX related Network Profiles we can create the Private Network Profile does not need to have an External Network Profile attached to it. It’s simply a range of IP’s to be used for the machines provisioned on to the network.
In the below diagram the blue network will be my private network. Machines placed on the blue network will only be able to communicate with machines placed on the orange or green network and not anything upstream. I can also limit it’s communications further by using security policies which we will discuss as a separate topic
When configuring a NAT Network Profile you have two options. You can configure a one-to-one or a one-to-many. Here we are going to walk through creating a one-to-many NAT Network Profile. One-to-many NAT network are networks that do source NAT only. This will allow any machine provisioned onto the network to communicate out of the network under one IP address, however there is no NAT translation configured to come into the network for any services. When you use a one-to-many NAT network profile in a Multi-Machine Blueprint an NSX Edge Gateway will be deployed, however routing will not be enabled and a Source NAT rule and relevant firewall rules will be created. NAT network get IP address from a pool of IP’s that will be reused over and over again for each deployment. The nature of NAT let’s us reuse the IP’s because the different apps being deployed will all communicate using unique IP address on the outside of the provisioned Edge Gateway. Although I am using a class C network in my example I really don’t need to. If I will never have more than six machines on the NAT network I could use a /29 network if I wanted to, but for simplicity I used a class C and assigned a fairly large range……just in case 😉
In the below diagram I’m going to represent the orange network as a one-to-many NAT network. All machines provisioned behind the router will get an IP address from the NAT Pool and all will SNAT to the upstream network as the external IP address of the router. The external IP is assigned from the External Network Profile that is assigned to the NAT Network Profile.
