集团云计算咨询项目详细设计方案

1、PAGE 集团云计算咨询项目详细设计方案目录 TOC o 1-3 h z u HYPERLINK l _Toc47295570 1前言 PAGEREF _Toc47295570 h 3 HYPERLINK l _Toc47295571 1.1背景 PAGEREF _Toc47295571 h 3 HYPERLINK l _Toc47295572 1.2文档目的 PAGEREF _Toc47295572 h 3 HYPERLINK l _Toc47295573 1.3适用范围 PAGEREF _Toc47295573 h 3 HYPERLINK l _Toc47295574 1.4参考文档 PA

2、GEREF _Toc47295574 h 3 HYPERLINK l _Toc47295575 2现状及需求分析 PAGEREF _Toc47295575 h 4 HYPERLINK l _Toc47295576 2.1现状分析 PAGEREF _Toc47295576 h 4 HYPERLINK l _Toc47295577 2.2需求分析 PAGEREF _Toc47295577 h 12 HYPERLINK l _Toc47295578 3设计综述 PAGEREF _Toc47295578 h 18 HYPERLINK l _Toc47295579 3.1设计原则 PAGEREF _To

3、c47295579 h 18 HYPERLINK l _Toc47295580 3.2设计思路 PAGEREF _Toc47295580 h 20 HYPERLINK l _Toc47295581 3.2.1物理资源模块化、标准化 PAGEREF _Toc47295581 h 22 HYPERLINK l _Toc47295582 3.2.2资源池化 PAGEREF _Toc47295582 h 22 HYPERLINK l _Toc47295583 3.2.3统一的资源管控平台 PAGEREF _Toc47295583 h 23 HYPERLINK l _Toc47295584 3.2.4业

4、务连续性保证 PAGEREF _Toc47295584 h 24 HYPERLINK l _Toc47295585 3.2.5云安全服务 PAGEREF _Toc47295585 h 24 HYPERLINK l _Toc47295586 3.2.6运维场景化 PAGEREF _Toc47295586 h 25 HYPERLINK l _Toc47295587 3.3建设目标 PAGEREF _Toc47295587 h 25 HYPERLINK l _Toc47295588 3.3.1建设目标 PAGEREF _Toc47295588 h 25 HYPERLINK l _Toc4729558

5、9 3.3.2总体建设思路 PAGEREF _Toc47295589 h 26 HYPERLINK l _Toc47295590 4集团云计算规划 PAGEREF _Toc47295590 h 28 HYPERLINK l _Toc47295591 4.1整体架构规划 PAGEREF _Toc47295591 h 28 HYPERLINK l _Toc47295592 4.2IaaS规划 PAGEREF _Toc47295592 h 28 HYPERLINK l _Toc47295593 4.2.1基础网络 PAGEREF _Toc47295593 h 29 HYPERLINK l _Toc4

6、7295594 4.2.2云网络 PAGEREF _Toc47295594 h 90 HYPERLINK l _Toc47295595 4.2.3计算 PAGEREF _Toc47295595 h 100 HYPERLINK l _Toc47295596 4.2.4存储 PAGEREF _Toc47295596 h 112 HYPERLINK l _Toc47295597 4.2.5云平台 PAGEREF _Toc47295597 h 127 HYPERLINK l _Toc47295598 4.2.6安全 PAGEREF _Toc47295598 h 142 HYPERLINK l _Toc

7、47295599 4.2.7运维 PAGEREF _Toc47295599 h 170 HYPERLINK l _Toc47295600 4.2.8容灾 PAGEREF _Toc47295600 h 193 HYPERLINK l _Toc47295601 4.3PaaS规划 PAGEREF _Toc47295601 h 201 HYPERLINK l _Toc47295602 4.3.1PaaS建设目的 PAGEREF _Toc47295602 h 201 HYPERLINK l _Toc47295603 4.3.2PaaS选型 PAGEREF _Toc47295603 h 202 HYPE

8、RLINK l _Toc47295604 4.3.3PaaS路线规划 PAGEREF _Toc47295604 h 203 HYPERLINK l _Toc47295605 4.4SaaS规划 PAGEREF _Toc47295605 h 207 HYPERLINK l _Toc47295606 4.4.1SaaS建设目的 PAGEREF _Toc47295606 h 207 HYPERLINK l _Toc47295607 4.4.2SaaS路线规划 PAGEREF _Toc47295607 h 207 HYPERLINK l _Toc47295608 5路线图规划 PAGEREF _Toc

9、47295608 h 212 HYPERLINK l _Toc47295609 5.1整体路线图 PAGEREF _Toc47295609 h 212 HYPERLINK l _Toc47295610 5.2第一阶段（2017年）：统一IT资源化 PAGEREF _Toc47295610 h 213 HYPERLINK l _Toc47295611 5.3第二阶段（2018年）：科研环境平台化 PAGEREF _Toc47295611 h 214 HYPERLINK l _Toc47295612 5.4第三阶段（2019年）：业务应用服务化 PAGEREF _Toc47295612 h 215

10、 HYPERLINK l _Toc47295613 5.5集团云计算建设预期效果与意义 PAGEREF _Toc47295613 h 216前言背景集团信息中心中心引入日趋成熟的云计算技术，建设面向全院及国网相关单位提供云计算服务的电力科研云，支撑全院各个单位的资源供给、数据共享、技术创新等需求。规划完成IaaS、PaaS、SaaS的统一设计与建设路线设计,实现云计算中心资源的统一管理及云计算服务统一提供；完成云计算中心的模块化设计，逐渐完善云运营、云管理、云运维及云安全等模块的标准化、流程化、可视化的建设；是本次咨询规划的主要考虑。文档目的本文档为集团云计算咨询项目的咨询设计方案，将作为集团

