Cluster, nodes, and services
What is a cluster
A cluster is a group of servers that vStack Center manages as a single resource. Each server in the cluster is called a node: it hosts a hypervisor, local disks, and storage pools. Virtual machines and virtual data centers (VDCs) run on top of this group rather than on a specific server.
The cluster exposes its parameters through its options. These include the cluster name and
identifier, site and location, limits for new
objects (vcpu_max, max_disk_size, max_ram_size, mtu_max), the pool
capacity threshold (pool_capacity_treshold), and a set of flags for enabled
features. The options are displayed alongside the node list, providing a single view
of cluster state.
Who manages what
vStack Center does not interact with nodes directly. Commands to manage cluster members — enable a node, disable a node, start or stop a service — go to Cluster Manager, a vStack OS component. The cluster dispatcher exchanges messages with it over ZeroMQ, and Cluster Manager delivers the command to the nodes over AMQP. This is why Cluster Manager unavailability appears in the API as a separate category of errors: vStack Center itself is running, but there is no component available to deliver the command.
Cluster Manager and Cluster master are different things. Cluster Manager is
the vStack OS component that manages nodes (its CLI on a node is vstack-cluster,
see the vStack OS documentation). Cluster master is access role No. 1 with full
cluster permissions. The former determines who executes commands; the latter determines who
is allowed to request them.
vStack Center collects some data through sources other than Cluster Manager. Hardware inventory, package versions, and node configuration parameters come from the node agent and are stored in the database. Actual CPU and memory consumption comes from InfluxDB. These sources behave differently, and those differences are visible in the UI.
| What you view | Source | What happens if the source fails |
|---|---|---|
| Node list, node and service statuses | Cluster Manager over ZeroMQ | No state is displayed; the screen reports an error retrieving status |
| Hardware inventory, software versions, configuration | Database populated by the node agent | Values are displayed but are outdated — check the Last_seen column |
| Actual CPU and RAM consumption | InfluxDB | Consumption is zero; node capacity is not displayed |
| Provisioning (resources allocated to VMs) | vStack Center database | Always calculated, independent of metrics |
The practical implication: "zero utilization" and "no data" are different states. Provisioned values remain reliable even when metrics are not being collected.
Two statuses for each object
A node or service is described by a pair of statuses rather than a single status. Administrative status is what the administrator has allowed. Operational status is what is actually happening. A difference between them indicates whether a node was intentionally taken out of service or failed on its own.
| Field | Object | Values | Meaning |
|---|---|---|---|
admin_status | node | ONLINE, OFFLINE | Whether the administrator has allowed the node to operate |
oper_status | node | node state | The actual state reported by the node |
enabled | node, service | true, false | Shorthand for administrative permission to operate |
admin_status | service | STARTED, STOPPED | Target service state |
oper_status | service | service state | Actual service state |
nodeId | service | node identifier | The node on which the service runs |
A cluster service is a unit that Cluster Manager starts on a specific
node. Services include storage pools (with names such as zpool_tank0) and cluster
system services. A service therefore has two independent dimensions: whether it is enabled or disabled,
and whether it is started or stopped. Enabling a service does not start it, and a running service
will stop if it is disabled.
What different users can see
All users share the same cluster status map, but what they can see depends on their privileges. A cluster administrator gets the full map, an observer gets the same map in "dashboard only" mode, and a regular user gets only a list of their VDCs.
| Privilege | What is visible |
|---|---|
View Cluster Status Map (full) (6003) | Full map: nodes, services, cluster options |
View Cluster Status Map (6000) without 6003 | The user's VDC list and options; no cluster membership data |
View Cluster Status Map (dashboard) (6004) without 6003 or 6000 | The same data, but marked as a dashboard — for viewing the summary only |
Privileges are evaluated in this order: 6003, then 6000, then 6004. For a user with both the vDC Admin (role_id=2) and Resource Viewer (role_id=5) roles, privilege 6000 therefore takes precedence over 6004. This user gets a VDC list. Dashboard mode is available to users who have 6004 but neither 6003 nor 6000.
Alongside nodes and services, vStack Center displays the state of the management machine: its file systems, CPU load, and memory. This is the control plane itself, not a cluster node — keep the two distinct.
Features controlled by flags
Some features are not always available. Cluster options contain flags such as
feature.*, and a feature controlled by a flag is unavailable when that flag
is disabled — even to the Cluster master role. Check the flag in advance: this takes less effort
than troubleshooting a rejected request.
| Flag | What it enables |
|---|---|
feature.hardware_inventory | Node hardware inventory and CPU core utilization by node |
feature.node_config_management | Node configuration: viewing and changing parameters, collecting software versions |
feature.physical_disc_management | Working with node physical disks |
feature.network_ports_management | Node port groups |
A flag has three possible values: enabled, disabled, and unset. Treat an unset flag as disabled.
Where to view state
Work from the top down. The Overview screen in Provider Data Center shows how much cluster capacity is available and how much is used, while its Resources tab breaks the same information down by node. Server Nodes shows the node list and the state of each node. Storage Resources shows storage pools and the nodes currently hosting them. The node card provides the most detailed view: its Software, Hardware, Disks, and Perfdata sections show package versions, inventory, disks, and metrics for a single node.
See also
- How to view cluster resources — an overview of cluster resources and aggregate metrics.
- How to manage cluster nodes — taking a node out of service and returning it to service, inventory, and configuration.
- How to manage cluster services — enabling, starting, and stopping services.
API methods
API operations covered on this page: get-statusmap, cluster-totals,
cluster-overview — see the API reference.