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

谢谢