Deploying The NSX Manager Virtual Appliance

Deploying the NSX Manager virtual appliance
The deployment of NSX requires a lot of things to be in place for a successful
deployment of NSX and below I will list the most important things for a smooth and
successful deployment of NSX.
NSX, VMWARE VERSION OF SDN/ Software-Defined Data
Center (SDDC)
VMware NSXfor vSphere isa core componentof the VMware Software-DefinedData
Center(SDDC);itisthe componentthatenablesnetworkvirtualization.Network
virtualization provides alayerof abstractionoverthe physical networkusingaVXLAN network
overlay.WithNSX,networkoperationsare now independentof the physical hardware,and
functionssuchas logical firewalls,loadbalancers,logical routers,logical switches,andvirtual
private networkscanbe provisioned,modified,ortorndownas part of an automatedworkflow.
Choosing the right VMware NSX for vSphere edition
VMware NSX has four licensing editions: standard, advanced, enterprise, and remote
office/branch offices (ROBO). Each licensing tier provides distinctive functionality, available
per CPU socket on a perpetual basis at the vSphere cluster level.
The standard and advanced editions are also available as per 100 users in a pack basis to
align with virtual desktop deployments (vSphere for desktop). The enterprise edition
is also available on per-VM term basis. You can upgrade from standard to
advanced/enterprise and from advanced to enterprise.

Getting ready
Like vSphere licensing, VMware NSX is licensed per CPU socket. If you have a
separate Management vSphere Cluster that is used for Infrastructure VMs and are not
planning to protect it with the NSX Distributed Firewall or place NSX Edge Service
Gateways onto it, you are not required to license the CPUs on that Management
vSphere Cluster. The Compute vSphere cluster and Edge vSphere cluster need to be
licensed.
How To do It :
From your vSphere inventory you will need to do the following:
1. Determine how many CPU sockets you need
2. Determine the NSX features required
3. If you are planning to integrate third-party partner solutions with NSX
4. Choose the NSX edition based on the features required
VMware NSX editions
The four tiers of licenses are as follows:
1. Standard edition
2. Advanced edition
3. Enterprise edition
4. ROBO
Note : Check on VMware website for all license requirements before deploying.

Log Insight into NSX : VMware vRealize Log Insight for NSX
VMware vRealize Log Insight is a log management engine that collects logs from a
number of different sources and provides rich dashboards and search functionality.
Log Insight is available for NSX at no additional charge, you are entitled to one Log
Insight CPU per NSX CPU license. The support and subscription is included with the
NSX purchase. It is a fully functioning version of Log Insight but limited to vSphere and
NSX data sources and content packs only. If you need more data sources and content
packs, additional Log Insight licenses are required.
VMware NSX Monitoring Tools
Selecting ESXi hosts and network adapters
Similar to the requirements of a VMware vSphere solution, choosing the correct hardware is
still an important part of any NSX deployment; therefore, you need to follow the same process
that you did for vSphere to ensure the hardware you are deploying is on the VMware
Compatibility Guide.
The compatibility guide does not only list the supported servers, but you need to also check if
your network interface card (I/O devices) is supported and features such as VXLAN Offload
and Receive Side Scaling are also supported.
VXLAN Offload
VXLAN Offload is akin to TCP segmentation offload (TSO), but compared to TSO, which is
designed for TCP packet headers, VXLAN encapsulates the original (source) packet from a
virtual machine into a user datagram protocol (UDP) packet with its own unique header,
known as the VXLAN header. Placing this additional header onto a packet invalidates
traditional offloading mechanisms in-place and therefore increases load on the CPU as
additional CPU cycles are needed to encapsulate and decapsulate every VXLAN packet.

Receive Side Scaling
Receive Side Scaling (RSS) is a technique the Network Interface Card (NIC)
employs to ensure that data processing for a particular connection is balanced across
multiple CPU cores. Without RSS, all connections would be handled by a single CPU
core, which can adversely affect network performance.
FIRST STEP’S Before Deployment
Deploying the NSX Manager virtual appliance is the first step to enabling network
virtualization in your vSphere environment. In this recipe, you will go through the steps
to enable your environment for NSX.
The following diagram depicts the logical process of enabling your environment for
network virtualization, and the first four steps will be covered here :

Things Needed Before Deployment :
Before deploying NSX Manager, the following prerequisites need to be satisfied:
 Static IP address and portgroup for NSX Manager
 Firewall ports open between NSX Manager, vCenter server, and ESXi VMKernel 0
