点击查看第一章
点击查看第三章

第2章

企业云计算涉及的技术选型和管理
在以AWS、Google、阿里等为代表的公有云发展的同时，很多大型企业出于数据安全性、系统稳定性、软硬件自主权、对自主可控以及TCO（Total Cost of Ownership，总体拥有成本）低的考虑，更加倾向于建设企业私有云来承载内部业务信息系统的运行。

2.1　企业私有云建设需求分析

在建设企业私有云之前，首先需要回答和解决的问题是企业是否真的需要私有云，以及需要什么样的私有云?企业私有云的建设是一个长期的系统工程，初始成本的投入也较为高昂。因此企业在建设私有云之前，应从以下几方面对需求和现状进行评估。
1.需求和资源使用特点
例如，某大型企业的IT系统现状：
□系统利用率低：烟囱式的系统建设部署方式导致系统资源无法共享，系统负载不均衡，整体资源利用率和能耗效率低。
□建设扩容成本高：IT系统中原有的UNIX服务器、数据库和存储阵列占比较高，标准化程度低，通用性差，导致建设扩容成本难以控制，给系统统一维护带来困难。
□扩展能力有限：系统的scale-up和scale-out能力不足，难以应对越来越大的系统处理和存储压力。
那么针对以上现状，如何通过云计算来改变呢?首先我们需要的是：
□动态部署架构：构建基于标准化硬件设备和虚拟化架构之上的云计算基础设施资源池，可对上层应用按需提供弹性资源，实现多系统有效共享，有效提高IT系统资源利用率和能耗效率。
□标准硬件单元：云计算采用标准的运算和存储处理单元，有效降低系统建设和扩容成本。
□高可扩展性：云计算硬件集群技术和软件并行处理能力能够提供出色的scale-out能力，几乎无限扩展IT系统的处理和存储能力。
通过引入云计算技术可改变传统信息系统竖井式的建设模式，通过底层资源的共享与灵活调度可提升资源利用率，降低整体信息系统建设成本，缩短信息系统的建设周期。这些实现都是以资源使用特点为前提的。如果一个信息系统本身无资源调度需求（如资源使用曲线较为平稳），或计划由云计算承载的信息系统整体资源规模较小，资源共享和调度的空间有限，又或者特定的应用系统不支持分布式部署，无法进行横向扩展甚至纵向扩展，对于此类信息系统建设，则无法充分利用云计算的优势。因此对本企业的需求和现状进行合理评估是非常必要的。
2.信息系统的标准化程度
在云计算环境中，信息系统所具有的标准化程度往往是决定私有云形态的重要因素。对信息系统的标准化评估存在多个维度，包括基础架构环境标准化（例如所需支撑的硬件是专用硬件还是通用硬件）、平台环境标准化（例如对于开发环境、中间件环境以及数据库环境的通用需求和租户限制），以及应用系统的标准化（例如应用系统的运行环境是否一致、配置参数是否标准化、分布式环境下数据的一致性等）。不同维度的标准化实现决定了企业私有云应该建设为IaaS云、PaaS云抑或是SaaS云。
□云化建设/迁移的难度
将新的应用系统直接部署在云计算环境中或将原有系统迁移到云计算环境中是两种主要信息系统的云化改造路径，对其实现难度的评估是对应用系统进行云化改造风险与收益评估的重要手段。整个业务系统的云化分析过程需要从包括硬件支撑环境改造、操作系统平台变更、平台软件绑定分析、IP地址依赖性消除、API重构、模块化改造、标准化改造、外部依赖条件等在内的多个层面和维度进行，准确评估业务信息系统云化改造的相关难点与痛点，才能对信息系统云化改造有充分的认识和准备。
□关于成本的评估与考虑
大型企业建设私有云往往会考虑定制化和一些业务特定的需求，其标准化程度往往低于公有云，由此所带来的自动化、运维、管理开销会更高。最后，在传统企业环境培养大量开发人才的要求也更高，工作技能、职能的转变同样需要成本的投入。

2.2　企业私有云技术路线选择

在大型企业建设私有云时，一个重要的问题就是技术路线的选择和成本价值产出。一般在进行私有云技术路线选择时，大型企业往往会把稳定性、成熟度、服务满意达成度放在首位，那么成熟稳定的商业解决方案就会被优先考虑，而开源的往往因为技术不够成熟和稳定，因此不被优先考虑。下面拿VMware和OpenStack来做比较。
1.从产品设计上看
VMware软件套件是自底向上的架构，下端边界为虚拟机管理器。VMware的vSphere和vCloud director产品都依赖于ESXi虚拟机管理器。由于VMware产品架构的健壮性，很多高规格用户在多数据中心规模的环境中都会使用该产品。但是VMware的软件系统是封闭的，并且软件的发展路线完全遵循VMware自己的发展目标，用户或消费者在此方面没有任何控制权。而OpenStack作为一个开源系统，没有任何一家单独的公司控制着OpenStack的发展路线。另外很多大公司都在支持OpenStack的发展，基于如此多公司的资源投入，OpenStack的发展是多元化的。然而这也带来了问题，即OpenStack部署和架构的实施和维护成本较VMware有了陡然提高，与此同时，相对快速的版本更新速度导致技术支持文档无法跟上产品的脚步。
2.从高可用和容错、资源平衡功能上看
在vSphere中，虚拟机级别的高可用性体现于允许在虚拟机或者ESXi主机出错时，在不同宿主机部署相同的虚拟机。高可用性即在硬件出问题时保证虚拟机的正常工作，当然如果真的出错了，则只能在不同的ESXi主机上启动虚拟机，这也可能造成服务的中断。FT（容错）的主要功能就是保证在出现故障时用户的应用不会出现中断。其原理就是在两台主机上创建一模一样的两台虚拟机—VM（主）与VM（辅助），VM（辅助）完全同步VM（主）的操作，当VM（主）发生故障时，VM（辅助）自动切换为VM（主）。FT可使应用程序实现零停机、零数据丢失，同时消除了传统硬件或软件集群解决方案的成本和复杂性。另外VMware vSphere的分布式资源调度（DRS）可以聚合集群中ESXi主机资源，通过监控利用率，自动分配这些资源给虚拟机，并能够跨ESXi主机不断进行虚拟机资源优化和平衡。
我们再看一下OpenStack的高可用性。目前并没有官方声明OpenStack支持虚拟机级别的高可用性，这个特性在Folsom版本被提出，但是后续又被放弃了。目前OpenStack有一个孵化项目Evacuate，其作用是为OpenStack提供虚拟机级别高可用支持。再看OpenStack 的容错。在OpenStack中没有针对容错的功能，并且截至目前也没有计划完成这些功能。OpenStack也还没有良好的资源自动平衡机制，截至目前OpenStack并未提供DRS功能，这属于OpenStack功能缺失的一部分。我们可以看到，在功能支持和功能细节方面，OpenStack相较VMware还是有差距的，仍然需要不断进步才能做得更好。
3.从成本和价值上看
VMware是商业软件，其成熟度和稳定性经受住了大量实际环境的考验，但使用成本高，体现在其授权费用和服务费用上。相对VMware的昂贵价格，OpenStack免费、开放的优势还是很明显的。对于VMware高投入带来的功能，OpenStack大部分可以免费提供给客户。那么是OpenStack还是VMware更有价值？这个问题并没有很清晰的答案，并且答案也取决于企业实际部署的规模。虽然OpenStack是免费使用的，但是它需要有专业的开发人员和此领域的专家才行，并且需要完成很多架构和搭建方面的工作，因为它支持很多部署场景，并且安装过程都不尽相同。VMware则需要花费一些经费购买授权和服务，但相对来说更加容易安装和运行，另外VMware的学习成本更低一些。
总的来说，基于以上分析，大型企业使用VMware则更稳定和可靠。而OpenStack入门门槛较高，如果企业没有足够的技术能力储备则无法解决大面积部署OpenStack所遇到的问题。

2.3　计算资源管理

在企业IT基础设施云架构下，计算资源、存储资源、网络资源在统一的云平台管理下被封装整合成不同的资源池，以云服务的方式提供给服务使用者。
云计算在企业的落地涉及多个方面。除了资源池管理，还有监控管理、运维管理和云服务管理，只有相关方面联动起来，才能真正让云计算在企业落到实处、发挥价值。
下面我们通过VMware和OpenStack这两个比较常用的IaaS管理平台来看看它们在计算资源管理方面的具体技术和实现。

2.3.1　VMware

