企业私有云平台基础架构规划、建设实践、平台建设难点总结探讨

字数 21037阅读 19292评论 9赞 27

随着云计算的飞速发展，建立企业私有云平台已成为趋势，平安、太保、泰康、阳光等多家保险公司已建成或正在进行私有云平台建设。云管理平台的主要优势在于：
1）云管理平台能提高资源的利用率，降低能源消耗，它可以通过引入虚拟化等科技的手段，来细化物理资源分配单元，从而提升系统分布的密度，提高系统使用效率，降低对物理设备的需求，从而降低IT设备投入，降低能耗节约成本。
2）云管理平台具有对IT资源的计量能力，该能力可以实现对资源的使用进行监测、控制和优化，使IT系统向更为便捷、更加智能化与更具可计量性转变，以此提高运维管理的效率。

在8月3日的线上活动交流中，围绕金融行业私有云基础架构建设实践，私有云云管理平台、安全、网络等方面的问题进行了充分的讨论，得到了各位专家的支持。大家针对私有云基础架构建设的相关问题，体现出了高度的参与热情。在此，对大家关注的问题以及针对这些问题各位专家的观点总结如下：
# 本期的总结重点会从四个方面进行：
1、私有云基础架构建设规划；
2、私有云平台建设实践；
3、私有云平台网络、安全建设实践；
4、金融行业私有云实践中遇到的难点。

# 一、私有云基础架构建设

## Q1:云平台的架构是选择商用还是开源产品，开源难倒就会真的省钱么？云平台引入策略？
A1:
首先要明确，是云平台cloud platform还是云管平台 cloud management platform
云平台目前主要是opentasck为代表，开源技术；
云管平台目前主要是vmware的vRA，华为的Manageone，以及一众创业型fit2cloud，cloudchef，cloudleaf，cloudrabbit，传统厂商荣之联，浪潮，华三等也均有类似的产品，闭源技术；
云平台，如果自己钻研开源的话，需要投入大量的人力物力进行开发维护，不是中小企业能够承担；往往选择大厂的基于开源的商业版，例如华为，华三，红帽，等基于openstack的产品
云管平台，说白了就是一个paas平台，是需要有很多的开发定制的；一般大厂都很介意定制化，所以有了一众创业公司的生存空间
目前实践经验 是不同的技术使用不同的云平台进行管理 然后在这些平台上再次开发一个统一资源管理的视图 完成资源分配的 资源查看，底层云平台负责资源的扩容，调配，等工作， 上层统一展示资源目前情况 比较好实现目前业务场景， 包括公有云和私有云的 资源统一展示的分派等功能
最好以业务应用类型来驱动，例如，以微服务架构为基础设计的应用，就推荐使用云计算架构来满足其弹性伸缩的要求。

## Q2: 企业云平台建设一共分几期？还是一部到位？云平台实施的方向？
A2:
云平台很少有一步到位的，往往最开始的阶段是满足最基础的需求，例如计算虚拟化，存储虚拟化，然后网络虚拟化，然后容器，监控，大数据，编排，数据库，等等应用。其实，这个和云计算的分层也是有很大关系的。从iaas到paas，再到saas，层层递进。企业的云平台建设，往往也是遵循这个规律。在实践中，可能会有一些交集。
通常都是分几期的。第一期为试点项目，第二期根据一期结果形成规范，标准，成为新开发应用的标准平台。第三期逐渐将老应用迁移到云平台上。
**对于云平台实施：**
（1）通常来讲，会使用在C区内逻辑隔离A，B类业务；使用东西防火墙做业务隔离；
（2）云平台的对接，主要是使用neturon来对接，这个需要SDN厂商提供driver，对接ACI，AC ，VCFC控制器；SDN网络和客户的网络主要还是使用vlan+vxlan的方式打通；
我们一般使用4个网：管理网， 业务网（vxlan），带外网，存储网；
（3）使用不同子网

## Q3: 私有云的容量如何评估？成本如何计算？如何才能做到成本和效率的平衡？
A3:
私有云的容量需要根据业务来评估：
以一般金融行业，有web区，有app，有db。需要根据运行在私有云上的业务的多少，来统计所需要的资源的多少。例如，web区，需要nginx，需要考虑HA和LB，那么就需要2台以上；如果多个业务共享nginx，那么就需要多个nginx来分担业务压力。
成本计算：
一般私有云平台上，都有一个celimeter这个模块，专门用来拥挤CPU，内存，网络的使用量，可以统计出使用私有云的资源，相对传统环境节省了多少资源。
至于成本和效率的平衡，一般在私有云建设初期很难做到。设备的购置，部署，人员的配置等等都是一笔不小的开支；私有云真正的优势体现，应该在后期的使用中
容量如何评估，这个肯定是没有普适标准的了。容量通常从三方面考虑：计算能力、存储容量、网络带宽。这三方面可以说也是数据中心最基本的三大核心要素了，我们都知道，云计算是以规模取胜的，这个规模如何决定？究竟是20节点，50节点，还是100+节点，这个得根据你自己的业务需求来考虑了，在小规模情况下，为了高可用，如果可用容量评估是N，那你就按2N来计算，私有云一般不会像达到公有云那种规模，所以通常也不可能达到很多布道师口中的 虚机随便挂，真挂了你宿主机资源没有了，咋整？
至于成本，的看你的方案了，你是采用开源自建，还是与厂商合作共建，合作情况下如何分工，哪些外包出去，这个你得仔细考虑。通常，如果人力资源有限，技术实力有限，那就由承包给厂商来实施吧，不然到后面也是个烂摊子。但是，全部外部给厂商的不足也是明显的，一不小心你就被锁定，每年烧钱的跑不掉的了，尤其是项目上马后，停也停不下来了。

