基于 cloudfoundry 的私有云平台

基于 CloudFoundry的私有云平台

@ 王炜煜，百度运维部

weibo.com/wwy1640

2013-7-19

内容

背景与目标

实践与改造（ Part 1 、 2 ）

流程与标准

改变运维

未来计划

1. 背景与目标

运维与 PaaS

StorageStorage

ServersServers

NetworkingNetworking

O/SO/S

MiddlewareMiddleware

VirtualizationVirtualization

DataData

ApplicationsApplications

RuntimeRuntime

OP(SRE) ，运维OP(SRE) ，运维

PaaS (and IaaS)PaaS (and IaaS)

目标自动化

业务的生命周期管理，如变更、监控、故障处理等资源利用率、弹性

标准化流程实例标准系统环境、 runtime、 framework

一体化集成第三方服务，如 DB、 Cache、 log、 FS等与其他系统平台联动

Why CloudFoundry ？

自动化自动化

标准化标准化一体化一体化

机器管理（下游部门）机器管理（下游部门）

Why CF ？

自动化

一体化标准化

2. 实践与改造（ Part1 ）J ava ， 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-Server1NATS-Server1 NATS-Server2NATS-Server2

NATS-Client(caching message)

NATS-Client(caching message)

NATS-Server1/2, Random list

NATS-Server1/2, Random list

多集群冗余设计• 多个独立的集群，逻辑互不影响

第一层切换，修改 DNS A 记录，对多个域名（ CNAME 到此 A 记录），统一切到不同的集群第二层切换，修改“接入层”（其应用层的功能，可简单理解为 nginx 的反向代理）保证好 APP （无状态）的容量，或快速扩容的预案，以防止流量切过来以后，出现过载

Baidu GateWayFront End

Router

A 记录

Baidu GateWayFront End

Router

app1app1 app1app1

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_1Router_1

NATS_1NATS_1

RouterRouter

NATSNATSCCHM

Stager

CCHM

Stager

DEADEA

PG_DBRedis

PG_DBRedis

整体结构（ cf1.0 ）

DEADEA

LoggingLoggingName ServiceName

ServiceMonitorin

gMonitorin

g

jvmjvm

StagerStager

FilePersisten

ce

FilePersisten

ce

HMHM

RouterRouter

CCCC

Baidu GateWay / Front EndBaidu GateWay / Front End

jvmjvm jvmjvm

API BridgeAPI Bridge

UAAUAA

jvmjvm

jvmjvm jvmjvm jvmjvm jvmjvm

Router （ Cluster 02 ）

NATS

NATS

DB

新增功能

•支持 RPC 、单实例多端口单实例开启多个端口，并提供 API 实时查询 IP 、端口号

与“名称服务”联动，同步动态 ip 端口与名称的对应关系

RPC 调用方，根据名称直连实例

DEA serverDEA server

支持 RPC 、单实例多端口

Instance01:portInstance01:port

Instance02:portInstance02:port


NS server

NS server

TXT 记录 ip:port ip:port

TXT 记录 ip:port ip:port

RPC 调用方

NS clientNS client

Domain ip:port ip:port

Domain ip:port ip:port

ip_local_port_range

10000 ~ 60000

Port 池（分配后，有冻结期）

61000 ~ 65000

新增功能

•支持 JMXAPI 实时查询 ip 与 Jconsole 端口号，实现 JMX 数据实时采集

DEADEA

支持 JMX

Instance01: Jconsole 端口Instance01: Jconsole 端口

Instance02: 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 MetricsMonitoring 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 ServerDEA Server

DEA agent.rbDEA agent.rb

Health MangerHealth Manger

instanceinstance

http 可用性

instanceinstance

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/issuethen exec $(dirname $0)/centos.sh $@fi

Container与宿主机的关系

Warden

Networking ， Bridge / NAT / Firewall / FlowControl 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_filestat_file

monitor.shmonitor.sh

process-1process-1

process-2process-2

DEADEA

HMHM

APP 的改造• 针对 RPC ，支持 NS Client

动态配置文件，代替路由

端口管理，冻结时间

• 输入输出文件输入文件，主动抓取

输出文件，推到中转处（如云存储），或基于 NS 服务

• 多进程的管理，启动脚本多进程，启动顺序控制

进程控制

• 文件持久化远程日志

使用云存储

整体结构（ CF2.0 ）

DEADEA

LoggingLoggingName ServiceName

ServiceMonitorin

gMonitorin

g

FilePersisten

ce

FilePersisten

ce

HMHM

gorouter （ RPC ，不适用）gorouter （ RPC ，不适用）

CCCC

Baidu GateWay / Front EndBaidu GateWay / Front End


UAAUAA

（ Cluster 02 ）

NATS

NATS

ContainerContainer

process-1process-1

process-2process-2

WardenWarden

NS ClientNS Client

ContainerContainer

process-1process-1

process-2process-2

ContainerContainer

process-1process-1

process-2process-2DB

主要改造点汇总（ cf v2.0 ）

• 基于 CentOS 的相关改造

• Container 环境的订制

• Buildpack 的订制

