乐趣区

关于云计算:云原生时代需要什么样的存储系统

jiezi

存储系统作为撑持业务零碎的基础设施软件的外围之一，始终处于一直变动和变革中。从晚期的物理机时代、到虚拟化技术的成熟遍及，到当初大规模部署的云环境都有存储系统在背地默默撑持。近年来，以容器、微服务、DevOps 为代表的云原生技术，受到了市场的宽泛关注，其可能更好地反对企业的云原生利用、自动化治理和业务翻新，满足用户在任何工夫、任何地点对任何利用的响应需要。相应地，存储系统作为撑持数据长久化、承载业务稳固运行的外围组件, 同样面临粗浅改革。

什么是云原生存储？

要了解云原生存储，咱们首先要理解云原生技术的概念，CNCF 对云原生定义如下：

云原生技术有利于各组织在私有云、公有云和混合云等新型动静环境中，构建和运行可弹性扩大的利用。云原生的代表技术包含容器、服务网格、微服务、不可变基础设施和申明式 API。

这些技术可能构建容错性好、易于治理和便于察看的松耦合零碎。联合牢靠的自动化伎俩，云原生技术使工程师可能轻松地对系统作出频繁和可预测的重大变更。

简言之：云原生利用和传统利用并没有一个规范的划分界线，其形容的是一种技术偏向，即越合乎以下特色的利用越云原生：

  • 利用容器化
  • 服务网格化
  • 申明式 API
  • 运行可弹性扩大
  • 自动化的 DevOps
  • 故障容忍和自愈
  • 平台无关，可移植的

云原生存储的概念来源于云原生利用，顾名思义：一个利用为了满足云原生个性的要求，其对存储所要求的个性是云原生存储的个性，而满足这些个性的存储计划，能够称其为云原生的存储。

为什么须要云原生存储？

云原生存储仍然是容器化面临的次要挑战之一

依据 CNCF 的调研报告：在应用 / 部署容器过程中遇到的挑战中，仍然有高达 29% 的人抉择存储。存储简直和平安问题一样，成为利用容器化过程中的次要难点。

目前，云原生存储遇到的挑战体现在以下几个方面：

易用性 ：存储服务部署、运维简单，云原生化水平低，短少与支流编排平台整合。

高性能 ：大量利用 IO 拜访，IOPS 需要高，低时延，性能成为利用运行效率瓶颈。

高可用 ：云原生存储曾经利用到生产环境，须要高牢靠 / 高可用，不能呈现单点故障。

敏捷性 ：PV 疾速创立、销毁、平滑的扩大 / 膨胀，PV 随 Pod 迁徙而疾速迁徙等。

有状态利用当初已成为容器存储的主体

随着 Kubernetes 的利用水平增强，并且随同着 IoT、5G、AI 等技术的成熟，越来越多的有状态利用被搬上容器平台。依据 CNCF 的调研报告，曾经有超过一半的用户曾经在容器中运行有状态利用，并且有 23% 的用户正在评估或打算在容器中部署有状态利用。

通常，有状态利用对存储的有如下三点需要：

① Volume 领有独立与 pod 的生命周期。

② Volume 中的数据是能够长久保留的。

③每个 pod 与其应用的存储关系是稳固的，不会因降级等因素而发生变化。

当然不同类型的利用具备不同的 IO 特点，对于存储有不同需要：

  • 数据库 —— 交易型数据库（OLTP）MySQL 和 PostgreSQL 通常承载的都是外围交易类业务，对存储系统的数据可靠性、性能要求极高。
  • AI/ML —— ML 应用程序, TensorFlow 应用分布式计算解决不同过程中的图形局部，每个过程都能够在独自的容器中运行。
  • 大数据分析 —— 剖析型数据库（OLAP），如 Spark，存储系统的可靠性以及提早的要求都不像 OLTP 数据库那么高，须要大容量存储。
  • HPC/ 渲染 —— 如图形绘制和视频转码工具，都能够应用应用程序实例集群化来解决大型批处理作业。
  • Devops —— Jenkins/Gitlab，通常 Jenkins 基于主从模型构建分布式集群，即会应用一个文件目录来保护其状态。因而，须要在不同主机上的容器之间共享该目录。