## Q4: 私有云是否需要支持多租户？多租户和单租户本质区别有哪些？
A4:
多租户的概念包含三层用户集成：
数据中心层
基础架构层
应用程序层
云计算技术设计中的重要内容是多租户的基础架构和应用程序层集成。此集成经过特别的调整，可节约成本和开发具有高度可伸缩性的 SaaS 应用程序，而这是以牺牲安全性和客户隔离需求 (segregation requirement) 为代价。很多情况下，这样的设计都是有效的，尽管可能不太适用于金融应用程序。
在数据中心租用空间并提供服务器、路由器和线缆以支持多个客户软件，这项功能自从硅谷创立初期就已经存在，因此用户对于数据中心层多租户应该并不陌生。如果正确实现此配置，则该配置能够提供最高级别的安全需求，它用防火墙和访问控制来满足业务需求，还定义了对提供 SasS 的基础架构的物理位置的安全控制。大多数情况下，可以将数据中心层多租户用作服务供应商，向公司提供场地来安置硬件、网络以及软件。
基础架构层的多租户是最简单软件栈概念，一个栈专用于一个特定客户。与数据中心层多租户相比，此配置更节约成本，因为栈是根据实际的客户账户部署的。在这种情况下，可以根据实际的服务使用来增加硬件需求。另外，基础架构层的每个用户都可以选择高可用性。每个客户都知道栈，所以软件和硬件最佳实践提供了一些实现选项。
应用程序层多租户需要在软件层和基础架构层基础上进行架构实现。需要修改现有软件架构，包括应用程序层的多租户模式。例如，多租户应用程序需要一些应用程序方法和数据表来访问和存储不同用户账户的数据，这会牺牲安全性。但如果正确实现此操作，就可以节省成本。对于小部件和简单的 Web 应用程序，应用程序层多租户是一个可行的解决方案，因为单个开发人员可以更快地开发软件，也负担得起调整规模的费用。不足之处在于更复杂的应用程序架构和实现；与基础架构处理多租户不同的是，如果基础架构发生变化，应用程序团队需要保持编程模式的可伸缩性和可靠性，而且在未来可用。
多租户服务指定从在软件应用程序中构建并直接访问的 HTTP RESTful 接口或 WSDL Web 服务终端访问。这些服务是建立多租户模式的面向服务的应用程序的关键，因为它们可重用于多种事务类型。
应用服务器是应用程序和基础架构层多租户的关键部件，因为多租户会影响安装、配置和应用程序代码。对于基础架构层，应用服务器的多租户意味着调整更快、更广，它配置了额外的服务器，其中包括应用服务器安装、配置和应用程序代码。多租户层不需要更改代码（除非应用程序设置了特别的需求），调整也很简单，一般由 IT 运营机构完成，而不是由开发人员重新设计应用程序源代码。通常，如果添加了新客户，则需要添加一个相同配置的栈，以便更轻松地满足安全需求。

## Q5: 服务器到底要不要买融合架构？什么样的规模适合融合架构？什么样的规模适合分离架构？
A5:
**一、 超融合的概念**
超融合(Hyper- Converged)目前还没有一个严格的标准定义， 各个厂商和机构都有各自的定义，这也说明超融合仍然处于快速发展
演变当中，并未形成统一的标准规范。 超融合中“超”对应英文“Hyper”，特指虚拟化，对应虚拟化计算架
构，如 KVM、XEN、Hyper-V 等。这一概念最早源自 Nutanix 等存储 厂商将 Google/Facebook 等互联网厂商采用的计算存储融合架构用于 虚拟化环境，为企业客户提供一种基于 X86 硬件平台的计算存储融 合产品或解决方案。按照这个概念，数据库一体机和大数据一体机都 不能划为超融合的范畴，因为RAC/Hadoop等应用并非运行在虚拟机 之上。此外，超融合架构中最根本的变化是存储，由原先的集中共享 式存储(SAN/NAS)转向软件定义存储，特别是分布式存储。
超融合中的“融合”是指计算和存储部署在同一个节点上，同时提供计算和存储能力。融合一般可以分为物理融合和超融合两种，超融 合是融合的一个子集。物理融合系统中，计算和存储仍然可以是两个 独立的组件，没有直接的相互依赖关系，共享主机的物理资源。超融 合与物理融合不同在于，重点以虚拟化计算为中心，计算和存储紧密 相关，存储由控制器虚拟机(Controller VM，CVM)而非物理机来控 制并将分散的存储资源形成统一的存储池，用于创建用户的应用虚拟 机。物理融合与超融合对比如所示。出于性能考虑，超融合架构通常 都需要将主机物理设备透传(Pass Through)给控制器虚机 CVM。
![3jbbkiajh03](/home/attachment/201808/06/1212257_153352697695754.png)

总结以上超融合的内涵可见，超融合架构是基于标准通用的硬件
平台，通过软件定义实现计算、存储、网络融合，实现以虚拟化为中 心的软件定义数据中心的技术架构。要判断一套系统是否采用超融合 架构，主要基于以下几点:
(1) 完全软件定义。独立于硬件，采用商业通用标准硬件平台(如 X86)，完全采用软件实现计算、存储、网络等功能。
(2) 完全虚拟化。以虚拟化计算为中心，计算、存储、网络均由 虚拟化引擎统一管理和调度，软件定义存储由虚拟机控制器 CVM 进 行管理。
(3) 完全分布式。横向扩展的分布式系统，计算、存储、网络按 需进行动态扩展，系统不存在单点故障，采用分布式存储。
**二、 超融合架构发展情况和案例**
未来 5 至 10 年新一代数据中心基础架构朝着软件定义和超融合 方向发展，SAN/NAS 存储逐渐被软件定义的存储所替代。在软件定 义存储(SDS)的推动下，超融合将成为数据中心基础架构的核心， 并且是软件定义数据中心(SDDC)的未来技术发展趋势。基于多种 复杂设备的数据中心最终会归一化成以通用服务器加互连网络的体 系架构。在这些通用服务器上部署关键的软件，通过虚拟化的方式实 现计算、存储资源。然后再在这些虚拟化资源的基础上部署应用，完 成具体功能。
存储、计算和网络的深度融合是未来IT基础设施发展的大趋势， 超融合架构因此成为企业级客户的首选，加速业务系统从传统架构向 云计算架构的转型。IDC 的统计报告显示，2016 年全球超融合市场规 模预计将增长 94%。另一家市场分析公司 Gartner 预计，2019 年全球 超融合市场的规模将超过 1000 亿美元，有大约 30%安装在企业数据 中心内的存储阵列都将是部署在软件定义存储或者基于 x86 硬件系 统的超融合集成系统架构。
2016 年以来，中国超融合市场持续升温，越来越多的超融合团队 逐渐发展起来。根据市场研究和咨询公司 Gartner 在 2016 年 11 月针 对中国超融合市场趋势发布的报告，思科、HP、Dell、EMC、NetApp 等老牌服务器和存储大厂纷纷将技术与产品战略转向超融合的路线 上来。报告指出，中国一跃成为全球超融合基础架构增速最快的市场，，
国内的 H3C、华为、Nutanix、联想、SmartX、深信服等厂商迅速跟 进了国际主流超融合解决方案。
目前超融合架构在国内的主要应用案例如下:
政府相关机构:中国检查出版社，中国证监会，中国互联网信息 中心，中国大连市政府，青海水利，广州地税局数据库虚拟化，国家卫计委云数据中心，湖北省公安厅审计平台，厦门公安局警务云平台， 最高法司法统计管理平台，深圳海关业务系统，广东海事局智慧海事 平台，中国(西安)丝绸之路研究院，温州医科大学第一附属医院等。
金融行业:招商银行，中银证券，南京证券，中信银行等。 制造行业:东风本田，宝山钢铁，中铁资源集团有限公司等。 IT 企业:科陆电子，联想集团，中国联通沃云，中国电信等。 教育行业:中国地质大学，中国科技大学，南开大学，北京邮电大学，北京外交学院，陕西省行政学院等。
**三、 超融合架构的优势**
超融合架构迅速发展的原因是其具有显著的优势，能够带来极高 的客户价值。超融合架构实现了计算、存储、网络等资源的统一管理 和调度，具有更弹性的横向扩展能力，可以为数据中心带来最优的效 率、灵活性、规模、成本和数据保护。使用计算存储超融合的一体化 平台，替代了传统的服务器加集中式存储的架构，使得整个架构更清 晰简单，极大简化了复杂 IT 系统的设计。厂商宣传超融合架构与传
统架构相比的优势对比如下表所示。
![6uksfhrynkp](/home/attachment/201808/06/1212257_153352704262665.png)