按照技术平台类型，计算资源池的组成可分为x86平台和非x86平台。非x86平台包含AIX小型机和HPUX等。在这里x86平台则可具体分为VMware虚拟化平台架构和x86物理服务器组成的数据集群类架构。
1.资源池的分区
在企业级IT基础设施环境中，为了保证风险可控以及业务安全性要求，从网络上划分了多个不同的安全区域。基础架构网络中，部署计算资源池一般有以下几个分区：
□业务生产区：运行企业各类线上生产系统。
□开发测试区：方便开发测试的各类业务测试系统。
□管理区：部署各类管理用服务器。
□物理区：部署各类数据库和不方便虚拟化的物理服务器。
□DMZ服务区：实现互联网接入及部分需要连接互联网的应用部署。
2.资源池部署规划
为了满足应用系统上线的需求，在相关区域中将选择不同标准的计算资源池以进行部署，部署区域和资源池类型的对应关系见表2-1。
3.部署单元（主机和集群）
具体来说，计算资源池（Resource Pool，RP）有两种，CPU资源池和内存资源池。

图2-1中一台EXSi主机有36GHz CPU资源和96GB可用内存资源，并且创建了两个资源池。其中OA系统获得1/3的资源，也就是12GHz CPU资源和32GB内存资源。HR系统获得剩下的2/3的资源。

一个集群（Cluster）的资源池包含集群中所有主机（Host）的资源总和。比如一个8主机的集群，每个主机都有32GHz CPU和64GB内存，那么这个集群的资源总和就是256GHz的CPU和512GB的内存。在这个集群中创建的资源池就从这个总的可用资源中分配。
集群的可用资源总是小于集群的总资源，这是因为每台主机都会占用一部分CPU和内存资源，以留给自己的Hypervisor和OS使用。
虽然集群资源池是所有主机资源的总和，但是并不意味着某一VM（虚拟机）可以使用超过某一台主机的资源。比如，两台32GB内存的主机组成集群，集群中创建了一个64GB内存的资源池，但是任何单台VM都不能使用超过32GB的内存，因为VM不能跨主机使用资源，即VM的可用资源受到单台主机物理资源上限的影响。
另外一种情况：如果考虑VM的SWAP的话，这台大于32GB内存的VM可以被创建，也可以被运行。虽然这台VM不能跨主机使用资源，也就是它最多可以使用32GB的内存，但是别忘记它还有SWAP，因此，20GB的SWAP保证了Guest OS的运行。
同VM一样，资源池也有份额（Shares）、预留（Reservation）和限制（Limit）这3个配置项，见图2-2与图2-3。

□限制
资源池的限制与VM的限制类似，不同的就是这个限制是资料池中所有VM可用物理资源的上限值。
虽然“限制”项不会限制VM的创建，但是它限定了可用物理资源，影响了资源池中运行的VM的性能。
□份额
资源池中的资源通常通过份额来分配，有3种预设的份额分配方式：High、Normal和Low，比重分别为4∶2∶1。反映在数字上则如表2-2所示。

比如说一个集群有5个资源池：1个High、2个Normal、2个Low。那么High资源池可以获得4/ （4+2×2+1×2） = 40%的资源，Normal资源池各可以获得20%，Low资源池各可以获得10%资源。
资源池下可以建子资源池。资源按份额的比例分配。
□预留
资源池的Reservation（预留）不是决定其中的VM能用多少CPU/内存资源，而是分配给VM的Reservation使用的。如果资源池的可用预留不够VM预留需要的量，VM将不能被启动，或者正在运行中的VM不能被移动到该资源池中。这种检查叫作准入控制（Admission Control）。
比如资源池中可用内存预留是1500MB。位于该资源池中的VM1和VM2的内存预留都是1024MB，当我们启动VM1时可以正常启动，但是再启动VM2时，剩下的可用内存预留只有476MB（小于1024MB），于是VM2无法启动，用户将收到“Insuff?icient Memory Resource”的报错。
资源池有两种类型：Fixed和Expandable。从图2-2和图2-3可以看出，CPU和内存资源都可以勾选“不受限制”（Expandable Reservation），默认是勾选的。如果手工去掉这个勾选，就可以更改为Fixed。
Fixed类型即其中的VM的Reservation只能使用自己的预留资源，而Expandable类型就是不仅可以使用自己的预留资源，而且当资源池中的可用预留资源不够VM使用的时候，可以使用父资源池中的。
VM开机时才会申请预留，关机时就把这部分预留还回资源池了。
RP（资源池）预留中的内存/CPU资源并非被这个RP独占，而其他RP无法使用。如果某一个RP预留中的内存没有被用完，则其他RP的VM还是可以使用这部分内存的。
例如，主机有3GB内存，在完全竞争下RP1获得1GB，RP2获得2GB。RP1设置了1GB的预留，但是其中没有VM。RP2中有且仅有一台VM并配置了2.5GB内存，运行一个消耗内存的程序，那么这个VM可以获得2.5GB的内存，其中0.5GB来自RP1，而无视其预留。
但是，增加某个RP的预留就减少了其他RP可以获得的预留。
开启一台VM所需要的物理内存，不仅与内存预留有关，也与内存开销有关。当可用内存预留小于开启一台VM的需求（等于内存预留和开销的总和）时，VM就无法启动。

2.3.2　OpenStack

OpenStack是一个能够管理整个数据中心大量资源池（包括计算、存储和网络资源等）的云操作系统。就计算资源来说，OpenStack可以规划并管理大量虚拟机，从而允许企业或服务提供商按需提供计算资源；开发者可以通过OpenStack API访问计算资源从而创建云应用，管理员与用户则可以通过Web访问这些资源。在OpenStack中，计算服务是OpenStack的核心服务，它由Nova项目提供实现。Nova项目不包括任何虚拟化软件；相反地，它通过各种插件与运行在主机上的底层虚拟化软件进行对接，然后再向外提供API。
Nova包括以下四个核心模块：
□Nova-api：向外提供OpenStack Compute API。
□Nova-conductor：数据库访问。
□Nova-scheduler：将通过API进来的虚拟机创建请求调度到某个主机上。
□Nova-compute：通过调用主机上Hypervisor的API创建和控制虚拟机。
1.主机管理
为了更好地管理云中的主机，OpenStack Nova引入了多个概念来对这些主机进行逻辑划分，这些概念包括域（Region）、可用域（Availability Zone，AZ）、主机聚合域（Host Aggregates Zone，HAZ）等。
OpenStack通过引入Region（域）的概念，支持全球化部署，比如为了降低网络延时，用户可以选择在特定的Region中部署服务。各个Region之间的计算资源、网络资源、存储资源都是独立的，但所有Region共享账户用户信息，因为Keystone是实现OpenStack租户用户管理和认证功能的组件，所以Keystone全局唯一，所有Region共享一个Keystone，Keystone端点中存储了访问各个Region的URL。
OpenStack引入了AZ的概念，其主要目的之一是基于可靠性考虑。AZ可以简单地理解为一组节点的集合。在实际操作中，我们可以将具有独立的电力供电设备的一组节点划分到一个AZ之中，比如将一个独立供电的机架划分为一个AZ。AZ由管理员创建，对用户可见，比如用户要运行某个有高可靠性要求的应用，那么他可以在两个不同的AZ之中分别创建一个虚拟机，然后在每个虚拟机中部署该应用，并使用负载均衡服务来连接这两个虚拟机中的应用以对外提供可靠的服务。
HAZ也是把一批具有共同属性的计算节点划分到同一个Zone中，HAZ可以对AZ进一步细分，一个AZ可以有多个HAZ，一个HAZ也可以跨多个AZ。同一个HAZ下的机器都具有某种共同的属性，比如高性能计算、高性能存储（SSD）、高性能网络（支持SR-IOV等）。HAZ和AZ的另一个不同之处在于HAZ对用户不是明确可见的，用户在创建虚拟机时不能像指定AZ一样直接指定HAZ，但是可以通过在Instance Flavor中设置相关属性，由Nova-scheduler根据调度策略调度到满足该属性的HAZ中。
这些概念组合起来，可以用图2-4来表示。

比方说，某用户有两个机房，分别位于北京和上海，分别有100台和200台物理服务器作为计算资源池，那么可以使用表2-3中的方法来对这些服务器进行划分。

2.资源池管理
如图2-5所示，Nova-scheduler服务通过运行在每个主机上的Nova-compute服务获取主机的信息并保存在集中式数据库中，形成一个虚拟计算资源池，这些信息会被及时更新。管理员可以在OpenStack Dashboard（Horizon）或者使用Nova API/CLI来查看资源池的情况。

如图2-6所示，在汇总（Hypervisor Summary）部分，管理员可以看到整个资源池中的资源总数，包括vCPU、内存和本地磁盘等，以及这些资源已经被使用的数目；在列表部分，可以看到每个主机的详细信息，包括类型、vCPU数目、内存总量和已使用量、本地磁盘空间总量和已使用量、虚拟机数目等。管理员还可以通过Nova CLI获取每一个Hypervisor在数据库中保存的详细信息。

3.资源池的使用
开发者、管理员和用户通过Nova API和CLI或者在OpenStack Horizon上进行操作来创建虚拟机，每个虚拟机都会占用一定的计算资源，而计算资源占用的多少则是通过Nova Flavor来实现的。Nova Flavor是所要创建的虚拟机的规格，其中就包含了该虚拟机所要求的vCPU、内存、本地磁盘等计算资源的数目。如图2-7所示。