11、信息中心云计算建设的指导性文件和依据。适用范围本文档资料主要面向负责集团信息中心云计算建设的负责人、项目经理、设计人员、维护人员、工程师等，以便通过参考本文档资料指导集团云计算数据中心的具体建设。参考文档集团云计算咨询项目访谈纪要信息安全技术信息系统安全等级保护基本要求（GB/T 22239-2008）信息系统灾难恢复规范（GB/T20988-2007）OpenStack Administrator Guide（ HYPERLINK / /）OpenStack High Availability Guide（ HYPERLINK / /）OpenStack Operations Guide（

12、HYPERLINK / /）OpenStack Architecture Design Guide（ HYPERLINK / /）现状及需求分析现状分析集团承载着行业多学科、综合性的科研工作，其信息化建设起步较早，但当前并行存在多套具有各自架构特点的平台，孤岛式建设导致资源不能重用，阻碍信息和业务的进一步深度集成和共享。集团当前IT开发平台不统一，各系统独立部署，形成资源孤岛，业务故障无法快速排除；架构上多套系统架构完全不同，没有统一的可靠性/可用性/安全性的软件架构设计，导致系统的可用性低，出现故障难以快速恢复。在机房建设方面，集团现有北京、南京、武汉三地四个数据中心机房，实现了应用的本地化

13、部署，同时个数据中心之间通过专线连接，链路质量有保障，为异地容灾提供了基础。但是四个中心没有规划灾备体系，数据中心没有明确的职能划分，数据中心之间的链路大多是单线，存在单点故障，且链路带宽已经不能满足现有集团业务发现的需求。(1)网络现状集团的网络分为信息内网和信息外网，信息内网与信息外网之间物理隔离，通过网闸进数据摆渡。信息内网承载全院用户访问自建业务系统和集团统推业务系统的内网流量；信息外网承载全院用户访问Inernet及对公网用户提供服务的流量；信息内网和信息外网的网络拓扑都采用星型，全网都采用静态路由实现互通目前网络运行基本正常，关键节点的设备和链路（清河核心、南京院区、武汉院区）采用

14、冗余部署，具备一定的可用性；在网络出口部署防火墙对集团信息内网进行整体安全防护，专门的DMZ区对外提供服务，并部署WAF进行WEB安全防护但随着IT环境的日益复杂，规模日益增长，网络系统局部存在问题仍有待改善：设备、链路、服务器接入有较多的单点，缺少冗余，可用性不高；网络架构层次不清晰，数据中心和办公网未有效隔离，数据中心没有进行功能区域划分；二层广播域跨越双中心，出现广播风暴会导致整网不可用；数据中心没有进行功能区域划分，缺少统一的安全策略；安全防护手段比较单一，缺乏安全纵深；网络设备配置存在安全薄弱环节，业务流量的监控和分析手段不足；大数据相关业务的网络都为千兆，存在带宽瓶颈；带外管理网不

15、完备，运维管理效率不高；网络基础服务没有统一的管理（DHCP、DNS、NTP等）（2）服务器现状集团目前已有729台服务器，其中小型机1台，X86服务器488台，刀片服务器240台，大部分服务器采用的是开发的X86架构，具有标准化的基础。目前全院正在逐步将服务器集中管理，由信息中心统一运维和规划，并且已经采用虚拟化的方式提供IT基础服务，避免了竖井式建设的资源浪费。但是集团大部分服务器服务年限过长，已经过保，存在严重的隐患；同时服务器的CPU和内存利用率普遍过低；大部分的服务器只配置了单网卡，存在链路单点问题，大部分服务器部署了一张网络平面，随着业务的发展和架构的演进，该网络平面将要同时承载业

16、务、管理和存储三种类型的流量，将会相互影响和冲突；没有根据服务器承载的业务或者功能进行有效的划分。目前集团采用华为虚拟化平台构建计算资源池，在提高了资源利用率，节能减排、业务快速部署上取得了明显的效果；正逐步将业务系统迁移至虚拟化平台上，完成了部分业务的云化工作。但是集群规模不统一，有3台一个集群，6台一个集群，且未进行规划，未来扩展不方便；划分的存储LUN也不统一，3T10几T不等，LUN的命名也不规范；资源严重超配，已经超过集群规模的150%，集群已无法正常启动HA机制；对于是否适合虚拟化未进行严格的评估，大数据部署在虚拟化平台上，资源争用严重；虚拟化管理平台单机部署，存在单点故障。（3）

17、存储现状在存储方面，已有的15套FC SAN存储IOPS指标较高，采用的多控制器架构支持高可用性，可良好的满足已有业务的运行；SAN存储作为共享存储和虚拟化平台结合，为当前喝多单机部署的业务提供了高可用性。但是未建立完整的存储分层架构设计，全部采用FC存储，存储成本很高；无完善的统一存储网络导致SAN孤岛现状，影响存储资源池的建设；业务和服务的RTO和RPO数值不明确，数据也未采用任何容灾备份架构或本地高可用架构，数据安全性较低；由于无存储监控软件，当前存储的运维复杂度较高，依靠人工每天定时三次登陆存储设备意义排查。（4）安全现状安全方面集团目前沿用传统安全组织架构。由集团领导层担任信息安全决