** 四、 超融合架构存在的问题**
超融合架构的优势和客户价值已经得到了全球和国内市场的肯 定，是未来 5 至 10 年新一代数据中心基础架构的首选方案。但也不 可避免地存在一些局限或问题，主要包括以下几个方面:
(1) 性能一致性 数据中心中存储的性能至关重要，而且希望能保持一致性，包括延迟、IOPS 和带宽，对于超融合架构可能存在一定问题: 一是超融合架构“共享一切”。计算和存储会争抢 CPU/内存/网络 等物理资源，而且计算和存储又相互依赖，一旦一方资源需求骤升会 导致另一方资源减少，进而影响性能。虽然可以从技术上进行资源隔离限制，但还是会对性能造成影响。 二是超融合架构“一切分布式和软件定义”，集群规模较大后，网络、硬盘、服务器发生故障的概率都会增大，数据重删/压缩/加密/纠 删码等功能都用软件实现，故障的自修复和数据功能实现都会消耗一 定的系统资源，导致性能下降和抖动。可以采用自修复的流控，数据 功能旁路到硬件模块处理，这些方法会缓解性能一致性问题，但又与 超融合的理念相背。
(2) 横向扩展问题 超融合架构关键特征之一就是易于扩展，最小部署，按需扩容。 超融合厂商宣称最大集群规模也差别很大，从数十到数千节点不等， 通常从 3 节点起配。超融合中计算能力、存储性能和容量是同步扩容 的，无法满足现实中单项能力的扩展，有些厂商还对扩容最小单元有 要求，扩展灵活性会受到限制。
集群达到一定规模后，系统架构复杂性就会非线性增加，集群管 理变的更加困难，硬件故障和自修复发生的概率也会大大增加。因此， 超融合架构一般不建议构建大集群，如果业务允许尽量构建多个适当 规模的较小集群，或者采用大集群中构建故障域或子资源池的方式。
(3) 系统复杂性
超融合架构简化了 IT 架构，极大降低了数据中心设计的复杂性， 实现了快速交付，并极大简化了运维管理。不过，这都是基于用户角 度的，从产品研发角度而言，超融合实际上使得内部的软件复杂性更高了。
由于超融合架构需要采用 CVM 虚拟机控制器，并且需要将主机物理设备透传给控制虚机，增加了部署配置管理的复杂性。计算和存 储对硬件平台的要求都不同，融合后也会一定程度上增加兼容性验证 的复杂性。超融合架构下，管理、计算、存储、高可用通常都需要配 置独立的虚拟网络，网络配置也会更加复杂。同时，共享物理资源的 分配、隔离、调度，这也是额外增加的复杂性。如果出现故障，问题 的跟踪调试和分析诊断也变得更加困难。
(4) SSD 分层存储
闪存 SSD 基本成为超融合架构中必不可少的元素，解决了 I/O 性 能瓶颈问题，尤其是 I/O 随机读写能力。目前迫于成本因素，全闪超 融合方案应用仍然较少，多数应用以 SSD 混合存储配置为主，从而 获得较高的性价比。通常情况下，我们假设热点数据占 10-20%，配 置相应比例的 SSD 存储，将热点数据存储在 SSD 存储中，一旦热点 数据超过预先设置阈值或触发迁移策略，则按相应淘汰算法将较冷数 据迁移回 HDD 磁盘存储，从而期望在性能和容量方面达到整体平衡。
问题在于热点数据占比并不好估计，如果 SSD 配置不足，性能 并不会得到优化。假设应用场景合适并且 SSD 配置合理，SSD 空间 最终要被热点数据占满，就会触发数据迁移，这时 HDD 存储仍将成 为 I/O 性能瓶颈，同时还要承担正常的 I/O 业务负载，整体性能就会 出现降级和抖动。为了缓解这一问题，SSD 一方面会过滤掉顺序读写 I/O，另一方面会把空间阈值设置较低，尽早进行数据迁移，同时选择 系统空闲时间执行和流控。带来的负面效应是，SSD 性能加速效果受 限，物理设备效率发挥不充分。另外，SSD 本身被写满时性能也会出 现较大的波动。
因此，实际中推荐根据应用场景采用全闪存 SSD 或全磁盘 HDD 配置，从而获得一致性的性能表现。如果成本所限无法全用 SSD，还 有另外一种应用方式，同时创建一个全 SSD 和一个全 HDD 存储池， 人为按照性能需求将虚拟机分配到不同存储池中。
(5) 文件共享存储
超融合架构采用分布式块存储方式替换传统的共享式存储解决 了虚拟化存储问题。然而实际业务应用中都有着文件共享需求，需要 分布式文件系统或 NAS 存储系统。这是目前超融合普遍缺失的，只 能依赖外部独立部署的 NAS 或集群 NAS 存储系统实现。目前的超融 合架构内还不能很好地统一支持块存储和文件存储。因此，超融合架 构中可以采用相同方式同时部署两套存储，分别提供分布式块存储和
文件系统文件共享存储。
根据 Gartner 的建议， 超融合比较适合用在中小型的基础设施部署，分支机构，有可以预测 的性能和容量需求的场景(性能和容量增长存在一定的比例关系，因 为扩展一个节点，一般是同步扩展了计算和存储能力)。
大型数据中心，针对的是无数混合的负载，一般追求容量和计算独立 灵活扩展，SDS 的部署方式也许更合适。
超融合架构下的存储逻辑单元已经拥有了很多过去高级存储才具备的功能，但是在数据保护，复制，容灾，高可用，这些关系到数据存 储层面的需求是超融合厂商不会花精力去关注也无法关注的，同时架构本身的局限性带来的用户选择面也比较窄，你无法把超大规 模的计算中心全部塞满超融合架构，用户对于结构化和非结构化数据 的海量增长这种数据存储的异构需求不适合全部交给超融合来解决，很多用户原本希望计算跟存储分布扩容，或者计算跟存储占比比较失 衡的情况，比如计算资源需求很大，存储资源需求很小，或者相反的 情况全部交给超融合，这样一股脑全部交给超融合的架构设计是相当糟糕的.