•支持 RPC 、单实例多端口

• 加强健康检查

•外围组件：文件持久化、监控联动、 URI路由、开发者工具包

3. 流程与标准

工作流程，简述

标准与容量，举例•标准信息采集

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产品线 -2

产品线 -1 （ Org ）产品线 -1 （ Org ）

模块 -2模块 -2

模块 -1 （ Space ）模块 -1 （ Space ）

分组 -1 （ A ）分组 -1 （ A ）

分组 -2 （ B ）分组 -2 （ B ）

实例，版本 -1（ APP-1-1 ）实例，版本 -1（ APP-1-1 ）

实例，版本 -2（ APP-1-2 ）实例，版本 -2（ APP-1-2 ）

实例，版本 -1（ APP-2-1 ）实例，版本 -1（ APP-2-1 ）

实例，版本 -2（ APP-2-2 ）实例，版本 -2（ APP-2-2 ）

实例，版本 -1（ A-1 ）

实例，版本 -1（ A-1 ）

实例，版本 -2（ A-2 ）

实例，版本 -2（ A-2 ）

实例，版本 -1（ B-1 ）

实例，版本 -1（ B-1 ）

实例，版本 -2（ B-2 ）

实例，版本 -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

监控添加监控添加

预发布、发布、回滚

app_v1instance01app_v1

instance01app_v1.paas.baidu.comapp_v1.paas.baidu.com app_v1instance02app_v1

instance02


instance01app_v2

instance02app_v2

instance02


instance01app_v3

instance02app_v3

instance02app_v3.paas.baidu.comapp_v3.paas.baidu.com

app.baidu.comapp.baidu.com

泛域名、 map/unmap 、 app 的多版本并存

前进，发布

后退，回滚

预发布，线下内网观察预发布，线下内网观察

基本的灰度发布


instance01app_v1.paas.baidu.comapp_v1.paas.baidu.com app_v1instance02app_v1

instance02


instance01app_v2

instance02app_v2

instance02


instance01app_v3

instance02app_v3

instance02


1 、将一个正式域名，同时指向多个 app2 、调整多个 app 的实例数比例，即调整了流量的比例



instance03

通过调整 app 实例的数量，灰度流量的分配比例

“布道之道”，平台的推广•军功章，有谁的一半？

APP 的支持⁺ 新服务，需遵守 PaaS 的相关标准、思想

⁺ 老服务，需 R&D 改造， QA需回归测试

外围的支持⁺ DB 、 Cache 、存储、接入、安全、监控，等等

•明确收益，建立共赢的生态圈交付更快、资源更省、事情变得简单

一站式的一体化服务，携手推广

一些方法•给用户（ APP 开发人员），尊贵的帝王般的享受

对重点的 APP ，有针对性的重点服务

对重要的管理者，有一套更完整、及时的沟通方式，如报表等

原则是“资本主义”，而不是社会主义

•事件“营销”如“ struts2 0day”

⁺ 积极配合 R&D 、 QA做问题排查、修复与实施

⁺ 积极通报进展，做好事件管理

⁺ 后期，针对此事，积极推进、参与讨论与决策，如与安全、架构组合作

⁺ 原则是“共赢”，而不是推卸责任

4. 改变运维

改变运维

“NoOps”PaaS(and IaaS) 的完整功能 >= 传统运维工作

StorageStorage

ServersServers

NetworkingNetworking

O/SO/S

MiddlewareMiddleware

VirtualizationVirtualization

DataData

ApplicationsApplications

RuntimeRuntime

OP(SRE) ，运维OP(SRE) ，运维

PaaS (and IaaS)PaaS (and IaaS)

如何改变，举例•故障自动恢复

在传统监控之上，增加了健康检查机制

实例的自动重启与“漂移”

传统的报警大量减少，人力减少⁺ 只有自动恢复失败时，才报警

监控

完整实例名 _1ip:port

… …

健康检查

API

… …

真实的实例 _1ip:port

漂移后的实例 _1

• “漂移”是正常现象，无需报警

• “漂移”失败，才需报警

• 监控细化到实例，每次根据名字，探测返回的 ip:port

如何改变，举例

•更加敏捷让开发者“忘记服务器”，转而面向资源

有完整的配置管理，与自动化部署功能

发布、预发布、回滚，极其简单，且不需要额外复杂的部署工具

弹性扩展，极其简单

使用 Buildpack ，实现“云端编译”，并直接运行

•一体化一站式的体验从发单、发布，到增删改监控，工作流程全自动

整合第三方服务，统一管理入口

5. 未来计划

未来计划• 回馈社区

• 针对私有云的功能，尽量封装原生组件（基于 CF2.0 ），将新的组件开源

• 如影响到原生组件的改动，尽量争取merge进主干

• 编写丰富的文档，以及心得，并积极参与交流

• 开发方向• 针对大型应用（大实例）的相关功能

• 智能调度相关

• 信息安全

• 更深入的持续集成

• UI

We are hiring !

@ 王炜煜weibo.com/wwy1640

谢谢

基于 cloudfoundry 的私有云平台

Documents