18、策层，由集团信息中心担任知悉层，各部门和其他院所配有安全专职。组织架构清晰，职责分工明确；有比较完善的ISO 27001三级文档；部署有部分安全产品，对云平台起一定的安全防护作用。但是信息中心负责集团的信息安全执行，在人员配备上存在不足；缺失云安全相关的安全制度；网络安全、主机安全、应用安全和数据安全的防护能力不足，在现网中缺失安全技术点，存在安全产品配置不合理的情况。（5）运维现状在运维方面院领导已对运维管理的规划性和流程体系的建设非常重视，并希望通过此项目在运维体系建设方面有所成果；目前已具备有服务请求、问题、变更等流程，并正在使用中，相关流程的配套文档也在逐步完善。但是运维缺乏统一规划，

19、建设完成后转维困难；目前运维工作主以被动响应为主，缺乏主动防范；监控系统仅覆盖了网络，云平台、应用的监控尚在测试中；SLA尚未发布，无法对各院所提供明确的SLA承诺，缺乏提供云服务的基本条件；缺乏专业的运维工具来支撑，运维工作的进度及效果很难得到管控，神码工单系统目前处于测试阶段，尚不能支撑，目前通过纸件、邮件、电话方式来处理日常运维工作的流转；运维人员配备和知识结构有待改进；运维流程不够全面，需要结合云运维来补充和完善。需求分析多中心建设需求集团未来需要构建三地四中心的灾备体系，满足集团同城双活异地容灾的云计算数据中心的规划设计，不同中心的资源池统一管理，构建集团科研云。网络建设需求IT基础

20、设施建设需求集团在IT基础设施上需要提高IT基础设施体运维效率和质量，实现自动化和可视化运维；基础设施资源池化，实现资源的弹性调度，提高资源利用率；缩短业务系统上线周期，适应业务快速发展需求。云运营建设需求需要构建集团云统一服务门户，集团云业务统一入口&一切即服务。应用系统对云计算的需求数据备份：希望通过统一的备份方案对重要数据进行备份和恢复，加强数据安全管理；可靠计算：通过云平台的高可靠机制，消除应用系统的单点故障，为计算资源赋予高可靠性机制，需考虑虚拟机HA、应用HA、FT等容错和数据保护机制；弹性计算：一些科研系统计算资源存在峰谷现象，平时资源闲置，忙时又没有足够的资源，严重制约科研进展

21、，计算资源池应具有弹性伸缩/扩展和自动均衡计算容量的功能 如DRS（Dynamic Resource Scheduler，动态资源调度）或DRX（ Dynamic Resource extensions，动态资源扩展）等计算特性；存储建设需求分布式存储建设：分布式存储经济、高可用、近线性扩展，构建分布式存储资源池，降低存储整体使用成本；统一FC存储网：将现有各独立的FC存储打通，构建FC存储网络，提升FC存储的共享和扩展性；充分共享：形成存储资源池，不仅仅用于云计算，而是满足全院各业务系统对存储的需求；云安全建设需求构建符合等保三级要求和集团要求的安全体系。运维建设需求运维方式转变：由当前的被

22、动服务方式逐步转化位未来主动防范的运维方式；运维工具建设：建立统一的监控平台，实现数据中心所有资源统一监控，运维与云服务统一，运营信息和运维信息统一大屏显示；构建监控告警和告警分级，运维团队能够及时掌握告警信息；完成运维流程工具建设，实现核心流程电子化和自动化运维流程梳理：梳理现有流程及相关文档，与流程工具整合，实现核心流程电子化和自动化运维团队建设：提供运维人员岗位及技能建议，提供运维流程中的角色及职责建议。PaaS建设需求DevOps一体化流程,建设开发-测试-发布一体化的平台；基于微服务的科研云环境；Cloud Native的业务云化；标准的开发测试环境，统一开发架构，减少软件平台的类型

23、和版本，降低运维难度；设计综述设计原则结合集团当前的实际现状及未来三年业务发展需求，此次云计算规划的考虑原则如下：关注IT能力的快速提升IT能力包括业务服务能力和运维能力上。业务服务能力上，从技术层面来说，包括物理硬件资源、云计算资源抽象层、统一的应用平台以及应用软件。运维能力则包括了人员、流程、工具等各个方面。IT能力组成示意对于云计算技术的选择以及运维工具的选择上，在技术对比之外，更应关注于选择本身是否能给集团带来业务服务能力以及运维能力的快速提升上，并以此作为评判的基本原则。采用开放的架构开放本身有两个含义：源代码开放和标准开放。源代码开放，允许集团可以拥有完全的掌控，可以修改或则增加新

24、的功能满足集团自身的需要；标准开放意味着集团可以通过各种符合标准的产品构成自己的云计算方案开放架构的两方面含义对于集团而言，标准开放比源代码开放更重要。源代码开放虽然能够让集团拥有完全的掌控，但由于人力的持续投入，以及业务重心的考虑，所谓的“完全的掌控”并不一定能够获得；而标准开放可以避免受单个实体控制（使单个实体受益），这是集团更应关注的。关注资源的弹性资源的弹性来自于集团的业务需求，也是重要的设计原则。资源的弹性体现在各个层面。硬件层面更多的表现为资源可以线性扩展，可以快速部署；IAAS平台层面则需要能够支撑管控规模的线性扩展；云资源层面则真正实现资源的弹性，可以随着业务量的增多而弹性增加

