VMware SDDC Design Considerations - PART Five: Physical Design

  In the fifth part of SDDC Design (based on VMware Validated Design Reference Architecture Guide) i want to tell give you some recommendations about the "SDDC Physical Design". Physical design is the fundamental and basic part of SDDC Design as i think, because if you don't have enough attention to this area, all of considerations about virtual, cloud and management layers will be affect negatively. So let's review some recommendations based on VMware SDDC Design:

1. Distribute all computing resources (Workload ESXi Hosts) between the dedicated racks for computing pods. Remember to measure overhead of burst workload and resource requirements of that. Although performance metrics depend on average usage of computing resources but to improve the efficiency of your SDDC, we should encounter with high resource running situation to calculate exact required hardware for each rack of computing pods.
2. It's better to provide similar circumstances for storage pods if you don't use VMware VSAN Solution and bunch of SAN storage devices are provided for your SDDC.
3. Management and Edge pods can be deployed and established inside same racks. Also you must consider some places for spine switches and other connectivity devices, especially external connections of Edge services in these racks. Note that if you provide same racks for these two types of pod, VLANs for DMZ & WAN Connections are spread on resources of both pod types, So must be respected to some security limitations, for example never provide Edge VLANs into the management pod hosts if you do not need them. Maybe VM power users or some virtual admins have access to change VM network connectivity and intentionally or not, connect the critical management service of SDDC to an outside network and break the security policies.
4. Provide dual power supplies at least for each of critical devices like storage and server and also each rack must have two separate power feeds to increase total availability of SDDC. So it's recommended to use dual UPS and power generators on the datacenter electricity infrastructure. (Check each types of prepared racks & UPS best practices documentaries)
5.  Try to provision identical hardware config (or similar at least similar CPU family) for ESXi hosts for the compute balancing and providing access to same resources for each of VMs across the SDDC. it also enables greater performance in virtualization computing and we can prevent more issues affected from a server problem. By default it's better to use more blade servers instead of a few tower/stand servers or some other powerful types of servers on the SDDC physical server provisioning.
6. VMware VSAN can grant better storage resources distributing and load-balance disk usage across all the hosts inside a VSAN Deployment. Just consider VSAN Design documentaries if you want to deploy it on your SDDC.
7.  Calculate total physical memory required before provision physical servers/blades for the SDDC. Testing and analyzing memory usage of some selected VMs of end-users applications and network services can be good way to estimate average memory usage and required RAM Modules.
8. We can provide some SD memory disks or USB devices (4GB or more storage) to install VMware ESXi inside them instead of local disks. They can be replaced fast & easy and there is no dependency to local arrays.
9. Physical networking design is following the Leaf-Spine architecture and is fully-compliance with this structure design method, (we reviewed it at Part4 of this series) So just need to adhere to  simplicity and scalability factors in your SDDC physical networking design.

Security Recommendation and Hardening on Virtual Environments - Chapter Two

 As the second part of security recommendations for vSphere environments and in continuous of first chapter i want to explain more about how to secure our virtualization infrastructure. Today unlike the previous post that i speak about some service or protocols, now i want to have 5 topics to discuss about how to harden credentials on virtualization infrastructure:

1. Account Lockout Duration: ESXi Hypervisors are very important part of VI and you must track and investigate every actions on them. So to prevent one of the main and usual attacks on ESXi credentials, first of all secure every types of login: DCUI, Shell, SSH, Web Client and vSphere Client. In the first step you should increase login failure lockout duration for root account or every sensitive credentials. After release of vSphere v6.0, account lockout is supported only for SSH and vSphere Web Services SDK not DCUI and Shell access. The default setting is 5 failed attempts and 15 minutes locking period. But if you feel it's not enough to prevent another retry, then you must increase lock duration and decrease number of permitted failed login. For example i think if you want to consider some failures for password input, because your VI admins maybe are still sleepy or want to have breakfast on his desk like me and blah blah blah, 3 failed attempts for login is enough and at least 30 minutes is a good decision to avoid risk of password guessing or brute force and library attacks. (Authentication Layer)

2. Limit access to Host per IP: No one is legitimate to connect to your VI assets like ESXi or vCenter servers, unless they are qualified as the approved persons and their system on networks are permitted. So the hosts and other VI management system IP addresses should accept only from some specific clients belongs to VI admins regardless of whether they are correct or not. (Access Layer)

