In my previous post Home Lab Step-by-Step-NSX-T 3.1 design and Install-P1, we completed the installation of NSX-T managers and added compute manager. In this post we will start discussing the different deployment options and how to ascertain which deployment model is best suited for our customers.
But, before jumping on to deployment options, I would like to talk about architecting/designing a solution. This is for the folks who are new to solution architecture field. To summarize, a solution is build up of 5 components. Requirements, Risks, Constraints, Assumptions and based on these, design decisions.
Like every business starts with an idea, similarly every solution starts from a requirement. Now requirements are further divided into 2 categories, business and technical. A good architect is able to differentiate between these two and makes his decisions thru entire solution keeping them in mind.
What could be a business requirement, well "Company A wants to reduce their IT expense" this is a business requirement. Where in "Company A's CTO wants solution to be highly available" is a good example of Technical requirement.
Requirements are the main driving force of the design, but constraints are the variable of the design which cant be changed. "Company A wants to utilize the hardware they bought for another project" this is a constraint.
Now, while designing solution you would find at certain areas where you cant apply the best practice due to the fact you have a constraint of specific requirement and which puts our design at risk, that should be well documented. For example, Company A only bought 2 servers for their management cluster which do not allow you to run vCenter in high availability cluster mode. Which poses a risk of "vCenter unavailability in case of host failure", with each risk you need to plan for its mitigation. In our example you cant run vCenter in VCHA and you cant completely mitigate this risk, but can provide high availability using vSphere HA.
Finally Assumptions, as designs is a canvas which is only showing the blue print of the actual project, you would make certain assumptions like "NTP server will be available for time sync".
Now, when you design a solution you make design decisions, VMware did a very good job in making VMware Validated Designs which I highlighted in my previous post, and that contains all general design decisions which you need to make while you work on the solution, but be aware that those not the final list, as each design will have certain decisions which are not covered in VVD, and as an architect you need to figure out what those decisions are.
Each decision should be backed by either requirement, constraint, assumption or risk mitigation action. This was a brief introduction to solution designing and by following this practice day and night you can prepare for VCDX certification. Now we will move forward with the NSX-T 3.1 design options.
Its a very good practice to check the release notes of the product you are going to design solution with.
Most common scenario one can get is single site, but don't think its going to be an easy ride. Its just one portion, now in single site you can have multiple vCenters, multiple clusters in each vCenters, consolidated clusters for management workloads and workloads workloads, etc or may be you have segregation based on environment (Test, Pre-prod and prod). Depending on customers sector such as defense, BFSI, oil and gas etc you might have restrictions between environments within site. So it all comes down to the same thing you can have endless possibilities and as an architect you need to design based on all the factors you have in your environment.
In this post I am going to cover Single site, one vCenter, Consolidated/Collapsed cluster design. I would try to cover different scenarios going forward in this series. In this design we are using 4 physical uplinks.
2 Uplinks we are using with VDS which is going to host our management, vMotion and vSAN traffic.
Rest 2 Uplinks we are going to use with VDS for NSX-T.
What are logical components in a NSX-T design.
- vCenter Server
- NSX Managers cluster
- Edge VMs
- Workload VMs
- ESXi Hosts
As we have already deployed our NSX-T manager and added compute manager. And we know how to add additional NSX-T managers to complete controllers cluster. Its time we configure our NSX-T SDDC for overlay networking.
List of pre-requisites we need to complete before we start configuration.
- IP pool for Host TEP addresses
- IP pools for edge node addresses
- Transport zones ( Overlay, Host vlan and edge vlan)
- Name of distributed switch we will use with NSX
- Name of uplink profile.
- Name for Host transport node profile
Lets start configuration of the NSX-T consolidated design datacenter.
Login to vCenter and NSX-T manager. Just be aware I have removed additional NSX-T managers which I deployed in my previous post to save physical resources, however in production environment never use single nsx t manager.
Once you login, you will be presented with home screen on NSX, and vcenter.
First step is to configure IP pools for host tep and edge tep. for that please navigate to NSX Manager UI and select networking tab, on the left hand menu you will find IP Address Pool click on that and select add ip address pool.
You will be presented with set subnet wizard, kindly add subnet details there.
Populate information of the tep subnet which we finalized in our post homelab part 3 networking.
Follow same steps for creating an IP pool for edge tep. Once tep pools are ready we will move on to creating transport zones. Remember transport zones are the boundary, hence we need to define correct transport zones. We will create one vlan transport zone for hosts and one for edge nodes and both of them will be part of same overlay transport zone.
You would see there are 2 default TZ are present one vlan and another one is overlay, however we will create our own TZ. Click on add zone.
Name transport zone and select the traffic type.
Same ways create two more transport zones, one for hosts and one for edges, but here traffic type will be vlan. Your configuration should look like this.
Now follow the wizard for VDS, name it.
I am selecting version 7.0.0 as my hosts are not updated with latest ESXi Image. You need to select the version which is compatible with your hosts esxi version.
Finish the wizard to create VDS. Once VDS is ready we need to make sure we change the default MTU to 9000 as we are going to use this VDS with NSX-T.
You will be presented with the wizard, choose add hosts.
Assign uplinks, here you will choose unused adaptors of your ESXi hosts. Choose unused adaptor and click on assign.
If you have multiple hosts with same unused physical adaptor, then check apply this uplink assignment to rest of the hosts checkbox.
Follow same steps for second uplink.
We are not migrating any VM networking as well.
Provide a name, please be aware in NSX-T letters are case sensitive that's why I prefer using only lower case. no changes to lag and scroll down to teaming.
Change teaming policy to load balance source from failover order.
Provide a name, select VDS, mode standard, vCenter name, Dswitch and transport zones. then scroll down.
Now its time we apply this transport node profile to our ESXi hosts.
Its time we hit configure NSX button, and select the transport node profile we have created and hit apply.
Wait for configuration to complete. Post completion your screen should look like this.
Now are hosts are configured for NSX-T, however we are only half way thru in our configuration.
Why not a n-vds?
ReplyDeleteWell its a good question, and trust me anyone who has worked with NSX-T would respond with why NVDS?
DeleteBut to help you understand, a small example is, it will reduce the requirement of physical uplinks if customers didnt want to keep management, backup etc traffic on nvds. Second vSphere admins are well versed with the knowledge of VDS management, for nvds one need to understand what is NVDS. I hope it helped you understand why VMware actaully came up with option of integration using vds instead of NVDS.