VMware NSX

3. NSX manager deployment

Chan Leave a comment

Next: NSX Controller Architecture & Deployment ->

First deployement task involved in a typical NSX deployment is to deploy the NSX manager. The NSX Manager, which is the centralized management component of NSX and runs as a virtual appliance on an ESX host. This article aim summarise all the usual steps required to effectively plan & deploy this NSX manager appliance.

  1. Consider the pre-requisites.

    1. A dedicated management cluster:
      1. This is an important consideration. NSX manager needs to be deployed in a dedicated management / infrastructure cluster that is separate from the compute cluster (where all of your production VM’s live). The NSX installation and upgrade guide states this. ” VMware recommends that you install NSX Manager on a dedicated management cluster separate from the cluster(s) that NSX Manager manages. Each NSX Manager works with a single vCenter Server environment. The NSX Manager requires connectivity to the vCenter Server, ESXi host, and NSX Edge instances, NSX Guest Introspection module, and the NSX Data Security virtual machine. The NSX Manager should be run on an ESX host that is not affected by down time, such as frequent reboots or maintenance-mode operations. Thus, having available more than one ESX host for NSX Manager is recommended”
      2. The topic of a dedicated management cluster can be discussed in a post of its own. But for the sake of NSX deployment (and lot of other VMware products such as vRealize Automation…etc), a dedicated management cluster that is not dependent upon the compute cluster (where your production workload reside) is a must have requirement. You can refer to this as a management cluster or an infrastructure cluster. This has become almost a must have these days not just because of NSX but also some other VMware products such as vRealize Automation (vCAC) also recommending a dedicated management cluster. A typical example would look like below.                                                                                                                        0 NSX deployment architecture
      3. VMware would even go a step further, and recommend separating out another dedicated cluster as an edge cluster too, which could be especially important in a highly scaled out, large NSX deployment. But in all honesty, I cannot see this happening with the majority of VMware customers where they would likely make the edge cluster the same as their compute cluster. But, if you are talking about a large enough NSX deployment to warrant a dedicated edge cluster, a similar deployment architecture would look like below.0. Scaled out deployment
    2. Management system requirements: Given below are some key management requirements
      1. Supported Web browser (Internet explorer 8, 9 & 10 only, 2 most recent Mozilla Firefox or 2 most recent google Chrome)
      2. vSphere Web Client (All NSX settings are managed through the vSphere web client only as there’s no plugin for the c# client.
    3. vSphere requirements:  The compute cluster must have the following vSphere requirements
      1. Enterprise plus licenses (require the ability to use the VDS-vSphere Distributed Switch)
      2. vCenter Server (managing the compute & Edge clusters) to be vCenter 5.5 or later
      3. All ESXi servers in the compute & Edge clusters to be 5.5 or higher (if ESX 5.0, multicast has to be used for VXLAN)
      4. VMware tools to be installed
    4. Communication requirements:  The following ports are required to be available for communication between NSX manager and the NSX components
      1. 443 between the NSX manager and ESXi hosts & vCenter server (of the compute & edge cluster)
      2. 443 between the REST client and NSX server (a rest client would be something like a vRealize Orchestrator for example)
      3. TCP 80 and 443 to access the NSX manager between the management host and vCenter server & NSX manager
      4. TCP 22 for CLI troubleshooting between management host and NSX manager

  2. Understand the NSX deployment order: The following deployment and configuration order must be followed during a typical deploymentNSX configuration order

  3. Obtain the NSX manager OVA file (refer to the previous post in this series to find out how)

  4. Deploy the NSX manager OVA file (within the management cluster vCenter server)

    1. Select the location of the NSX manager OVA flie (either through the vSphere web client or the vSphere c# client)1
    2. Check the OVA version and click next                                                                  2
    3. Accept the EULA and click next                                                                                 3
    4. Provide a name for the NSX manager (don’t forget to manually add a DNS entry on your DNS server)  4
    5. Select the cluster on which to deploy the NSX manager (this should be the management cluster)    5
    6. Select any resource pools if required                                                                                                                    6
    7. Select the datastore to store the NSX manager OVF (should be specific to the management cluster)     7. Datastore
    8. Select the disk format (I would recommend Eager Zeroed Thick unless you have NSF as in the below screenshot)  8. Disk type
    9. Select the appropriate management network for the NSX manager (note the communication path with NSX manager) 9. Network Mapping
    10. Provide the CLI “admin” account password & the CLI privilege mode password for the NSX manager VM, networking properties such as Host name, IP details, DNS and NTP server details. Use redundant values here for high availability.10. Properties-1 10. Properties-2
    11. Select the power on after reboot check box and click finish                                                           11. Power On after deploy

  5. Perform the initial configuration of the NSX manager server

    1. Login to the NSX manager instance using https://NSX-Manager-Host-Name-Or-IP using a supported browser. The credentials use here are admin and the password you provided for the CLI admin account (during the ova deployment) 12. Login
    2. Click on View Summary                                                                                                                                                                   13. Manage settings
    3. Ensure that all NSX manager components are running and click on the manage tab at the top. Under the selected General section on the left, configure the NTP server settings (if not set automatically), syslog server details for log forwarding and any locale details if different from default.14. General settings
    4. Under the Network section, verify the general network settings are accurately set based on deployment parameters 15. Network tab
    5. Assign any specific SSL certifications required under SSL certification section. It is recommended that the default, self signed certificate is NOT used for production deployments 16. SSL Cert
    6. Select the backup & Restore on the left and click change under the FTP server settings to configure an FTP server  (FTP and SFTP supported) as a backup location 17. backup location
    7. Test the backup process by performing a SSL manager backup using the backup button 18. Backup verification
    8. Click on the NSX Management service under the COMPONENTS on the left and configure the lookup service. The lookup service configuration is optional but recommended. Look up server should be your SSO server & the default service port number is 7444. The default SSO administrator account (if using vCenter SSO) would be Administrator@vSphere.local on vCenter 5.5 or higher and admin@System-Domain if vCenter 5.0 or 5.1) 19. Look up service
    9. Now configure the vCenter service registration. Note that this vCenter server needs to be the vCenter server managing the computer & edge cluster, NOT the management cluster. You’d also need a vCenter administrative account to connect to the vCenter with and I would normally create a dedicated NSX service account on the Active Directory (or what ever your directory server system is) with administrative privileges within that vCenter. (keep a note of that service accounts credentials as you’ll need it in the step 11 below) 20. vCenter integration
    10. Ensure that both lookup service and the vCenter server registrations are successful with a green circle against the status of each. 21. Verification
    11. Now login to the vSphere web client (of the computer & edge cluster vCenter) using the NSX service account previously used to register NSX manager with the vCenter server. Note that at this point in time, that is the only account that has permission to see & configure the NSX manager instance within vCenter (note that we already allocated vCenter administrative rights to this account so you can login through the web client)22. vSphere web client login
    12. Once logged in, click on Networking & Security on your left                                                                                                            23. vSphere web client home
    13. Now click on NSX managers on the left and then select the IP address of your NSX manager25. NSX managers
    14. Now click on Manage tab at the top and then Users tab. Verify that you only have 2 users here. The default admin user created during the appliance deployment and the domain account you specified during the integration of NSX manager with. Now  click the plus sign to add a user.  You can a vCenter user or a vCenter group. a vCenter user can be an active directory user. (provided that the active directory is configured within your vCenter SSO). Note that Active Directory groups don’t seem to work here as it needs to be an individual account. If your vCenter admin account would also need NSX administrative rights, please specify it here in the format of Domain\AccountName and click next.27. Add user
    15. Select the appropriate NSX role. You would need the enterprise administrator role assigned to at least one other account (unless you are going to use the service account credentials to configure NSX which is not recommended). So I’m giving a dedicated domain account the NSX enterprise administrator privileges here and I will use that account to login to the vSphere web client to configure NSX afterwards. That account also happened to have vCenter administrative rights too in order to be able to do deploy various NSX components. You can tie down privileges so that NSX Enterprise administrators and vCenter administrators can be separate accounts if you wish but the NSX admin account would need the following permissions within vCenter
      1. User permission to add and power on VMs within the computer cluster vCenter
      2. Permission to add files to the VM datastores within the computer cluster vCenter  28. Enterprise admin
    16. Now, when you log out the NSX service account, and log back in to the vSphere web client with the new account you’ve allocated NSX enterprise administraitive rights, you are able to see NSX manager instance and can configure all other NSX components.

Hope this was useful. In the next article of the series, we will look at how to configure basic NSX components such as VXLAN, logical switches…etc

Next: NSX Controller Architecture & Deployment ->

Cheers

Chan

2. How to gain access to NSX install media

Chan Leave a comment

Next: NSX Manager Deployment ->

Ok, this is the 2nd post in the series of NSX. Its about how to gain access to NSX installation media (especially if you are part of average Jo Blogs community)  for you to try it out which seems to be not very clear to many (and wasn’t clearly documented by VMware until recently, in one place)

Now, when I first heard about VMware pushing NSX to customers, especially after the discontinuation of vCloud Networking and security, first thing I wanted to do was to get hold of the evaluation media for NSX along with the official documentation and try it out in my lab, having done the same with all other VMware products since vSphere 3.5 U2 release, initially as an ordinary customer and later, as a VMware partner. However to my surprise, when I logged in to my VMware account, I was not able to download the installation media / appliance as it said I was not entitled to download it. I work for a large VMware partner in the channel and I have almost unrestricted access to all VMware product media downloads together with NFR licenses that I can use for study, lab & demo purposes. So I was specially disappointed to see everyone taking about NSX and blogging about it being deployed in their labs…etc, yet as a large VMware partner, I (or anyone else in my company for that matter) didn’t have access to get the media. (see the screenshot below). I’d spoken to a large number of other VMware channel partners and their techies and some large VMware customers who’s got close relationships with VMware and everyone had the same issue. Just cannot seem to get hold of the download…!!

1. Cannot download

After some digging through the VMware channel team and partner alliance team, I found out that the NSX business unit within VMware are keeping a tight grip on the software to the degree that they would not want you to have access to download NSX unless you fit the following criteria.

  • An NSX customer who’s bought the license / NSX accelerator service through the VMware PSO (professional services) arm

OR

So, the first option means, they would want you to buy / pair for it through a starter kit / accelerator pack, which in all honesty I wouldn’t want to as a customer, especially when I can download every other VMware product for free and evaluate for 60 days to decide whether its worth paying for it. So, Nah….! to that one

Second option means you need to have done the NSX ICM course. Now this too could be seen as an un-necessary expense to the average customer as the course isn’t cheap. I (well… my company to be precise) had to pay around £3,000.00 (in the UK) fro me to attend this course. Again, I wasn’t too thrilled about having to go down this route, especially since I am a SE at a VMware reseller & a solution provider who sell VMware products and they are handicapping my ability to learn the damn product before I could position it for the customers which didn’t make much sense. But as it turned out, I had to do the ICM course anyway as a starting step towards earning the VCP:NV certification (work in progress, amongst other things) and I finally gained access to the software in a legitimate way. When you finish the course, after about 2 weeks, what’s supposed to happen is that you are submitted to be approved to receive access to NSX media (whether you are a customer or a partner). Only if you are successful, you are then supposed to receive an email  from the Nicira team with a link to either create an account on the Nicira website or to reset the password to login to your Nicira portal (provided that the Nicira team has created you an account already after verifying that you’ve completed the course and approved you as a suitable candidate). The email I received looked like below.

2. Nicira Welcome email

As you can see, you are NOT allowed to share this account with anyone else without permission from the POC team within Nicira business unit.

Once you got your password reset, you can login to the https://apps.nicira.com/ url with your credentials and you’ll finally have access to download the media from their (note that you may still NOT have access to download the media from the generic My VMware portal where you download all other VMware software from, unless probably if you’ve actually bought it)

3. Nicira login

Once you login, you’ll have access to NSX download. In my case I have access to both the NSX-V as well as NSX-MH versions but unsure what you’d be allowed access to.

4. NSX-V download

 

5. NSX-MH

You also get access to a evaluation license key (under entitlements) which appears to be valid a lot longer than the standard 60 day evaluation period.

So, as far as I’m aware, these are the ONLY 2 ways available to you as a partner or as a customer, to gain access to the download to play with it your self. And I have spoken to lot of people including specialist engineers within the NSX BU within VMware as well as the director of the VMware networking and security division in emea and they’ve all confirmed this to be the case. So, the bottom line is, if you need access to it, its gonna cost you one way or another…!

Now, if you are happy not to have access to the install bits but simply wants to play with it, there’s a 3rd option available to you, and that’s called hands on labs. VMware hands on labs are free and anyone can sign up with an account to access various hands on labs. I’ve tried HOLS out and they are pretty awesome. And there are a number of  different hands on labs you can take, that involve NSX. Warning….! These labs are quite lengthy and usually are around 4-5 hours long each.

  • HOL-SDC-1403 : VMware NSX Introduction – This is probably best beginners course to take first up. The course contains the followings
    • Component Overview & Terminology
    • Logical Switching
    • Logical Routing
    • Distributed Firewall
    • Edge Services Gateway
  • HOL-SDC-1425: VMware NSX Advanced – next step up from the above, Include DHCP relay, scale out L3, L2VPN, Trend micro integration and Riverbed integration lab work.
  • HOL-SDC-1424 – VMware NSX in the SDDC – This NSX lab covers integration of NSX with components of the vCloud Suite to deliver on the Software Defined Datacenter (primarily the integration with vRA). This lab is awesome and include the following contents
    • Create Network Profiles
    • Create a Multi-Machine Blueprint
    • Configure a Catalog Item and Deploy
    • vCenter Orchestrator and the NSX API through vCloud Automation Center Advanced Designer
    • Using vCenter Operations with the NSX Management Pack
    • Using vCenter Log Insight with NS
  • HOL-SDC-1419 – VMware NSX for Multi-Hypervisor Environments. This lab appears to be completely based on NSX & Linux KVM

The hands on labs catalog is available here and the access to labs themselves is available here.

Aside from those dedicated labs, the following hands on labs (as of the time of writing) are also available that involve NSX in some form or another.

  • HOL-PRT-1464 – Symantec Data Center Security: Server – Secure your SDDC – Symantec Data Center Security: Server leverages NSX Service Composer and Security Groups to orchestrate and provision security policies for your virtual workloads. Provide agent-less malware protection and guest network threat protection with automated workflows.
  • HOL-SDC-1413 – IT Outcomes – App and Infrastructure Delivery Automation -Reduce time to deliver applications and infrastructure with automated provisioning and policy-based governance throughout the service delivery lifecycle using vRealize Automation and Application Services. Integration points with VMware’s NSX for vSphere will be shown, as well as external service integration (such as vCloud Air, IP, and service management), and extensibility through additional automation
  • HOL-SDC-1415 – IT Outcomes – Security Controls Native to Infrastructure – Learn how several VMware technologies work together to implement policy-based network control, configuration and compliance management, and intelligent operations management. You will use NSX for vSphere to isolate, protect, and apply security policies across virtual network workloads. Use vCenter Configuration Manager to continuously identify, assess, and remediate out-of-compliance virtual machines. Finally, you will use vCenter Operations Manager for operational insight into the health, risk, and efficiency of the virtual infrastructure
  • HOL-SDC-1420 – OpenStack with VMware vSphere and NSX – Are you interested in learning more about OpenStack?  OpenStack is a cloud API framework that enables self-service cloud provisioning and automation.  You will take a basic tour of OpenStack and use it with vSphere and NSX to provision compute, storage and networking resources
  • HOL-SDC-1412 – IT Outcomes – Data Center Virtualization and Standardization – This lab will focus on taking the traditional benefits of vSphere and extending it further into your Software-Defined Data Center (SDDC) through Software-Defined Storage using Virtual SAN and network virtualization using NSX for vSphere. This will enable organizations to see how to deliver the same efficiency and agility for the datacentre as it does right now for the VM
  • HOL-PRT-1462 – Palo Alto Networks – Virtualized Data Center Security – Configure the Palo Alto Networks virtualized next-generation firewall VM-1000-HV with VMware NSX to protect VM to VM communications from today’s advanced threats

 

These hands on labs are a great way to play with NSX and its related products such as vRA, vCO, Palo Alto network firewall integration…etc, but if you would like to do it in your own time, at your own phase, in your own lab (which most of us IT geeks would given the chance), these labs may not be that  an alternative to having access to the software.

Hope this was useful and clarifies any questions you may have had about how to gain access to NSX media to start working / playing with it.

Comments would be helpful & appreciated.

Next: NSX Manager Deployment ->

Cheers

Chan

1. Brief Introduction to NSX

Chan Leave a comment

Next: How to gain access to NSX media ->

NSX is the next evolution of what used to be known as vCloud Networking and Security suite within the VMware’s vCloud suite – A.K.A vCNS (now discontinued) which in tern, was an evolution of the Nicira business VMware acquired a while back. NSX is how VMware provides the SDN (Software Defined networking) capability to the Software Defined Data Center (SDDC). However some may argue that NSX primarily provide a NFV (Network Function Virtualisation) function which is slightly different to that of SDN.

The current version of NSX available comes in 2 forms

  1. NSX-V : NSX for vSphere – This is the most popular version of NSX and is what appears to be the future of NSX. NSX-V is inteneded to be used by all existing and future vSphere users alongside their vSphere (vCenter and ESXi) environment. All the contents of the rest of this post and all my future posts within this blog are referring to this version of NSX and NOT the multi hypervisor version.
  2. NSX-MH : NSX for multi hypervisors is a special version of NSX that is compatible with other hypervisors outside of just vSphere. Though it suggests multi- hypervisors in the name, actual support (as of the time of writing) is limited and is primarily aimed at offering networking and security to OpenStack (Linux KVM) rather than all other hypervisors (currently supported hypervisors are XEN, KVM & ESXi). Also, the rumour is that VMware are phasing NSX-MH out anyway which means all if not most future development and integration efforts would likely be focused around NSX-V. However if you are interested in NSX-MH, refer to the NSX-MH design guide (based on the version 4.2 at the time of  writing) which seems pretty good.

Given below is a high level overview of the architectural differences between the 2 offerings.

1. Differnces between V & MH

NSX-V

NSX-V, or as commonly referred to as NSX, provide a number of features to a typical vSphere based datacentre

2. NSX features

NSX doesn’t do any physical packet forwarding and as such, doesn’t add anything to the physical switching environment. It only exist in the ESXi environment and independent (theoretically speaking) of the underlying network hardware. (Note that NSX however is reliant on a properly designed network in a spine and leaf architecture and require support for MTU > 1600 within the underlying physical network).

  • NSX virtualises Logical Switching:- This is a key feature that enables the creation of a VXLAN overlay network with layer 2 adjacency over an existing, legacy layer 3 IP network. As shown in the diagram below, a layer 2 connectivity between 2 VM’s on the same host never leaves the hypervisor and the end to end communication all takes place in the silicon.  Communication between VM’s in different hosts still has to traverse the underlying network fabric however, compared to before (without NSX), the packet switching is now done within the NSX switch (known as the Logical switch). This logical switch is a dvPort group type of construct added to an existing VMware distributed vSwitch during the installation of NSX

3. Logical Switching

  • NSX virtualises logical routing:- NSX provides the capability to deploy a logical router which can route traffic between different layer 3 subnets without having to physical be routed using a physical router. The diagram below shows how NSX virtualise the layer 3 connectivity in different IP subnets and logical switches without leaving the hypervisor to use a physical router. Thanks to this, routing between 2 VMs in 2 different layer 3 subnets in the same host would no longer require the traffic to be routed by an external, physical router but instead, routed within the same host using the NSX software router allowing the entire transaction to all occur in the silicon. In the past, a VM1 on a port group tagged with vlan 101 on host A, talking to VM2 on a port group tagged with vlan 102 on the same host would have required the packet to be routed using an external router (or a switch with Layer 3 license) that both uplinks / vlans connects to. With NSX, this is no longer required and all routing, weather VM to VM communication in the same host or between different hosts will all be routed using the software router.

4. Logical Routing

 

  • NSX REST API:-  The built in REST API provide the programmatically access to NSX by external orchestration systems such as VMware vRealize Automation (vCAC). This programmatically access provide the ability to automate the deployment of networking configurations, that can now be tied to application configurations, all being deployed automatically on to the datacentre.

5. Programmatical access

  • NSX Logical Firewall:-  The NSX logical firewall introduces a brand new concept of micro segmentation where, put simply, through the use of a ESXi kernel module driver, un-permitted traffic are blocked at the VM’s vmnic driver level so that the packets are never released in to the virtual network. No other SDN / NFV solution in the market as of now is able to provide this level of micro segmentation (though Cisco ACI is rumoured to bring this capability to ACI platform through the use of the Appliance Virtual Switch).  The NSX logical firewall provide the East-West traffic filtering through the distributed firewall while North-South filtering is provide through the NSX Edge services gateway. The Distributed firewall also allows the capability to integrate with advanced 3rd party layer 4-7 firewalls such as Palo-Alto network firewalls.

6. Firewalls

There are many other benefits of NSX all of which cannot be discussed within the scope of this article. However the above should provide you with a  reasonable insight in to some of the most notable and most discussed benefits of NSX.

Next: How to gain access to NSX media ->

Cheers

Chan