标签：目的 编写 conf 调试 tac show enc 性能测试 container
| 编号 | 项目 | 部署场景 | 当前状况 | 后期计划 | ETA用户 | 版本集成团队 | Dev团队 | RT团队 |
|---|---|---|---|---|---|---|---|---|
| 1 | UME |
项目日常开发、测试场景(基于TECS)
|
1、IaaS/TECS环境 Daisy/Provider/提供TECS环境的自动搭建及维护、物理（硬件）资源管理、虚拟资源管理 Director提供跨地域资源统一监控（可视化），但功能无法完全满足中心要求，目前正在开发RMS资源管理系统。 2、PaaS/UME环境 目前提供基于Jenkins任务的自动化环境部署脚本进行PaaS环境部署 PaaS功能服务及UME网管自动部署，需要等OKI版本发布后进行该部分自动化脚本编写及调试。 3、Gbase虚机模板 目前Gbase v8.0脚本有问题，正在跟厂家支持人员进行沟通。
|
1) 基于HP刀片、自研刀片给出模板，自动安装。 2）6月份底完成RMS基本功能，通过RMS调度Jenkins任务。 3)GBASE , 后续由Gbase团队/资源团队负责Gbase虚机镜像的发布和更新。 |
独占 | 固定 | 合租或者独占 | |
| 2 | UME |
性能测试
|
同上 PS：UME规模与Gbase部署形态的说明 性能测试环境中小区数量小于2万的环境Gbase部署在虚拟机中，小区数量超过2万（含2万）的环境Gbase部署在物理刀片上。 手工部署大容量测试环境。 |
不同规模的配置需要资源情况与项目明确，定制自动化调度。Q3启动自动化。 | 独占 | / | / | 独占 |
| 3 | UME |
项目日常开发、测试场景(基于裸机)
|
环境都是手工部署，还不能自动部署。完全自动部署存在比较大问题。裸机类型目前分为HP、自研E9000。HP部署PaaS在5.8验证完成。E9000还没有开展 | 暂时没有脚本方案。计划和朱立峰、危达讨论OKI的部署方案。5月底之前讨论清楚项目需求之后再确定启动时间。 | / | 固定 | 独占和合租 | 独占 |
| 4 | UME |
大容量测试
|
关于裸设备的使用与磁阵划分有比较大关系，大容量磁阵规划需要项目明确，暂时启动不了。 | 等项目明确需求之后再启动。 | / | / | / | / |
| 5 | EMS |
项目日常开发测试场景(基于TECS)  |
UniRan项目：目前由唐蕾团队完成日常场景部署，当前存在问题是ZDC支持裸设备在虚机使用中不具备重复性，虚拟机一旦重新部署，裸设备需要重新手工挂载，目前还没有找到解决办法。 LTE项目：目前虚拟机由资源团队统一管理和维护，包含虚拟化环境本身、模板等，团队根据需要申请所需的虚机。
|
8月份启动，9月底能够完成对UniRan项目的支持。 | 独占 | 固定 | 独占或者合租 | 独占或者合租 |
| 6 | EMS |
项目日常开发测试场景(基于Redhat操作系统）
|
UniRan项目：刀片的环境是分配到各个开发团队。开发2框刀片，1框HP刀片是（借用的），自研刀片(无磁阵) LTE项目：目前虚拟机由资源团队统一管理和维护，包含虚拟化环境本身、模板等，团队根据需要申请所需的虚机。 |
UniRan资源管理和项目沟通清楚，明确管理方法,.530给出结果。 | / | 固定 | 独占或者合租 | 独占或者合租 |
| 7 | EMS |
大容量测试（基于Redhat操作系统）
|
后端测试团队负责。关于自动部署大容量环境的的脚本，RT测试团队+ETA+资源团队正在开发中。GUL 10万小区场景测试中OMMR已经完成，通过脚本调用实现批量生成OMMR环境。整体部署计划10月底完成 开发规划及进展：6-测试环境自动化部署 |
按照计划执行 | / | / | / | 独占 |
| 8 | UME |
商用故障复现场景  |
只是考虑规划，暂时没有此场景 | / | / | / | / | |
| 9 | UME |
商用故障复现场景
|
只是考虑规划，暂时没有此场景 | / | / | / | / |
| 事项 | 发起者 | 业务流 | 当前状况 | 后期计划 | 创建环境机制 |
|---|---|---|---|---|---|
| 资源申请和调度流程 | ETA用户申请 |
 |
由ETA团队申请，资源团队手工部署。 | 6月底完成自动化部署对接，支持自动申请，自动分配。 | 中心私有云内部资源，通过自动调度创建策略，通过脚本创建资源。。 |
| Dev团队/RT团队//前后台联调(后台提供环境) |
 |
团队邮件或者电话申请，资源团队手工执行脚本自动部署 | 6月底自动完成 | ||
| 版本集成/showCase |
 |
版本集成团队固定使用环境。 | 固定使用 | ||
| 前后台联调环境流程 | 前后台联调（前台提供环境） | 邮件、电话通知，由资源团队负责安装PaaS，以及UME依赖的公共组件。 团队特殊依赖的组件或者包由团队自己负责安装。开发联调版本如何获取，需要项目明确管理规范。 | 通过脚本自动部署 | 通过RMS调用资源创建脚本，自动完成资源创建 | 外部资源通过手工输入资源访问的参数，通过用户发起资源创建。 |
| 技术部云资源调度 | ETA用户申请 | 技术部资源通过管理员输入访问资源TECS的租户、密码、IP，安装PaaS的版本 | 通过RMS调用资源创建脚本，自动完成资源创建 | 资源创建策略自动调度脚本创建。 | |
| PaaS新版本到资源发布流程 | 资源团队 |
 |
使用正式PaaS版本。
|
根据UME项目规划，跟踪PaaS版本发布和自动安装脚本的更新。 |
| 人力 | 地域 | 工作量 | 当前任务 | 备注 |
|---|---|---|---|---|
| 王庆帅 | 西安 | 100% | PaaS自动部署脚本编写及团队测试环境提供、维护；UME裸设备方案及文档支撑 | |
| 何长久 | 西安 | 100% | PaaS裸设备部署方案验证、文档输出 | |
| 郭学彬 | 上海 | 100% | RMS整体框架设计和需求澄清；外部任务承接和分配 | |
| 顾谊 | 上海 | 100% | RMS系统开发 | |
| 石勇 | 上海 | 50% | 上海环境维护 | 5月7号开始投入 |
| 苏高波 | 西安 | 100% | RMS系统开发 | 5月8号开始投入 |
| 周亚新 | 西安 | 100% | RMS系统开发 | 5月8号开始投入 |
| 刘泉 | 深圳 | 80% | 深圳的资源维护 |
| UME使用场景 | director能力 | 优点 | 缺点 |
|---|---|---|---|
| 资源汇总管理 | director按照数据中心进行数据汇总，按照云环境汇总。云环境会有多个，对于多个云环境数据汇总不支持。 | director可以把下级的不同类型资源（刀片、存储）屏蔽掉。支持环境的监控。 | 把三地资源数据汇总，director不支持。对于IBM v3700存储暂时还不支持管理(已经提需求给虚拟化，并且提供了脚本) |
| 资源租用，可能有合租，可能有独占 | director的资源是按照vDC分配到组织，再有组织派生出部门，由部门自由分配vDC，vDC内部如何使用由部门决定。但是vDC反复删除和建立，导致director不稳定，会有功能不可用的现象，象云环境数据获取不到、vDC数据获取不到现象在使用过程中出现过4次以上。和虚拟化中心沟通结果是vDC一旦创建好之后，主要操作vDC内部的虚机，尽量不要再删除vDC。 | 由director上组织对应使用场景，可以有多团队共用1套环境。 | 不能直观看到环境有哪些团队在使用，不能频繁删除vDC。另外director不稳定，基本上2周内会崩溃1次。 |
| 资源申请简单 | 对PaaS环境发布管理支持不完善，需要人工介入安装操作；接口不便于通过脚本发布PaaS环境；不支持用户直接申请资源 | director可以统一管理资源 | 不能够满足资源申请不同用户需求 |
5）RMS系统与云测试差异
| 编号 | 云测试系统 | RMS工具 | 备注 |
|---|---|---|---|
| 1 | 规划图形界面支持PaaS环境的创建，对自动创建策略还不支持。 | 环境是自动创建的，根据预先定义的策略进行环境创建和回收。 | |
| 2 | 规划用户自己负责创建环境，用户自己管理的环境。创建环境时间长度与具体应用有一定关系，比如创建PaaS环境，用户输入paas依赖的蓝图等7、8个参数，然后可能等待3个小时之后的创建结果。环境可以根据用户需求灵活定制。 | 用户申请，只需PaaS版本、租用时长即可，系统根据用户类型提供环境。理论上几秒就提供出相应的环境。环境是提前定制好的，不用用户关心。 | |
| 3 | 可以指定测试用例，在创建环境上运行测试用例，系统的主要目的是测试。测试串行，不可以并行测试。 | 主要目的是支持团队开发、ETA的流水线以及RT测试的环境需求。测试由用户控制，可以并行测试。 | |
| 4 | 图形界面，REST接口，通用接口，暂时不确定BDT调用逻辑是否复杂。 | 团队可以由界面输入获取环境，由REST访问提供给ETA团队BDT接口用于流水线 | |
| 5 | 无租约概念 | 有租约要求的 | |
| 6 | 在6月30日之前看不到具体实现 | 计划在6.30前完成第一阶段对UME资源支持，7月份会优化资源创建和回收策略。 |
标签：目的 编写 conf 调试 tac show enc 性能测试 container
原文地址：http://www.cnblogs.com/onetwo/p/7895670.html
