【作者】孙佳明，兴业数金应用平台部软件工程师。本科毕业于东南大学，硕士毕业于电子科技大学，熟悉云计算、云原生技术，目前主要从事兴业银行容器云平台研发、建设以及行内应用上云技术支持相关工作。





1 背景

某银行已经落地容器云平台，并已经承载运行部分关键微服务应用：

1. 越来越多的有状态服务也开始考虑通过该容器运平台进行调度管理和运行，诸如spark、mysql以及各类消息中间件等

2. 目前主要以FC-SAN、vSAN作为应用存储解决方案，大部分应用使用本地物理磁盘

3. 容器云平台目前提供Ceph块存储作为存储解决方案，通过StatefulSet解决容器应用持久化存储需求



2 方案需求

1. 存储卷管理需求：容器的一次调度或者故障恢复，会带来卷的挂载和卸载，卷的挂载和卸载一方面需要具有足够的稳定性，同时也需要考虑性能需求，避免应用延迟。

2. 存储卷快照管理需求：传统的存储卷快照策略主要从资源角度进行管理，而容器的存储卷往往动态分配而来，快照策略需要与容器应用备份需求保持一致。

3. 容量扩容需求：存储卷容量需要考虑扩容的能力，最大程度避免对应用运行的影响。

4. 运维管理需求：随着容器有状态应用的增长，对传统存储运维工作也会带来挑战，整体方案需要兼顾运维敏捷和安全。

5. 分布式存储需求：分布式应用的横向扩展，带来存储横向扩展的需求，方案需考虑引入分布式存储适配分布式应用在容器云部署的需求。



3 Kubernetes CSI原理及方案设计

3.1 Kubernetes存储动态供应

PV后端的存储可以是iSCSI，RBD，NFS等存储资源，供集群消费，PersistentVolumeClaim（PVC）就是对这些存储资源的请求。PVC消耗的资源是PV。于是，在Kubernetes中Pod可以不直接使用PV，而是通过PVC来使用PV。

通过PVC可以将Pod和PV解耦，Pod不需要知道确切的文件系统和支持它的持久化引擎，可以把PVC理解为存储的抽象，把底层存储细节给隔离了。另一方面，如果使用PV作为存储的话，需要集群管理员事先创建好这些PV，但是如果使用PVC的话则不需要提前准备好PV，而是通过StorageClass把存储资源定义好，Kubernetes会在需要使用的时候动态创建，这种方式称为动态供应 (Dynamic Provisioning)。

图片

详细流程分析如下：

1. Pod加载存储卷，请求PVC

2. PVC根据存储类型(此处为rbd)找到存储类StorageClass

3. Provisioner根据StorageClass动态生成一个持久卷PV

4. 持久卷PV和PVC最终形成绑定关系

5. 持久卷PV开始提供给Pod使用

3.2 实现存储动态供应

动态供应比静态供应灵活更多，而且这种方式还解耦了Kubernetes系统的计算层和存储层，更重要的是它给存储供应商提供了可插拔式的开发模型，存储供应商只需要根据这个模型开发相应的卷插件即可为Kubernetes提供存储服务。

有三种方法实现卷插件:

◎ 第一种，Kubernetes内部代码中实现了一些存储插件，用于支持一些主流网络存储，叫作In-treeVolume Plugin。

◎ 第二种 Out-of-tree Provisioner：如果官方的插件不能满足要求，存储供应商可以根据需要去定制或者优化存储插件并集成到Kubernetes系统。

◎ 第三种是容器存储接口CSI (Container Storage Interface)，是Kubernetes对外开放的存储接口，实现这个接口即可集成到Kubernetes系统中。CSI特性在刚过去的12月正式GA，同时社区也宣布未来将不再对In tree/Out of tree继续开发，并将已有功能全部迁移到CSI上，所以对于存储供应商和使用者来说，第三种CSI是更推荐的解决方案。

3.3 CSI 插件原理及设计方案

原理

