云计算资源池平台架构设计.docx
《云计算资源池平台架构设计.docx》由会员分享，可在线阅读，更多相关《云计算资源池平台架构设计.docx（71页珍藏版）》请在冰点文库上搜索。
云计算资源池平台架构设计
云计算资源池平台架构设计
第1章云平台总体架构设计
基于当前IT基础架构的现状，未来云平台架构必将朝着开放、融合的方向演进，因此，云平台建议采用开放架构的产品。
目前，越来越多的云服务提供商开始引入Openstack，并投入大量的人力研发自己的openstack版本，如VMware、华三等，各厂商基于Openstack架构的云平台其逻辑架构都基本相同，具体参考如下：
图2-1：
云平台逻辑架构图
从上面的云平台的逻辑架构图中可以看出，云平台大概分为三层，即物理资源池、虚拟抽象层、云服务层。
1、物理资源层
物理层包括运行云所需的云数据中心机房运行环境，以及计算、存储、网络、安全等设备。
2、虚拟抽象层
资源抽象与控制层通过虚拟化技术，负责对底层硬件资源进行抽象，对底层硬件故障进行屏蔽，统一调度计算、存储、网络、安全资源池。
3、云服务层
云服务层是通过云平台Portal提供IAAS服务的逻辑层，用户可以按需申请相关的资源，包括：
云主机、云存储、云网络、云防火墙与云负载均衡等。
基于未来云平台的发展趋势及华北油田数据中心云平台的需求，华北油田的云平台应具备异构管理能力，能够对多种虚拟化平台进行统一的管理、统一监控、统一运维，同时，云平台能够基于业务的安全需要进行安全防护，满足监控部门提出的安全等级要求。
下面是本次云平台架构的初步设计，如下图所示：
图2-2：
云平台总体架构图
第2章资源池总体设计
从云平台的总体架构可以看出，资源池是云平台的基础。
因此，在构建云平台的过程中，资源的池化迈向云的是第一步。
目前，计算资源的池化主要包括两种，一种是X86架构的虚拟化，主要的虚拟化平台包括VMware、KVM、Hyper-V等；另一种是小型机架构的虚拟化，主要的虚拟化平台为PowerVM，这里主要关注基于X86架构的虚拟化。
存储资源的池化也包括两种，一种是当前流行的基于X86服务本地磁盘实现的分布式存储技术，如VMwareVSAN、华为FusionStorage、华三vStor等；另一种是基于SAN存储实现的资源池化，实现的方式是利用存储虚拟化技术，如EMCVPLEX、华为VIS（虚拟化存储网关型）和HDSVSG1000（存储型）等。
这两种方式分别适用于不同的场景，对于普通的数据存储可以尝试使用分布式存储架构，如虚拟机文件、OLAP类数据库等，而对于关键的OLTP类数据库则建议采用基于SAN存储的架构。
网络资源池化也包括两种，一种是基于硬件一虚多技术实现的网络资源池，如华为和华三的新型的负载均衡、交换机、防火墙等设备；另一种是基于NFV技术实现的网络资源池。
这两种方式分别适用于不同的场景，对于南北向流量的网络服务建议采用基于硬件方式实现的网络资源池化，而对于东西向流量的网络服务建议采用基于NFV技术实现的网络资源池化。
图2-2-1：
华北油田资源池总体设计示例
2.1X86计算资源池设计
2.1.1计算资源池设计
服务器是云计算平台的核心之一，其承担着云计算平台的“计算”功能。
对于云计算平台上的服务器，通常都是将相同或者相似类型的服务器组合在一起，作为资源分配的母体，即所谓的服务器资源池。
在这个服务器资源池上，再通过安装虚拟化软件，使得其计算资源能以一种虚拟服务器的方式被不同的应用使用。
这里所提到的虚拟服务器，是一种逻辑概念。
对不同处理器架构的服务器以及不同的虚拟化平台软件，其实现的具体方式不同。
在x86系列的芯片上，其主要是以常规意义上的VMware虚拟机或者H3Cloud虚拟机的形式存在。
后续的方案描述中，都以H3C虚拟化软件进行描述。
∙CVK：
CloudVirtualizationKernel，虚拟化内核平台
运行在基础设施层和上层操作系统之间的“元”操作系统，用于协调上层操作系统对底层硬件资源的访问，减轻软件对硬件设备以及驱动的依赖性，同时对虚拟化运行环境中的硬件兼容性、高可靠性、高可用性、可扩展性、性能优化等问题进行加固处理。
∙CVM：
CloudVirtualizationManager，虚拟化管理系统
主要实现对数据中心内的计算、网络和存储等硬件资源的软件虚拟化，形成虚拟资源池，对上层应用提供自动化服务。
其业务范围包括：
虚拟计算、虚拟网络、虚拟存储、高可靠性（HA）、动态资源调度（DRS）、虚拟机容灾与备份、虚拟机模板管理、集群文件系统、虚拟交换机策略等。
采用购置的虚拟化软件对多台PC服务器虚拟化后，连接到共享存储，构建成虚拟化资源池，通过网络按需为用户提供计算资源服务。
同一个资源池内的虚拟机可以共享资源池内物理服务器的CPU、内存、存储、网络等资源，并可在资源池内的物理服务器上动态漂移，实现资源动态调配。
计算资源池逻辑组网架构图如下所示：
计算资源池逻辑组网架构
建成后的虚拟化系统，虚拟机之间安全隔离；虚拟机可以实现物理机的全部功能；兼容主要服务器厂商的主流X86服务器、主流存储阵列产品、运行在X86服务器上的主流操作系统，并支持主流应用软件的运行。
2.1.2资源池主机容量规划设计
单台服务器所能支持虚机数量的决定因素主要取决与两方面：
⏹服务器的硬件配置
♦CPU性能---多核高主频技术使得CPU成为性能瓶颈的可能性越来越低
♦内存大小---做为硬指标的内存，配置越高，所能支持的虚机数量越多
♦网络端口---千兆网环境已很普遍，网络带宽大多有保证，更多从管理角度来考虑
♦HBA卡---磁盘访问性能对虚机数量有一定影响，建议采用10G以太网或者8GbpsFC以减少链路影响
♦本地磁盘---内置磁盘的可用性及IO吞吐能力均较弱，不建议在其上存放虚拟机，推荐使用外置高性能磁盘阵列
⏹应用负载大小
♦由于物理服务器资源自身的最大限制，应用负载越大，所能同时运行的虚机数量越少
♦建议将不同应用访问特性的应用混合部署在同一物理服务器上
♦灵活运用DRS和VMotion技术可将物理机与虚机的比率关系调到最优
♦考虑到HA及DRS所要求的资源冗余，所有运行虚机在正常负载下，总体资源使用率不超过三分之二会比较合适
在部署虚拟化时，对物理服务器的硬件配置需要考虑以下因素：
♦可用的CPU目标数量尽可能多，单台服务器建议配置6个以上的CPU核。
♦超线程技术并不能提供等同于多核处理器的好处；建议关闭CPU的超线程功能
♦使用具有EM64T能力的IntelVT或AMDV技术的CPU可以同时支持运行32位和64位的虚拟机
♦采用同一厂商、同一产品家族和同一代处理器的服务器组成的集群，可以获得最好的虚拟机迁移兼容能力
♦内存资源往往比CPU资源更会成为潜在的瓶颈，尽可能采用最大容量的内存条（单条8GB效果优于两条4GB）。
下表给出了部署虚拟化时的服务器建议配置：
服务器CPU路数
双路
四路
CPU（建议主频2GHz以上）
双路四核
四路双核或四核
内存
16GB+
32GB+
千兆网口
无外接存储
4+/6+
4+/6+
使用FC存储
4+/6+
4+/6+
使用IP存储
6+/8+
6+/8+
SAN端口
2*8GbpsFC
或
2*10GbpsEth
2*8GbpsFC
或
2*10GbpsEth
内置硬盘（使用外置磁盘阵列时）
2
2
电源
双冗余
双冗余
⏹虚拟机资源分配设计
1.虚拟机CPU分配原则：
♦尽量使用最少的vCPUs，如果是单线程应用，无需多线程处理。
♦虚拟CPU数量不要等于或超过物理CPU核数，如双路双核的服务器配置，虚机最多使用两个虚拟CPU
2.内存分配原则：
♦内存总量为在资源评估后，计算虚拟机评估结果所需实际内存尽量避免大于物理内存的总和。
因为应用程序而产生的更多内存需要用磁盘内存来解决，会导致系统性能下降。
如需要P2V迁移，在进行虚拟化迁移之前，应对每个应用系统虚拟化迁移后所需的虚拟计算进行合理的评估和计算，以确保迁移后应用系统的可用性、可靠性和各项性能指标可满足业务目标。
虚拟资源计算的原则是，如果客户希望业务系统迁移后，业务系统能够保持与原系统一致的体验，我们建议虚拟机的计算能力与原物理服务器的计算能力保持一致；如果客户希望通过P2V的迁移，提高资源的利用率，我们建议虚拟机的计算能力可以相比原先进行一定程度的压缩，具体的压缩计算方式如下图所示。
2.1.3高可用保障
⏹主机高可用
H3CCAS虚拟化平台HA功能会监控该集群下所有的主机和物理主机内运行的虚拟主机。
当物理主机发生故障，出现宕机时，HA功能组件会立即响应并在集群内另一台主机上重启该物理主机内运行的虚拟机。
当某一虚拟服务器发生故障时，HA功能也会自动的将该虚拟机重新启动来恢复中断的业务。
除了对集群中的物理服务器节点进行持续检测之外，H3CCASHA软件模块还对运行于物理服务器节点之上的虚拟机进行持续检测。
在每台服务器节点上都运行了一个LRMd（LocalResourceManagerdaemon，本地资源管理器守护进程），它是HA软件模块中直接操作所管理的各种资源的一个子模块，负责对本地的虚拟化资源进行状态检测，并通过shell脚本调用方式实现对资源的各种操作。
当LRMd守护进程检测到本机的某台虚拟机出现通信故障时，首先将事件通知给DC，由DC统一将该虚拟机状态告知集群内所有的物理服务器节点，并按照一定的策略算法，为该故障的虚拟机选择一个空闲的服务器节点，在该节点上重启该虚拟机。
⏹操作系统蓝屏高可用
蓝屏又称之为蓝屏死机（BlueScreenofDeath，BSoD），是微软Windows操作系统无法从一个系统错误中恢复时，为保护计算机数据文件不被破坏而强制显示的屏幕图像。
从专业的角度来讲，蓝屏被定义为“当微软Windows操作系统由于出现灾难性错误或者内部条件阻止系统继续运行而显示的蓝色屏幕”。
Linux类型操作系统没有蓝屏的概念，与之对应的称之为内核崩溃（KernelPanic），此时，可能会在终端输出内核栈，如果Linux操作系统开启了CoreDump选项，则会产生Core文件。
H3CCASCVK虚拟化内核系统支持虚拟机蓝屏（Windows）和崩溃（Linux）的故障检测及HA处理，前提条件是在虚拟机操作系统上必须安装CAStools工具，该工具的目的是通过虚拟串口通道保持与H3CCASCVK虚拟化内核系统的实时通信，判定虚拟机的存活状态，如果在3个时间周期（一个周期为30秒）内没有接收到操作系统CAStools的应答，则通过探测虚拟机磁盘I/O读写来进一步判定虚拟机的存活状态，如果在6个时间周期（一个周期为30秒）内没有探测到虚拟机磁盘I/O读写活动，则判定虚拟机操作系统蓝屏。
当确定虚拟机出现蓝屏之后，有三种HA处理方式，可由系统管理员在H3CCASCVM虚拟化管理平台上配置：
（1）不处理：
即使检测到虚拟机蓝屏故障，也不会做任何处理（默认配置）。
（2）故障重启：
将蓝屏后的虚拟机在本地物理主机上重新启动。
（3）故障迁移：
将蓝屏后的虚拟机迁移到集群内其它正常工作的物理主机上。
⏹应用高可用
应用HA是指运行于虚拟机操作系统内的业务系统的高可靠性，当业务系统由于自身原因导致无法对外正常提供服务时，可以借助应用HA功能，以最短的时间自动恢复业务。
企业级业务系统一般都以进程服务的方式驻留在操作系统内，H3CCASCVM虚拟化管理平台利用CAStools工具来监控业务服务进程的状态，该工具安装在虚拟机操作系统上，通过虚拟串口通道保持与H3CCASCVM虚拟化管理平台的实时通信，判定业务的存活状态。
如果在连续3个时间周期（1个周期为30秒）内探测到被监测的服务状态为非运行或非活跃状态，则自动重启该服务，如果连续4个时间周期检测到应用服务故障，且重启服务失败，则根据系统管理员配置的应用HA策略，重新启动虚拟机或仅上报应用故障不可恢复的告警消息。
H3CCAS应用HA服务检测机制
应用HA特性给客户带来如下明显的价值：
（1）实时显示应用程序的可用性状态；
（2）当应用程序不可用时，执行用户自定义的修复策略，包括重启服务和重启虚拟机，最小化业务宕机时间；
（3）当应用程序不可用时，触发告警通知。
2.1.4性能状态监控
◆基于物理服务器的性能监控
提供物理服务器CPU和内存等计算资源的图形化报表及其运行于其上的虚拟机利用率TOP5报表，为管理员实施合理的资源规划提供详尽的数据资料。
物理服务器性能图形报表
◆基于虚拟机的性能监控
提供虚拟机CPU、内存、磁盘I/O、网络I/O等重要资源在内的关键元件进行全面的性能监测。
虚拟机性能图形报表
◆基于虚拟交换机的性能监控
提供虚拟机交换机上各个虚端口的流量统计与模拟面板图形化显示。
虚拟交换机状况监测
◆基于虚拟网卡的性能监控
提供进出虚拟机虚端口的流量的图形化实时显示。
虚拟网卡性能状况监测
2.2PowerVM计算资源池设计
小型机，在国内习惯上用来指UNIX服务器，在服务器市场中处于中高端位置。
小型机具有区别X86服务器和大型主机的特有体系结构，各厂商使用自家的UNIX版本的操作系统和专属处理器。
小型机以其RAS（高可靠性、高可用性、高服务性）等特性，在金融、政府、电信、工业等领域广泛使用。
IBMPower小型机在中国保守估计每年的销量是20,000台，市场存量200,000台以上。
小型机的市场占有率非常高，如果云平台要进入金融、政府等行业的市场，就必须把小型机“融入”到自己的系统当中。
云平台要做到支持小型机，那么首先该平台要支持小型机的虚拟化。
这也是云计算各厂商主要的重要竞争点。
本文将谈谈华三通信的云平台如何做到支持小型机虚拟化。
2.2.1IBMPower小型机虚拟化技术介绍
PowerVM是在基于IBMPOWER处理器的硬件平台上提供的虚拟化技术家族，为IBMPower小型机提供了行业领先的虚拟化解决方案。
借助IBMPowerVM虚拟化解决方案，企业可以整合大量的应用程序和服务器、充分虚拟化系统资源，从而提供一个更具灵活性的动态IT基础架构。
PowerVM虚拟化实现架构如图1所示。
图1PowerVM虚拟化架构
图2VMware架构
从图1可以看出，PowerVM虚拟化核心是固件级别，IO虚拟化由专用的VIOS（虚拟I/O服务器）分区（即虚拟机）提供。
而如图2所示VMware虚拟化是建立在操作系统之上的，IO虚拟化也是由操作系统提供。
由于其核心技术内建于系统固件之中，PowerVM提供了一个高度安全的虚拟化平台，该平台已获得了通用标准评估与验证体系（CCEVS）EAL4+安全认证。
2.2.2H3Cloud云平台支持Power小型机虚拟化
H3Cloud云平台是一套基于OpenStack、面向业务的私有云操作与管理系统，提供了租户管理、认证鉴权、计算、网络、存储等私有云服务与管理功能。
目前H3Cloud云平台已经支持Xen、KVM、VMwareESXi、CAS等虚拟化技术。
鉴于IBMPower小型机在金融、电信等领域的广泛应用和PowerVM在虚拟化方面的优势。
H3Cloud云平台支持PowerVM虚拟化势在必行。
Power小型机虚拟化管理网络架构
Power小型机管理系统网络总体架构如下图所示：
服务网络
管理网络
数据网络
图3Power小型机管理系统网络总体架构
和H3Cloud管理其它虚拟化厂商产品的组网方案相同，Power小型机管理系统中也存在3种类型的网络：
服务网络、管理网络和数据网络。
服务网络：
主要为云环境提供服务。
PCenter连接在本网络里以便能够访问H3Cloud云平台；而H3Cloud云平台为了能够访问PCenter和为Power小型机的微分区提供image镜像文件，需要连接到本服务网络；Power小型机作为客户端需要能够访问H3Cloud云平台的镜像文件服务器以便下载镜像文件，因此也需要连接在本网络中。
管理网络：
本网络主要为PCenter能够访问HMC（HardwareManagementConsole）以便管理Power小型机使用。
主要作用是能够通过HMC获取管理的Power小型机的各种信息，并且能够访问Power小型机的VIOS以便配置微分区。
数据网络：
主要为部署的微分区的应用程序之间交换数据使用。
Power小型机虚拟化支持概述
H3Cloud平台对Power小型机虚拟化支持功能模块如下图所示：
图4H3Cloud云平台对Power小型机虚拟化支持模型
如图4所示，在整个模型中，PCenter驱动是H3Cloud云平台与PCenter服务程序联系的纽带，H3Cloud平台通过它与PCenter服务程序的RESTAPI接口进行通信，获取PCenter服务程序管理的Power小型机的信息，比如Power小型机的电源状态和CPU个数、内存大小、硬盘大小、网络连接等硬件信息。
RESTAPI接口是PCenter服务程序对外提供的标准访问接口，外部程序或者客户端需要通过RESTAPI与PCenter服务程序通信。
PCenter服务程序是整个Power小型机管理系统的核心，它基于客户机／服务器模型，通过HMC来对Power小型机进行管理和获取小型机资源信息，并且能够支持在Power小型机上进行微分区和微分区硬件设备（比如SCSI客户端、虚拟以太网卡）的创建、删除、查询等操作。
PCenter服务程序同时能够直接与Power小型机的VIOS通信，对Power小型机微分区的硬盘和网络进行创建和管理。
Pcenter服务程序能够依据收集到的所管理Power小型机的各种硬件信息，将H3Cloud平台的虚拟机创建请求信息自动调度到合适的Power小型机上进行虚拟机的生命期管理。
HMC专门负责管理Power小型机，Pcenter服务程序正是通过HMC对Power小型机进行管理控制。
VIOS是Power小型机上专门负责I/O管理的特殊分区，一般来说，它占有所有的I/O硬件资源比如硬盘控制器、物理网卡设备等，并基于这些物理设备来为在Power小型机上创建的微分区提供虚拟I/O服务。
而微分区将作为客户端使用VIO服务器提供的服务。
2.2.3示例
下面以创建PowerVM云主机为例来演示用户需求在H3Cloud云平台上实现。
配置PowerVM实例
用户在H3Cloud云平台上单击“创建新主机”链接，然后按照提示，选择
用于创建新主机的镜像、规格和网络，在“基本配置”tab页输入新主机的名称等信息后，单击“确定”按钮，开始创建主机。
如图5和6所示。
图5PowerVM实例配置详情界面
图6PowerVM实例创建完成界面
通过SSH远程登录PowerVM实例
主机创建成功后，可以通过SSH客户端工具远程登录该主机。
如图7所示。
图7远程登录云主机界面
云计算本身不提供虚拟化技术，它需要借助于各种主流的虚拟化方案并和其进行交互，来实现云主机的创建和管理。
H3Cloud云平台支持Power小型机虚拟化后，借助H3Cloud云平台强大的私有云服务与管理能力，必将给使用Power小型机的金融、政府等行业用户带来全新的体验。
2.3物理服务器计算资源池设计
在云数据中心中，物理主机作为云计算资源重要的单元，对于高IO要求和性能敏感型的应用是必不可少的。
H3CloudOS可以统一纳管裸设备，将服务器作为资源交付给最终用户。
最终用户在选择云主机时，可以根据云主机所负载的应用选择相对应规格的物理服务器、适用的OS等参数。
H3CloudOS可以实现对物理主机实现类似于普通虚机生命周期管理里涵盖的功能，将物理服务器纳入整个云计算数据中心的计算资源池统一管理。
2.4网络资源池设计
2.4.1网络虚拟化
内、外网资源池网络资源均采用两台核心交换机、两台接入交换机组成，全网由万兆光纤互联。
云计算中大量采用和部署的虚拟化几乎成为一个基本的技术模式，部署虚拟机需要在网络中无限制地迁移到目的物理位置，虚机增长的快速性以及虚机迁移成为一个常态性业务。
这些动态工作负载的连接要求网络具备资源化能力，而传统网络已经不能满足需求。
传统网络技术面临以下三个问题：
1）虚拟机迁移范围受到网络架构限制
虚拟机迁移的网络属性要求，当其从一个物理机上迁移到另一个物理机上，虚拟机需要不间断业务，因而需要其IP地址、MAC地址等参数维持不变，如此则要求业务网络是一个二层网络，且要求网络本身具备多路径多链路的冗余和可靠性。
传统的网络生成树（STP，SpaningTreeProtocol）技术不仅部署繁琐，且协议复杂，网络规模不宜过大，限制了虚拟化的网络扩展性。
基于各厂家私有的IRF/vPC等设备级的（网络N:
1）虚拟化技术，虽然可以简化拓扑、具备高可靠性，但是对于网络有强制的拓扑形状，在网络的规模和灵活性上有所欠缺，只适合小规模网络构建，且一般适用于数据中心内部网络。
而为了大规模网络扩展的TRILL/SPB/FabricPath/VPLS等技术，虽然解决了上述技术的不足，但对网络有特殊要求，即网络中的设备均要软硬件升级，而支持此类新技术会带来部署成本的大幅度上升。
2）虚拟机规模受网络规格限制
在大二层网络环境下，数据流均需要通过明确的网络寻址以保证准确到达目的地，因此网络设备的二层地址表项大小（即MAC地址表），成为决定了云计算环境下虚拟机的规模上限，并且因为表项并非百分之百的有效性，使得可用的虚机数量进一步降低。
特别是对于低成本的接入设备而言，因其表项一般规格较小，限制了整个云计算数据中心的虚拟机数量，但如果其地址表项设计为与核心或网关设备在同一档次，则会提升网络建设成本。
虽然核心或网关设备的MAC与ARP规格会随着虚拟机增长也面临挑战，但对于此层次设备能力而言，大规格是不可避免的业务支撑要求。
减小接入设备规格压力的做法可以是分离网关能力，如采用多个网关来分担虚机的终结和承载，但如此也会带来成本的巨幅上升。
3）网络隔离/分离能力限制
当前的主流网络隔离技术为VLAN（或VPN），在大规模虚拟化环境部署会有两大限制：
一是VLAN数量在标准定义中只有12个比特单位，即可用的数量为4K，这样的数量级对于公有云或大型虚拟化云计算应用而言微不足道，其网络隔离与分离要求轻而易举会突破4K；二是VLAN技术当前为静态配置型技术（只有EVB/VEPA的802.1Qbg技术可以在接入层动态部署VLAN，但也主要是在交换机接主机的端口为常规部署，上行口依然为所有VLAN配置通过），这样使得整个数据中心的网络几乎为所有VLAN被允许通过（核心设备更是如此），导致任何一个VLAN的未知目的广播数据会在整网泛滥，无节制消耗网络交换能力与带宽。
上述的三大挑战，完全依赖于物理网络设备本身的技术改良，目前看来并不能完全解决大规模云计算环境下的问题，一定程度上还需要更大范围的技术革新来消除这些限制，以满足云计算虚拟化的网络能力需求。
在此驱动力基础上，逐步演化出Overlay网络技术的SDNVPC数据中心方案。
2.4.1.1Overlay介绍
Overlay基础概念
Overlay在网络技术领域，是一种网络架构上叠加的虚拟化技术模式，其大体框架是对基础网络不进行大规模修改的条件下，实现应用在网络上的承载，并能与其
升级会员 