1、基于CloudFoundry的私有云平台,王炜煜，百度运维部 2013-7-19,内容,背景与目标 实践与改造（Part 1、2） 流程与标准 改变运维 未来计划,1. 背景与目标,运维与PaaS,Storage,Servers,Networking,O/S,Middleware,Virtualization,Data,Applications,Runtime,OP(SRE)，运维,PaaS (and IaaS),目标,自动化 业务的生命周期管理，如变更、监控、故障处理等 资源利用率、弹性标准化 流程 实例标准 系统环境、runtime、framework一体化 集成第三方服务，如DB、Cac
2、he、log、FS等 与其他系统平台联动,Why CloudFoundry ？,自动化,标准化,一体化,机器管理（下游部门）,Why CF ？,自动化,一体化,标准化,2. 实践与改造（Part1） Java，base on cf 1.0,Java Apps,产品种类 100 APP 200 实例2000 平均单实例10G（内存） 日均总pv 10亿 APP的开发及测试人员 700人 Tomcat5/6/7、jdk1.5/1.6、Standalone,开始实施，准备工作,基于CentOS的相关改造 独立部署各个CF组件 拆解BOSH、chef，基于物理机实施 OS环境初始化 apt-get 改
3、为 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.
4、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,集群容量评估,实例数量，NATS容量评估 单台DEA承载的实例数（100），对NATS-Server压力影响不大 单NATS-Server，保守估计可承受330台DEA，
5、单台实例数530个 多NATS-Server，可扩展,延时 （ms）,DEA台数 （10 340台）,单DEA实例数 （5 30个）,临界线 330台DEA,集群内，组件冗余、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,多集群冗余设计,多个独立的集群，逻辑互不影响 第一层切换，修改DNS
6、 A记录，对多个域名（CNAME到此A记录），统一切到不同的集群 第二层切换，修改“接入层”（其应用层的功能，可简单理解为nginx的反向代理） 保证好APP（无状态）的容量，或快速扩容的预案，以防止流量切过来以后，出现过载,Baidu GateWay Front End,Router,A记录,Baidu GateWay Front End,Router,app1,app1,CNAME（正式域名）,CNAME（正式域名）, CNAME CNAME . A . A 119.75.217.56,核心组件，分布,Router_1,NATS_1,Router,NATS,CC HM Stager,DE
7、A,PG_DB Redis,整体结构（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,新增功能,支持RPC、单实例多端口 单实例开启多个端口，并提供API实时查询IP、端口号 与“名称服务”联动，同步动态ip端口与名称的对应关系 RPC调用方，根据名称直连实例,DEA server
8、,支持RPC、单实例多端口,Instance01:port,Instance02:port,API Bridge,NSserver,TXT记录ip:portip:port,RPC调用方,NS client,Domainip:portip:port,ip_local_port_range 10000 60000,Port池（分配后，有冻结期） 61000 65000,新增功能,支持JMX API实时查询ip与Jconsole端口号，实现JMX数据实时采集,DEA,支持 JMX,Instance01: Jconsole 端口,Instance02: Jconsole 端口,“instances“:
9、 “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 TotalCom
10、pilationTime 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,新增功能,加强健康检查 七层检测 文件句柄数检测,DEA S
11、erver,DEA agent.rb,Health Manger,instance,http可用性,instance,CPU,MEM,DISK,report,加强健康检查,句柄,DEA(v1.0)，逻辑改进,端口管理 问题描述 单DEA多实例，并行的端口分配与启动，没有临界区，有端口竞争的问题 解决方案 借鉴了DEA(v2.0)的逻辑（注：即 DEA_NG，与CF1.0不兼容） 设定 ip_local_port_range 为 1000061000，作为动态端口的范围 将6100165000，作为DEA的调度分配端口 对分配的端口，增加“释放时间、端口号”的数据结构 通过延时释放端口，解决了端
12、口竞争的问题 备注 CF2.0中，已解决此问题，方法同上,DEA(v1.0)，逻辑改进,实例资源信息管理 问题描述 du命令算实例磁盘空间，时间较长，随后执行其他计算命令，信息已不一致 CPU计算的方法，没有考虑主机核数 解决方案 调整相关命令的顺序 CPU利用率计算时，除以核数 备注 CF2.0中，已解决此问题,新增功能（与外围系统联动）,文件持久化 使用MFS（Moose File System） DEA 部署MFS-Client，并 mount /mfs/path，供实例使用 MFS服务端提供HTTP接口，获取数据基于URI的路由，区分APP 监控联动 APP的生命周期，与外部监控
13、系统的API交互，实现监控项的自动增删改开发者工具包 自动化发布（封装vmc） 文件查看,主要改造点汇总（cf v1.0）,基于CentOS的相关改造 使用NATS-Cluster、NATS-Client重试与缓存 支持RPC、单实例多端口 支持动态JMX、Jconsole 加强健康检查 端口管理 实例资源信息管理 外围组件：文件持久化、监控联动、URI路由、开发者工具包,2. 实践与改造（Part2） C/C+，base on cf 2.0,C/C+ Apps，几大核心问题,Container 的运行环境与资源隔离 Kernel/GNU 资源隔离 快照，Core Dump单实例多进程 健康检
14、查 进程运行顺序 实例内，进程间通信 多端口 多实例的同构性,C/C+ Apps，几大核心问题,大实例 实例个数多（10万） 数据量大（单实例，2TB） 内存占用高（单实例，100G） 启动时间长（30分钟） 流量大（单实例，日总PV2亿） 漂移时，防止资源不足APP通信 网络层通信，权限、流量控制 输出文件，需要外部抓取 输入文件，需要外部推送 RPC，非HTTP协议，不包含PATH信息，无法路由,实例的 OS-Level 环境准备,Container的运行环境 Kernel 与宿主机一致 订制Container的文件环境,warden/warden/root/linux/rootfs/se
15、tup.sh,if grep -q -i centos /etc/issue thenexec $(dirname $0)/centos.sh $ fi,Container与宿主机的关系,Warden,Networking，Bridge / NAT / Firewall / FlowControl,DEA,包管理,Buildpack API detect ， 检查 complie，环境准备 目录结构 程序文件，及相关配套程序 启动脚本，保证进程的启动顺序，等等 监控脚本，可以周期性执行，检测整个实例的健康程度 release，发布信息 Procfile，参数传递（如端口号） .profile.
16、d，环境变量,健康检查，改造点,自定义监控脚本 自定义监控脚本，随实例一起发布，周期性改写stat_file文件内容 DEA定期检查stat_file文件,实例,stat_file,monitor.sh,process-1,process-2,DEA,HM,APP的改造,针对RPC，支持NS Client 动态配置文件，代替路由 端口管理，冻结时间 输入输出文件 输入文件，主动抓取 输出文件，推到中转处（如云存储），或基于NS服务 多进程的管理，启动脚本 多进程，启动顺序控制 进程控制 文件持久化 远程日志 使用云存储,整体结构（CF2.0）,DEA,Logging,Name Service,
17、Monitoring,File Persistence,HM,gorouter（RPC，不适用）,CC,Baidu GateWay / Front End,API Bridge,UAA,（Cluster 02）,N A T S,Warden,NS Client,DB,主要改造点汇总（cf v2.0）,基于CentOS的相关改造 Container环境的订制 Buildpack的订制 支持RPC、单实例多端口 加强健康检查 外围组件：文件持久化、监控联动、URI路由、开发者工具包,3. 流程与标准,工作流程，简述,标准与容量，举例,标准信息采集 App相关名称、相关接口人（R&D、QA、运维、相
18、关经理，等） Runtime与容器版本 无状态、RPC、URI路由 动静态文件分离 文件持久化容量信息采集 PV、QPS 单实例 CPU、内存、磁盘、带宽、重启时间 实例数量,SLA，举例,服务对象 Java 应用（以下简称“APP”） 符合标准的APP服务时间 24365全年无休沟通方式 Mail、Tel、接口人信息稳定性相关指标 核心组件，可用性99.99%（每月），MTTR5天 控制服务，可用性99.95%（全年） APP自身SLA，不因平台本身，造成负面影响 注：APP自身问题，不在此SLA范围内，如： 程序bug、容量预估错误、外部系统故障（如DB、Cache）等,组织关系，层级,产
19、品线（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， 且有多个实例,对CC进一步封装,产品线(Org) OrgName 模块(Space) OrgName_SpaceName 模块分组 Org
20、Name_SpaceName_GroupTag 模块版本 OrgName_SpaceName_GroupTag_VersionTag实例（id唯一） OrgName_SpaceName_GroupTag_VersionTag_Index,GroupTag、VersionTag,GroupTag 可以区分：配置文件、机房、机架等维度的不同 VersionTag 可以区分：程序、数据、配置文件等 包含：四位版本号、时间戳实例完整名称，例子 Org_Space_GroupA_1-1-1-1-438249600_1 Org_Space_GroupB_1-1-1-1-438249600_1,审批与发布,
21、发审批单 APP信息（程序版本、容量信息、相关说明，等等） 审批人（相关经理、需知晓的人） 操作者、操作时间 监控信息（监控策略、接口人等）开始发布操作，并添加监控 发布前，对应审批流必须通过 操作人、程序版本、MD5、时间等信息，必须与审批流一致 都一致，且流程通过，则可以开始发布 发布成功后，添加监控,发单,审批,发布APP,监控添加,预发布、发布、回滚,app_v1 instance01,app_,app_v1 instance02,app_v2 instance01,app_v2 instance02,app_v3 instance01,app_v3 instance02,app_,,
22、泛域名、 map/unmap、 app的多版本并存,前进，发布,后退，回滚,预发布，线下内网观察,基本的灰度发布,app_v1 instance01,app_,app_v1 instance02,app_v2 instance01,app_v2 instance02,app_v3 instance01,app_v3 instance02,,1、将一个正式域名，同时指向多个app 2、调整多个app的实例数比例，即调整了流量的比例,,app_v2 instance03,通过调整app实例的数量，灰度流量的分配比例,“布道之道”，平台的推广,军功章，有谁的一半？ APP的支持 新服务，需遵守Paa
23、S的相关标准、思想 老服务，需R&D改造，QA需回归测试 外围的支持 DB、Cache、存储、接入、安全、监控，等等明确收益，建立共赢的生态圈 交付更快、资源更省、事情变得简单 一站式的一体化服务，携手推广,一些方法,给用户（APP开发人员），尊贵的帝王般的享受 对重点的APP，有针对性的重点服务 对重要的管理者，有一套更完整、及时的沟通方式，如报表等 原则是“资本主义”，而不是社会主义事件“营销” 如“struts2 0day” 积极配合R&D、QA做问题排查、修复与实施 积极通报进展，做好事件管理 后期，针对此事，积极推进、参与讨论与决策，如与安全、架构组合作 原则是“共赢”，而不是推卸责
24、任,4. 改变运维,改变运维,“NoOps”,PaaS(and IaaS) 的完整功能 = 传统运维工作,Storage,Servers,Networking,O/S,Middleware,Virtualization,Data,Applications,Runtime,OP(SRE)，运维,PaaS (and IaaS),如何改变，举例,故障自动恢复 在传统监控之上，增加了健康检查机制 实例的自动重启与“漂移” 传统的报警大量减少，人力减少 只有自动恢复失败时，才报警,监控,完整实例名_1 ip:port, ,健康检查,API, ,真实的实例_1 ip:port,漂移后的实例_1,“漂移”是
25、正常现象，无需报警 “漂移”失败，才需报警 监控细化到实例，每次根据名字，探测返回的ip:port,如何改变，举例,更加敏捷 让开发者“忘记服务器”，转而面向资源 有完整的配置管理，与自动化部署功能 发布、预发布、回滚，极其简单，且不需要额外复杂的部署工具 弹性扩展，极其简单 使用Buildpack，实现“云端编译”，并直接运行一体化一站式的体验 从发单、发布，到增删改监控，工作流程全自动 整合第三方服务，统一管理入口,5. 未来计划,未来计划,回馈社区 针对私有云的功能，尽量封装原生组件（基于CF2.0），将新的组件开源 如影响到原生组件的改动，尽量争取merge进主干 编写丰富的文档，以及心得，并积极参与交流开发方向 针对大型应用（大实例）的相关功能 智能调度相关 信息安全 更深入的持续集成 UI,We are hiring !,王炜煜