图片
CSI 插件要遵循 CSI 的标准实现相关的接口，在实现接口中，可以调用底层存储服务端的 API，CSI 插件在容器平台和存储资源体系结构中起到承上启下的作用。

容器平台可以通过 gRPC 调用 CSI 插件，对接 CSI 接口，支撑容器平台对于存储卷管理的功能，如创建、挂载、删除等操作。而 CSI 插件实现 CSI 接口，是通过调用存储服务端 API 实现相关业务逻辑。

Kubernetes CSI 对接组件和 CSI 存储插件共同构成存储插件层，在 Kubernetes 和存储服务之间。

部署架构

图片
蓝色部分指的是 K8S 与 CSI 的对接组件，这是由 Kubernetes 团队维护的，绿色部分是开发的 CSI 存储插件。

首先可以从 Controller 服务来看，CSI 插件在部署时分为 Controller 类服务和 Node 类服务，Controller类服务是从存储服务端的角度对存储资源进行相应的操作。

Controller 服务相当于 CSI 插件大脑，只需要部署 Controller 服务的一个副本即可。在 Controller 服务里，封装了 K8S 和 CSI 的对接组件，包括 External Provisioner、External Attacher 和开发的 CSI 存储插件也封装在这个服务里。主要流程是通过 External Provisioner 和 External Attacher，他们会主动获取 K8S API Server 存储的相关资源信息，再调用 Controller 里的 CSI 存储插件所使实现的 CSI 接口，对存储服务端的存储资源进行相关操作。

Node 服务使用 K8S DaemonSet 进行创建，在 Node 服务里，会封装一个 Driver Registrar 这么一个K8S 和 CSI 的对接组件。这个组件的主要功能是将 Node 服务注册。

在 Node 服务中，也有个 CSI 存储插件的容器，在这个容器中，接收到本 Node 上 Kubelet 的调用，Kubelet 可以直接通过 UDS 调用 CSI 插件，Node 服务 CSI 存储插件的容器实现的相关 CSI 接口对主机上的存储卷进行操作，比如对主机上的存储卷进行分区格式化或者将存储卷挂载至某个容器的指定路径下，或者从某个容器的指定路径中进行卸载操作。



4 Ceph RBD/Ceph FS provisioner部署案例

根据容器云平台目前提供Ceph块存储作为存储解决方案的背景，可通过Ceph RBD/Ceph FS provi-sioner部署，实现容器平台使用Ceph存储的动态供应。

rbd-provisioner为kubernetes 1.5+版本提供了类似于kubernetes.io/rbd的ceph rbd持久化存储动态配置实现。

部署rbd-provisioner案例

参考：https://github.com/kubernetes-incubator/external-storage

部署完rbd-provisioner，还需要创建StorageClass。创建SC前，我们还需要创建相关用户的secret。

创建secret保存client.admin和client.kube用户的key，client.admin和client.kube用户的secret可以放在kube-system namespace，但如果其他namespace需要使用ceph rbd的dynamic provisioning功能的话，要在相应的namespace创建secret来保存client.kube用户key信息；

说明

在OpenShift、Rancher、SUSE  CaaS以及本Handbook的二进制文件方式部署，在安装好ceph-common软件包的情况下，定义StorageClass时使用kubernetes.io/rbd即可正常使用ceph rbd provisioning功能。

图片
图片




5 在容器云的卷管理、快照、容量管理方案及适用场景

可参考：https://github.com/container-storage-interface/spec/blob/master/spec.md

5.1 CSI中可实现的控制器服务RPC

CreateVolume

如果控制器插件具有CREATE_DELETE_VOLUME控制器功能，则必须实现此RPC调用。该RPC将由CO调用，以代表用户（将其作为块设备或已挂载的文件系统使用）来供应新卷。

此操作必须是幂等的。如果已经存在与指定卷“名称”相对应的卷，可以从accessibility_requirements访问该卷，并且与CreateVolumeRequest中指定的capacity_range，volume_capabilities和parameters兼容，则插件必须回复“0单击确定，并带有相应的CreateVolumeResponse。

