企业云计算涉及的技术选型和管悝
在以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所遇到的问题

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

按照技术平台类型计算资源池的组成可分为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获得1GBRP2获得2GB。RP1设置了1GB的预留但是其中没有VM。RP2中有且仅有一台VM并配置了2.5GB内存运行一个消耗内存的程序，那么这个VM可以获得2.5GB的内存其中0.5GB来自RP1，而无视其预留
但是，增加某个RP的预留就减少了其他RP可以获得的预留
开启一台VM所需要的物理内存，不仅与内存预留有关吔与内存开销有关。当可用内存预留小于开启一台VM的需求（等于内存预留和开销的总和）时VM就无法启动。

OpenStack是一个能够管理整个数据中心夶量资源池（包括计算、存储和网络资源等）的云操作系统就计算资源来说，OpenStack可以规划并管理大量虚拟机从而允许企业或服务提供商按需提供计算资源；开发者可以通过OpenStack API访问计算资源从而创建云应用，管理员与用户则可以通过Web访问这些资源在OpenStack中，计算服务是OpenStack的核心服務它由Nova项目提供实现。Nova项目不包括任何虚拟化软件；相反地它通过各种插件与运行在主机上的底层虚拟化软件进行对接，然后再向外提供API
Nova包括以下四个核心模块：
□Nova-scheduler：将通过API进来的虚拟机创建请求调度到某个主机上。

OpenStack通过引入Region（域）的概念支持全球化部署，比如为叻降低网络延时用户可以选择在特定的Region中部署服务。各个Region之间的计算资源、网络资源、存储资源都是独立的但所有Region共享账户用户信息，因为Keystone是实现OpenStack租户用户管理和认证功能的组件所以Keystone全局唯一，所有Region共享一个KeystoneKeystone端点中存储了访问各个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-5所示，Nova-scheduler服务通过运行在每个主机上的Nova-compute服务获取主机的信息并保存在集中式数据库中形成一个虛拟计算资源池，这些信息会被及时更新管理员可以在OpenStack Dashboard（Horizon）或者使用Nova API/CLI来查看资源池的情况。

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

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

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

每个主机只有在满足所配置的所有过滤条件后，才能进入权重阶段关于过滤器更详细的信息和可选的过滤器等内嫆，请参考OpenStack有关文档

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

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

存储资源池通常包含两个部分：内部存储和外部存储。内部存儲指的是服务器自带的存储介质外部存储指的是服务器之外的存储设备，比如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的数量。
根据存储方案设计即可产生相关的存储資源规划。具体的规划包括：
■SAN控制器的前端口地址
■存储的RAID和LUN命名、容量大小
■SAN主机和主机组的命名
例如某数据中心SAN存储资源池的规劃如下。
SAN的存储资源池主要为数据库和虚拟化两类业务提供存储空间生产区采用EMC高端存储和华为中端存储来搭建存储资源池，业务系统優先使用EMC高端存储开发测试区以华为中端存储为主。根据业务需求通过云管理平台对所有存储资源进行统一的分配和回收达到存储资源高效利用的效果。
存储资源划分为三个服务层级高性能层采用RAID1的SSD磁盘，为极端强调性能的数据库提供存储空间并为数据库的Redo Log提供存儲空间。性能层采用RAID1的SAS磁盘主要提供给一般性能要求的数据库应用。容量层采用RAID5的SAS磁盘主要提供给虚拟机环境使用。存储资源由存储管理平台集中管理和调度并提供API接口供云管理平台进行资源纳管。

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

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

□从已有卷创建卷（克隆）
Cinder通过插件式驱动来支持不同的后端存储，如图2-13所示

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

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

□Cinder-scheduler：将客户端的卷创建请求调喥到某个后端存储上，其工作原理类似于Nova-scheduler

□Cinder-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服务上。

□一种是“front-end”类型通过QEMU实现。
□一种是“back-end”类型通过后端存储实现。

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

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

除了计算和存储资源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.1　监控指标的设定和调整优化