## Q6: 私有云的两地三中心架构如何实现？如何提高云服务的sla？
A6：
首先，“两地三中心”是传统IT架构领域大佬IBM搞出来的容灾备份方案，具体是指同城两中心加异地一中心，合称两地三中心。在传统IT架构里面，一般只有向金融、银行这种财大气粗的才搞得起“两地三中心”。那么在云计算时代，有没有必要搞两地三中心呢，一般小客户肯定是搞不起的，直接用公有云即可，各大公有云运营商通常都建的有不同的Region或AZ，异地就是Region，同城独立数据中心通常对应到AZ，对于很多大厂，那就不是两地三中心了，而是N地N中心（N>=2）。上云了是不是就万事大吉，一切都扔给运营商了呢？如果这样考虑，碰到“挖机事件”、“雷击事件”，你就等着洗洗睡吧！云不能给你100%的SLA，业务连续性还是得靠你的业务高可用设计。怎么设计，把传统“两地三中心”的思想帮到云上就可以了，业务部署在运营商不同的Region上，至少不同的AZ中，Region之间通过GLB实现双活负载均衡。
回到问题。私有云两地三中心架构如何实现，参照各大公有云的实现不就ok了？私有云 与 公有云之间除了网络访问、计费这些模块外，几乎是一样的实现原理，主要还是预算问题，两地三中心对很多企业来说，不是说搞就搞得起的。具体点，可以将三中心接入同一个WEB管理界面，实现统一的监控调度，异地数据中心彼此从网络、电力、计算、存储上独立。要提高SLA，单纯从云架构高可用上设计是不完善的，必须配合业务一起进行高可用设计，还是那个简单的思想，业务跨中心，全局负载均衡器实现跨中心高可用。

# 二、私有云云管理平台建设实践

## Q1: 对于云管平台的建设通常需要考虑哪些？
A1
**云平台可提供如下类型的云服务：**
1、云资源型类服务：其目标是向业务提供基础设施资源服务：云主机资源，云网络资源、云安全资源、云存储资源。
2、云平台支撑类服务：其目标是向业务提供平台型的支撑功能。可以提供包括开发测试环境、数据库服务、应用服务引擎、Web应用环境等。
云管平的选择，还是要根据自身的需求进行。你说的华为自带的我理解应该是其manageone，如果底层全是华为的硬件，例如华为的超融合，华为的SDN，那么毫无疑问，manageone是最佳选择；如果底层是异构的，那么，建议选择网络和云管平台联动较好的解决方案。
所有人都希望一个平台能统一管理 所有资源 包括 你说的4点，但是你会发现这个项目 越做项目失败几率越大，项目需求不断扩大， 需要管理的设备越来越多，接口不断修改 数据越来越不准确，导致 各个系统间开始对数据造成冲突，这样 的项目实在是实施难度太大， 如果立项不是数据中心级别的 建议实现能自控的需求，避免项目失控
**可以参考如下的设计：**
**云计算平台设计主要包括IAAS层、PAAS层、云监管层。**
本次设计方案以IaaS层作为基础架构的平台，向上提供标准计算虚拟化资源、网络虚拟化资源、存储虚拟化资源、数据库和中间件等自助申请服务，实现多服务目录体系，同时实现资源统计报表和计量计费等功能。
其中IAAS包括云计算操作系统为云平台编排层及服务门户，通过分别对接计算、存储、网络实现跨资源领域的业务编排、租户管理。云计算运维系统拟对租户、主机、虚机、云硬盘、网络、安全等资源告警、性能分析、故障定位、业务优化、资源使用分析等各个层面进行运维。基础设施层面包括计算、存储、网络等部分，其中部分计算存储拟采用计算、存储相融合的超融合架构，超融合中计算虚拟化采用vmware 虚拟化，分布式存储需要与vmware相兼容于同一物理服务器上。本次云计算平台要求能够与vmware深度融合，除支持在云计算平台上进行新建类型的操作之外，也需要支持能够在线不中断纳管已有ESXI主机资源。在本次纳管中，不需要新增件新的vaware收费组件，如NSX等。计算资源也包括物理机裸机用于装载数据库服务器。
网络拟采用SDN/VXLAN 网络，SDN网络需要支持对安全资源、公网地址资源、租户资源的纳管，并且云计算平台应保证与SDN网络的标准化、模块化对接，不会对第三方SDN网络的选择带来任何阻碍。

## Q2: 如何设计云管平台自身架构以适应技术发展？
A2
云管理平台整体架构分为云资源管理、云资源接入、云资源运维三大模块，模块于模块之间松耦合。并对外提供系统对接接口。
**云管理平台整体技术框架采用分层，分模块建设的思想，具有以下优点：**
多层体系结构：多层体系结构是合理而有效的系统结构模式。客户层负责用户界面的显示工作，中间层为应用服务器，负责封装业务逻辑。可以根据实际情况又划分为若干层，数据存储由数据库系统完成。
松散耦合:应用服务层可以按功能或业务流程进行划分，形成多个子模块，子模块之间的交互以及与客户层和数据库之间的交互保持相对独立性。
![3iksk5tgzkl](/home/attachment/201808/06/1212257_153352710468040.png)

云管平台目前有两个技术方向，重度集成，和轻度集成
重度集成完成所有其他底层业务平台功能，包括vsphere所有功能，openstack所有功能，存储管理所有功能，
而轻集成只完成部署业务调用，其他管理功能对云管平台来看是基础架构，数据读取方，前台只做容量展示等监控功能
两个方向各有利弊，最终看你得需求，快速上线轻度集成，
如果想重度集成需要长期的开发和技术投入

# 三、私有云网络、安全建设实践