4.资源的调度
当Nova-api服务接收到创建虚拟机的请求后，它会通过消息队列将请求转交给Nova-scheduler模块，后者会根据在数据库中保存的整个环境中计算资源池的情况，按照请求中所要申请的资源，选择一个最合适的主机来创建该虚拟机。
如图2-8所示，Nova-scheduler的调度包括两个子过程：
□过滤（filtering）：Nova根据管理员在配置文件中所配置的过滤器（filter），对云环境的所有主机进行逐一过滤，将满足所有过滤器要求的主机选出来。
□权重（weighting）：对上一步骤中所有满足要求的主机计算权重并以此排序从而得出一个最佳主机。计算主机权重的过程需要调用指定的各种Weigher Module以得到每个主机的权重值。
Nova中已经实现了很多过滤器，也支持用户自定义的过滤器。Nova默认使用如下过滤器：
□RetryFilter：过滤掉之前已经尝试调度过的主机。
□AvailabilityZoneFilter：过滤出在指定可用域中的主机。
□RamFilter：过滤出有足够内存（RAM）的主机。
□CoreFilter：过滤出有足够vCPU核的主机。
DiskFilter：过滤出有足够根磁盘和临时磁盘空间的主机。
□ComputeFilter：过滤出Nova-compute服务可用的主机。
□ComputeCapabilitiesFilter：过滤出满足Flavor中指定的特定要求的主机。
□ImagePropertiesFilter：过滤出满足虚拟机镜像特定要求的主机。

每个主机只有在满足所配置的所有过滤条件后，才能进入权重阶段。关于过滤器更详细的信息和可选的过滤器等内容，请参考OpenStack有关文档。
5.虚拟机管理
如图2-9所示，Nova-compute支持多种Hypervisor，通过使用不同的Hypervisor API来管理这些Hypervisor上的虚拟机。OpenStack通过Nova管理虚拟机，形成在云范围内的虚拟机资源池。

根据OpenStack社区2016年最新的一次用户调查结果，目前，在生产和开发测试环境中使用的Hypervisor情况如图2-10所示。

2.4　存储资源管理

下面我们通过VMware和OpenStack这两个比较常用的IaaS管理平台来看看它们在存储资源管理方面的具体技术和实现。

2.4.1　VMware

1.存储资源池设计
存储资源池通常包含两个部分：内部存储和外部存储。内部存储指的是服务器自带的存储介质。外部存储指的是服务器之外的存储设备，比如SAN、NAS等。一般服务器内部的存储介质容量有限，企业私有云数据中心主要使用的还是外部存储。
2.存储资源的选择
在企业级数据中心，虚拟化和云计算的大规模应用和深入对存储系统的一个最大挑战就是需要解决大规模虚拟机部署和业务上云所带来的存储压力和瓶颈。随着虚拟机数量的迅速增加，随机读取的陡增和写入I/O的爆发压力不可避免，这就必然提高了整个系统对于存储设备稳定性和I/O性能的要求。
虚拟化环境存在的典型性能问题包括性能瓶颈、混合负载的优化问题、激增流量性能问题等，下面进行具体描述。
□性能瓶颈
当主机对于存储访问的需求超过存储设备所能提供的性能时，就会出现性能瓶颈，这直接影响到主机上的应用性能。当将传统存储设备用于高度虚拟化环境、多个虚拟机的多个应用并行运行时，存储设备将难以提供充足的性能来满足实际运行要求。例如，一台服务器上可以部署10个虚拟机，但由于后端存储性能的限制，在实际业务过程中只能满足8个虚拟机的并行运行。
□混合负载的优化问题
虚拟化常常在混合负载环境下运行：有可能某一个虚拟机在传输大文件时，另一个虚拟机却在访问流媒体，而其他虚拟机则在运行某个业务的数据库。在这种情况下，存储阵列就会出现多个大的I/O顺序读写和在线小I/O交易数据处理的并行运行，从而导致存储资源的争用。采用传统存储来处理混合负载问题不仅使性能调优变得更加困难，还会因为资源的争用导致系统整体性能下降。
□激增流量性能问题
虚拟化和云计算的工作负载常常是不可预测的，因此数据流量激增往往会导致性能问题。随着虚拟化技术的提高和业务云化的深入，单个物理机上运行的虚拟机和应用越来越多，我们难以预料在某个时刻某一应用是否会有突发的大流量产生。我们希望存储能自动扩展，动态分配容量和性能，以满足突发流量的各种需求。
除了需要考虑存储的各种性能问题，对于存储资源利用率的提高和优化也是建设存储资源池时要考量的。在企业数据中心，云环境下的存储资源利用率一般从以下几个方面来考虑。
□SLA（服务水平协议）级别的存储资源利用率
在企业级数据中心和云计算环境下，如何根据服务水平需求细粒度地动态配置资源，对SLA级别的存储资源利用率起着决定性作用。
□配置存储资源利用率
在传统存储中，配置的存储容量中只有很少一部分得到实际使用，剩下的大部分被预留用于未来的业务发展，这就导致存储资源利用率低下。同时，这些长期处于闲置状态的存储资源依然需要消耗存放空间、电力、散热和维护资源。
□存储容量利用率
由于我们无法准确预估一个业务的增长和所需求的存储空间，一般在分配存储资源时采用精简配置。但是在数据保护和业务连续性过程中，一些自动精简技术只能实现配置过程的精简，不能保证恢复过程的精简，这就导致存储容量在数据恢复过程的浪费。另外，传统存储预配置造成的存储容量浪费，在远程复制、镜像和快照等实现数据保护和业务连续性过程中得到进一步放大。
□虚拟机容量利用率
虚拟化可能带来虚拟机蔓延和已配置的虚拟机空间闲置。此外，在测试和研发业务中，在项目完成且数据迁移后，为虚拟机配置的空间会导致大量退役后虚拟机闲置资源的积累。如果无法有效回收这些闲置的存储容量，不仅会造成虚拟化环境存储成本的快速上升，也会导致虚拟化环境运营成本的更大浪费。
3.存储资源的设计方法
在一个企业级数据中心，基于云计算和虚拟化环境对存储资源进行设计时，首先要基于业务的需求，根据业务的规模和业务类型，通过采集基础数据，整理出业务需要的存储容量、性能和可用性级别要求，并根据预计使用的存储设备的类型规格，计算出所需要的存储资源配置。
存储资源设计从信息收集到输出详细的存储资源配置方案经过如下几个过程：
□获取基础数据
对于现有的业务应用服务器，在数据增长量是可预计的情况下使用各种服务器性能采集工具，通过采集一段时间的服务器关键性能数据（如一个月），收集到对该业务具有关键作用的物理服务器的CPU、内存、存储、网络、磁盘I/O等数据，以便准确充分地对存储性能需求进行评估。
对于新添加的业务应用，如果对该业务的存储资源、业务增长率有比较准确的估计，则可以根据这些数据，结合业务类型并依据业界通行的存储性能估算方法，计算出该业务对存储的性能需求。反之，如果对该业务的存储资源、业务增长率没有比较准确的估计，但其他企业已有大致相同规模的同类应用，则可以参考业界对该类型服务器的存储需求，或采用对该业务进行开发测试的推荐存储需求，作为该服务器的存储需求。
□方案设计
根据上一步骤获取的存储性能和容量数据，推荐使用的存储类型、接口方式、RAID类型、磁盘类型等，相关信息包括IP SAN或FC SAN的配置信息、存储机柜的数量、存储集群的数量和每个集群下LUN的数量。
其中IP SAN或FC SAN的配置信息包括IP SAN或FC SAN的总数量，单台IP SAN或FC SAN的硬盘数量、硬盘类型，SAN的RAID类型、数量、热备盘数量。
□存储资源规划
根据存储方案设计，即可产生相关的存储资源规划。具体的规划包括：
■SAN控制器的前端口地址
■存储的RAID和LUN命名、容量大小
■LUN的条带深度
■SAN主机和主机组的命名
■SAN标识
■硬盘的划分
■存储设备的组网
例如，某数据中心SAN存储资源池的规划如下。
SAN的存储资源池主要为数据库和虚拟化两类业务提供存储空间，生产区采用EMC高端存储和华为中端存储来搭建存储资源池，业务系统优先使用EMC高端存储，开发测试区以华为中端存储为主。根据业务需求通过云管理平台对所有存储资源进行统一的分配和回收，达到存储资源高效利用的效果。
存储资源划分为三个服务层级，高性能层采用RAID1的SSD磁盘，为极端强调性能的数据库提供存储空间，并为数据库的Redo Log提供存储空间。性能层采用RAID1的SAS磁盘，主要提供给一般性能要求的数据库应用。容量层采用RAID5的SAS磁盘，主要提供给虚拟机环境使用。存储资源由存储管理平台集中管理和调度，并提供API接口供云管理平台进行资源纳管。

