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 firstname.lastname@example.org 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.
If you read my blogs you know I’m usually all business talking tech and providing my readers with what I hope is useful information. Today I’m writing to ask for your support. My wife and I are raising money for Muscular Dystrophy by participating in the Harley Davidson Ride for life fund raiser. Last year Ride for Life donated $1.09M dollars to the MDA as part of this charitable event and hopefully this year we can raise even more.
My ask of you:
If you have found the information on this blog useful please show your support by donating to Ride for Life. My wife and I are trying to reach a goal of $3,000 raised for MDS through Ride for Life. Any donation you can make is greatly appreciated. You can make a donation by visiting my donation page at http://www2.mda.org/site/TR/General/22-NortheastDivision?px=3059956&pg=personal&fr_id=12249. For every dollar raised a matching donation will be made by VMware Foundation up to $3,141.59 as part of their Matching Gift program for employees. All donation must be in by 5/1/2015.
Regardless of whether you are able to donate or not I want to thank you all for following my blog and may you all have happiness and good health!
NSX for vSphere was released on December 4th and I’m sure you all dropped everything to get the bits upgraded in your lab environments. Good news is if your installs took as long as mine you might still have time to read this before they finish 😉 In all seriousness I would recommend setting aside a good amount of time. I have 3 clusters with a total of 8 hosts and 5 Edge Gateways it took a total of about 5 hours to complete the upgrade. Worst part is I told my wife I would be an hour and then we could go Christmas Shopping. Not good 😉 Good news is if you finish in 2 hours you get the rest of the day off. Seriously your boss called me and said that would be fine. Oh and if you are running EVO:Rail the upgrade only takes 1/4th of the time……. j/k.
To start you will need to download the upgrade bundle. IF you haven’t already I have the link in my post about the release.
First thing you will want to do before starting the upgrade is take a snapshot of your NSX manager Server. No seriously take a snapshot it will only add a few minutes to the overall time. Actually mine took a little bit of time to complete.
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.
The out of the box vCAC –> NSX integration requires the use of Multi-Machine blueprints. Multi-Machine blueprints are basically a blueprint that pulls together one of more single-machine blueprint. In order to create a three tier web application like the one I will be walking through we will need three standard blueprints to utilize within our Multi-Machine blueprint. In the below example will be configuring a Multi-Machine blueprint that will deploy an NSX Edge Gateway on to it’s own reservation and then deploy three different blueprints each onto a different network specific to it’s tier. Example below:
I will be walking through how to create a Multi-Machine blueprint that will build out the equivalent of the above diagrams Multi-Machine App.
When integrating vCAC with NSX you will need to configure reservations for use with NSX. Depending on your configuration you may need one or more reservations. One reservation for your provisioned workloads, and one reservation for the provisioned NSX Edge router.
You have the option of provisioning the Edge Router to the same reservation as the Multi-Machine blueprint, or you can specify a separate reservation for the Edge Router. In the MoaC lab I will be using a separate reservation for the Edge Router because all routers are to be deployed in the Management Cluster and all workloads in the Services Cluster.
Before we create the reservations we are going to create a Reservation Policy. Reservation Policies are basically a tag that allows you to target reservations that are assigned with targeted Reservation Policy.
Creating a Reservation Policy
Go to Infrastructure –> Reservations –> Reservation Policies
Select New Reservation Policy
Give the Policy a Name and click the green check.
That’s it. Like I said it’s just a tag.
Create a Reservation Policy to use with an Edge Gateway Reservation.
Routed Network Profiles have a very specific function. Routed Network Profiles are used in conjunction with NSX and Multi-Machine vCAC blueprints. Routed Network Profiles are used to define the networks that will be used by the Multi-Machine component machines. These networks will sit behind a deployed NSX Edge Gateway that is deployed as part of the Multi-Machine deployment.
While creating a Routed Network profile you will need to select an External Network Profile for the Routed Network profile to use. The External Network Profile is used to assign the IP address to the Uplink Interface of the NSX Edge Gateway that is deployed as part of a Multi-Machine Request. Routed Network Profiles also consists of IP Network Ranges, not IP address ranges.
IP Network Ranges are used to allocate a Range of IP’s to be used for a specific component Machine. An example would be if you have a web server component in a Multi-Machine blueprint and you want to deploy two of them. If the range was a /30 network range you would have two IP addresses available for your two web servers
Below is a diagram representing the Architecture of NSX when using Routed Network Profiles in vCAC. The External Network Profile that is defined in a Routed Network Profile if depicted as the Purple network in the diagram. As you can see in the diagram this is the Logical Network that connects the vCAC deployed routers to the pre-existing NSX Edge. The Green, Orange, and Blue networks represent the Routed Networks that are assigned from the Routed Network Profile.