25、，也可以随着业务量的萎缩而弹性收缩；应用层面的弹性则更多的体现在灵活的部署上。其他通用原则除去上述集团应该特别关注的原则外，整个规划设计还需要考虑下述通用原则：其他通用原则汇总高可用性：结构的高可用性，资源的冗余部署，逻辑关系的松耦合设计，不会因为任何一个模块发生故障而影响业务的开展。具体来说，包括物理网络、云计算资源、云计算平台、业务应用自身等各个层面的高可用。安全性：安全区域合理规划，安全策略精细化部署，安全策略进行统一的管理，能够满足未来业务发展对安全的需求。灵活性：满足业务与应用系统灵活多变的资源分配及部署需求。可管理性：结构简单、健壮，易于管理和维护，满足监管要求及日常运维的需求，并

26、提供及时发现和排除故障的能力。性能：采用的技术应带来性能的提升，至少本身不会带来性能的大幅下降。设计思路集团云计算的服务对象包括业务及科研体系、运维体系、管理层，未来则可能面向集团，甚至其他企业提供服务。每个服务对象对云计算的关注和诉求均存在不同。具体分析各个对象的需求，可以发现：自有业务体系：能够方便、快速的获得所需IT资源，不愿介入IT本身的管理维护，业务系统不中断；其他业务体系：对云内隔离的疑虑，对云内安全的需求，对可靠性保证的担忧；管理层：关注投资收益比，能方便的获得投资决策数据，包括业务的经营数据，IT的运营数据；运维体系：平台可靠，易于管理，业务快速自愈能力，弹性扩展能力，运维工作

27、量低，完善的安全防护；建设者：建设者和运维体系可以是一个实体，但基于对象考虑它有其独特的需求。初始能够快速建设，后续能够快速的扩容，建设周期短，人员投入少，建设质量有保证；针对各个对象需求分析总结，云计算的规划思路主要在于标准化模块化、资源池化、资源服务化、云容量的可视化、运维部署自动化、资源高可用、云安全服务、运维场景化这些方面，具体分析见下面的表格。针对服务对象的云计算规划思路分析服务对象分析云计算相关规划思路自有业务体系关注资源提供的数量及类型、及时性，自服务能力等，可用性资源池化、资源服务化、业务连续性其他业务体系可用性、安全隔离云安全服务、业务连续性管理层资源利用率、业务数据云容量的

28、可视化建设者可扩展性标准化、模块化运维体系可维护性、业务连续性、可管理性、可视化、自动化、安全业务连续性、云安全服务、运维部署自动化，运维场景化对前面的规划思路进行归纳分类，云计算的规划主要需要考虑下面的六点：物理资源的模块化、标准化；资源池化；统一管理平台（统一平台的资源服务化、云容量的可视化、运维部署自动化）；业务连续性；云安全服务；运维场景化；后面针对每一点分别进行具体分析。物理资源模块化、标准化物理资源的模块化、标准化是云计算建设的基础。云计算的最重要的特点之一就是资源的弹性，弹性的主要表现则是资源的快速扩展和收缩。其中资源的快速扩展不仅仅是逻辑资源层面的，也是物理资源层面的。物理资源

29、的模块化、标准化，利于机房的预先规划，利于资源的批量采购，也利于云计算资源运维的自动化。集团未来业务规模的扩大，必然需要IT基础设施规模的扩展来支撑。在后续的设计中，通过物理POD设计、网络划分、分区设计、资源池单位、存储统一规划等实现基础网络、计算单元、存储单元的标准化规范、模块化的设计，实现云计算建设的快速扩展物理资源模块化、标准化建设思路资源池化资源池是云计算的逻辑构成。具体而言，资源池化主要包含三个方面：首先是逻辑资源标准化，为上层应用提供统一的资源交付，对底层硬件则通过软硬件解耦，屏蔽硬件差异；其次通用化，不针对特定的应用，在云的支撑下可以构造出千变万化的应用，同一个云可以同时支撑不

30、同的应用运行。无论这种应用是基于Windows，还是Linux，无论这种应用是计算密集型，还是网络密集型；无论这种应用是针对外部访问的，还是对内提供服务的，均可以通过这一通用的平台支撑。最后是资源灵活调配，不受物理部署的限制，实现计算、存储以及网络资源的任意位置流动。池化的一个重要特点就是资源的流动性。只有流动才能使资源调度整体上处于平衡。经过多年的发展，云计算的资源池化已不仅仅限于计算的资源池化，还包括网络、存储甚至安全的资源池化。针对集团的此次资源池规划，将分为计算、存储、网络三大部分进行分析设计。统一的资源管控平台资源服务化、云容量的可视化、运维部署自动化，这些均需要统一的云资源管控平台

31、来实现。将各种资源进行逻辑构建和标准化后，大量资源的运维管理成为一个急需解决的问题。统一的云平台是解决的这一问题的最好办法。同时通过云平台的集成，将资源的申请使用变成平台上的自助式服务，云的容量变成平台上的可视图形，手动的运维变成平台上的自动处理流程，最终实现云的服务。针对集团的云资源管控平台，将从平台的选择、平台的架构、服务的构成几个方面来进行分析。业务连续性保证无论采用何种建设方式，业务连续性保证都是无法回避的问题。通常的业务连续性保证可以分为数据中心内和数据中心间两个层面。数据中心内的业务连续性则聚焦于高可用性。对于云计算数据中心内而言，继续细分则可以分为物理基础设施的高可用、云计算自身

32、的高可用、云为业务提供的高可用、以及业务自身的高可用。其中云计算自身的高可用和云为业务提供的高可用，是云计算应具有的可用性保证。数据中心间的业务连续性则聚焦于灾备。灾备级别可分为数据级容灾及应用级容灾，通常的手段则是通过多中心建设来实现。针对集团的此次云数据中心规划，后面讲详细分析云数据中心内的业务连续性保证，并简单介绍多中心的灾备体系。云安全服务安全本身自成体系，包括物理、网络、主机、数据、应用等各个层面。在云计算的建设中，安全所有的这些部分均存在，只是在云环境下，部分的安全防护方式以及安全手段出现了新的变化。云环境下由于IT资源变成逻辑的、与物理位置无关的资源，原有的基于物理边界的安全防护