## Q1: 当前阶段，云平台与SDN是选择同一厂商还是不同厂商相互对接？优劣势分别是什么？云平台与sdn对接问题？
A1
这个主要还是要看整体的架构，相对而言，使用openstack做为云平台的大多数都使用kvm作为计算虚拟化，那么对于SDN这块，相对选择比较容易做选择；而如果选择vmware作为虚拟化的话，那么，能做好的也就几个大厂有实力。
对于一众创业型CMP公司，基本没有对接SDN的能力。就是说支持，也只是理论，或者简单支持，根本唔打上生产。
SDN可以提供网络设备的规划和管理，具体的好处在于运维管理。当前阶段，建议云平台和SDN是同一供应商，这样配合会更好。
SDN采用overlay的技术：
Overlay组网方案上存在网络Overlay、主机Overlay、混合Overlay三种：
ν 网络Overlay：有网络设备提供Overlay的报文处理、转发，性能较高，对服务器及其上的Hypervisor软件无要求，同时也可以使物理服务器进入Overlay网络中，管理界面也较清晰。
ν 主机Overlay：由服务器上的Hpervisor层或其中的vSwitch提供Overlay的报文处理、转发，部署较方便成本也相对低，但性能存在一定不足。
混合Overlay：有统一的控制器（Controller）控制，可同时提供主机Overlay和网络Overlay。可满足多形态服务器场景的需求，兼顾灵活性和高性能。
在服务器端部署vSwitch ,可基于Linux KVM、VMware vSphere、Microsoft Hyper-V等平台部署。Vxlan VTEP和GW由controller统一集中管理。核心设备主要提供Vxlan网关功能，支持Vxlan报文的封装与解封装，并根据内层报文的IP头部进行三层转发，实现跨Vxlan之间的转发，也可支持Vxlan和传统VLAN之间的互通。
vSwitch主要提供虚拟化Vxlan隧道封装功能，支持VM接入Overlay网络，支持Vxlan报文的封装与解封装，支持跨Vxlan之间的转发。此时vSwitch连接的物理交换机无需支持Vxlan功能。物理接入网络设备主要提供Vxlan隧道封装功能，支撑物理服务器接入Overlay网络，支持Vxlan报文的封装与解封装，并根据内层报文的MAC头部进行二层转发。
混合Overlay组网同时支持软硬件形态的边缘设备，灵活组网部署。提供虚机与非虚拟化的物理服务器之间的二层数据互通。采用高性能物理设备，可以提升网络的整体性能。控制面的SDN Controller支持集群，并可通过扩展控制节点实现Overlay网络规模的扩展，考虑可靠性，Controller节点至少3个。同时支持分布式网关功能，虚机迁移后无需重新配置网关等网络参数。
构建的虚拟化网络通过SDN控制器提供的Openstack的Neutron插件，与整个OpenStack平台联动，最终构成一个全自动交付的网络资源池。
云计算平台体系采用标准的社区架构，坚持按照云计算平台组件化、模块化的思路进行产品开发和生产，各个模块之间的对接均按照社区标准API、插件等方式进行设计。云计算平台支持通过SDN网络Neutron插件的方式对接第三方SDN网络并进行纳管，实现计算、网络、存储跨资源领域的编排。

## Q2: 云平台sdn网络在原有网络中定位的问题？云平台SDN网络在实施过程中的问题？
A2
建议采用两层网络模型，从而在物理上部署多个结构相同的二层网络从而保障物理网络最优架构。同时采用SDN思路和基于Vxlan的网络Overlay技术进行部署。
（1）通常来讲，会使用在C区内逻辑隔离A，B类业务；使用东西防火墙做业务隔离
（2）云平台的对接，主要是使用neturon来对接，这个需要SDN厂商提供driver，对接ACI，AC ，VCFC控制器；SDN网络和客户的网络主要还是使用vlan+vxlan的方式打通；
我们一般使用4个网：管理网， 业务网（vxlan），带外网，存储网；
（3）使用不同子网

## Q3: 云平台有SDN和无SDN的区别是什么？SDN到底能为云平台带来哪些好处？
A3
接入层交换机需具备1G/10G自适应端口，满足1G/10G网卡接入，解决现有云网络带宽容量问题。
服务器接入采用万兆双网卡接入，并采用双网卡双活工作模式提高服务器接入带宽
骨干层和接入层之间通过多条40G线路三层路由互连，骨干链路需要通过技术手段实现链路的负载分担，提高骨干流量带宽
SDN Fabric网络架构采用“Spine+Leaf”两层新架构设计，骨干和接入层之间三层方式连接，以避免二层网络可能带来的环路和广播风暴问题
骨干层多台设备相互独立，骨干设备单台故障不影响其他骨干设备
骨干层和接入层之间通过多条40G线路三层路由互连，骨干链路和采用ECMP技术手段实现链路的冗余，确保一条链路故障，不影响业务转发
服务器接入采用万兆双网卡接入，双网卡部署双活工作模式实现服务器接入侧的接口冗余和接入链路冗余 
通过Vxlan实现不同功能以及业务网络之间的相互逻辑及安全隔离，不同重要程度的功能网络在网络传输过程中能实现基于优先级或带宽的流控。
SDN Fabric架构支持租户、安全域、安全纳管、自定义业务网络、服务连等技术实现用户间、应用间的访问隔离，确保租户与租户之间、应用与应用之间的隔离。
Fabrci架构采用VXLAN技术实现整个Fabric架构的overlay网络重构
采用SDN控制器以及EVPN技术实现对虚拟网络的抽象，实现业务与物理网络解耦
支持以租户的形式为应用提供虚拟承载网络，每个租户虚拟网络能够实现按需分配
SDN控制器支持设备自动化上线，支持Underlay和Overlay的统一管理，支持通过基于Rping等探测方式实现故障定位
实现与服务器配套的网络配置同步和安全策略的管理，支持虚拟化服务器的自动迁移及相应安全策略的动态调整。

## Q4: 私有云内部安全区域规划？
A4
网络分区分层是金融行业必须的安全规范，目前传统的还是以物理隔离为主要环境架构， 随着sdn的测试上线 可进行虚拟的分区分层的网络隔离操作，和物理分区一样每个区域是不能直接互联必须有虚拟防火墙和路由器在中间进行网络隔离，具体分区方式看你的业务需求或者找一个网络规划公司做下网络规划
在考虑云安全防护需求时，更多的需要结合云内部的安全体系架构来进行落实。云内部建立云内的网络安全防护机制，在未经过授权允许的情况下，云内各系统间默认情况下不能相互访问，将不同应用系统加入到不同的安全区域，不同安全区域之间的云主机网络默认隔离。当需要互通时，通过修改域间规则，来打开互访通道。

