淘宝T4

淘宝T4

1. T4:淘宝私有云 林昊 2012-10
2. Agenda ● ● ● ● ● 起源 实现方案 碰到的问题 使用状况 美好的将来
3. 起源 ● 2010年引入虚拟化,1台物理机装3个虚拟 机,一定程度降低了成本; ● 机器规模增长非常快,其中1/3的虚拟机的 peak load < 0.5; ● 做一个产品来提升机器的资源利用率。
4. 起源 ● 为什么叫T4 ○ Taobao的架构体系发展 ■ 1.0: php ■ 2.0: 集中式Java ■ 3.0: 大规模分布式Java ○ 这个产品将再次改变淘宝的运行体系,因此命名 为:Taobao 4.0,缩写:T4。
5. 实现方案 ● T4的目标 ○ 在保障系统稳定性的情况下降低运维成本; ○ 实现平滑迁移。
6. 实现方案 ● 运维成本不够低的主要原因 ○ 单台物理机上跑的应用不够多; ○ 分给应用的机型以及机器数是静态的; ○ 集群的资源利用率不均衡。
7. 实现方案 ● 单台物理机上跑更多的应用; ○ 超配; ■ 支持资源可共享; ■ 支持共享的资源的动态调整。 ○ 部署的应用的合理搭配; ■ 资源消耗多的和少的搭配; ■ 消耗的资源不同的互补。
8. 实现方案 ● 分配应用的机型以及机器数需要是动态的 ○ 根据应用的资源利用率动态调整; ■ 机型需要支持动态调整; ■ 机器数要动态的要求是应用新上线机器和下线 机器的动作需要全自动化。 ● 集群的资源利用率做到均衡 ○ 根据集群各机器的资源利用率状况动态迁移应用;
9. 实现方案 ● 总结 ○ 动态 ■ 单机资源的搭配以及数量可动态调整; ● 需要一个可很好支持此需求的虚拟化方案; ■ 动态迁移应用保障单机应用搭配的合理性以及 集群资源利用率的均衡。 ● ● ● 强大的监控; 资源管理系统; 应用上下线的全自动化。 ○ 弹性 ■ 根据应用的资源消耗状况动态调整机型以及机 器数。 ● ● ● 强大的监控; 资源管理系统; 依赖动态特性。
10. 实现方案 ● 虚拟化方案 ○ 需要支持动态搭配以及数量的调整; ○ 内部应用的特征 ■ Share Nothing,集群化; ■ 统一的OS; ■ 安全级别要求不是很高。 ○ 选择了LXC(Linux Container) ■ namespace ■ cgroup ■ 创建出的每个container我们称为instance;
11. 实现方案 ● 虚拟化方案 ○ 自行实现了单机cpu搭配的动态调整; ○ 进行了一定的封装,实现了通过界面来调整 instance的机型。
12. 实现方案 ● 强大的监控 ○ 现成的; ○ 需要做的是无缝集成; ● 应用上下线的全自动化 ○ 内部已有多套负责各种功能的运维系统; ○ 需要做的是无缝集成。
13. 实现方案 ● 资源管理系统 ○ 负责资源的分配; ■ 演变:资源池-->按需分配 ○ 结合监控调度应用的资源 ■ 真正的云阶段 ■ 待实现,因此有点标题党...
14. 实现方案 ● 整体结构图 运维系统 Artoo2 RT VipViewer OPSDB WF ... 实现上下线的自动化 保持运维方式的不变 T4Console (Java) 资源注册 资源分配 资源监控 ssh通知需要执行的task instance T4物理机 (t4kernel+lxc) 控制脚本 应用上下线 ... http获取需要执行的task CPU调度 程序 ... instance 应用环境 控制脚本
15. 碰到的问题 ● 在instance里top看到的是物理机的资源状况; ○ 修改内核; ● max user processes限制会互相影响; ○ 修改uid; ○ LXC不支持user namespace是一件很痛苦的事。 ● 磁盘空间限制方式用img方式限制带来的问题; ○ 改为用quota; ● cgroup oom killer的死锁问题; ○ vm.oom_kill_allocating_task=1
16. 碰到的问题 ● 执行service network restart导致网络挂掉的问题; ○ https://access.redhat. com/knowledge/solutions/65421 ● instance里执行reboot的问题; ○ 暂时限制了; ● 挂载nfs时某些情况下导致load暴涨的问题; ○ http://www.spinics.net/lists/linux-nfs/msg17811. html ○ http://www.spinics.net/lists/linux-nfs/msg27912. html ● 机型的选择颇为痛苦; ○ 根源为目前不支持弹性。
17. 使用状况 ● 覆盖淘宝、天猫、一淘的部分Java应用、PHP 应用; ● instance数在9月份突破1k; ● instance的平均配置为:3 core/5g; ● 平均每台物理机(16 core/48g)运行了12个 instance,物理机的load在2-10之间;
18. 使用状况 ● 性能状况 ○ A应用同等qps的情况下,xen vs instance的情况 为rt基本一致,xen的load是instance的1.5倍; ○ B应用同等qps的情况下,xen vs instance的情况 为xen的rt是instance的1倍,load是instance的2倍; ○ C应用在压测极限qps的情况下,xen的机器大概能 承担5倍流量,而instance的机器可承担8倍的流 量。
19. 美好的将来 ● 动态 ○ 集群利用率的均衡; ● 弹性 ○ 真正迈入云时代; ● 和不同类型的应用一起运行 ○ 类似Google Shared Environments。
20. The End! ● 谢谢!