refactor(general): update overview and concepts sections (#944)

This PR changes several documents to reflect the recent changes in the OpenEBS and adds a new set of digrams. In a follow-up PR, the user guide section will be updated. Signed-off-by: kmova <[email protected]>
openebs-archive · Jul 16, 2021 · b9d6d7a · b9d6d7a
1 parent 4ed2168
commit b9d6d7a
Show file tree

Hide file tree

Showing 26 changed files with 608 additions and 887 deletions.
diff --git a/docs/architecture.md b/docs/architecture.md
diff --git a/docs/assets/app-engine-node-capabilities.svg b/docs/assets/app-engine-node-capabilities.svg
diff --git a/docs/assets/cas.svg b/docs/assets/cas.svg
diff --git a/docs/assets/control-plane-overview.svg b/docs/assets/control-plane-overview.svg
diff --git a/docs/assets/data-engine-overview.svg b/docs/assets/data-engine-overview.svg
diff --git a/docs/assets/data-engines-comparision.svg b/docs/assets/data-engines-comparision.svg
diff --git a/docs/assets/openebs-architecture.svg b/docs/assets/openebs-architecture.svg
diff --git a/docs/assets/openebs-control-plane.svg b/docs/assets/openebs-control-plane.svg
diff --git a/docs/assets/openebs-hld.svg b/docs/assets/openebs-hld.svg
diff --git a/docs/benefits.md b/docs/benefits.md
@@ -8,11 +8,11 @@ sidebar_label: Benefits
 
 <br>
 - [Open Source Cloud Native storage for Kubernetes](#open-source-cloud-native-storage-for-kubernetes)
-- [Granular policies per stateful workload](#granular-policies-per-stateful-workload) |
-- [Avoid Cloud Lock-in](#avoid-cloud-lock-in) |
-- [Reduced storage TCO up to 50%](#reduced-storage-tco-up-to-50) |
-- [Native HCI on Kubernetes](#natively-hyperconverged-on-kubernetes) |
-- [High availability - No Blast Radius](#high-availability) |
+- [Granular policies per stateful workload](#granular-policies-per-stateful-workload)
+- [Avoid Cloud Lock-in](#avoid-cloud-lock-in)
+- [Reduced storage TCO up to 50%](#reduced-storage-tco-up-to-50)
+- [Native HCI on Kubernetes](#natively-hyperconverged-on-kubernetes)
+- [High availability - No Blast Radius](#high-availability)
 <br>
 
 :::tip

diff --git a/docs/cas.md b/docs/cas.md
@@ -7,66 +7,59 @@ sidebar_label: Container Attached Storage
 ------
 
 
+## What is CAS?
 
-In CAS or Container Attached Storage architecture, storage runs within containers and is closely associated with the application that the storage is bound to. Storage runs as micro service and will have no Kernel module dependencies. Orchestration systems such as Kubernetes orchestrates the storage volume like any other micro services or container. CAS provides benefits of both DAS and NAS. 
 
+Container Attached Storage(CAS) is a software that includes microservice based storage controllers that are orchestrated by Kubernetes.  These storage controllers can run anywhere that Kubernetes can run which means any cloud or even bare metal servers or on top of a traditional shared storage system. Critically, the data itself is also accessed via containers as opposed to being stored in an off platform shared scale out storage system.
 
+<img src="/docs/assets/cas.svg" alt="Container Attached Storage" width="600px">
 
-## PVs on monolithic systems
+CAS is a pattern very much in line with the trend towards disaggregated data and the rise of small, autonomous teams running small, loosely coupled workloads.  In other words, my team might need Postgres for our microservice, and yours might depend on Redis and MongoDB. Some of our use cases might require performance, some might be gone in 20 minutes, others are write intensive, others read intensive, and so on. In a large organization, the technology that teams depend on will vary more and more as the size of the organization grows and as organizations increasingly trust teams to select their own tools.
 
-In non-CAS models, Kubernetes Persistent Volumes are still tightly coupled to the Kernel modules, making the storage software on Kubernetes nodes monolithic in nature.  
+CAS means that developers can work without worrying about the underlying requirements of their organizations storage architecture. To CAS, a cloud disk is the same as a SAN which is the same as bare metal or virtualized hosts.  Developers and Platform SREs don’t have meetings to select the next storage vendor or to argue for settings to support their use case, Developers can spin their our own CAS containers with whatever storage is available to the Kubernetes clusters.
 
-![NON-CAS](/docs/assets/non-cas.png)
+CAS reflects a broader trend of solutions – many of which are now part of Cloud Native Foundation – that reinvent particular categories or create new ones – by being built on Kubernetes and micro services and that deliver capabilities to Kubernetes based microservice environments. For example, new projects for security, DNS, networking, network policy management, messaging, tracing, logging and more have emerged in the cloud-native ecosystem and often in CNCF itself.
 
-## PVs on CAS systems
 
-In contrast, CAS enables you to leverage flexibility and scalability of cloud-native applications. The storage software that defines a Kubernetes PV (Persistent Volume) is based on the micro services architecture. The control plane (storage controller) and the data plane of the storage software (storage replica) are run as Kubernetes Pods and, therefore, enable you to apply all the advantages of being cloud-native to CAS.
-
-![CAS](/docs/assets/cas.png)
 
 ## Advantages of CAS
 
-<font size="5">Agility</font>
+### Agility
 
 Each storage volume in CAS has a containerized storage controller and corresponding containerized replicas. Hence, maintenance and tuning of the resources around these components are truly agile. The Kubernetes rolling upgrades capability enables seamless upgrades of storage controller and  storage replicas. Resources such as CPU and memory, can be tuned using container cGroups. 
 
-<font size="5">Granularity of Storage Policies</font>
+### Granularity of Storage Policies
 
 Containerizing the storage software and dedicating the storage controller to each volume brings maximum granularity in storage policies. With CAS architecture, you can configure all storage policies on a per-volume basis. In addition, you can monitor storage parameters of every volume and dynamically update storage policies to achieve the desired result for each workload. The control of storage throughput, IOPS, and latency increases with this additional level of granularity in the volume storage policies.
 
-<font size="5">Avoids Lock-in </font>
+### Avoids Lock-in
 
 Avoiding cloud vendor lock-in is the common goal for most users and enterprises. This goal has contributed significantly to the adoption of Kubernetes as it is a widely accepted orchestration platform for containers. However, the data of stateful applications remains dependent on the cloud provider and technology. With CAS approach, storage controllers can migrate the data in the background and live migration becomes a fairly simple task. In other words, stateful workloads can be moved from one Kubernetes cluster to another in a non-disruptive way for users.
 
-<font size="5">Cloud Native</font>
+### Cloud Native
 
 CAS containerizes the storage software and uses Kubernetes Custom Resource Definitions (CRDs) to represent the low-level storage resources, such as disks and storage pools. This model enables storage to be integrated into other cloud-native tools seamlessly. The storage resources can be provisioned, monitored, managed using cloud-native tools such as Prometheus, Grafana, Fluentd, Weavescope, Jaeger, and others.
 
-## PV is a micro service in CAS
-
-![CAS](/docs/assets/cas-arch.png)
-
-As shown in the above diagram, in CAS architecture, the software of storage controller and replicas are completely micro services based and hence no kernel components are involved. Typically, the storage controller POD is scheduled on the same node as the persistent volume to increase the efficiency and the replica pods can be scheduled anywhere on the cluster nodes. Each replica is configured completely independently from the others using any combination of local disks, SAN disks, and cloud disks. This allows huge flexibility in managing the storage allocation for workloads at scale. 
-
-## Hyperconverged and not Distributed
+Similar to hyperconverged systems, storage and performance of a volume in CAS is scalable. As each volume is having it's own storage controller, the storage can scale up within the permissible limits of a storage capacity of a node. As the number of container applications increase in a given Kubernetes cluster, more nodes are added, which increases the overall availability of storage capacity and performance, thereby making the storage available to the new application containers. This process is exactly similar to the successful hyperconverged systems like Nutanix. 
 
-CAS architecture does not follow a typical distributed storage architecture with blast radius limitations. With synchronous replication from storage controller onto the storage replicas, the storage becomes highly available. The metadata of volume replicas are not shared among the nodes and is independently managed on every local node. If a node fails, the storage controller, which is a stateless container in this case, is spun on a node where second or third replica is running and data continues to be available. Hence, with CAS there is no blast radius effect that is typically seen in distributed storage systems such as Ceph, Glusterfs, and so on in the event of node failures. 
+### Lower blast radius
 
-Similar to hyperconverged systems, storage and performance of a volume in CAS is scalable. As each volume is having it's own storage controller, the storage can scale up within the permissible limits of a storage capacity of a node. As the number of container applications increase in a given Kubernetes cluster, more nodes are added, which increases the overall availability of storage capacity and performance, thereby making the storage available to the new application containers. This process is exactly similar to the successful hyperconverged systems like Nutanix. 
+CAS architecture does not follow a typical distributed storage architecture that ends up having higher blast radius when nodes fail or rebuild is in progress. 
 
-<br>
+With synchronous replication from storage controller onto the fixed storage replicas, the storage becomes highly available. The metadata required to maintain the replicas is simplified to saving the information of the nodes that have replicas and information about the status of replicas to help with quorum. If a node fails, the storage controller, which is a stateless container in this case, is spun on a node where second or third replica is running and data continues to be available. Hence, with CAS there the blast radius is much lower and also localized to the volumes that have replicas on that node. 
 
 
 ## See Also:
 
-### [OpenEBS architecture](/docs/next/architecture.html)
+### [OpenEBS Architecture](/docs/next/architecture.html)
 
-### [CAS blog on CNCF](https://www.cncf.io/blog/2018/04/19/container-attached-storage-a-primer/)
+### [Blog: Container Attached Storage is Cloud Native Storage (CAS)](https://www.cncf.io/blog/2020/09/22/container-attached-storage-is-cloud-native-storage-cas/)
 
+### [Blog: Container Attached Storage](https://www.cncf.io/blog/2018/04/19/container-attached-storage-a-primer/)
 
+### [Webinar: Need for Container Attached Storage](https://www.cncf.io/webinars/kubernetes-for-storage-an-overview/)
 
+### [Connect with Community](/docs/next/support.html)
 <br>
 
-<hr>
 
-<br>