## Q5: 私有云平台架构中，安全规则和方案怎么制定？
A5
**1) 云计算物理层安全**
云计算物理层面临着对计算机网络与计算机系统的物理装备的威胁，是指由于周边系统环境和物理特性导致的网络安全设备和线路的不可用，从而造成所承载的网络应用不可用。主要表现在自然灾害、电磁辐射、三防（防火、防水、防尘）及恶劣的工作环境方面，而相应的防范措施包括抗干扰系统、物理隔离、防辐射系统、供电系统的冗余设计和可靠性备份，采取前后上下等多种通风方式。
**2) 虚拟化资源层安全**
虚拟化层是云计算代表性的属性之一，也是现阶段云计算数据中心实施最为广泛的技术，基于服务器的虚拟化技术，可以将单台物理服务器虚拟出多台虚拟机并独立安装各自的操作系统和应用程序，从而有效提升服务器本身的利用效率。但是这种虚拟化技术也带来了一些安全风险，比较典型的有基于虚拟化所衍生的一些安全漏洞，以及针对VM-VM虚拟机流量交换的安全问题。
虚拟化软件导致的安全漏洞风险：这个问题可以从2个方面来看，一方面，以虚拟化应用程序本身可能存在的安全漏洞将影响到整个物理主机的安全。黑客在利用漏洞入侵到主机系统之后，可以对整个主机上的虚拟机进行任意的配置破坏，从而导致系统不能业务，或者是将相关数据进行窃取,如果黑客侵入了虚拟机配置管理程序，则会直接影响到其管理的全部虚拟机的安全。另一方面，基于虚拟化环境开发的各种第三方应用程序的漏洞安全。这些应用程序是云服务交付的核心组成，包括Web前端的应用程序、各种中间件应用程序及数据库程序等，即使在传统网络安全环境下，他们仍然会因为编程技术的缺陷而存在多个安全漏洞，在云计算环境下，这些安全漏洞会继续存在，典型如各种WEB会话控制漏洞、会话劫持漏洞及各种注入攻击漏洞。同时为了适应或使用虚拟化环境下的各种API管理接口，也可能产生一些新的安全漏洞。
云计算虚拟机流量交换的安全新风险：在虚拟化环境下，单台物理服务器上可以虚拟化出多个完全对立的虚拟机并运行不同的操作系统和应用程序，各虚拟机之间可能存在直接的二层流量交换，而这种二层交换并不需要经过外置的二层交换机，管理员对于该部分流量既不可控也不可见，在这种情况下，管理员需要判断VM虚拟机之间的访问是否符合预定的安全策略，或者需要考虑如何设置策略以便实现对VM之间流量的访问控制。
**3) 多租户IaaS服务层安全**
多租户环境下的基础安全服务主要体现在IaaS服务层。IaaS作为云计算的重要组成部分，其将基础设施包括网络、存储、计算等资源进行虚拟化等处理，能够为每个用户提供相对独立的服务器计算资源、存储资源以及在承载网上设定专有的数据转发通道，这种云计算的模式已经得到IT业界的广泛认可.在本次大地保险云安全平台的建设过程中，基于IaaS模型下的各种安全服务体系的建设其是重点所在，根据现阶段的需求来看，这部分服务主要包括针对云计算防火墙服务、云计算负载均衡业务。不同的租户可以根据自身的业务需求，合理的选择部署云安全防火墙服务或者是防火墙叠加负载均衡业务。部署该安全服务后，每个租户可以获得逻辑上完全属于自己的防火墙和负载均衡。租户可以根据自身需求，设定自身的各种安全防护策略，生成自身独有的安全日志分析报告。同时对于部分需要负载均衡的业务，也可以设置独立的负载均衡的算法，以保证业务的可靠性运行。当然，考虑到应用层的安全风险一直是互联网的重点防护对象之一，各种基于web应用层的安全攻击会导致用户业务系统的权限被窃取以及关键数据的泄露，未来也可以考虑增加一些新的诸如IPS入侵检测等增值服务，用户可以根据自身业务系统的安全级别合理选择是否租用该漏洞防护服务等。这部分的内容后续将作为重点进行论述。
**4) PaaS/SaaS应用层数据安全**
在云安全体系的建设过程中，PaaS和SaaS的安全建设也非常重要。和IaaS的建设思路不同，PaaS的安全建设，其关键在于平台开放的思想下，开发者应用平台及数据库系统对于多开发者数据安全的适配。典型问题包括针对开发者的用户身份认证，开发者的平台和数据库的访问使用权限控制，不同开发者数据的安全隔离、及操作行为审计等内容。为此需要在数据库的开发及平台应用环境开发过程中考虑到上述安全风险的防护。而在SaaS模型下，应用系统级的多租户共享涉及到的应用层安全问题，除了多租户身份认证和权限控制及数据库安全隔离等需求外，还需要考虑针对应用环境的代码级的安全审计等问题，确保提供给租户的应用程序本身的安全具备很高的水平，不会轻易被黑客等攻击者利用其内在的各种安全漏洞。在本次的大地保险云建设过程中，这部分的安全通过合理配置数据库及应用程序来进行保证。
**5) 建立安全运维体系，确保系统安全**
除了前面提到的各种安全措施，还需要在运维管理方面建立相应的安全措施，形成完善的运维体系，以确保整个系统安全。
**¬ 专业安全运维团队**
配备了一支高水平的专业安全运维团队,安全团队的成员都经过严格挑选，具备良好的道德修养和职业操守，同时具备极高的专业安全技术水平。安全团队有严格安全保密制度，有效的安全操作管控能力，以及长效的安全审计机制。
**¬ 日常安全流程**
安全运维团队实行7X24小时安全值守服务，随时监控和处理日常安全问题。对于常见的网络攻击和入侵探测等，大多数都由云平台自动化处理，少数情况需安全人员人工判断后加以处理。同时，安全团队还及时对各系统运维人员的安全服务请求作出响应，配合各系统运维人员做好安全防范工作。
**¬ 应急响应流程**
一旦发生特大的网络攻击或新类型的安全问题，安全运维团队将启动突发安全事件应急响应流程。应急响应流程将紧急调动各方资源，临时提升云平台防护门槛，组织专家会诊安全问题，制定紧急应对方案并立即实施。对于新型安全问题，将即刻启动安全防御新功能开发，并尽快上线启用，保证安全系统的及时升级和安全的长效性。
**¬ 安全消防演习**
安全团队不定期会进行必要的安全消防演习，以考验各种安全流程和资源在实战状态下的有效性。消防演习一般不做事前通知，并在可控范围内发起模拟网络攻击和黑客入侵，同时记录各安全处理环境的效率和结果，最终评判整个安全体系的防卫和响应能力。

