In the first of a series of blogs, I look into the need for certain configuration items within VMware vSphere.
The first is ensuring a consistent time source across your infrastructure. Does it matter, and what breaks (if anything) if you do not?
The management components of vSphere and the core infrastructure in most cases, need to be configured with a time that is the same (Within a range). Not having the same/similar time can result in vSphere either not working, getting inconsistent results, or can hind troubleshooting.
Many features in vSphere rely on the same time for components to communicate with each other. From Active Directory integration allowing centralized authentication to vCenter to certificate handshaking between Platform Service Controllers (PSC).
Kerberos is a computer network authentication protocol that is the basis of authenticating Active Directory tokens. Kerberos may not work if the skew is more than five minutes (300 seconds).
External PSC or multiple PSCs
If your PSC is external to vCenter or there are multiple PSCs in the environment, the time source must also be in sync.
Though KB 75032 relates to the deployment/upgrade, it shows the need for a synchronised time source.
When the VMware Certificate Authority (VMCA) is used, a synced time source is required. The VMware Doc outlines the requirements.
When troubleshooting vSphere issues, reviewing logs is the cornerstone of any review. Matching logs from different vSphere components (eg. ESXi and vCenter logs) becomes a very difficult task when the timestamps of the logs are out of sync.
Though you can manually set the time, this has a high administrative overhead. The simplest and, in my opinion, the easiest solution is to use is a centralised time source such as a Network Time Protocol (NTP) server.
NTP is a networking protocol for clock synchronization between computer systems. They come in two flavours (Public and Private). A public NTP server is a service that is available for public consumption. Some are run by government agencies such as the National Institute of Standards and Technology (NIST), volunteer organizations such as the Network Time Protocol project (ntp.org), and other commercial organizations (eg. Microsoft). A private NTP server is within the local network and there for the sole use of an organization (or those it explicitly allows).
My preferred NTP location is a public NTP server. In many designs, there are security considerations that mean infrastructure servers/devices do not have direct access to the internet. An option would be a dedicated NTP appliance gaining its time from Global Positioning System (GPS) data. These can often be costly and only in a few edge cases reach the threshold that its benefits exceed their cost.
Where the client requirements are to limit public-facing network traffic, it would be advisable to have a local NTP server (Physical or Virtual). All devices/servers that are NTP capable should be pointed at this single source of truth for time. It would be suggested that the NTP server does have access to a public NTP server to ensure no time drift.
Lastly, another NTP server should be configured to reduce occurance of a single point of failure that a lost NTP server may create. As many devices/servers that offer connection to NTP servers are hierarchical by nature, you can define more than one NTP server in the configuration. The configuration is a primary and secondary setup. Therefore if the primary is uncontactable, the device/server will attempt to connect to the secondary.
https://docs.vmware.com/en/VMware-Validated-Design/5.1/sddc-planning-and-preparation/GUID-39743023-3139-4289-A2EC-C40DCC3AFB76.html?hWord=N4IghgNiBcIHYBcAOIC+Q (There are later versions of the VVD but this explains it well)
Be First to Comment