Baidu Cloud Foundry

3,259 views

Published on

Found this public presentation of the massive work Baidu is doing with Cloud Foundry.

0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,259
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
90
Comments
0
Likes
5
Embeds 0
No embeds

No notes for slide

Baidu Cloud Foundry

  1. 1. 基于CloudFoundry的私有云平台 @王炜煜,百度运维部 weibo.com/wwy1640 2013-7-19
  2. 2. 内容  背景与目标 实践与改造(Part 1、2) 流程与标准 改变运维 未来计
  3. 3. 1. 背景与目标
  4. 4. 运维与PaaS  Storage Servers Networking O/S Middleware Virtualization Data Applications Runtime OP(SRE),运维 PaaS (and IaaS)
  5. 5. 目标  自动化 业务的生命周期管理,如变更、监控、故障处理等 资源利用率、弹性 标准化 流程 实例标准 系统环境、runtime、framework 一体化 集成第三方服务,如DB、Cache、log、FS等 与其他系统平台联动
  6. 6. Why CloudFoundry ? 自动化 标准化 一体化 机器管理(下游部 ) 自动化 一体化标准化
  7. 7. Why CF ?  自动化 一体化 标准化
  8. 8. 2. 实践与改造(Part1) Java,base on cf 1.0
  9. 9. Java Apps  •  产品 类 >100 •  APP >200 •  实例>2000 •  平均单实例10G(内存) •  日均总pv > 10亿 •  APP的 发及测试人员 > 700人 •  Tomcat5/6/7、jdk1.5/1.6、Standalone
  10. 10. 开始实施,准备工作  •  基于CentOS的相 改造 ü  独立部署各个CF组件 ⁺  拆解BOSH、chef,基于物理机实施 ü  OS环境初始化 ⁺  apt-get 改为 yum ü  Ubuntu-cmd to CentOS ⁺  DEA(v1.0),agent.rb、secure.rb yum install -y make gcc gcc-c++ kernel-devel.x86_64 openssl-devel.x86_64 libxml2.x86_64 libxml2- devel.x86_64 libxslt.x86_64 libxslt-devel.x86_64 git.x86_64 sqlite.x86_64 ruby-sqlite3.x86_64 sqlite- devel.x86_64 unzip.x86_64 zip.x86_64 ruby-devel.x86_64 ruby-mysql.x86_64 mysql-devel.x86_64 curl- devel.x86_64 postgresql-libs.x86_64 postgresql-devel.x86_64 zlib-devel.x86_64 readline-devel.x86_64 ImageMagick.x86_64 ImageMagick-devel.x86_64 php-magickwand.x86_64
  11. 11. 集群容量评估  •  实例数量,NATS容量评估 ü  单台DEA承载的实例数(<100),对NATS-Server压力影响不大 ü  单NATS-Server,保守估计可承受330台DEA,单台实例数5~30个 ü  多NATS-Server,可扩展 延时 (ms) DEA台数 (10 ~ 340台) 单DEA实例数 (5 ~ 30个) 临界线 330台DEA
  12. 12. 集群内,组件冗余、LB设计  •  NATS ü  使用cluster版,多NATS,心跳同步 ü  Client 端缓存信息,如果网络中断,则不断reconnect ü  多NATS负载均衡(Client > 0.5.beta.6) NATS-Server1 NATS-Server2 NATS-Client (caching message) NATS-Server1/2, Random list
  13. 13. 多集群冗余设计  •  多个独立的集群,逻辑互不影响 ü  第一层切换,修改DNS A记录,对多个域名(CNAME到此A记录),统一切到不同的集群 ü  第二层切换,修改“接入层”(其应用层的功能,可简单理解为nginx的反向代理) ü  保证好APP(无状态)的容量,或快速扩容的预案,以防止流量切过来以后,出现过载 Baidu GateWay Front End Router A记录 Baidu GateWay Front End Router app1 app1 CNAME(正式域名) CNAME(正式域名) www.baidu.com CNAME www.a.shifen.com. www.baidu.cn CNAME www.a.shifen.com. www.a.shifen.com. A 119.75.218.77 www.a.shifen.com. A 119.75.217.56
  14. 14. 核心组件,分布  Router_1 NATS_1 Router NATS CC HM Stager DEA PG_DB Redis
  15. 15. 整体结构(cf1.0)  DEA Logging Name Service Monitoring jvm Stager File Persistence HM Router CC Baidu GateWay / Front End jvm jvm API Bridge UAA jvm jvm jvm jvm jvm Router(Cluster 02) N A T S DB
  16. 16. 新增功能  •  支持RPC、单实例多端口 ü  单实例 启多个端口,并提供API实时查询IP、端口号 ü  与“名称服务”联动,同步动态ip端口与名称的对应 系 ü  RPC调用方,根据名称直连实例
  17. 17. DEA server 支持RPC、单实例多端口  Instance01:port Instance02:port API Bridge NS server TXT记录 ip:port ip:port RPC调用方 NS client Domain ip:port ip:port ip_local_port_range 10000 ~ 60000 Port池(分配后,有冻结期) 61000 ~ 65000
  18. 18. 新增功能  •  支持JMX ü  API实时查询ip与Jconsole端口号,实现JMX数据实时采集
  19. 19. DEA 支持 JMX  Instance01: Jconsole 端口 Instance02: Jconsole 端口 { "instances": [ { "index": 0, "state": "RUNNING", "since": 438249600, "jconsole_ip": "10.1.1.1", "jconsole_port": 61111 }, { "index": 1, "state": "RUNNING", "since": 438249600, "jconsole_ip": "10.1.1.1", "jconsole_port": 62222 } Monitoring Metrics CpuUseRateDaemonThreadCount MemPool_OldGen_UseRate NonHeapMemoryUsage_used TotalCompilationTime TotalPeakThreadCount TotalStartedThreadCount UnloadedClassCount GC_Major_Frequency GC_Major_Time … … Stager: java -Dcom.sun.management.jmxremote.port={VCAP_JCONSOLE_PORT} -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false
  20. 20. 新增功能  •  加强健康检查 ü  七层检测 ü  文件句柄数检测
  21. 21. DEA Server DEA agent.rb Health Manger instance http 可用 性 instance CPU MEM DISK …… report 加强健康检查  句柄
  22. 22. DEA(v1.0),逻辑改进  •  端口管理 ü  问题描述 ⁺  单DEA多实例,并行的端口分配与启动,没有临界区,有端口竞争的问题 ü  解决方案 ⁺  借鉴了DEA(v2.0)的逻辑(注:即 DEA_NG,与CF1.0不兼容) ⁺  设定 ip_local_port_range 为 10000~61000,作为动态端口的范围 ⁺  将61001~65000,作为DEA的调度分配端口 ⁺  对分配的端口,增加“[释放时间、端口号]”的数据结构 ⁺  通过延时释放端口,解决了端口竞争的问题 ü  备注 ⁺  CF2.0中,已解决此问题,方法同上
  23. 23. DEA(v1.0),逻辑改进  •  实例资源信息管理 ü  问题描述 ⁺  du命令算实例磁盘空间,时间较⻓长,随后执行其他计算命令,信息已不一致 ⁺  CPU计算的方法,没有考虑主机核数 ü  解决方案 ⁺  调整相 命令的顺序 ⁺  CPU利用率计算时,除以核数 ü  备注 ⁺  CF2.0中,已解决此问题
  24. 24. 新增功能(与外围系统联动)  •  文件持久化 ü  使用MFS(Moose File System) ü  DEA 部署MFS-Client,并 mount /mfs/path,供实例使用 ü  MFS服务端提供HTTP接口,获取数据 •  基于URI的路由,区分APP ü  foo.baidu.com/app1 à app1.foo.baidu.com ü  foo.baidu.com/app2 à app2.foo.baidu.com •  监控联动 ü  APP的生命周期,与外部监控系统的API交互,实现监控项的自动增删改 •  发者工具包 ü  自动化发布(封装vmc) ü  文件查看
  25. 25. 主要改造点汇总(cf v1.0)  •  基于CentOS的相 改造 •  使用NATS-Cluster、NATS-Client重试与缓存 •  支持RPC、单实例多端口 •  支持动态JMX、Jconsole •  加强健康检查 •  端口管理 •  实例资源信息管理 •  外围组件:文件持久化、监控联动、URI路由、 发者工具包
  26. 26. 2. 实践与改造(Part2) C/C++,base on cf 2.0
  27. 27. C/C++ Apps,几大核心问题  •  Container 的运行环境与资源隔离 ü  Kernel/GNU ü  资源隔离 ü  快照,Core Dump •  单实例多进程 ü  健康检查 ü  进程运行顺序 ü  实例内,进程间通信 ü  多端口 ü  多实例的同构性
  28. 28. C/C++ Apps,几大核心问题  •  大实例 ü  实例个数多(10万) ü  数据量大(单实例,2TB) ü  内存占用高(单实例,100G) ü  启动时间⻓长(30分钟) ü  流量大(单实例,日总PV2亿) ü  漂移时,防止资源不足 •  APP通信 ü  网络层通信,权限、流量控制 ü  输出文件,需要外部抓取 ü  输入文件,需要外部推送 ü  RPC,非HTTP协议,不包含PATH信息,无法路由
  29. 29. 实例的 OS-Level 环境准备  •  Container的运行环境 ü Kernel 与宿主机一致 ü 订制Container的文件环境 warden/warden/root/linux/rootfs/setup.sh if grep -q -i centos /etc/issue then exec $(dirname $0)/centos.sh $@ fi
  30. 30. Container与宿主机的关系  Warden Networking,Bridge / NAT / Firewall / FlowControl DEA init─┬─xxx ├─xxx─xxx ├─xxx mount r usr/ lib/ etc/ mount rw xxx/ network interface(sub net) Cgroup – CPU / MEM Name space init─┬─xxx ├─xxx─xxx ├─xxx mount r usr/ lib/ etc/ mount rw xxx/ network interface(sub net) Cgroup – CPU / MEM Name space
  31. 31. 包管理  •  Buildpack API ü  detect , 检查 ü  complie,环境准备 ⁺  目录结构 ⁺  程序文件,及相 配套程序 ⁺  启动脚本,保证进程的启动顺序,等等 ⁺  监控脚本,可以周期性执行,检测整个实例的健康程度 ü  release,发布信息 ü  Procfile,参数传递(如端口号) ü  .profile.d,环境变量
  32. 32. 健康检查,改造点  •  自定义监控脚本 ü  自定义监控脚本,随实例一起发布,周期性改写stat_file文件内容 ü  DEA定期检查stat_file文件 实例 stat_file monitor.sh process-1 process-2 DEA HM
  33. 33. APP的改造  •  针对RPC,支持NS Client ü  动态配置文件,代替路由 ü  端口管理,冻结时间 •  输入输出文件 ü  输入文件,主动抓取 ü  输出文件,推到中转处(如云存储),或基于NS服务 •  多进程的管理,启动脚本 ü  多进程,启动顺序控制 ü  进程控制 •  文件持久化 ü  远程日志 ü  使用云存储
  34. 34. 整体结构(CF2.0)  DEA Logging Name Service Monitoring File Persistence HM gorouter(RPC,不适用) CC Baidu GateWay / Front End API Bridge UAA (Cluster 02) N A T S Container process-1 process-2 Warden NS Client Container process-1 process-2 Container process-1 process-2 DB
  35. 35. 主要改造点汇总(cf v2.0)  •  基于CentOS的相 改造 •  Container环境的订制 •  Buildpack的订制 •  支持RPC、单实例多端口 •  加强健康检查 •  外围组件:文件持久化、监控联动、URI路由、 发者工具包
  36. 36. 3. 流程与标准
  37. 37. 工作流程,简述  评审 •  标准 •  容量 •  SLA 接入 •  组织 系 •  名称信息 •  运维信息 流程审批 •  权限申请 •  名称申请 •  发布操作 发布更新 •  预发布 •  灰度 •  回 故障处理 •  可用性 •  安全 •  问题管理
  38. 38. 标准与容量,举例  •  标准信息采集 ü  App相 名称、相 接口人(R&D、QA、运维、相 经理,等) ü  Runtime与容器版本 ü  无状态、RPC、URI路由 ü  动静态文件分离 ü  文件持久化 •  容量信息采集 ü  PV、QPS ü  单实例 CPU、内存、磁盘、带宽、重启时间 ü  实例数量
  39. 39. SLA,举例  •  服务对象 ü  Java 应用(以下简称“APP”) ü  符合标准的APP •  服务时间 ü  24×365全年无休 •  沟通方式 ü  Mail、Tel、接口人信息 •  稳定性相 指标 ü  核心组件,可用性>99.99%(每月),MTTR<20分钟,MTBF>5天 ü  控制服务,可用性>99.95%(全年) ü  APP自身SLA,不因平台本身,造成负面影响 ü  注:APP自身问题,不在此SLA范围内,如: 程序bug、容量预估错误、外部系统故障(如DB、Cache)等
  40. 40. 组织关系,层级  • 产品线(Org) • 模块(Space) • 分组(APP) • 版本(APP-*) 产品线-2 产品线-1 (Org) 模块-2 模块-1 (Space) 分组-1(A) 分组-2(B) 实例,版本-1 (APP-1-1) 实例,版本-2 (APP-1-2) 实例,版本-1 (APP-2-1) 实例,版本-2 (APP-2-2) 实例,版本-1 (A-1) 实例,版本-2 (A-2) 实例,版本-1 (B-1) 实例,版本-2 (B-2) 虚线内, 相当于一个APP, 且有多个实例
  41. 41. 对CC进一步封装  产品线(Org) OrgName 模块(Space) OrgName_SpaceName 模块分组 OrgName_SpaceName_GroupTag 模块版本 OrgName_SpaceName_GroupTag_VersionTag 实例(id唯一) OrgName_SpaceName_GroupTag_VersionTag_Index
  42. 42. GroupTag、VersionTag  • GroupTag •  可以区分:配置文件、机房、机架等维度的不同 • VersionTag •  可以区分:程序、数据、配置文件等 •  包含:四位版本号、时间戳 • 实例完整名称,例子 •  Org_Space_GroupA_1-1-1-1-438249600_1 •  Org_Space_GroupB_1-1-1-1-438249600_1
  43. 43. 审批与发布  •  发审批单 ü  APP信息(程序版本、容量信息、相 说明,等等) ü  审批人(相 经理、需知晓的人) ü  操作者、操作时间 ü  监控信息(监控策略、接口人等) •  始发布操作,并添加监控 ü  发布前,对应审批流必须通过 ü  操作人、程序版本、MD5、时间等信息,必须与审批流一致 ü  都一致,且流程通过,则可以 始发布 ü  发布成功后,添加监控 发单 审批 发布APP 监控添加
  44. 44. 预发布、发布、回滚  app_v1 instance01app_v1.paas.baidu.com app_v1 instance02 app_v2 instance01 app_v2 instance02 app_v3 instance01 app_v3 instance02app_v3.paas.baidu.com app.baidu.com 泛域名、 map/unmap、 app的多版本并存 前进,发布 后退,回 预发布,线下内网观察
  45. 45. 基本的灰度发布  app_v1 instance01app_v1.paas.baidu.com app_v1 instance02 app_v2 instance01 app_v2 instance02 app_v3 instance01 app_v3 instance02 app.baidu.com 1、将一个正式域名,同时指向多个app 2、调整多个app的实例数比例,即调整了流量的比例 app.baidu.com app_v2 instance03 通过调整app实例的数量, 灰度流量的分配比例
  46. 46. “布道之道”,平台的推广  •  军功章,有谁的一半? ü  APP的支持 ⁺  新服务,需遵守PaaS的相 标准、思想 ⁺  老服务,需R&D改造,QA需回归测试 ü  外围的支持 ⁺  DB、Cache、存储、接入、安全、监控,等等 •  明 收益,建立共赢的生态圈 ü  交付更快、资源更省、事情变得简单 ü  一站式的一体化服务,携手推广
  47. 47. 一些方法  •  给用户(APP 发人员),尊贵的帝王般的享受 ü  对重点的APP,有针对性的重点服务 ü  对重要的管理者,有一套更完整、及时的沟通方式,如报表等 ü  原则是“资本主义”,而不是社会主义 •  事件“营销” ü  如“struts2 0day” ⁺  积 配合R&D、QA做问题排查、修 与实施 ⁺  积 通报进展,做好事件管理 ⁺  后期,针对此事,积 推进、参与讨论与决策,如与安全、架构组合作 ⁺  原则是“共赢”,而不是推卸责任
  48. 48. 4. 改变运维
  49. 49. 改变运维  “NoOps” PaaS(and IaaS) 的完整功能 >= 传统运维工作 Storage Servers Networking O/S Middleware Virtualization Data Applications Runtime OP(SRE),运维 PaaS (and IaaS)
  50. 50. 如何改变,举例  • 故障自动 ü  在传统监控之上,增加了健康检查机制 ü  实例的自动重启与“漂移” ü  传统的报警大量 少,人力 少 ⁺  只有自动 失败时,才报警 监控 完整实例名_1 ip:port … … 健 康 检 查 AP I … … 真实的实例_1 ip:port 漂移后的实例_1 •  “漂移”是正常现象,无需报警 •  “漂移”失败,才需报警 •  监控细化到实例,每次根据名字,探测返回的ip:port
  51. 51. 如何改变,举例  •  更加敏捷 ü  让 发者“忘记服务器”,转而面向资源 ü  有完整的配置管理,与自动化部署功能 ü  发布、预发布、回 , 其简单,且不需要额外 杂的部署工具 ü  弹性扩展, 其简单 ü  使用Buildpack,实现“云端编译”,并直接运行 •  一体化一站式的体验 ü  从发单、发布,到增删改监控,工作流程全自动 ü  整合第三方服务,统一管理入口
  52. 52. 5. 未来计
  53. 53. 未来计划  • 回馈社区 •  针对私有云的功能,尽量封装原生组件(基于CF2.0),将新的组件 源 •  如影响到原生组件的改动,尽量争取merge进主干 •  编写丰富的文档,以及心得,并积 参与交流 •  发方向 •  针对大型应用(大实例)的相 功能 •  智能调度相 •  信息安全 •  更深入的持续集成 •  UI
  54. 54. We are hiring ! @王炜煜 weibo.com/wwy1640 谢谢

×