33、措施变得不再适用。新的基于云环境下的资源隔离手段、资源的防护措施，是本次规划重点需考虑的地方。同时云的服务化的理念也渗透到安全的领域，基于云内的安全服务成为未来安全的一个方向。基于集团当前的业务现状以及未来的业务需求，传统安全结合云的安全规划，是本次项目的安全设计的主要规划方式。运维场景化通过资源集中管理，云计算为各种自助服务、自动化运维管理提供了基础。但具体的自动化运维需要明确的场景定义。针对特定的业务场景以及故障场景，通过自动化的技术手段，满足业务的资源需求，以及实现业务的自愈，是运维场景化的主要方向。云环境下的自动化运维，通常包括下面三种常见的场景，此次的规划中也将具体分析这三种具体场景

34、：业务故障的场景。当云环境下的物理服务器故障、VM故障、或者OS异常等发生时，通过云平台的自动检测切换，保障业务的正常运行，减少业务中断时间；业务对资源质量需求的场景。许多业务运行对CPU占用、内存分配有较高的要求，而实际运行中这些情况瞬息万变。通过云平台对相关资源的自动检测，主动将高资源质量要求的应用迁移到资源充裕的位置；业务对资源数量需求的场景。当业务运行资源不够导致服务能力不足，且业务自身支持通过资源数量的增加来提供服务能力时，云平台通过检测资源的瓶颈并自动增加相关资源来保证业务的服务能力提供。这种场景很好的体现了云计算资源的弹性。建设目标建设目标结合集团IT架构现状和未来业务发展的需求

35、，我们给出的解决建议有采用标准化硬件基础设施建设；建设云计算高可用架构的统一资源池；建设统一的云管理平台；构建统一的PaaS平台；构建运维体系、流程和工具；建设基于等保的安全体系，最终达到IT资源统一云化、科研环境平台化、业务应用服务化、运维管理自动化的云计算建设目标。目前云计算已经是未来IT的基础架构，包括“中国大数据战略”，“物联网行动纲领”，“中国制造2025战略”，“中国电信CTnet2025战略”都是将云计算作为基础技术支撑；国家电网发布了信息通信新技术推动智能电网和“一强三优”现代公司创新发展行动计划，推进大数据、云计算、物联网和移动互联等新技术在智能电网和“一强三优”现代公司建设

36、中的创新应用；集团作为国家电网最重要的核心科研机构，集团担负着促进科学进步、为行业提供技术支撑的重任。 结合宏观和微观的需求，本次集团云计算项目建设的终极目标是构建国际一流的科研云。总体建设思路集团本次云计算项目基于统一的云计算架构，构建集团科研信息化平台，建立面向行业的科研云，对外提供云增值服务，支撑集团成为“国际一流的科研和技术服务机构”，总体建设思路如下：IT资源统一云化：对全院IT资源整合，提供云化的IT资源统一管理和自助服务，达到统一的资源池、统一的资源池管理和统一的资源交付；科研环境平台化:通过构建PaaS科研平台，科研DevOps一体化环境，最终实现业务应用微服务化，实现集团科研

37、信息化平台，建立统一的PaaS科研开发环境，支持集团创新提升。业务应用服务化：通过建设科研云统一门户和应用商店，提供云增值服务，对内对外外提供大数据分析、数据仿真等云增值服务，支撑集团成为“国际一流的科研和技术服务机构”，加快推进成果转化。集团云计算规划整体架构规划日前，集团发布信息通信新技术推动智能电网和“一强三优”现代公司创新发展行动计划（以下简称行动计划），推进大数据、云计算、物联网和移动互联等新技术在智能电网和“一强三优”现代公司建设中的创新应用。集团未来三年云计算整体蓝图，需要构建多中心的“科研云”，全面提升集团未来的业务创新能力，保障业务快速安全交付。对于其中同城云数据中心内的建设

38、，则可以划分为物理资源层、虚拟化平台层、云服务层，以及贯穿各个层面的运维管理层整个科研云涵盖IaaS、PaaS、SaaS服务，提供完整的云计算服务；同时科院云是符合等保三级和集团合规要求的安全可靠的云；同时建设统一的运营、运维管理体系贯穿整个科研云各个层面；构建集团统一的云服务门户，通过云服务门户统一对内对外提供云服务，支持科研各应用领域： IaaS规划针对集团此次云计算的建设，从基础网络、云网络、计算、存储、云平台、安全、运维和容灾八个领域对云计算进行规划设计，基于开源的高可用的商用云计算架构，各组件松耦合、模块化、标准化，实现云计算的灵活性，最终实现统一的资源池化、统一资源管理和统一资源交

39、付的目标。基础网络网络总体设计设计原则集团网络总体设计需重点关注网络架构的规范、安全体系的完善、网络管理的统一、业务部署的灵活、技术的成熟可靠等各方面的需求。为了能够满足集团业务系统对网络基础设施的要求及设计目标，在集团的网络总体设计中采用以下设计原则：高可用性：网络结构的高可用性，物理资源的冗余部署，逻辑关系的松耦合设计，不会因为任何一个网络模块发生故障而影响全局网络的畅通。安全性：网络安全区域合理规划，安全策略精细化部署，符合信息系统安全等级保护基本要求，全网的安全策略进行统一的管理，能够满足未来业务发展对安全的需求。可扩展性：采用业务功能模块化和网络拓扑层次化的设计方法，使得网络架构在功

