Starting with version 4.7.100, VxRail supports vSAN 2-Node for small and Remote-Office Branch-Office (ROBO) deployments. This solution works best for environments that needs hyperconverged compute and storage with a minimal configuration. VxRail 2-Node consists of two VxRail E560 nodes and a vSAN Witness Appliance. It is recommended to deploy the Witness appliance in another site but in case of lacking another site it can be deployed in the same site as vSAN 2-Node.
There are some considerations and requirements that you need to have t in place before starting the VxRAIL 2-Node implementation.
vSphere 7.0 introduced by VMware in March 2020 and went to GA in April 2020. Many new features like DRS & vMotion improvement and also Lifecycle Manager has been released. After half a year VMware introduced first major update on vSphere 7 and today this release went into GA. It is now publicly available, you can download it from VMware and take advantage of this latest and greatest release! Here in this blog post I will go through the new features and capabilities
In Part 1 of NSX-T SSL Certificate Replacement, the process of certificate template preparation and request has been explained. This blog post will teach you how to import and replace the generated certificate into NSX-T Manager. It is really important to verify the imported certificate before replacing it. I want to point out that if you are using a Virtual IP for you NSX-T management cluster, you should have generated the SSL certificate for management cluster’s Virtual IP address.
NSX-T installation comes with a out of the box self-signed SSL certificate. Because of security and compliance reasons, most of customers want to replace default self-signed certificate with a CA signed certificates. We have been looking for guide that explains how to do this step-by-step but unfortunately we couldn’t find one! There are some very useful guides like this one from VMware but as you read through, you realize the documentation is not complete. So to make story short, we looked around and ran SSL certification replacement.
To setup NSX-T Role-based Access Control(RBAC) it’s better to create groups in Active Directory and add users into the group for two reasons. First it’s easier to add a group with couple of users as members rather than assign role to many users in NSX-T. Second, with help of Group Policy you can define a “Restricted Group” and it locks down membership to that group. As a result it provides a layer of security.
Now that we have finalize deploying three managers in NSX-T management cluster we can go ahead and configure a Virtual IP(VIP) on it. We can use NSX-T internal mechanism to set an IP address on the cluster or setup an external load balancer in front of NSX-T managers. Configuring VIP which is recommended by VMware is more simple but using a LB would load balance traffic among NSX-T managers. This is a design question and should be chosen based on requirements and customer needs.
Please keep in mind that if you want to choose this approach, you need to have all NSX-T managers are on the same subnet. In this case, managers are attached to SDDC Management network. To configure Virtual IP, login to NSX-T Manager UI, choose System and on the left panel select Appliances then click on SET VIRTUAL IP option.
In the previous articles, we deployed first NSX-T Manager and then we added vCenter Server as Compute Manager in NSX-T Web UI. In this post we are going to finalize NSX-T Management cluster. In production environment for high availability and performance reasons, it is recommended to have three NSX-T Managers in the cluster. Second and third NSX-T Managers should be added from NSX-T Web UI. To deploy additional NSX-T manager appliances, go to System menu and choose Appliances and click on “ADD NSX APPLIANCE”.
In previous blog post we started NSX-T implementation by deploying first NSX-T Manager. Before deploying other two NSX-T Managers we need to add a Compute Manager. As it defines by VMware, “A Compute Manager is an application that manage resources such as hosts and VMs. One example is vCenter Server”. We do this because other NSX-T Managers will be deployed through Web UI and with help of vCenter Server. We can add up to 16 vCenter Servers in a NSX-T Management cluster.
To add compute manager in NSX-T, It is recommended to create a service account and customized vSphere Role instead of using NSX-T default admin account. The reason behind defining a specific role is because of security reasons. As you can see in the below screen shot I created a vSphere Role call “NSX-T Compute Manager” with the required privileges. I use this Role to assign permission to the service account on vCenter Server.
In a previous blog post, NSX-T architecture explained and now we can start implementation of NSX-T. Deployment process of NSX-T Data Center beings with deployment of NSX-T Management cluster. In NSX-T 3.0 management cluster is consist of three NSX-T managers which include both management and control plane. The management plane provides Web UI, REST API and also interface to other management platforms like vCenter Server, vCloud Director or vRealize Automation. The Control plane is responsible for computing and distributing network run time state.
NSX-T managers can be deployed on ESXi or KVM hypervisor. If you are planning to use ESXi platform to host NSX-T managers, an OVA file should be used. On the other hand for KVM platform, a QCOW2 image will be used for NSX-T manager deployment. It is important to note that mixed deployments of managers on both ESXi and KVM are not supported. Based on type of deployment and size of environment, NSX-T manager node size configuration should be selected. Following is the four different configuration options and their requirements.
In series of blog posts we are going to walk through different steps to setup a NSX-T Data Center infrastructure. If you are new to NSX-T, please first go ahead and read the Introduction to VMware NSX. To get more insight on NSX-T architecture you can continue with NSX-T Architecture and Components post. Because we are using NSX-T 3.0 for the purpose of this implementation deep dive, you can also review What’s new in NSX-T 3.0 blog post.
Following are the required steps to build a solid NSX-T Data Center foundation. Please follow each step and we are going to update and complete this list regularly.