More Related Content Similar to Baidu Cloud Foundry (20) More from James Watters (14) Baidu Cloud Foundry9. Java Apps
• 产品 类 >100
• APP >200
• 实例>2000
• 平均单实例10G(内存)
• 日均总pv > 10亿
• APP的 发及测试人员 > 700人
• Tomcat5/6/7、jdk1.5/1.6、Standalone
10. 开始实施,准备工作
• 基于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
13. 多集群冗余设计
• 多个独立的集群,逻辑互不影响
ü 第一层切换,修改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
19. 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
22. DEA(v1.0),逻辑改进
• 端口管理
ü 问题描述
⁺ 单DEA多实例,并行的端口分配与启动,没有临界区,有端口竞争的问题
ü 解决方案
⁺ 借鉴了DEA(v2.0)的逻辑(注:即 DEA_NG,与CF1.0不兼容)
⁺ 设定 ip_local_port_range 为 10000~61000,作为动态端口的范围
⁺ 将61001~65000,作为DEA的调度分配端口
⁺ 对分配的端口,增加“[释放时间、端口号]”的数据结构
⁺ 通过延时释放端口,解决了端口竞争的问题
ü 备注
⁺ CF2.0中,已解决此问题,方法同上
24. 新增功能(与外围系统联动)
• 文件持久化
ü 使用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路由、 发者工具包
28. C/C++ Apps,几大核心问题
• 大实例
ü 实例个数多(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与宿主机的关系
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
31. 包管理
• Buildpack API
ü detect , 检查
ü complie,环境准备
⁺ 目录结构
⁺ 程序文件,及相 配套程序
⁺ 启动脚本,保证进程的启动顺序,等等
⁺ 监控脚本,可以周期性执行,检测整个实例的健康程度
ü release,发布信息
ü Procfile,参数传递(如端口号)
ü .profile.d,环境变量
33. APP的改造
• 针对RPC,支持NS Client
ü 动态配置文件,代替路由
ü 端口管理,冻结时间
• 输入输出文件
ü 输入文件,主动抓取
ü 输出文件,推到中转处(如云存储),或基于NS服务
• 多进程的管理,启动脚本
ü 多进程,启动顺序控制
ü 进程控制
• 文件持久化
ü 远程日志
ü 使用云存储
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)等
43. 审批与发布
• 发审批单
ü APP信息(程序版本、容量信息、相 说明,等等)
ü 审批人(相 经理、需知晓的人)
ü 操作者、操作时间
ü 监控信息(监控策略、接口人等)
• 始发布操作,并添加监控
ü 发布前,对应审批流必须通过
ü 操作人、程序版本、MD5、时间等信息,必须与审批流一致
ü 都一致,且流程通过,则可以 始发布
ü 发布成功后,添加监控
发单
审批
发布APP
监控添加
47. 一些方法
• 给用户(APP 发人员),尊贵的帝王般的享受
ü 对重点的APP,有针对性的重点服务
ü 对重要的管理者,有一套更完整、及时的沟通方式,如报表等
ü 原则是“资本主义”,而不是社会主义
• 事件“营销”
ü 如“struts2 0day”
⁺ 积 配合R&D、QA做问题排查、修 与实施
⁺ 积 通报进展,做好事件管理
⁺ 后期,针对此事,积 推进、参与讨论与决策,如与安全、架构组合作
⁺ 原则是“共赢”,而不是推卸责任
51. 如何改变,举例
• 更加敏捷
ü 让 发者“忘记服务器”,转而面向资源
ü 有完整的配置管理,与自动化部署功能
ü 发布、预发布、回 , 其简单,且不需要额外 杂的部署工具
ü 弹性扩展, 其简单
ü 使用Buildpack,实现“云端编译”,并直接运行
• 一体化一站式的体验
ü 从发单、发布,到增删改监控,工作流程全自动
ü 整合第三方服务,统一管理入口