forked from openebs/openebs
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
28 additions
and
11 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,29 +1,46 @@ | ||
| # Overview | ||
|
|
||
| OpenEBS is a open source storage platform delivering containerized block storage for containers. OpenEBS aims at making storage instrastructure programmable, easy-to-use, consumed by applications via self-service. OpenEBS takes storage software upgrade seriously. | ||
| OpenEBS is a open source storage platform delivering containerized block storage for containers. | ||
|
|
||
| The storage controller functionality is delivered as containers - openebs/jiva. An OpenEBS Volume comprises of one or more containers working as a clustered microservice, providing block storage to other containers. OpenEBS Volumes are fully isolated user space storage engines that present the block storage via iSCSI and persist the data onto the storage attached to Nodes (aka Docker Hosts). The storage attached to the docker hosts can either be directly attached disks or cloud volumes depending on where the Container Cluster is deployed. OpenEBS uses *Maya*, a storage orchestration engine that helps in managing local and remote storage, integrate into the container orchestrators like Kubernetes, Docker Swarm, Nomad etc., manages QoS policies for OpenEBS Volumes. | ||
| Yes! The storage controller functionality is itself, delivered as containers. An OpenEBS Volume comprises of one or more containers working as a clustered microservice, providing block storage to other containers. This micro-services based architecture for storage controller functionality - where each Volume data is being served by its own set of containers, as opposed to a single monolothic storage controller software serving multiples volumes is what differentiates OpenEBS from traditional storage appliances. | ||
|
|
||
| OpenEBS, being container native, seamlessely integrates easily into the container orchestartors via OpenEBS Maya and OpenEBS Volume containers. | ||
| OpenEBS Storage Controller functionality comprises of serveral micro-services (or containers) that can be classified into two broad categories: OpenEBS Data Plane - that serves the data to the applications and OpenEBS Control Plane - that manages the OpenEBS Volume Containers. If you notice this classification, closely resembling that of a typical Container Orchestrator, it is because OpenEBS Volumes are delivered through containers and these containers are better managed by Container Orchestrators! So OpenEBS Control Plane services work in conjunction with the CO - schedulers, apiserver, etc., | ||
|
|
||
| ## OpenEBS Volume Container (aka jiva, aka data plane) | ||
|
|
||
| ## OpenEBS Volume Containers (aka jiva) | ||
| *openebs/jiva* containers are at the heart of the OpenEBS Volume's storage functionality. OpenEBS Volumes are fully isolated user space storage engines that present the block storage via iSCSI and persist the data onto the storage attached to Nodes (aka Docker Hosts). The storage attached to the docker hosts can either be directly attached disks or cloud volumes (like EBS, GPD, etc.,) depending on where the Container Cluster is deployed. | ||
|
|
||
| *openebs/jiva* containers are the heart of the OpenEBS Volume's storage functionality. OpenEBS Volumes provide persistent storage for containers, with resliency against system failures via a distrubuted architecture, faster access to the storage, snapshot and backup capabilities. In addition, provides mechanism for monitoring the usage and enforcing QoS policies. | ||
|  | ||
|
|
||
| OpenEBS Volume (or Jiva) Containes are scheduled onto the container hosts using Orchestration Engines. Jiva containers consume the disk storage from the local host or remote storage using volume plugins (like k8s persistent volumes). OpenEBS Volumes are described in yaml files, just like your application pods, are deployed through objects like Pods, Deployments, Services, StatefulSets etc., | ||
| OpenEBS Volumes provide persistent storage for containers, with resliency against system failures, faster access to the storage, snapshot and backup capabilities. In addition, provides mechanism for monitoring the usage and enforcing QoS policies. | ||
|
|
||
| Further details on the OpenEBS Volume Container - jiva can be found under the following repo - [openeb/jiva](https://github.com/openebs/jiva) | ||
| The Disks where the data is peristed are called as *Storage Backends*, which can be either host directories, attached block devices or remote disks. Each OpenEBS Volume comprises of an iSCSI Target Container (represented as openebs-vol1 in the above diagram) and one or more Replica Containers (openebs-vol1-R1 and openebs-vol1-R2). | ||
|
|
||
| ## OpenEBS Storage Orchestration (aka maya) | ||
| The application pods will access the storage via the iSCSI Target Container, whicn will replicate the data to all its replica's. In the event of the node failure, the iSCSI Target Container is started on one of the remaining online nodes, and will serve the data by connecting to the available Replica container(s). | ||
|
|
||
| Maya makes the storage infrastructure programmable via yaml files that the DevOps can define and commit, just like the container clusters or containerized applications. Maya builds on top of the container orchestration engine capabilities in terms of runtime, scheduling, monitoring etc., and extends the capabilities to orchestrate and simplify the management of storage. Maya will learn and provide storage metrics to the container schedulers for better placements of pods as well as storage migration between hosts within/across cluster(s). | ||
| ### Source Code | ||
|
|
||
| Maya is a set of components that can be further divided as follows: | ||
| - Services : These encapsulate a specific functionality like maya-apiserver, maya-agent, maya-mulebot, etc., that are either installed as binary services or container services. These will be either be running as Cluster Services (like the maya-apiserver), or on every docker host or node (like maya-agent) or can be completely out-of-band like (storage-analytics in the cloud). You can learn more about these services under the following repo - [openebs/maya](https://github.com/openebs/maya). | ||
| - [openebs/jiva](https://github.com/openebs/jiva) Storage Controller functionality which includes the replication logic | ||
| - [openebs/gotgt](https://github.com/openebs/gotgt) iSCSI Target functionality, which is used by *openebs/jiva*. | ||
|
|
||
|
|
||
|
|
||
| ## OpenEBS Control Plane (aka OpenEBS Storage Orchestration, aka maya) | ||
|
|
||
| OpenEBS Control Plane - auguments the functionality provided by the Container Orchestrator, with storage specific orchestration capabilities, via a set of services. OpenEBS control plane can hook into any of the container orchestrators like Kubernetes, Docker Swarm, Nomad, etc., making it possible to run OpenEBS hyper-coverged with Container Orchestrators. | ||
|
|
||
|  | ||
|
|
||
| OpenEBS Control Plane is also delivered as micro-services that can be further divided as follows: | ||
| - Services : Each service will encapsulate a specific functionality like maya-apiserver, maya-agent, maya-mulebot, etc., that are either installed as binary services or container services. These will be either be running as Cluster Services (like the maya-apiserver), or on every docker host or node (like maya-agent) or can be completely out-of-band like (storage-analytics in the cloud, represented as *maya cloud*). You can learn more about these services under the following repo - [openebs/maya](https://github.com/openebs/maya). | ||
|
|
||
| - Plugins : Maya allows the OpenEBS storage to be run along side any orchestration engine like kubernetes, docker swarm, nomad etc., This is made possible by the maya orchestration engine plugins. For example, one of the ways in which Kubernetes can consume OpenEBS Storage is via the K8s Dynamic Provisioners - [openebs-provisioner](https://github.com/openebs/external-storage/tree/master/openebs). | ||
|
|
||
| - Tools : CLI/UI tools that will help with installation or management of tasks. One of the first tools under heavy development is [mayactl](https://github.com/openebs/maya/tree/master/cmd/mayactl), that aims at simplying the management of OpenEBS Volumes. | ||
|
|
||
| In the current release, OpenEBS Control supports integration with Kubenetes. OpenEBS control plane represents the volume containes as Deployments and Services similar to other Applications deployed on Kubernetes. Since these Volumes can be expressed, as YAML files, OpenEBS allows to make storage infrastructure programmable. | ||
|
|
||
| Maya builds on top of the container orchestration engine capabilities in terms of runtime, scheduling, monitoring etc., and extends the capabilities to orchestrate and simplify the management of storage. Maya will learn and provide storage metrics to the container schedulers for better placements of pods as well as storage migration between hosts within/across cluster(s). | ||
|
|
||
|
|
||
| *Note: In future, OpenEBS can also be deployed as a storage service (non hyperconverged) like the traditional software defined storage, and can be connected via the storage plugins.* |