Designing a Solution for NSX-T 3.1: A Step-by-Step Guide

In my previous post, we discussed 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. Before diving into the deployment options, it’s essential to understand the architectural components of a solution and how to design one.

Architectural Components of a Solution

—————————————-

A solution is built up of five components:

1. Requirements: These are the needs of the business or the project. They can be further divided into two categories: business requirements and technical requirements.

2. Risks: These are the potential issues that may arise during the design and implementation of the solution.

3. Constraints: These are the limitations that cannot be changed during the design and implementation of the solution.

4. Assumptions: These are the assumptions made during the design and implementation of the solution.

5. Based on these, design decisions are made.

Designing a Solution

———————

A good architect is able to differentiate between business and technical requirements, makes design decisions based on the requirements, risks, constraints, and assumptions.

Business Requirements:

* Company A wants to reduce their IT expense.

Technical Requirements:

* Company A’s CTO wants solution to be highly available.

Constraints:

* Company A only bought two servers for their management cluster, which cannot be changed.

Risks:

* VCenter unavailability in case of host failure.

Assumptions:

* NTP server will be available for time sync.

Design Decisions:

1. Highly available solution with two servers for management cluster.

2. Use vSphere HA for mitigating the risk of VCenter unavailability in case of host failure.

3. Assume that NTP server will be available for time sync.

Now, let’s move on to the NSX-T 3.1 design options. It’s essential to check the release notes of the product you are going to design a solution with. Most common scenarios include single site, but don’t think it’s going to be an easy ride. There are multiple possibilities, and as an architect, you need to design based on all the factors you have in your environment.

In this post, we will cover Single site, one vCenter, Consolidated/Collapsed cluster design. We will discuss different scenarios going forward in this series.

Logical Components in a NSX-T Design

—————————————-

1. vCenter

2. NSX-T Manager

3. VDS (Virtual Distributed Switch)

4. NVDS (Network Virtual Distributed Switch)

5. Subnets

6. Uplinks

7. VMware Tools

8. vSphere Replication

9. vSphere HA

10. vSphere DRS

Pre-requisites for Configuration

———————————

1. Log in to vCenter and NSX-T Manager.

2. Set subnet wizard.

3. Add subnet details.

Why not a n-vds?

—————

Well, it’s a good question, and trust me, anyone who has worked with NSX-T would respond with why NVDS? But to help you understand, a small example is, it will reduce the requirement of physical uplinks if customers didn’t want to keep management, backup, etc. traffic on nvds. Second, vSphere admins are well versed with the knowledge of VDS management, for nvds one needs to understand what is NVDS. I hope it helped you understand why VMware actually came up with option integration using vds instead of NVDS.

In the next post, we will discuss the configuration of NSX-T 3.1 and how to design a solution for our customers. Stay tuned!