3. Who has which access exactly? Sadly it's a common method to grant root access to each of VI support and administration team. It's necessary to clearly specify every authorized member need which privileges, so you can grant default roles like VM Power user or network administrator or provide a new role with required actions for that level. Maybe i don't need some privileges for my daily management actions, so it's better to never have them. (Personally i always preferred to never carry responsibilities more than i legally permitted and i hope you listen to this advice.) At last grant role access to each of VI admins or VM help desk or tech support members. (Authorization Layer)

4. How much time you need to stay in "logged in" mode? Especially it will be very sensitive, if you are in shell or SSH connection (you know because of magical power of these management access!) and leave your PC for some minutes, What reaction should be happened against your idle connection? Obviously i want to say it must be interrupted after a short while if you are not there yet. So strongly recommended to specify idle timeout and availability timeout for all of connecting methods (ESXi Shell, SSH or DCUI).

5. SSO configuration password policy: Never change these settings or if you want to do that, never make it easier (please for sake of god). It's very important that every member of VI admin team use very complex password and nobody logins with default user. 

 I know these topics are routine tips, but sometimes it's good to remind them to us. For more helps to do them, refer to below links:

1.https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-DC96FFDB-F5F2-43EC-8C73-05ACDAE6BE43.html

2.https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.security.doc/GUID-6E1ECA4D-B617-4D42-B40B-71E4C83DEEFB.html

VMware VDI (Horizon View) Troubleshooting - Part I

 Usually we think it's so easy to change most of the server's name! Just a little configuration changes like editing FQDN value maybe destroy all of your configuration and setting. It's going to sounds like a disaster if you change computer name/account of a server without any consideration or checklist about how to do it. But sometimes you may be wrong in initial server name configuration and after service setup and startup, then you will understand what's happened (forget to change the default name or choose a suitable name based on your design worksheets). Now let's check this matter about a VMware Horizon View Connection Server. First of all you should answer some of questions like:

   1. What should we do if we need to change computer account?

   2. What will happen if we change computer account? 

   3. What should we do as the post-execution after renaming the server? 

 As the first step, you have to review the service documentary specially troubleshooting documents. Then investigate side effects in your virtual desktop infrastructure objects like desktop pools or provided and in-used virtual desktops. Naturally none of them cannot connect to the server anymore, especially if you change the primary connection server nor any of replica servers. As the best and safest way to configure server after renaming it, you can uninstall VMware Horizon 7 Connection Server component (and also HTML Access) and install it again without any concern about losing VDI data and structure. Because there is another important application on provisioned connection server: AD LDS Instance VMware VDMDS that as it's name demonstrate, it's the directory service for VMware VDI suite and is a separated component from Horizon View Connection Server

So let me explain about structure of Horizon View. It's fundamental is based on Lightweight Directory Access Protocol (So you cannot install this service on a domain controller). View LDAP is a data repository and consists of all of it's configuration information and it will be created when you install the first View connection server. This repository will be replicated to other View replica servers. Like other LDAP service it has some partitions, objects and attributes of objects and can be edited by ADSIEdit, just remember if you want to do it, type the Distinguished Name like :

dc=vdi, dc=vmware, dc=int

And then you can find connection server object on these Sub OUs: 'Properties\Server' and 'Properties\LVM\Server'.

The second way to check and change VDI configurations on connection servers is doing by windows registry editor. You can see related path (HKLM\ Software\ VMware, Inc.\VMware VDM) about Horizon View on second picture:

 But regardless of these two rough and dangerous methods, VMware recommended vdmadmin CLI for troubleshooting of Horizon View (note using regedit is not a suitable way). If you refer to following path you can also see other useful CLI like vdmexport and vdmimport:

%ProgramFiles%\ VMware\ VMware View\ Server\ tools\ bin\

Absolutely we know all of gathered information from each of these troubleshooting methods must be same, for example if you check the system GUID , all ways must return the same value:

 Reinstalling the connection server component is the fastest and easiest way, but if risks assessment and information security policies of your organization prevents you from that, now what method you will Choose to reconfigure your virtual desktop infrastructure servers? We will review more about Horizon View troubleshooting on another parts of this series.