多云环境带来的云原生挑战

现在，越来越多的 IT 组织正在构建混合云和多云环境以撑持其业务运行。从容器的角度来看，咱们晓得在多个云平台上运行应用程序曾经成为了容器技术应用的次要驱动力，带来了远超以往的好处，如开发者效率的晋升以及反对微服务等。然而，多云以对立的形式治理、爱护和部署存储可能具备挑战性：

  • 多个 API —— 云服务通过 API 进行通信。尽管 RESTful API 有一些标准化，但不同的提供者会创立不同的 API 构造。这能够包含不同的规定构造或不同的语言。这些差别须要应用程序自定义以实现跨服务通信。
  • 兼容性问题 —— 为了顺利集成到繁多环境中，存储服务须要跨云兼容。这意味着服务须要适应雷同的数据结构并容许与雷同的工具集成。
  • 简单的治理 —— 很难确保跨云服务和环境的可见性。它须要集中监控和联结服务，例如身份和访问控制。如果没有中心化，服务可能会呈现配置差别或谬误，并减少脆弱性。

如何抉择云原生存储

常见云原生存储计划

OpenEBS

OpenEBS 是目前 CAS（Container Attached Storage）的一种开源实现计划，因而它间接运行在 Kubernetes 平台上，通过 Kubernetes 平台进行编排与调度。

OpenEBS 反对如下三种存储类型，别离为 cStor、Jiva 以及 LocalPV。

特点：

  • 每个 Volume 都由一个轻量级的 Controller 来治理，这个 Controller 能够是一个独自的 Pod。
  • 这个 Controller 与应用该 Volume 的利用 Pod 在同一个 Node（Sidecar 模式）。
  • 不同的 Volume 的数据应用多个独立的 Controller Pod 进行治理。

OpenEBS 存储引擎抉择：

Jiva：实用于低容量的工作负载，比方内部测试、集体体验上。

Cstor：存储级别上具备高可用性、快照、克隆等的利用，比方 MYSQL、GitLab、Jinkens 等。

LocalPV：要求高性能、低提早，通常更适宜分布式的利用，这些利用实质就是分布式的，内置的高可用性，比方 Zookeeper、Prometheus、Cassandra、MongoDB、Elastic 等。

Prometheus 生成警报，须要低提早存储而不是复制存储，因而抉择 LocalPV。

Rook-Ceph

Rook 的指标并不是从新造轮子实现一个全新的存储系统，最开始 Rook 我的项目仅仅专一于如何实现把 Ceph 运行在 Kubernetes 平台上，Rook Ceph 则同时提供了块存储、共享文件系统存储以及对象存储接口。

Rook 除了能反对 Ceph，还反对：EdgeFS、CockroachDB、Cassandra、NFS、Yugabyte DB。不同的存储通过不同的 Operator 实现，但应用起来基本一致，Rook 屏蔽了底层存储系统的差别。

两种存储计划比照

OpenEBS 和 Rook 的长处
  • 反对 CSI，具备很好的容器数据卷接入能力。
  • 社区较为沉闷，网络资源、应用材料丰盛，容易动手。
  • 与云原生编排零碎高度交融，可能齐全用云原生的思维对存储系统进行部署、降级、扩容等运维治理。
不足之处
  • OpenEBS/Rook 性能差，IO 性能、吞吐、时延等方面都体现欠佳，很难利用在高性能服务场景。
  • Rook 保护老本高，尽管部署、入门简略，但组件多，架构简单，排错艰难，一旦运行中呈现问题解决起来十分辣手，须要有很强的技术团队加以保障。
  • OpenEBS LocalPV 尽管性能高，然而没有高可用性，单点故障，而且短少企业级个性克隆、快照等个性。

QingStor 的云原生存储及利用实际

QingStor NeonIO 是一款反对容器化部署的企业级分布式块存储系统，可能给 Kubernetes 平台上提供动态创建（dynamic provisioning) 长久存储卷（persistent volume) 的能力，反对 clone、snapshot、resstore、resize 等性能。

NeonIO 架构图

NeonIO 架构如图上所示。

zk/etcd: 提供集群发现、分布式协调、选 master 等服务

