基于CloudFoundry的私有云平台

Presentation on theme: "基于CloudFoundry的私有云平台"— Presentation transcript:

1 基于CloudFoundry的私有云平台
@王炜煜，百度运维部 weibo.com/wwy1640

2 内容 背景与目标 实践与改造（Part 1、2） 流程与标准 改变运维 未来计划

3 1. 背景与目标 通过背景与目标，了解为什么会做私有云平台的项目， 解决什么问题，带来什么收益，以及为什么选择CF

4 运维与PaaS PaaS (and IaaS) Applications OP(SRE)，运维 Data Runtime
Middleware O/S Virtualization Servers Storage Networking

5 目标 自动化 标准化 一体化 业务的生命周期管理，如变更、监控、故障处理等 资源利用率、弹性 流程 实例标准
系统环境、runtime、framework 一体化 集成第三方服务，如DB、Cache、log、FS等 与其他系统平台联动

6 Why CloudFoundry ？ 机器管理（下游部门） 自动化 标准化 一体化 自动化 一体化 标准化

7 Why CF ？ 自动化 标准化 一体化 Buildpack，程序实例标准 Container，环境标准

8 2. 实践与改造（Part1） Java，base on cf 1.0

9 Java Apps 产品种类 >100 APP >200 实例>2000 平均单实例10G（内存）
日均总pv > 10亿 APP的开发及测试人员 > 700人 Tomcat5/6/7、jdk1.5/1.6、Standalone

10 开始实施，准备工作 基于CentOS的相关改造 独立部署各个CF组件 OS环境初始化 Ubuntu-cmd to CentOS
拆解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 集群容量评估 实例数量，NATS容量评估 单台DEA承载的实例数（<100），对NATS-Server压力影响不大
单NATS-Server，保守估计可承受330台DEA，单台实例数5~30个 多NATS-Server，可扩展 临界线 330台DEA 延时 （ms） 单DEA实例数 （5 ~ 30个） DEA台数 （10 ~ 340台）

12 NATS-Server1/2, Random list
集群内，组件冗余、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 多集群冗余设计 多个独立的集群，逻辑互不影响 Baidu GateWay Front End Baidu GateWay Front End
第一层切换，修改DNS A记录，对多个域名（CNAME到此A记录），统一切到不同的集群 第二层切换，修改“接入层”（其应用层的功能，可简单理解为nginx的反向代理） 保证好APP（无状态）的容量，或快速扩容的预案，以防止流量切过来以后，出现过载 CNAME（正式域名） CNAME（正式域名） CNAME CNAME A A A记录 Baidu GateWay Front End Baidu GateWay Front End Router Router app1 app1

14 核心组件，分布 Router_1 Router CC HM Stager NATS_1 PG_DB Redis NATS DEA

15 Baidu GateWay / Front End
整体结构（cf1.0） Baidu GateWay / Front End N A T S Router Router（Cluster 02） HM CC UAA Stager DEA DB jvm jvm jvm jvm jvm jvm jvm jvm API Bridge Monitoring Name Service File Persistence Logging

16 新增功能 支持RPC、单实例多端口 单实例开启多个端口，并提供API实时查询IP、端口号

17 支持RPC、单实例多端口 NS server DEA server RPC调用方 NS client API Bridge TXT记录
Instance01:port Instance02:port ip_local_port_range 10000 ~ 60000 Port池（分配后，有冻结期） 61000 ~ 65000 NS client Domain ip:port API Bridge NS server TXT记录 ip:port

18 新增功能 支持JMX API实时查询ip与Jconsole端口号，实现JMX数据实时采集