插件可以创建3种类型的卷：

◎ 空卷，当插件支持CREATE_DELETE_VOLUME可选功能时。

◎ 从现有快照中，当插件支持CREATE_DELETE_VOLUME和CREATE_DELETE_SNAPSHOT可选功能时。

◎ 从现有的卷。当插件支持克隆并报告可选功能CREATE_DELETE_VOLUME和CLONE_VOLUME时。

DeleteVolume

如果控制器插件具有CREATEDELETEVOLUME功能，则必须实现此RPC调用。CO将调用此RPC取消供应卷。

此操作必须是幂等的。如果对应于指定volume_id的卷不存在或与该卷关联的工件不再存在，则插件务必回复0 OK。

如果Controller Plugin支持在不影响其现有快照的情况下删除卷，则这些快照必须仍然可以完全正常运行，并且可以作为新卷的源，并且在删除卷后出现在ListSnapshot调用中。

ControllerPublishVolume

如果控制器插件具有PUBLISHUNPUBLISHVOLUME控制器功能，则必须实现此RPC调用。当想要将使用该卷的工作负载放置到节点上时，CO将调用此RPC。插件应该执行使卷在给定节点上可用所需的工作。插件不得假定此RPC将在将使用该卷的节点上执行。

ControllerUnpublishVolume

这个RPC是ControllerPublishVolume的反向操作。在卷上的所有NodeUnstageVolume和NodeUnpublishVolume被调用并成功之后，必须调用它。插件应该执行使卷准备好被其他节点消耗的必要工作。插件不得假定此RPC将在先前使用该卷的节点上执行。

ValidateVolumeCapabilities

控制器插件必须实现此RPC调用。CO将调用此RPC，以检查预配置的卷是否具有CO所需的所有功能。仅当支持请求中指定的所有卷功能时，此RPC调用才应返回“已确认”（请参见下面的注意事项）。此操作必须是幂等的。

ListVolumes

如果控制器插件具有LIST_VOLUMES功能，则必须实现此RPC调用。插件应返回有关它所知道的所有卷的信息。如果在CO同时通过ListVolumes结果分页的同时创建和/或删除卷，则CO可能见证列表中的重复卷，不见证现有的卷，或两者兼而有之。当通过多次调用ListVolumes遍历卷列表时，CO不会期望所有卷具有一致的“视图”。

5.2 快照

要实现快照特性，CSI驱动程序必须添加对附加控制器功能CREATE_DELETE_SNAPSHOT和list_snapshot的支持，并实现附加控制器RPCs: CreateSnapshot、DeleteSnapshot和listsnapshot。

图片
使用Kubernetes创建一个新的快照

一旦定义了VolumeSnapshotClass对象，并且有了要快照的卷，就可以通过创建VolumeSnapshot对象创建新的快照。

快照的源指定创建快照的卷。它有两个参数:

◎ kind - 必须是PersistentVolumeClaim

◎ name - PVC API对象名称

假定快照卷的NameSpace与VolumeSnapshot对象的NameSpace相同。

图片

在VolumeSnapshot规范中，用户可以指定VolumeSnapshotClass，该类包含关于应该使用哪个CSI驱动程序创建快照的信息。当创建VolumeSnapshot对象时，参数fakeSnapshotOption: foo和VolumeSnapshotClass中引用的任何秘密都会传递给CSI plugin com.example。通过CreateSnapshot调用驱动csi。

使用Kubernetes导入现有快照

我们可以通过手动创建一个VolumeSnapshotContent对象来表示现有快照，从而将现有快照导入Kubernetes。因为VolumeSnapshotContent不是NameSpace API的对象，所以只有系统管理员才有权创建它。

创建了VolumeSnapshotContent对象之后，用户可以创建指向VolumeSnapshot对象的VolumeSnapshot对象。外部快照控制器将在验证快照是否存在以及VolumeSnapshot和VolumeSnapshotContent对象之间的绑定是否正确之后，将快照标记为ready。一旦绑定，快照就可以在Kubernetes中使用了。