## Q6: 如何在云平台上实现多租户的资源分配与安全隔离？
A6:
用户、租户与多租户是一个适用于多个行业的普遍性概念。
一个环境/系统的一个使用者即该环境/系统的一个用户。系统允许其用户通过一个登录流程（enrollment process）进入该系统，并获取访问系统及其资源的权限。用户在管理粒度上被分到若干组内，每组成为一个租户（tenant）。一个简单的层级中，一个用户只属于一个租户；但是，复杂情况下，一个租户还可以有自租户。因此，用户可以分为几类，包括管理员用户，租户管理员用户和普通租户用户等。
多租户（multi-tenancy）是指一个建立在共同的底层资源上的环境被被多个租户共同使用。就像一个大楼一样，许多租户共享大楼的基础设施，比如电梯，但是使用墙和门来在租户之间做隔离；在一个公司内部，敏感部门还需要进一步隔离。多租户的含义包括两个方面：（1）共享带来经济性 （2）隔离保证安全性。
在 SaaS 层面，多租户是一种应用的架构形式，它使得 SaaS 提供商可以通过搭建在共享的硬件和软件架构上的一个应用来同时地服务不同租户中的用户。这么做，可以通过更好地利用基础架构资源，以及简化维护和管理来显著降低运行费用，比如，对应用做一次升级就可以使得所有用户获得最新版本。
SaaS 多租户可以在不同的层面实现：（1）利用虚拟化技术在基础架构层实现，比如给不同的租户创建单独的虚机，在虚机中运行应用 （2）在中间件层实现：共享操作系统和中间件，租户拥有单独的应用，比如容器 （3）在应用层实现：所有租户共享单个或者若干个应用，在应用内或者应用访问层实现租户隔离。其中，在应用层实现可以最大限度地提高效率：所有底层架构，包括存储、操作系统、中间件和应用都在不同的租户之间共享。
然而，在应用层实现多租户，是最难实现性能隔离的。性能隔离的目标包括：（1）阻止一个租户使用应用影响到别的租户使用应用的性能 （2）确保每个租户的可能不同的 SLA。根据租户的需求，往往是价格，每个租户的 SLA 可以不同。
举个例子，一个 SaaS 供应商提供一个在线酒店预订系统作为一个在线软件服务给他的租户，比如旅游中介。每个旅游中介的员工和客户都是该租户的一个终端用户。这种应用在季节性需求旺盛或者举行促销时，租户的请求往往达到短期的峰值。因此，对于 SaaS 供应商来说，如果确保一个需求达到峰值的租户（比如正在做促销的租户）不会影响其它租户使用该应用的性能就非常关键了。除此以外，每个租户可以要求不同的 SLA，根据他们的需要。比如，一个大型的旅游中介往往要求在峰值期间能够处理更大量的请求。
为了说明这种租户的影响，我们使用两种方式来部署应用。第一种方式，给每个租户分配一个虚机，这种情况下，应用不是多租户的。性能隔离通过虚机实现，请求大的租户也没法获得分配给他们的虚机的资源以外的更多资源。第二种方式，在物理基础设施集群上部署一个多租户的应用集群。每个虚机中运行同样应用的一个实例，所有租户都可以访问。这个集群使用一个 FIFO 的负载均衡器来转发所有租户的请求到三个虚机上。而在应用层，没有做别的事情来做性能隔离。
第一种方式中，实现了不同租户之间的性能隔离，但是，这种方式有可能造成某个应用示例出现空闲。但是，第二种方式中的应用层面的多租户，一个租户的峰值请求明显地将会影响别的租户。理想情况下，云管理系统会监控访问请求的增长，并会在它出现峰值时增加新的虚机到集群中来处理新增请求。但是，这种方式需要至少几分钟的时间来启动新的虚机。
一个私有云往往是单租户的，因为它部署在一个企业的数据中心内，被该企业内的员工使用。一个公有云往往是多租户的，因为从成本考虑，所有的租户都共享硬件或者软件资源，租户隔离粒度相对较高。但是在某些时候，私有云或者公有云也需要较高的隔离粒度，比如一个公司内的财务部门，出于安全性考虑，需要它所使用的虚机与别的部门使用的虚机隔离开来；比如一个政企部门，在公有云上，要求它的所有虚机或者存储必须在单独的服务器上。这种情况下，可以分为两种隔离粒度：
在一个云内的有限隔离粒度：虚机被物理地隔离在指定的服务器上，但是存储和网络实现逻辑隔离就够了。
在多个云内的完全隔离：这就是专有云，一个用户完全使用专属物理资源来搭建它的专有云。
隔离可以在不同的层面，使用不同的技术实现：
物理层面的隔离：这是最完全的隔离，不同的租户使用不同的物理硬件，包括计算和存储服务器和网络设备等。
计算在操作系统层面的隔离：虚机，一方面它提供较高的安全隔离性，另一方面，它结合其它技术比如 Linux cgroup 来实现性能保证。
计算在中间件层面的隔离：比如容器，它共享操作系统等底层资源，使用 Linux namespace 等技术提供一般的隔离性。
网络在逻辑层面的隔离：使用 VLAN, VxLAN，GRE 等方式来实现网络流量的逻辑隔离。
存储在应用层面的隔离：比如 Ceph 和 Swift 等共享存储，提供应用层面的租户隔离性。

# 四、金融行业私有云实践中遇到的问题

## Q1: 基于openstack的云平台和vmware vRA的云平台对于金融机构如何进行选择？如何选择云平台基础架构？
A1
首先，要看底层计算虚拟化的使用；如果基于KVM，那么肯定是openstack比较好；如果是vmware的虚拟化，那么vRA的管理则更胜一筹；openstack对接vmware虚拟化，目前国内能做好的，除了几个大厂，其他很少能做；主要是opentack本身对接vmware社区的功能就完成50%，其余的要靠厂商自己去开发，这个不是小长能做的。
vRA对与SDN这块，软件的NSX是其主要的支持；对于硬件SDN的支持，可能要看NSX-t；同时NSX价格不菲；
openstack对于软硬件的SDN支持都比较好，但是可用性方面，以及和vmware计算虚拟化的联动方面都是一个很大的问题
两个技术 比较来说 openstack技术难度大，如果自身运维能力不够建议用VMware，但不要用vRA开发成本太高
对于基础架构的选择：
从私有云的基础架构看来，可以分为计算虚拟化，存储虚拟化，网络虚拟化三大类，同时，还有其他的功能作为补充
计算虚拟化和存储虚拟化，目前有超融合架构和分离式架构可以选择。对于中小规模，建议两者都可以；如果是超大规模，建议使用分离式比较好
计算虚拟化，可以选择vmware或则会kvm，是目前的主流
存储虚拟化，主要是分布式存储和传统存储，云环境都能支持
网络虚拟化，主要是分硬件SDN和软件SDN
只要想清楚以上的问题，基本就可以把基础架构私有云搭建起来了。
对于应用选择架构的问题，需要case by case的谈。例如，数据库的业务，那么我就必须给它分配高性能的CPU，最好是SSD的存储，高速网络-万兆双网卡mod4绑定。