40、能、容量、覆盖能力等各方面具有易扩展能力，使其能够动态响应业务发展变化，快速满足业务和应用不断变化对网络基础架构的要求，配合业务的快速发展或变革。性能：网络的带宽、时延、抖动等性能指标满足业务系统的要求。灵活性：采用新技术和新特性时，网络架构不需要调整或调整较小，满足业务与应用系统灵活多变的部署需求。可管理性：网络简单、健壮，易于管理和维护，满足行业监管要求及日常运维的需求，并提供及时发现和排除网络故障的能力。设计思路集团网络总体设计参考目前国内外一流企业和科研单位网络建设中流行的设计理念和规范，保持技术上具有总体先进性和开放性；同时又考虑成熟性、稳定性与先进性相结合，保证网络稳定有效的前提下

41、具有一定的前瞻性。具体的网络整体设计思路如下：网络松耦合：信息内网、信息外网和科研网松耦合；数据中心网络、广域网及各院区松耦合；数据中心内部各功能分区松耦合。核心网架构：信息内网、外网和科研网均基于核心网架构，数据中心和各院区作为叶子节点，扁平化接入，实现较好的扩展性，并有效隔离故障域。前后端网络分离：集团数据中心的前端业务网络与后端管理网物理隔离，流量互不影响，保证高可用性。模块化分区：模块化的数据中心是一种用标准、可重复构建单元来构建数据中心的基础设施方法，CELL和POD是数据中心模块化设计的关注重点，也是模块化数据中心构建的最基本单元。信息内网数据中心网络功能分区包括：核心交换区、二级

42、系统区、三级系统区、VDI区、高性能计算区、开发测试区、管理业务区、广域网区。信息外网数据中心网络功能分区包括：核心交换区、二级系统区、互联网出口区、广域网区和管理业务区。网络分层：集团数据中心网络分核心层、汇聚层、接入层三层网络架构设计，不同的网络层次承担不同的功能。核心层主要负责流量的高速转发，汇聚层主要负责流量的汇聚及网络安全、路由策略的部署，接入层为各种IT系统和终端用户提供接入设施。标准化部署：网络架构设计采用标准化设计思路，从物理上和逻辑上，对网络各节点以及节点之间的连接，进行标准化设计，简化部署，降低运维管理复杂度。主要包括网络组件标准化设计、连接方式标准化设计、协议部署标准化设

43、计。网络总体设计集团网络分为信息内网、信息外网和科研网，信息内网承载全院用户访问自建业务系统和集团统推业务系统的内网流量；信息外网承载全院用户访问Inerent及对公网用户提供服务的流量；科研网承载各院所实验室的科研流量。三张网络物理上相互独立，互访需要经过隔离装置进行数据摆渡。物理部署机房物理部署清河数据中心（科研楼三楼）机房综合布线遵循TIA-942 Tier IV标准的星形连接架构。清河数据中心（科研楼三楼）网络机房机柜布放如上图所示：网络机房最左侧四列机柜放置信息内网的网络设备和MDA区的线缆，最右侧两列机柜放置信息外网的网络设备和MDA区的线缆，最右侧的第三列机柜放置科研网的网络设备

44、和MDA区的线缆，其余机柜作为服务器机柜。清河数据中心（科研楼三楼）服务器机房机柜布放如上图所示：每列机柜部署一个配线柜和一个强电柜，配线柜布放网络机房的MDA区到本列机柜的光纤，经ODF配线架/MPO模块盒采用尾纤跳线到各机柜架顶的ODF配线架/MPO模块盒上。POD设计云计算数据中心通常会采用结构化、模块化、标准化的设计方法，实现IT基础设施（计算、网络、存储）的灵活扩展，减少对在网运行业务的影响，简化部署，便于实现自动化运维。服务提供点(POD，Point Of Delivery)是“服务模块”的具体实现形式，采用这种方式实现数据中心的物理资源的组件化、模块化设计，有利于提高扩展性，隔离

45、故障域，通过组件的重用来提高IT基础设施的部署效率。具体而言，POD是一组包括处理器、存储、网络和应用的物理组件，可以最大限度地提高数据中心空间的模块化、可伸缩性和易治理性。POD的规模一般根据业务服务器规模而定，可以包括一组或多组机柜组合而成，颗粒度与数据中心规模相关。POD通常可以分为服务器POD（如X86服务器、刀片服务器等）、存储POD等类型。2U高度X86服务器POD根据服务器机房（低密）每机柜电源功率和TOR交换机端口利用率，2U高度的X86服务器POD由三组机柜构成，后续按POD进行业务扩展。物理部署每三组机柜作为一个POD，按POD进行业务扩展；每组机柜部署12台2U服务器，每

46、个POD最多部署36台2U服务器；每个POD至少部署5台交换机，2台业务网交换机，2台管理网交换机，1台带外管理交换机，若POD内使用分布式存储，则需要增加2台存储网交换机。交换机端口利用率（均按单台设备计算）4U高度X86服务器POD根据服务器机房（低密）每机柜电源功率、TOR交换机端口利用率，和每列机柜的部放情况，4U高度的X86服务器POD由五组机柜构成，后续按POD进行业务扩展。物理部署每五组机柜作为一个POD，按POD进行业务扩展；每组机柜部署6台4U服务器，每个POD最多部署30台4U服务器；每个POD至少部署5台交换机，2台业务网交换机，2台管理网交换机，1台带外管理交换机，若P