VolumeSnapshotContent对象应该使用以下字段创建，以表示预先准备好的快照：

◎ csiVolumeSnapshotSource- 快照识别信息。

◎ snapshotHandle - 快照的名称/标识符。这个字段是必需的。

◎ driver-用于处理此卷的CSI驱动程序。这个字段是必需的。它必须匹配快照控制器中的快照器名称。

◎ creationTime和restoreSize - 这些字段对于预先准备的卷是不需要的。外部快照控制器将在创建后自动更新它们。

◎ volumeSnapshotRef-在此对象之前，应先绑定VolumeSnapshot对象。

◎ name和namespace - 它指定内容绑定到的VolumeSnapshot对象的名称和命名空间。

◎ UID - 这些字段对于预先准备的卷是不需要的。外部快照控制器将在绑定后自动更新字段。如果用户指定UID字段，他/她必须确保它与绑定快照的UID匹配。如果指定的UID不匹配绑定快照的UID，则将该内容视为孤立对象，控制器将删除它及其关联的快照。

◎ snapshotClassName - 这个字段是可选的。外部快照控制器将在绑定后自动更新字段。

图片

图片


创建VolumeSnapshot对象，允许用户使用快照：

◎ snapshotClassName - 卷快照类的名称。这个字段是可选的。如果设置了快照，快照类中的snapshotter字段必须匹配快照控制器的snapshotter名称。如果没有设置，快照控制器将尝试找到一个默认快照类。

◎ snapshotContentName - 卷快照内容的名称。这个字段对于预先准备的卷是必需的。

图片


一旦创建了这些对象，快照控制器将把它们绑定在一起，并将Ready (under Status)字段设置为True，以指示快照可以使用了。

使用Kubernetes从快照中提供一个新卷

要提供预填充快照对象数据的新卷，请使用PersistentVolumeClaim中的新数据源字段。它有三个参数:

◎ name - 表示要用作源的快照的VolumeSnapshot对象的名称

◎ kind - 必须是 VolumeSnapshot

◎ apiGroup - 必须是 snapshot.storage.k8s.io

假定源VolumeSnapshot对象的NameSpace与PersistentVolumeClaim对象的NameSpace相同。

图片

图片


当创建PersistentVolumeClaim对象时，它将触发一个新的卷的供应，该卷预先填充了来自指定快照的数据。



6 分布式存储的适用场景

体现分布式存储技术特点：多副本一致性、容灾性、扩展性、分级存储、高性能，及对比传统块存储和文件存储的收益；从业务收益、IT运维、TCO分析、社会效果、等等

6.1 主流分布式存储对比

HDFS

主要用于大数据的存储场景，是Hadoop大数据架构中的存储组件。HDFS在开始设计的时候，就已经明确的它的应用场景，就是为大数据服务。主要的应用场景有：

◎ 对大文件存储的性能比较高，例如几百兆，几个G的大文件。因为HDFS采用的是以元数据的方式进行文件管理，而元数据的相关目录和块等信息保存在NameNode的内存中，文件数量的增加会占用大量的NameNode内存。如果存在大量的小文件，会占用大量内存空间，引起整个分布式存储性能下降，所以尽量使用HDFS存储大文件比较合适。

◎ 适合低写入，多次读取的业务。就大数据分析业务而言，其处理模式就是一次写入、多次读取，然后进行数据分析工作，HDFS的数据传输吞吐量比较高，但是数据读取延时比较差，不适合频繁的数据写入。

◎ HDFS采用多副本数据保护机制，使用普通的X86服务器就可以保障数据的可靠性，不推荐在虚拟化环境中使用。

Ceph

Ceph是一个开源的存储项目，是目前应用最广泛的开源分布式存储系统，已得到众多厂商的支持，许多超融合系统的分布式存储都是基于Ceph深度定制。而且Ceph已经成为LINUX系统和OpenStack的“标配”，用于支持各自的存储系统。Ceph可以提供对象存储、块设备存储和文件系统存储服务。

