Baidu Cloud Foundry
-
Upload
james-watters -
Category
Documents
-
view
2.855 -
download
2
description
Transcript of Baidu Cloud Foundry
基于CloudFoundry的私有云平台
@王炜煜,百度运维部 weibo.com/wwy1640 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、Cache、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 改为 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
集群容量评估 �
• 实例数量,NATS容量评估 ü 单台DEA承载的实例数(<100),对NATS-Server压力影响不大
ü 单NATS-Server,保守估计可承受330台DEA,单台实例数5~30个
ü 多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 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
核心组件,分布 �
Router_1
NATS_1
Router
NATS CC HM
Stager
DEA
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
支持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
新增功能 �
• 支持JMX ü API实时查询ip与Jconsole端口号,实现JMX数据实时采集
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
新增功能 �
• 加强健康检查 ü 七层检测
ü 文件句柄数检测
DEA Server 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 为 10000~61000,作为动态端口的范围
⁺ 将61001~65000,作为DEA的调度分配端口
⁺ 对分配的端口,增加“[释放时间、端口号]”的数据结构
⁺ 通过延时释放端口,解决了端口竞争的问题
ü 备注 ⁺ CF2.0中,已解决此问题,方法同上
DEA(v1.0),逻辑改进 �
• 实例资源信息管理
ü 问题描述
⁺ du命令算实例磁盘空间,时间较⻓长,随后执行其他计算命令,信息已不一致
⁺ CPU计算的方法,没有考虑主机核数
ü 解决方案
⁺ 调整相关命令的顺序
⁺ CPU利用率计算时,除以核数
ü 备注
⁺ CF2.0中,已解决此问题
新增功能(与外围系统联动) �
• 文件持久化 ü 使用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)
ü 文件查看
主要改造点汇总(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
• 单实例多进程 ü 健康检查
ü 进程运行顺序
ü 实例内,进程间通信
ü 多端口
ü 多实例的同构性
C/C++ Apps,几大核心问题 �
• 大实例 ü 实例个数多(10万)
ü 数据量大(单实例,2TB)
ü 内存占用高(单实例,100G)
ü 启动时间⻓长(30分钟)
ü 流量大(单实例,日总PV2亿)
ü 漂移时,防止资源不足
• APP通信 ü 网络层通信,权限、流量控制
ü 输出文件,需要外部抓取
ü 输入文件,需要外部推送
ü RPC,非HTTP协议,不包含PATH信息,无法路由
实例的 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
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
包管理 �
• Buildpack API ü detect , 检查
ü complie,环境准备
⁺ 目录结构
⁺ 程序文件,及相关配套程序
⁺ 启动脚本,保证进程的启动顺序,等等
⁺ 监控脚本,可以周期性执行,检测整个实例的健康程度
ü release,发布信息
ü Procfile,参数传递(如端口号)
ü .profile.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 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
主要改造点汇总(cf v2.0) �
• 基于CentOS的相关改造
• Container环境的订制
• Buildpack的订制
• 支持RPC、单实例多端口
• 加强健康检查
• 外围组件:文件持久化、监控联动、URI路由、开发者工具包
3. 流程与标准
工作流程,简述 �
评审 • 标准 • 容量 • SLA
接入 • 组织关系 • 名称信息 • 运维信息
流程审批 • 权限申请 • 名称申请 • 发布操作
发布更新 • 预发布 • 灰度 • 回滚
故障处理 • 可用性 • 安全 • 问题管理
标准与容量,举例 �• 标准信息采集
ü App相关名称、相关接口人(R&D、QA、运维、相关经理,等)
ü Runtime与容器版本
ü 无状态、RPC、URI路由
ü 动静态文件分离
ü 文件持久化
• 容量信息采集 ü PV、QPS
ü 单实例 CPU、内存、磁盘、带宽、重启时间
ü 实例数量
SLA,举例 �• 服务对象
ü Java 应用(以下简称“APP”) ü 符合标准的APP
• 服务时间 ü 24×365全年无休
• 沟通方式 ü Mail、Tel、接口人信息
• 稳定性相关指标 ü 核心组件,可用性>99.99%(每月),MTTR<20分钟,MTBF>5天 ü 控制服务,可用性>99.95%(全年) ü APP自身SLA,不因平台本身,造成负面影响
ü 注:APP自身问题,不在此SLA范围内,如: 程序bug、容量预估错误、外部系统故障(如DB、Cache)等
组织关系,层级 �
• 产品线(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
模块分组 OrgName_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
审批与发布 �
• 发审批单 ü APP信息(程序版本、容量信息、相关说明,等等)
ü 审批人(相关经理、需知晓的人)
ü 操作者、操作时间
ü 监控信息(监控策略、接口人等)
• 开始发布操作,并添加监控 ü 发布前,对应审批流必须通过
ü 操作人、程序版本、MD5、时间等信息,必须与审批流一致
ü 都一致,且流程通过,则可以开始发布
ü 发布成功后,添加监控
发单
审批
发布APP
监控添加
预发布、发布、回滚 �
app_v1 instance01 app_v1.paas.baidu.com
app_v1 instance02
app_v2 instance01
app_v2 instance02
app_v3 instance01
app_v3 instance02 app_v3.paas.baidu.com
app.baidu.com
泛域名、 map/unmap、 app的多版本并存
前进,发布
后退,回滚
预发布,线下内网观察
基本的灰度发布 �
app_v1 instance01 app_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实例的数量,灰度流量的分配比例
“布道之道”,平台的推广 �
• 军功章,有谁的一半? ü APP的支持
⁺ 新服务,需遵守PaaS的相关标准、思想
⁺ 老服务,需R&D改造,QA需回归测试
ü 外围的支持 ⁺ DB、Cache、存储、接入、安全、监控,等等
• 明确收益,建立共赢的生态圈 ü 交付更快、资源更省、事情变得简单
ü 一站式的一体化服务,携手推广
一些方法 �
• 给用户(APP开发人员),尊贵的帝王般的享受 ü 对重点的APP,有针对性的重点服务
ü 对重要的管理者,有一套更完整、及时的沟通方式,如报表等
ü 原则是“资本主义”,而不是社会主义
• 事件“营销” ü 如“struts2 0day”
⁺ 积极配合R&D、QA做问题排查、修复与实施
⁺ 积极通报进展,做好事件管理
⁺ 后期,针对此事,积极推进、参与讨论与决策,如与安全、架构组合作
⁺ 原则是“共赢”,而不是推卸责任
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
• “漂移”是正常现象,无需报警
• “漂移”失败,才需报警
• 监控细化到实例,每次根据名字,探测返回的ip:port
如何改变,举例 �
• 更加敏捷 ü 让开发者“忘记服务器”,转而面向资源
ü 有完整的配置管理,与自动化部署功能
ü 发布、预发布、回滚,极其简单,且不需要额外复杂的部署工具
ü 弹性扩展,极其简单
ü 使用Buildpack,实现“云端编译”,并直接运行
• 一体化一站式的体验 ü 从发单、发布,到增删改监控,工作流程全自动
ü 整合第三方服务,统一管理入口
5. 未来计划
未来计划 �
• 回馈社区 • 针对私有云的功能,尽量封装原生组件(基于CF2.0),将新的组件开源
• 如影响到原生组件的改动,尽量争取merge进主干
• 编写丰富的文档,以及心得,并积极参与交流
• 开发方向 • 针对大型应用(大实例)的相关功能
• 智能调度相关
• 信息安全
• 更深入的持续集成
• UI
We are hiring !
@王炜煜 weibo.com/wwy1640
谢谢