47、OD内使用分布式存储，则需要增加2台存储网交换机。交换机端口利用率（均按单台设备计算）刀片POD根据服务器机房（高密）每机柜电源功率和TOR交换机端口利用率，POD由二组机柜组成，后续按POD进行业务扩展。物理部署每二组机柜作为一个POD，按POD进行业务扩展；每组机柜部署2台刀片（假设每台刀片12U，每台刀片的业务网口16个）每个POD最多部署4台刀片；每个POD至少部署4台交换机，2台业务网交换机，2台管理网交换机。信息内网网络规划网络总体架构设计集团信息内网清河、昌平、南京和武汉数据中心及各院区通过广域网承载平台进行互联，实现高可用性、高性能和灵活扩展。后续随着集团综合数据通信网建设的逐

48、步完善，集团清河、昌平、南京和武汉数据中心及各院区就近接入集团综合数据网，充分利用综合数据网的高带宽、高可用、广覆盖，满足后续容灾的相关需求。数据中心分区规划数据中心分区原则云计算数据中心的网络通常包括前端网络和后端网络,前端网络包括业务网和存储网，承载业务运行相关流量；后端网络包括数据备份网、虚机迁移网、带外管理网及管理网，承载运维管理相关流量。不同的网络类型承载不同的业务，具有不同的流量特点和网络带宽需求。考虑投资成本、运维难度、不同业务的流量特点和带宽需求，对集团云计算数据中心的的网络进行适当整合，分为业务网、存储网和云管理网，云管理网上承载数据备份流量、虚拟机迁移流量和管理类流量，不同

49、类型的流量使用ACL进行安全隔离，通过QoS进行带宽保障。业务网、存储网和云管理网相互独立，通过业务网的管理业务区实现对整个信息内网的统一运维和管理。依据业界数据中心建设的最佳实践，数据中心的逻辑分区通常会根据业务应用类型、业务应用之间耦合度、业务应用安全级别、业务应用的运维管理等因素进行划分。逻辑分区的划分原则通常有如下：按业务类型及应用之间的耦合性进行逻辑分区原则业务耦合度大的应用在本逻辑区域内（区域汇聚内）实现转发。业务耦合度小的应用在不同逻辑区域内（跨区域汇聚）实现转发。按业务应用安全级别进行逻辑分区原则安全等级一致的服务器部署在同一个逻辑区域内。生产类业务、开发测试类业务应处在不同的

50、安全域内。按业务应用的运维管理进行逻辑分区原则业务流量、安全控制、组网协议方面有特殊要求的业务在同一个逻辑区域内。当某一个逻辑区域内的服务器数量超过一定数量后（根据接口数量不同，通常300-500台），可以进行拆分。数据中心网络分区设计参考集团的业务系统类型和信息系统安全等级保护基本要求及集团公司安全要求，结合业务流量自身特点，实现资源的高效利用，保证各分区之间尽量松耦合，高内聚，简化运维管理，对信息内网的数据中心进行相应的网络功能分区。根据各网络分区承载的业务类型，结合前期调研与需求分析阶段汇总的业务需求，确定各分区的TOP设计原则和设计建议。核心交换区功能：连接数据中心的各个网络分区，高速

51、转发跨分区的的数据流量。设计原则：核心交换区按照高可用性、高性能、可扩展性原则进行设计。设计建议：采用CLOS架构，设备之间松耦合，具备高可用性、高性能和良好的可扩展性，有效隔离故障域。VDI区功能：承载虚拟桌面应用，终端用户通过瘦客户端或者其他设备来访问客户桌面。设计原则：VDI区按照高可用性、高性能、安全性原则进行设计。设计建议：采用独立的物理资源，区域内各节点和链路冗余备份；区域内设备的业务处理能力满足客户使用高峰期和终端用户数增长需要；部署安全设备进行安全防护。二级系统区功能：承载等保二级业务系统。设计原则：二级系统区按照高可用性、安全性、性能、可扩展性原则进行设计。设计建议：采用独立

52、的物理资源，区域内各节点和链路冗余备份；部署安全设备进行安全防护；区域内设备的业务处理能力具备冗余空间，满足业务高峰期和业务发展需要具备较好的扩展性。三级系统区功能：承载等保三级业务系统。设计原则：三级系统区按照高可用性、安全性、性能原则进行设计。设计建议：采用独立的物理资源，区域内各节点和链路冗余备份；部署安全设备进行纵深安全防护；区域内设备的业务处理能力满足客户使用高峰期和终端用户数增长需要。高性能计算区功能：海量结构化数据和非结构化数据的存储和处理。设计原则：高性能计算区按照高可用性、安全性、性能、可扩展性原则进行设计。设计建议：采用独立的物理资源，区域内各节点和链路冗余备份；部署安全设

53、备进行纵深安全防护；高带宽，高吞吐能力；具备较好的扩展性。开发测试区功能：为业务系统和应用提供开发测试环境；新业务系统的预上线测试。设计原则：开发测试区按照安全性和灵活性原则进行设计。设计建议：采用独立的物理资源；采用独立的路由进程；部署安全设备，严格控制与数据中心其他区域之间的互访；验证新特性和新功能不会影响整体架构。管理业务区功能：承载与IT管理业务相关的各类系统，包括云平台、网管平台、安管中心等。设计原则：管理业务区按照可管理性、安全性、高可用性原则进行设计。设计建议：部署计算、存储、网络、安全、云平台等多种管理服务器，一体化运维管理；采用独立的物理资源；区域内各节点和链路冗余备份；部署