Ceph没有采用HDFS的元数据寻址的方案，而且采用CRUSH算法，数据分布均衡，并行度高。而且在支持块存储特性上，数据可以具有强一致性，可以获得传统集中式存储的使用体验。对象存储服务，Ceph支持Swift和S3的API接口。在块存储方面，支持精简配置、快照、克隆。在文件系统存储服务方面，支持Posix接口，支持快照。但是目前Ceph支持文件存储的性能一般，部署稍显复杂，性能也稍弱，一般都将Ceph应用于块和对象存储。

Ceph是去中心化的分布式解决方案，需要提前做好规划设计，对技术团队的要求能力比较高。特别是在Ceph扩容时，由于其数据分布均衡的特性，会导致整个存储系统性能的下降。

GFS

GFS是google分布式文件存储，是为了存储海量搜索数据而设计的专用文件系统。和HDFS 比较类似，而且HDFS系统最早就是根据GFS的概念进行设计实现的。

GFS同样适合大文件读写，不合适小文件存储。适合处理大量的文件读取，需要高带宽，而且数据访问延时不敏感的搜索类业务。同样不适合多用户同时写入。

HDFS和GFS的主要区别是，对GFS中关于数据的写入进行了一些改进，同一时间只允许一个客户端写入或追加数据。而GFS  是支持并发写入的。这样会减少同时写入带来的数据一致性问题，在写入流程上，架构相对比较简单，容易实现。

GPFS

GPFS是 IBM 的共享文件系统，它是一个并行的磁盘文件系统，可以保证在资源组内的所有节点可以并行访问整个文件系统。GPFS 允许客户共享文件，而这些文件可能分布在不同节点的不同硬盘上。GPFS提供了许多标准的 UNIX 文件系统接口，允许应用不需修改或者重新编辑就可以在其上运行。

GPFS和其他分布式存储不同的是，GPFS是由网络共享磁盘（NSD）和物理磁盘组成。网络共享磁盘（NSD）是由物理磁盘映射出来的虚拟设备，与磁盘之间是一一对应的关系。

GPFS文件系统允许在同一个节点内的多个进程使用标准的UNIX文件系统接口并行的访问相同文件进行读写，性能比较高。GPFS支持传统集中式存储的仲裁机制和文件锁，保证数据安全和数据的正确性，这是其他分布式存储系统无法比拟的。GPFS主要用于IBM 小型机和UNIX系统的文件共享和数据容灾等场景。

Swift

Swift主要面向的是对象存储。和Ceph提供的对象存储服务类似。主要用于解决非结构化数据存储问题。它和Ceph的对象存储服务的主要区别是：

◎ 客户端在访问对象存储系统服务时，Swift要求客户端必须访问Swift网关才能获得数据。而Ceph使用一个运行在每个存储节点上的OSD（对象存储设备）获取数据信息，没有一个单独的入口点，比Swift更灵活一些。

◎ 在数据一致性方面，Swift的数据是最终一致，在海量数据的处理效率上要高一些，但是主要面向对数据一致性要求不高，但是对数据处理效率要求比较高的对象存储业务。而Ceph是始终跨集群强一致性。

6.2 传统存储架构的局限性和分布式存储的优点

传统存储架构的局限性主要体现在以下几个方面：

◎ 横向扩展性较差：受限于前端控制器的对外服务能力，纵向扩展磁盘数量无法有效提升存储设备对外提供服务的能力。同时，前端控制器横向扩展能力非常有限，业界最多仅能实现几个控制器的横向。因此，前端控制器成为整个存储性能的瓶颈。

◎ 不同厂家传统存储之间的差异性带来的管理问题：不同厂商设备的管理和使用方式各有不同，由于软硬件紧耦合、管理接口不统一等限制因素无法做到资源的统一管理和弹性调度，也会带来存储利用率较低的现象。因此，不同存储的存在影响了存储使用的便利性和利用率。

