Project Eru

目前我们开发的 Eru 项目，作为平台层面的高层调度器

Transcript

1. Project Eru CMGS@HBS
2. Why • Google 的 Borg 亲⼉儿⼦子都叫 Omega 了，终极解决 ⽅方案了不是，相⽐比之下我们 NBE 这名字就太弱爆 了…… • I smell your weakness… • 继承于⾖豆瓣的命名⻛风格，我们只好找了魔戒中的⾄至 ⾼高神 Eru 为项⺫⽬目名来镇场⼦子 • 不是 PaaS ！！不是 PaaS！！不是 PaaS！！ • 重要的事情⼀一定要说三遍……
3. Eru 就是他了
4. Features • Online & Offline 混排 • 业务和服务部署⽀支持 • 基于 Docker 实现环境隔离 • runtime ⼀一致性，快速部署和扩容 • 物理/逻辑集群划分 • 弹性资源控制 • 还有⼀一堆我懒得说了……
5. Features • 好吧继续说下… • 基于 redis 的数据总线，基于消息随意扩展 • 统⼀一业务/服务⾏行为，标准化线上操作 • 集群动态感知，详细的物理监控数据 • 基于⼆二层的⺴⽹网络隔离（macvlan） • ⽀支持多⼦子⺴⽹网交叉 • 安全控制
6. 架构
7. So • 它不是 PaaS（再次强调） • 主要功能是⽤用在线上服务/业务编排 • 这是为啥我们的⺫⽬目标⼀一直是 Borg/Omega • 分 Core 和 Agent 两个部分 • ⺫⽬目前完成了 Redis-Cluster ⽀支持和 web ⽀支持 • 标准化业务代码整个⽣生命周期 • 躺了⼤大概⺴⽹网络/存储/资源分配/调度/服务发现/扩容缩容这么⼀一堆 领域的坑 • 妈妈再也不⽤用担⼼心我加班了……
8. Diff • 对⽐比第⼀一代 Nebulium Engine • Core 和 Agent 低耦合，通过消息总线传递消息 • Core ⽆无状态化，允许多个 Core 保证旁路控制可靠性 • Core 直接操作 Docker daemon，降低 Agent 的复杂度提⾼高可靠性 • 启⽤用 MacVLAN • 更加精细的物理/逻辑分组隔离 • 更弹性的资源控制 • 全包 VS 组合模型 • 总之相当于重写了……
9. 名词 • Group 操作组，不关⼼心⽤用户，那是上层调⽤用者⾃自⼰己组 织。⼀一个 Group 可以操控若干 Pod • Pod 逻辑上分割的服务器集群，逻辑上 Pod 是隔离的， 物理上并不⼀一定 • Host 起 Container 的物理机器 • Private Host 资源有限服务器，⽤用于以 Cpu Bound 的为 主的服务，与 Pod 绑定 • Public Host 变相的服务降级措施，⽤用于部署抢占式 Container，与 Group 绑定
10. 名词 • App 逻辑上⼀一个业务/服务，我们称为 App • Entrypoint 启动 App 的姿势，可以有多个，实现⼀一 份代码多种⾓角⾊色 • Port App 启动⾃自⼰己绑定的端⼝口，为了服务发布 • Env App 可以启动时选择的环境，主要包含 MySQL 等资源地址 • Build App 打包⽅方式，⽀支持对镜像安装⼀一些系统级 依赖
11. ⺴⽹网络 • 重写⺫⽬目的之⼀一 • Docker 默认的⺴⽹网络模式⽐比较残疾 • 业内其他公司各有各的解决⽅方案 • 我们使⽤用 MacVLAN
12. ⺴⽹网络 • ⺫⽬目前有的⼏几种 Overlay ⽅方案 • Tunnel Based 太灵活，规模上 去后debug 噩梦 • Weave 的性能问题 • Route Based 需要 Agent 在 Host 上操作 • MacVLAN 依赖物理⺴⽹网络 • Calico ⽣生效需要时间
13. 其他公司怎么做的
14. Hmmm… • Tencent 分享的盖亚是⽀支持所有 docker ⽀支持的⽅方式，推 测 Host 居多 • Weibo 分享他们主要是 Host，VxLAN ⼩小规模测试中 • 雪球分享他们⾃自建了 Bridge • 作为⾖豆瓣半只平台组所在的宜信⼤大数据…他们⽤用了 Calico • 这件事告诉我们，要有⼀一个强⼒力 SA • 京东据说是 OVS • UniteStack 测试称 OVS 性能衰减⽐比较惨烈
15. Eru • 基于 MacVLAN • 感谢运维没在⼆二层做任何限制 • ⼆二层⼦子⺴⽹网隔离，纯洁的数据包 • 理论上每个 Container 拥有独⽴立的⺴⽹网络栈，近似的可以看成是虚拟机 • 混合云作为甲⽅方只能 Push 服务提供商来⽀支持了，微软表⽰示好好好， AWS 斜眼看着我们 • 主要还是简单 • QoS 交给⼆二层实现，达到⺴⽹网络资源限制和调度的效果 • 改内核什么的不是⾂臣妾不⾏行，是懒得维护啊…… • 部署时选择让 Container 加⼊入到什么⼦子⺴⽹网（s，此处表⽰示是个复数）
16. Eru • Core • 管理和分配⼦子⺴⽹网IP，部署时进⾏行 • 部署完毕通过数据总线⼲⼴广播 IP:PORT，⽤用于服务发现 • 回收死掉 Container 的资源 • Agent • 调⽤用 IP 命令给 container 塞⼊入 MacVLAN 设备 • 配置 IP 启动⺴⽹网卡 • 死掉/关掉的 Container 会⾃自动释放 MacVLAN 设备，不需要关⼼心
17. 资源 • 重写⺫⽬目的之⼀一 • 早期 NBE 的资源分配……我现在也看不懂了 • CPU/内存/⺴⽹网络为主 • 成本上是⺴⽹网络>CPU>Memory>Disk 这样的 • 磁盘暂时不考虑
18. 其他公司怎么做的
19. Hmmm… • Tencent 表⽰示我们有⾃自⼰己的 tlinux，在内核中实现了⼀一 个 subsystem，从⽽而使得可以设定⼀一个 softlimit 控制 container 的内存 • 改造后的 Yarn ⽀支持 0.1 核这个粒度的调度，提⾼高了 CPU 利⽤用率 • ⺴⽹网络会通过 tc 控流，暂不知他们怎么实现的，因为印 象中 tc 精度并不⾼高 • Google Borg 是抢占式，task 分级 • 宜信⼤大数据是半⼈人⼯工的内存限制
20. Eru • 内存 • 记录申请⼤大⼩小，但是不做限制，每个 Container 都拥有整个物理内存⼤大⼩小的上限 • 通过外围⼀一个观察者，读取 influxdb 中的内存数 据，判断是否超限 • 同时判断所在物理机内存剩余量 • 如果超限并且物理机内存剩余量低于 20% • OOM Kill
21. Eru • Cpu • ⼀一开始我们只做了 By Core • Tencent 的分享让我们开启了脑洞，觉得 0.1 核的 ⽀支持应该也不错 • 实际上⼀一个 Redis instance 吃不满⼀一个核 • 我们可以针对 Pod 设定不同逻辑集群的 CPU 碎 ⽚片率，可以 0.1 也可以 0.01
22. Eru • ⺴⽹网络 • ⺫⽬目前毫⽆无节操限制 • 采⽤用 MacVLAN 之后在⼆二层设备做 QoS • 需求没有那么强烈 • Public Host • ⾃自⼰己抢资源，不关⼼心
23. 调度和编排 • 主要重写的部分 • 早期的调度和编排灵活度不够，导致耦合业务⽐比 较强，因此推⾏行阻⼒力⽐比较⼤大 • 完全⾃自写 • Kubernetes/Docker Swarm 等通通不⽤用 • 裁剪和整合成本⾼高于⺫⽬目前我们⾃自研成本 • ⾂臣妾连 Mesos 都没玩透，Marathon 就算了吧
24. 其他公司怎么做的
25. Hmmm… • Tencent 再次表⽰示改个 Yarn 不是什么事… • Weibo 表⽰示我⾃自研我⾃自豪 • 宜信⼤大数据觉得虽然 Docker Swarm 有坑，但我跳 得过去 • 京东似乎是⽤用的 OpenStack（真的管⽤用吗？）
26. Eru • Core 负责计算如何部署 Container • App 部署时需要选取 • Entrypoint，决定以什么⾝身份启动 • Env，决定 Container 能使⽤用哪些资源 • Networks，决定 Container 加⼊入到哪些⼦子⺴⽹网 • CPU/MEM ⼀一个滑动条拖来拖去
27. 容器内存储 • ⺫⽬目前暂时 DM 居多 • Overlay 已经上了测试机，3.19 内核伤不起 • Overlay 我们测试结果⾮非常喜⼈人 • 但是，似乎有些奇怪的问题 • 其他公司⼀一般外挂了 • 我们其实也外挂了 MooseFS
28. 监控 • Agent 报告 Container 死活给 Core • by APIEventListener • Agent 读取本地 Cgroups 状态⽂文件发数据给 influxDB • by libcontainer/Cgroups/fs struct Manager • Agent 通过 exec 进 container ⾥里⾯面 cat 出 MacVLAN 设备的状态来获得⺴⽹网卡状态 • InfluxDB 是个坑，⺫⽬目前我们掉进了 0.9 RC 正⽆无穷
29. Scale • Eru 本⾝身⾃自⼰己不做 Scale • 谁关⼼心，谁做 • 监控 InfluxDB 中的基础信息数据，也可以对⽐比业 务⾃自⼰己的监控数据（QPS，响应时间等） • 觉得不⾏行了，调⽤用 Core 的 API • 我们实现了⼀一个简单版本的扩展程序作为栗⼦子，主 要以平均 Container 的 CPU 利⽤用率作为指标，来 对⼀一个 App 下所有 Container 进⾏行扩容和缩容
30. 扩展 • 与 NBE 第⼀一代最⼤大的不同 • 第⼀一代是个完整的⼯工作范式，是计划经济 • Core 对外交互主要依赖 Redis 的 PubSub/List 等 ⽅方法/数据结构 • 谁关⼼心，谁去监视对应的 Key，然后完成下⼀一步操 作 • ⽐比如对 web 服务可以⽤用 nginx 读取 redis 数据然 后动态的更新⾃自⼰己的 upstream（by openresty）
31. 扩展 • 理论上来说 Agent 也是 Core 的⼀一个扩展 • 我们称 Redis 为数据总线 • 适⽤用于任何业务/服务需求 • 主要⽅方便了业务/服务发现和 Scale • 之前说的扩容缩容⼯工具就是这种模式下开发的
32. ⼯工作流 • NBE 第⼀一代完整的控制了从 source code 到 online system 的所有流程 • 我们发现业务⽅方表⽰示改起来太特么蛋疼了 • 于是，我们预留了 Build 作为 App 描述中的关键字 去掉了 Test，丰俭由⼈人 • Test 和其他 Entrypoint ⼀一样，是通⽤用的，业务可以 ⾃自⾏行设置⼀一个 Entrypoint 为 Test ⽅方式 • 保留了 Gitlab hook，推崇 Github workflow
33. 镜像和容器 • 基础镜像基于 Ubuntu 14.04 最⼩小化打包⽽而成 • 每个基础镜像之上有⼀一层业务镜像 • Binary/Python/Java • 每个镜像⾥里⾯面有个 Launch 脚本，Build App Image 时替换掉其 中的 uid username，作为 App 镜像的⼊入⼝口 • Container 以 root ⾝身份创建 • 启动时 mount /proc/sys 到⼀一个可写⺫⽬目录，Launch 会修改⼀一些内 核参数（为了⼆二进制服务的⽀支持），这样并不会影响 Host • 最后建⽴立 Container 内⽤用户，exec 启动 App 选取的 Entrypoint， 保证进程安全
34. 举个栗⼦子 • Redis Cluster • 近400个 Instances • 有 10个集群 • 完善的部署/监控/扩容/Proxy服务，随时可以 Docker 化 • 测试 QPS（测试脚本达到上限服务端并没）为15W左 右，实际业务峰值 8W 左右 • 全 AOF，M-S 结构看需求
35. Redis Cluster • 按照内存/内核数分内存，⼀一般⼀一个 Instance 内存 在 1G 左右 • 这种规模容器内写⼀一般是没啥问题的 • 要修改 vm.overcommit_memory 和 net.core.somaxconn • 使⽤用 Launch 脚本⽅方式+ remount /proc/sys 到可写 ⺫⽬目录，不⽤用 Privilege 模式达成
36. Redis Cluster • 现有的⾃自动发现 Redis Cluster Instance 的服务， 只需要关注 Core 的⼲⼴广播信息即可做到对集群增加 或者减少 Instance • ⼀一个 Redis Cluster 是⼀一个独⽴立⼦子⺴⽹网 • 现有⾃自动扩容 Redis Cluster 的服务只需要调⽤用 Core 的 API 就可以实现部署扩容，不需要以前的 部署系统先去部署⼀一⼤大堆 Instance
37. Redis Cluster • Cerberus 作为我们⾃自⼰己的 Proxy 也⽤用类似的⽅方式 部署 • 想要增加集群吞吐能⼒力直接增加 Cerberus 即可 • 对于业务⽽而⾔言，每⼀一个 Redis 集群都是独⽴立隔离 的，像积⽊木⼀一样丢给他们就能⽤用 • 任何 Redis Cluster 都可以从最⼩小集群开始⾃自动按 需扩容
38. 好处 • 扩容缩容不需要使⽤用我们另外⼀一个部署项⺫⽬目去做了， 提⾼高了扩容缩容的效率 • 对于集群感知能⼒力更强，预先容量估计和规划也可 以不⽤用做了（当然做了更好……） • 积⽊木⼀一样的丢给业务⽅方⽤用，实现真正的 SaaS 模 式，模糊物理服务器边界 • 更好的利⽤用服务器资源
39. Q&A
40. 谢谢 https://github.com/HunanTV