How it works
To create a StorageOS cluster, deploy the StorageOS volume plugin or container on each node. This can be automated in Kubernetes. StorageOS nodes aggregate available server storage into a distributed pool and presents virtual block devices to clients on any node. It is backed by an external key/value store which is used for service discovery, configuration and health checking. Data is replicated synchronously to as many nodes required for durability, and if a node fails, one of the replicas is promoted to master.
Each node runs a control plane and/or a data plane component from the same container image. By default the data plane and control plane are started in the same container. It’s also possible to start the control plane and data plan in separate containers to support app and storage-centric node configuration for larger environments. StorageOS requires access to an external KV store to persist configuration.
The data plane processes all data access requests and pools the aggregated storage for presentation to Clients. Because the data plane manages data services independently, it can be started as a separate container process to separate apps and storage functions in larger environments.
The control plane is responsible for managing configuration, monitoring health, scheduling, controlling the rules engine, provisioning and recovery processes. It does this through the StorageOS API which is accessed by plugins (e.g. Docker, Kubernetes), StorageOS GUI and CLI and any REST requests. The API in turn communicates with the Control Plane components and other nodes in the cluster to take appropriate action.
The control plane is also responsible for maintaining state and does this over an embedded message bus (NATS) where data and cluster configuration state is maintained in a distributed KV store (etcd). A rules engine recommends data placement and configures data policy rules. The scheduler maintains desired state across the cluster.