19 支持 JMX DEA Monitoring Metrics { "instances": [ "index": 0,
Stager： java \ -Dcom.sun.management.jmxremote.port={VCAP_JCONSOLE_PORT} -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false DEA { "instances": [ "index": 0, "state": "RUNNING", "since": , "jconsole_ip": " ", "jconsole_port": 61111 }, "index": 1, "jconsole_port": 62222 } Instance01: Jconsole 端口 Instance02: Jconsole 端口 Monitoring Metrics CpuUseRateDaemonThreadCount MemPool_OldGen_UseRate NonHeapMemoryUsage_used TotalCompilationTime TotalPeakThreadCount TotalStartedThreadCount UnloadedClassCount GC_Major_Frequency GC_Major_Time … …

20 新增功能 加强健康检查 七层检测 文件句柄数检测

21 加强健康检查 Health Manger DEA Server report DEA agent.rb instance instance
http可用性 CPU MEM DISK 句柄 …… instance instance

22 DEA(v1.0)，逻辑改进 端口管理 问题描述 解决方案 备注 单DEA多实例，并行的端口分配与启动，没有临界区，有端口竞争的问题
借鉴了DEA(v2.0)的逻辑（注：即 DEA_NG，与CF1.0不兼容） 设定 ip_local_port_range 为 10000~61000，作为动态端口的范围 将61001~65000，作为DEA的调度分配端口 对分配的端口，增加“[释放时间、端口号]”的数据结构 通过延时释放端口，解决了端口竞争的问题 备注 CF2.0中，已解决此问题，方法同上

23 DEA(v1.0)，逻辑改进 实例资源信息管理 问题描述 解决方案 备注
du命令算实例磁盘空间，时间较长，随后执行其他计算命令，信息已不一致 CPU计算的方法，没有考虑主机核数 解决方案 调整相关命令的顺序 CPU利用率计算时，除以核数 备注 CF2.0中，已解决此问题

24 新增功能（与外围系统联动） 文件持久化 基于URI的路由，区分APP 监控联动 开发者工具包
使用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 主要改造点汇总（cf v1.0） 基于CentOS的相关改造 使用NATS-Cluster、NATS-Client重试与缓存
支持RPC、单实例多端口 支持动态JMX、Jconsole 加强健康检查 端口管理 实例资源信息管理 外围组件：文件持久化、监控联动、URI路由、开发者工具包

26 2. 实践与改造（Part2） C/C++，base on cf 2.0

27 C/C++ Apps，几大核心问题 Container 的运行环境与资源隔离 单实例多进程 Kernel/GNU 资源隔离
快照，Core Dump 单实例多进程 健康检查 进程运行顺序 实例内，进程间通信 多端口 多实例的同构性

28 C/C++ Apps，几大核心问题 大实例 APP通信 实例个数多（10万） 数据量大（单实例，2TB） 内存占用高（单实例，100G）
启动时间长（30分钟） 流量大（单实例，日总PV2亿） 漂移时，防止资源不足 APP通信 网络层通信，权限、流量控制 输出文件，需要外部抓取 输入文件，需要外部推送 RPC，非HTTP协议，不包含PATH信息，无法路由

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 Container与宿主机的关系 DEA Warden Cgroup – CPU / MEM Cgroup – CPU / MEM
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 Networking，Bridge / NAT / Firewall / FlowControl

31 包管理 Buildpack API detect ， 检查 complie，环境准备 release，发布信息
目录结构 程序文件，及相关配套程序 启动脚本，保证进程的启动顺序，等等 监控脚本，可以周期性执行，检测整个实例的健康程度 release，发布信息 Procfile，参数传递（如端口号） .profile.d，环境变量

32 健康检查，改造点 自定义监控脚本 实例 HM DEA stat_file monitor.sh process-1 process-2
比较简单实用的方案 实例 stat_file monitor.sh process-1 process-2

33 APP的改造 针对RPC，支持NS Client 输入输出文件 多进程的管理，启动脚本 文件持久化 远程日志 使用云存储
动态配置文件，代替路由 端口管理，冻结时间 输入输出文件 输入文件，主动抓取 输出文件，推到中转处（如云存储），或基于NS服务 多进程的管理，启动脚本 多进程，启动顺序控制 进程控制 文件持久化 远程日志 使用云存储

34 Baidu GateWay / Front End
整体结构（CF2.0） Baidu GateWay / Front End NS Client （Cluster 02） gorouter（RPC，不适用） N A T S CC UAA HM DEA Container process-1 process-2 Container process-1 process-2 Container process-1 process-2 DB Warden API Bridge Monitoring Name Service File Persistence Logging

35 主要改造点汇总（cf v2.0） 基于CentOS的相关改造 Container环境的订制 Buildpack的订制
支持RPC、单实例多端口 加强健康检查 外围组件：文件持久化、监控联动、URI路由、开发者工具包

36 3. 流程与标准

37 工作流程，简述 评审 接入 流程审批 发布更新 标准 容量 SLA 组织关系 名称信息 运维信息 权限申请 名称申请 发布操作 预发布 灰度
回滚 故障处理 可用性 安全 问题管理

38 标准与容量，举例 标准信息采集 容量信息采集 App相关名称、相关接口人（R&D、QA、运维、相关经理，等） Runtime与容器版本
无状态、RPC、URI路由 动静态文件分离 文件持久化 容量信息采集 PV、QPS 单实例 CPU、内存、磁盘、带宽、重启时间 实例数量

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 组织关系，层级 产品线（Org） 模块（Space） 分组（APP） 版本（APP-*） 产品线-2 产品线-1 （Org） 模块-2
实例，版本-1 （APP-1-1） 实例，版本-2 （APP-1-2） 实例，版本-1 （A-1） 实例，版本-2 （A-2） 分组-2（B） 虚线内， 相当于一个APP， 且有多个实例 实例，版本-1 （APP-2-1） 实例，版本-2 （APP-2-2） 实例，版本-1 （B-1） 实例，版本-2 （B-2）

41 对CC进一步封装 产品线(Org) OrgName 模块(Space) OrgName_SpaceName
模块分组 OrgName_SpaceName_GroupTag 模块版本 OrgName_SpaceName_GroupTag_VersionTag 实例（id唯一） OrgName_SpaceName_GroupTag_VersionTag_Index

42 GroupTag、VersionTag GroupTag VersionTag 实例完整名称，例子
可以区分：配置文件、机房、机架等维度的不同 VersionTag 可以区分：程序、数据、配置文件等 包含：四位版本号、时间戳 实例完整名称，例子 Org_Space_GroupA_ _1 Org_Space_GroupB_ _1

43 审批与发布 发审批单 开始发布操作，并添加监控 发单 审批 发布APP 监控添加 APP信息（程序版本、容量信息、相关说明，等等）
审批人（相关经理、需知晓的人） 操作者、操作时间 监控信息（监控策略、接口人等） 开始发布操作，并添加监控 发布前，对应审批流必须通过 操作人、程序版本、MD5、时间等信息，必须与审批流一致 都一致，且流程通过，则可以开始发布 发布成功后，添加监控 发单 审批 发布APP 监控添加

44 预发布、发布、回滚 app.baidu.com 泛域名、 map/unmap、 app的多版本并存 app_v1 app_v1 app_v2
后退，回滚 app_v1 instance01 app_v1 instance02 app_v1.paas.baidu.com app.baidu.com app_v2 instance01 app_v2 instance02 app_v3 instance01 app_v3 instance02 app_v3.paas.baidu.com 前进，发布 预发布，线下内网观察 泛域名、 map/unmap、 app的多版本并存

45 基本的灰度发布 app.baidu.com app.baidu.com 1、将一个正式域名，同时指向多个app
app_v1 instance01 app_v1 instance02 app_v1.paas.baidu.com app.baidu.com app_v2 instance01 app_v2 instance02 app_v2 instance03 app.baidu.com app_v3 instance01 app_v3 instance02 通过调整app实例的数量，灰度流量的分配比例 1、将一个正式域名，同时指向多个app 2、调整多个app的实例数比例，即调整了流量的比例

46 “布道之道”，平台的推广 军功章，有谁的一半？ 明确收益，建立共赢的生态圈 APP的支持 外围的支持 新服务，需遵守PaaS的相关标准、思想
老服务，需R&D改造，QA需回归测试 外围的支持 DB、Cache、存储、接入、安全、监控，等等 明确收益，建立共赢的生态圈 交付更快、资源更省、事情变得简单 一站式的一体化服务，携手推广

47 一些方法 事件“营销” 给用户（APP开发人员），尊贵的帝王般的享受 如“struts2 0day” 对重点的APP，有针对性的重点服务
对重要的管理者，有一套更完整、及时的沟通方式，如报表等 原则是“资本主义”，而不是社会主义 事件“营销” 如“struts2 0day” 积极配合R&D、QA做问题排查、修复与实施 积极通报进展，做好事件管理 后期，针对此事，积极推进、参与讨论与决策，如与安全、架构组合作 原则是“共赢”，而不是推卸责任

48 4. 改变运维

49 “NoOps” 改变运维 PaaS(and IaaS) 的完整功能 >= 传统运维工作 PaaS (and IaaS)
Applications OP(SRE)，运维 Data Runtime PaaS (and IaaS) Middleware O/S “NoOps” Virtualization Servers Storage PaaS(and IaaS) 的完整功能 >= 传统运维工作 Networking

50 如何改变，举例 故障自动恢复 监控 健康检查 API 在传统监控之上，增加了健康检查机制 实例的自动重启与“漂移”
传统的报警大量减少，人力减少 只有自动恢复失败时，才报警 “漂移”是正常现象，无需报警 “漂移”失败，才需报警 监控细化到实例，每次根据名字，探测返回的ip:port 监控 API 健康检查 完整实例名_1 ip:port 漂移后的实例_1 … … … … 真实的实例_1 ip:port

51 如何改变，举例 更加敏捷 一体化一站式的体验 让开发者“忘记服务器”，转而面向资源 有完整的配置管理，与自动化部署功能
发布、预发布、回滚，极其简单，且不需要额外复杂的部署工具 弹性扩展，极其简单 使用Buildpack，实现“云端编译”，并直接运行 一体化一站式的体验 从发单、发布，到增删改监控，工作流程全自动 整合第三方服务，统一管理入口

52 5. 未来计划

53 未来计划 回馈社区 开发方向 针对私有云的功能，尽量封装原生组件（基于CF2.0），将新的组件开源
如影响到原生组件的改动，尽量争取merge进主干 编写丰富的文档，以及心得，并积极参与交流 开发方向 针对大型应用（大实例）的相关功能 智能调度相关 信息安全 更深入的持续集成 UI

54 We are hiring ! 谢谢 @王炜煜 weibo.com/wwy1640