用专利方法，给XGFS分布式文件的数据拍个照
随着数据的重要性愈加凸显，越来越多的企业开始关注存储产品以及备份方案。在应用这些存储产品时会遇到以下的问题：
1. 备份速度的问题：随着业务的不断发展，数据越来越多，更新越来越快，在休息时间来不及备份如此多的内容，在工作时间备份又会影响系统性能。
2. 操作简单化的问题：数据备份应用于不同领域，进行数据备份的操作人员也处于不同的层次。操作的简单与否直接影响操作的效果和数据的安全。
3. 保护数据一致性的问题：有些关键性的任务是要 24 小时不停机运行的，在备份的时候，有一些文件可能仍然处于打开的状态。
4. 容错的问题：数据备份损坏了，怎样在最短的时间恢复它。尤其是在实际操作中，遇到病毒感染、人为误操作、恶意篡改、系统宕机造成的数据损坏、应用程序BUG造成的数据损坏、存储系统BUG造成的数据损坏等情况，如何在这些场景下快速恢复数据，对业务数据提供连续性保护呢？
为提高数据存储的安全性和高效率，保护企业的数据，数据快照技术是其中比较成熟的技术之一。
XGFS 分布式文件快照功能
XGFS在5.1版本中已支持目录快照快照功能，可以实现对文件系统中任意目录配置快照保护，快照瞬时完成。支持对目录同时设置手动快照和定时快照策略。同时支持手动删除快照，或者设置快照的过期删除时间，快照过期后可自动删除快照。
XSKY快照专利技术
存储快照在实现上有多种方式，其中最常用的两种技术是，写时拷贝(Copy On Write，COW)和写时重定向(Redirect On Write，ROW) 。
为什么元数据使用COW技术
XGFS对文件的元数据使用COW 写时拷贝技术。COW在创建快照时，并不会发生物理的数据拷贝动作，仅是拷贝了原始数据所在的源数据块的物理位置元数据。在创建快照之后，这个快照就相当于一个可供上层应用访问的存储逻辑副本，快照卷与源数据卷通过各自的指针表共享同一份物理数据。
当源数据卷中任意数据将要被改写时，COW 需要确保对原始数据的拷贝操作发生在原始数据的改写操作之前，当元数据修改后，会copy一份信息后再修改，旧元数据信息链接到快照映射到快照空间，而新的元数据写入head空间。采用这样的方式保证了可以高效访问元数据的最新状态，使快照时间点后更新的数据不会出现在快照卷中，快照卷中的数据都必须是快照时间点那一刻的数据，以此保证了快照数据的完整性。
COW的优势是读更快，因为修改数据时，老的数据都是copy出来的，这样下次读不用去找老的数据。因为元数据非常小，且元数据读访问更多，所以采用COW更合适。
为什么文件数据使用ROW技术
如果使用COW对文件的数据做快照，会存在三个问题：
1. 每一次写IO涉及到三次IO操作（一次读原来的对象数据，一次写入新的对象，一次写入新的IO），严重导致卷性能下降，根据实际测试情况，甚至可能下降一半以上；
2. 每次写入新的IO，需要拷贝一个4M数据的对象，存在只更新很小的数据情况下也需要占用4M的空间，导致快照占用的存储空间较大，大大浪费了存储空间。
3. 还有写放大问题。例如4M数据只改了4K，那么也会写入4M。
当然COW和ROW这个适用的场景不太一样，如果是读多得场景，其实用COW更合适。
XGFS目录快照对文件的数据使用了专利的ROW 快照技术。创建快照时，ROW也会copy一份源数据指针表作为快照数据指针表，此时两张表的指针记录都相同的。在创建快照之后，也就是在快照时间点之后，发生了写操作，那么新数据会直接被写入到快照卷中，然后再更新源数据指针表的记录，使其指向新数据所在的快照卷地址。
可以看出，ROW与COW最大的不同就是：COW的快照卷存放的是原始数据，而ROW的快照卷存放的是新数据。因为ROW这种设定，所以其多个快照之间的关系必定是链式的，因为最新一次快照的原始数据很可能就存放在了上一次快照时创建的快照卷中。
ROW在传统存储场景下最大的问题是对读性能影响比较大。ROW的写性能基本没有损耗，只是修改指针，实现效率很高。但多次读写操作后，某时刻的源数据卷的数据会变得非常离散(源数据指针表记录都被更新了)，这时ROW的连续读写性能就不如COW了。
专利展示
XSKY快照的专利技术对传统的ROW技术做了优化，使读性能大幅提高。
XGFS快照在Kubernetes场景的应用
Kubernetes有状态应用使用PersistentVolumes存储应用数据。PersistentVolume与使用它的Pod有独立的生命周期，因此即使Pod消失了，数据也需要保存在底层存储系统上。但是，如果存储系统上的底层卷由于某种原因损坏了，存储在PersistentVolumes上的数据也会消失。为了防止数据丢失，Kubernetes官方设计了Snapshot来为有状态应用提供数据保护。
CSI快照原理
Kubernetes 中通过 PVC 以及 PV的设计体系来简化用户对存储的使用，而存储快照的设计其实是仿照 PVC& PV体系的设计思想。我们需要先了解几个概念：• VolumeSnapshot
与PVC类似，当用户想创建或删除一个卷快照时，可以选择创建或删除一个VolumeSnapshot。
• VolumeSnapshotContent
与PV类似，VolumeSnapshotContent代表集群中被分配的一个快照资源。
• VolumeSnapshotClass
VolumeSnapshotClass同StorageClass类似，指定了卷快照的一些参数，如驱动的信息，DeletionPolicy，访问快照的Secret等。
快照功能是由 CSI drivers 提供给 Kubernetes 集群, 一般情况下 CSI drivers 需要自动安装这些 API 资源，可以看到这些 API 资源是 CRD，而并不在 Core API 中。
Sidecar-snapshotter会监听volumesnapshots CRD，当一个VolumeSnapshot实例（custom resource）被创建时，sidecar-snapshotter会调用CSI Driver创建一个存储快照，并且同时Sidecar-snapshotter也会在Kubernetes集群生成一个VolumeSnapshotContent实例与存储快照对应。VolumeSnapshotContent建立了同底层存储的快照的映射关系，VolumeSnapshotContent 中的 SnapshotHandle 是一个指向存储快照的UID。
Snapshot Controller监听VolumeSnapshot和VolumeSnapshotContent资源，负责建立 VolumeSnapshot和VolumeSnapshotContent之间的一对一关系。
XGFS快照实践
首先在Kubernetes集群中，安装好CSI Driver、Sidecar-snapshotter、Snapshot-controller 组件。
为Demo应用创建好PVC和PV，并且绑定完成：
创建一个VolumeSnapshotClass对象，命名为csi-nfs-snap,并指定csi driver为csi-xsky-nfs-driver：
开始创建快照，我们先创建一个VolumeSnapshot yaml文件，命名为csi-nfs-pvc-snapshot，并指定volumeSnapshotClass为csi-nfs-snapshotclass，并且指定需要创建快照的PVC是csi-nfs-pvc：
创建Snapshot：
查看Volumesnapshot 资源已经创建成功：
检查Volumesnapshotcontent 对象也已经自动创建并且映射给了csi-nfs-pvc-snapshot：
可以在存储界面上看到创建好的snapshot：
快照正是存储技术中的"后悔药"，通过快照功能，可以在存储设备发生应用故障或者文件损坏时进行快速的数据恢复。当然，快照不仅仅具备了"后悔药"的功能，还能给人不少小惊喜，比如为存储用户提供另外一个数据访问通道，当原数据进行在线应用处理时，用户可以访问快照数据，还可以利用快照进行测试等工作。
而XSKY星辰天合下一代分布式文件系统XGFS，便具有这种“后悔药”，XGFS支持对文件系统中任意目录配置快照保护，快照瞬时完成。通过快照技术，系统管理员能够实现数据的零窗口备份，从而满足企业对业务连续性和数据可靠性的要求。通过瞬时快照技术，可获取并保护业务数据的实时可用状态；按照业务数据的重要性需求，可对目录设置灵活的定时快照保护策略。
XGFS在短短的半年时间，就累计部署超过了150PB，成为XSKY星辰天合增长最快的产品线，并在大规模数据分析、高性能计算存储后端广泛应用。
END
# 往期推荐 #