VMware vSAN is Software-Defined Storage(SDS) solution from VMware that is fully integrated into vSphere. To enable vSAN, we need to have a minimum of three ESXi hosts, and each host needs at least one cache disk and one capacity disk. The local disks of ESXi hosts should be formatted by VMFS. Since vSAN is a vSphere clustering feature, we should also have Center Server in place before start implementing it.
If you are a System Administrator or even a Solutions Architect, you might a face a challenge to build a vSAN Cluster with minimum ESXi servers without having a vCenter in place. In many green field environments, vCenter has not been installed and you want to keep ESXi’s disks intact and unformatted. In addition, there are some customers that want to build and manage vSAN Cluster in a separate vCenter and they do not have any additional ESXi host for vCenter deployment.
If you are using vRealize Suite’s solutions like vRealize Operation, vRealize Automation, or vRealize Log Insight, then vRealize Suite Lifecycle Manager(vRSLCM) comes in handy into day to day operations. This product automates the deployment, configuration, and upgrade of the vRealize Suite. If you plan to deploy any of vRealize products or even automate the Day 2 operations like certificate replacement, then vRSLCM is a go-to tool for your use case. It is also worth mentioning that some products like vRelaize Automation(vRA) use this solution as a built-in tool for the deployment process. It is recommended to deploy vRSLCM first and then deploy and other vRealize Suite products due to ease of installation and configuration orchestration. But if you already deployed any of the suite’s products, you can also add them into vRealize Suite Lifecycle Manager.
In this blog post and following video tutorial, I show you how to deploy vRealize Suite Lifecycle Manager with Easy Installer and lay the foundation for the rest of vRealize Suite products deployment. The license for this product is included in any edition of the vRealize Suite licensing package.
In the first part of NSX-T Distributed Firewall, I explained the importance of embracing NSX-T DFW. In this post, I review how you can create and apply firewall rules to implement Micro-segmentation. To create firewall rules, first you need to define a Policy section which basically contains one or more firewall rules. A policy in NSX-T DFW can be defined as stateful or stateless. In the case of being stateless, you need to define the rules in both directions. Otherwise, the reverse traffic is not allowed to pass. On the other hand, in the default stateful mode, when you define a rule it will apply bidirectionally.
Then you need to define the rules under the policy section which evaluates the criteria of a traffic flow. DFW rules determine whether the traffic should pass or get dropped based on the protocol and ports.
Before jumping to NSX-T Distributed Firewall (DFW) concept and rule creation, I want to point out why this solution is important and what security issues can be addressed by using this powerful solution. Building a zero trust model security has been the biggest concern of network and security teams. In traditional data centers, high-level segmentation is built, which could help to prevent various types of the workload from communicating. But the main challenge of the legacy security model is data centers facing a lack of lateral prevention communication system between workloads within a tier. In other words, traffic can traverse freely inside a network segment and access the crucial information until it reaches the physical firewall to get dropped. In addition, implementing different layers of security and firewalls would cause complexity and cost.
NSX-T Distributed Firewall (DFW) is a hypervisor kernel-based firewall that monitors all the East-West traffic and could be applied to individual workloads like VM and enforce zero-Trust security model. Micro-segmentation logically divides department or set of applications into security segments and distribute firewalls to each VM.
After upgrading to vCenter 7 Update 1 , when I tried to browse vCenter HTML5 UI, I faced “no healthy upstream” error. I could access to vCenter Management Interface (VAMI) https://vCenter-IPaddress:5480 without any issues. I could also connect to vCenter Server through SSH but I realized couple of vCenter Server services could not start.
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.
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 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 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.