## Q2: 金融行业私有云平台应该如何选择，并且如何保证安全可靠性？
A2
**安全总体需求可分解为如下内容。**
（1） 保护金融信息资源价值不受侵犯；
（2） 保证信息资产的拥有者面临最小的风险和获取最大的安全利益；
（3） 保证金融的信息基础设施、信息应用服务和信息内容为抵御各种安全威胁而具有保密性、完整性、真实性、可用性和可控性的能力。
1)等保合规
为了满足大地保险云等保的安全性要求，我们建议从网络安全、云主机安全、数据安全、应用安全、安全审计等方面进行安全等保考虑
2）网络安全
防攻击能力
集成漏洞库、专业病毒库、应用协议库的IPS产品，特征库数量10000+以上。能精确识别并实时防范各种网络攻击和滥用行为。SecPath IPS通过了国际权威组织CVE(Common Vulnerabilities & Exposures，通用漏洞披露)的兼容性认证，在攻击防护方面达到业界顶尖水平。
专业的网管软件通常具有较强的网络设备接口信息监测功能。网管软件可以全天候监测路由器、交换机等主要网络设备的端口流量、端口使用率、内存、CPU、路由表等信息，通过设备物理面板图真实反映网络设备接口的运行状态，还可根据需要对面板进行配置。

此外，网管软件也会提供一些常用的网络工具，方便网络管理员对网络设备进行远程监控和管理。
3）云主机安全
包括密码安全，补丁安全，防病毒软件
4）数据安全
包括备份安全，操作安全，
5）应用安全
包括应用漏洞扫描，数据库漏洞扫描
6）安全审计
包括堡垒机，数据库审计

## Q3: 上云之后对IT部门的架构有什么样的影响？
A3
云计算使传统意义上的数据中心从原来的成本中心转变成服务中心，支持向公司内部输出规范的、有质量保证的服务，降低服务成本、运营成本的同时促进IT部门运维模式发展变革，简化系统建设、运维工作，提升工作效率。
对于金融保险业，云计算有其独特的价值：
λ 缩短上线周期
云计算的引入能够显著缩短硬件资源、平台环境、应用系统的部署周期，支持各部门在最短时间内以“随需即取”的方式获取系统部署所需的一切服务资源，运维管理团队即可根据服务模板实现远程快速部署和动态调整，减少重复性建设工作，支撑业务的快速发展变化。
λ 进一步实现绿色节能
云计算构建于池化的硬件资源基础上，并进一步实现服务化封装及更高层级的细粒度服务复用，从而相应降低对数据中心机房的电力、制冷、空间消耗，实现机房绿色节能。
λ 促进运维模式发展变革
针对业务需求部门提供自助式服务，需求部门依据定制的云服务目录选取所需的计算资源、存储空间、网络服务、基础平台环境等服务项并提交申请，运维管理团队根据定制成型的服务模板，依靠自动化技术及云管理平台来交付规范的、有质量保证的服务，将传统运维模式转变为以服务为中心的方式，降低系统建设、运维、管理工作量。
运维人员角色的转变，image维护人员，云服务实施人员，持续运维人员，和资源管理人员，角色不通 与传统运维，日后运维多是 运维需求调研开发运维产品上线，自动业务需求梳理开发相关软件上线

## Q4: 云平台技术适合在保险行业中哪些应用率先发起？是否有评判的标准？
A4
这个应该和应用的设计有关。如果应用采用微服务化的设计，那么就必须要有云环境来承接
云计算分好多细节技术 包括powervm openstack VMware等 容器另外一种敏态技术，如果要引入云化管理可先配置云管平台把已有稳态技术类似VMware上的vm 转化为 云管vm 自动化的部署vm产品和 内容服务， 目前保险行业引入VMware技术已经很成熟可考虑先云化VMware技术的vm，说起云化应用最好先选择积分，短信催单等外围系统。保证运维水平和技术能力完全可对云化运维完成业务支撑后，再次对核心业务进行云化管理转化。

## Q5: 虚拟化程度较高的中小金融企业上私有云有什么明显的好处？
A5
看你管理的 vm 数量，如果超过400个vm最好上一个云管平台，减少认为操作和快速vm以及业务供给，把相关人员技术路线从运维转化为自动化运营，使内部投资成本降低而效率提高
云计算使传统意义上的数据中心从原来的成本中心转变成服务中心，支持向公司内部输出规范的、有质量保证的服务，降低服务成本、运营成本的同时促进IT部门运维模式发展变革，简化系统建设、运维工作，提升工作效率。
对于金融保险业，云计算有其独特的价值：
λ 缩短上线周期
云计算的引入能够显著缩短硬件资源、平台环境、应用系统的部署周期，支持各部门在最短时间内以“随需即取”的方式获取系统部署所需的一切服务资源，运维管理团队即可根据服务模板实现远程快速部署和动态调整，减少重复性建设工作，支撑业务的快速发展变化。
λ 进一步实现绿色节能
云计算构建于池化的硬件资源基础上，并进一步实现服务化封装及更高层级的细粒度服务复用，从而相应降低对数据中心机房的电力、制冷、空间消耗，实现机房绿色节能。
λ 促进运维模式发展变革
针对业务需求部门提供自助式服务，需求部门依据定制的云服务目录选取所需的计算资源、存储空间、网络服务、基础平台环境等服务项并提交申请，运维管理团队根据定制成型的服务模板，依靠自动化技术及云管理平台来交付规范的、有质量保证的服务，将传统运维模式转变为以服务为中心的方式，降低系统建设、运维、管理工作量。

## Q6: 有没有做过新数据中心建设中详细的私有云设计方案？包含业务分析调研及最终不同业务采用不同方案来实现的？
A6
数据中心多 虚拟技术管理 统一云管理平台，支持自服务配置开发等等，看你团队的技术能力和技术规划路线，数据中心目前核心最好跑在稳态的技术上就是传统的 网络和vm技术， 其他外围业务可在敏态技术上如容器等， 设计方案规划个十年就可以了，先调研好自由业务的 团队能力再进行设计比较实际。

私有云平台云平台私有云云安全

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！