1、企业 IT 技术架构调研汇报调研工作汇总1调研结果分析2技术架构规划建议提纲3技术架构调研工作汇总时间2016/07/19 2016/07/28人员投入30 人天调研范围十三五 IT 规划目标、技术架构现状访谈部门及人员信息技术部领导及技术骨干 12 人以上系统调研表调查表：9 份系统汇总表：2 份，调研内容包括服务器、存储、网络、桌面、HPC 等共 73个主要业务系统的技术架构信息，涉及服务器总数为 94 台文档清单 S01-IT 战略调查表 S02-基础设施调查表 S03-技术平台调查表 S04-网络调查表 S05-桌面调查表 S06-应用系统调查表-PDM S07-应用系统调查表-ERP
2、 S08-HPC 调查表 S09-数据中心运维调查表 S10-数据库系统汇总表 S11-UNIX 服务器汇总表企业架构的分析思路业务架构应用架构技术架构数据架构概念级（策略）功能级（设计）运营级（实施）组织结构设计业务流程数据模型应用功能模型应用设计应用参考架构平台设计存储设计网络设计安全设计数据库设计数据仓库设计数据部署数据存储及管理应用部署和运行设施地域(数据访问和分布原则）(参考架构、模式、分组)业务建模和关系(流程、活动、事件、信息、角色、地域）技术构件(用户群、参考架构等）应用平台运营 数据库存储运营网络运营IT 运维管理管控是架构演进和持续运营的基础架构是指导信息化建设的基本原则标
3、准是确保架构落地的规范化保证现状调研总结：架构层面-业务架构应用架构 数据架构技术架构业务建模和关系应用功能模型数据模型技术构件(流程、活动、事件、(参考架构、模式、分组)(数据访问和分布原则）(用户群、参考架构等）信息、角色、地域）组织结构设计应用设计数据库设计平台设计存储设计业务流程应用参考架构数据仓库设计网络设计安全设计-设施应用数据部署应用运营数据运营地域部署和运行数据存储及管理网络运营IT 运维管理大部分系统按照垂直业务线进行建设，形成互相隔离的竖井，难以适应未来智能制造统一管控的业务需求架构层面问题发现：公司拥有多种不同型号的服务器、存储等基础设施，但缺乏统一的资源规划和管理方法；
4、ERP、PDM 等核心业务系统的应用及数据 库使用单点部署，若出现故障可能影响正常的生产运营。各业务系统之间的服务集成和安全管理采 用点对点方式，增加了系统建设和管理的复杂度。基础设施概念级（策略）功能级（设计）-运营级（实施）现状调研总结：标准层面基础设施业务架构应用架构 数据架构技术架构业务建模和关系应用功能模型数据模型技术构件(流程、活动、事件、(参考架构、模式、分组)(数据访问和分布原则）(用户群、参考架构等）信息、角色、地域）组织结构设计应用设计数据库设计平台设计存储设计业务流程应用参考架构数据仓库设计网络设计安全设计-设施应用数据部署应用运营数据运营地域部署和运行数据存储及管理网络
5、运营IT 运维管理业务系统缺乏统一标准和规范，导致不同系统之间存在较大的差异，难以实现集成和优化标准层面问题发现：缺乏集团层面的技术标准和规范；公司采用了多种版本的中间件和数据库，系统建设标准不一；系统配置以人工方式为主，难以保证基础环境的一致性。概念级（策略）功能级（设计）运营级（实施）现状调研总结：管控层面-业务架构应用架构 数据架构技术架构业务建模和关系应用功能模型数据模型技术构件(流程、活动、事件、(参考架构、模式、分组)(数据访问和分布原则）(用户群、参考架构等）信息、角色、地域）组织结构设计应用设计数据库设计平台设计存储设计业务流程应用参考架构数据仓库设计网络设计安全设计-设施应用
6、数据部署应用运营数据运营地域部署和运行数据存储及管理网络运营IT 运维管理需要结合创新技术，建立标准化的管控流程，提高运维效率，合理利用资源。管控层面问题发现：未能建立统一的信息化管控流程、方法和 组织体系；现有的基础架构较为复杂，导致管控工作 难度大、任务重；没有实现端到端的业务监控和问题诊断，不能及时预警和解决业务中断。基础设施概念级（策略）功能级（设计）-运营级（实施）调研工作汇总1调研结果分析2技术架构规划建议提纲3调研分析框架网络域基础设施域（服务器、操作系统、存储&存储网络）技术平台域（应用服务器，数据库）数据中心运维域桌面域HPC 并行计算域应用域调研分析采用分层分域的方法对公司
7、的信息化建设现状进行全面梳理，作为技术架构规划的参考依据。技术架构的设计内容主要包括：基础设施、技术平台、信息化标准和信息安全体系。技术架构的设计目标包括：构建双活数据中心，并推进异地容灾数据中心建设；积极运用云技术、服务化、虚拟化等理念和技术，完善计算、存储、网络等资源的管理和应用；IT 运维管理的规范化和流程化；构建面向智能制造的网络环境。技术架构的整体设计目标技术平台基础设施信息化标准信息安全体系主题数据基础数据业务数据产品研发生产制造供应链管理运营管控客户管理业务架构应用架构数据架构技术架构元数据技术服务试验交付架构设计的内容框架战略经营市场营销工艺设计生产制造供应链客户产品研发技术架
8、构的指导方针和原则指导方针技术架构设计应该充分结合先进适用的信息技术，最大程度的利用已有的软硬件和数据资源；技术架构设计应该“面向应用，注重体系”；适度超前设计原则需要考虑未来 5 年的信息化建设需要需要考虑创新技术（例如虚拟化等）的应用；需要具备良好的可扩展性和可管理性；需要考虑应用、数据的分级资源管理模式；合规性设计原则需要保证涉密业务的高度安全；需要遵循 BMB 17、20 等系列安全规范技术架构参考：应用架构概要设计人力资源管理财务管理任务管理流程管理行政办公项目管理产品研发产品全生命周期管理产品协同设计工艺集成管理生产制造企业资源规划ERP3.0制造执行系统MES供应计划供应链管理采
9、购管理供应商管理交付管理客户管理客户关系管理 CRM维护大修外场服务技术培训数字化标准信息安全应用架构规划主要面向运营管控、产品研发、生产制造、供应链管理和客户管理等五大应用平台的建设，预计新建和完善 37 个主要应用系统（其中新增 23 个）。运营管控基础设施域和技术平台域的主要组件基础设施层技术平台层SAN 存储IBM DS 系列，Fujitsu DX 系列等关系型数据库Oracle DB,MySQL,SQLServer小型机服务器IBM Power 系列,Fujitsu M 系列等x86 服务器IBM,Fujitsu,HP,Dell等UNIX 操作系统IBM AIX,Sun Solari
10、sWindows 操作系统Microsoft Windows门户框架IBM WebSphere Portal反向代理IBM WebSeal身份认证/访问授权IBM TAM/TIMWeb 服务器IBM IHS,ApacheFC-SAN 网络IP 网络应用开发框架普元 EOS服务总线普元ESB流程平台普元 BPS负载均衡格尔前端接入应用框架应用Java EE应用服务器服务器IBM WebSphere,Apache Tomcat数据库操作系统服务器存储网络存储协同应用服务器Lotus Domino非关系型数据库Apache HBase,Domino DB.Net 应用服务器MBMCTivoli运维管
11、理（，）NAS 存储宏衫基础设施的逻辑拓扑基础设施域现状调研：服务器及操作系统目前公司共有各类服务器 94 台（套）（不包括 HPC 设备，一箱刀片服务器按照一台计数），放置于 35 个机柜。不同服务器设备之间采用 3 个 VLAN 进行逻辑隔离。设备类型：主要包括小型机服务器和 x86 服务器，其中，IBM，Fujitsu 和 Sun 的小型机共 21 台，x86 服务器共73 台（套），使用寿命超过 7 年以上的服务器占比48%。系统管理：小型机服务器上主要采用 AIX 和 Solaris 等UNIX 操作系统，x86 服务器上则主要采用 Windows 操作系统；其中，UNIX 服务器的
12、升级会根据需求不定期进行，Windows 服务器则采用域管理进行策略推送；资源使用：整体资源使用状况较为紧张，ERP 和 PDM 等关键应用的资源利用率可达 90%以上，并出现过资源耗尽宕机的情况；资源虚拟化：小型机上采用了逻辑分区，x86 服务器上暂未使用虚拟化。1567380706050403020100服务器类型IBM 小型机其它小型机x86 服务器目前公司共有 SAN 存储设备 8 套，整体可用容量为 298 TB，另有 NAS 存储设备 1 套，可用容量为 40 TB；设备类型：SAN 存储设备主要用于业务应用构建，其中核心存储 DS 8000 已经使用 9 年以上，无法扩容，也无技
13、术支持；NAS 存储设备为宏衫+安全设计机头，仅用于工作数据交换；存储管理：SAN 存储设备采用 4 节点 SVC 统一管理，以手工方式分配存储资源。由于整体资源非常紧张，目前仅能满足各应用的存储容量要求，无法满足存储性能要求。存储网络：统一采用 4G FC SAN，通过 2 套 B80 级联B24 SAN 交换机连接 SVC 和各存储，目前 FC SAN 还剩余 20 个端口；存储分级：目前没有采用存储分级策略，也没有分开涉密网和非涉密网存储，计划将 EMC 存储用于非涉密网；存储备份：目前仅使用 Network Backup 备份 PDM 和ERP 等核心系统数据，每周一全备，每天增量备份
14、，每月全备到物理带库。基础设施域现状调研：存储及存储网络型号数量可用容量(TB)已用容量用途IBM DS800012424核心应用IBM DS530013024DS8000VDMFujitsu DX9013225部门应用Fujitsu 刀片存储132/刀片存储华为 5000112040DS8000VDM谷数 8600148/备份谷数 66001/备份测试EMC112/计划用于非涉密网合计8298SAN 存储设备统计基础设施域：主要发现与优化建议主要发现设备使用年限过长：大部分小型机服务器的服务年限甚至超过 9 年，不仅导致部分关键应用的性能问题突出，而且由于缺乏厂方技术支持，出现故障可能无法修
15、复；缺少建立资源规划体系：整体的计算、存储资源均非常紧张，同时由于缺乏合理的资源分级制度，导致有限资源无法得到合理利用；操作系统有待更换：大部分关键应用采用了可靠性较差的 Windows操作系统部署，可能影响业务系统的可用性。没有专门的开发测试环境：缺乏专门的开发测试环境，曾出现应用未经过充分测试而导致生产环境关键数据丢失的事件。设备配置不规范：计算和存储资源配置以人工方式为主，无法保证规范性。以时间配置为例，由于各服务器之间没有配置统一的时钟服务器，将出现时间不同步，导致应用集群或数据集群出错；优化建议-建立设备的生命周期管理体系，明确设备报废或降级使用标准，逐步淘汰老旧设备；-建立资源分级
16、制度，为不同密级别、不同类型的业务应用分别配置合理的计算存储资源；-采用商用的 UNIX 和 Linux 操作系统替代 Windows；-建立专门的开发测试环境，可以先利用部分老旧设备进行搭建；-规范设备配置标准，建立统一的时钟、域名、DNS 等配置。目前公司共有各类数据库 75 套，以 Oracle 数据库为主，共 46 套；关键业务系统均采用 Oracle 数据库，其它数据库包括 SQLServer，MySQL，Domino,Hbase，以及部分平台软件中自带的 DB2 等。部署环境：关键业务系统的 Oracle 数据库主要部署于 IBM 和富士通小型机服务器，所采用的操作系统为 AIX
17、或 Solaris；其它数据库则主要部署于 x86 服务器，所采用的操作系统为 Windows；部署模式：大部分业务系统的数据库采用单点部署，仅有 HR/财务系统的 Oracle 数据库采用了 RAC 集群部署，仅有 PDM 系统的 Oracle 数据库具备备份能力（基于 Oracle Active Data Guard 构建）；OLTP和 OLAP 数据库均未分离；数据库版本：关键业务系统的数据库版本以Oracle 10g,11g 为主，极个别系统采用 Oracle 8i,9i。技术平台域现状调研：数据库46131012350454035302520151050数据库数量统计OracleSQ
18、LServerMySQLDominoHbase其它关键业务系统的数据库运行环境131102468101214AIXSolarisWindows技术平台域现状调研：关键数据库列表序号主机型号采购年限CPU/内存业务系统数据库大小（GB）版本是否 RAC1IBM P5952010.0612/98GPDM140011.2.0.3否2IBM P5902007.054/8GPDM 容灾140011.2.0.3否3IBM P5902007.0512/65GERP328011.2.0.3否4IBM P5952009.1112/44GHR,财务45011.2.0.3是5IBM P5902007.058/32G
19、HR,财务45011.2.0.3是6IBM P5902007.128/16GERPS8010.2.0.5否7IBM P5902007.128/16GCAPP17510.2.0.5否8IBM P5702009.034/16G数控应用47010.2.0.5否9Fujitsu M10-4s2014.0232/131GVPM1810.2.0.5否10IBM P5702005.118/7GTDM510.2.0.5否11IBM P5702010.105/40GIT 运维511.2.0.3否12IBM P5702010.105/40G门户510.2.0.5否13宝德 PR4860R2015.064/64G驾
20、驶舱511.2.0.1否14Sun Fire V892006.114/16G老财务339.2.0.4否15IBM P5952009.1120/80GOA3.01.410.2.0.4否技术平台域现状调研：应用服务器目前公司共有 73 个业务应用，主要基于 Java EE 平台构建，另有少量应用基于.net 和 Domino 平台构建。其中，Java EE 应用服务器主要包括WebSphere 和 Tomcat。部署环境：大部分应用服务器部署于 x86 服务器，所采用的操作系统为 Windows，少量应用服务器（例如PDM）部署于 IBM 小型机，所采用的操作系统为AIX；部署模式：大部分业务应用
21、（例如 PDM）采用单点部署，部分关键应用（例如 ERP、门户、OA 等）采用集群部署模式；同时，由于应用服务器之间没有采用统一时间，可能导致应用集群出错。应用服务器版本：Java EE 应用服务器主要采用 WebSphere（6，7.1 等版本）以及Tomcat（5，6，7 等版本）；WebSphere 8.5 版本已经采购，但尚未应用。PDMTomcatWebSphereDomino门户WebSpherePortal关键应用的运行环境ERPOA-PDM 应用：单节点应用，部署于 IBM 小型机上的Tomcat 应用服务器；-ERP 应用：8 节点应用集群，部署于 x86 平台的 WebSp
22、here 应用服务器；-OA 应用：2 节点应用集群，部署于 x86 平台的 Domino应用服务器；-门户应用：2 节点应用集群，部署于 x86 平台的 WebSphere Portal 服务器。技术平台域现状调研：应用框架及前端接入目前公司采用的应用框架主要包括：集成框架：公司先后采购过 IBM MB/MQ 及普元 ESB 服务总线用于应用集成，但目前仅有门户和 HR 通过普元ESB 实现集成，其它应用之间的集成通常采用基于数据库链接（data link）或 Web Service 方式的点对点集成；流程平台：OA，门户等应用均采用普元 BPS 作为基础流程平台；开发框架：除 OA、门户等
23、应用外，大部分 Java EE 应用均采用普元 EOS 作为基础开发框架；门户框架：公司门户基于 IBM WebSphere Portal 的门户框架构建。反向代理典型应用的部署架构（门户）负载均衡负载均衡反向代理Web 服务器门户应用门户应用目前公司采用的前端接入组件主要包括:硬件负载均衡反向代理Web 服务器（软负载均衡）身份认证/访问授权等其中，身份认证/访问授权组件仅有门户系统采用。技术平台域：主要发现与优化建议主要发现业务可用性不高：大部分应用和数据库均采用单点部署模式，一旦出现单点故障即导致业务不可用；标准规范不统一：各业务系统的开发和部署没有统一标准，应用平台、应用服务器和数据库
24、服务器的版本较多，部分老版本已经没有技术支持，建议考虑采用规范化的开发、应用和数据平台；竖井式应用架构：各业务系统之间没有采用统一的服务集成和认证授权，而是采用点对点的集成方式。随着业务应用规模的扩大，难以进行管理和维护，也增加了应用安全的隐患；数据库分离：OLTP 交易和 OLAP 分析的数据库没有分离，使得ERP、PDM 等关键应用的数据库性能压力较大，影响业务应用的正常使用；容灾备份：除 ERP、PDM 等少量关键数据库之外，大部分数据库缺乏备份容灾能力，可能导致业务数据的丢失。优化建议-关键应用采用集群部署模式以消除单点故障；-为不同类型应用设计统一的开发和部署规范；-采用统一的企业服
25、务集成平台和认证授权平台-将 OLTP 数据库和 OLAP 数据库分离，建立专门的分析数据库；-为不同类型的业务系统设计响应的数据备份和容灾策略，以保证关键数据的可靠性。应用域现状调研：PDMPDM 应用是公司的核心应用之一，目前整体部署在一台 P595 服务器上，多次出现因应用资源耗尽而导致宕机的情况，严重影响了业务的正常运行。业务要求：平时使用人数 200 人，业务高峰期 500-600人，用户类型主要包括 CAD，CAPP 和普通用户，业务要求提供 7x24 可用；部署架构：PDM 采用 BS 架构的三层设计，应用服务器基于 Tomcat 和 Windchill 平台构建，数据库服务器则
26、采用 Oracle，并实现了 Data Guard 容灾。目前数据库容量1T，电子仓库非结构化数据 6T；主要问题：由于应用与数据库共享一台老旧的 P595 设备，资源无法扩展，导致应用服务器内存长期消耗超过90%，时有内存消耗殆尽而导致停机；同时，CPU 资源的整体利用率不高。Web 服务器 Apache应用服务器TomcatServerManagerMethodServer目录服务器LDAP1 个 Apache 实例，4G 内存6 个 Tomcat 实例每个 6G 内存1 个 JVM，8G内存8 个 JVM，8G内存WindChill 服务器数据库服务器Oracle电子仓库应用服务器LPA
27、R1（40核，148G）数据库服务器LPAR2（20核，96G）PDM 部署架构P595 服务器PDM 应用：现有优化计划及建议现有优化计划信息技术部对 PDM 系统的设计了如下的优化计划：应用与数据库分离：将 PDM 的应用服务器从现有的逻辑分区迁出，将原有的应用资源划给数据库的逻辑分区使用；另行采购服务器用于 PDM 应用服务器的构建；应用的分布式改造：改造现有的应用，使其可采用分布式部署：-现有 Windchill 9.0 版本不支持完全意义的分布式架构；-若升级 Windchill 11 即可支持分布式架构，但可能需要大量的 license 费用投入；应用部署环境的选择：以现有的 AI
28、X 应用环境为基准，分别采用 Fujitsu M10 服务器（Solaris OS）和 2 路 E5 x86 服务器（Linux OS）进行了应用基准性能测试，效果显示 AIX Solaris Linux。建议-在应用与数据库分离的基础上，还需考虑为数据库搭建集群环境，确保关键数据的安全性；-现有性能基准测试中，三种类型服务器（P595，M10，x86）的配置相差较大，建议采用近似配置的服务器重新进行测试，评估应用部署环境的合理选择。应用域现状调研：ERPERP 应用是公司的核心应用之一，目前采用分布式应用+单机数据库的部署模式。ERP 应用的整体性能较差，严重影响了业务部门的工作效率。业务要
29、求：用户数为 1200 左右，业务高峰可达 300-400并发。业务要求提供 7x24 可用；RTO 及 RPO 要求：目前上班时间允许停机 10 分钟，停机超过 1 小时需要发公告；作为核心业务系统，PDM 的建设要求尽可能减少数据丢失；部署架构：ERP 采用 BS 架构的三层设计，应用服务器采用 WebSphere，基于 8 台 x86 服务器构建，数据库服务器则采用 Oracle，基于 P590 逻辑分区构建；主要问题：-查询分析和业务交易共享同一个数据库，导致业务高峰期的数据库的资源占用极高，性能响应慢；-ERP 平台由金航数码开发，但模块由不同供应商提供，业务逻辑复杂，维护困难；负载
30、均衡应用服务器WebSphere数据库服务器Oracle应用服务器WebSphere应用服务器WebSphereERP 部署架构负载均衡ERP 主要模块包括：任务管理、合同管理、计划管理、采购管理、库存管理、质量管理、计量技术管理、MES、成本管理、外协合作；明年计划推进单机质量档案，完善 MES 无纸化等模块。ERP 应用：主要发现与优化建议主要发现存在单点故障：数据库采用单点部署模式，可能出现单点故障而导致业务不可用；数据分析和业务处理未分离：ERP 应用中 50%的数据已经关闭，但历史数据并没有归档，而是拷贝复制的方法用于数据分析，导致影响业务处理的性能；随着无纸化 MES 的推进，ER
31、P 系统系统会有大量非结构化数据（图片、报表）存储，对数据库的能力要求更高；设备能力不足：核心数据库部署于 P590 服务器上，处理能力有限，导致数据库成为整个应用的瓶颈；此外，负载均衡设备不能正常工作，经常将所有请求转发至同一个应用节点，导致节点宕机；缺乏协作环境：由于没有测试平台，曾经出现未严格测试的代码直接在生产环境中上线，导致关键业务数据的误删除和丢失。优化建议-采用集群方式构建 ERP 的核心数据库，避免可能的单点故障；-构建专用的分析数据库，并将 ERP 的历史数据归档，减少对业务处理的压力；-更新数据库服务器和负载均衡设备，避免设备老旧而出现的故障风险；同时可考虑采用更高性能的闪
32、存阵列，优化数据库能力；-可利用老旧设备构建专用的开发测试环境。网络域现状调研目前公司主要有三套物理隔离的网络，每套物理网络有 1-2 套逻辑隔离的网络，主要包括：区域 1-互联网，金航商网；区域 2（园区网）-涉密网，工控网；区域 3-考勤网。网络架构及速率：目前采用接入-汇聚-核心的三层架构，采用接入交换机 900 台，汇聚交换机 5 台，核心交换机 2 台，提供 1G 到桌面、10G 上行速率，网络速率无明显瓶颈；网络可用性：目前仅有核心交换机有高可用设计，其它层级都是单点接入；网络监控：采用盈高准入系统来监控接入交换机，采用 BMC 监控系统管理汇聚和核心交换机。现有网络整体运行平稳，
33、故障较少；网络设计：全网配置了 DNS，涉密网中只有外联区域使用了 NAT；未使用 SDN/NFV 等功能。互联网仅有指定位置的指定终端可接入金航商网规划用于电话会议、办公、订餐等功能，考虑提供无线网络接入涉密网用于厂区内数据中心、办公设备接入工控网用于工控设备的接入考勤网仅供考勤打卡系统使用区域 1网络分区概况区域 2（园区网）区域 3网络域：主要发现与优化建议主要发现涉密网和工控网的隔离策略：涉密网和工控网仅采用逻辑隔离，存在安全隐患，目前考虑的方式包括：-物理隔离：使用人工刻录光盘的方式在两个网络间传输数据，主要问题是效率不高；-网闸隔离：采用网闸隔离两套网络，但目前测试发现网闸的丢包率较高（5%）；网络管理不规范：没有专门的设备管理网络，所有设备的管理口都是接入到数据网络中；同时，目前也没有形成专门的网络监控和管理机制，都是事后被动解决问题。没有无线网络：出于安全考虑，公司目前没有