◎ 分布式存储往往采用分布式的系统结构，利用多台存储服务器分担存储负荷，利用位置服务器定位存储信息。它不但提高了系统的可靠性、可用性和存取效率，还易于扩展，将通用硬件引入的不稳定因素降到最低。

分布式存储主要优点如下：

◎ 高性能：一个具有高性能的分布式存户通常能够高效地管理读缓存和写缓存，并且支持自动的分级存储。分布式存储通过将热点区域内数据映射到高速存储中，来提高系统响应速度；一旦这些区域不再是热点，那么存储系统会将它们移出高速存储。而写缓存技术则可使配合高速存储来明显改变整体存储的性能，按照一定的策略，先将数据写入高速存储，再在适当的时间进行同步落盘。

◎ 弹性扩展：得益于合理的分布式架构，分布式存储可预估并且弹性扩展计算、存储容量和性能。分布式存储的水平扩展有以下几个特性：节点扩展后，旧数据会自动迁移到新节点，实现负载均衡，避免单点过热的情况出现；水平扩展只需要将新节点和原有集群连接到同一网络，整个过程不会对业务造成影响；当节点被添加到集群，集群系统的整体容量和性能也随之线性扩展，此后新节点的资源就会被管理平台接管，被用于分配或者回收。

◎ 支持分级存储：由于通过网络进行松耦合链接，分布式存储允许高速存储和低速存储分开部署，或者任意比例混布。在不可预测的业务环境或者敏捷应用情况下，分层存储的优势可以发挥到最佳。解决了目前缓存分层存储最大的问题是当性能池读不命中后，从冷池提取数据的粒度太大，导致延迟高，从而给造成整体的性能的抖动的问题。

◎ 多副本的一致性：与传统的存储架构使用RAID模式来保证数据的可靠性不同，分布式存储采用了多副本备份机制。在存储数据之前，分布式存储对数据进行了分片，分片后的数据按照一定的规则保存在集群节点上。为了保证多个数据副本之间的一致性，分布式存储通常采用的是一个副本写入，多个副本读取的强一致性技术，使用镜像、条带、分布式校验等方式满足租户对于可靠性不同的需求。在读取数据失败的时候，系统可以通过从其他副本读取数据，重新写入该副本进行恢复，从而保证副本的总数固定；当数据长时间处于不一致状态时，系统会自动数据重建恢复，同时租户可设定数据恢复的带宽规则，最小化对业务的影响。

◎ 容灾与备份：在分布式存储的容灾中，一个重要的手段就是多时间点快照技术，使得用户生产系统能够实现一定时间间隔下的各版本数据的保存。特别值得一提的是，多时间点快照技术支持同时提取多个时间点样本同时恢复，这对于很多逻辑错误的灾难定位十分有用，如果用户有多台服务器或虚拟机可以用作系统恢复，通过比照和分析，可以快速找到哪个时间点才是需要回复的时间点，降低了故障定位的难度，缩短了定位时间。这个功能还非常有利于进行故障重现，从而进行分析和研究，避免灾难在未来再次发生。多副本技术，数据条带化放置，多时间点快照和周期增量复制等技术为分布式存储的高可靠性提供了保障。

◎ 存储系统标准化：随着分布式存储的发展，存储行业的标准化进程也不断推进，分布式存储优先采用行业标准接口进行存储接入。在平台层面，通过将异构存储资源进行抽象化，将传统的存储设备级的操作封装成面向存储资源的操作，从而简化异构存储基础架构的操作，以实现存储资源的集中管理，并能够自动执行创建、变更、回收等整个存储生命周期流程。基于异构存储整合的功能，用户可以实现跨不同品牌、介质地实现容灾，如用中低端阵列为高端阵列容灾，用不同磁盘阵列为闪存阵列容灾等等，从侧面降低了存储采购和管理成本。



7 容器云的NBU数据备份