2.4.2　OpenStack

除了计算资源以外，OpenStack还管理存储资源。OpenStack可以为云服务或云应用提供所需的对象及块存储资源；因对性能及价格有需求，很多组织已经不能满足于传统的企业级存储技术，而OpenStack可以根据用户需要提供可配置的对象存储或块存储功能。
在OpenStack私有云环境中可能存在多种不同类型的存储资源，比如传统的企业级存储和新兴的软件定义存储，按照存储类型可以分为块存储和对象存储等。作为管理数据中心资源的云操作系统，OpenStack通过Cinder和Swift项目来管理这两种存储资源。
如图2-11所示，与Cinder相比，Swift有些不同，它是一个开源对象存储项目，并不提供存储虚拟化功能，因此，本节我们主要讨论Cinder。与Nova项目类似，Cinder服务本身也不提供存储功能，而是通过虚拟化各种后端存储形成虚拟存储池，以供虚拟机和应用使用。

1.虚拟机对块存储的要求
Cinder是一个资源管理系统，负责向虚拟机提供持久块存储资源，它把不同的后端存储进行封装，向外提供统一的API，对卷进行管理并贯穿虚拟机的整个生命周期。如图2-12所示。

Cinder的基本功能：
□创建卷
□从已有卷创建卷（克隆）
□扩展卷
□删除卷
□挂载卷到虚拟机
□从虚拟机上分离卷
□创建卷快照
□从已有卷快照创建卷
□删除卷快照
□从镜像创建卷
□从卷创建镜像
Cinder通过插件式驱动来支持不同的后端存储，如图2-13所示。

图2-14是Cinder LVMiSCSIDriver的技术架构。

图2-15是IBM SVC/DS8K/XIV Cinder驱动的技术架构。

图2-16为默认的LVM驱动和第三方存储驱动。

2.存储池管理
Cinder-volume服务运行在存储节点上，管理着存储空间。每个存储节点都有一个Volume Service，若干个这样的存储节点联合起来可以构成一个虚拟块存储资源池，如图2-17所示。

OpenStack Cinder主要包括如下几个子模块（如图2-18所示）：
□Cinder-api：提供Cinder REST API。
□Cinder-scheduler：将客户端的卷创建请求调度到某个后端存储上，其工作原理类似于Nova-scheduler。
□Cinder-volume：调用后端存储的接口进行卷操作。
3.Volume Type和QoS
运行不同应用的虚拟机对存储可能有不同要求，比如，对I/O要求高的虚拟机自然要求使用高I/O的后端存储，对数据加密有要求的虚拟机则要求后端存储支持卷加密功能，有些虚拟机则有QoS要求。一方面，Cinder-volume周期性地将后端存储的功能和容量等信息上报给Cinder-scheduler；另一方面，Cinder通过Volume Type功能来支持这种需求。

Volume Type是定义某个服务级别的标准的集合，它由云管理员定义，用户在创建卷的时候根据需要选择使用某种Volume Type；带有某种Volume Type的卷在被创建后也可以被修改。
举个例子：如图2-19所示，用户需要创建一个SLA为“Silver”、大小为520GB的卷，他输入大小和Volume Type；Cinder-scheduler则会根据该Volume Type中定义的存储能力，找到一个满足条件的后端存储（Cinder backend），再将卷创建请求调度到该后端存储对应的Cinder-volume服务上。

如图2-20所示，Cinder支持两种类型的QoS：
□一种是“front-end”类型，通过QEMU实现。
□一种是“back-end”类型，通过后端存储实现。

用户使用Cinder QoS的通常步骤是：
□创建一个QoS spec：cinder qos-create high_read_low_write consumer= "front-end" read_iops_sec=1000 write_iops_sec=10
□创建一个Volume Type：cinder type-create type1
□将QoS spec和Volume Type关联起来：cinder qos-associate 9476d6a5-8903-4383-bb0a-bdc753843329 ca306ba5-fe9e-4b87-84b1-49823057c528
□创建一个使用上述Volume Type的卷：cinder create --display-name high-read-low-write-volume volume-type type1 100
□将卷挂载到某个虚拟机：nova volume-attach vm-1 high-read-low-write-volume/dev/vdb

2.5　网络资源管理

下面我们通过VMware和OpenStack这两个比较常用的IaaS管理平台来看看它们在网络资源管理方面的具体技术和实现。

2.5.1　VMware

在企业级数据中心内，VMware由于管理和应用的不同要求，需要划分多个不同的网络区域，并需要考虑物理区域和逻辑区域的隔离。依据应用系统的要求，数据中心网络逻辑区域划分需要考虑如下原则：
1）根据安全架构，不同安全等级的网络区域归属不同的逻辑区域。
2）不同功能的网络区域归属不同的逻辑区域。
3）承载不同应用架构的网络区域归属不同的逻辑区域。
4）区域总量不宜过多，各区域之间保持松耦合。
根据以上原则，网络的逻辑区域可划分为外网区和内网区。
□外网区：外网区根据功能的不同可划分为互联网和外联网两个区域。这两个区域部署对外服务的应用系统，互联网提供互联网客户的访问，部署Web网站、电子商务、学习环境等互联网业务；外联网提供第三方机构及大客户的访问，部署外联或托管等业务。
□内网区：内网区根据功能的不同又可划分为网络功能区、服务器接入区和带外管理区。
■网络功能区：无服务器部署，根据功能不同划分为核心区和广域网区两个子区域。核心区提供各个模块间的高速转发功能，广域网区负责数据中心与集团各网络的互联互通。
■服务器接入区：负责各类应用服务器的部署，根据功能的不同可分为主机接入区和开放服务区两个子区域。主机接入区提供x86或其他小型机的接入环境。开放服务区提供开放服务器的接入环境。在开放服务区，可根据不同的应用架构进行区域细分，即普通开放服务区、网络管理安全区、存储区和语音区。
■带外管理区：这是一个特殊功能区域，负责服务器和网络设备的带外组网，也方便对服务器和网络设备进行带外管理和维护。

2.5.2　OpenStack

除了计算和存储资源，OpenStack还能管理数据中心内的网络资源。如今的数据中心存在大量设备，如服务器、网络设备、存储设备、安全设备等，而它们还将被划分成更多的虚拟设备或虚拟网络；这会导致IP地址的数量、路由配置、安全规则呈爆炸式增长；传统的网络管理技术无法真正地高扩展、高自动化地管理下一代网络；因而OpenStack提供了插件式、可扩展、API驱动型的网络及IP管理。
如图2-21所示，一个标准的OpenStack网络环境至少需要4个不同的数据中心网络：
□管理网络（management network）：用于OpenStack各组件之间的内部通信。该网络内的IP地址必须只能在数据中心内可访问。
□数据网络（data network）：用于OpenStack云内虚拟机之间的数据通信。
□外部网络（external network）：用于向虚拟机提供因特网访问。该网络内的IP地址必须在因特网上可访问。
□API网络（API network）：提供OpenStack API访问的网络。该网络内的IP地址必须在因特网上可访问。
对于内部网络，OpenStack Networking项目Neutron提供了丰富的API来定义云中的网络连接。它的主要概念包括：
□Network：一段隔离的二层（L2）网段，类似于物理网络中的VLAN。
□Port：将一个设备比如虚拟机的一个网卡连接到一个虚拟网络的连接点。
□Subnet：一段IPv4或者IPv6地址段，以及它们的配置状态。
通过创建和配置网络、端口和子网，开发者、管理员和租户可以创建出丰富的OpenStack云中网络。

除此以外，OpenStack Neutron还提供了基于VR（Virtual Router，虚拟路由器）的VPN as a Service（VPN即服务），可以将两个物理上分离但是由互联网连接起来的两个OpenStack子网通过VPN连接起来，并使得各自子网内的虚拟机可以互连互通。

2.6　监控管理

2.6.1　监控指标的设定和调整优化

