共计 2308 个字符，预计需要花费 6 分钟才能阅读完成。
业务背景
创云融达是一家以海量数据的存管用为外围，以企业级公有云建设能力为根底，并提供数据资产和数据中台产品和解决方案的高新技术企业。
近年来，为了优化人们征税缴费的服务体验，各省市税务系统逐渐构建了面向税务办事大厅的各种创新型智慧设施和智慧利用，如办税一体机，智慧税务大屏，语音辅助设施、以及业务流程辅助 AI 机器人等。极大便当人们税业务体验的同时也对 IT 集成和 IT 基础设施提出了更高的要求。
创云融达承建了多地的智慧税务大厅解决方案，在实践中，咱们发现智慧事务大厅的业务有如下特点：
1. 各类智慧税务利用零碎数量较多；
2. 办事大厅的业务场景对服务的实时性和可用性也有较高要求；
3. 利用不仅仅须要数据库等结构化数据，也须要肯定规模的非结构化数据的存储需要；
依据以上特点，咱们总结出了智慧税务基础设施的需要：稳固、牢靠，适应于超交融集群环境（规模 3 - 6 节点）的分布式存储解决方案，提供云主机和对象存储，保证数据安全性、和稳固牢靠运行。
计划选型
对于对象存储，创云融达有自研的 OEOS, 有冷热数据主动分层和智能编排机制，实现了海量数据的长久化存储，同时也满足了海量小文件的高 IO 性能要求。能够为各类智慧利用提供非结构化数据的存管用治理平台。
对于块存储，十分出名的有 Ceph，然而开源版本的 Ceph 在应用过程中是有很多稳定性的问题，惯例的一些异样都会引起 IO 抖动, 和 Curve 替换 Ceph 在网易云音乐的实际 中提到的问题也相似。这些问题和 Ceph 的一致性协定、数据搁置算法都相干，基于开源版本去改变复杂度和工作量都很大。同时，咱们留神到了开源的 Curve。
通过和 Curve 社区屡次深刻的技术交换，理解到 Curve 分布式存储通过对数据块的数据摆放机制的优化，胜利解决了 Ceph 类存储中 CRUSH 算法在生产环境中的微小不确定性，从而具备生产环境所须要的稳定性和高可靠性。因而，基于 Curve 构建分布式块存储，作为虚拟化环境的数据底座，具备比 Ceph 产品具备更高的可靠性和数据安全性。
特地须要提到的是 Curve 块存储在快照上的设计。Curve 块存储的快照反对上传到 S3，不限度快照数量并且升高了快照的存储老本。这一设计和咱们自研的对象存储 OEOS 能够完满联合。
计划落地
咱们对 Curve 块存储进行了深刻的测试，以后曾经在我的项目中胜利构建了基于 Curve 的分布式块存储和创云 OEOS 对象存储联合的分布式存储解决方案，为智慧税务我的项目中提供了对立存储基础设施。为智慧税务提供了无力的技术撑持，并在多地市的新建智慧税务大厅我的项目中失去了胜利利用。
整体的架构如下：
- 反对块存储和对象存储，反对 ISCSI、S3、NFS、SMB 协定
- 对象存储反对冷热分层，反对 EC
- 块存储提供高性能，快照数据反对转储到对象存储中
- 所有服务高可用，任一节点故障不影响用户 IO
在我的项目落地的过程中，联合 Curve 的特点和业务场景，总结了一些虚拟化场景下的应用教训。
1. 业务短暂的 IO 波峰
在 KVM 虚拟化场景下，当用 KVM 镜像生成虚拟机实例的时候，会有短暂的 IO 波峰（5000-6000 IOPS），之后则隐没。而业务场景少数状况下对 IO 的要求不高。因而，咱们设计了两个逻辑池，一个 SSD 盘逻辑池，和一个机械盘逻辑池。KVM 虚拟机则制作成 40G 的系统盘。这样，所有的 KVM 系统盘都调配在 SSD 逻辑池中，而数据盘调配在机械盘逻辑池中，从而解决了 KVM 镜像问题。
2. nebd 服务的单点和性能问题
Curve 社区提供的 curve-tgt 版本是基于 nebd 的，nebd 是为理解耦下层利用和 curve-sdk 所加的热降级模块。但在实践中，这个服务有可能存在单点问题，且对 IO 时延也有 15% 左右的耗费。
因而，咱们在社区版 curve-tgt 根底上做了一点改良，让 curve-tgt 的 backend 间接调用 Curve 客户端（libcurve.so），测试证实也很稳固，并且也进步了性能。
此外，curve-tgt 还有一个多节点负载平衡的问题。咱们的解决思路是，在每个节点上开两个 curve-tgt 过程（3260 和 3261 端口），传统的 3260 端口仅用于 iscsi discovery，当收到 iscsi login 命令的时候，利用 iscsi 的 login redirect 机制，调用 loadbalancer，取第二个过程（3261 端口）做重定向。Loadbalancer 过程随机选取所有 active 节点的一个，重定向到该节点的 3261 端口上，实现 login。最初一点，再通过 keepalived 为 3260 端口提供一个虚 IP 机制，则保障了 discovery 过程不会因为单节点掉电而生效。
3. 集群整体掉电
和社区探讨后，咱们解决思路是：在剖析出 UPS 市电故障时，第一步把前端 curve-tgt 过程进行掉，第二步集群所有的卷做一次快照，第三步做一次 fsync，保障所有内存中的数据都刷到盘上，最初进行集群。
后续布局
以后咱们曾经基于 Curve 和 OEOS 对象存储交付了多个超交融集群，接下来还想摸索 Curve 更多的应用姿态、新硬件的反对等。近期的布局如下，欢送感兴趣的小伙伴一起探讨：
1. 在 SSD+HDD 混合部署方面，探讨是否有更多的性能晋升空间；
2. 应用 Curve RDMA 版本；
3. 多正本静默谬误查看机制的检测和预防探讨；
4. 集群整体掉电状况可靠性和安全性的剖析；
作者简介： 王彦灵（wangyanling@oct-ea.com），创云融达存储解决方案专家，曾在 XSky 等公司从事存储运维开发工作。2021 年开始关注 Curve 社区，应用、部署、运维 Curve 集群，也在代码上做一些原型试验，对社区有浓厚兴趣。