AutoSwitch 灾备切换软件技术方案

AutoSwitch 灾备切换软件技术方案 13.3技术方案 13.3.1需求分析 1、框架要求 1）支持多平台/多厂商环境。所管理的切换受控端可以分布于所有主流操作系统平台。支持以下操作系统（包括且不仅限于AIX、 HP-UX、Solaris、Linux和Windows Server等）。 2）所管理的切换受控端支持代理Agent和非代理Agentless两种方式对业务主机（应用中间件和数据库主机）、存储管理、DNS设备进行交互操作。 2、功能需求 1）切换流程的创建和修改：支持图形可视化创建及修改流程。可按模板进行流程创建，提供版本管理、发布管理功能。支持批量创建流程、支持模板创建流程。 2）切换流程的执行：支持并发执行流程，可同时启动后台多个自动流程执行。支持灵活的流程执行模式，在同一流程中提供正常执行（按预定义）、全自动执行（人工转自动）及人工执行（自动转人工）三种模式能灵活根据实际要求在多种模式之间进行自然切换。 3）报表功能：提供内容包括但不局限于流程执行、用户信息、故障信息等的报表系统，并具有报表导出功能，能够以网页或EXCEL等文件方式将报表导出并保存。 4）审计功能：所有的操作要有详细的审计记录（包括命令行和图形的操作记录及作业记录）。能够显示各主要模块的运行状态，具有系统日志审计功能。 5）演练和分析功能：支持在不影响生产的情况下及时演练、发现问题、保证灾备系统的可用性，能够根据演练中的问题进行分析，不断优化演练技术流程。 3、非功能需求 1）扩展性：通过界面配置即可完成新功能扩展。具备灵活的横向扩展，从技术上来说，主控端可以无限制支持增加的受控端。 2）可靠性：支持本地高可用方式部署。软件本身具备数据同步功能，当一方发生灾难时，另一方能立即在线进行接管控制，保证了平台7*24正常运行。 3）易用性：采用单一用户数据库权限系统，用户无需多次登录；能够从单一Web入口进入灾备自动切换控制台，无需人工逐一登录各主机进行操作。故障处理与反馈提示均要友好且准确。 4、性能要求

1）在主机上运行时要满足资源消耗小、执行效率高的特点。受控端主机上的Agent程序对内存、CPU占用不能影响主机上业务的正常运行(要求内存占用30MB、CPU占用2%以下)。 2）每分钟可以执行100到200个及以上切换流程。 3）可以同时支持100用户并发支持切换流程，响应时间值在5秒到2秒及以下。 5、管理要求 1）提供良好的人机界面，方便定义切换和管理流程；通过图形界面方式实时展示切换信息，直观展示流程中各步骤的顺序关系； 2）支持对所有Agent进行状态监控，保证流程可顺利执行。支持对系统登录状态进行记录，支持监控和管理工作负载异常，通过操作控制台创建生产运行时报告，帮助分析。在流程执行界面中嵌入滚动日志，直观显示流程执行状态。 3）支持人工处理环节，对于必须人工执行或判断的环节，由人工做出判断后，决定流程是否继续执行或终止；可以根据图标颜色变化准确定位故障或人工处理需求的发生位置，并根据图标链接页面查询到该步骤的人工处理方案。 6、安全要求 1）支持对系统用户按角色或者角色组进行授权；支持对系统功能提供角色级别的权限控制。 2）支持https的系统访问，保证管理端和被管端通讯信息安全加密； 3）具备数据加密认证功能，在网络传输中，数据可以进行SSL加密和认证。 4）提供防火墙支持机制。 7、存在问题 灾备中心建设投入了大量人力、物力，但灾备切换还停留在手工阶段，灾难来临时灾备中心能否在规定的RTO内完成切换、及时保障生产、发挥应有作用，还有很大的隐忧。主要原因有如下几个方面： 1）手工切换时间过长、难以达到RTO目标 由于流程的繁琐、复杂，导致手工切换至少需要很长时间才能完成灾备切换，往往不能在规定的RTO内完成切换，实现保障业务连续性的目标。 2）手工切换人为因素过多、切换经常失败 手工流程繁琐、复杂，执行起来往往比较吃力，命令很多、时间较紧，操作员精神压力大导致手忙脚乱，人为出错的几率也就增大，实际操作中由于这样那样的原因往往导致切换失败，无法保证一次切换成功。 3）缺乏演练、关键时刻不能发挥作用 由于业务发展的需要、应用经常升级，有关配置、系统环境也随之需要做相应变化，但受限于保障生产的要求，无法及时演练，导致不能尽快发现问题、灾备中心关键时刻能否发挥作用存在很大隐忧。 总之，灾备切换依靠手工完成，不仅效率低，而且切换时间长，由于人为干预过多导致切换的成功率无法保证；公司的IT运维水平和故障应急处理能力难以提升、难以保障IT服务的持续性和主动规避不可预见的风险。

