基于Librados的流量治理方案

1 需求背景&现状

需要自己实现一套类似RGW的对象存储服务，解耦元数据存储到独立的数据库服务(如TiDB)，同时提供跨Ceph集群的数据读写能力，实现横向扩展和跨集群级别的容灾。

TCP长连接数

每个LibRados客户端会话都会与对应的ceph集群多个服务角色建立TCP连接，而且目前这个TCP是长连接，无法进行Keep-alive一类的设置。
以写入一个对象数据到Ceph集群为例，client会先和mgr和mon建立通信，获取对应的osd/pg map相关记录，之后根据拿到的最新map记录，使用crush算法计算出最终需要进行数据I/O交互的主OSD，最后再与对应的主OSD进行通信。这里有个关键点就是OSD一旦与客户端建立通信连接以后，这个TCP连接会一直保持，因此随着集群内其他OSD与客户端不断进行数据交互，这样的客户端到OSD的TCP长连接会越来越多。同理，随着客户端的数量越来越多，每个OSD上面维护的TCP连接也会越来越多，因此需要对整个系统中的客户端到OSD的TCP连接数进行控制，以减少OSD的开销。

数据请求的跨集群路由

整个系统的数据写入会分布在不同的Ceph集群，因此需要在入口侧进行数据流量的按集群拆分。但是如果每个入口Router节点如果都作为客户端使用Librados连接到具体的集群，一方面会加重Router的设计复杂度，另外也会在后续的部署过程中，需要将Router就近接入到对应的集群才能减少网络波动带来的可靠性影响。

2 解决思路

gRPC代理模型

将全部的librados的请求封装成gRPC服务，按集群维度来构建多个gRPC连接池，每个连接池维持与Ceph集群的长连接，同时提供Proxy来实现负载均衡和服务的冗余。客户端请求一般以短连接方式与Proxy进行通信(也可以设置keealive来实现长连接)，客户端通信完成以后就释放对应的TCP连接。

效果图

欢迎订阅本公众号cephbook，干货满满，专业老司机教你搞"对象"存储!