当虚拟化和云计算技术被企业和数据中心广泛利用后，其对现有硬件提供更高的资源利用率和降低企业应用成本成为人们谈论的焦点，通常物理服务器的资源利用率只有10%～20%，因此通过虚拟化整合资源利用率低的服务器将非常有意义。
服务器虚拟化技术在近几年已经发生了根本性改变，现在虚拟化已经被视为数据中心实现灵活和弹性的必需品，虚拟化开销较低的服务器已经没有太大意义，越来越多的组织开始虚拟化整个业务乃至数据中心，这样组织可以将所有宿主服务器看作一个计算资源池，实现按需分配资源。
为了确保存储和服务器能应付不断增长的业务需求，对磁盘资源、内存和CPU资源、宿主操作系统进行监控和调整是必要的。
1.磁盘资源
服务器硬盘是磁盘资源中最慢的组件，在企业数据中心，注意仔细设计存储子系统，不要让它成为主要性能瓶颈，而最理想的办法是使用SAN，即使预算不允许，也要想办法确保磁盘资源争用不会导致虚拟机（VM）瘫痪。
首先应将宿主操作系统安装到专用硬盘上，注意不是专用卷，确保宿主操作系统不会与虚拟机抢夺磁盘资源。如果托管服务器可以连接外置存储，还可以考虑将宿主操作系统的分页文件移动到外置存储的专用驱动器上。
RAID阵列是满足虚拟服务器性能所必需的，至少应该选择使用RAID1，但“RAID1+RAID0”（RAID10）是更好的选择，因为它能提供容错，并且性能开销也比RAID5小。如果可以的话，给每个虚拟服务器分配一个专用磁盘阵列最好。
虽然存储阵列类型很重要，但阵列使用的硬盘也同样重要，如果两个或更多虚拟服务器共享一个存储阵列，那么应该考虑使用10k RPM的硬盘，它比7500 RPM的硬盘要贵一些，但性能表现却要好很多，当然这需要用户在性能和成本之间进行平衡。
另外不要忘了使用可热插拔的SCSI硬盘，不然换一块硬盘就得关闭系统，尤其是当多个虚拟服务共享一个存储阵列时，其影响面非常大。
不管使用哪种存储设备类型，都要确保已安装了合适的驱动。比如可以让Windows系统自动识别存储设备，虽然这样做本身并没有问题，存储设备也可能会工作得很正常，但性能表现就不是很理想了。
使用固定大小的虚拟硬盘来配置虚拟服务器会获得额外的性能提升。虽然动态扩展虚拟硬盘很方便，但对服务器的性能是有影响的。
磁盘I/O性能监控的指标主要包括以下七个。
指标1：每秒I/O数（IOPS或TPS）
对于磁盘来说，一次磁盘的连续读或者连续写称为一次磁盘I/O，磁盘的IOPS就是每秒磁盘连续读次数和连续写次数之和。当传输小块不连续数据时，该指标有重要参考意义。
指标2：吞吐量
吞吐量即硬盘传输数据流的速度，传输数据为读出数据和写入数据的和。其单位一般为kbit/s、MB/s等。当传输大块不连续数据时，该指标有重要参考作用。
指标3：平均I/O数据尺寸
平均I/O数据尺寸为吞吐量除以I/O数目，该指标对揭示磁盘使用模式有重要意义。一般来说，如果平均I/O数据尺寸小于32KB，可认为磁盘使用模式以随机存取为主；如果平均每次I/O数据尺寸大于32KB，可认为磁盘使用模式以顺序存取为主。
指标4：磁盘活动时间百分比
磁盘处于活动时间的百分比即磁盘利用率，磁盘在数据传输和处理命令（如寻道）时处于活动状态。磁盘利用率与资源争用程度成正比，与性能成反比。也就是说磁盘利用率越高，资源争用就越严重，性能就越差，响应时间就越长。一般来说，如果磁盘利用率超过70%，应用进程将花费较长的时间等待I/O完成，因为绝大多数进程在等待过程中被阻塞或休眠。
指标5：服务时间
服务时间即磁盘读或写操作执行的时间，包括寻道、旋转时延和数据传输等时间。其大小一般与磁盘性能有关，CPU/内存的负荷也会对其有影响，请求过多也会间接导致服务时间的增加。如果该值持续超过20ms，一般认为会对上层应用产生影响。
指标6：I/O等待队列长度
I/O等待队列长度即待处理的I/O请求数目，如果I/O请求压力持续超出磁盘处理能力，该值将增加。如果单块磁盘的队列长度持续超过2，一般认为该磁盘存在I/O性能问题。需要注意的是，如果该磁盘为磁盘阵列虚拟的逻辑驱动器，需要再将该值除以组成这个逻辑驱动器的实际物理磁盘数目，以获得平均单块硬盘的I/O等待队列长度。
指标7：等待时间
等待时间指磁盘读或写操作等待执行的时间，即在队列中排队的时间。如果I/O请求持续超出磁盘处理能力，意味着来不及处理的I/O请求不得不在队列中等待较长时间。
通过监控以上指标，并将这些指标数值与历史数据、经验数据以及磁盘标称值对比，必要时结合 CPU、内存、交换分区的使用状况，不难发现磁盘I/O潜在或已经出现的问题。但如何避免和解决这些问题呢？这就需要利用磁盘I/O性能优化方面的知识和技术了。限于篇幅，在这里仅列出一些常用的优化方法以供读者参考：
1）调整数据布局，尽量将I/O请求较合理地分配到所有物理磁盘中。
2）对于RAID磁盘阵列，尽量使应用程序I/O等于条带尺寸或者为条带尺寸的倍数。并选取合适的RAID方式，如RAID10、RAID5。
3）增大磁盘驱动程序的队列深度，但不要超出磁盘的处理能力，否则部分I/O请求会因为丢失而重新发出，这将会降低性能。
4）应用缓存技术减少应用存取磁盘的次数，缓存技术可应用在文件系统级别或者应用程序级别。
5）由于大多数数据库中已包括经优化后的缓存技术，数据库I/O宜直接存取原始磁盘分区（raw partition）或者利用绕过文件系统缓存的DIO（Direct I/O）技术。
6）利用内存读写带宽远比直接磁盘I/O操作性能优越的特点，将频繁访问的文件或数据置于内存中。
2.内存和CPU资源
物理内存是服务器虚拟机容纳数量的最大影响因素，应尽可能安装最多的内存，最好是主板支持的内存上限。此外，应给虚拟机分配合适的内存，给宿主操作系统预留足够的内存，避免内存不够用或过度分配。
有些虚拟化产品不限制管理员过度分配服务器的CPU资源，它们允许用户分配比物理CPU核心还多的虚拟CPU给虚拟机。为了获得最佳性能，宿主操作系统至少要预留两个CPU核心，以确保分配的每个虚拟CPU都有对应的物理CPU核心，否则就会出现“资源赤字”。
请记住，这些建议是基于最佳性能角度考虑的。虽然有时可以分配比物理CPU核心还多的虚拟CPU给虚拟机，性能也能维持在一个可接受的水平，但它一定不是最优的状态。一般建议CPU可以超配，但内存最好不要超配。
CPU和内存性能监控关键指标说明如下。
CPU使用率：指用户进程与系统进程消耗的CPU时间百分比，长时间情况下一般可接受的上限不超过85%。
判断CPU是否是瓶颈的方法：一般情况下当CPU满负荷工作时，有时候并不能判定为CPU出现瓶颈，比如Linux总是试图要CPU尽可能的繁忙，使得任务的吞吐量最大化，即CPU尽可能最大化使用。因此，一般主要从两方面来判断CPU是否为瓶颈：一是CPU空闲持续为0，二是运行队列大于CPU核数（经验值为3～4倍），即可判定存在瓶颈。CPU的高消耗主要由什么引起的？可能是应用程序不合理，也可能是硬件资源不足，需要具体问题具体分析，比如问题由SQL语句引起，则需要跟踪并优化引起CPU使用过高的SQL语句。
内存利用率：内存利用率=（1-空闲内存/总内存大小）×100%。
判断内存是否是瓶颈的方法：一般至少有10%可用内存，内存使用率可接受上限为85%。当空闲内存变小时，系统开始频繁地调动磁盘页面文件，空闲内存过小可能由内存不足或内存泄漏引起，需要根据系统实际情况监控分析和优化。
3.宿主操作系统
服务器虚拟化优化常常被忽视的一个方向是宿主操作系统本身对硬件资源的需求。不是所有虚拟化产品都依赖于传统的Windows服务器操作系统。例如，Hyper-V服务器是一个专门的、独立的产品，它比完整的Windows服务器操作系统的“身材”要小巧得多，因此它对硬件资源的需求就更少。
如果目标是最大化性能，那么最好使用独立的虚拟化产品，可以是VMware、Hyper-V或其他VMware类似的产品，但有时系统管理需求可能会要求你在宿主服务器上运行传统操作系统，在这种情况下，你可以采取一些措施来减少宿主操作系统的开销。
首先，确定宿主操作系统中的哪些进程是必需的，哪些是可有可无的，哪些是应该停止的，在任何情况下，宿主操作系统都应该只运行那些关键的应用，如备份代理或防病毒软件，其他非必需应用应该关闭或卸载。
其次，确保宿主操作系统上的防病毒软件不要扫描虚拟硬盘或与虚拟机相关的任何文件。扫描这些文件不但没有实际意义，而且会对服务器的性能造成影响，最糟糕的是，防病毒软件还可能损坏虚拟硬盘文件。
另一个优化技术是更改宿主操作系统的处理器调度方法，Windows服务器提供了一个设置，允许你调整处理器调度以优先满足运行中的程序或后台服务。对于虚拟主机，应该总是优先满足后台服务的需要。
最后，如果宿主服务器可以自动执行碎片整理，那么应该将碎片整理进程安排在空闲时段执行。同样，对虚拟机执行自动化碎片整理也应该安排在非高峰时段进行，同时要避免多个虚拟机同时执行碎片整理。
随着虚拟主机处理的负载越来越多，优化宿主服务器的虚拟化性能变得比以往任何时候都重要，通过优化可以确保资源池得到最有效的利用。