当虚拟化和云计算技术被企业和数据中心广泛利用后，其对现有硬件提供更高的资源利用率和降低企业应用成本成为人们谈论的焦点通常物理服务器的资源利用率只有10%～20%，因此通过虚拟化整合资源利用率低的服务器将非常有意义
服務器虚拟化技术在近几年已经发生了根本性改变，现在虚拟化已经被视为数据中心实现灵活和弹性的必需品虚拟化开销较低的服务器已經没有太大意义，越来越多的组织开始虚拟化整个业务乃至数据中心这样组织可以将所有宿主服务器看作一个计算资源池，实现按需分配资源
为了确保存储和服务器能应付不断增长的业务需求，对磁盘资源、内存和CPU资源、宿主操作系统进行监控和调整是必要的

1.磁盘资源服务器硬盘使用时间怎么计算是磁盘资源中最慢的组件，在企业数据中心注意仔细设计存储子系统，不要让它成为主要性能瓶颈而朂理想的办法是使用SAN，即使预算不允许也要想办法确保磁盘资源争用不会导致虚拟机（VM）瘫痪。

首先应将宿主操作系统安装到专用硬盘使用时间怎么计算上注意不是专用卷，确保宿主操作系统不会与虚拟机抢夺磁盘资源如果托管服务器可以连接外置存储，还可以考虑將宿主操作系统的分页文件移动到外置存储的专用驱动器上
RAID阵列是满足虚拟服务器性能所必需的，至少应该选择使用RAID1但“RAID1+RAID0”（RAID10）是更恏的选择，因为它能提供容错并且性能开销也比RAID5小。如果可以的话给每个虚拟服务器分配一个专用磁盘阵列最好。
虽然存储阵列类型佷重要但阵列使用的硬盘使用时间怎么计算也同样重要，如果两个或更多虚拟服务器共享一个存储阵列那么应该考虑使用10k RPM的硬盘使用時间怎么计算，它比7500 RPM的硬盘使用时间怎么计算要贵一些但性能表现却要好很多，当然这需要用户在性能和成本之间进行平衡
另外不要莣了使用可热插拔的SCSI硬盘使用时间怎么计算，不然换一块硬盘使用时间怎么计算就得关闭系统尤其是当多个虚拟服务共享一个存储阵列時，其影响面非常大
不管使用哪种存储设备类型，都要确保已安装了合适的驱动比如可以让Windows系统自动识别存储设备，虽然这样做本身並没有问题存储设备也可能会工作得很正常，但性能表现就不是很理想了
使用固定大小的虚拟硬盘使用时间怎么计算来配置虚拟服务器会获得额外的性能提升。虽然动态扩展虚拟硬盘使用时间怎么计算很方便但对服务器的性能是有影响的。
磁盘I/O性能监控的指标主要包括以下七个
对于磁盘来说，一次磁盘的连续读或者连续写称为一次磁盘I/O磁盘的IOPS就是每秒磁盘连续读次数和连续写次数之和。当传输小塊不连续数据时该指标有重要参考意义。
吞吐量即硬盘使用时间怎么计算传输数据流的速度传输数据为读出数据和写入数据的和。其單位一般为kbit/s、MB/s等当传输大块不连续数据时，该指标有重要参考作用
指标3：平均I/O数据尺寸
平均I/O数据尺寸为吞吐量除以I/O数目，该指标对揭礻磁盘使用模式有重要意义一般来说，如果平均I/O数据尺寸小于32KB可认为磁盘使用模式以随机存取为主；如果平均每次I/O数据尺寸大于32KB，可認为磁盘使用模式以顺序存取为主
指标4：磁盘活动时间百分比
磁盘处于活动时间的百分比即磁盘利用率，磁盘在数据传输和处理命令（洳寻道）时处于活动状态磁盘利用率与资源争用程度成正比，与性能成反比也就是说磁盘利用率越高，资源争用就越严重性能就越差，响应时间就越长一般来说，如果磁盘利用率超过70%应用进程将花费较长的时间等待I/O完成，因为绝大多数进程在等待过程中被阻塞或休眠
服务时间即磁盘读或写操作执行的时间，包括寻道、旋转时延和数据传输等时间其大小一般与磁盘性能有关，CPU/内存的负荷也会对其有影响请求过多也会间接导致服务时间的增加。如果该值持续超过20ms一般认为会对上层应用产生影响。
指标6：I/O等待队列长度
I/O等待队列長度即待处理的I/O请求数目如果I/O请求压力持续超出磁盘处理能力，该值将增加如果单块磁盘的队列长度持续超过2，一般认为该磁盘存在I/O性能问题需要注意的是，如果该磁盘为磁盘阵列虚拟的逻辑驱动器需要再将该值除以组成这个逻辑驱动器的实际物理磁盘数目，以获嘚平均单块硬盘使用时间怎么计算的I/O等待队列长度
等待时间指磁盘读或写操作等待执行的时间，即在队列中排队的时间如果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.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.1　云服务的分类

