OpenEBS Jiva can be used to dynamically provision highly available Kubernetes Persistent Volumes using local (ephemeral) storage available on the Kubernetes nodes.
Jiva provides containerized block storage controller.
Jiva Operator helps with dynamically provisioning Jiva Volumes and managing their lifecycle.
- Refer to the Jiva Operator Quickstart guide.
- Thin Provisioning
- Enforce volume quota
- Synchronous replication
- High Availability
- Incremental/Full Snapshot
- Full Backup and Restore (using Velero)
- Supports OS/ARCH: linux/arm64, linux/amd64
Jiva comprises of two components:
- A Target ( or a Storage Controller) that exposes iSCSI, while synchronously replicating the data to one or more Replicas.
- A set of Replicas that a Target uses to read/write data. Each of the replicas will be on a different node to ensure high availability against node or network failures. The Replicas save the data into sparse files on the host filesystem directories.
For ensuring that jiva volumes can sustain a node failure, the volumes must be configured with atleast 3 replicas. The target will serve the data as long as there are two healthy replicas. When a node with a replica fails and comes back online, the replica will start in a degraded mode and start rebuilding the missed data from the available healthy replicas.
If 2 of the 3 replicas go offline at the same time, then volume will be marked as read-only. This ensures that target can decided which of the replicas has the latest data.
Jiva is optimized for consistency and availability and not performance. There is a significant degradation in performance compared to local storage due to the following design choices:
- Jiva uses "strong consistency" approach where target will make the write operation as completed only after the data is confirmed to be written to all the healthy replicas.
- Also Jiva does not implement any caching logic, to allow for the jiva target and replica containers to be ephemeral.
- Jiva engine is completely written in user space to be able to run on any platform and make upgrades seamless.
If you need low latency storage, please checkout other OpenEBS Engines like Mayastor and Local PVs.
Some of the organizations that have publicly shared the usage of Jiva.
You can see the full list of organizations/users using OpenEBS here.
If you are using Jiva, and would like yourself to be listed in this page as a an adopter, please raise an issue with the following details:
- Stateful Applications that you are running on OpenEBS
- Are you evaluating or already using in development, CI/CD, production
- Are you using it for home use or for your organization
- A brief description of the use case or details on how OpenEBS is helping your projects.
If you would like your name (as home user) or organization name to be added to the ADOPTERS.md, please provide a preferred contact handle like github id, twitter id, linkedin id, website etc.
OpenEBS welcomes your feedback and contributions in any form possible.
- Join OpenEBS community on Kubernetes Slack
- Already signed up? Head to our discussions at #openebs
- Want to raise an issue or help with fixes and features?
- See open issues
- See contributing guide
- See Project Roadmap
- Want to join our contributor community meetings, check this out.
- Join our OpenEBS CNCF Mailing lists
- For OpenEBS project updates, subscribe to OpenEBS Announcements
- For interacting with other OpenEBS users, subscribe to OpenEBS Users
Please read the community code of conduct here.
OpenEBS Jiva uses the following two projects:
- Fork of the Longhorn engine, which helped with the significant portion of the code in this repo, helped us to validate that Storage controllers can be run as microservices and they can be coded in Go.
- The iSCSI functionality is provided by gostor/gotgt.