2.6.2　统一运维监控平台和告警处理

构建一个统一的运维监控平台，必须以运行监控和故障报警这两个方面为重点，将所有业务系统中所涉及的网络资源、硬件资源、软件资源、数据库资源、存储资源等都纳入运维监控平台中，并通过消除管理软件、数据采集手段的差别，对各种不同的数据来源实现统一管理、统一规范、统一处理、统一展现、统一用户登录、统一权限控制，最终实现规范化、自动化、智能化的大运维管理。
统一运维监控平台的系统建设主要有以下3个要点：
□分层告警
在企业级数据中心中会存在多个检测组，下层组织只需要将关键告警信息转发到上层组织。当发生重大故障时，多级组织可以同时发现、分解、解决故障事件。为了减少层级间数据冗余和节省链路带宽，我们可以按级别、类型有针对性地进行数据转发。
□监控数据同步
为了提高系统的可用性和业务连续性，我们可以在多个数据中心之间进行数据同步，当其中的监控中心发生故障时，其他备选监控中心可以暂时接管监控工作，当系统恢复时再切换到原有监控中心。
□全方位支持模式
企业级数据中心环境下的监控平台可能在不同的地理位置都有服务站点，这些站点可能跨时区、国家或地区。为了有效地监控系统并节省资源，我们可以在多个监控中心之间进行消息转发。
如图2-22所示，在每个数据中心都部署了分控中心，总部部署统一监控中心并与各分控中心保持实时联系，实现告警信息的统一收集、监控与分发。当数据中心1不在工作时间时，其所负责的数据中心告警将由统一监控平台负责分发到其他正在工作的分控数据中心，实现及时处理并达到最佳经济效益。

下面具体介绍应用监控项以及告警处理。对于一个企业的私有云来说，云监控的应用监控项比较多，但大多数只是警示性监控项，具体监控项的描述会在监控项输出的时候归档成表，以下针对主要的两个监控项进行说明。
1.Java进程监控及处理
该监控项在每个云监控应用中都有设置，目的是实时监测应用的Java进程是否有关闭的情况，如果监控报警收到没有Java进程，此时应用管理员应该查看服务器出现的状况，通常情况下只须重启应用即可。
2.端口监控及处理
云监控各应用的运行涉及不同的端口，端口监控的目的就在于确保每一个端口的状态正常，如果出现端口报警，一般情况下重启应用即可。如果出现重启应用解决不了的情况，须到服务器上检查网络状态，系统状态以定位问题所在。
对于运维人员来说，不可能天天盯着数据报表，因此还需要对监控收集到的数据进行报警和处理。
例如，对每个需要监控的主机或服务设置一个合理的报警阈值，当收集到的数据超过这个阈值时，在第一时间自动报警并通知运维人员，反之，运维人员就可以做其他事情，而不用时刻盯着数据报表，这是构建智能监控报警平台必须要实现的一个功能。
对主机或服务的状态值进行监控并当达到指定阈值时进行报警，要实现这个功能并不难，写一个简单的shell脚本就能实现，但是维护性差，并且当需要监控报警的主机或服务越来越多时，脚本的性能就变得很差，管理起来也非常不方便，因此需要有一个专业的监控报警工具来实现这个功能，那么拥有自动化的运维监控工具就非常有必要了。

2.7　运维管理

2.7.1　IT运维流程与规范

随着信息化的飞速发展，IT信息系统已成为支撑企业运作不可缺少的一部分，企业内部建立了各种信息系统，如ERP系统、CRM系统、生产执行系统、办公自动化系统等。目前，虽然信息技术在企业中的应用得到了前所未有的重视，但是企业中普遍存在“重建设、轻运维”，“重技术、轻流程”等问题，导致对IT运维工作投入不足，缺乏规范化的运维管理流程。其实从信息系统的整个生命周期来看，实施建设只占其生命周期的20%，而其余80%的时间都是对其进行运行维护，所以运维阶段是IT生命周期中的关键阶段，如果IT的运维管理做得不好，那么这些花费大笔投资建立起来的系统将无法带来预期的效益。
由于缺乏规范的运维管理体系，导致企业普遍存在以下问题：
□运维人员就像救火队员一样处于被动的服务状态，只有当问题已经发生后才进行紧急处理，不能预防问题的发生。
□缺乏统一的服务台，用户请求随意性大，他们直接找有经验的信息人员，导致能干的人员成天处理无价值的琐碎事情，价值无法有效体现。
□缺乏规范的运维制度和流程。在处理问题时，没有对问题进行记录和分类，导致无法跟踪和监控问题的处理情况。
□IT运维的相关经验没有积累和共享。由于缺乏对运维过程的记录，使得问题的处理方法只有当时的维护人员掌握，相关经验难以积累和共享。
□运维人员绩效无法量化。在运维工作中没有建立量化的考核指标，IT运维质量和运维人员的绩效无法量化，使得运维人员的工作积极性得不到提高。
因此实现运维管理从传统被动式服务转变为主动预防服务，以流程贯穿整个运维管理过程，实现运维管理的标准化、规范化和流程化是目前企业信息化建设急需解决的问题。
那么如何建立规范的IT运维流程与体系呢？从实践来看，需要做好以下几方面的工作。
1）标准化。比如说，我们数据中心经常要进行巡检，不同的人巡检，其效果是不一样的，因为不一样水平的人能够发现的问题不尽相同。那么针对硬件、小型机、x86、存储等，做到这些环节的巡检标准化，甚至可以用软件来统一实现是否可行？经过近一年的努力，我们把巡检标准化这个难题给解决了。现在不管哪个员工到现场，根据这份标准化流程和分析方法做出来的巡检报告质量能保证水平基本一致。从这件事情我们可以窥见标准化的重要性。
2）自动化。一旦能够标准化了，下一步我们就可以考虑运维的自动化了。现在很多企业都在谈论运维自动化，但如果企业运维的各种工具、平台、知识体系都不标准化，怎么能做到自动化？即使做出来了，这种自动化也是虚的。在做运维自动化的过程中，企业采集了大量指标，做了大量的监控告警，但每天成百上千个告警跳出来，根本解决不完—这不是在做自动化，而是给我们的运维添乱、添堵，给运维人员造成巨大的精神压力。所以说，考虑自动化之前，一定要先考虑运维标准化，当我们能把运维的一系列工作包括采集、分析、监控、操作等全部标准化了，自动化的问题也会迎刃而解。
3）可视化。自动化实现后还需要做可视化，为什么呢？这是必须完成的一个环节，它可以把采集到的大量数据通过一种可视化方式表现出来，很好地把一些指标向运维人员展示并在一定程度上解放运维人员，降低运维成本。但是在做可视化的过程中，我们不能再走以前的老路。以前我们使用的运维自动化工具都是一些商业软件，并且这些商业软件通常是基于网管式方法，这些网管软件面面俱到，但是不够专业。举个例子，比如说现在有一个业务系统，这个系统里面有12个网络设备、90个服务器，不同的人关注的点是不一样的，但是专业的网管软件只能采集一套数据。因此这里就涉及在引入可视化时，不单单要把数据展示出来，还要做到场景化运维。对于哪怕同一个拓扑图，网管人员、安全人员和业务人员会根据自身关注的指标体系，看到不一样的内容，即不同的人关注不同的场景。
当我们把前面所有步骤都完成了，后续就可以实践智能化了，也就是引入大数据分析。通过大数据分析，我们能够发现以前很多关注不到的问题，一些以我们的知识能力达不到的分析层面。至此，我们的运维流程和体系就逐步完善起来了，同时智能化的大数据分析对我们的IT运维来说也是很好的补充。

2.7.2　自动化运维工具

