Home Lab Step-by-Step-NSX-T 3.1 design and Install-P1

 In my previous post Home Lab Step-by-Step Part-10-vSAN 7, we completed single site vSAN cluster setup. Now we will start deployment of NSX-T manager, after completing NSX-T manager installation we will talk about the different design scenarios, and we will discuss the deployment method for them as well.

If you are new to software defined networking space, then I would highly recommend reading Getting Started with NSX-T: Logical Routing and Switching: The Basic Principles of Building Software-Defined Network Architectures with VMware NSX-T by Iwan Hoogendoorn and If you at advanced level then would recommend reading Multi-Site Network and Security Services with NSX-T: Implement Network Security, Stateful Services, and Operations

Before we start deployment of our NSX-T manager, we need to make sure we are ready with pre-requisites. What are those pre-reqs? Well these are clear system requirements for NSX-T, hence kindly check them properly and make sure everything is in place.

Below table shows resource requirement for different form factor, we will be deploying extra small as we are running POC in our test lab.

In a real environment you would have to make this choice based on Design requirements.

Now, we need to prepare our vSphere environment, and download the installation media.

Preparing the environment is the hard part, and it totally depends if its a green field or brown field design. Now if you are new to the designing and solutioning. Let me clarify, green field stands for a new environment which will be build from scratch, and brown field stands for environment which is already in production. Any environment which is already in production will present lots of constraints due to current state it is in. We will discuss it in more detail when we will review the design options available. Before we do that I am attaching one very useful link if you wish to learn how a good VMware Validated design looks like, trust me this is what "we"(architects) refer when designing NSX-T solutions.

If you are starting your journey to be an Architect then I would highly recommend Kick-start your solutions architect career by learning architecture design principles and strategies and Introduction to Solution Architecture. 

So lets get back to preparation, we need to make sure vCenter is up and running, enough compute, storage and network resources are available for NSX-T cluster.

We need to have network setup for NSX-T, if you recall we have created some extra vlans in our post home-lab-step-by-step-part-4-virtual router, now we need to finalize IP address for our NSX-T components.

Once we have the IP schema ready, we are good to start, lets download the NSX manager ISO from my.vmware.com .

Login to the vCenter, and validate you have created the networks which now will be needed. Navigate to Networking tab>> select the Distributed switch.

Move to Host and Cluster view, select one host and right click on it, select option deploy from OVF template.

Select the second option to locate downloaded OVA file from myvmware and click next.

Assign name and select the folder, where you want to place the NSX manager. Click next

Select the compute resource where you want to place your NSX manager.

Review the details, and click next.

Select deployment size and click next.

Select Storage/datastore where nsx manager should be placed, in my case I only had one DS.

Select the management network and move to template customization screen.

Now set the password for System root, CLI admin user and Audit user. 

Password complexity requirement.

 Please follow the password complexity rule as below:

- minimum of 12 characters in length

    - >=1 uppercase character

    - >=1 lowercase character

    - >=1 numeric character

    - >=1 special character

    - >=5 unique characters

Now its time for setting the appliance IP and selecting its role. As now we have 2 more options with the same ISO is Global NSX manager and nsx-cloud-service-manager.

Assign DNS server address, NTP and enabling services such as SSH.

Now finish the wizard and wait for NSX manager appliance to be deployed successfully.

As now windows comes with inbuild security, and do not trust files downloaded from internet directly. You might get the error I received, but that is not something you should be worried. 

This issue " Failed to deploy OVF package. ThrowableProxy.cause A general system error occurred: Transfer failed: The OVF descriptor is not available." has been there for sometime and solution is pretty simple. You need to open properties of the downloaded OVA file and check the unblock box, apply and now you are good to deploy the template.

Once you start deployment after unblocking the file, OVF deployment will start with no issues.

Now meanwhile we are waiting for deployment to complete, lets discuss what is NSX?

In simple words, NSX is the software defined networking solution offered by VMware. But does this really answers our question, I would say no. So what is the answer to this, well as we saw innovation in other spaces of datacenter such as Compute and Storage NSX is the innovation in networking space. NSX is one of the SDN solutions available in market, however as NSX doesn't necessarily  need separate hardware, as it can run on the same ESXi hosts where we have our virtual servers are running, it has an edge over other solutions, one more feature which makes it shine among others is the capability of micro-segmentation. We will talk in detail on these topics as we move further in our NSX-T design and install series.

For the folks who are new to this networking space, this is for you. I am writing a little about basics of networking which you need to understand before you start working with NSX, as NSX itself is a networking solution.

We all know, job of networking is to establish communication channel between two or more entities. It is exactly same as any other form of communication, so to explain I am taking example of old times when we didn't have computers.

In that era if you need to send a message to someone you would use written letter. Now lets understand how that would have worked.

In this image you see two buildings, one and two. Each building has four houses numbered 1,2,3 and 4. But in each building house with same number is allocated to someone else, for example house number 1 is allocated to Blue in building 1 and in building number 2 its allocated to Alpha. I hope you are with me so far.

