Persistent container storage made easy

Containers have made app deployment lightweight and portable.

We think your data should be too.

StorageOS for developers and DevOps

Build stateful containerized apps

  • High availability, low latency persistent block storage
  • Access storage volumes through Docker and Kubernetes plugins
  • Low-latency reads and writes
  • Fast, simple recovery from node failure (professional license)
  • High availability (professional license)
  • Install from Docker Store as a 40MB plugin or container
  • Manage via the RESTful API, CLI or GUI
  • Slack, forum and email support

StorageOS for infrastructure teams

Scale, manage and monitor storage infrastructure

  • Runs in user space, with no kernel dependencies
  • Runs on any 64-bit Linux system – bare metal, VMs, cloud or hybrid
  • Automate storage management and apply policy with rules
  • Proactive monitoring and reporting on policies and SLAs
  • Enhanced availability, thin provisioning and volume management for cloud storage
  • Quality of service

StorageOS for enterprise

Enterprise container storage solution at an ultra-low price point

  • Containerize workloads backed by enterprise storage solution
  • Bring agility and flexibility to existing storage arrays
  • Avoid vendor lock-in and complex refresh cycles
  • Moves storage away from a CAPEX model to an OPEX model
  • Enterprise class SLA-based support

How it works

To create a StorageOS cluster, deploy the StorageOS volume plugin or container on each node. This can be automated in Docker Swarm and 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.

Components

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.

Data Plane

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.

Control Plane

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 (Consul). A rules engine recommends data placement and configures data policy rules. The scheduler maintains desired state across the cluster.

Want to look at StorageOS in more detail?

Get started for free

Deploy a StorageOS cluster in 10 minutes – no credit card required.

StorageOS ticks all the boxes when it comes to simplifying storage provisioning and management with business rules automation, letting developers focus on building great applications that drive their users’ businesses.

Letizia Lukas, Director, exigo S.A.