2.2 云计算架构关键技术
相对于云计算初期阶段以探索和试用为特征的非互联网领域及行业的基础设施云资源池建设，新阶段云计算基础设施云化已步入大规建设，新阶段云计算基础设施化已步入大规模集中化建设的阶段，需要云操作系统（Cloud OS）必须具备对多地多数据中心内异构多厂家的计算、存储以及网络资源的全面整合能力，因此有如下一些关键技术和算法。
2.2.1 超大规模资源调度算法
我们说希望能像用水用电一样的方式去使用IT资源，那么IT资源的供给就需要许多类似于大大小小的水厂/电厂的IT资源工厂，这就是我们所说的IT数据中心。
以水厂为例，其实我们有各种大小的水库，有时候为了供给一个大城市，我们会通过复杂的管道，将某些江河或某些水库引入城市边上的大水库。就是说，这个供水系统是一个复杂的网络系统，需要有良好的预先设计。
可以看到，尽管我们家家户户使用的自来水没有什么差别，但实际上他们是来自于不同的水厂。每个水厂都可能遇到自己的枯水期，使用这些水厂水资源的客户可能面临缺水的问题，就是说，水的供应并不是无限制的。对应地，其实我们需要的IT资源也并不是无限制供给的，它是由后面大大小小的IT数据中心的能力决定的。当然，为了应对一些大企业的IT资源要求，我们需要将异地的IT数据中心进行联网设计，组成一个大的IT资源池来给大客户使用；此时，这个大资源池的组成技术、调度技术都是关键技术，包括以下三个方面。
一、计算资源调度算法
超大规模资源调度算法实现十万物理机、百万虚拟机的多级、分层调度。
在一个分布式的数据中心情况下，计算虚拟化部分负责L2～L5调度，以虚拟机（含OS及应用软件/中间件）为基本调度单元，完成指定虚拟机实例或者虚拟机集群到整个云数据中心计算资源池内最合适的物理机或者物理机集群的映射（见图2-9）。
图2-9 超大规模数据中心调度
初始分配调度及动态规划
典型的调度算法：首次匹配、负载均衡、轮转指针等，可统一规划为运筹学的线性规划NP求最优解/次优解的问题，约束条件及目标函数均可按需进行策略配置。
资源弹性分配的问题域
资源弹性分配的限定条件有下面6个表达式，如图2-10所示。
图2-10 资源弹性分配
其中各变量的含义如下。
i=1, …, N，表示服务请求数量。
h=1, …, H，表示每个集群中同质物理服务器的数量。
j=1, …, d，表示每个服务器提供的资源类型数量（例如CPU、RAM、带宽等）。
Rij表示第i个服务请求对资源类型j的资源需求量，这个值在0和1之间，表示资源的满足程度。
δij表示Rij是否为固定资源请求类型，取值0或者1。如果Rij是固定资源请求（比如每个用户邮箱服务固定需要内存10G），则δij=1；如果Rij是弹性资源请求（比如每个用户邮箱服务需要的内存可以在0～10G之间），则δij=0。
，表示服务i的最小产出要求，取值在0和1之间。例如某个大型企业需要从云中获得邮箱服务1000个用户，并且客户要求无论如何，最差的情况下也需要保证服务200个用户，则此时取值0.2。
eih表示资源请求i是否分配在物理服务器h上，取值0或者1。如果是，则取值1，否则取值0。
yih表示服务i在服务器h上是否进行Scale方式的输出。如果服务i不在这个服务器上，则取值必须是0。
各个限定表达式的含义具体如下。
表达式（1）：表示服务请求i分配在物理服务器h上的状态，或者在，或者不在。
表达式（2）：表示无论某个服务器是否承载了服务请求i，所有服务器上满足服务请求i的总和肯定等于1。
表达式（3）：表示一个服务i可以在某个服务器h上得到部分运行资源的满足，这个满足程度肯定大于等于0，如果大于0而小于1，表示服务器i需要的资源是分配在多个服务器上的，此服务器只能满足部分资源需求；如果等于1，表示此服务此时无须进行Scale，它完全能在h服务器上得到全部的资源满足。
表达式（4）：表示一个服务在相关的服务器上能取得的产出必须大于它的最小产出需求。例如客户要求云系统满足最低200个邮箱用户的需求，而系统中有10万台服务器，不管此时有多少台服务器给这个企业客户提供邮箱服务，都必须保证200个邮箱用户的使用。
表达式（5）：表示资源类型j在服务器h上能分配各种服务使用的最大值是1。
表达式（6）：表示最小的服务产出Y不会大于任何服务的产出。
资源弹性分配的近似最优解有如下公式：
其中NZ表示不等于0的物理资源集合。
整个系统的求解就是获得Y值的最大值。一般来说，我们可以采用如下的条件来获得最优解：
二、存储资源调度算法
存储资源的调度算法主要实现以下几点（见图2-11）。
图2-11 异构大存储池
将数据中心服务器（机架式服务器）直连存储（HDD/SSD）转换为高性能、低时延的共享存储资源，大幅提升可用存储空间，实现无SAN化的计算集群的虚拟化整合。
性能无损的瘦分配、为每VM/PM提供更大的“瘦分配弹性” ：为不具备“瘦分配”能力的服务器内置DAS/SSD，以及外置SAN带来天然瘦分配能力，并解决多数外置SAN存储瘦分配带来的性能下降开销问题。
更大规模的跨SAN资源池，基于在线分布式去重实现更大范围的重复数据识别与删除（文件级/对象级/块级），将资源利用率进一步提升40%。
更大规模的资源池，意味着可有更多共享空闲资源满足计算侧需求，避免独立SAN/NAS各自数据不均衡带来的资源浪费（30%）。
超大资源池下，将“跨SAN”数据热迁移的概率几乎降低为零。
物理机无Hypervisor，也需要引入“存储融合”层来解决数据的跨SAN热迁移能力（存储大资源池内的）。
三、能耗管理最优化算法
要降低PUE值，实现云计算绿色节能的理念，需要有一个好的能耗管理算法。能耗管理算法在云计算中是一个关键技术（见图2-12）。
图2-12 能耗管理功能模块图
计算部分是数据中心L1+L2功耗的主要矛盾和关键路径（60%～70%）；
数据中心内，基于“轻载合并”原则进行VM热迁移调度，使得更多的空闲服务器可以下电或处于节能运行态；
计算虚拟化部分与数据中心L1管理软件联动，尽量减少局部热点，从而允许L1管理软件控制空调提升平均工作温度，达到提升PUE效率的目的；
持续动态采集当前负载情况下服务器、UPS和空调、制冷设备的功耗及温度数据，得出PUE指标，并在管理界面上实时呈现。
处理过程具体如下。
1．输入信息
（1）物理机信息列表
静态规格：CPU主频和数量、内存大小、网卡速率。
负载信息：CPU利用率、内存利用率、网络I/O。
状态：上电、下电、异常状态。
功率信息（可选）：额定功耗、当前功率。
温度信息（可选）：当前CPU温度、物理机温度。
其他（可选）：物理机能耗效率评级、离冷风送风口距离或评级。
（2）虚拟机信息列表
静态规格：虚拟机CPU（vCPU数量和主频）、内存大小、网卡速率。
负载信息：CPU占用、内存占用、网络I/O。
约束信息：互斥性约束、亲和性约束。
物理机和虚拟机的关联关系。
物理机对应的VM ID列表。
（3）两个场景
轻载时，合并VM，物理机下电节能。
重载时，启动物理机，均衡VM，保证QoS。
（4）三个子算法
轻载/重载检测算法。
上下电PM选择子算法。
负载均衡子算法。
（5）算法设计时要考虑的问题
多维资源问题。
迁移成本-收益分析。
迁移震荡问题。
What-if测试。
配电问题。
温度问题。
调度约束。
2．输出信息
其主要有两种动作，即物理机上下电动作、VM迁移动作。
2.2.2 异构硬件集成管理能力
一、异构硬件管理集成技术
1．异构的内容
异构的内容包括以下几点。
业务运行平面上，虚拟化引擎层（Hypervisor）天然实现了硬件异构：例如通过XEN及KVM虚拟化引擎的硬件指令仿真，并引入必要的半虚拟化驱动，则可对上层客户机操作系统完全屏蔽多数厂家x86服务器的差异。
管理维护平面上，云OAM维护管理软件通过采用灵活的插件机制对各类异构硬件通过有代理以及无代理模式的模式，从各类服务器硬件管理总线、以及操作系统内的Agent，甚至异构硬件自带的管理系统中收集，并适配到统一建模的CIM信息模型中来。
虚拟机、物理机统一建模：x86服务器虚拟机、物理机，以及ARM物理机的异构集群管理。
2．异构实现原理
异构实现原理如图2-13所示。
图2-13 硬件异构兼容原理
二、异构Hypervisor简化管理集成技术
针对数据中心场景，企业IT系统中的Hypervisor选择往往不是唯一的，可能有VMware的ESX主机及vSphere集群，可能有Microsoft的Hyper-V及SystemCenter集群，也可能有从开源KVM/XEN衍生的Hypervisor（如华为UVP等）多种选择并存。此时云操作系统是否有能力对这些异构Hypervisor加以统一调度管理呢？答案是肯定的。可以依托OpenStack开源框架，通过Plug-in及Driver等扩展机制，将业界所有主流的Hypervisor主机或者主机集群管理接口统一适配到OpenStack的信息模型中来，并提供V2V/P2V虚拟机镜像的转换工具，在异构Hypervisor之间按需进行虚拟机镜像转换。这样即使不同Hypervisor也可共存于同一集群，共享相同存储及网络服务，甚至HA服务。
资源以统一集群方式管理（OpenStack目标），屏蔽Hypervisor差异，简化云计算资源管理（见图2-14）。
图2-14 Hypervisor异构统一管理原理
三、异构存储管理集成的统一简化技术
异构存储管理继承的统一简化技术主要包括如下几点（见图2-15）。
图2-15 存储异构统一管理原理
10PB级存储大资源池，跨多厂家异构外置存储，以及服务器自带SSD/HDD的资源池化，将存储服务抽象为同时适用于虚拟机和物理机的“统一EBS”服务；
容量、IOPS、MBPS等SLA/QoS是EBS存储服务界面的“统一语言”，与具体支撑该服务的存储形态及厂家无关；
可按需将部分存储高级功能（数据冗余保护、置0操作、内部LUN拷贝、链接克隆等卸载到外置存储（类VVOL）；
针对DAS存储融合，应用层逻辑卷与存储LUN之间采用DHT分布式打散映射，以及一致的RAID保护；
针对SAN存储融合，应用层逻辑卷与存储LUN之间采用DHT分布式打散映射（新建卷），或者直接映射（利旧并平滑迁移已有卷），据可靠性一般由SAN存储自身负责；
同一应用Volume的直接映射卷可“逐步”平滑迁移到DHT映射卷，实现业务中断。
2.2.3 应用无关的可靠性保障技术
一、数据中心内的可靠性保障技术
数据中心内的可靠性保障技术主要包括HA（High Availability）冷备份、FT（Fault Tolerance）热备份、轻量级FT。
1. HA（High Availability）冷备份
数据中心内基于共享存储的冷迁移，在由于软件或硬件原因引发主用VM/PM故障的情况下，触发应用在备用服务器上启动。其适用于不要求业务零中断或无状态应用的可靠性保障（见图2-16）。
图2-16 冷备份原理
2. FT（Fault Tolerance）热备份
其指指令、内存、所有状态数据同步。该方式的优势是状态完全同步，完全保证一致性，且支持SMP。劣势是性能开销大，会带来40%左右的性能降低（见图2-17）。
图2-17 热备份原理
3．轻量级FT
其是基于I/O同步的FT热备机制。优势是CPU/网络性能损耗10%以内，支持单核和多核。劣势是适合于网络I/O为主服务的场景（见图2-18）。
图2-18 轻量级FT原理
二、跨数据中心的可靠性保障技术
跨数据中心的可靠性保障技术，主要是基于存储虚拟化层I/O复制的同步和异步容灾两种。
基于存储虚拟化层I/O复制的同步容灾，采用生产和容灾中心同城（＜100KM）部署，时延小于5ms, DC间带宽充裕，并且对RPO（恢复点目标）要求较高，一般RPO接近或者等于0秒。分布式块存储提供更高效的I/O同步复制效率（见图2-19）。
图2-19 基于应用层的容灾复制原理
基于存储虚拟化层I/O复制的异步容灾采用生产和容灾中心异地（大于100KM）部署，带宽受限，时延大于5ms，同时对RPO有一定的容忍度，如RPO大于5分钟。I/O复制及快照对性能的影响趋近于零（见图2-20）。
图2-20 基于存储层的容灾复制原理
2.2.4 单VM及多VM的弹性伸缩技术
单VM及多VM的弹性伸缩技术包括基本资源部件级别、虚拟机级别、云系统级别三个层次的伸缩技术。
基本资源部件级别：精细化的Hypervisor资源调度，对指定虚拟机实例的CPU、内存及存储规格进行弹性伸缩，并可对伸缩上下限进行配额限制。
虚拟机级别：指虚拟机集群的自动扩展与收缩，基于CloudWatch机制对集群资源忙闲程度的监控，对业务集群进行集群伸缩与扩展的Auto-Scaling控制。
云系统级别：在内部私有云资源不足的情况下，自动向外部公有云或其他私有云（计算及存储资源池）“租借”及“释放”资源。
上述弹性伸缩机制，使得在大规模共享资源池前提下，流控及因流控引发的业务损失被完全规避（见图2-21）。
图2-21 弹性伸缩
2.2.5 计算近端I/O性能加速技术
原则上，针对在线处理应用，I/O加速应发生在最靠近计算的位置上，因此作为提高I/O性能的分布式Cache应该运行在计算侧（见图2-22）：
图2-22 存储缓存加速功能
远端Cache的I/O效率，高出本地IOPS/MBPS效率1个数量级；
通过分布式内存、SSD Cache，实现对内部和外部HDD硬盘介质资源的I/O性能提升2～3倍；
NVDIMM/NVRAM和SSD Cache保证在全局掉电（或多于2个节点故障情况下）情况下计算近端的写Cache数据无丢失；
分布式Cache可提供更大的单VM（单应用）的磁盘并发MBPS，效率可提升3～5倍。
2.2.6 网络虚拟化技术
一、业务应用驱动的边缘虚拟网络自动化
分散在交换机、防火墙、路由器的L2转发表及L3路由表集中到SDN控制器，使得跨多节点的集中拓扑管控及快速重定义成为可能。基于x86的软件交换机和VxLAN隧道封装的Overlay叠加网可以实现业务驱动且与物理网络彻底解耦的逻辑网络自动化，支持跨数据中心的大二层组网。基于业务模板驱动网络自动化配置，如图2-23所示。
图2-23 网络功能虚拟化层次架构
二、更强大、更灵活的网络安全智能策略
在云计算早期阶段，一般采用下面的方法进行网络安全的部署，但存在一些不足。
公有云、多租户共享子网场景下，静态配置安全组规则仅在目的端进行过滤，无法规避DOS攻击（见图2-24）。
图2-24 虚拟机网络安全原理
采用外置防火墙方法控制子网间安全，但存在流量迂回（见图2-25）。
图2-25 采用外置防火墙方法控制子网间安全
为解决云计算早期阶段技术安全隐患，新阶段云计算架构通过软件定义网络的实施，解决这些问题（见图2-26）。
图2-26 通过软件定义网络的实施解决问题
按业务需求统一定义任意目标——源组合的安全策略定义下发到Controller；
子网内互访，首包上送Controller，动态下发安全过滤规则，源头扼杀攻击；
子网间互访，动态下发快转流表，避免迂回。
2.2.7 应用模块以及工作流技术
对于目标架构的基础设施层的管理功能定位，仅仅做好物理和虚拟机资源的调度是远远不够的，其应当涵盖独立于具体业务应用逻辑的普遍适用的弹性基础设施之上的应用的全生命周期管理功能，涵盖从应用模板、应用资源部署、配置变更、业务应用上线运行之后基于应用资源占用监控的动态弹性伸缩、故障自愈以及应用销毁的功能。整个应用的生命周期管理应遵循如图2-27所示的流程。
图2-27 全生命周期管理流程
各部分包括以下内容。
（1）图形化的应用模板设计方式：采用基于图形的可嵌套式重用模板；采用拖拽和粘贴拷贝式的方式来定义分布式应用模板；使得模板设计简单高效（见图2-28、图2-29）。
图2-28 图形化的应用模板
图2-29 图形化的应用模板设计
（2）提前准备的丰富模板库和自动部署：为物理机、容灾、SDN、LB、防火墙等准备好应用模板；当有应用需求时，系统直接从模板库中选取相应的模板进行自动部署（见图2-30）。
图2-30 从模板库中选取相应的模板
（3）基于SLA的应用监控：面向不同的应用（数据库、HPC、基于LAMP的Web网站等），定义不同的SLA指标集，对这些指标进行监控，采用静态阈值和动态基线相结合的方法进行故障告警和性能预警，使应用监控更自动化和精细化，满足客户业务运行的要求。
（4）基于工作流的应用故障自愈：采用基于工作流的管理方式，通过对应的设计工具来设计用户自定义事件，当监控到应用故障、事件触发和工作流引擎的运转时，系统支持应用的自动修复，达到故障自愈的目的。
2.2.8 容器调度与编排机制
Docker 2013年发布正式开源版本后，容器技术成为云计算领域一个新的热点。进入容器的世界后，你会发现Docker生态系统十分庞大，Docker公司发布的容器引擎只是单节点上管理容器的守护进程，而企业数据中心或者公有云管理的节点规模十分庞大，因而一个成熟的容器管理平台还需要至少下述两个层面的能力（见图2-31）。
图2-31 容器调度与编排机制
1．容器集群资源管理和调度
收集被管理节点的资源状态，完成数以万计规模的节点的资源管理；同时根据特定的调度策略和算法，处理用户的容器资源申请请求。
2．应用编排和管理
针对数据中心不同类型的应用，比如Web服务，批量任务处理等，抽象不同类型应用常用的应用管理的基础能力，并通过API暴露给用户使用，从而用户开发和部署应用时可以利用容器管理平台的上述API能力实现对应用的自动化管理。用户通过应用编排和管理还可以实现应用模版定义，以及一键式自动化部署。应用模版包括组成应用的各个组件的定义，以及组件间逻辑关系定义，用户可以从应用模版一键部署应用，实现应用灰度升级等，大大简化了应用的管理和部署。
本书第五章对容器调度和编排机制进行了详细的阐述。
2.2.9 混合云适配连接机制
越来越多的企业使用混合云，将公有云资源作为企业侧的私有云的延伸进行统一管理。混合云适配连接机制需要提供的功能包括：
统一对象模型；
统一北向API；
云间网络互联互通。
典型的混合云架构，如图2-32所示。
图2-32 混合云架构
典型的混合云架构，分为如下三层。
1. Cloud Gateway
Cloud Gateway部署在最底层，对接异构云的资源管理服务。以AWS为例，Cloud Gateway对接适配AWS的弹性计算服务（EC2）、弹性块存储服务（EBS）和虚拟网络服务（VPC），用于异构云对象模型的转换和API适配，屏蔽云间功能差异性。
2. Cloud Broker
Cloud Broker提供加云管理、加云配置（用于接入供应者云进行发放资源的账号、密码、Flavor映射关联等云配置）、统一租户管理、云间资源管理和云间互联互通功能。Cloud Broker通过Cloud Gateway将供应者云作为计算、存储资源池使用，在此之上提供统一的租户管理，实现云间资源的统一管理和资源跨云统一编排，对外提供统一的API接口；Cloud Broker通过Cloud Gateway使用VPN隧道或者云间专线互联的方式实现跨云网络的互联互通。
3. Cloud Market
Cloud Market在Cloud Broker提供的云间资源统一管理和云间网络互联互通的功能基础之上，通过调用Cloud Broker北向统一的云管理API实现服务的跨云统一部署和编排。