写点什么

Redis on AEP 实践

用户头像
BUG侦探
关注
发布于: 3 小时前
Redis on AEP 实践

背景

由于公司 Redis 实例规模比较大 45000+,使用服务器数量多 2000+,而且使用内存存储成本相比磁盘要高很多,基于 Redis 集群进行现状分析,针对以下集群决定使用傲腾 AEP 存储进行成本优化。

  1. 请求量低的小集群非常多,部署比较分散,服务器资源成本高。

  2. 大容量集群每次申请 200G 到 2T 容量不等,使用服务器数量多。

傲腾 AEP 上线需要做什么


傲腾 AEP 性能如何

首先性能测试,整体来讲跟纯内存相比有 10%左右的损耗,测试数据如下。目前我们在该机型仅支持小集群、大容量的业务,目前不存在性能问题。



说明:上图为当 Redis 单进程 cpu 负载 80%左右的情况下,在内存和傲腾不同存储上分别运行在不同版本 3.2.11、4.0.12、5.0.8、6.0.5,当 set 命令 value 为 10、100、1000 字节每秒处理请求个数压测结果对比。



说明:上图为当 Redis 单进程 cpu 负载 80%左右的情况下,在内存和傲腾不同存储上分别运行在不同版本 3.2.11、4.0.12、5.0.8、6.0.5,当 get 命令 value 为 10、100、1000 字节每秒处理请求个数压测结果对比。



说明:上图为当 Redis 单进程 cpu 负载 80%左右的情况下,在内存和傲腾不同存储上分别运行在不同版本 3.2.11、4.0.12、5.0.8、6.0.5,当 set 命令 value 为 10、100、1000 字节响应时间分别为 1、2、3、4 毫秒的百分比压测结果对比。



说明:上图为当 Redis 单进程 cpu 负载 80%左右的情况下,在内存和傲腾不同存储上分别运行在不同版本 3.2.11、4.0.12、5.0.8、6.0.5,当 get 命令 value 为 10、100、1000 字节响应时间分别为 1、2、3、4 毫秒的百分比压测结果对比。

密集部署调度是否能打散


  1. redis 集群 1 个节点下主从不在同一个机柜组。

  2. redis 内存利用率大于 50%不再调度新实例

  3. 一个机柜组承载每个集群不超过 25%的实例数。

  4. 扩容 k8s 集群中 node 后新增实例的打散依然符合以上规则。

密集部署宕机业务影响范围


  1. 业务恢复时间从实例不可用到域名切换完成耗时 20~40s 之间。

  2. 拓扑恢复时间完全自动化,DBA 关注进度就好,宕机服务器 500+G 内存恢复需要 30min 左右。

管理方式变更

1).Redis 资源申请

1)目前可以做到 Redis 资源分钟级别交付。

2).增加异常诊断

1)基于 Redis、操作系统,中间件层快速聚合分析到历史时间段的异常指标。生成集群诊断报告。

2)通过获取 Redis 实时 monitor 日志,分析出热点数据,输出热点报表信息。

3).异常处理预案

1)增加了 sentinel 服务异常后宕机批量切换工具。

2)增加了主从同时宕机批量从异地备份机恢复数据的工具。

4).增加集群画像

1)集群列表页关联业务组,划分权限,只显示各自归属集群,方便业务方查看。

2)业务方更详细了解集群基础信息(架构、分片、机房等)和性能信息(访问量、容量等指标的实时统计和天级统计)。

3)基础数据完整和准确,有效实施后续自动化功能建设。

4)实时统计、天级统计信息可定时产出报表,分析低访问量、慢查询多等集群。

5)集群信息完整,出问题时可以快速定位业务方、访问源服务、关联申请原工单、操作类型统计等维度方便排查。

阶段工作成本对比

总结

1)非核心业务可以先上 AEP,如果性能不够再迁移到纯内存服务器上。

2)目前存量小实例继续进行迁移。

密集部署遇到的问题

1).整点 cpu 高,慢日志数量增多,业务出现规律性超时。

原因:

1.每个 docker 容器整点执行收集 Redis 客户端连接,遇到客户端连接多的情况尤为严重。

2.每个 docker 容器整点执行收集 Redis 元信息的任务。

3.每个 docker 容器整点执行 anacron 任务。

解决方案:

1.降低定时任务收集客户端连接的频率。

2.随机打散定时任务的执行时间。

3.去掉不必要的定时任务。

2).sentinel 高可用服务自动切换部分失败。

原因:

1.sentinel 服务线程数不够,丢弃部分待处理任务。

2.sentinel 元信息更新失败问题。

解决方案:

1.优化 sentinel 服务线程数。

2.优化更新 sentinel 元信息的版本控制。

3).sentinel 高可用服务异常切换慢。

原因:

1.异常检测周期长。

2.域名切换耗时高。

解决方案:

1.异常检测周期由原来 30s 降低到 10s。

2.优化域名切换接口索引缺失问题由原来平均 30s 降低到 3s。

4).Redis 负载高,操作系统卡顿。

原因:

1.docker 容器管理 Redis 进程,sentinel-agent 组件沿用物理机部署版本,线程数过高导致操作系统卡。

2.每个 docker 容器部署了 repl-agent 组件。

3.每个 docker 容器的 cadvisor 监控项过多。

解决方案:

1.优化 sentinel-agent 组件降低线程数。

2.下线 repl-agent 弃用组件。

3.优化 cadvisor 监控项数量。

5)./var 目录容量满出现 Redis 所在容器被驱逐。

解决方案:

1.将 coredump 日志记录到较大分区。

2.优化各个分区容量的使用的报警等级。

6).Redis 宿主机重启后二次调度,导致数据异常。

解决方案:

1.任务原因导致的宿主机宕机,自动进行调度隔离。







发布于: 3 小时前阅读数: 4
用户头像

BUG侦探

关注

还未添加个人签名 2021.06.08 加入

专注于发掘程序员/工程师的有趣灵魂,对工作中的思路与总结进行闪光播报。

评论

发布
暂无评论
Redis on AEP 实践