1 / 54

基于 CloudFoundry 的私有云平台

基于 CloudFoundry 的私有云平台. @ 王炜煜，百度运维部 weibo.com/wwy1640 2013-7-19. 内容. 背景与目标 实践与改造 （ Part 1 、 2 ） 流程与标准 改变运维 未来计划. 1. 背景与目标. 运维与 PaaS. Applications. OP(SRE) ，运维. Data. Runtime. PaaS ( and IaaS ). Middleware. O/S. Virtualization. Servers. Storage. Networking. 目标. 自动化

tanisha-gilliam
Download Presentation

基于 CloudFoundry 的私有云平台

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  3. 1. 背景与目标

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

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

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

  7. Why CF ？ 自动化 标准化 一体化

  8. 2. 实践与改造（Part1） Java，baseoncf1.0

  9. JavaApps • 产品种类 >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

  11. 集群容量评估 • 实例数量，NATS容量评估 • 单台DEA承载的实例数（<100），对NATS-Server压力影响不大 • 单NATS-Server，保守估计可承受330台DEA，单台实例数5~30个 • 多NATS-Server，可扩展 临界线 330台DEA 延时 （ms） 单DEA实例数 （5~30个） DEA台数 （10~340台）

  12. 集群内，组件冗余、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. 多集群冗余设计 • 多个独立的集群，逻辑互不影响 • 第一层切换，修改DNSA记录，对多个域名（CNAME到此A记录），统一切到不同的集群 • 第二层切换，修改“接入层”（其应用层的功能，可简单理解为nginx的反向代理） • 保证好APP（无状态）的容量，或快速扩容的预案，以防止流量切过来以后，出现过载 CNAME（正式域名） CNAME（正式域名） www.baidu.comCNAMEwww.a.shifen.com. www.baidu.cnCNAMEwww.a.shifen.com. www.a.shifen.com.A119.75.218.77 www.a.shifen.com.A119.75.217.56 A记录 BaiduGateWay FrontEnd BaiduGateWay FrontEnd Router Router app1 app1

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

  15. 整体结构（cf1.0） BaiduGateWay / FrontEnd N A T S Router Router（Cluster 02） HM CC UAA Stager DEA DB jvm jvm jvm jvm jvm jvm jvm jvm APIBridge Monitoring NameService File Persistence Logging

  16. 新增功能 • 支持RPC、单实例多端口 • 单实例开启多个端口，并提供API实时查询IP、端口号 • 与“名称服务”联动，同步动态ip端口与名称的对应关系 • RPC调用方，根据名称直连实例

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

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

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

  26. 2. 实践与改造（Part2） C/C++，baseoncf2.0

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

  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与宿主机的关系 DEA Warden Cgroup – CPU / MEM Cgroup – CPU / MEM Name space Name space mount r usr/ lib/ etc/ mount rw xxx/ init─┬─xxx ├─xxx─xxx ├─xxx mount r usr/ lib/ etc/ mount rw xxx/ init─┬─xxx ├─xxx─xxx ├─xxx network interface（sub net） network interface（sub net） Networking，Bridge / NAT / Firewall / FlowControl

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

  32. 健康检查，改造点 • 自定义监控脚本 • 自定义监控脚本，随实例一起发布，周期性改写stat_file文件内容 • DEA定期检查stat_file文件 HM DEA 实例 stat_file monitor.sh process-1 process-2

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

  34. 整体结构（CF2.0） BaiduGateWay / FrontEnd NS Client （Cluster 02） gorouter（RPC，不适用） N A T S CC UAA HM DEA Container Container Container DB process-1 process-1 process-1 process-2 process-2 process-2 Warden APIBridge Monitoring NameService File Persistence Logging

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

  36. 3. 流程与标准

  37. 工作流程，简述

  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. 组织关系，层级 产品线-2 • 产品线（Org） • 模块（Space） • 分组（APP） • 版本（APP-*） 产品线-1（Org） 模块-2 模块-1 （Space） 分组-1（A） 实例，版本-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 • 可以区分：程序、数据、配置文件等 • 包含：四位版本号、时间戳 • 实例完整名称，例子 • Org_Space_GroupA_1-1-1-1-438249600_1 • Org_Space_GroupB_1-1-1-1-438249600_1

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

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

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

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

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

  48. 4. 改变运维

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

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

More Related