54、安全设备，控制与管理网之间的互访。广域网区功能：进出数据中心流量的高速转发和路由控制。设计原则：管理业务区按照高可用性、性能原则进行设计。设计建议：采用独立的物理资源，区域内各节点和链路冗余备份；高带宽，高吞吐能力。核心交换区网络设计数据中心核心交换区连接其他各网络功能分区，负责各区域间的高速流量转发，构建更高可用性和性能及灵活扩展的网络核心。架构数据中心核心交换区负责各区域间的高速流量转发，访问控制、路由过滤等网络功能从核心交换区剥离，分散至各个功能分区汇聚层，简化核心交换区，构建更高性能和灵活扩展的网络核心；核心交换区由两台独立的高端交换机组成，各网络区域的汇聚设备，每台都与两台核心交换机

55、互连；核心交换机与各区域汇聚交换机之间，均是采用三层路由互通，通过ECMP进行负载分担。高可用性核心交换区采用高可靠架构(双机、冗余引擎和冗余电源配置)，以避免网络层面的单点故障；两台核心交换机相互独立，故障隔离。性能核心交换机采用CLOS多级交换架构，支持分布式流量调度；到各分区汇聚之间（高性能计算区除外）采用万兆互联，满足不断增长的服务器接入带宽需求，未来能够平滑升级至100G；单台交换机可以支撑全数据中心的业务流量。可扩展性核心层采用CLOS架构部署，核心层设备之间不互联，扩容相对独立，未来可以灵活的进行横向扩展。VDI区网络设计VDI区承载虚拟桌面应用，终端用户通过瘦客户端或者其他设备

56、来访问客户桌面。架构采用传统的汇聚+接入的两层架构。汇聚由两台高端交换机组成，支持网络虚拟化技术，作为本区域的业务网关；汇聚交换机与数据中心核心交换区设备之间全连接，通过三层路由实现互通；服务器POD内部署TOR交换机，支持网络虚拟化技术，以提高带宽利用率，简化管理。高可用性汇聚设备、POD内部署的业务网TOR接入和防火墙都采用双设备，服务器通过双网卡同时接入TOR，实现设备及接入的高可用性；TOR接入与区域汇聚支持网络虚拟化，两者通过跨设备的聚合链路互连，防火墙与区域汇聚之间也采用跨设备的链路聚合，实现节点之间连接的高可用性；每台汇聚设备通过两条链路分别连接到两台核心交换，并支持ECMP路由

57、，实现区域出口连接的高可用性；防火墙旁挂部署， 通过PBR(策略路由)引流方式，防火墙全部失效后业务不受影响，实现业务的高可用性。安全性汇聚设备旁挂防火墙，通过PBR(策略路由)引流方式对整个区域实现安全防护；区域内部的安全控制，通过在交换机上下发访问控制规则（ACL）实现。性能TOR接入到VDI汇聚，及VDI区汇聚之间均采用万兆连接， VDI区汇聚之间互连带宽大于等于任何单台汇聚设备上行带宽；汇聚与防火墙之间采用千兆链路，防火墙要求具备高新建连接数和并发连接数的性能，满足业务系统跨区访问的需求。二级系统区网络设计二级系统区承载根据信息系统安全等级保护定级定级指南和集团相关安全要求确定的二级应

58、用系统。架构采用Spine+Leaf的两层架构。汇聚由两台高端交换机组成，支持网络虚拟化技术，作为Spine节点，TOR接入作为Leaf节点；汇聚交换机与数据中心核心交换区设备之间全连接，通过三层路由实现互通；服务器POD内部署TOR接入交换机，支持网络虚拟化技术，以提高带宽利用率，简化管理。高可用性汇聚设备、POD内部署的业务网TOR接入和防火墙都采用双设备，服务器通过双网卡同时接入TOR，实现设备及接入的高可用性；TOR接入与区域汇聚支持网络虚拟化，两者通过跨设备的聚合链路互连，防火墙与区域汇聚之间也采用跨设备的链路聚合，实现节点之间连接的高可用性。每台汇聚设备通过两条链路分别连接到两台核

59、心交换，并支持ECMP路由，实现区域出口连接的高可用性；防火墙旁挂部署， 通过PBR(策略路由)引流方式，防火墙全部失效后业务不受影响，实现业务的高可用性；旁挂服务器负载均衡，采用SNAT方式实现应用的高可用性。安全性汇聚设备旁挂防火墙，通过PBR(策略路由)引流方式对整个区域实现安全防护；区域内部的安全控制，通过在交换机上下发访问控制规则（ACL）实现。可扩展性汇聚设备支持高密度万兆，通过横向扩展的方式，接入更多的服务器POD；防火墙和服务器负载均衡旁挂部署，便于扩展。性能TOR接入到二级系统区汇聚，及二级系统区汇聚之间均采用万兆连接， 二级系统区汇聚之间互连带宽大于等于任何单台汇聚设备上行

60、带宽；汇聚与防火墙，汇聚与负载均衡设备之间采用千兆链路，防火墙要求具备高新建连接数和并发连接数的性能，满足业务系统跨区访问的需求。三级系统区网络设计三级系统区承载根据信息系统安全等级保护定级定级指南和集团相关安全要求确定的三级应用系统。架构采用Spine+Leaf的两层架构。汇聚由两台高端交换机组成，支持网络虚拟化技术，作为Spine节点，TOR接入作为Leaf节点；汇聚交换机与数据中心核心交换区设备之间全连接，通过三层路由实现互通；服务器POD内部署TOR接入交换机，支持网络虚拟化技术，以提高带宽利用率，简化管理。高可用性汇聚设备、POD内部署的业务网TOR接入和防火墙都采用双设备，服务器通