开源或商业的自动化运维工具有很多，本书并不能一一枚举。这里只对业内著名的开源配置自动化工具进行介绍。
Puppet：Puppet是一种Linux、UNIX、Windows平台的集中配置管理系统，使用自有的Puppet描述语言，可管理配置文件、用户、cron任务、软件包、系统服务等。Puppet把这些系统实体称为资源，Puppet的设计目标是简化对这些资源的管理以及妥善处理资源间的依赖关系。Puppet采用C/S星状结构，所有客户端和一个或几个服务器交互。每个客户端周期地（默认为半个小时）向服务器发送请求，获得其最新配置信息，以保证与该配置信息同步。Puppet使用一种建模方法来配置自动化配置清单，通过推送的方式来更新所有服务器。
Chef：该工具类似于Puppet，它也是使用编程脚本来实现服务器、操作系统和应用软件自动化部署和更新的。Chef使用Git编程语言，它能够提供非常详细和定制化的脚本，受到IT运维团队的青睐。
Ansible：Ansible是一款基于Python的自动化运维工具，集合了众多运维工具（Puppet、Chef）的优点，实现了批量系统配置、批量程序部署、批量运行命令等功能。管理节点上的Ansible将命令通过SSH协议（或者Kerberos、LDAP）推送到被管理节点上并执行命令，通过这种方式能够在管理节点上控制一台或多台被管理节点，以执行安装软件、重启服务等命令。
Salt：Salt在配置自动化脚本或者部署应用软件方面的功能类似于Puppet和Chef。你可以通过使用Python或PyDSL编程语言创建定制化的脚本或模块，还可以下载预制模块。Salt的最大优势在于其伸缩性和弹性能力。
Git：Git是一个开源的分布式版本控制系统，用于Linux内核开发的版本控制工具，可以有效、高速地处理从很小到非常大的项目版本管理。与常用的版本控制工具CVS、Subversion等不同，它采用了分布式版本库的方式，不需要服务器端软件的支持（注：这需要区分使用的是什么样的服务器端，使用HTTP协议或者Git协议等不太一样。并且在push和pull时与服务器端还是有交互的），使源代码的发布和交流极其方便。Git的速度很快，这对于诸如Linux Kernel这样的大项目来说自然很重要。Git最为出色的是它的合并跟踪（merge tracing）能力。
Foreman：Foreman是一个集成的数据中心生命周期管理工具，提供了服务开通、配置管理以及报告功能，与Puppet一样，Foreman也是一个Ruby on Rails程序。与Puppet不同的是，Foreman更多地关注服务开通和管理数据中心的能力，如PXE启动服务器、DHCP服务器及服务器开通工具进行集成。Foreman可以与Puppet集成使用，通常是作为Puppet的前端接入。Foreman能够通过Facter组件显示系统目录信息，并且可以从Puppet主机报表中提供实时信息，能够自动化完成所有手工管理工作。Foreman还能够管理大规模（当然也包括小规模）的企业级网络，可能有很多域、子网和很多Puppet Master节点。Foreman也可以实现配置版本的回溯。

2.7.3　云环境下的新型IT运维体系

在企业私有云环境下，虚拟化通过资源优化整合，大幅降低了硬件投入、能源、数据中心的物理空间等成本，虚拟服务器正在承担着企业基础甚至核心架构的重任。但虚拟化却增加了IT运维的复杂性，加之很多企业都是重建设、轻运维，没有理念的转变和IT运维管理工具、运维策略的支撑，“后虚拟化时代”带来的这些新问题将会使得IT部门麻烦重重。
据调查，很多企业中云化的业务系统运行状况并不乐观。比如，IT部门优化了服务器资源，但网络资源却没有升级，一台实体服务器向外连接的带宽还与从前一样，如果被虚拟化承载的多个业务系统是跨越多个实体物理机进行部署的，那么网络性能与交换机背板带宽将成为虚拟机流量交换的“短板”，业务系统反而会因为虚拟化变得更加缓慢。因此，如果企业不能将业务系统里的基础数据导入IT运维最为关键的CMDB（配置管理数据库）中，而迫不及待地点击“安装”，等待他们的将是另一个危机陷阱。当然，我们也可以通过建立负载均衡来优化工作负载，或者对多个业务系统进行划分，把高CPU高I/O、高CPU低
I/O、低CPU高I/O、低CPU低I/O的不同业务应用系统区分开来，并放到不同配置的实体物理机上或纳入不同配置的资源池，以避免混乱划分带来的风险。随着每台实体服务器上托管的虚拟机数量增多，资源的整体利用率提高了，但业务系统的潜在风险因大集中反而更高了，此时实体服务器性能监测的重要性不言而喻。
如何构建云环境下的IT运维体系呢？基于云计算的弹性、灵活快速扩展、降低运维成本、自动化资源监控、多租户环境等特性，云环境下的运维需要从以下两个方面来考虑。
1）改变现有的IT运维管理工具。
IT运维工具需要能够管理IaaS平台。IaaS平台可以看作一个大型数据中心，它具有大型数据中心的异构化、虚拟化和大容量的特点，这要求管理云计算的IT运维工具必须具有标准化、虚拟化和自动化的特点：
①通过标准的数据采集方式管理异构的云平台。
②能够监控和管理虚拟化的云设施，包括虚拟服务器、虚拟数据库等。
③具有高度的自动化能力以完成对大量物理、虚拟设备的监控管理并能主动发现潜在问题、及时进行告警。
2）为用户提供SaaS模式的运维服务。
云的到来无疑给中小企业带来了利好消息，企业无须投入大量资金、人力进行运维管理平台体系的建设，只须购买基于SaaS的运维管理服务，即可享受先进的运维管理工具和运维管理体系。基于云的IT运维管理工具必须提供基于PaaS模式的标准软件接口，用户可以在云上添加针对专业设备的监控管理工具模块或开发个性化的运维功能模块，这样既可以满足自身业务的需求，也使云运维管理工具日渐完善。
构建云环境下的新型IT运维体系则需要注意以下三点：
1）打破原有各运维资源之间的分割，进行一体化监控和管理。
打破以往的运维分割，对复杂异构的IT资源环境（如网络设备、服务器、存储、安全设备、操作系统、中间件、数据库、业务系统、前端应用等）进行一体化监控和管理，保障IT基础架构稳定可靠运行、降低系统和业务应用宕机风险，实现提高运维效率和优化运维流程、控制运维成本的目标。
2）把安全管理作为体系框架的核心，针对资源池化的特点进行合理的控制与调度，实现资源的统一管理、安全运行。
在企业中，安全管理中心作为运维管理平台与资源池之间的连接纽带，便于信息安全管理的贯彻与落实；虚拟化资源池的建立可以实现IT系统对资源分配进行统一管理，同时，整合虚拟化管理平台则可实现统一运维管理。系统和应用的部署由人工操作变为模板控制，大大减少了对集成商和运维人员的依赖；原有对基础设施的维护分解为对物理机和虚拟系统的维护。当物理机或虚拟设施发生故障时，可调用不同的基础设施来替换，降低了发生单点故障的可能性；事件、流程、人员与安全中心并列，形成对资源池的全面管理，实现了资源的统一管理和安全运行。
3）建立业务导向的一体化管理，实现高效运维。
云计算体系下的运维目标首先应该以业务为导向，如新业务的快速部署、系统容量的平滑扩容、随需而变的资源分配等，根据业务目标形成IT服务的管理目标，保证IT服务达到要求的等级标准。其次通过自动化运维工具完成系统部署、配置管理以及监控报警等功能，降低故障发生率，提升故障发生后的响应处理效率，实现业务的快速恢复。最后通过改进运行维护服务能力管理过程中的不足，持续提升运行维护服务能力。

2.8　云服务管理

2.8.1　云服务的分类

云服务主要分为三大类，从底向上依次为IaaS、PaaS和SaaS，每一类服务解决的问题都不一样。
1.IaaS
基础设施即服务（Infrastructure as a Service），是云服务里最重也是最基础的一块，经常提到的云计算、云存储和CDN加速等都属于这个领域。由于这个领域有资本密集的特征，相对中小云服务公司，巨头在这一块的优势是极其明显的。国际市场上亚马逊的AWS占据了该领域比较大的份额，国内是阿里云。而AWS和阿里云之所以能占有这么高的份额，与它们的母公司都是电商公司有密不可分的关系。由于电子商务在海量数据、实时支付等处理上对速度有极高的要求，且对失败的容忍度较低，同时还对安全性有严格要求，因此，电商公司内的许多部门在处理业务时会在不知不觉间产生各种对云服务的需求。
现在的IaaS市场上，大的流程化的云服务厂商会更多地提供基础模块化服务，由于巨大的前期投入，该领域不是一般小公司可承受的。但还是有部分创业公司，如七牛云、Ucloud等，选择从存储、金融等一些细分垂直领域切入并做精做深，加上B端（企业）市场先付费的特性，因此仍然有不错的营业收入。在达到一定量之后，可再探索一个有效的盈利模式。
2.PaaS
平台即服务（Platform as a Service），这个分类下已经诞生了上市公司Twilio，2015年其营收达1.669亿美元，2016年一季度营收大增78%，上市首日即大涨92%，市值已经突破了35亿美元。
由于不管是国外还是国内市场IaaS的竞争大局将定，云服务市场的变数可能更多地发生在PaaS和后面要提到的SaaS领域。PaaS的价值在于，它可以提供软件开发（包括APP）所需的基础功能模块，特别是非核心但又有普遍需求的模块，如通信、存储、推送等。
相对于发展时间较长的IaaS和SaaS来说，国内的PaaS发展程度相对比较低，市场仍需培育，并且它不像AWS这样的底层云服务：客户的数据存储在亚马逊的服务器上，一旦开始用，很少会再进行迁移，这就是所谓的数据忠诚度。但如Uber、WhatsApp等公司，在使用Twilio服务的同时也会使用其他多家公司的服务，一旦一家公司出问题，可以立马更换。
由于对于云的需求服务开始像水、电、煤一样变得常见，即插即用式的接入网络就可以直接使用的定制化云模块依然有很大的市场需求，提供更多技术场景的综合类PaaS公司将有机会迅速发展。
3.SaaS
软件即服务（Software as a Service），这一领域可能是大家最熟悉的。虽然它主要还是面向企业的服务，但是仍有许多可以让企业员工个人直接使用到的产品。国外比较有名的如由CRM起家的Salesforce等，国内比较有名的如做企业通信的钉钉（Ding Talk）和企业销售管理的纷享销客等。
与PaaS仍处在初期发展不同，SaaS已经红火数年，并且关注度持续升温。之前提到的PaaS领域的Twilio的市值才刚达35亿美元，而Salesforce已经突破500亿美元了。
除了CRM，SaaS领域还有许多细分领域，相对于OA、ERP和团队协作软件，由于CRM涉及销售，是企业营收的根本，所以无论是国内还是国外，都是最早进入红海竞争的产品门类。
但是，云服务市场发展到今天，这三个分类的分界线变得越来越模糊。
比如，做SaaS业务的Salesforce会收购一些PaaS公司，这样一来，除了定制化软件，它开始涉足定制化接口模块业务了。而原本做IaaS的AWS，也在原来的业务基础上叠加了PaaS甚至SaaS业务。国内的阿里云也是如此，推出了YunOS，包括旗下的钉钉也开始提供全部的三大类云服务。
其中，PaaS创业企业的境遇最尴尬，一方面它们面临着SaaS企业基于优势业务拓展PaaS服务带来的压力，另一方面IaaS巨头公司持续开放自家产品的功能，形成平台效应并成为PaaS创业企业的挑战。
虽然PaaS公司做IaaS比较难，但它们可以利用自己在某些方面的技术优势向SaaS领域发展，这样更靠近用户之后，不但丰富了自己的产品线，也提升了自己的盈利能力。

