部署模式（精选十篇）
部署模式 篇1
一、集团企业财务共享模式构建的基础
(一) 构筑集团企业统一的财务控制体系
统一的财务控制体系是集团企业财务共享模式构建的重要基础, 是作为一种管理思想和原则, 通过各种工具、系统运行规则与相关管理制度来实现的。构筑统一的财务控制体系, 首先要建立统一的财务核算体系, 即在集团总部、各子公司之间采用统一的数据采集和核算方法, 执行统一的会计政策, 最终保证集团内各分子公司提供的财务信息口径统一、准确、可比;其次建立合理的组织结构模式, 合理的组织模式能够实现资源的有效共享, 要把相互关联的管理组织加以整合, 使原来基于集团按照地区、子公司等进行的财务部门构建转变为基于业务类型的财务部门构建, 并将其剥离出来, 集中归属到财务共享服务中心;第三建立集团全面预算管理与控制体系, 集团预算管理与控制体系是财务控制体系的手段, 通过它对集团公司及下属各子公司的预算执行情况进行实时监控和数据采集, 以保障企业经营目标的顺利实现;最后通过构建集团资金管理平台加强集团资金控制, 通过该平台, 一方面对下属各子公司的资金进出进行实时检测与控制, 另一方面实现集团内部的资金统一调度, 提高资金使用效率。
(二) 设计合理的财务流程
设计合理的集团财务流程有利于集团财务信息在集团总部、财务共享中心和各分子公司之间进行高效的传递, 对于降低财务成本、提高服务质量、加强集中管理和控制有非常重要的作用。
集团企业财务流程设计的基本思路是:根据集团实际情况, 在业务处理流程上, 增加或减少一些步骤, 以使新的流程满足跨组织、跨地域服务的实际需求;同时对各子公司财务服务流程进行分析和调整, 将其中一些具有风险管理意义的流程挑选出来, 交由财务共享服务中心来执行, 这样, 有利于财务共享服务中心通过关键控制流程实现对业务活动的控制和风险管理。
集团在进行财务流程重新设计时, 要考虑改造后的流程能够为各下属单位所接受, 因为其最终目的还是为各子公司、客户等提供服务。同时当财务服务流程发生变化之后, 集团的其他相关业务流程也要根据新的服务流程进行改动, 以便与财务流程无缝衔接, 有效实现各方面应用信息的集成, 使得各应用系统的基础数据和业务数据能得到集中管理和共享。
(三) 搭建安全、高效的网络化信息技术平台
集团企业财务共享模式的构建需要强大的信息系统来支持。通过建立一个安全、高效的能够覆盖整个集团企业的信息平台, 才能发挥财务共享的优势, 保证集团总部的战略得到有效贯彻和执行。随着信息技术的发展及其在企业管理中的广泛应用, 特别是网络财务、ERP等这些采用了高效信息交流与集成技术的系统在企业中的建立和使用, 使得财务共享服务模式在集团企业的实践和应用有了一定的基础。利用网络财务、ERP系统的技术基础和其他信息技术, 财务共享服务模式可以跨越地理距离的障碍, 向其服务对象提供内容广泛的、持续的、反应迅速的服务。
二、集团企业财务共享模式基本框架
(一) 集团企业财务共享服务模式
从世界范围来看, 目前企业财务共享服务模式有两种, 一是将财务共享服务中心建立在独立于总部和下属单位以外的第三地, 国外大部分集团企业都采用了这种模式, 如惠普公司在大连建立起了财务共享服务中心, 面向东北亚区包括日本、韩国和中国提供共享服务;摩托罗拉在天津滨海新区建立了全球财务共享服务中心, 该中心负责摩托罗拉公司全球应付账款业务、往来业务、报销业务等, 堪称摩托罗拉公司的财务部;国内的中兴通讯在西安建立了全球财务共享服务中心, 该中心为集团公司的预算管理、资金管理、核算和经营决策分析等提供全方位的数据支撑, 在降低财务运营成本、控制财务风险和提高会计信息质量等方面起到了重要作用。二是将财务共享服务中心建立在集团总部所在地, 与集团总部联系紧密, 是在原有的集团财务管理机构的基础上进行适当的财务组织变动而形成的, 我国的集团企业由于制度、法律、历史等原因, 目前大多采用此种模式, 如中国网通、长虹等集团企业都在总部原有的财务管理机构的基础上, 进行适当的整编与改革, 建立了财务共享中心, 节约了创建成本, 便于总部进行集中监控, 降低风险。
(二) 集团企业财务共享模式基本框架
从选址来看, 无论是采用第三地模式还是集团总部所在地模式, 财务共享模式的基本框架和实现的功能是一样的。构建模式的重心是优化集团财务管理价值链;采用集中管理模式, 固化财务制度;保证集团与分子公司目标一致;完善监控体系, 有效降低风险;科学评价绩效。图1所示为本人设计的集团企业财务共享模式的基本框架。在该框架中财务共享中心一方面通过网络收集从各子公司上传的业务数据完成会计核算、成本核算与管理, 实现资金的集中管理、内部银行等服务, 同时各子公司通过网络查询业务处理结果及反馈的信息;另一方面接受集团总部下达的政策、制度等, 同时为集团总部提供管理决策所需要的信息, 以利于集团总部战略财务、财务决策、财务监控和财务评价等功能的实现。
三、集团企业财务共享模式部署策略
集团企业在地理位置上往往比较分散, 有的下属子公司分布于全国甚至是全世界, 一般采用的模式是各个子公司组建自己的局域网, 然后将附近区域这些局域网再相互连接起来构成一个城域网, 距离远的超出城域范围的, 再通过广域网连接在一起。但是通过广域网连接在一起的集团企业网上往往运行着各种类型和不同操作系统的计算机, 多模式的互连及兼容性等技术性问题非常难以解决, 同时由于广域网的连接速度比较低, 无法将整个集团企业的数据进行集中采集和处理, 使得数据的传输和共享成为一个难于解决的问题。为了克服这些难题, 本人设计了基于Intranet/Internet技术的部署方案, 如图2所示。
Intranet是建立在企业内部的Internet, 又称企业内连网, 它是一种基于Internet的TCP/IP, 使用WWW工具, 采用防止外界侵入的安全措施, 为企业内部服务并有连接Internet功能的企业内连网络。Intranet技术优势包括:对客户端作了最大限度的简化, 把客户端统一为通用的浏览器;解决了多模式互连以及兼容性等技术问题;最大限度实现无纸化办公, 促进信息传递;扫除了信息传递的障碍, 使得整个集团溶为一体。对集团企业而言, Intranet将分散环境中的子公司、个人和资源组织在一起, 从而实现全球范围内的访问, 任何用户都可以通过Intranet访问存储在不同地方的信息资源, 并且Web引导和搜索模式可以使得用户能更加方便地找到和分析信息。
采用基于Intranet/Internet技术的部署思路主要是:在集团各子公司、集团总部和财务共享中心内部建立自成一体的、相对独立的Intranet内部网络, 内部网络上采用TCP/IP作为通信协议, 利用Internet的Web模型作为标准模式, 并由Intranet内主机或服务器为其内部各部门提供财务信息服务;各子公司与财务共享中心的连接通过Internet, 为了保障内部网的安全, 需要建立防火墙把内部网与Internet隔开。各子公司、集团总部和财务共享中心的Intranet内部网络系统里的文件、应用程序处理的结果一律通过Web浏览程序显示出来, 作为相关用户, 只要操作Web浏览程序, 各种各样的处理任务都可以通过Web浏览程序调用系统资源来完成, 服务器则集中了所有的应用逻辑, 开发、维护等几乎所有工作也都集中在服务器端。
四、结论
作为一个新的管理工具, 财务共享服务模式在支撑集团企业制度的标准化, 流程的科学化与精简化, 有效降低财务管理成本, 提高效率, 强化总部对分子公司的管控力度以及集团内部运营风险、财务风险控制等方面具有其它管理工具无法比拟的优越性。尽管目前在我国这种模式的普及程度较低, 但随着我国经济的发展和管理水平的不断提升, 该模式必将成为集团企业的首要选择, 发展也将越来越成熟。
参考文献
[1]陈虎、董皓:《财务共享服务》, 中国财政经济出版社2009年版。[1]陈虎、董皓:《财务共享服务》, 中国财政经济出版社2009年版。
[2]李嘉:《集团企业实施财务共享服务路径探讨》, 《财会通讯》 (综合版) 2009年第23期。[2]李嘉:《集团企业实施财务共享服务路径探讨》, 《财会通讯》 (综合版) 2009年第23期。
部署模式 篇2
第一季度工作总结和第二季度工作部署
4月1日，省档案局局长李安全主持召开局务会，总结第一季度、部署第二季度的档案工作。李安全局长传达了延安干部学院正厅局长“加强党性修养、坚定理想信念、保持优良作风”培训班精神，巡视员阎中恒传达了省直单位机关效能年活动汇报会精神，各处、室、中心负责人汇报了一季度工作情况和二季度工作打算。副局长方维华参加了会议。
会议认为，今年一季度的工作，在去年工作的基础上，按照全省档案工作会议的部署，有计划、有步骤地组织实施，各项工作又有了新的发展、新的提高，有的工作具有一定的创新性，在全国具有一定的位置。
一是档案业务工作全面启动。省档案局对省直单位2009档案工作检查、国家档案局8号令的贯彻执行、机构改革中撤并单位档案的处理和档案规范化管理工作及时进行了部署和指导；将2009年中央新增投资项目的档案管理、省重点工程档案工作列入重点工程稽查内容，会同有关部门进行专项检查；在江中集团公司建立了国有企业档案工作联系示范点，以点带面推进国有企业档案工作再上一个新台阶；开展了新建县级档案馆情况调研指导，加强县级档案馆建设。
二是馆藏档案资源建设工作全面推进。省档案馆接收5个省直单位到期档案2666卷、昌金高速公路等重点项目档案2746卷，整合省属高校电子档案目录4188条，网上下载2008重大活动的报道内容，拍摄省人大第十一届二次会议、省政协第十届二次会议、环鄱阳湖生态经济区建设等重大活动照片档案800多张、视频档案500G、DVD视频文件300多分钟，征集知名画家熊德琪、万徐良和摄影家武敦瑜、吴先桂捐赠的画作、摄影作品53幅（件、本），收购日军侵华史料《画报跃进之日本》3册，修裱破损民国档案10331页。
三是档案利用服务工作全面拓展。完成了10809卷档案的初审鉴定，整合了全省劳模数据库，着手建设全省档案目录中心，与南昌大学、江西师范大学等院校建立了档案馆教学实践基地，接待查阅档案和参观档案展览687人次、查阅档案资料393卷（件）、复印档案资料1132页。省档案新馆被省委、省政府命名为爱国主义教育基地。
四是档案信息化建设全面推行。制定了《江西省档案馆电子档案与数据备份管理规范》和《江西省档案信息网站集中检查测评细则》；著录照片档案5300余张，扫描民国开放档案136732画幅，录入现行档案文件级目录数据35717条，整合省直25个立档单位档案目录数据65881条，导入省档案馆利用系统馆藏现行档案文件级目录数据39954条；组织了电子文件接收管理系统软件的研发，启动了《电子文件接收与管理办法研究》课题的研究。
五是档案宣传工作有声有色。全省在《中国档案报》和《中国档案》杂志刊登稿件59篇，在《国家档案局网》、《中国档案资讯网》、《中国档案网》刊登稿件122篇，订阅《中国档案报》895份、《中国档案》杂志800份，在全国刊稿排名第5名、报刊订阅排名第12名，较上年排名分别前6位和4位，是历年同期刊登稿件、订阅报刊最多的一年，得到了《中国档案报》通报表扬。与此同时，组织省市10家新闻媒体对档案工作集中采访报道，省委书记苏荣和省委常委、省委宣传部长刘上洋对南昌晚报报道的《神秘档案“开口”替百姓说话》一文引起关注并作出批示。《南昌晚报》、《江西日报》、《经济晚报》《江南都市报》等新闻单位对档案工作进行了连续报道，档案工作的影响面有了新的扩大。
六是机关效能建设初见成效。按照省委、省政府的统一部署，召开了动员大会，邀请了省委党校专家授课，组织学习了胡锦涛总书记春节期间视察江西时的重要讲话、全国“两会”、省“两会”精神，进一步完善了工作制度，实行了定岗、定员、定责制，细化了工作任务，把软任务做硬。为了提高服务质量，方便群众查阅利用档案信息，对上下班作息进行了合理调整和安排，实行了中午不休息连续接待。为提高行政效率，把仅有的3项行政许可项目审批权全部下放设区市，向社会承诺办理时间由20天缩减为10天。
会议要求，第二季度的工作要在第一季度的基础上，突出重点，抓住薄弱环节，注重整体效益，把档案工作推向深入。
一是着力抓好档案行政管理工作。制定出台一批指导性、政策性文件，开展全省城建房产档案执法调研；组织省直单位档案员集中培训，深入部分省直单位现场指导；建立1—2个国有企业档案工作规范化管理示范点，推动省重点骨干企业和省直属企业的档案工作规范化管理；搞好社会主义新农村建设档案工作调研和试点，修订《乡（镇）、村文件材料归档范围和档案保管期限表》，制定《乡（镇）、村档案工作规范化管理标准》；抓好省重点建设项目竣工档案登记和验收工作，实行跟踪服务、规范管理，迎接国家档案局的检查。
二是着力抓好档案信息化建设。组织全省档案网站检查评比，开展设区市档案馆信息化情况调研，改版提高“江西省档案局网站”；搞好江西省档案电子文件接收管理系统软件研发与试点，完成模块上线、试用、修改；录入到期新进馆档案、馆藏档案和全省目录中心现行档案等数据不少于3万条，完成民国开放档案数字化全文目录数据库80万画（幅）录入任务，卫星接收省电视台新闻联播内容。三是着力抓好档案馆业务。收集胡锦涛总书记春节期间视察我省等重大活动档案资料，拓展省党代会、省委全委会、省人大常委会等重大活动的现场拍摄，做好2009年国家重点档案抢救与保护项目申报，抓好档案抢救与保护项目的实施，整理省政府办公厅档案，完成档案开放鉴定2.5万卷，建好全省档案目录中心，办好《中国档案文献精品展》在线展览，编好《城市解放》系列丛书，开展庆祝建国60周年征文活动，组织档案学会会员学习交流活动，开展中小学生爱国主义教育和大学生实践活动，完善馆藏档案台帐，加强档案安全保管。
四是着力抓好机关效能建设。举办全省档案局馆长、信息化建设和档案员上岗培训班，组织兰台青年讲坛，强化思想教育，从严落实制度，从严管好机关，促进机关工作热情大提振、工作标准大提高、工作效率大提升。
部署模式 篇3
集装箱码头生产作业系统涉及多种作业资源的配置、计划和调度，属于复杂系统。装卸设备之间合作的有效性是集装箱码头运作效率的决定因素，因此，集装箱码头生产作业系统本质上是协同作业系统。在传统的作业环境下，集装箱码头主要依赖人的经验或预定的程序对作业任务进行规划和调度，并形成确定的作业序列，其中“计划”是码头运作过程中的重点；然而，集装箱码头的作业任务和作业环境具有随机性和动态性，确定的“计划”必然导致作业主体之间无法及时、有效地协同，进而造成码头作业效率低下和资源浪费。实现集装箱码头作业主体之间动态协同作业，以解决码头静态集中计划与动态分布式作业过程的冲突等问题，是提高码头作业效率的重要课题之一。随着传统集装箱码头逐步向自动化集装箱码头演变，作业资源的自主协同性也日益受到关注并得以发展。
智能体技术是人工智能领域的研究热点。智能体具有自主性和智能性，能对动态变化的环境做出自适应行为，并能与其他智能体通信，相互协作完成复杂任务。智能体技术使集装箱码头作业主体在动态环境下的协同作业成为可能，但“智能性”同时也意味着大量的逻辑运算，这给作业设备的硬件和实时通信带来挑战，要求集装箱码头改变现有的软硬件架构和布局。
本文从智能体系统应用于集装箱码头作业的实际问题出发，研究集装箱码头协同作业系统软硬件智能体部署模式：结合集装箱码头的应用环境，分析整体式部署模式的优缺点，并基于码头企业数据中心向云计算平台发展的趋势，提出分体式和混合式的新型部署模式。
2 集装箱码头协同作业系统软硬件部署模式
如图1所示，集装箱码头智能体设备在软硬件实现上分为软件智能体和硬件智能体。软件智能体是智能体设备的大脑，主要负责智能计算以及与其他智能体交互协同；硬件智能体是智能体设备的硬件实体，主要负责人机交互、环境感知、无线通信以及机械控制等。
2.1 整体式部署模式
2.1.1 概述
在整体式部署模式下：硬件智能体与软件智能体整合在一起，安装在码头作业资源（如集卡、场吊、桥吊等机械）上；软件智能体在硬件智能体上运行，就像软件在计算机中运行一样。
集装箱码头整体式智能体系统部署环境如图2所示：码头机械上同时部署软件智能体和硬件智能体，从而组成一套完整的智能设备；智能设备之间在协同作业中通过无线网络进行频繁通信；管理智能体（或智能体管理系统）在码头企业的云计算中心服务器上运行，其通过无线网络与码头机械通信，实现对机械的管理。
2.1.2 优点
整体式部署模式使码头机械成为典型的、完全意义上的智能体。这种部署模式简单易行：新加入的智能体设备只要经过简单配置就能快速入网，与其他智能体设备协同工作；即使智能体设备与外部联系中断，也能独立执行任务。
2.1.3 缺点
（1）硬件要求较高。由于软件智能体要实时进行复杂的人工智能计算，硬件智能体必须具备足够的计算能力和存储空间支持软件运行。目前码头机械常用的嵌入式设备往往难以满足这样的计算要求。
（2）网络要求较高。智能体设备之间的协同工作需要高速、稳定的无线通信带宽，这就要求集装箱码头部署高质量的无线网络。
（3）设备制造和维护成本较高。由于整体式模式下智能设备的软硬件技术含量较高，且必须适应集装箱码头的户外工作环境，导致设备制造和维护成本较高。
2.2 分体式部署模式
2.2.1 概述
硬件智能体的功能相对简单且发展较为成熟，因此，可以采取分体式部署模式，将集装箱码头智能设备中的软件智能体与硬件智能体分开部署：硬件智能体安装在码头机械上，对应的软件智能体在码头企业的云计算中心服务器上运行。
集装箱码头分体式智能体系统部署环境如图3所示：码头机械上仅安装智能设备的硬件智能体组件，对应的软件智能体组件部署在码头企业云计算中心；智能设备的软硬件智能体之间通过无线网络通信以传输参数和结果；码头机械的软件智能体和系统的管理智能体（或智能体管理系统）分布在码头企业云计算中心的高性能服务器上，进行复杂的协同智能计算。
2.2.2 优点
（1）智能体设备的硬件要求较低，码头机械常用的嵌入式设备完全能满足需求。
（2）智能设备的软件智能体在远程云计算服务器上运行，其强大的计算能力和大容量的存储空间能满足人工智能算法的要求。
（3）云计算中心的服务器之间通过高速以太网连接，具有高带宽和高可靠性，能支持大量智能体之间的复杂协同和决策需求。
（4）软件智能体统一部署在云计算中心，能充分发挥云计算平台安全、经济的优势，便于统一管理和维护软件，保证智能体的数据库安全。
（5）码头机械之间的无线通信量较小，而智能设备的硬件智能体只与其对应的软件智能体通信，对码头无线网络覆盖的要求较低。
综上所述，分体式部署模式的性价比较高，有利于智能体设备的应用和推广，能够使当前技术条件下的码头机械快速升级，具备智能化运行能力。
2.2.3 缺点
在分体式部署模式下，必须保证智能设备的硬件智能体与软件智能体之间的通信，如果两者之间的网络连接中断，将导致智能设备失去智能；因此，分体式部署模式适用于硬件智能体与软件智能体之间通信量较小且实时性要求不高的情况（例如传输协同算法的参数和计算结果等），而对高清视频信息的实时传输和控制则不一定适用。不过，从集卡、场吊、桥吊等码头机械协同作业的实时性要求来看，分体式部署模式在大多数情况下能够满足要求。此外，分体式智能体设备的部署比较复杂，新的智能机械进场后，需要在码头企业的云计算中心安装相应的软件智能体并完成相关配置才能开始运行。
2.3 混合式部署模式
针对分体式部署模式下存在的软件智能体与硬件智能体连接可靠性的问题，为确保智能设备在网络断开的情况下依然能自主或部分自主地运行，可以考虑在硬件智能体上运行从软件智能体，主要负责简单的智能计算（例如某些启发式算法或随机算法）、缓存服务器端的主软件智能体的计算结果等，用以在网络中断或实时性要求较高的情况下实现自主智能处理。此种模式为混合式智能体系统部署模式（见图4）。
企业应用系统全冗余部署模式研究 篇4
企业应用系统部署后, 单机隐患和故障往往是系统管理员头疼的问题。一旦应用服务器或数据库服务器出现磁盘、内存等故障, 轻则引起系统停运, 重则导致数据丢失。尽管可以通过磁盘划分RAID、应用备份、数据备份等方式来提高系统可用性, 但始终不是治本之策。本文通过研究一种全方位冗余的部署方式, 力求从根本上解决单机故障和隐患影响系统可用性的问题。
2 企业应用系统全冗余部署模式的必要性分析
随着计算机应用的不断深入, 企业对计算机系统的依赖程度也日渐增加。尤其一些关键行业应用上, 后台核心系统是否具备高可用性能力, 直接影响到公司业务。高可用性包括保护业务关键数据完整、维持应用程序运行连续等多个方面。在这些信息处理系统中保存了大量的关键业务数据, 若是出现信息丢失、破坏等现象, 将带来严重损失。在传统观念中, 往往选择价格昂贵的专有计算机系统来提高业务系统运行的稳定性, 系统实施及维护成本极高。而价格较低的单一的PC服务器系统目前还无法满足用户对于安全性及可用性的要求。在资源有限的情况下, 如何保证业务系统的高可用性和数据的安全, 已成为众多用户关注的焦点问题。
3 应用系统传统部署方式
无论是C/S模式 (客户端/服务端) 还是B/S (浏览器/服务端) 模式, 大部分企业应用系统在部署时均采用传统的三层架构, 即应用程序、中间件、数据库。应用程序和中间件一般部署在一台应用服务器上, 数据库部署在一台数据库服务器上, 如图1所示。应用服务器上的应用程序通过数据库客户端连接到数据库服务器上的数据库服务端进行数据操作。
此种部署模式虽然简洁高效, 但存在单机故障风险。一旦应用服务器、数据库服务器的软硬件出现故障, 将导致系统停运。如果应用服务器上的程序和数据无法恢复且备份不到位, 系统则面临重新搭建, 延长停运时间的风险。如果数据库服务器上的程序和数据无法恢复且备份不到位, 则数据库不但需要重新搭建, 还将面临数据丢失的风险。
4 全冗余部署方式实施步骤
4.1 双机工作概念的提出
从广义上来看, 就是对于重要的服务, 使用两台服务器, 互相备份, 共同执行同一服务。当一台服务器产生故障, 可由另外一台服务器承担相应的服务任务, 无需人工干预, 实现系统的自动、持续服务。双机热备主要利用备用服务器解决了主服务器故障时服务中断问题。但是, 在实际应用中, 有时存在多台服务器情况, 即服务器集群。双机热备通常需要有共享的存储设备, 某些情况下也可使用两台独立服务器。实现双机热备, 需要使用专业集群软件或是双机软件。
从狭义上来看, 双机热备指的是基于active/standby的服务器热备。服务器数据主要包括数据库数据同时往两/多台服务器写, 或使用一个共享存储设备。同一时间只有一台服务器运行, 当处于运行状态的服务器出现故障, 无法正常启动时, 则另外一台备份服务器科通过软件诊测 (如:心跳诊断) 激活standby机器, 确保应用短时间完全恢复使用。
双机的三种模式:①双机热备, 也就是常说的主备方式, 服务器数据主要包括数据库数据同时往两/多台服务器写, 或是使用一个共享存储设备 (例如:磁盘阵列柜) 。若是主服务器产生故障, 通过诊测 (例如:心跳/串口线诊断) 激活备用机器, 确保应用短时间完全恢复使用。②双机互备, 双机热备基础上, 2个独立的应用在2台机器上同时运行, 彼此均为备机, 若是一台服务器产生故障, 则另外一台服务器可在短时间接管故障服务器的应用, 确保应用持续。此种方式实际上是双机热备的一种应用, 它避免了两个应用使用四台服务器分别实现双机热备。③双机双工, 两台或是多台服务器均为活动, 同时运行相同的应用, 从而保证整体的性能, 也实现了负载均衡与互为备份。此种模式下, 需要利用磁盘柜存储技术。对于数据库服务而言, 它同时需要数据库软件的支持, 因此可以说是比较复杂的。
4.2 全冗余部署模式的构建
为了解决上一章节中的单点故障隐患等问题, 本章节考虑提出一种全冗余部署模式。
如图2所示, 采用2台应用服务器、2台数据库服务器、2台光存储交换机、1台磁盘阵列来实现系统部署。
4.2.1 服务器硬盘RAID配置
建议将每台服务器的硬盘划分为两个部分:第一部分硬盘数量视存储空间配置为双数 (比如2块) , 配置RAID1, 用于安装操作系统;第二部分硬盘配置RAID5, 用于部署程序和存放数据。
4.2.2 服务器通过光存储交换机连接存储
每台服务器需要安装2块HBA卡, 4台服务器通过HBA卡分别连接到2台冗余的光存储交换机, 再通过2台光存储交换机连接到磁盘阵列的2个冗余的控制器。连接时建议采用机柜的光配连通。
4.2.3 服务器集群搭建
2台应用服务器、2台数据库服务器之间均采用心跳线相连。应用服务器集群可以采用操作系统自身集群或者中间件集群等方式。数据库服务器集群建议采用数据库集群方式 (如Oracle RAC) 。公用数据均存放在磁盘阵列中。
4.2.4 服务器双网卡聚合
每台服务器的两块网卡做聚合, 虚拟为一个IP地址, 视为同一块网卡。
5 高可用性分析
5.1 系统各层次、各设备的冗余
通过以上部署模式, 尽可能实现了系统各个层次、各个设备的冗余。具体如下:
5.1.1 服务器硬盘冗余
每台服务器中用做操作系统安装的硬盘采用RAID1部署 (完全镜像) , 一旦损坏1块磁盘, 不影响操作系统运行。另外部分的硬盘采用RAID5部署 (N-1模式) , 损坏磁盘数量不大于1块, 不影响程序运行。
5.1.2 服务器网卡冗余
由于每台服务器的两块网卡做了聚合, 一旦损坏1块网卡, 不影响网络连通。
5.1.3 应用服务器冗余
2台应用服务器通过搭建操作系统自身集群或者中间件集群, 一旦1台应用服务器损坏, 不影响系统运行, 如图3所示。
5.1.4 数据库服务器冗余
2台数据库服务器通过搭建数据库集群, 一旦1台数据库服务器损坏, 不影响数据库对外提供服务, 如图4所示。
5.1.5 光存储交换机冗余
通过配置2台冗余的光存储交换机, 一旦1台光存储交换机损坏, 不影响服务器与磁盘阵列的连通, 如图5所示。
5.1.6 磁盘阵列控制器冗余
通过选用带有冗余的双控制器磁盘阵列, 一旦一个控制器发生损坏, 不影响服务器通过光存储交换机与磁盘阵列连通, 如图6所示。
同时应用数据、数据库数据文件等公有数据均保存在磁盘阵列中, 大大提高了可靠性。
考虑一种比较极端的情况, 假设1台应用服务器、1台数据库服务器、1台光存储交换机、磁盘阵列的1个控制器同时发生故障, 系统照样可以继续运行, 如图7所示。
5.2 系统整体应用优势
①对服务器硬件配置要求不高, 可以根据应用情况采用不同型号或配置;②可利用原有生产系统快速构建双机系统, 性价比高;③系统切换时间短, 最大程度减少业务中断的影响;④切换过程对应用程序无影响, 无需重新启动或登录, 做到无人值守;⑤系统效率高, 系统中数据读写、管理及容错由磁盘阵列来完成。而系统服务故障监控切换处理由软件来完成。双机监控依靠串口线路或专用TCP/IP网路线路, 既不占用主机CPU资源也不占用基础业务网络带宽, 在实际应用中得到用户的一致好评;⑥支持丰富的应用配置, 如:Oracle、MSSQL、Sybase、My SQL、文件服务、Web服务等, 无需额外插件支持用户自定义应用;⑦硬件可采用机架式结构, 便于维护管理。
6 结语
通过上一章节中的高可用性分析, 该部署模式实现了应用服务器、数据库服务器、光存储交换机、磁盘阵列等各个层次和设备的冗余, 大大提高了系统可用性。不过, 由于该部署模式涉及设备较多、部署方式相对复杂、对管理员的技术要求较高, 后续可以通过硬件功能整合改进等方式来进一步优化。
摘要：冗余系统指的是应用两套及其以上相同、相对独立的配置构成互为冗余控制系统。若是处于工作状态的部分出现故障, 则作为冗余部分将会承担其工作, 实现整套系统的不间断运行。基于此, 本文提出了企业应用系统全冗余部署模式, 以期实现系统整体运行可靠性大幅提高。
关键词：企业,应用系统,全冗余部署模式
参考文献
[1]谢文超.全冗余系统的设计与应用[J].江苏锅炉, 2014 (3) :45~49.
[2]汪啸.采用冗余数据删除技术进行备份系统优化的应用研究[J].信息通信, 2015 (3) :26.
[3]侯丽娟.网络冗余技术在公司局域网的应用分析[J].网络安全技术与应用, 2014 (11) :132~133.
部署工作计划 篇5
一、坚持建设标准
对城镇的所有建设，一律按规划图实施，杜绝规划点外建设，规划点上的建设项目，一律按法定程序审批，小城镇的建设标准，严格规范抓好每一项建设项目，做到建一项，达标一项。集镇区新规划居民小区，综合农贸市场，镇区道路，下水道、转盘、绿化带等建设全部招投标，按图施工。
二、创新建设项目
对镇区域按规划进行集中建设，功能分区明确，主街道建筑规模和造型新颖美观，群体空间结构协调，色彩搭配和谐，在新规划住宅区，保证规模档次，环境、安排适度。
三、完善规划编制
请市规划设计院继续把集镇总体规划全面编制完善，争取上半年完成规划成果报批。并适时启动集镇区控制性规划编制及报批。
四、配套设施建设
1、桃园路，在中大街到振兴路这段面，铺好水泥路面、下水道的设施、视为、水果、蔬菜五谷杂粮等综合性农贸市场。
2、镇区内的自来水管网配套，结合县改水工程全面配套到位。
3、绿化与亮化建设
(1)绿化工程，搞好镇区绿化工程，利用现有自然条件，规划中大街北半段面两侧绿化，以花园格式或以定点植树进行规划建设。
(2)亮化工程，中大街北段面没有安装路灯、在20xx年期间把北段面安装15盏路灯，增加龙苴小城镇亮化工程的透明度。
4、环境设施。配齐中大街北半段环境设施垃圾箱20个。
五、完成建设目标
1、转盘建设，为树立龙苴镇对外形象，在镇北“丁”字路口，按集镇整体规划设计40米直径转盘、转盘内设有司马龙苴雕像，是树立龙苴北大门对外形象，也是缓解集镇进出口交通和人流疏散。
2、房地产开发，以政府开发为主体，以民资民力为房地产动力，开发桃园路南、中大街东，原食品站旧址、开发商住小区。占地面积3335平方米，建筑面积4460平方米，投资267万元。
3、完成龙胡路南，振兴路西新住宅小区的工程建设和小区内外道路、下水道等设施配套建设。
4、完成老街道道路改造建设，铺水泥路宽16米，长500米，道路建设，建筑面积800平方米，投资48万元。
六、镇区控制性规划位置
美军事部署大调整 篇6
事实上，微妙的改变已在出现。近年美国海军已将愈来愈多的攻击潜艇调到亚洲。这些潜艇既是美国截听他国通讯、监控船只活动的情报耳目，也是战争爆发时率先负起第一波攻击任务、向敌国发射巡航导弹的"发射台"。据一名海军高级官员透露，不过两三年前，美国海军仍将六成的潜艇留在大西洋，然而今时今日，驻大西洋和太平洋的潜艇数目已基本均等，预料未来驻太平洋的潜艇还会占大多数。
一名国防部官员还指出，过去8年，国防部有近2/3的前瞻性军演行动，是在亚洲进行；另外针对亚洲地区问题的战略智囊研究小组，近年也愈来愈多。
美国国防部长科恩表示，随着美军将焦点由欧洲逐步转向亚洲，"我们需要更多的空军运输机，更多的战略空降师，更多的海军登陆师"。
针对未来可能要出兵亚洲，美国将加强发展和生产长程轰炸机和加油机，而不是研制中的短程空军新贵F-22战斗机---这种在冷战时代设计的机种，主要是针对在相对狭窄的中欧上空进行空中格斗。在去年美国国防部举行的亚洲未来研讨会上，与会的NorthropGrumman公司电子传感器组主管罗奇说："现在我们设计战斗机的思路还是停留在驻守德国的时候。亚洲的地域远比欧洲大，所以飞机的腿也得长些。"事实上，美国空军内部近日也在讨论是否把部分"空军远征部队"的基地，移至关岛；过去美国为防范朝鲜的威胁，已派遣过B2型隐形轰炸机至关岛。"空军远征部队"是美国的主力快速应变部队，共有10队，部署于全球不同地方。
同样，美国海军预料也将发展更多可以远程作战、甚至跟现有舰种截然不同的军舰。美国海军已有近半个世纪没有在亚太水域执行军事作战任务。国防部就曾研究过，假如印尼瓦解触发乱局，海军可能被派往马六甲海峡，保护这条国际水道畅通无阻，因波斯湾的石油都经此大量输往日本等东亚国家。美国国防部一项研究便称，现在的美国军舰不够隐形，不能避开雷达的侦察，随着愈来愈多国家(当然也包括中国)拥有精准导弹技术，美舰的性能必须大幅提高。
这是美国研制的新一代超音速远程战略轰炸机B1
驻太平洋区美军实力
太平洋陆军6万陆军及人员
太平洋舰队13万海军及人员(170艘船)
太平洋空军4万空军及人员(380架飞机)
太平洋海军7万海军及人员(两支特遣队)
部署模式 篇7
IEEE802.11系列无线局域网络 (Wi Fi) 标准的出现, 使“网络无处不在”的美好愿望成为现实, 它所具备的移动性和灵活性, 使得医院部署特殊的信息化应用成为可能。生命体征数据采集、医护数据查询和录入、医生查房、床边护理、护理监控、药物配送等无线应用系统正在逐渐得到使用和部署。移动医护是现在绝大部分医院首先部署的业务, 医护人员通过便携机、PDA等移动终端接入设备, 可以尽可能有效的与患者进行交流, 从而提供更高效的床边诊疗服务。
一、移动医护面临的挑战
在医院部署移动医护业务的时候, 很多医院发现实际效果远达不到预期。科室里的医护人员经常会抱怨PDA不好用, 扫描扫不上、连接中断, 这些问题都严重制约了一线医护人员使用无线医疗的体验感。
导致出现以上问题的主要原因是组成移动医护系统的智能终端、Wi Fi网络和移动医护软件之间的配合, 尤其是智能终端在Wi Fi网络的漫游问题, 而移动医护最大的业务特点就是漫游要求非常高, 医院医护人员的使用范围覆盖整个病区, 使用频率高, 而且跨病房使用非常密集。因此, 我们需要重点分析智能终端在Wi Fi网络漫游中涉及到的一些因素:
Wi Fi网络的漫游机制。漫游对移动医护最大的影响是智能终端跨越AP时的切换机制, 例如一个终端准备从AP1的有效信号范围进入到AP2的有效信号范围, 随着离AP1的距离越来越远, AP2的距离越来越近, 终端感知AP1的信号越来越弱, 感知AP2的信号越来越强, 在达到一定临界值的时候, 终端就需要进行AP的漫游切换, 接入AP从AP1转换到AP2上。现在医院普遍存在的移动医护体验感不好的根本原因就在于漫游出现了问题, 经常会出现终端即使信号已经很弱了, 仍久久不切换远端AP, 或者不停地在两个AP之间进行频换切换, 即该切换的时候不切换, 不该切换的时候反复切换, 这些问题就导致了最后数据连接中断, 业务停顿。
在这种情况下, 一方面需要保证漫游区信号的稳定和健壮, 同时还可以在AP和终端上实现下线机制, 在AP上实现感知信号差异的时候强制踢下终端, 或者主动迅速降低信号强度, 让智能终端自动完成切换。
二、Wi Fi网络建设模式
为了能够在医院提供全面、符合强度标准的信号覆盖, 满足漫游区域的信号稳定健壮, Wi Fi部署方案有以下几种:AP入室、天线入室和楼道高密放装三种方案, 分别介绍如下:
1. AP入室。
该方案以三个病房为一个单位, 中间病房部署一个AP, AP部署的位置可以在屋顶或正对窗户的墙壁放装, 该AP穿墙覆盖相邻的三个病房。在护士站、配药室、隔离病房、会议室、大套间等特殊环境单独AP覆盖, 病区过道视终端信号强度按需布置, 特别注意过道死角, 信号较弱会导致漫游问题。
该方案的优点是可以保证病房Wi Fi信号的强度均匀, 没有死角, 卫生间边上容易出现的死角可以由房内AP穿墙覆盖;该方案的缺点是需要病房内专门为AP走线, 并且AP数量较多, 终端漫游的次数比较多。
2. 天线入室。
该方案在楼道部署放装AP, 并且由AP上伸出多根天线进入病房, 每个病房一根入室天线, 过道需要视信号强度确定天线数量, 天线安装规范, 固定在天花板或者墙壁上, 可以采用5+1的方式, 如果信号不达标, 可采用4+2, 美化天线安装需正对病房。
该方案的优点是可以保证病房Wi Fi信号的强度均匀, 因为每个病房都有天线进入, 所以房间内没有死角, 此外单AP覆盖范围较大, 终端漫游次数较少, 减少了因为漫游而出现的一些使用问题;该方案的缺点是需要病房内专门为天线走线, 并且天线部署的位置可以在屋顶及正对。
3. 楼道高密放装。
在很多病区不能布线进入病房的场景下, 可以通过楼道高密放装的方式解决。在楼道放装AP, AP放装的位置非常讲究, 要在相邻两个病房门外的交界处, 使AP的信号可以直线覆盖到病房的最里面。每门对门相邻的两个病房, 或者门对门相邻的四个病房由一个AP覆盖。
该方案非常适合相邻两个或四个病房门对门, 几个门正对的过道的AP正好可以覆盖这几个房间, 其优点直线覆盖无障碍物, 施工方便, 有效避免病房漫游, 此外, 终端在AP之间的漫游区域全部集中在楼道, 保证了医护人员在病房内使用终端的时候, 漫游已经完成, 大大提升了移动医护的体验感;该方案的缺点是AP数量比较多, 而且走廊直线放装不利于对未来的采用三角定位的Wi Fi定位等物联网应用的开展。
三、结语
部署模式 篇8
随着国家电网公司SG-ERP架构的深入应用及“五大”的推广, 深化集团化运作, 建设一体化的国家电网公司的重要性日益显现。因此, “十二五”期间, 国家电网公司在SG-ERP的发展规划中明确提出要在SG186两级平台的基础上, 建设支撑智能电网和国家电网公司集约化管理的一体化通信信息平台, 并逐步过渡到大范围的统一集中和数据共享。通过一级部署[1], 促进业务的标准化建设, 提高业务系统的集约管控力度;简化优化IT架构, 提升对业务发展的服务与响应能力, 同时提高软硬件资源利用率, 降低建设和运维成本。采用一级部署模式, 运行监控、定期巡检、故障处理、应急处理、数据备份、容灾处理等工作仅在国家电网公司总部进行, 可以极大地降低网省公司系统运维工作量。针对国家电网公司安全监督管理、政工管理、纪检监察、班组管理、审计管理等综合管理业务应用, 从管理需求、用户规模、软硬件资源等方面考虑初步具备一级部署改造的条件。鉴于此, 国家电网公司信通部统一组织各业务信息化建设队伍开展系统一级部署改造工作[1]。
1 一级部署
目前国家电网公司安全监督管理、政工管理、纪检监察、班组管理、审计管理等综合管理业务应用已经完成一级部署改造工作, 一级部署业务应用总体技术架构如图1所示。
1) 待办集成。在总部门户里分发或者集中展示待办任务并实现页面集成[2]。总部门户和网省门户的待办任务通过总部和网省的应用集成平台 (ESB) 实现分发[3]。
2) 目录集成。用户通过门户访问一级部署业务应用[4], 总部目录系统集中管理用户、组织机构等数据, 这些数据直接通过总部目录系统同步到一级部署各业务应用, 目录服务对一级部署业务应用提供身份同步、代理保护、单点登录、单点注销的功能, 同时借助目录服务“总部–省公司”之间级联认证实现省市公司用户对总部一级部署业务应用的访问。
3) 应用集成。一级部署各业务应用与总部的其他业务应用之间存在横向集成, 与省公司业务应用之间存在纵向集成, 通过应用集成平台 (ESB) 实现一级部署各业务应用与其他业务应用的数据共享[3]。
4) 一级部署各业务应用是在原两级部署的基础上进行改造, 开发平台与两级部署时采用的开发平台一致, 即国网统一开发平台 (So Tower) , 由So Tower平台提供底层基础支撑服务。
2 集成方案
2.1 待办集成
业务应用从两级部署改为一级部署后, 若待办直接与网省门户集成必将造成网络链路交错复杂、带宽占用较高、待办统一管理 (以及审计) 的不便, 增加一级部署业务应用待办发送逻辑的复杂性, 从而影响一级部署应用待办发送性能。为解决以上问题, 采用基于ESB连通特性完成待办的集中管理和统一分发[3]。
整个待办发送与接收采用事件驱动方式实现一级部署业务应用待办到网省门户的分发。在这个过程中, 待办数据及待办状态以XML格式通过总部ESB发送到总部门户待办处理模块。总部门户待办处理模块根据收到的待办信息通过ESB的两级贯通特性分发到具体网省门户待办处理模块上。
待办集成流程如图2所示。红色部分路径为待办数据传输示意路径, 黑色部分路径为待办消息传输示意路径。
待办信息在总部门户直接通过目录单点登录功能实现展现, 待办信息在网省门户的展现需要借助ESB两级贯通及目录服务的级联认证实现, 待办展现过程示意如图3所示。
1) 一级部署业务应用通过Web Services客户端将待办数据推送到总部ESB上的代理服务 (Proxy) 。
2) 总部ESB上的代理服务 (Proxy) 将待办数据传送给业务服务 (Business) , 业务服务将待办数据传送给总部门户待办服务 (Web Services服务端) ;其次总部待办库将待办数据发送到总部ESB待办分发代理服务上, 总部ESB待办分发代理服务将待办数据传送给总部ESB待办分发业务服务。
3) 总部ESB待办分发业务服务将待办数据发送给网省ESB待办分发代理服务。
4) 网省ESB待办分发代理服务将待办数据传送给网省ESB待办分发业务服务;网省ESB待办分发业务服务将待办发送给网省门户待办服务 (Web Services服务端) 。
5) 网省门户用户在网省门户中点击待办连接时首先通过网省目录拦截并认证。
6) 网省目录通过目录级联认证实现到总部目录的认证。
7) 完成到总部目录的认证后, 直接跳转到一级部署业务应用上处理待办。
一级部署业务应用产生待办事件时通过调用Web Service客户端Jar包中的方法, 将预先封装好的XML串发送到总部ESB上, 总部门户通过总部ESB接收该待办消息, 再通过网省标识判断, 若为总部待办就由总部门户处理, 若为网省待办直接推送到网省门户 (依托国网ESB二级级联) , 待办处理流程如图4所示。
由总部门户系统提供封装好的Web Service客户端Jar包供给一级部署业务应用调用, 该Jar包中含有门户系统提供给一级部署业务应用的证书及密钥, 待办参数通过证书签名及密钥加密后形成的密文, 传输到总部ESB的待办服务上, 总部门户通过总部ESB收到消息后通过证书解密并验证签名, 验证成功后将处理该消息 (见图5) 。
2.2 目录集成
身份目录为一级部署业务应用提供组织机构、用户账号信息。统一用户管理工具实现应用系统组织机构、用户账号等信息同步过程的集中管理、流程审批和审计监控[4]。一级部署业务应用与目录服务集成架构如图6所示。
用户通过操作统一用户管理工具改变存储在目录中的数据信息。普通用户只能修改本人基础信息, 如密码信息、用户中文名称等。目录管理员和业务应用系统管理员可以在权职范围内管理目录中组织机构和用户信息。需要登录一级部署业务应用的用户, 通过目录服务认证后, 由目录访问网关通过自动填表实现单点登录[3]。
2.3 应用集成
由于此前的业务应用皆为二级部署, 它们之间的集成为总部或网省层面的2个业务应用之间的横向集成, 其业务交互较少。当总部的部分业务应用率先从二级部署改为一级部署后, 不仅与总部的其他业务应用之间存在横向的集成, 还与网省的业务应用之间存在纵向的集成, 业务应用的服务化程度加深、业务交互增多, 网络链路更长, 通过ESB注册、管理以及智能路由的服务更多, 并可能存在大数据量的交互, 大大增加了集成的复杂性, 应用集成示意如图7所示。
针对总部一级部署业务应用与其他业务应用之间的横向集成, 业务应用可通过Web Services方式接入ESB, 通过ESB的消息智能路由来实现。
而对于一级部署业务应用与网省业务应用之间的纵向集成, 则可通过总部ESB与网省ESB的二级级联方式实现小数据量的服务交互;针对大数据量的服务交互, 则通过总部ESB与网省ESB的消息智能路由功能、总部数据交换与网省数据交换的数据传输功能相结合来实现。
各业务应用之间是以标准的Web Services方式接入ESB来实现集成, 并且由于集成需求和关系不同, 所以服务需求方、服务提供方、应用集成三方需充分分析、归纳集成场景, 并选择合适的实现方式 (同步返回、异步不返回、异步返回) 来完成服务的交互。
同时, 服务提供方提供服务时, 应贯彻SOA的理念, 严格遵循应用集成典型设计中的服务规范与约定, 如Web Services规范、JMS规范、命名规范、数据格式原则、服务设计原则、服务提供原则等。
2.4 数据迁移[5]
利用数据分析工具分析网省数据与国网数据存在冲突的范围, 有针对性的处理冲突数据, 消除冲突, 保证数据唯一, 然后合并到国网库中, 数据迁移过程示意如图8所示。
数据迁移时, 有2种类型的数据存在冲突风险。
1) 通过数据库脚本初始化的数据, 如角色、资源信息等;此种情况数据在各省公司及总部完全相同, 合并时仅需保留一份。
2) 涉及数据上报下发的业务数据。在两级部署中, 网省上报或国网下发是通过数据交换方式实现的, 数据上报下发时, 会创建一条与原数据主键相同的数据, 因而, 在数据迁移的过程中, 会产生主键冲突, 此种情况数据表均有2个特征:数据表中都包含网省标识字段;数据表中都包含组织机构或用户标识信息。
通过数据上报下发产生的主键冲突, 可确定冲突发生范围。为实现数据正确迁移, 将总部数据库作为目标库, 将各省公司数据库作为源库, 在迁移数据前对源库进行预处理, 引入数据权限配置表, 制定冲突数据合并规则, 消除冲突源, 从而实现数据的正确迁移。
引入数据访问权限配置表, 使用数据整合工具分析系统中所有上报 (下发) 表中每条数据, 根据上报 (下发) 字段的值、公司标识等信息得知该数据是否已上报或下发, 同时向数据访问权限配置表中插入数据。
数据冲突范围分析工具、数据上报下发统一管理模块和数据访问权限配置表在设计时统一考虑历史上报下发数据合并及一级部署后数据上报下发方式改变问题。其中, 数据访问权限配置表在历史数据迁移阶段记录了数据上报下发状态, 在一级部署系统运行阶段, 通过开发数据上报下发统一维护模块, 向各模块开发人员提供统一接口, 统一维护系统中各模块数据上报下发状态, 减少代码修改量和修改风险。
3 结语
本文主要从待办集成、目录集成、应用集成、数据迁移等方面介绍了国家电网公司综合管理类系统一级部署过程中的关键集成点, 为各在建及已建应用逐步向一级部署模式迁移提供指导, 最大程度地规避系统从两级部署到一级部署改造过程中的集成风险。
摘要：目前国家电网公司安全监督管理、政工管理、科技管理、纪检监察、班组管理、企协管理、国际合作、审计综合管理等综合管理类系统由两级部署到一级部署的改造工作已经完成。文章介绍了综合管理类系统一级部署总体技术架构, 重点分析了两级部署到一级部署改造的集成方案, 包括目录集成、待办集成、应用集成及数据迁移方案, 通过对综合管理类系统一级部署改造集成方案总结, 希望能对其他类型业务应用开展一级部署工作提供指导和借鉴。
关键词：一级部署,待办集成,目录集成,应用集成,数据移植
参考文献
[1]张键, 文爱军.国家电网公司信息化建设一级部署方案[J].电力信息化, 2011, 9 (4) :10–13.ZHANG Jian, WEN Ai-jun.First-order deployment scheme of information Construction in state grid corporation[J].Electric power IT, 2011, 9 (4) :10–13.
[2]胡奇.jBPM4工作流应用开发指南[M].北京:电子工业出版社, 2010.
[3]郑文平.企业门户 (Portal) 项目实施方略与开发指南[M].北京:电子工业出版社, 2013.
[4]DIMAGGIO L, CONNER M, KUMAR K, et al.Jboss Esb Beginner's Guide[M].American:Packt PublishingLimited, 2012.
部署模式 篇9
云[1]由概念转为企业实务, 应该是这三年来的相当明显的一大趋势。一部分云服务商搭平台, 推出公有云的云主机、块存储等等服务[2], 以求先有鸡后有蛋。另一部份服务商则在其传统系统集成和IT服务外包客户的IT架构转型时, 顺应客户需求的变化, 提供混合云的解决方案, 配合建设多租户云平台, 有蛋再有鸡。
企业用户的IT架构转型, IT系统中的应用服务迁移到云上时, 一个问题应运而生:用户业务信息系统原有安全防护需求如何满足?原有安全设备是否随迁入云?原有安全设备如何有效利旧?
云服务商一方面需要设计云平台的安全性[3], 以提供传统上已配备的安全服务功能、虚拟化多租户带来的隔离安全和东西向流量感知与控制等新功能, 另一方面也要面对多租户的个性化安全服务需求, 如何经济有效地去满足的问题。
1 安全服务的设计与实现
根据安全功能与云平台的耦合紧密程度, 可以分为三类设计。
其一是传统网络设计[4], 安全功能在云外存在, 把云平台视为一个逻辑大服务器, 以组网技术, 个性化地实施用户安全设备的串接。客户原配套的安全设备参与到云中虚拟私有网的组网中去, 继续发挥其特定的、高于云平台一般性安全配置的安全作用。此方案的核心是求解混合云组网模式。
这可细分为两个常规的应用场景。用户的一种应用场景是, 其在云平台上租用的云主机在用户整个企业IT系统中, 处于DMZ区或外网的位置。GRE隧道方式互联, 适合于云平台与企业内网互联;物理路由器配策略路由方式, 则适合于云平台的互联网出口也承担企业上网的主通道职责。因为由云平台软件构建的GRE隧道, 其带宽效率和稳定性有不足。相较采用传统路由器 (路由交换机) 操作系统提供的策略路由有优势。也可考虑使用SDN交换机, 基于Vx LAN技术来去做Overlay, 基于物理交换机来按需建隧道。其优点第一是隧道数简单;第二是吞吐大, 处理能力强, 可保证东西向流量的处理。
另一种应用场景是, 用户在云平台上租用的云主机在用户整个企业IT系统中, 处于内网的位置, 需要通过与用户其他子网的互联连通到互联网出口。这样, 客户原有安全需求, 可依然通过其原有安全设施的部署来实现, 不因为部分业务系统迁移到云平台而丧失防护。
其二是以云平台可选安全服务项形式, 内在地提供公共服务。这个思路是, 如果在云平台基础上, 再配置合适的第三方安全设施, 可满足客户对安全增值服务的需求, 即可不必再串接用户原有安全设备。这也可细分为两种模式。一是紧耦合的安全资源池模式。此种思路认为, 在云环境中, 安全同样是应该以服务的形式提供给租户。对数据中心而言, 自动化、可运维、出错率少是关键。基于此, 为严肃业务服务的云应该建立安全资源池。用户可通过安全业务编排, 编排服务链。服务链可以通过SDN交付至客户的逻辑网络, 同时, 服务链可以随用户业务负载变化。数据中心可根据虚拟网络功能及处理负载进行收费。紧耦合的另一优势是云环境下的监控和可视化, 并针对安全模型进行分析, 可以展现至租户、管理员等。可以为客户提供网络行为追踪回放, 安全预警等服务。对于管理员来说, 运维排错, 分析预测都是在云环境中需要的。同时这一模式的难点是, 紧耦合模式需要对云平台进行深度开发和定制, 并与第三方安全厂商紧密合作 (接口开放) 。
另一模式是松耦合的第三方安全设备接入服务[5]。相对松的耦合形式是, 在云平台出口交换机上, 物理上旁路、逻辑上串接安全设备。功能上可满足业务需求, 但操作上需要人工跨多个设备或平台界面, 对于运维排障工作带来风险, 也难以实现弹性配置、自服务的效果。
更关键的现实性或难点在于:安全是个无底洞, 第三方安全功能焉能配齐?通常易于部署配置的是防毒类产品 (主机层级部署) 和平台层级串接防火墙、负载均衡设备。
第三种设计思路可谓是中间道路, 即云平台第三方增强型公共安全服务+单租户安全设备混合云组网, 也就是说, 常规安全服务由云平台提供, 特殊需求则特定部署串接到用户混合云组网中。
正如图1所示, 作为云服务运营商, 提供传统IDC的安全内容 (物理安全、网络安全) , 结合云平台的安全措施, 即可构成云服务的常规服务。对于系统安全、应用安全和数据安全这样在客户虚机内部的安全需求, 则根据第三方安全产品的部署特点和租户需求的规模化特点, 作适宜的服务提供安排。
2 业界云安全服务比较
从现行提供云服务的技术实现来看, 业界主要的安全服务架构可分为三类。
第一类是SDN (软件定义网络) 实现安全。云平台软件定义、提供、配置、并可计量安全功能服务, 其优点是:功能内在于云平台, 安全成为各类资源池的一类;成本有优势;自服务便捷。缺点则表现为:软件实现, 性能有局限;且当前可实现功能有局限, 不是所有功能都可SDN。通常云平台都实现了FW;VLAN隔离等安全功能。
第二类是SMN (软件纳管网络) 实现安全。云平台通过与第三方安全设备 (API) 的互操作, 实现深度融合, 从云平台界面中实现编排配置、服务计量。其优点是:自服务便捷。缺点是需与安全设备商逐家沟通, 定制开发;且云平台如采用安全硬件资源池, 投资高;而安全VE版有限。此类方案的代表, 云杉可纳管绿盟的漏扫 (VE版) ;天融信、hillstone的防火墙;九州云纳管hillstone的防火墙。
第三类是由VLAN/Vx LAN对接外部安全设备。用户安全设备通过专线或VPN连接专用安全设备, 归入云内VLAN/Vx LAN实现云内流量外出前的安全处理。优点是, 用户按需配置安全设备, 个性化满足需求;利旧原有安全设备。缺点表现在:没有资源池化的复用优势;需要二层/三层网络互联的配置, 或较为复杂。
3 B类用户云安全服务典型案例
在YD云 (某运营云服务商云品牌) 中的某B类用户, 为满足等保要求, 需要挂载物理的防火墙、WAF、IPS等设备。
初始探讨了方案两种。一是网络安全设备IPS/IDS/WAF挂接在核心/出口交换机上。用户的配置公网IP的云主机在安全设备中可以直接进行安全检查, 但其配私网IP及基础网络IP的云主机则无法通过安全设备进行保护。
探讨方案二是在云平台万兆接入交换机上, 串联网络安全设备IPS/IDS/WAF。此方案下, 用户配公网IP的云主机流量不经过串联在接入交换机上的网络安全设备上, 而是随云平台原出口流向, 走核心交换机出口, 安全设备对公网流量起不到保护作用。此时, 用户配置云内基础网络 (平台私有) IP的云主机因直连接入交换机的私网与云内基础网络是互通的, 此部分流量可享有安全防护。这里要求网络安全设备提供DNAT, SNAT功能。
对于入流量, IP组为 (Internet访问IP, 客户公网IP) - (SNAT, DNAT) à (网络安全设备内网IP, YD云基础网络IP) 。在网络安全设备上记录响应的信息, 在出流量时要做逆变化。SNAT保证出流量时, 流量从客户网络设备原路返回, 而不是从YD云的出口去。DNAT则是入流量时直接访问YD内基础网络中的虚机。对于出流量, IP组 (基础网络IP, 客户网络设备内网IP) --客户网络设备进行 (SNAT, DNAT) à转化为 (网络设备公网IP, Internet访问IP) 。私有网络IP VM:私有网络IP VM通过GRE与安全设备打通后才会受到安全设备的保护。
结论是, YD云的云内网络无法接入安全设备, 安全方案要通过云外网络安全设备来实现, 其组网方案与传统安全解决方案无异。
物理专线之间的隔离目前比较折中的办法是通过交换机的ACL规则实现, 但这种方案会造成交换机的CPU使用率过高, 网络工程师不推荐使用。为了分担CPU负载, 最适宜的方案是云平台核心/出口交换机之上跑三层的路由交换机设上终结专线, 且其EIP逻辑接口上挂ACL。
4 总结和展望
企业IT架构的云化转型是一种趋势。这其中安全功能实现是转型中需要衔接好的一个重要功能域。对于云环境来说, SDN是一个理想的方向, 但目前业界的发展尚处在探索中, 尚未出现统一的标准和尽如人意的解决方案。于是, 云内云外各承担一步分安全功能, 共同满足用户需求是一个现实的路径。
不论SDN或是硬件耦合参与, 云平台纳管安全功能, 实现自动化、弹性资源提供都是一个诱人的选择, 这也是YD云将进一步完善服务内容的一个努力方向。
参考文献
[1]张弘.软件定义的新型网络节点设计研究.[D]成都:电子科技大学, 2013.
[2]龚向阳.一种面向多样化网络业务融合的SDN网络架构.[J]北京:北邮, 2013.
[3]赵恒.基于SDN架构的电信承载网和BNG设备演进思路.[R]河南:中国电信河南分公司, 2013.
[4]CISA 2015培训教材[D].上海:交大慧谷培训中心, 2015.
部署模式 篇10
关键词：ERP,集中部署,数据迁移,历史数据
0 引言
为深入推进国家电网公司“两个转变”和集团化运作, 实现业务响应更快速、管控更集中、服务更优质、工作更协同, 国家电网公司总部对信息系统由目前的总部、省公司二级部署向全公司集中部署转变, 提出了迫切需求。根据ERP系统集中部署建设工作的总体安排, 天津市电力公司被列为首批试点建设单位。该项试点工作在为其他网省公司积累经验的同时, 将显著提高天津市电力公司支撑业务的标准化水平, 满足业务响应更快速、管控更集中、服务更优质、工作更协同的要求, 促进业务共享融合和集约管控, 有效支撑“三集五大”建设。在ERP集中部署的背景下, 为了保证ERP系统集中部署后历史数据的可用性, 需研究出行之有效的数据迁移方案, 能够将各网省历史数据整理、转换、集中, 使得业务操作能够获得历史数据的支撑, 充分利用历史数据的价值。
1 系统现状分析
为确保新旧系统的顺利对接, 实现系统内历史数据的有效迁移, 需对ERP系统现状进行详细分析, 分析内容包括系统总体情况、试点单位技术现状及业务现状。
目前国家电网公司ERP系统为两级部署模式, 总部及大多数单位还部署有商务信息仓库 (Business Warehouse, BW) 、企业门户 (Enterprise Portal, EP) 等相关系统, 并通过一体化平台与外围应用系统集成。各省 (市) 电力公司ERP系统内包含大量的系统数据, 涵盖了各核心模块, 总数据量达13 TB左右, 因此对数据延续性要求很高。主数据的迁移范围 (数据对象清单) 需依据统一模板确定, 业务数据的迁移范围需综合考虑业务要求、迁移代价、法律与审计需求等因素, 进而得到确定。通过统计23家省 (市) 电力公司数据库容量, 得到ERP系统的数据量平均为0.73 TB;省 (市) 电力公司间ERP系统版本有所不同, 大部分公司为ECC6.0, 个别公司版本是在6.0基础上升级的不同EHP包, 系统和版本的差异将导致数据迁移及转换的复杂度进一步上升。
由于各公司使用的会计科目层次和内容不同, 将无法直接在控制区域层面实现合并。工厂编号及物料编码等信息在迁移中需重命名或重新编号, 号段的设计需由业务部门通盘考虑, 按统一模板来设计调整号码段[1]。在ERP数据归档工作中, 归档数据的配置信息若发生变化 (如公司代码等) , 需通过迁移转换服务才能恢复归档数据的正常访问。
系统技术方面, 变更过的数据仓库、数据字典 (Data Dictionary, DDIC) 对象将是迁移中蓝图分析的重要组成部分[2], 需要根据各省 (市) 电力公司的更改情况与统一模板对比, 决定是否保留或丢弃省 (市) 电力公司的定制化数据仓库及DDIC对象。
结合试点单位业务现状, 各模块数据迁移方案中包含以下重要关注点。
1) FICO模块:凭证分割未激活的单位未来实现凭证拆分的难度较大, 货币键是RMB的省 (市) 电力公司需通过货币键转换场景以转换成CNY。同时, 财务凭证、内部订单和控制凭证的数量多少均将直接影响转换时间的长短。
2) PS模块:试点单位存在非省 (市) 电力公司代码的项目 (例如归属于电力设计院、招投标公司、各供电公司等) , 可能涉及公司代码相关的转换场景, 如果公司代码降级为利润中心, 对未清业务数据的转换难度将加大。
3) PM模块:网省电力公司存在任务清单及维护通知, 需进一步确认是否与其他网省业务冲突, 再进一步评估是否在集中部署过程中实施切换。设备主数据、分类特性、工单类型等内容均需确认是否转换为集中部署方案规定的内容。
4) MM模块:对于已上线WM模块的试点单位, 存在仓位、转出单等主数据及业务数据。若集中部署不启用替代方案, 则须放弃精细的仓库管理能力。若需要WM功能支持, 则将增大未清业务迁移的难度。
2 数据迁移典型场景及方案
通过对ERP系统现状的综合性分析, 针对各核心模块, 提出了模块内数据迁移的设计方案[3], 利用系统场景切换工具 (SAP Landscape Transformation, SLT) 实现相应的数据迁移, 针对各模块典型场景下的历史数据迁移展开了分析研究。系统数据迁移SLT方法论如图1所示。
2.1 财务场景
财务模块中涉及历史数据迁移的场景主要包括组织架构转换场景设计、凭证转换场景设计及资产转换场景设计。
2.1.1 组织架构转换场景设计
基于设置模式, 存在4种组织架构转换的场景, 即公司代码转换为利润中心、公司代码重组、利润中心及成本中心重组。
1) 公司代码转换为利润中心的场景设计主要按照组织架构编码规则, 创建新的利润中心;将现有公司代码下的数据转换到新的利润中心下, 同时合并该公司代码到其他保留的公司代码中;公司代码下所关联的所有组织结构按需重命名, 将其迁移到其他公司代码下。公司代码转换为利润中心场景如图2所示。
2) 公司代码重组包括公司代码重命名、公司代码合并、公司代码拆分等情况。按照组织结构编码规则, 即《国家电网公司成熟套装软件信息分类与编码方案》编码清单, 创建新的公司代码。将需要重组的公司代码通过SLT执行公司代码重组, 公司代码的拆分涉及到主数据及业务数据的拆分迁移, 需确定拆分规则, 并依据此规则运用SLT专业工具及方法将原公司代码下的数据迁移到新系统的新公司代码下。公司代码重组场景如图3所示。
3) 利润中心及成本中心重组包括利润中心重命名及合并、成本中心重命名及合并, 按照组织结构编码规则, 创建新的利润中心与成本中心, 通过SLT执行相应重组工作[4]。由于表外科目尚未通过主数据管理 (Master Data Management, MDM) 模块集中管理, 需梳理各网省电力公司对于表外科目的核算需求, 用于统一的配置及编码, 避免数据冗余和重码。科目主数据重组场景如图4所示, 存在科目合并、拆分及重命名等情况, 按照对应编码规则进行创建, 通过SLT执行会计科目的转换等。
2.1.2 凭证转换场景设计
业务数据迁移包括财务凭证、利润中心凭证及成本中心凭证等数据, 数据迁移过程中要保证3类凭证的关联性。迁移后系统的配置与原系统不同, 需通过校验系统配置, 确保迁移后数据与新系统配置不冲突, 最终根据数据转换规则执行数据转换。
2.1.3 资产转换场景设计
涉及到的资产数据包括资产主数据和资产业务数据, 即资产明细等。按照资产编码规则创建新的资产编码, 资产主数据存在折旧码、折旧年限变更等情况, 在数据迁移过程中要保证数据连续性, 即原系统中的资产变更记录同时迁移到新系统中。
2.2 人资场景
人资模块中涉及历史数据迁移的场景主要包括人事事件转换场景、组织架构转换场景、主数据编码转换场景及薪酬数据转换场景。
1) 人事事件转换场景:人事事件记录了员工从进入到退出企业所发生的所有人事变动情况, 各单位在规范化之前存在本单位特有的人事事件数据编码, 需统一新旧人事事件类型及原因编码对应关系, 进行数据转换。
2) 组织架构转换场景:组织架构是人力资源结构的重要组成部分, 主要涉及人事范围、人事子范围、员工组、员工子组及薪资核算范围转换等。
3) 主数据编码转换场景:人力资源管理主数据主要包括组织单位、职位、职务、人员和培训, 其中培训管理已完成二级部署, 编码规范统一, 无需进行特殊转换。
4) 薪酬数据转换场景:主要涉及基本工资体系数据、工资项数据转换。基本工资体系数据转换包括工资等级类型、工资等级范围、工资等级组、工资等级级别;工资项数据转换需结合各网省系统现状设计统一规范编码后再进行对应工资项数据转换, 薪资核算结果表 (RT) 数据主要转换对象为非标准工资项数据[5]。
2.3 项目场景
项目模块中涉及历史数据迁移的场景主要包括项目主数据场景、项目用户状态场景及网络编码场景。
1) 项目主数据场景设计:项目模块的主数据分为项目标准架构、项目标准网络及服务主数据。在收集各网省的项目主数据基础上, 区分各网省的项目主数据编码段, 以2位网省代码进行区分, 项目标准架构同时遵循信息技术[2010]1336号和[2011]209号文, 最后使用SLT工具转换相应主数据。
2) 项目用户状态场景设计:项目用户状态由状态参数文件、状态节点及节点系统控制3部分组成。
3) 网络编码场景设计:需考虑主键编码重复的情况, 整理和统计各网省的网络编码, 根据业务组提供的网络编码规则, 在原网络编码前增加两位网省的公司代码, 运用SLT专业工具和方法将网络编码迁移到新系统。
2.4 物资场景
物资模块中涉及历史数据迁移的场景主要包括物资主数据转换场景及业务数据转换场景。
1) 物资主数据转换场景:物资管理模块主数据包括物料主数据、供应商主数据、客户主数据、批次主数据。各省 (市) 电力公司的物料主数据已按物资集约化进行了统一, 无需转换, 供应商、客户、批次存在差异。以供应商主数据为例, 按照主数据设置规则统一规范各类供应商的编码范围及编码规则, 对各单位需要迁移的供应商按照新的编码规则和号码范围进行统一编码, 通过SLT进行数据转换。如果供应商主数据在新系统中已经存在, 只需要扩展本公司的相关数据。
2) 业务数据转换场景:包括采购申请、采购订单、询价单、框架协议、预留、物料凭证、发票、内外向交货单、销售订单及盘点凭证等。各单位业务数据需要进行统一规则转换, 以采购申请、账户分配类别为例, 统一分配各单位采购申请的凭证类型和号码范围, 统一屏幕必输字段、定制化字段或按需求分别设置屏幕, 并整理出新旧字段的对应规则;对各单位需要迁移的采购申请按新的编码规则和号码范围进行统一编码, 通过SLT进行数据转换。
2.5 设备场景
设备模块中涉及历史数据迁移的场景主要包括组织架构场景及业务数据场景。
1) 组织架构转换场景:设备管理的组织结构包括计划/维护工厂、工作中心与计划员组。各网省均采用8位编码方案, 但编码规则不一致。根据新的编码规则对工作中心进行重新编号, 由用户确认新旧编号对应关系表进行数据转换。
2) 业务数据转换场景:PM设备模块的业务数据包括维护计划、维护订单及通知单等。对PM作业类型需做两级定义, 第一级用1位字母标识维修费用分类, 第二级用2位数据标识维修性质。
3 数据迁移方案实施效果
国网天津市电力公司ERP系统的数据迁移属于从新总账源系统到新总账目标系统的迁移, 所以基于新总账的数据迁移方案, 最终实施工作实现了以下几方面的成果。
1) 完成了数据统一模板的搭建。系统数据迁移过程中的迁移环境包含了生产系统中完整的生产数据, 并利用统一模板系统的拷贝环境作为数据迁移测试;搭建完成了包括天津市电力公司子模板在内的统一模板系统, 包括人资组织架构及主数据模板、物资主数据模板、财务主数据模板、设备资产模板及项目主数据模板等;确定了统一模板配置点与天津市电力公司系统配置差异点的转换规则, 为系统数据迁移提供了有效的模板准备。
2) 完成了业务数据对象的梳理。通过与业务部门的积极沟通, 梳理了数据对象的迁移属性, 包括对象是否迁移、对象迁移范围、天津市电力公司ERP系统中各业务数据的对应规则等, 为迁移工作铺垫了全面的数据基础。
3) 依托迁移方案, 开展了系统数据的整体迁移实施工作。实施过程中, 首先完成了业务对象迁移蓝图设计, 针对各核心模块, 提出了模块内数据迁移的设计方案, 并详细建立了各类实际场景。根据各场景设计中的实际分析, 研究各模块典型场景下的历史数据及迁移方式。天津市电力公司ERP系统的业务复杂度高, 业务对象的数量以及匹配关系复杂度高, 数据量相对较庞大, 但参照总体方案, 整体数据实现了顺利迁移。
4) 以源系统及目标系统的数据结果为依据, 开展了相关数据的测试工作, 确保历史数据迁移工作的质量。由于该方案的数据迁移是从底层数据表上做直接修改, 而不是按照应用逻辑来处理, 所以可能存在数据遗漏或者不准确的映射规则造成数据不一致问题, 因此测试工作极具必要性。方案实施后, 制定了明确的测试计划, 测试过程包括功能测试、用户接受度测试、集成测试及性能测试, 在定义测试环境及测试策略后, 完成迁移方案的整体测试, 确保方案的迁移效果。
5) 完成了其他应用性调整工作, 成功解决了天津市电力公司本地化部分特殊业务对象存在的应用性问题。由于天津市电力公司的业务对象较复杂, 需要调整的地方较多, 因此实施过程中进行了底层定制化信息方面的调整, 调整了在上一阶段分析出的底层对象冲突, 同时依据业务流程的变动, 调整了相应业务对象的迁移范围。
4 结语
本文通过详细分析ERP系统应用现状, 从场景设计及技术方案研究等角度, 对集中部署工作的历史数据迁移工作进行了详细的分析与阐述, 重点描述了ERP系统各核心模块数据迁移的设计方案。本文所提出的历史数据迁移方案已经部分应用到国家电网公司ERP系统集中部署实施工作中, 并取得了工程实际的应用经验。ERP集中部署工作覆盖面广, 实施内容复杂而极具挑战性, 未来将在ERP系统权限体系研究方面开展深入研究工作, 进一步推进ERP系统集中部署工作的实施及贯彻。
参考文献
[1]詹伟.湖北电力ERP数据仓库的研究与应用[J].电力信息化, 2011, 9 (3) :21–23.ZHAN Wei.Research and application of ERP data warehouse in Hubei Electric Power Company[J].Electric Power IT, 2011, 9 (3) :21–23.
[2]毕子健.电力物资管理ERP系统设计研究[D].北京:华北电力大学, 2011.
[3]雷晓萍.青海省电力公司ERP商业智能的设计与应用[J].青海电力, 2011, 30 (1) :36–40.LEI Xiao-ping.Design and application of ERP business intelligence in Qinghai Power Company[J].Qinghai Electric Power, 2011, 30 (1) :36–40.
[4]周小明, 赵永彬, 韦明.电力企业ERP运维数据中心的设计与应用[J].电力信息化, 2010, 8 (7) :104–108.ZHOU Xiao-ming, ZHAO Yong-bin, WEI Ming.ERP data warehouse design and application in electric power company[J].Electric Power IT, 2010, 8 (7) :104–108.
