the nutanixist 14: the PSC, identity and architecture

When I joined VMware, the company had just released version 6.0, and along with it, the external PSC (Platform Services Controller).

The idea behind the PSC was to centralize a set of core services, upon which the rest of the product portfolio could be built, including vCenter.

The problem was availability.

vCenter 6.0 depended on the PSC to be available so you could log in.

If the PSC were down or unreachable, you would be unable to log in.

You encountered a peculiar complexity: vCenter was up, but the PSC was unreachable, and you couldn’t log into vCenter to resolve the issue with the PSC (and yes, vSphere HA can’t help).

In short, the failure domain of the PSC and vCenter was distinct, and because they were different, your infrastructure only worked when the PSC and vCenter were available and reachable.

As you add more vCenters to a PSC, in what became known as the MxN configuration, for your entire environment to work as expected, everything had to be working.

So? If your environment consists of 10 vCenters and one PSC, and the connection to the PSC is broken for any vCenter, then that vCenter isn’t functioning correctly.

So? Just use the local account.

Except, the whole point of the PSC was not to use local accounts.

Because not being able to log into vCenter was unacceptable, customers had to maintain both local accounts and PSC accounts.

So what? It’s just an occasional thing. Except it isn’t. As the number of vCenters increases, the probability of any one vCenter being unable to reach its PSC increases, which means some part of your infrastructure is always requiring you to use a local password.

Where things got messy was during the restoration from backup. The PSC didn’t just include your identities; it also included tag definitions. If you restored a PSC from backup, then from the point of view of all the vCenters, it appears to have reverted to an earlier state. And so the tag definitions could suddenly disappear. And if they did, then any operational tooling that depended on the tags would break.

From 6.5 to 7.0, the vCenter team rectified that architectural flaw. We worked to make the transition as seamless as possible, driven by one consideration: never break the fault domain between vCenter and login.

What surprised me, according to the VCF 9.0 documentation, which I probably misread, is that VCF now requires a single centralized broker and also requires local identities.

So while VCF has gone around and around on this topic, Nutanix chose a different path; instead of relying on a single global broker, each cluster and system has its own broker, which can federate with one another.

I wondered why both companies took different paths. At the core, it comes down to the fact that Nutanix considers the cluster the irreducible control plane, while VMware considers ESX. A cluster can have an identity broker, whereas every host cannot—details in architecture matter.