2.8.2　云服务的建设

云服务是云计算环境的核心。在构建私有云时企业往往会从自身的应用特点和需求出发进行服务的设计和实现，因此很难针对私有云制定通用的服务模板。依据云计算建设的通用方法，对于云服务的建设，一般来说会关注以下四个方面：
□云服务的识别：云服务的识别是云服务实现的第一步，决定了在云计算环境中将供给的服务内容。云服务的识别是以需求调研为基础的，从必要性、可复用性、实现成本等多个角度出发，分析服务实现的难点和收益，制定服务分阶段实现的计划与路线图。
□云服务的设计：在云计算环境中对云服务的使用模式决定了云服务的设计要点，一般来说，对于云服务的设计内容包括服务的底层架构、服务的运行流程、服务安全与监控、服务的审计与合规性检查、评价服务能力的关键指标（KPI）、服务的高可用、服务的SLA等几个方面。
□云服务的实现：云服务的实现一般有四种方式。一是从业务需求分析出发进行云服务的定制开发;二是利用第三方软硬件产品进行服务封装;三是从其他云计算运营商购买，合作实现;四是基于已有服务进行服务组合，形成新的服务。
□云服务的维护：在云服务上线后，对云服务的运维是企业私有云成败的关键。云服务的维护包括两个方面。一是针对云服务自身的维护，包括对服务能力和状态的监控、对服务性能和规模的趋势分析、服务的修正与升级、服务底层架构的维护等；二是服务的SLA达成度保障，包括实时监控服务的KPI并与SLA所规定的服务目标进行比较，在不符合SLA时及时干预使其符合要求，同时确保满足SLA所规定的安全、隔离等相关条款。

2.8.3　云服务质量评估

从云服务质量评估的角度来说，云服务可以包含一项或多项核心服务和支持服务，如
图2-23所示。核心服务是重点，它能满足用户的关键期望和需要。支持服务也是不可或缺的部分，它能推动和增强核心服务的服务。

1）可用性。从服务的角度来说，可用性是最重要的参数，它表示一个服务是否存在或者是否立即可用。服务可用性落实到具体的可以衡量的指标上来说，通常用百分比中的几个9来表示。比如在云厂商提供的SLA中会对各种类型的服务可用性进行承诺，如“××服务的可用性至少达到99.9%”。承诺中的99.9%就是我们常说的“3个9”级别，9越多代表可用性越高，计算公式为：
正常服务时间百分比% =（最大可用分钟数-停机时间）÷最大可用分钟数
含9越多代表停机时间越短，以年为例，计算列表如图2-24所示。

服务可用性划分了5个等级，从“2个9”到“6个9”。为什么没有90%，即“1个9”？因为“1个9”不在可用性范围内。绝大多数企业在上云之前其可用性均已超过99%，而第5级的“6个9”每年只停机31秒堪称完美，可惜要达到这个等级需要投入的代价非常昂贵，目前不具备可实施性，因此多数基于可用性等级考虑选择均在“3个9”到“5个9”之间。企业可以根据业务特点并结合服务性价比，来选择合适的云平台部署。
2）安全性。云计算的优势显而易见，用户将其IT应用系统转移至云端的同时也增大了风险性。在用户使用云计算服务后，云服务提供者如何确保客户数据的隐私性和安全性成为一个重要的课题。云服务的安全性从客户感知的角度可以细化为数据的保密性、数据的完整性、业务的连续性、灾难恢复这几个评估角度。云服务安全性评估还需结合国内相关法律法规和标准要求，对云服务进行全方位的评测，以帮助企业有效提升云服务安全水平、管理策略，同时降低安全风险、减少损失，保持企业的云服务业务持续发展和竞争优势，维护企业的声誉、品牌和客户信任。
3）性能。性能是云服务的重要质量衡量指标，包括提供的服务性能、客户感知的虚拟机性能以及云计算业务提供的设备性能。
4）易用性。云服务的易用性需要从客户使用的角度展开，比如各类资源是否方便申请和使用、配置更改和应用设定是否操作简单和便捷。
5）可扩展性。可扩展性是云基础架构的一项重要特征。云计算所具备的可扩展性可以让用户根据业务和资源需求的变化随意配置相应的设备和资源等，比如增加计算资源、存储容量、给带宽扩容，以及不断增加、减少不同规格的云主机等，使得系统、设备、资源等变得更加灵活可控。
6）可管理性。从客户角度来看，具备良好可管理性的云服务可以实现客户便捷管理云主机和相关产品的功能。是否具备运转稳定、操作便捷、覆盖全面的统一管理平台是衡量云服务可管理性的主要指标。

2.8.4　云服务安全性和法规遵从

企业不使用公有云而选择自建私有云的主要考虑就在于安全。数据表明，安全已经成为阻碍云计算发展的最主要原因之一。根据CDA数据分析师协会统计，32%已经使用云计算的组织和45%尚未使用云计算的组织将云安全作为进一步部署云的最大障碍。
事实上，安全对于ICT而言并非全新课题，传统的信息系统架构同样存在安全问题。只是在云计算环境中，由于采用了包括资源共享、打破资源孤岛、多租户等在内的新的运营模式，导致错误容易蔓延，同时，由于涉及大量虚拟化和自动化等新的技术领域，往往会带来新的技术风险点，因此，在云计算环境中安全问题显得尤为突出。
在云计算体系中，安全涉及很多层面，一般来说，在云计算环境中应主要考虑网络安全、存储安全、物理机安全、虚拟化安全、虚拟化管理安全、交付层安全、数据安全、安全服务和运维安全等9个层面和领域。
同样需要注意的是，并非所有的应用安全问题都应该依赖于云计算环境的安全架构来解决。云计算基础架构环境支持的系统种类众多，业务要求和安全基线各有不同，在对用户进行服务供给时应根据服务种类以及SLA对安全服务内容进行严格的规范，划分清晰的分工和责任界面。
ITIL v3定义的术语—服务水平协议（SLA），主要用以描述提供商和客户之间的服务、文档目标以及具体的职责。为了使其变成一个安全的术语，SLA应该为一个环境带来透明度，能够迭代变化并通过指标的使用加强自动化协作，以便维护相互之间的信任。
云服务为客户提供一个有用的资源，可以在基础架构层证明其资源合规性，并对客户确定合规责任提供了一些建议。然而，由于绝大多数合规工作需要由客户完成，同时由于共同责任的模式，客户一定要了解云的服务细则。
考虑到这些，云安全和法规遵从的关键点主要有以下三个：
□资产所有权：包含数据保管、控制、拥有和返回权。
□服务可用性、监控和响应：旨在衡量与成本相关的领域以及持续性能力。
□服务基线：比如配置管理的法规遵从或者安全评估。
编写一个云服务的SLA要覆盖以上三个领域的风险，并且可以基于可用性水平、保密性和完整性来衡量。

2.9　小结

本章从企业云计算涉及的技术选型和计算、存储、网络资源管理以及监控和运维、云服务管理等方面，阐述了私有云建设的一些实际问题，以帮助读者更好地理解企业私有云建设。