mysql：提供元数据存储服务，如 PV 存储卷的元数据

center：提供逻辑治理服务，如创立 PV 卷，快照

monitor: 提供监控服务，可能把采集监控指标裸露给 Prometheus

store：存储服务，解决利用 IO 的性能

portal：提供 UI 界面服务

CSI：提供 CSI 的规范 IO 接入服务

NeonIO 的特点

简略易用

  1. 全栈组件容器化：服务组件、CSI、Portal 容器化
  2. 残缺实现 CSI 接口：提供规范的 IO 接入能力，可动态、动态创建 PV

  3. UI 界面，“零“运维

    • 存储运维操作界面化、告警、监控可视治理。
    • 基于 PV 粒度的性能监控，如 IOPS、吞吐量，能够疾速定位到热点 PV。
    • 基于 PV 粒度的 QoS，保障用户高优先级的服务质量。
    • 存储的扩容、降级、劫难复原运维操作，基于 K8s 命令即可实现。
  4. 与云原生高度交融

（1）反对 Prometheus，通过 ServiceMonitor 把 NeonIO 的采集指标裸露给 Prometheus、Grafana，进行图形化展现。

（2）同时 UI 界面可与 Prometheus 对接，展现其余云原生监控的指标，如 node-exporter 的磁盘 IO 负载、带宽等。

（3）服务发现、分布式协调反对 etcd、元数据的治理，应用 CRD 的形式。

  1. 一键式部署：采纳 Operator 形式部署，并实现集群服务主动启动

超高性能

  1. 全闪的分布式存储架构

（1）集群中所有节点独特承当压力，IO 性能随着节点减少而线性增长；

（2）存储介质反对 NVME SSD；

（3）反对 RDMA：通过高速的 RDMA 技术将节点连贯。

  1. 极短的 IO 门路：摈弃文件系统，自研元数据管理系统，使 IO 门路极短。
  2. 应用 HostNetwork 网络模式

益处：

（1）Store CSI Pod 应用 HostNetwork，间接应用物理网络，缩小网络档次。

（2）管理网络、前端网络、数据同步网络拆散，防止网络竞争。

高可用

  1. 服务组件可靠性与可用性

(1) 治理服务默认应用 3 正本 Pod，正本数能够配置，举荐应用 3/5 正本，任何一 Pod 因故障无奈提供服务，还有其余 Pod 提供服务。

(2) 应用探针检测 Pod 服务是否可用，是否存活，检测到 Pod 服务不可用剔除组件服务，检测到 Pod down 掉后重启 Pod，使其重新启动服务。

  1. 数据的可靠性与可用性

(1) Volume 分片为 Shard

(2) 每个 Shard 独立抉择存储地位

(3) 每个 Shard 的 3 个正本存储在不同的物理节点上

(4) 写入时同步写入 3 个正本，强统一

(5) 读取时只从主正本读

(6) 正本数按 volume 可配

敏捷性

  1. Pod 跨节点重建高效：2000PV 的挂载 / 卸载 16s
  2. 批量创立 PV 能力：2000PV 的创立 5 min

NeonIO 性能体现

测试平台：NeonIO 超交融一体机集群（3 个节点，192.168.101.174 – 192.168.101.176）

留神：所有测试均应用 NVMe SSD。卷大小 = 1TiB。性能工具

图中黄色示意的是 NeonIO，第一张图纵坐标是 IOPS，第二张图纵坐标是毫秒，从后果来看，无论是单正本还是 3 正本，NeonIO 在 IOPS、时延都有显著的劣势。

NeonIO 利用场景

  • Devops 场景：批量疾速创立 / 销毁 PV 能力，2000PV 创立 5min。
  • 数据库场景：WEB 网站后端数据库 MySQL 等提供稳固的长久化存储，提供高 IOPS、低时延。
  • 大数据利用剖析场景：提供超大容量，PV 可扩容到 100TB。
  • 计算和存储拆散部署场景：K8s 集群 1 部署 NeonIO，K8s 集群 2 通过 CSI 应用 K8s 集群 1 的 NeonIO 存储。

作者

杨兴祥 QingStor 高级软件工程师

本文由博客一文多发平台 OpenWrite 公布！

退出移动版