Ceph对象存储的实战兵法（上）

作者:匿名更新于： 2021-10-17 21:50:46

　　客户端分布在内部网络上，意味着应该尽量减少endpoint入口和客户端之间的路由跳跃，以确保其带宽。

　　接下来的文章里，小编想给大家介绍一下基于Ceph对象存储的实战兵法，一起来看看吧!知己知彼，百战不殆

　　分析商业IO模型。

　　了解业务基本存储模型:

　　·最高并发量，最高读写带宽要求。

　　在知道单个RGW最大并发数上限的前提下，你需要使用多少RGW实例来支持这些并发。

　　读写带宽的最高值决定了您需要使用多少OSD来支持如此大的读写带宽，同时也要考虑endpoint入口处的带宽是否符合这一要求。

　　·客户分布在内外或外部网络。

　　客户主要分布在外部网络上，这意味着在公共网络这样复杂的网络环境中，数据读写会受到一些不可控制的因素的影响，所以现在做对象存储的公共云不敢告诉你自己的带宽、延迟和并发数。

　　客户端分布在内部网络上，意味着应该尽量减少endpoint入口和客户端之间的路由跳跃，以确保其带宽。

　　·读写率，平均大小。

　　若读取量较高，如CDN场景，可考虑在endpoint入口添加读取缓存组件。

　　若写入率较高，如数据备份，则应考虑控制好入口带宽，避免出现高峰期多项业务抢占写入带宽，影响整体服务质量。

　　request的平均尺寸决定了整个对象存储服务是针对大文件还是小文件进行性能优化。

　　老司机经验:很多时候，我们不知道业务的具体IO模型构成。这时候可以考虑小规模访问业务，将前端endpoint的访问日志(比如前端使用nginx)连接到ELK等日志分析系统，借助ELK可以轻松分析业务IO模型。　　

　　兵马未动，粮草先行

　　所有业务理念最终都需要建立在基础硬件平台上。前期业务规模小，可能不太注重硬件选择。但是，随着业务的不断增长，选择可靠、稳定、性价比高的硬件平台就显得尤为重要。

　　·小规模硬件资源体验。

　　小型化一般指集群机器数量在20台以内或osd数量在200台以内的场景，在此阶段，MON节点可考虑使用虚拟机，但必须满足两个条件：

　　*MON数量超过3个，最多5个，浪费金钱，CPU和内存控制在2核4G以上。

　　*MON必须分布在不同的物理机器上，NTP同步良好。

　　至于OSD节点，满足以下条件:

　　*OSD打死也不要上虚拟机，日常换盘和故障排错麻烦，而且由于虚机IO栈多了一层，数据安全性差很多。

　　*需要考虑网络的带宽限制。如果是1000兆，只能做bond，尽量满足每个OSD有40~60M/s的网络带宽。从经验来看，如果网络能做几万兆，就不要做1000兆bond了。后续网络升级需要停止OSD也是一个很大的坑。

　　*每一个OSD再抠也要做到至少1核2G的物理资源，否则当出现问题座数据恢复时，内存将无法hold。

　　*如果你不在乎性能，没有SSD做journal，那就算了。

　　*indexpool最好使用SSD，木有那也没办法。

　　RGW节点非常容易:

　　*RGW可以考虑使用虚拟机器，甚至docker，因为我们可以通过多次开放来提高整个服务的高可用性和并发性。

　　*每个RGW的资源至少为2核4G，因为每个request请求在写入rados之前缓存在内存中。

　　*RGW服务节点大约有2个，前端可以连接nginx作为反向代理来改进并发。

　　*在不调整的情况下，civetweb并发比fastcgi差得多。　　

　　·中等规模的硬件资源体验。

　　中等规模一般是指集群机器数量在20~40台以内或osd数量在400台以内的场景。在这个阶段，业务基本已经初具规模。MON节点不适合虚拟机方案，需要注意以下几点:

　　*MON数量超过3个，最多5个，CPU和内存控制在4核8G以上。如果条件允许，将MON的metadata存储在SSD上。因为当集群达到一定规模时，Mon上的LevelDB会有性能瓶颈，尤其是数据压缩时。

　　*MON必须分布在不同的物理机器上。如果条件允许，可以部署多个机柜，但注意不要跨越多个IP网段。如果网段之间的网络波动，很容易触发Mon频繁选举。当然，选举中有参数可以调整。

　　符合下列条件的OSD节点：

　　*OSD要考虑做好crushmap的故障域隔离，可以使用3个副本，绝对不要去省钱做2个副本，后期磁盘批量到达使用寿命后，这是很大的隐患。

　　*每个OSD物理节点的OSD磁盘数量不宜过多，单盘容量不宜过大。你可以做一个8T的SATA磁盘。如果单盘用量超过80%，那么整个数据回填时间绝对是漫长的等待。当然可以控制backfill的并发数，但是对业务有影响，要权衡。

　　*每个OSD最好由SSDjournal护送。没有必要在这个规模下节省SSD。

　　*indexpool必须使用SSD，这将是性能的质的飞跃。

　　RGW节点非常容易:

　　*RGW仍可考虑使用虚拟机器，甚至docker。

　　*前端入口应连接负载平衡方案，如LVS或nginx反代理。高可用性和负载平衡是必要的选择。

　　*根据SSD数量和故障域设计，控制rgw_override_bucket_index_max_shards的数量，调整bucket的index性能。

　　*RGW服务可以考虑在每个OSD上部署一个，但必须确保相应节点有足够的CPU和内存。

　　·大中型硬件资源经验。

　　大中型规模一般是指集群机器数量在50台以内或osd数量在500台以内的场景。在这个阶段，业务基本达到了一定的规模。MON节点不应使用虚拟机器，还应注意一些事项:

　　*MON数超过3个，最多5个，上SSD。

　　*MON必须分布在不同的物理机上，必须跨多个机柜部署，但注意不要跨IP网段，最好是万兆互联。

　　*每个MON保证8核16G内存基本足够。

　　符合下列条件的OSD节点：

　　*OSD必须事先设计好crushmap的故障域隔离，推荐3份，至于EC方案，要看你是否有能力解决服务器批量断电下的EC数据恢复问题。

　　*OSD硬盘必须统一配置，不要混合4T和8T，这样weight控制会很麻烦，每个osd的pg分布一定要优化，避免性能压力和容量分布不均匀。pg分布优化后会有内容介绍。

　　*SSDjournal和SSDindexpool是必须的。

　　RGW节点非常容易:

　　*RGW还是老实实用的物理机，到了这个规模，今天省的钱哪天都要哭着交学费。

　　*前端负载平衡方案可以进行一层优化，如提高前端带宽和并发能力，增加读取缓存，甚至增加dpdk。

　　*civetweb代替fastcgi，可以大大提高部署效率，如果结合docker，可以实现快速并发能力的弹性伸缩。

　　*RGW可以集中部署在单独的物理节点上，也可以考虑使用OSD混合方案。

　　上面就是基于Ceph对象存储的实战兵法的介绍了，希望可以帮到你的学习，后面小编会继续分享相关的知识点，敬请关注!

  　　>>>>>>点击进入云计算专题