Link Search Menu Expand Document

Management Cluster

Should you create a new datastore or use existing?

Choices:

  • Use existing Datastore
  • Add new Datastore
  • Add N new Datastores, for N VMs running Kubernetes etcd/Control Plane services

Which one is “best”? You guessed it - it depends. In all likelihood, though, a separate VMware Datastore (and therefore a new SolidFire volume) would be a good starting point.

N new datastores for N VMs (Nodes) would be better for situations where a higher HA is desirable, as a failure or failover of one Datastore wouldn’t impact all etcd nodes at the same time. Multiple Management Clusters are also a possibility, so one could have the important ones deployed across multiple datastores, and less important ones on one dedicated Datastore (or even shared, although Min QoS for such volumes would have to be set with care).

The one thing that doesn’t sound like a good idea at all is to put Management Cluster VMs on the same Datastore where vCenter or other non-Rancher VMs run.

ez-rancher (and presumably HCC) do not assume that Management Cluster would use PVCs.

Default Datastores on NetApp HCI

As of NetApp Deployment Engine 1.8P1, these two get created during HCI deployment:

  • NetApp-HCI-Datastore-01
  • NetApp-HCI-Datastore-02

Personally I’d create one or more new datastores (NetApp-HCI-Datastore-Rancher-0[1,2,3]) for the important Management Cluster.

Workload Cluster(s)

These could be on new Datastore, or spread across two or more, similar to Management Clusters.

ez-rancher allows downstream cluster managers to deploy Trident from catalog, but they need to obtain a dedicated storage account from VI or Storage Administrator.

Again, pay attention to Storage QoS settings (especially Min QoS). Personally I would suggest to evaluate (first in non-production) QoS SIOC to see if helps with intra-VM fairness when Rancher workload VMs are sharing one Datastore/Volume.