上QQ阅读APP看书，第一时间看更新

Some design decisions

Also, even if the public cloud is an option for SMB cases, most of them, for different reasons (one could be the lack of reliable network connectivity), are still building their own on-premises infrastructures. In SMB scenarios, a reasonable availability level could be between 99% and 99.9%, but there are some workloads that may require the higher level (or others that are not critical at all). The vSphere HA features could be enough for most cases.

Performance isn’t usually a problem, due to the computing capacity of a common server today; potentially, a single host can handle all the workloads, but of course, it represents a single point of failure. For this reason, two, or more commonly three, hosts are the typical configuration. The sizing of those hosts is not usually critical and reducing the cost could also be interesting, considering single socket configurations.

For the licenses aspect, VMware has a specific bundle called Essential Plus Kit with limited features but an affordable price that can cover an infrastructure with up to three hosts. Other vendors have similar bundles to simplify the adoption in this scenario, or perhaps have a subscription model. In this case, the design is quite simple, because you just have to build a two or three node cluster and think about the resiliency and the recoverability aspects. The three node limits could be enough for SMBs, unless we want to also include a disaster recovery part (but you can use other licenses on the second site).

For the storage part, you can use some kind of hyper-converged solution (although, for vSAN, three hosts are just the minimum). Alternatively, use an external storage, maybe with a direct SAS connection to avoid the need for a fabric.

An interesting design option has been introduced with VMware vSphere 6.5 Update 1, through a significant change in the maximum number of hosts that the vCenter Server Foundation edition can manage now up to four nodes (not only three nodes, like in the past).

What are the possible implications of this? With four nodes, you can do interesting things that you can now plan in your design:

vSAN cluster: Technically, three nodes are the minimum, but I don’t like to build a vSAN cluster with only three nodes. I prefer to have four in order to plan a better resiliency.
vSAN two node cluster: Does it make sense to have a cluster with just two nodes, the witness appliance on a third node, and to manage both the third node and the witness with the same vCenter? Maybe yes, or, let’s say, why not? Now it can be considered.
Production and DR cluster managed by the same vCenter: Also possible with three nodes, but limited to 2+1; in this case, you have more flexibility.
Scale out instead of scale in: Will it make sense to have more hosts (maybe with a single processor) instead of few?

Instead, for very small environments or for very limited budgets, some other minimal solutions can be considered, if you can reduce the availability and recoverability requirements. For example, just two nodes with the Essential license (that is the cheapest one, but it does not provide any cluster functionality), one active, and one in manual standby (for each workload) with a VM based replication solution to have a minimum level of recoverability (several third-party backup solutions provide VM replication across hosts).

For an SMB scenario, there could be a risk in using licenses based per VM or instance, considering that the estimated number could increase in the future (VM spread). But if the growth could be estimated carefully, it could make sense to consider licensing based per VM or per space. Note that for VMware vSphere, the Essential Plus (or in some minor cases, the Essential) bundles remain the most popular, and they just license three bi-processor hosts.