携程Redis容器化实践 携程李剑
2020-02-27 230浏览
- 1.携程Redis容器化实践 CIS-Sysdev-李剑
- 2.目录 • 背景 • Redis为什么要容器化 • Redis能不能容器化 • 架构和细节 • 一些坑
- 3.背景
- 4.基本概念 • 集群是访问Redis的基本单位 • 应用通过CRedis提供的客户端通过集群访问到实例 • 多个集群对应一个Pool，一个Pool对应多个Group，每个Group 对应一个或多个实例 • Key通过一致性hash散列到每个Group上
- 5.集群拓扑图
- 6.数据 • 总内存200T+，平均每天访问次数超百万亿次 • 宿主机1400+，实例数16000+ • 实例大的高达60G+，小的只有几百M。QPS高的有几万，低的 个位数
- 7.Redis为什么要容器化
- 8.标准化和自动化 • Redis直接部署在物理机上，每个版本 之间配置差异巨大，不好维护 • 容器镜像天然支持标准化，与物理机 完全无关 • 容器基于K8S自动部署效率，相比人 工部署提高了59倍
- 9.规模化 • 有别于社区方案，携程技术方案演进 需要对大的实例分拆 Redis实例规模 120000 100000 • 实例分拆造成实例数急剧膨胀，靠人 力难以运维 • 容器化能对分拆后的实例很好的管理 和运维 80000 60000 40000 20000 0 目前 目前 分拆后 分拆后
- 10.提高资源利用率 • 借助于容器化和上层的编排系统，我 们很轻易的就可以做到资源利用率的 提升 Redis资源利用率 50% 45% 40% 35% 30% 25% 20% 15% 10% 5% 0% 容器化前 容器化前 容器化后 容器化后
- 11.Redis能不能容器化
- 12.性能测试-响应时间 Redis-benchmark SET 响应时间 单位ms 10 8 6 4 2 0 99%line 99.9%line 容器DATA100K 物理机DATA100K 容器DATA50K 物理机DATA50K 99.99%line
- 13.性能测试-QPS QPS 20000 15000 10000 5000 0 100K 50K 容器 物理机
- 14.性能测试-监控流量
- 15.小结 • 容器与物理机性能有细微差别,大约5-10% • 携程的使用场景Redis完全可以容器化
- 16.架构
- 17.总体架构 • 运维和治理工具:CRedis Gov, Rat • Paas提供统一接口对外接口 • Redis微服务提供Redis实例的 CRD功能以及自定义的Redis调 度策略 • 基础设施包括 OVS/Neutron/Telegraf/Quota/ StickyScheduler提供网络存储监 控磁盘配额等方面能力
- 18.流程
- 19.细节
- 20.问题 • 客户端直连，IP固定和宿主机固定，Master/Slave不能在一台宿主机上 • 部署基于物理机，端口来区分，监控也通过端口来区分 • 重启实例Redis.conf文件配置不丢失 • Master挂了不希望被K8S立刻拉起来，而得让Sentinel感知 • 几乎没有任何内存控制
- 21.方案-K8S原生策略 • 基于K8S的Statefulset • nodeAffinity保证调度到指定宿主机上 • podAntiAffinity保证同一个Statefulset的pod不调度到同一台宿主机上 • Toleations保证可以调度到taint的宿主机上，而该宿主机不会被其他资源类 型调度到，如mysql,app等
- 22.方案-Sticky Scheduler
- 23.方案-quotas • 自研chostpath和cemptydir 基于xfs的quota限额 • 将Redis.conf和data目录挂 载出，保证重启容器后配置 不丢失，也保证容器重启后 可以读rdb数据
- 24.方案-监控 • 每个POD两个容器,一个Redis实例,一个监控程序telegraf • 监控程序基于物理机监控脚本移植 • 所有telegraf脚本固化在物理机上，一旦修改方便统一推送，对Redis实例 无任何影响
- 25.
- 26.
- 27.方案-supervisord • 1号进程supervisord • Redis挂掉后，supervisord不去主动拉起 • 等哨兵执行master/slave切换后再删pod重建
- 28.方案-内存CPU配额 • CPU超分不限制 • 容器内存超分到80G,limit=80G
- 29.超分大法好,OOM了怎么 办？
- 30.方案-调度策略 • 集群重要性划分 • 基于重要性调度到低中高配机器上 • 基于重要性决定是否调度到多Region上
- 31.单Region
- 32.多Region
- 33.方案-宿主机预留(调度前) • 不同配置宿主机限定不同max-pod数量 • 占位pod预留10%资源禁止调度 • 设定pod的request=redis max_memory
- 34.方案-调度中和调度后 • 基于宿主机实际容量调度 • 定时轮询所有宿主机查看内存分配是否合理，对于不合理的集 群，自动触发迁移
- 35.方案-其他策略 • 动态调整HZ（减小used_memory) • 动态打开关闭自动碎片整理(减小rss_memory) • 宿主机内存告警 (>80%)
- 36.小结 • Redis跑在容器上，多个组件共同协作的才能达成 • 现状决定必须超分 • 超分后如何不OOM是关键 • 思路需要发散，容器层面和Redis层面都 可以相应的对策 Redis资源利用率 50% 45% 40% 35% 30% 25% 20% 15% 10% 5% 0% 容器化前 容器化前 容器化后 容器化后
- 37.一些坑
- 38.System load有规律毛刺 增加POD毛刺上升，而 且看上去跟CPU利用率 无关
- 39.System load有规律毛刺 降低POD数量，毛刺减 小， 但并没有消失
- 40.System load有规律毛刺 • 修改telegraf中的 collection_jitter值，用 来设置一个随机的抖动 来控制tellgraf采集前的 休眠时间，让瞬间不会 爆发上百个进程
- 41.Slowlog异常
- 42.Slowlog异常 • 具体分析可以查看携程技术中 心微信公众号：ctriptech
- 43.Xfs bugs • xfsprogs4.5(mkfs.xfs)使用的是 没有attribute((packed))，64位 上sizeof (xfs_agfl)是40字节， • 内核态(linux4.5以后)的XFS有 attribute((packed))，64位机器 上sizeof 是36字节，会导致内核 在写xfs_agfl时候误判有多一个 agfl_bno,写出界导致Metadata corruption
- 44.Xfs bugs • Xfsaild进入D状态导致宿主机大量D状态进程和僵尸进程,最终导致宿主机僵 死 • 与khuagepaged有关 • 升级内核到4.14.67后backport4.15-4.19的bugfix，关闭透明大页，压测 问题依然存在，但能控制free内存在3G以上不复现，实际生产上使用4.14 内核还没再复现过。
- 45.本PPT来自2018携程技术峰会 更多技术干货，请关注“携程技术中心”微信公众号