Now Blue wants to communicate with Orange, and for any successful communication you need 4 things Sender name, senders address, Receiver name and receivers address. So here Blue is sender, and its address is 1 and as its in the same building, blue knows orange lives in house number 4. He will come out of his house with the letter and can deliver it to house number 4 for orange.

But if he needs to send a letter to Alpha who lives in building number 2 house number 1 he would still come out of the house with the letter with receivers address and name on top of it, but will hand it over to a messenger who knows where building number 2 is.

This is the same logic which applies in the world of networking, We have IP addresses and MAC addresses. If you wish to co-relate, IP is the name of the entity and mac address is the physical address, building is one network subnet and building 2 is another network subnet and messenger is our router.

Now how do we know who lives on which address in same subnet, we have a protocol for that and its called address resolution protocol. Along with as any residential/official building has a record who lives where in a form of physical/virtual register. Switches also have MAC tables for each subnet which maps IP to MAC and MAC to IP. 

In this example I only talked about 2 buildings, now imagine a complete society, then an Area, multiple areas will make a city, multiple cities will make a state and multiple states will make a country. Same mechanism is used in networking.

Each switch can be considered as a state, which will have multiple subnets, and each subnet will have multiple IP addresses. In order enable inter subnet communication we need routers, and to secure that communication we need firewalls.

There are technical terms for each concept I have touched so far, for example Subnets are defined with vlans, inter-subnet communication is called inter-vlan routing etc. Networking is a very vast domain which certainly I cant cover in just one post, but I feel it was enough to explain basics of communication.

Let move forward, there are multiple mechanisms which are in place to make sure communication is effective, like in mailing system things are organized, that is the reason one mail use to travel from one house in United states to a house in India. Same ways Amazon delivers your orders or any thing which needs to travel from one place to another, like Air planes.

In NSX-T as well we have these mechanisms, that's why we have management plane, control plane and data plane. Each plane literally does exactly what their name signifies.

NSX Manager falls under management plane which is our single pane of management.

Then comes Controllers, which are running inside NSX manager but are part of the control plane, now control plane is divided into 2 parts, centralized control plane and local control plane, its job is to control what was defined by the management plane. Dataplane is production traffic.

You can say it as Management plane is the higher management, Control plane is middle management and data plane is the actual workforce.

So now we have deployed our NSX-T manager. Lets power it on and login on it for the first time. As its using self signed certificate, kindly ignore the warning and proceed.

Then you will be presented with the login screen, use the admin credentials we have configured while deploying the NSX-T manager.

 

Accept the EULA, and you are logged in to your first NSX manager, with dark theme 😉. Please be aware that this is the only way of deploying first NSX manager in the cluster.

Here you can decide whether you want to join the Customer experience improvement program.

Finally you have the first look of your own NSX-T manager.

Now its time to review some of the design decisions, as per the VVD and design workshops you would conduct with customer.

In our LAB we will only use single NSX-T manager, however in real world when you would design a solution, you will make sure that you are deploying NSX-T managers in cluster, what is the justification for this decision? well actually there are two.

1. Deploying NSX-T managers in cluster will make the management plane highly available.
2. As controllers are inbuild in NSX-T managers, it keeps control plane highly available too.

Now, we will navigate to licenses and we will add our NSX-T license. System>>Licenses and click on add license.

Once we are done with assigning license, we can move onto adding compute manager.

I hope you already know that NSX-T is not only meant for VMware infrastructure, but can be used with KVM hypervisor, baremetal servers etc. Thats the reason we add these solutions as compute managers.

To add compute manager we will navigate to system>>Fabric>>Compute manager.

Once Compute manager is loaded, click on add compute manager, to add vCenter as compute manager.

Fill in the vCenter details and click Add.

You will be presented with vCenter server thumbprint, click on add.

Wait for registration to complete.

Once registration is complete, you will see the status change to registered and connection status to "Up".

In our Lab environment we are ready to add a new DVS, or we can use the one we have created already, in both the cases MTU should be more than 1600 but recommended is 9000.

But in real world this is the point where you will deploy two more appliances.

For that you need to navigate to system>>appliances.

Now click on Add NSX appliance to deploy second NSX-T manager in the cluster. I will only show you the steps but in Lab I will not actually deploy second and third manager. Fill in the details for the second manager such as management IP, NTP and DNS etc along with the form factor of the manager, this should be identical to first manager.

Now complete the appliance placement configuration.

Finally complete NSX manager passwords for access, keep that same as first manager, and enable SSH access.

Once all the information is provided in the wizard click on install appliance. Repeat same steps for deploying third NSX-T manager node, wait for both the nodes to be deployed and joined cluster.

Now assign the cluster VIP for ease of management, be aware that cluster IP doesn't do load balancing, it only provides ease of management.

 

Now we have completed deployment of NSX-T manager and controller cluster. This is an essential and common part of each design topology. Whether its a single site or multi site or federation with global managers.

In my next post we will start with what design scenarios we can do and how we can design solution better. 

I hope I was able to add value, if your answer is yes, then don't forget to share and subscribe. 😊

If you want me to write on specific content or you have any feedback on this post, kindly comment below.

If you want, you can connect with me on Linkedin, and please like and subscribe my youtube channel VMwareNSXCloud for step by step technical videos.