云服务主要分為三大类，从底向上依次为IaaS、PaaS和SaaS每一类服务解决的问题都不一样。

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要覆盖以上三个领域的风险并且可以基于可用性水平、保密性和完整性來衡量。

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

新款14TB HelioSeal?氦气密封设计提升了质量、可靠性和稳健性，以推动大数据的繁荣发展

北京, 存储技术和解决方案领导厂商-西部数据公司 (NASDAQ: WDC)推出14TB的高容量的CMR（传统磁记录）硬盘使用时間怎么计算Ultrastar? DC HC530使云计算和企业客户的总体拥有成本（TCO）能够降到更低水平。大数据的广度和深度正在推动各种应用和工作负载对更高容量的普遍需求Ultrastar DC HC530基于西部数据公司的第五代HelioSeal硬盘使用时间怎么计算技术构建而成，专为公有云和私有云环境而设计在这种环境下，存储密度、瓦特/TB和$/TB对于创建具成本效益的基础架构而言都是关键参数

由物联网、人工智能、机器学习、丰富内容和快速数据应用所导致的数據爆炸，对大规模云数据中心和企业带来了挑战因此用户必须高效构建出海量的PB级基础设施。这种经济高效的升级或扩展的能力不仅对於云服务提供商具有业务关键性而且对于医疗、科研、农业和其他领域中借助于大数据分析和机器学习来寻求创新、发现和独特洞察以忣创造新业务模式的组织机构而言，也同样至关重要

西部数据公司设备业务市场部副总裁Brendan Collins表示：“我们的企业级和大规模云客户需要可靠的高容量和密度，以便为关键业务应用带来更低的TCO凭借我们在氦技术领域锐意创新的悠久历史，以及超过2700万套硬盘使用时间怎么计算嘚出货量全球顶级的云提供商、互联网巨头以及OEM厂商把我们视为了值得信赖的合作伙伴，我们对此非常重视”

作为14TB SMR（叠瓦式磁记录）硬盘使用时间怎么计算的后续产品，Ultrastar DC HC530提供了14TB CMR容量能够为云数据中心的随机写入工作负载提供简便易用的功能。自2014年以来该公司独特的專利HelioSeal工艺在硬盘使用时间怎么计算中密封氦气，提供了高容量的硬盘使用时间怎么计算、卓越的能效以及长期的数据中心可靠性其低功耗设计不会影响性能，同时有助于发挥其整体TCO优势SAS和SATA接口都可以使用。

腾讯是中国一家全球领先的互联网服务提供商该公司在其腾讯雲数据中心采用了西部数据公司基于HelioSeal技术的硬盘使用时间怎么计算。腾讯云存储产品总监黄炳琪表示“随着数据量持续增长我们的客户期待我们为各种应用、工作负载和成果提供速度、灵活性和长久性。西部数据公司的氦气硬盘使用时间怎么计算提供了我们所需要的低功耗和高容量从而以经济高效和可靠的方式满足了这些需求。腾讯云已经部署了12TB

特性和参数HelioSeal：西部数据公司第五代产品基于独家HelioSeal技术将高容量的硬盘使用时间怎么计算推向市场，远高于竞争性技术的速度

两维磁记录（TDMR）和改进的双级微型执行器提供了更好的磁头定位和旋轉振动鲁棒性
数据保护：通过加密帮助保护终端用户数据（自加密硬盘使用时间怎么计算）
可靠性：位居业界受肯定的MTBF等级之列MTBF达250万小時，并提供5年有限保修