Veritas有推出可作为容器部署的NetBackup Client。NetBackup Client Container利用NetBackup策略来运行备份。根据所需的保护级别，NetBackup Client Container 可通过以下方式保护容器化应用程序：

◎ 保护存储在永久卷上的应用程序数据

◎ 使用暂存区域保护应用程序数据

◎ 将应用程序部署在同一应用程序容器中，以执行应用程序一致性备份

图片
7.1 获取NetBackup Client image

Veritas NetBackup为Docker认证的容器备份解决方案：

https://www.veritas.com/protection/netbackup/resources

https://hub.docker.com/_/veritas-netbackup-client?tab=description

图片
7.2 部署方式一（Sidecar部署方式）

NetBackup Client Container可与应用程序共存并从应用程序运行所在的节点操作。为此，为每个应用程序Pod部署一款NetBackup Client Container作为Sidecar。

在此方法中：

◎ NetBackup Client Container作为应用程序Pod的一部分一起运行。这可确保应用程序和NetBackupClient Container的生命周期相同。

◎ 需要保护的PV卷必须同时可以被应用程序和NetBackup Client Container访问。

该解决方案可：

◎ 简化备份管理员的管理操作

◎ 优化网络备份性能

◎ 有效利用NetBackup核心技术，例如Accelerator、Client Direct Backup等

◎ 通过添加备份策略（policy）来分类不同应用程序数据

◎ 一致的标准客户端数据恢复操作。

下图为Sidecar 的部署模式：

图片
7.3 部署方式二（单一POD部署方式）

NetBackup Client Container 从可访问各卷的单个点保护永久存储。由此，仅需部署一个 NetBackup Client Container 即可保护多个应用程序 Pod。

在以下情形中，可部署单一NetBackup Client Container保护多个应用程序Pod：

◎ 应用程序所有者不希望将NetBackup Client Container容器纳入到自己的Pod中

◎ 群集可用的外部 IP 接口的数量有限

◎ 为了尽可能减少NetBackup在群集中的占用空间

可在Kubernetes群集的每个节点部署一款NetBackup Client Container，或每个群集部署一款NetBackup Client Container，具体取决于：

◎ PV的访问模式：“ReadWriteOnce”卷仅在一个节点上可用，而“ReadWriteMany”卷在群集的多个节点上可用

◎ 所需的客户端吞吐量。

在此方法中，在NetBackup Client Container中装入所有需要保护的卷（PV）。Pod启动后无法装入卷。管理员必须提前了解需要保护的卷，且必须在创建Pod之前在NetBackup Client Container模板中定义这些卷。所有受保护的应用程序被记录为相同的NetBackup客户端名称。因此，应该为每一个不同的应用程序创建一项NetBackup策略(Backup Policy)，并为该类应用程序指定特定的关键字，数据恢复时将可按该关键字进行快速查找。

图片
7.4 部署方式三（Dump & Sweep部署方式）

此外，还可通过装入转储卷在第二种部署模式中使用“Dump & Sweep”方式。

在“Dump & Sweep”方式中，需要保护的应用程序Pod不仅装入数据卷，还装入转储卷。应用程序所有者将应用程序数据转储到转储卷。NetBackup使用NetBackup标准策略定期清除转储卷。

所有受保护的应用程序均记录相同的NetBackup客户端名称。因此，为每个应用程序创建一项  NetBackup 策略，并为该应用程序指定特定的关键字。

下图说明了为多个Pod 部署一款NetBackup Container时使用的“Dump & Sweep”方法。

图片



8 容器云存储整体架构面临的挑战与经验

性能

在容器的使用场景，通常会有非常多的Pod或者在Pod上会挂载较多的卷，需要消耗一定的资源，特别如今云原生时代，非常适合要求轻量，快速的容器云平台，一分钟内就能启动上百个pod，对存储IO性能，并发创建能力也有很高要求。

跨数据中心双活等问题

稳定性、数据一致性、网络故障等等问题带来的运维复杂度。