️This article has been over 1 years since the last update.

本文是对常见存储方案的简要汇总介绍。

在PaaS设计中，存储是对密度要求最大的部分。在应用服务中，有K8s/nomad等框架可以很容易处理计算调度编排问题，有抽象网络处理流控与ACL问题。而存储却门槛却极高，开源软件很难开箱即用，而且一般是要求高密度，高承诺，紧耦合的，它需要网络数通、路由与压缩算法、前端ASIC、专用OS(FS)、RIAD ASIC、SSD平衡算法等复合知识，也是加班最很的。

本文介绍内容在app之下，infra之上，方便软件类SE更好设计app系统。

Infra层

下文是大致范围

存储设计通常是放在基础设施上实现的，需要专门的Infra工程师，而应用工程师一般接触不到。

真正的设计存储方案至少包含如下

• 机房机柜：能源、散热、消防、安全、密度等
• 交换框：汇聚、接入、控制、管理；GE线
• 控制框：SDS、存储网关与专用硬件，SDN
• 机器：RAID、盘位、BMC、Health
• 协议：Shard、主从选举、Heard-beat等

如果想更深入了解，可以优先看下Top厂商的产品介绍/Support资料，大致就能明白了

比如这里是来自Huawei的40GE的物理方案

这个领域非常复杂而且需要经验，尤其是主备切换的单点故障细节真的多，往往定位需要一天。比如有次实施人员将数据盘和系统盘挂到一起，等存储负载上来后发现vi都卡，最终用lsblk才发现硬盘速度都影响OS了，导致告警组件超时而频繁切选举。

存算分离

所谓的超融合方案

VM/云方案

VM可以利用远端存储实现直接RDMA对接VM软件，VM再分配给具体的OS，一般采用Cinder+SDN的方案

可以参考这篇文章

裸金属物理部署方案

OS需要安装在本地，计算数据通过GE/IB线进行直连，实现存算分离，这个的确是紧耦合方案。

CSI

在应用侧，可以直接挂载磁盘或者使用Container Storage Interface (CSI) 来进行wrapper

对硬件/云的wrapper

比如FusionStorage/CCE提供了K8S的CSI服务，这个没啥毛病

1

FusionStorage/CCE -> CSI -> Kubenetes

用户态分布式存储

这种用户态wrapper的设计其实对应用开发者来说挺鸡肋的，需要跳过FS抽象，并掌握三种技术栈（硬件、CSI、SDS），比如IOMesh要求在每台机器上都要安装磁盘、应用并依赖k8s。

• 没有运维能力的开发者，还不如用虚拟化的云硬盘/NFS，或者直接集成S3的SDK
• 有运维能力的开发者，必定不敢接这种锅，因为硬盘不归你管，权责不清晰；分散硬件过于繁琐。
• 有非常强运维能力的开发者，用高速网线连接集中式硬件存储多香

应用层与Local存储

业务应用层一般不会实现过于复杂，而是简单的本地切片，比如

• Gitlab代码仓库有两层分片：
  • 第一层通过Map结构[key: mountPoint]作为物理挂载点的切片（并存储key到projects表），这种方案不涉及算法，需要人工经验进行分配。
  • 第二次切片通过sha256(projectId)进行分发。
• SVN代码仓库同上，需要在Apache的httpd.conf进行人工经验配置，基于文本存储切片数据
• 高级供应商MultiSite为Git/SVN的文件系统进行了二次定制，基于PAXO实现了跨广域网的共识