Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a DAE 新变化介绍
Semelhante a DAE 新变化介绍 (20)
Mais de Tianwei Liu
DAE 新变化介绍
- 2. 提纲 • DAE 新变化 • DAE 多实例⽀支持 • DAE Scale 策略 • DAE Docker化进程 • DAE 使⽤用中常⻅见问题
- 3. DAE 新变化 • 92 nodes, 20 pool, 385 apps, 104 external apps，处理绝⼤大部分对外流量 • movie/group/sns/music/fm/dongxi/loc… 核⼼心应⽤用迁移到dae环境中 • 多instance ⽀支持 • auto scale 机制 • 优化部署流程 • 增加app/node/pool监控：dae-monitor-agent, bridge • dae 分级上线⽀支持 • 复杂mount point ⽀支持 • 集成⽀支持：PIDL, shuai（应⽤用性能分析）, dpark • staticng 与静态⽂文件改进 • docker 化（47 nodes）
- 4. DAE 功能 http LVS Nginx(lb) gunicorn - sync - async multi-instances Nginx gateway thrift douban service gunicorn sync customized dae_thrift _router pidl pidlproxy- client gunicorn sync customized pidlproxy- server dae api memcache mysql doubandbfs mfs/permdir mq cdn statsd mail/irc auto-scale cron daemon mount point run script nagios waylife logs dae sdk dae test(qaci) shuai auto build make archive autostage0 deploy autodeploy bridge docker container dpark online offline dev dae prelease
- 5. DAE 结构 APP Node Frame- work dae- common dae-sa- tools dae-monitor- agent ossetup dae-daemon daes runtime dae sdk sc dae-mq dae-deploy dae-scale bridgestaticngdae-crondaeqaci
- 6. • dae-mq: beanstalkd mq 队列信息数据 • dae-cron: cron调度，监控，⽇日志与重试操作 • sc： thrift-clients, pidl-clients 下载及关系映射 • daeqaci: 测试驱动与jenkins 执⾏行模板⽣生成 • staticng: 静态⽂文件打包 • bridge: app/node/pool 层⾯面监控展⽰示与API，app常规操作 • dae-scale: 各种scale策略发出者 • dae_deploy: app上线操作与app资源操作的api接⼝口 DAE 结构(续)
- 7. • dae-common：dae通⽤用函数库 • dae-sa-tools: ⾯面向dae sa的操作⼯工具 • dae-monitor-agent: 节点上的监控agent • ossetup: 幂等的, app配置与nginx配置⽣生成器 • dae-daemon: daemon(mq, cron, daemon)的控制器 DAE 结构(续)
- 8. • 以前的部署： 1. 没有daemon，直接⽤用websocket连(dae-admin) 2. 没有存储部署状态和⽇日志 3. 没有将部署分步呈现 4. 没有archive 概念，直接到每台机器上git pull代码 5. 没有应⽤用版本信息，需要⼈人⼯工到机器上看 6. 上线时就出现502 7. 没法紧急终⽌止和回滚 8. 需要⼿手⼯工填写commit，没法看代码状态 9. 没有分级上线 10.… DAE 应⽤用部署流程
- 11. DAE 应⽤用部署流程（续） dae-sdk bridge deploy 常规上线 分级上线 dae_deploy API 检测是否正在部 署及权限检查 部署任务 放⼊入mq队列 部署daemon make archive 1.staticng 2.app.yaml 3.daeqaci 4.prebuild daes binpkg环境 docker 环境 更新snapshot svc -o graceful showdown（21s） dae-ossetup app svc -u docker image build dae-selftest group sleep 15s affiliated nodes: dpark, servant(async) pull image set release image info svc -o graceful showdown（21s） dae-ossetup app svc -u dae-selftest update pidl files external config: lb, nagios, mail, tinydns
- 13. • dae-selftest 500（应⽤用层⾯面） • docker-registry timeout -> build/push failed • sa nginx配置错误, ossetup nginx reload 失败 • tinydns nodes 不稳定，timeout • nagios 挂掉 • node 挂掉 • redarrow TimeLimitError 上线⼜又失败了...
- 14. DAE 分级上线 • 定义：每⽇日安全发布，将某些特定的⽤用户导⼊入到某个节点的 上，不同节点版本不同 • 将上线新版本产⽣生的错误限制在⼀一个较⼩小的⽤用户范围内，防⽌止错误 扩散 • 每个应⽤用独⽴立分级上线 • stage 阶段： • stage0: 最先发布的集群，办公室IP，⼚厂⼯工 • stage1: 固定IP ⼀一定⽐比例的⽤用户导⼊入 • stage2: 全量
- 15. DAE 分级上线 • 解决的问题： • 部署界⾯面 + 部署流程 • 静态⽂文件：根据不同节点的返回不同的版本 • nginx 配置分离：将sa⼿手⼯工写在shire.conf中的分离，由 ossetup模板⽣生成 • nginx 流量分配: split_clients + ossetup 刷nginx配置 • 与auto-scale的冲突 • 详细介绍：http://code.dapps.douban.com/liutianwei/staging- deploy-doc
- 16. DAE 分级上线 • ⺫⽬目前状态： • web http 流量，包括不同instance和api的独⽴立分级上线 • auto-stage deploy 与 auto-rollback • 解决stage node crash的问题 • 分级部署的rollback问题
- 17. DAE 多实例⽀支持 • 提供web多实例⽀支持，让不同的实例拥有相同的代码和 运⾏行权限，但运⾏行空间相互隔离，互不影响。 • 效果：导⼊入这个应⽤用的http请求根据url-instance 配置，导⼊入不同的instance • 实现：loadbalancer 根据url选择不同instance upstream，并设置X-DAE-INSTANCE —> 后端 nginx gateway, 根据X-DAE-APPNAME和X- DAE-APPNAME导⼊入不同的instance的domain socket • 注意：instance和handler的配置不冲突，⼆二者 不能相互取代 • bridge上app resource上查看不同instance的资 源, web-xxx 形式 timeout: 90s graceful timeout: 20s sync mode
- 20. DAE Scale 策略 • 以前： • sa ⼿手⼯工调整shire的workers • dae-sa ⼿手⼯工选节点，增减app的workers • ⺫⽬目前： • app 根据当前服务情况⾃自动scale workers • app ⾃自动增减节点 • ondemand scale
- 21. DAE Scale 策略
- 22. DAE Scale 策略 node/pool 调整 app nworkers调整 ondemand scale调整
- 23. DAE Scale 策略 App resource ⻚页⾯面
- 24. Node DAE Scale 策略流程图 Bridge Scale monitor agent dae-sa-tools host: load,cpu,mem,hw-info,ping… env: puppet,nginx,upgrading,offline… app: mem,pcpu,nworker,busyworkers… docker: daemon,containers,network… redis/mc/statsd storage active data aggregator app api pool api node api resource page graphite scale policy workers bound node offline update time no nworker docker api passive nagios UI config app autoscale elastic pool node ranger ondemand scale spike check scale rps noop busy worker busy worker mark cnt policy operation worker:incr,decr node/pool:add,remove view dae_deploy api redarrow workers change:TTIN, TTOUT pull image/snanpshot -> start ossetup:nginx lb: nginx upstream weight collect:10s data cache api: 60s nagios update time: 600s app scale: 300s node/pool ranger: 600s min scale interval: 60s irc: dae_ranger, dae-scale External Graphite
- 25. DAE Scale 策略 • 再看⼀一下bridge resource ⻚页⾯面
- 26. Ondemand Scale • ondemand scale的使⽤用 • 场景：App定时推送会带来⽤用户短时间内⼤大量访问，QPS迅速提 升，auto-scale调整不够及时，造成应⽤用后端资源不⾜足，出现http 502现象。 • 解决：ondemand_scale api • 请求参数： • ondemand_rps: 预估⾼高峰期的qps • duration_seconds 能handle住⾼高峰期qps的持续时间 • instance: scale instance • 返回结果： • handle_rps: DAE系统能够处理的qps • expected_workers: 预期达到的workers • 建议：建议在推送前的10分钟左右调⽤用该接⼝口，可以以cron的 ⽅方式进⾏行
- 27. • ondemand scale的使⽤用 • 例⼦子：dongxi的API QPS会在20:08由60涨到120左右，所以 ondemand scale为: http://bridge.dapps.douban.com/api/app/dongxi/ ondemand_scale?ondemand_rps=120&duration_seconds=600&instance=api Ondemand Scale
- 28. Ondemand Scale
- 29. DAE Docker化进程 • 什么是docker? • Go语⾔言编写的Container引擎， 对系统资源的利⽤用率很 ⾼高，秒级启动，实现轻型隔离，多个容器间不会相互影 响，⽅方便构建image，⼀一定的⽣生态圈. • 关键词: Container化, cgroup, Linux namespace, Image,COW，fs layer，devicemapper/overlay …
- 30. 为什么选Docker? • 环境差异化： • 问题1：某个app需要某些⾮非Python包，就要在全局安装，并需要 修改daes或shire的binpkg 依赖，运维困难，在未来的升级中困 难重重 • 问题2：不同编程语⾔言：python, go • docker: cow结构，Linux Kernel⼀一致(bootfs)，但上层可不同 (rootfs), fs layer cow 结构
- 31. 为什么选Docker?(续) • 更快速的交付与部署： • 问题：开发, 测试, 线上的环境不⼀一致 • docker：可以⽅方便构建镜像 —>创建container, 整个过程可 ⻅见，使运⾏行环境构建标准化 fusible 构建与运⾏行
- 32. 为什么选Docker?(续) • 轻量容器化技术： • 问题：VM启动速度慢，有额外系统开销，⽐比较重 • docker：基于cgroup和linux namespace的轻量化进程级别 的隔离，秒级启动，接近原⽣生性能，额外开销低 vm container 对⽐比
- 33. 为什么选Docker?(续) • 社区： • 活跃社区，⼀一定的⽣生态圈 • os, monitor, management, • devops, hosting service, • bigdata, config management, • network，security • image-registry….. docker ⽣生态
- 34. • 47 nodes docker (47/92) • 所有对外应⽤用都完全或部分运⾏行在docker环境中 • 完善的docker监控与环境清理 • daes docker image 发布与patch 流程 • 优化docker image build 及daemon性能参数 • 绝⼤大部分dae组件都⽀支持docker环境 DAE Docker化进程
- 35. • os: gentoo • Linux kernel 3.18.10(⽀支持overlayfs) • docker 1.5.0 • storage driver: • direct-lvm devicemapper(少量) • overlayfs on ext4 • docker-registry 0.9.1 Docker 版本选择
- 36. • 定义Image 层次，构建image DAE在如何改造来适应docker gentoo dae_base shire dae_shire_base dae_beta dae_release dae_shire_beta dae_shire_release App1 App2 App3 App4 … AppN-1 AppN root base daes apps
- 37. DAE在如何改造来适应docker • 定义Image 层次，构建image bridge image management
- 38. • 运⾏行container：web-gunicorn, thrift-service, pidl-service, daemon group api run cmd DAE在如何改造来适应docker
- 39. • 监控docker 环境 DAE在如何改造来适应docker sindar5c docker 监控
- 40. • 升级daes镜像与patch image • 定期清理image与container • 重构puppet配置，保证host的最⼩小环境安装 DAE在如何改造来适应docker
- 41. • DAE SDK 和测试环境的Docker化，即开发部署流 程的优化 • 不限于DAE Python，⽀支持其他语⾔言，如golang • 梳理app依赖关系，减少⽆无⽤用依赖，让app image 更轻 DAE Docker化下⼀一步
- 42. DAE FAQ
- 43. App http 502报警 • 直接原因：后端资源不⾜足 • 根本原因： 1. QPS 是否异常 —> 有爬⾍虫或正常流量上升 —> 封禁或scale⾃自愈 2. gunicorn worker 是否阻塞 <— 观察resource或nworker图，看 busyworker_mark_cnt, busyworker, nworker三者关系 1. 查看bridge API Usage⻚页⾯面, 查看基础服务是否变慢 —> mc, beansdb, sqlstore 次数和响应时间 2. 是否502只发⽣生在某些节点 —> load, cpu, mem, tcp timeout 3. shuai 跟踪分析变慢的instance —> 变慢发⽣生在那个阶段 1. 代码⾃自⾝身性能问题 2. http 请求timeout —> 对应⺴⽹网站慢，timeout过⼤大，GET请求，内 部gateway, docker⺴⽹网络坏掉 3. redis 变慢 4. 具体的请求，key和sql语句 4. daemontools log —> worker timeout 5. dae-scale 故障 3. 机器app与其他任务混跑，其他任务跑⻜飞，造成load升⾼高 4. mfs 变化 —> 造成⺴⽹网络拥塞 5. nginx loadbalancer —> 1. 配置错误 2. nginx故障
- 45. • dae_profile: http://bridge.dapps.douban.com/api/node/nain1/?_dae_profile=1 • prof2png: http://prof2png.dapps.douban.com/ • example：http://code.dapps.douban.com/bridge/pull/431/ 性能分析(2) • ?_dae_profile=1 • ?_dae_profile=download • ?_dae_app_server=xxx
- 46. • 需求： • ⼆二级域名：dongxi.douban.com • 挂载到主站某个路径下：www.douban.com/group • 挂载任意⼆二级域名的某个路径下：ypy.douban.com/accounts < — accounts app server • api.douban.com 的挂载 • 定制： • 设置新的log格式，写⼊入不同的位置 • 对location 增加rewrite规则 • 特殊的nginx 配置：静态⽂文件，header等… • 实现：nginx 配置⽅方⾯面可以向ossetup提pr • 详细介绍：http://code.dapps.douban.com/dae/docs/blog/dae- ossetup.html 复杂mountpoint配置
- 47. • 过程： • http://bridge.dapps.douban.com/domain/ • ossetup 仓库daesenv/templates/dae-apps/ <APPNAME>/domains.mako 添加⼆二级域名 • templates/dae-mount-points/external-domain-conf.mako 中检查是否有 include dae-apps/<APPNAME>.conf; 的 字段，若没有则添加 • SA 设置DNS mountpoint配置：⼆二级域名
- 48. • 过程： • app.yaml mount_points 配置 • daesenv/templates/dae-mount-points/external-mount-points-conf.mako 增加upstream和split include • 到对应挂载的app mountpoints ⽂文件，如shire: daesenv/templates/dae- mount-points/shire/mount-points-apps.mako, include 相关url location⽂文 件 mountpoint配置：挂载路径
- 49. • 需求：要跑⼀一个脚本，处理⼀一些数据，运⾏行时间很⻓长 • 问题：daemon 会被杀掉 • app 上线 • daes 例⾏行升级(⼀一周⼀一次) • zk 断连造成daemon restart • 节点故障重启 • 建议： • 拆分成⼩小任务，记录执⾏行过程 • cron 任务会保证意外挂掉的daemon进程，会⽴立即重启执 ⾏行，但不记录断点，从头执⾏行 对⻓长时间运⾏行任务的建议
- 52. 谢谢