OpenEBS

本文图片来源Openebs 前言 关于 OpenEBS OpenEBS是一个运行在Kubernets上的开源存储项目，符合CAS(Container Attached Storage)架构， 它的所有组件全部运行在用户层，属于在k8s上云原生的分布式文件系统。 OpenEBS文件系统提供如下类别的特性，每个特性都可以用于某个特定环境下的解决方案。 cStor: 支持容错，高可用性，副本拷贝，支持快照，克隆等技术，其后端是由ZFS支持。 Jiva: 后端引擎为年轻的Longhorn，支持容错，副本拷贝，但没有cStor的快照和克隆技术。 Dynamic Local PV HostPath: 直接使用本地文件存储，优点是低延时，缺点是不支持高可用，一旦本地节点宕机或者本地磁盘损坏，则导致数据丢失， Dynamic Local PV Devices: 和HostPath类似，直接使用本地的硬盘进行存储，缺点也是无法支持高可用，但是低延迟。 Dynamic Local PV ZFS: 不支持高可用，但可以使用ZFS的功能(制作快照和克隆技术)，从而提升数据的保护能力，便于从灾难中恢复数据。 特性(Features) CAS 架构: PV和PVC都是容器化的，便于kubernets进行管理。 同步副本: 当采用cStor Jiva Mayastor存储引擎时，实现多副本同步拷贝，从而提供数据的高可用冗错机制。 快照和克隆: 采用cStor存储引擎时，支持写时复制快照技术，生成快照有助于我们可以回滚数据，克隆可以快速的生成一套生产环境数据以便开发在测试环境使用真实的生产数据。 备份和恢复: 使用备份工具及插件，快速的备份文件和恢复文件。 监控: openebs 组件会提供Metric接口，从而方便prometheus对其监控，进而调优整套存储方案的性能。 Alpha特性 支持ARM64，这也是我目前在使用的原因，自己在组建一套7*24小时运行的Polkadot委托节点，因为直接和收益挂钩，所以我调研了很多容器化的存储架构方案，虽然Openebs性能不如其他的老牌分布式存储系统，像Ceph，glusterfs这样的，但是它提供的CAS架构和高容错机制，以及支持ARM64，就让我决定选择它用于金融行业的云存储架构方案。 架构 基于单一服务的PV架构 整个PV的底层读写操作全部在内核层面完成，Kubernets只是增加了一层抽象，将PV通过底层的分布式文件读写接口导出到用户层，Pods通过PVC与PV绑定进行数据的读写处理。 基于微服务的PV架构 典型的CAS架构，数据的读写操作全部在用户层处理，CAS架构中的副本拷贝以及存储控制器全部由kubernets自身来进行调度，PV直接从CAS控制器的底层资源中获取存储设备，Pods通过PVC与PV绑定，从而完成数据的读写处理。 None CAS 与 CAS 对比 CAS的优势: 更加敏捷，可以直接在Pods层面去优化存储控制器。 更加精细的监控，能够直接监控到每一个Volume的IOPS，读写延迟。 解耦合，不依赖于第三方的云存储系统，比如你可以不改变yaml文件的情况下，将应用从一个集群，迁移到另一个集群，如果采用None CAS，则会非常依赖对于Kubenets不可见的存储管理系统，迁移过程中需要修改yaml文件中关于PV的描述。 云原生，好处就在于能够直接与其他系统对接，比如文件系统监控，管理，采用Kube CRD的方式直接调用底层的存储系统。 微服务架构 采用微服务的方式极大的提高了分布式文件系统的高可用性，因为整个存储的服务全部运行在用户层，每一个服务都可以从一个节点迁移到另外一个节点，只要我们满足副本的可用性，即使某一个节点宕机也不会影像我们线上的数据访问，保证系统的可用。 从上图中，我们可以看出Storage Controller直接管理底层的副本处理的相关Pods，应用层的Pods通过PV与Storage Controller沟通。 ...