13.3.2技术架构 AutoSwitch分为四大部分： 1、管理中心： 管理中心部署在灾备服务器端的控制中心上，分别位于各个生产中心及灾备中心等地点。操作人员通过浏览器以WEB方式AutoSwitch管理界面，实现对于灾备系统各业务流程的集中控制和管理。

2、流程调度和控制中心： 通常调度和控制中心部署在灾备服务器端的控制中心上，也可以部署到前置机上。调度和控制中心通过前置机进行流程的调度与管理。 3、前置机 如并发用户数不多于100个时，没有必要设置前置机。 前置机的作用主要有两点，一是配合轻量级Agent的设计，将Agent端的业务逻辑和数据层的工作承担起来，尽量减轻业务主机的压力；二是增加了可扩展性，通常情况下，一台前置机可支持200-500个并发用户，仅通过增加前置机个数就可以相应增加并发用户数的能力。 4、受控端Agent 受控端Agent部署在生产中心和灾备中心各个业务主机上，执行由AutoSwitch前置机发布的命令，并将执行结果发送给前置机。 AutoSwitch受控端Agent采用轻量化设计，仅有通讯和操作命令执行部分，其他功能都由前置机的程序补充完成，这可以最大化地减轻对业务主机的负载。

架构设计 Agent设计采用轻量化设计，仅有通讯和操作命令执行部分，其他功能都由前置机的程序补充完成，这可以最大化地减轻对业务主机的负载。 对于不能安装Agent的设备，提供通过ssh、telnet或远程图形化代理的方式进行操作。

对Unix、Linux平台，采用Perl或C、C++编制Agent，可以支持所有的主流Unix和Linux平台。 对Windows平台，提供32位和64位的可执行代码，可以支持所有的Windows系统。 13.3.3功能架构设计 开发部分： 1、脚本开发与维护：  支持参数化脚本的设计与模板  支持脚本的图形化维护操作

2、流程开发与维护：  提供建立灾备流程所需的各类基本元素，比如流程、子过程、连接弧等；  支持图形用户界面的基本操作  提供用户定义各模型属性的对话框；  支持流程模板，可以由模板生成流程。  支持模板和流程的保存与读取；  支持多层次建模；  支持人工操作

3、部署执行部分：  支持流程部署的图形化操作  支持流程实例化时的参数自适应匹配。  支持自动化操作和人工操作  支持自动化操作的异常检查，并在发生异常时转为人工操作，人工处理后，仍可继续自动化操作。 例：WebLogic集群启动流程中，每台的启动命令是相似的，AutoSwith 可以用参数化的方式复用流程和脚本。这样，比如在西安测试中，有6台Weblogic Server，启动命令类似，仅Server名称不同，AutoSwith只做一个流程，复用同一个脚本，即完成任务。 主机集群配置： 主机集群执行结果： 4、监控部分  AutoSwitch服务器监控  AutoSwitch Agent监控  业务主机监控  配置文件变更监控 注：绿色表示正常、蓝色表示处于停止状态、红色表示发生故障。 5、系统维护部分：  用户管理  角色管理  权限管理  服务器管理  操作类型管理  操作对象管理 6、报表、审计部分：  系统维护报表  流程定义报表  流程执行报表  审计报表

7、外部接口部分： 支持webservice、redis、socket、syslog等多种接口形式。 13.3.4非功能架构设计 性能高：轻量化Agent，可大大减少对业务主机的负载；无差异前置机集群可以通过硬件扩充提高AutoSwitch服务器端的性能。 易用性好：提供操作脚本和流程的标准化模板，可以大大化简流程开发的工作量；图形化的操作易学、易用。 可维护性好：提供Agent和操作脚本的自动与人工下发；统一控制台，无需登录各个业务主机。 可扩展性好：采用分布式消息系统和缓存系统，使每个前置机可以控制任一个Agent，每个流程及每个操作也可以由任一个前置机处理。这不仅提高了AutoSwitch的处理性能，也使AutoSwitch具有非常好的可扩展性。 可靠性高：AutoSwitch数据库和控制中心支持高可用集群和远程数据复制，确保7×24可靠工作。 例：

自动流程中的每个操作步骤都对应有原手工流程内相应的命令和解释，即可以帮助操作人员更好地理解自动流程，更大的作用是在该步骤发生异常时，可以更快地帮助操作人员排查问题。

13.3.5性能架构设计 Agent设计采用轻量化设计，仅有通讯和操作命令执行部分，其他功能都由前置机的程序补充完成，这可以最大化地减轻对业务主机的负载。通常情况下，受控端Agent占内存3M以下，CPU 1%以下。 采用分布式消息系统和缓存系统，使每个前置机可以控制任一个Agent，每个流程及每个操作也可以由任一个前置机处理。这不仅提高了AutoSwitch的处理性能，也使AutoSwitch具有非常好的可扩展性。这使得在配置2台前置机的