Interface on each host (refer to vmware website for a complete list of ports)
 Forward and reverse DNS entries for NSX Manager
 NTP server is accessible; minimum of four is recommended for accurate time
 Shared datastore for the appliance to be deployed onto
 Satisfy minimum requirements for NSX Manager
Fill in the following table before deployment : (Also make sure to include the cli password and cli
privilege password )

Afteryouhave gatheredall the neededinfoaslistedabove follow the steps below todeployNSX
Manager.
1. Log into the vSphere Web Client
2. Select Hosts and Clusters, right-click on the target cluster and select Deploy OVF
Template
3. Select Local File and locate the NSX Manager OVA downloaded earlier; click on Next
4. Type in the Name of the virtual appliance and click on Next
5. Select the vSphere cluster and resource where you want to deploy NSX Manager and
select Next
6. Review details, Accept license agreements and click on Next
7. Select the shared datastore of where you want the virtual appliance to be deployment onto
8. Select the VLAN-backed portgroup as defined earlier and click on Next
9. Fill in the template details as highlighted in the preceding table and click on Next
10. Ensure all details are correct and click on Finish:

Next Step will be to :
Replacing the NSX Manager certificate
When you first deploy the NSX Manager, it creates a self-signed certificate. Using a self-
signed certificate is generally not a recommended security practice. It is recommended to
deploy a signed certificate from your internal certificate authority. NSX Manager supports two
ways of deploying a signed certificate, which are as follows:
 Certificate signing request to a Certificate Authority (CA)
 Importing a PKCS#12 certificate archive (bundle) onto the NSX Manager, which includes
the private and public key for NSX Manager and certificate chain of any subordinate CAs in
your environment
Next we will explore how you can create a certificate signing request on NSX Manager and
how to import a PKCS#12 certificate bundle onto the NSX Manager.
Certificate Signing Request
A Certificate Signing Request (CSR) is the first part in a three-step process; this process
involves the following steps:
1. The NSX Manager creating a CSR
2. The CSR is sent as a request to the certificate authority, which then signs the certificate
and sends back a signed certificate
3. Importing the signed certificate into the NSX Manager
The procedure to complete a certificate signing request is as follows:
1. Log into NSX Manager via your web browser
2. Click on Manage Appliance Settings
3. Click on SSL Certificates

4. Click on Generate CSR and follow the prompts as per the following screenshot:
5. Click on OK and select Download CSR
6. Send the CSR file to your security administrator and get the certificate signed
7. With the returned certificate, click on Import so you can import the correct certificate into
the NSX Manager
8. Reboot the NSX Manager to complete the process of importing a signed certificate into the
NSX Manager

Using a PKCS#12 certificate
Importing PKCS#12 into the NSX Manager is used when the certificate signing was
not completed using the CSR method outlined in the previous recipe. The PKCS#12
format is typically used in scripted installations of NSX Manager and other
components. If a CSR was not generated by the NSX Manager itself, it is required that
the PKCS#12 archive is imported into NSX Manager.
The PKCS#12 archive generally consists of the following:
 A signed server certificate
 A private key for the signed certificate
 Root and intermediate certificate authority public keys
The PKCS#12 is also password-protected, so it's important to have the password
before attempting to import the PKCS#12 archive into NSX Manager.
In some cases, the received signed certificate may not be in the PCKS#12 format. In
this event, you must convert the certificates into the PKCS#12 format for import into
the NSX Manager. This can be achieved using openSSL (https://www.openssl.org/),
and the command to achieve this is as follows:
openssl pkcs12-export-outserver.p12-inkeyserver.key -inserver.crt-certfile CACert.crt

The procedure to import the PCKS#12 archive is as follows:
1. Log into the NSX Manager via your web browser
2. Click on Manage Appliance Settings
3. Click on SSL Certificates
4. Click on Upload PCKS#12Keystore and browse to the file
5. Enter the password for archive and click on Import
6. Reboot the NSX Manager to complete the process of importing the signed certificate
Until NextTime…………………………………

Deploying The NSX Manager Virtual Appliance

More Related Content

What's hot (19)

Similar to Deploying The NSX Manager Virtual Appliance (20)

More from David kankam (13)

Recently uploaded (20)

Deploying The NSX Manager Virtual Appliance