作者：(美)卓苏拉(Joysula,V.),(美)欧尔(Orr,M.),(美)佩吉(Page,G)
出版社：人民邮电出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
云计算与数据中心自动化试读：
前言
云计算对于IT行业来说是一个巨变，就像用电网代替本地发电机一样。云计算提供效用计算，并且正在改变计算机行业的竞争性质。有许多公司声称他们能够提供云服务。但在多数情况下，他们讨论的只是服务器供给或者数据中心自动化。
许多领先的IT厂商，例如Amazon、Google、Microsoft、HP和Cisco等，认为云计算是控制IT资源的下一合理步骤，也是降低总体拥有成本的主要手段。云计算不仅仅是 IT 业自己热炒的一个话题，云计算承诺要在未来的几年内变革 IT 资源部署、配置和管理的方式。服务供应商已经切实认识到向着这种“一切皆服务”交付模式转移的巨大价值。通过将他们的基础设施扩展并作为服务使用，而不必处理大量分散且不兼容的筒仓或者普遍的单租户托管和租用模型，服务供应商能够向客户提供更高的价值。
本书提供了构建架构的实用方法，尤其是为提供虚拟化/云服务和基础设施即服务（IaaS）来构建架构。根据我们与许多业内领先管理软件厂商和系统集成商合作的经验，我们提供的知识可以说最为全面，详细介绍了如何管理云架构以及提供云服务。本书用实际的用例和构建云的最佳做法详细介绍了云的使用者和供应商都可以利用的管理步骤。
本书目标
本书就如何从头到尾构建和实施管理云的解决方案架构提供了详尽的信息。对于新手来说，本书提供了关于云的信息以及管理云解决方案架构的方法。对于有经验的实际操作人员来说，本书提供了如何设置和提供基础设施即服务（IaaS）的信息。对于产品专家来说，本书介绍了服务供应商的产品要求、讨论了他们的系统如何与其他系统交互才能提供可满足最终用户需求的集成解决方案。
本书是随着我们在实验室中开始与主要管理软件开发商合作提供端到端云基础设施（由计算、网络、存储资源构成）而发展出来的。在这个过程中，我们发现多数独立软件开发（ISV）无法应对提供端到端云基础设施的挑战。因此，我们与Cisco的各类软件开发商合作伙伴使用双方的产品，一起开发云管理的端到端集成解决方案。本书的解决方案和最佳做法提供了端到端的架构解决方案，可以在任何实验网络和生产网络中针对本书描述的场景进行复制和使用。
本书的组织方式
本书分为4个部分。
第1部分：虚拟化管理和云计算环境简介
■第1章“云计算概念”：本章介绍了虚拟化的概念和云的概念。虚拟化和云计算相辅相成。厂商和解决方案供应商也日益使用虚拟化来构建私有云。本章将讨论公共云、私有云以及混合云，还将讨论将企业内计算转移到云计算的好处。本章还提供了在云上可以提供的服务类型的信息，例如基础设施即服务（IaaS）、软件即服务（SaaS），影响云采用的障碍，以及云的好处和投资回报（ROI）。
■第2章“云设计模式和用例”：本章介绍了当今多数企业中常见的典型应用程序设计模式和用例，讨论了如何将这些设计模式和用例转移到云。
■第3章“数据中心的架构和技术”：本章概述了支持新一代“实时”托管IT服务用例所需的架构原则和基础设施设计。本章重点介绍构建块、技术，以及有助于简化数据中心设计和运营的概念。
■第4章“IT服务”：本章从以业务为中心和以技术为中心的角度分别介绍了IT服务的分类。本章还介绍了IaaS背后的经济学和将“工作负载”放在云中的概念，即风险和成本。
■第5章“Cisco的云策略”：本章描述了Cisco公司的企业战略，重点在于与云有关的技术、系统和服务开发。本章还简要介绍了技术向云发展的过程，以便读者更好地理解IT行业是如何发展到这个阶段的。
第2部分：管理云服务
■第6章“云管理参考架构”：本章讨论了各种行业标准，介绍了如何用它们构建参考架构。本章讨论了ITIL、TMF以及ITU-TMN三个标准，并用这些标准构建一个涵盖流程模型、云框架和管理模型的参考架构。本章还对不同管理层之间的集成模型提供了建议。
■第7章“服务履行”：本章描述了云服务履行（也可称为云服务供给）的细节。服务履行负责向客户交付产品和服务。其中包括：订单处理、服务配置和激活以及资源供给。第6章从管理的角度提供了两个参考模型。本章在第6章的基础上提供了云服务履行的细节，并提供了一个管理云的端到端逻辑功能架构。端到端逻辑功能架构基于电信管理委员会（TMF）eTOM（增强的电信运营图）和信息技术基础设施库（ITIL）V3生命周期构建。
■第8章“服务保证”：本章描述了如何自动提供基础设施，介绍了从客户订购服务到实际提供服务时的服务提供方式。需要对这些服务进行监控，这样才能向客户提供高质量的服务。本章讨论了主动性和反应性维护活动、服务监控（SLA/QoS）、资源状态、性能监控以及故障排除。其中包括持续的资源状态和性能监控，主动检测可能的故障，收集和分析性能数据，识别和解决潜在的或真实的问题。
■第9章“收费和分摊”：云计算的终极目标是在需要的时候按需提供资源，以及提供对数据的正确使用。选择进行收费/计费还是只向使用者显示这些数据，由许多因素决定，这些因素在本章都有讨论。本章介绍了云的收费/计费术语；IaaS、PaaS、SaaS的收费考虑，从订单到现金（OTC）的流程，以及云服务的收费/计费架构。
第3部分：管理云资源
■第10章“IaaS的技术构建块”：本章介绍了如何设计和构建IaaS服务，从基本的构建块开始，逐步发展到完整的服务目录。本章还讨论了如何在云管理系统中保持服务数据，对云解决方案改变传统CMDB实现的地方提出了一些思考。
■第11章“自动化和协调资源”：在第10章的基础上，本章介绍，如何在云基础设施中实现服务目录产品，围绕云服务的整个生命周期介绍了云服务的供给、激活和管理的最佳做法。
■第12章“云容量管理”：对任何基础设施进行优化都是一项挑战，更不用说面对的是云产生的独特的、实时的需求。本章介绍了一些关键的容量挑战，描述了开发容量模型的过程，讨论了如何部署支持这个模型的工具。
■第13章“提供正确的云用户体验”：云从根本上改变了 IT的使用和交付方式。要想成为成功的云供应商，关键在于用户体验。本章定义了与云交互的典型角色，他们的需求，以及为了实现一致的用户体验而应该考虑的一些典型集成模式。
■第14章“从成熟度的视角采用云”：在多数情况下，云的构建和部署会涉及组织、流程和技术等各个方面。评估潜在的云用户或云供应商处于三个方面的哪个方面，是关键的第一步。本章提供一个简单的、可扩展的框架，用来评估云的成熟度。
第四部分：附录
附录 A“案例研究：云供应商——混合云”：这个案例研究将本书介绍的概念集成在一起，使用一个具有代表性的示例显示了从使用者和供应商角度考虑云的时候，IT部门和电信公司可以做出的选择。虽然这个示例是虚构的，但这个案例研究是根据实际经验归纳出来的。
■附录 B“术语和缩略词”：这个附录列出了本书使用的云术语的常用缩写及其解释和定义。
关于作者
Venkata（Josh）Joysula博士拥有CCIE资格（编号13518），他是Cisco服务技术集团（CSTG）的一位杰出服务工程师（DSE）和首席解决方案架构师。他在电信和 IP领域拥有25年的管理经验，包括系统工程、技术营销、咨询、客户管理和部署工作。Josh已经在Cisco工作了11年，在此之前，他是贝尔实验室的一位杰出工程师。Josh参与过编写关键的ITU-T网络管理文档，并担任过TMF委员会的顾问主任。Josh发表过60余篇技术论文、报告、文章和图书，世界各地的Cisco客户和Cisco内部工程师经常咨询他的建议，邀请他去演讲，并且他还对OSS/BSS架构和产品进行OSS评估。
Malcolm Orr是Cisco服务部门的企业架构师。Malcolm的工作重心是向电信公司和大型企业客户提供 NGN 和云平台的架构、构建和运营指导。Malcolm 在 IT 界有 18年以上的工作经验，过去5年在Cisco工作期间，他负责为各类客户提供架构和复杂的解决方案。他目前是Cicso内部Tier 1公共云项目的首席架构师。在加入Cisco之前，Malcolm是AMDOCS的资深顾问，研究BT 21CN传输工作。他曾经是Harbrook咨询公司的创始人之一和技术总监，该公司专门提供网络和系统管理方面的咨询服务。
Greg Page是Cisco公司售前数据中心架构团队的解决方案架构师。Greg在 IT界已经工作了16年（近11年在Cisco公司），从事过各种技术顾问工作，专攻数据中心架构和技术，以及服务供应商的安全性（他的CISSP证书编号是77673）。
关于技术审稿人
Krishna Arji是Cisco的高级经理。在这个岗位上，他负责开发各种技术来支持Cisco服务部门的工作。Krishna在Cisco的服务技术集团的众多岗位上都有过工作经历。最近他在云规划、设计和实现服务的交付所需要的技术评估和开发中承担了关键角色。在他的领导下，他的团队已经开发出多种工具来执行客户基础设施的路由、交换、数据中心、安全性以及 WLAN 评估。他的专业领域包括：网络、软件设计和开发、数据中心技术（例如虚拟化）。Krishna拥有电子通信工程学士学位，以及企业软件技术硕士学位。他的一项关于存储区域网络自动评估的 USPTO 专利正在审批当中（序列号13/115,141）。
Eric S. Charlesworth是Cisco公司的WW数据中心/虚拟化和云架构组织的技术解决方案架构师。Eric在数据中心/网络领域有20年以上的经验，目前专攻云计算和数据中心管理。在此之前，他在南方贝尔和IBM担任过各种技术岗位的领导工作。Eric也是云凭据委员会（www.cloudcredential.org）评审委员会成员，协助开发和审批该项目的有关材料，他还是云挑战（www.cloudchallenge.com）的成员。作为技术编辑，Eric为Pearson Education和Van Haren Publishing出版公司提供编辑/评审服务。
献辞
Venkata（Josh）Joysula，感谢我的家庭、同事、我的管理团队提供的所有支持。
Malcolm Orr，感谢所有支持我的同事，感谢我的父母。
Greg Page，感谢Cisco公司的同事的支持，感谢我的家庭和朋友。感谢你们多年的支持和爱。
致谢
Venkata（Josh）Joysula，感谢我的家人给我的支持，感谢我的经理 Sunil Kripalani的鼓励。另外，还要感谢审稿人Krishna Arji和Eric Charlesworth。感谢Charles Conte（目前在 Juniper工作）、Jason Davis、GopalRenganathan、Manish Jain、Paul Lam以及其他许多DV/V项目的项目成员。还要特别感谢Cisco Press的Chris、Mary Beth和Mandie。
Malcolm Orr，感谢 James Urquard关于云成熟度的建议。感谢Aaron Kodra的支持，以及我的同事们的支持。
Greg Page，感谢 Cisco同事们的支持，尤其我的合著者Malcom和 Josh，还有 John Evans、Thomas Reid、Eric Charlesworth、UweLambrette、WouterBelmans；以及我在Cisco早年的同事Mark Grayson。最后要感谢Wendy Mars给我机会和自由，让我可以钻研“云/IaaS”这一课题。第1部分 虚拟化管理和云计算环境简介第1章 云计算概念
本章介绍虚拟化和云计算的概念。虚拟化和云计算密不可分，且厂商和解决方案供应商越来越多地使用虚拟化来构建云。本章将讨论各种虚拟化和云计算的类型，讨论从现场计算转换为云计算的获益。本章还将讨论在云端可以提供的服务类型，例如软件即服务（SaaS）、平台即服务（PaaS）以及基础设施即服务（IaaS）。另外，本章还将讨论云采用及云影响、云计算的投资回报（ROI）以及云获益。本章完成时，您将能够了解下列内容：
■虚拟化和虚拟化类型；
■云计算和云计算类型；
■云服务模型；
■云采用和云影响；
■云投资回报（ROI）和获益。1.1 虚拟化
如今，虚拟化已经成为一项技术必需品，且因为合理的理由这一趋势仍在持续发展，因为在实施虚拟化之后，可以获益颇多，例如：
■按需访问服务器、网络和存储资源；
■节能环保，实现绿色地球；
■减少占用物理空间；
■节省难以发现的人力资源；
■削减资产成本和运营成本。
这些节约金额可能非常巨大，因企业规模而有所不同。
虚拟化用于创建操作系统、计算设备（服务器）、存储设备或网络设备等资源的虚拟版本。服务器虚拟化打破了一台物理服务器只能运行一个操作系统的传统模式，采用虚拟机监控程序技术在一台物理服务器上创建多台虚拟机。云计算和虚拟化的概念经常互换使用，但这样混淆两种概念是不正确的。例如，服务器虚拟化提供了支持云计算所需的灵活性，但这并不能使虚拟化等同于云计算。需要多种支撑技术才能实现云计算，虚拟化不过是其中的一种技术；而且，对于云计算来说，虚拟化并非是必需品。例如，谷歌（Google）及其他厂商已经演示了不使用虚拟服务器的云服务，它们使用其他技术实现了类似的结果。本章将在稍后进一步阐释云计算。
我们很难定义虚拟化，因为它有很多方面。通常，虚拟化具有一种一对多或多对一的两面。在一对多方式中，虚拟化支持用一个物理资源创建出多个虚拟化资源。这种虚拟化允许数据中心最大化地利用其资源。承载应用的虚拟资源被映射到物理资源中，从而实现服务器资源更高的利用率。
在多对一方式中，虚拟化支持从多个物理资源创建一个虚拟（逻辑）资源。这种情况在云计算中尤为常见：多个物理资源组合在一起，构成一个云。正如先前所述，虚拟化并不是云，它只是建立和管理云的一项支撑技术。此处的虚拟化指的是操作系统虚拟化（例如由VMware、Xen或其他基于虚拟机监控程序的技术提供支持）。在Cisco的云概念中，虚拟化的概念进行了扩展，将各种类型的虚拟化囊括在内，例如网络、计算、存储以及服务。这些类型将在下一节进行介绍。
可以将虚拟化定义为一个抽象层，它可以存在于整个IT堆栈或其中的某个部分中。换句话说，从数据中心和IT的角度，可以将虚拟化重新表述为：“一组技术功能的实施过程，这个过程能将服务器资源、网络资源、存储资源的物理特征隐藏起来，以避免系统、应用或给端用户与这些资源的交互。”1.1.1 虚拟化类型
对不同的人而言，虚拟化可能具有不同的涵义。本章将讨论下列虚拟化类型：
■服务器虚拟化；
■存储虚拟化；
■网络虚拟化；
■服务虚拟化。
图1-1所示演示了一个数据中心可能拥有服务器虚拟化、网络虚拟化、存储虚拟化以及服务虚拟化，并使用虚拟化工具对其进行管理。可能还有其他类型的虚拟化，但此处将介绍数据中心虚拟化技术的起点。图1-1 虚拟化类型1.1.2 服务器虚拟化
服务器虚拟化（也称为硬件虚拟化）是当今最广为人知的硬件虚拟化应用。如今，强大的x86计算机硬件旨在运行单一操作系统和单一应用。这使得无法有效利用大多数机器。虚拟化允许在一台物理机器上运行多台虚拟机，在多个环境之间共享单台计算机的资源。不同的虚拟机可以在同一台物理计算机上运行不同的操作系统和多个应用。图1-2对比了虚拟化服务器和非虚拟化物理服务器。
虚拟机监控程序软件创建的虚拟机（VM）模拟物理计算机的环境，创建的独立操作系统环境，在逻辑上与主服务器隔离。虚拟机监控程序也称为虚拟机管理器（VMM），它是一个计算机程序，允许多个操作系统共享单一硬件宿主。单一物理机器可以用来创建多个虚拟机，多个虚拟机可以同时而独立地运行多个操作系统。虚拟机以文件形式存储，因此在恢复故障系统时，只要将虚拟机的文件复制到新机器上即可。图1-2 服务器虚拟化
服务器虚拟化的关键获益
■分区
■在一台物理机器上运行多个操作系统。
■在虚拟机之间划分物理系统资源。
■虚拟机并不知道存在其他虚拟机。
■管理
■一台虚拟机发生故障不会对其他虚拟机造成影响。
■管理代理能够在每台虚拟机上独立运行，以便确定每台虚拟机的性能以及在这台虚拟机上运行的应用。
■封装
■可以将整个虚拟机状态保存在一个文件内。
■移动和复制虚拟机信息如同复制文件一样简单。
■灵活性
■可以配置任何虚拟机并将其迁移到任何物理服务器上的相似机器上。
■使用多个操作系统平台，例如Windows和Linux。
■无需中断虚拟机，便可修改虚拟机配置。
在任何数据中心聚合项目中，服务器虚拟化都是减少物理服务器数量、从而减少物理空间占用、制冷、电缆以及资本费用的关键驱动因素。1.1.3 存储虚拟化
存储虚拟化指的是为物理存储设备提供一个逻辑、抽象的视图。它为许多用户或应用提供了一种访问存储的方式，用户或应用在访问存储的时候，无需担心存储的物理位置和物理管理方式。存储虚拟化能够使一个环境中的物理存储在多个应用服务器间进行共享，虚拟层后的物理设备看起来还像是一个没有物理边界的庞大存储池并对其加以管理。存储虚拟化将所有设备综合在一个设备中进行使用，从而隐藏了一个组织内有多个独立存储设备的事实。虚拟化隐藏了寻找数据存储位置、获取数据、向用户提供数据的复杂过程。
通常情况下，存储虚拟化适用于更大型的存储区域网（SAN）阵列，但也精确地适用于本地桌面硬盘驱动器上的逻辑分区和独立冗余磁盘阵列（RAID）。长期以来，大型企业已经从SAN技术中获益，在SAN中，存储与服务器解耦，直接连接到网络上。通过在网络上共享存储，SAN可以实现可伸缩且灵活的存储资源分配、支持高效的备份解决方案、实现更高的存储利用率。
存储虚拟化可提供下列好处。
■资源优化：在传统情况下，存储设备物理地连接到服务器上，并专用于服务器和应用。如果需要更多存储容量，则需要购买更多磁盘并将其添加到服务器上，并专用于应用。这种运营方式造成未利用或浪费大量存储。利用存储虚拟化技术，可以按需获取存储空间，而不会浪费任何空间，组织还可以更高效地利用现有的存储资产，而无需购买额外的存储资产。
■运营成本：为每台服务器和应用添加和配置独立的存储资源需要耗费大量的时间，并且需要许多技术娴熟的专业人员，而这些人又很难找到。这些都会影响整体运营成本（TCO）。存储虚拟化支持在应用之外添加存储资源，运营人员只需在管理控制台采取拖放操作就可以将存储资源添加到存储池中。带有图形用户界面的安全管理控制台可以提高安全性，允许运营人员方便地添加存储资源。
■提高可用性：在传统的存储应用中，因为维护存储设备、升级软件而导致计划内停机时间，以及由于病毒和电源问题造成的计划外停机时间，都会造成客户无法使用应用。这种停机会导致无法实现对客户做出的服务等级协议（SLA）承诺，从而引起客户不满以及客户流失。存储虚拟化能够在最短时间内配置新的存储资源，从而提高资源的整体可用性。
■提高性能：许多执行单一任务的系统会压垮单一存储系统。如果通过虚拟化将工作负荷分布到多个存储设备，那么就可以大大提高性能。另外，还可以在存储上实施安全监控，例如只允许经过授权的应用或服务器访问存储资产。1.1.4 网络虚拟化
网络虚拟化可能是所有虚拟化类型中最具有歧义的一种虚拟化。网络虚拟化有多种类型，简要描述如下。
■VLAN 是网络虚拟化的一个简单示例。VLAN 允许将一个局域网逻辑地划分到多个广播域内。按照交换机端口定义 VLAN。也就是说，您可以选择将端口 1～10加入VLAN 1；端口 11～20加入VLAN 2。同一VLAN中的端口无需保持连续性，因为这是逻辑划分，并不是物理划分，所以连接到这些端口上的工作站不需要处于同一位置，居于建筑物不同楼层的用户可以连接在一起以便构成一个局域网。
■虚拟路由和转发（VRF），通常用于多协议标签交换（MPLS）网络，允许一个路由表的多个实例同时并存在同一路由器内。因为无需使用多台设备就可以划分多个网络路径，这可以大大提高路由器的功能。因为流量自动进行分离，VRF 还提高了网络的安全性，并能消除加密和认证的需求。
■网络虚拟化的另一种形式就是将多个物理网络设备聚合到一台虚拟设备中。该虚拟化的示例有：Catalyst 6500交换机的虚拟交换系统（VSS）特性。这一特性将两个独立的机箱虚拟地组合成一台更大、更快的Catalyst交换机。
■虚拟设备上下文环境（VDC），这是一个数据中心的虚拟化概念，可以用来虚拟化设备本身，使物理交换作为多台逻辑设备呈现。在这个VDC内，可以包含自己独有、独立的VLAN和VRF集合。可以给每个VDC分配物理端口，从而将硬件数据层也虚拟化。在每个VDC内，独立的管理域来管理VDC本身，从而将管理层本身也虚拟化。对于与VDC连接的用户，每个VDC看起来都是唯一的设备。
虚拟网络（VN）代表着基于计算机的网络，至少有一部分由VN链接构成。VN链接不包含两种资源之间的物理连接，但使用网络虚拟化的方法实施了虚拟连接。开发Cisco VN链接技术以便桥接服务器管理、存储管理以及网络管理领域，从而确保在一个环境内所做的更改会传递到其他环境。例如，当用户在VMware vSphere环境中使用vCenter初始化VMotion，以便将虚拟机从一台物理服务器转移到另一台物理服务器时，这个事件就会传递给数据中心网络和 SAN，于是相应的网络配置和存储服务也会随着这台虚拟机一并转移。
图1-3演示了虚拟网络、虚拟计算、虚拟存储如何在基础设施中进行相互交互。图1-3 网络虚拟化
从广义上讲，如果设计得当，网络虚拟化会与服务器虚拟化或虚拟机监控程序类似，即用户、应用、设备之间能够安全地共享通用的物理网络基础设施。1.1.5 服务虚拟化
数据中心的服务虚拟化指的是提供额外安全性的防火墙服务、提供额外性能和可靠性的负载均衡服务。虚拟接口——通常称为虚拟 IP（vIP）——对外公开，对外表现为实际的Web服务器，并按需管理进出Web服务器的连接。这样负载均衡器就能将多个Web服务器或多个应用作为单一实例来进行管理，与允许用户直接连接到每个Web服务器相比，这种做法可以提供更安全、更健壮的拓扑。这是一种一对多的虚拟化表现方式。对外表现为一台服务器，实际隐藏着反向代理设备后的多台服务器的可用性。1.1.6 虚拟化管理
虚拟化管理指的是协调虚拟资源的配置和协调，以及对资源池和虚拟实例进行运行时协调。该特性包括虚拟资源到物理资源的静态映射和动态映射，还包含整体的管理功能，例如容量管理、分析、收费以及SLA。
图1-4所示演示了网络、计算、存储如何与管理/调配层进行交互，从而能够近实时地提供服务。通常情况下，服务被抽象到客户门户层，客户在其中选择服务，然后通过各种域和中间件管理系统，配合配置管理数据库（CMDB）、服务目录、会计、收费系统、SLA管理、服务管理、服务门户等，自动配置服务。图1-4 管理虚拟化
网络、计算以及存储虚拟化，由于提供了灵活而容错的服务，与固定技术资产解耦，正在对IT产生重大影响。我们再也无需空出维护窗口和离线应用，就能服务和升级底层硬件。无需维护窗口，就能维修和更新硬件，并将应用转移回到增强的基础设施中。虚拟化的其他获益还包括更高效地利用过去未充分利用的资源、减少受管硬件资产以及整合硬件维护协议。
虽然虚拟化带来出色的灵活性，但它同时也增加监控和管理服务的需要，以便提供更强大的态势感知。过去，管理员可以确定地表述：“我的数据库在服务器 X 上运行，这台服务器与交换机 B 进行连接并使用存储阵列 C。”虚拟化解耦了这种关系，支持以更具伸缩性、以性能为中心的方式利用这些基础设施资源。应用可以位于服务器集群中的任何计算节点上，可以利用任何存储设备上的存储空间，可以使用虚拟网络，也可以进行转移以满足性能或运营需求。如今，在进行维护之前，理解这种依赖关系愈发重要。
那么，虚拟化和云计算之间的区别是什么？这是一个常见的问题。答案很简单。虚拟化是一项技术，在虚拟机中运行软件时，通过虚拟机监控程序运行程序指令，就像在专用服务器上运行一样。虚拟机监控程序是服务器虚拟化的核心和灵魂。云计算则是一种运营模型。在运行云的时候，没有数据必须通过的虚拟机监控程序层。要拥有云，可能需要有服务器虚拟化，但仅有服务器虚拟化并不能运行云。在云中，包含的资源被抽象出来，在多租户的环境中根据需要和规模向客户提供服务。云所包含的技术也是这样得到利用的。多数情况下，云计算中都使用相同的基础设施、服务目录、服务管理工具、资源管理工具、调配系统、CMS/CMDB、服务器平台、网络布线、存储阵列等。通常情况下，会向客户提供一个自助服务门户，客户在门户上可以订购服务，门户隐藏了基础设施以及管理的所有物理复杂性。下一节将进一步介绍云计算的细节。1.2 云计算
云是目前最热门的词汇，业内所有人都可以定义云。我们认为，美国国家技术和标准学会（National Institute of Technology and Standards，NIST）提供的云定义最为简单。
云计算是一种模型，它支持方便、按需地通过网络访问可配置计算资源（例如网络、服务器、存储、应用和服务）的共享池，可以在尽可能不需要管理工作或服务供应商交互的情况下快速提供和发布这些可配置计算资源。
Gartner对云定义如下：
一种计算风格，利用互联网技术向多个外部客户提供大量可扩展的IT相关的功能。
那么，到底什么是云计算？从“公用事业”的角度而言，可以将云当成第四种公用事业（排在水、电、电话之后）。正如我们和其他许多人所相信，这正是云计算的终极目标。请考虑一下电和电话（公用事业）服务。我们回家或上班的时候，我们只要插上插头，就可以想用任意度数和任意时间长度的电量，而无需知道是怎么发电的或供应商是谁（我们只知道每个月底要为消耗的电量付费）。电话也是如此，我们接上电话线，进行拔号，想谈多久就谈多久，并无需知道通过哪类网络或哪些服务供应商进行转换。如果将云作为第四种公用事业，我们插上显示器就可以得到无限的计算资源和存储资源，想用多久、想用多少都可以。当互联网到了下一阶段——云计算阶段时，我们会将计算任务分配给“云”，即通过网络访问的计算、存储以及应用资源的组合——我们不再关心我们的数据的物理存储位置，也不关心服务器物理位置，我们只是在需要它们的时候才使用它们（并为它们付费）。云供应商通过能够通过Web浏览器进行访问互联网交付应用，同时业务软件和数据存储在远程地点的服务器上。多数云计算基础设施都包含通过共享数据中心提供的服务。云看起来是一种为满足消费者计算需求的单一访问点，许多云服务供应商在云上提供带有指定SLA的服务产品。
当我们为自己要处理的任务指定所需要的确切计算功能、数据或应用数量之后，云会为我们提供惊人的灵活性。因为我们不需要自行投入大量资本，所以云服务非常便宜，而且，由于拥有可靠的数据中心和基础设施，所以云服务很可靠。我们将能够“将插头插入”云，而无需在自己的硬件上安装软件。表 1-1 所示为云的一些关键特点和功能。表1-1 云的关键特点和功能
表 1-2 概括了各种云部署模、它们的特征以及每种模型的简要说明。表1-2 云交付模型1.2.1 服务模型
图 1-5 显示了服务模型和交付模型。所有服务均可在任何一种云交付模型中进行交付。图1-5 服务交付模型（资源来源：NIST）
表1-3简要说明了各种服务模型。表1-3 云服务模型
图1-6显示了上述服务模型和IT基础结构，以及主要的厂商。对服务的进一步描述，请参阅后面的列表。图1-6 服务模型和主要厂商
下面简要描述了图1-6所示的SaaS、PaaS和IaaS服务。
■软件即服务（SaaS）：SaaS在IT业内非常普遍。一般来说，软件公司提供托管他们软件的 SaaS，然后为客户更新和维护这个 SaaS。云中的 SaaS 在云内结合了这一托管实践，使软件在云中运行，而无需在企业的本地机器上安装软件，从而满足企业的业务需求。这一功能是通过运行在云基础设施之上的供应商的应用向消费者进行提供。可以通过各种客户端设备（从瘦客户端界面，例如Web浏览器）方便地访问这些应用（例如基于Web的电子邮件）。对于消费者而言，底层的云基础设施，其中包括网络、服务器、操作系统、存储、甚至每个应用的功能，都是透明的，惟一的例外可能就是特定于用户的应用配置设置比较有限。SaaS 的主要厂商包括Cisco（WebEx）、Microsoft、Google以及Salesforce.com。
■平台即服务（PaaS）：从计算的术语讲，平台通常指的是支持软件运行的硬件架构和软件框架（包括应用）。计算领域的常见平台有：Linux、Apache、MySQL以及PHP（LAMP）堆栈。运行在云上的 PaaS 向用户提供这些熟悉的平台堆栈，使用户摆脱购买和管理底层软硬件的成本和复杂性，从而方便地部署应用。PaaS 产品通常通过提供并发管理、可缩性、故障转换、安全性，从而使众多地并发用户能够使用应用。消费者并不需要管理或控制底层的云基础设施，其中包括网络、服务器、操作系统或存储，但能控制部署的应用，可能还会控制应用托管环境的配置。PaaS的主要厂商包括 Cisco（WebEx连接）、Amazon Web服务、Google和Windows Azure。
■基础设施即服务（IaaS）：当谈到基础设施时，人们想到是网络设备、服务器、存储设备、连接、空调系统等项目。但在购买云基础设施时，以上部件都不是必需品；相反，用户在使用基于云的基础设施时，只需要关心如何去开发平台和软件。云向消费者提供的IaaS功能包括网络、计算和存储资源。消费者能够在IaaS上部署和运行任意软件，其中可以包括操作系统和应用。消费者并不管理或控制底层的云基础设施，但能控制操作系统和部署的应用。云IaaS的主要厂商包括Telstra、AT&T、Savvis、Amazon Web服务、IBM、HP和Sun等。
IT的基础性硬件和软件资源包括构成网络的项目，即交换机、路由器、防火墙、负载均衡器等；服务器和存储设备以及软件。通常情况下，IT基础由多个厂商的设备和软件构成。提供IT基础性硬件和软件的主要厂商包括Cisco、HP、IBM、Dell、VMware、Red Hat和Microsoft等。1.2.2 云采用和云影响
多数公司的CxO级高管不再需要别人向他们兜售云的好处，他们都非常清楚。他们知道云计算可以大大简化操作和使用、降低成本、提高效率，但他们对云仍然有所顾虑。
各种调查的数据表明，影响IT人员采用云的关键因素是安全性和集成。虽然完全性和集成问题是人们对云计算的最大担心，但这些顾虑并没有妨碍企业在自己的公司内部实施基于云的应用。因为认识到云的好处、尝到云计算实施方便、安全性方面的功能以及成本节约的甜头，70%使用云计算的IT决策者正计划在未来的12个月内将更多的解决方案到云。
根据对客户进行的多次研讨与调研，下列安全性和集成问题似乎是多数客户最关注的问题。
■云如何保护数据安全、如何保持数据可用。
■如何满足当前和日后的安全及风险管理合规性要求。
■云都提供了何种的安全服务。
■如何对云的安全性执行内外部审计。
■如何自动提供网络、计算和存储。
■如何近实时地按需向客户门户提供向所有基础设施设备发出的需求。
■如何协调众多的新兴云工具和现有的旧工具。
虽然许多调查表明，多数客户都关心安全性和集成的问题，但多数成功的组织都会仔细计算风险，并在实施云的时候采用合适的安全措施。众所周知，没有人能够确保100%安全，但是，了解自己当前的状态，就可以应用合适的安全措施，既消除风险，又发展业务。关于安全性和集成的更多细节，将在后续章节继续讨论。1.2.3 投资回报和云获益
Amazon Web 服务发布的容量/利用率曲线显示了投资回报。
图 1-7中的容量/利用率曲线示例显示的是典型的数据中心和云 IT IaaS按需服务的资源使用情况。因为在生命周期早期存在不必要的资本开支，所以存在闲置容量，而在生命周期后续又出现资源短缺。如果没有云 IT IaaS，计划的资源要么因为实际使用率低于计划资源量而浪费，要么没有足够资源满足客户需求，引起客户不满和客户流失。
图1-7清楚地表明云IaaS为何有利于防止资源的过度供应或者供应不足，从而提高成本、收益和毛利，并提供必需的资源匹配客户的动态需求。利用云IaaS，资源的供给能够符合需求曲线（参见图1-7所示的曲线），既不浪费资源也不缺乏资源。
根据容量/利用率曲线和云IaaS的技术优点，可以将云IaaS的经济获益概括如下。
■按使用情况为资源付费。最终用户的投资成本只包括连接期间的成本，没有前期成本。
■基础设施设备的抽象通常由云供应商完成，最终用户没有锁定到任何物理设备。最终用户只在使用的时候才能通过按需要的基础设施。
■最终用户按需获取服务，服务规模可大可小，没有规划的成本，也没有物理设备的成本。提供基础设施的云供应商还可以从充分利用自己设备的闲置容量而获益。
■最终用户可以从任何地方不受限制地访问应用、计算和存储。
■最终用户可以使用的容量不受限制，同时性能保持不变，只受双方达成一致的SLA影响。
从 Open Group的白皮书“从云计算实现投资回报”可以了解有关投资回报分析的更多细节信息。图1-7 容量利用率曲线（资料来源：AWS4）1.3 小结
虚拟化已经在大多数企业环境和服务供应商环境中有了一席之地，IaaS形式的云服务在大型企业环境和一些服务供应商环境中也发展到了某种程度。虚拟化技术支持用多个物理资源创建虚拟（逻辑）资源。虚拟化可以在计算（服务器）网络、路由器和交换网络、存储网络、防火墙和负载均衡服务上实施，对虚拟资源的管理可以使用管理工具进行，例如供给、调配以及中间件工具。云计算和虚拟化经常互换使用，但这是错误的。例如，服务器虚拟化提供了云计算需要的灵活性，但并不能因此使虚拟化等同于云计算。实现云计算需要许多支撑技术，而虚拟化不过是其中之一。
云计算是对底层应用、信息、内容、资源的抽象，从而可以以更具弹性、按需使用的方式提供和消费资源。这种抽象也使底层资源更容易管理，并为应用本身更高效的管理提供了基础。通过云，无需任何前期资本成本投入，就可以立即访问硬件资源。仅此一点，就足以激励许多企业和服务供应商转移到云，因为这样可以提供更快的投资回报。1.4 参考资料
1 NIST对云计算的定义，http://csrc.nist.gov/groups/SNS/cloud-computing。
2 Gartner对云计算的定义，http://www.gartner.com/it/page.jsp?id=707508。
3 www.mimecast.com/News-and-views/Press-releases/Dates/2010/2/70-Percent-of-Companies-Using-Cloud-Based-Services-Plan-to-Move-Additional-Applications-to-the-Cloud-in-the-N ext-12-Months。
4 Amazon Web服务，AWS Economic Center，http://aws.amazon.com/economics。
5 Open Group 的白皮书《从云计算实现投资回报》，www.opengroup.org/cloud/whitepapers/ccroi/index.htm。第2章 云设计模式和用例
本章概述构成云部署的各个部分，重点放在基础设施即服务（IaaS）的服务模型。本章完成时，您将能够了解下列内容：
■当今多数企业中的应用程序设计模式及业务功能；
■对于指定的设计模式，哪种部署模式最合适；
■典型的云用例；
■SaaS和PaaS服务如何利用Iaas提供更好的灵活性和管理一致性；
■如何描述IaaS构成其他云服务模型的基础；
■云使用者的运营模型。2.1 典型设计模式和用例
第1章讨论了云的标准定义，并在一定程度上解释了云计算成为使用者和供应商的一股重要技术力量的原因。从云服务的使用者角度看，可以认为云的所有服务模型（基础设施即服务[IaaS]、平台即服务[PaaS]、软件即服务[SaaS]）都算不上是新的服务，云本身并没有引入任何新的设计模式或软件。相反，应该将云看成以更加动态的方式使用计算、存储、网络以及软件资源的一种新方法。从云供应商的角度来看，云服务模型是供应商提供服务的新方式，能够以更加动态的方式提供定义良好的解决方案，并按服务的使用情况收费或计费。通过这种方式，这些服务的使用者可以为他们的产品和他们使用IT的方式实现不同的业务模型。
从使用者的角度出发来看一个示例。使用者A想部署一个服务来托管内容，具体用什么服务不限。他可以在新的托管合同中购买这项服务，托管服务只是给他提供了一个空间，用来上载文件和管理内容，并按月对空间收费。对内容的修改几乎可以实时进行。但是，如果使用者需要增加服务器端处理，或者增加后台数据库来存储数据，那么他可能不得不等待几天，等候供应商修订合同，向他目前的服务中添加这些功能。在这个示例中，不是按Web服务器的活动对服务使用者计费，签署的合同通常要求按半年或一年付费。
或者，您可以从 Amazon（EC2）购买一个虚拟实例，提供一个具有 CPU、内存、硬盘大小的基本机器，部署一个标准的Web服务器映像，然后根据需要修改内容。如果需要额外的功能，则可以部署额外的软件或实例。如果您不再需要这些内容，那么可以销毁实例，并停止付费。
传统托管模型和云之间的主要区别是：按照使用者实际使用的服务收费，而不是按固定费率收费。如果Web托管服务不忙，那么使用者可以少付些钱。所以，云在这种情况下实际上并没有提供什么新服务。服务仍然在托管中，但服务和使用模型发生了变化，允许使用者花同样的钱做更多的事情。更典型的示例就是内容供应商Netflix，为了满足预期的需求，它用Amazon来托管自己的平台。这意味着Netflix几乎能够实时地扩充它的容量，将对业务的中断降到最小。如果它需要增加更多物理容量，或者需要重新谈判现有的托管合同，就不能在需要提供服务时候满足客户需求。所以，云本身并没有使可以做到的事情增加，但确实改变了实际能做到的事情。
那么，什么是IT服务呢？IT服务有许多定义，但对本章来说，我们将IT服务定义为按特定拓扑方式组织起来的IT资源集合，以提供和支持特定的业务功能。首先应该对将某个服务转移到云的决策进行评估，确保云能够支持所需的拓扑，并且业务能够承担由云承载的风险。而且，还需要评估云的哪种部署模型最适合计划采用的云用例。2.1.1 设计模式
图2-1显示了在当今大型企业的应用程序基础上发现的典型设计模式。图2-1 典型的设计模式
在多数大企业中，都会对应用程序进行分层：从安全的角度将表示、应用程序和数据分解到数据中心内的不同平台上。因此在最低程度上，一个云解决方案（IaaS）必须支持区域划分（zoning）的概念，即允许不同的虚拟机在不同的安全区域或可用区域中存在，以满足应用程序分层的需求。在一个层内，还会有不同的设计模式为不同的问题提供解决方案。
■负载均衡器：有许多实例/工作程序执行相同的作业，由负载均衡器在这些实例/工作程序之间对作业的请求进行分配，并由负载均衡器将响应发回请求者。在所有三个分层中都可以看到这个设计模式，在实现网站和业务应用程序时经常用到。
■分配器与搜集器：可以将一个请求分解成多个独立的请求，然后在多个程序间分配，最后将多个工作程序的反应汇总后再返回请求者。搜索引擎经常使用这种模式，另外在应用程序层和数据库层经常看到这一模式。
■缓存：在使用负载均衡器模式或者分配器与搜集器模式分配请求之前，先查看缓存，缓存中存储了之前完成的所有查询。如果在缓存中没有发现匹配项，则向工作程序发出请求。这一设计模式在所有三层中都很常见。
■任务调度：智能化的调度程序根据当前的负载、趋势或者预测，在工作程序集合上启动任务。任务采用并行方式处理，输出结果传递到输出队列进行搜集。这个设计模式通常在应用程序层间使用。
■其他：随着技术的发展，类似MapReduce、黑板之类的设计模式可能会流行起来。本书无意预测哪些设计模式会在云中获得成功。但可以看清的是，当负载要求对系统规模进行横向扩展的时候，IaaS是承载此类设计模式的出色平台。
使用“基础设施容器”是其他设计模式的一个良好示例。例如，VMware 描述了这样的一种虚拟数据中心：“vCloud 虚拟数据中心（vDC）是对资源（例如网络、存储、CPU 和内存）的一种分配机制。在 vDC 中，计算资源完全虚拟化，可以根据需求、服务级别要求或者二者的组合来分配这些资源。有两种vDC。
■供应商vDC：这些vDC包含vCloud服务提供商提供的所有资源。供应商vDC由云系统管理员创建和管理。
■组织vDC：这些vDC为存储、部署和操作虚拟系统提供了一个环境。它们还提供了虚拟介质存储，例如虚拟软驱和虚拟光驱。
组织的管理员规定如何将来自供应商vDC的资源分配给组织内的vDC。
Vmware的vDC为将特定于租户的拓扑复杂性（例如第2层隔离、防火墙）抽象出来提供了一个好办法，还为管理资源提供了方法。这一主题的一个变体就是 Cisco 的网络容器（Network Container），目前已经提交给OpenStack作为网络即服务的基础，网络容器对 IaaS 的服务模型进行了进一步的抽象，从而向最终用户隐藏复杂的网络拓扑，并在更大的设计模式中使用。在图2-2中可以看到实例化了三个负载均衡器设计模式。但是，负载均衡功能、第2层隔离和安全性以及第3层隔离，都是在一个网络容器内实例化的，而这个网络容器是在一套物理网络设备之上运行的。这样，应用程序开发人员就能专注于应用程序的功能，无需考虑网络拓扑实现的细节。开发出来的应用程序只需要它所在的虚拟机与具体网络容器内的具体区域连接即可，负载均衡、防火墙、寻址等工作均由网络容器处理。
了解大企业中目前正在使用哪些设计模式，可以更好地理解应用程序拓扑，更好地了解在云中支持这些拓扑所需要的基本构造块。但一个更大的问题是：我是否愿意冒险将应用程序及其数据转移到云中？图2-2 网络容器设计模式
Gartner定义了三类应用程序。
■记录系统：记录业务以及业务交互的数据。
■差异系统：使业务对外看起来不同，并使业务经营也不同。
■创新系统：可以为业务带来真正的价值。创新系统可以从云提供的弹性和快速配置能力中受益，但是数据的动态性以及未经过滤的本质，会使在企业边界之外托管这类应用程序显得不明智。
图2-3展示了这三类应用程序。图2-3 应用程序的功能分类2.1.2 云用例
那么，对于多数大型企业来说，现在有哪些还不现实，或者哪些成本不可接受呢？我们将以大型企业为主，因为它们最有可能采用私有云、公共云或混合云的解决方案。相比主流IT技术，多数云技术仍然相当不成熟，因此采用云解决方案的过程仍然是个冒险的过程。但是，如果采用云解决方案获得成功，企业会变得更加敏捷、投入产出比更高，从而取得实质性的回报。考虑到云市场目前的成熟度以及对安全性的考虑，大型企业在短期内还不会将关键业务应用程序部署到云（IaaS、PaaS）中。当然，目前围绕客户关系管理（CRM）以及销售工具的 SaaS 产品已得到广泛采用，但这些应用程序通常相当独立，不需要与现有业务流程或技术集成，因此采用起来也更简单。目前已经梳理出来的许多典型用例允许企业“试探性”地使用云（IaaS/PaaS/SaaS），并从中得到一些显著的商业收益。表2-1显示了在目前的大型企业中发现的典型用例。表2-1 云用例续表
公司开发和测试环境的设置及维护工作既要投入大量人力，又需要高昂的成本。应用程序开发和硬件更新的周期性意味着这些环境会在大部分时间中的使用率都很低，而在需要使用这些环境的时候，它们可能又过时了。虚拟化可以减少硬件更新的需求，因为您可以随时增加虚拟机的内存和CPU，而且可以相对平稳地在不同的硬件平台间迁移，但硬件仍然是必须的，而且使用率仍然不高。另外，如果企业面对的是工作时间没准的开发人员，他突发灵感，想起自己可以让公司的某个应用程序运行起来快 3倍，凌晨3点起来就要开始工作，但需要一台新的数据库服务器，这时该怎么办？云（IaaS和 PaaS）为企业提供了满足这些灵活性需求、按需自助服务需求和提高利用率的功能（至于使用哪种部署模型，私有云还是公有云，这些内容将在下一节讨论）。
业务持续性和灾难恢复对任何企业来说都是两个关键领域。可以将业务持续性视为允许客户、员工在任何时候都能访问关键业务功能的过程和工具，业务持续性主要包括技术支持、变更管理、备份以及灾难恢复。同开发和测试环境的使用率低下等情况一样，支持业务持续性过程的系统在业务运行正常的时候，利用率也会比较低；但是在出现故障的时候，利用率可能会极高。例如，技术支持部门可能会收到大量的请求。在出现重大停机或“灾难”的时候，将这些应用程序转移或切换到备用地点，确保用户仍然能够访问应用程序、提交问题或者访问备份数据，这些都是至关重要的。云明显能够通过虚拟化技术提高技术支持或变更管理软件的利用率，或者通过SaaS的“按使用付费”模式降低成本。IaaS支持创建特定应用程序的新实例，实现应用程序规模的横向扩充，从而解决 IaaS 支持的某些需求问题，还支持在出现故障的时候转移到备用公有云或备用私有云上的备份或备用应用程序，甚至可以在混合云模型中分解负载。
随着内部IT部门开始用共享服务模型来集中其功能、跟踪成本，并将成本分摊到不同的业务线或业务单元就变得越来越重要。如果服务转移到企业外由SaaS或IaaS供应商提供，那么根据使用情况来跟踪和分摊成本，就成为企业管理成本的一个关键功能。服务在云中托管（IaaS）意味着可以使用IaaS内在的机制来计算和呈现不同的收费、分摊和反馈数据。
桌面管理是大型企业中非常突出的问题，为了排除故障、修改和保护不同的桌面配置，需要部署大量的运营资源。虚拟桌面基础设施（VDI）的引入允许用户连接到集中管理的桌面，这种做法大家都清楚，在这里不再详细讨论，但云（IaaS）有助于桌面的自助管理、有助于新桌面的克隆，还有助于主映像的管理。另外，对于VDI资源的计费和收费也可以通过基于云的VDI解决方案来实现。
纯粹基于存储的服务（例如文件备份、映像备份以及.ISO存储）在任何一个大型企业中都是必需的，通常会占用多达几TB的空间。如果在业务线（LOB）或业务单元（BU）级别上购买和分配这些资源，会造成大量的资本开支以及严重的利用率低下。问题云（IaaS 的子集）解决方案可以实现更高的利用率，而提供的灵活性和自助服务程度与在单个LOB或BU上分配资源的灵活性和自助服务程度相同。另外，存储云还能利用其他云用例，例如灾难恢复和分摊，从而提供更加全面的服务。
按需计算服务是任何IaaS云的基础，不受用例限制。使用者想的只是提高业务的敏捷性，或者追加现有服务以满足需求，或者需要在指定期间内迅速实现对新业务的支持。所有IaaS用例对按需计算的支持都取决于云供应商的能力。但是，不能简单地认为单个问题的解决方案就是部署服务器虚拟化技术，如VMware ESX或Microsoft HyperV。许多应用程序无法或者不会虚拟化，所以在云产品中包含物理的按需服务需求经常被忽视。虽然提供物理服务器的做法不像提供虚拟服务器的做法那么普遍，但这是个必备的能力，它要求在虚拟机监控程序级别、物理服务器及其上的操作系统和应用程序不能满足需求的时候，具备提供物理存储和物理网络的支持能力。2.2 部署模型
本章目前讲的用例和设计模式既可存在于企业内部数据中心的私有云内，也可存储在通过互联网公共访问的公有云内，还可存在于电信运营商通过企业 IP VPN服务提供的私有访问的公有云内。第1章讨论了这些模型；表2-2描述了最流行的模型。表2-2 私有云和公共云
公共云或服务供应商提供的虚拟私有云，支持一套标准的设计模式和用例。例如，Amazon Web Service（AWS）EC2支持负载均衡设计模式，在单独一层内提供。通过可用性分区和自动伸缩，它支持按需计算、使用情况监控以及业务持续性这几个用例。但对特定用例的具体需求来说，还需要进行评估。公共云的一个关键原则就是使用共享基础设施在供应商自己的数据中心托管多个租户，并使用公共的安全模型提供租户之间的隔离。云的全部管理由供应商负责，使用者只需要按使用量付费即可。
私有云由IT部门构建和运营，所以支持内部使用者希望在整体的云参考模型中描述的任何用例。虽然多个业务线或业务单元可以使用相同的基础设施，但安全模型不需要像公共云那样复杂，因为云的基础设施在企业内部，数据通常也存储在企业内部。构建私有云时不需要企业构建大量的虚拟化、网络、存储、管理（以及其他）功能，也不需要已经具有的这么多功能，但构建私有云意味着企业可以完全地利用云，甚至有可能发展出新的收入机会或业务模型。另外，企业必须为支持云服务进行初始的基础设施投资，还要承担容量用尽、要增加新基础设施时的后续成本。
第三个选择是允许服务供应商构建私有云，并且运行的私有云托管在它的数据中心或放在企业内部。如果企业既想利用云服务，又不想投入太多，还要满足安全或合规要求，那么托管云是理想的解决方案。托管云与公共云不同，托管云的基础设施在正常的操作时间内是由特定租户专用的。在非高峰时段，可以将资源退回给服务供应商，这样可以对应用程序打折收费。但是，有些租户可能不喜欢在他们的数据中心上运行不同的工作负荷。托管云并不意味着企业不必构建或投资云功能中心，而且如果供应商提供公共云服务，那么也许还可以根据需要在低成本的公共云和成本较高的私有云之间来回迁移工作负载。图2-4演示了这一概念。图2-4 云部署模型和移动性2.3 以laaS为基础
迄今为止，我们已经从使用者的角度了解了构成云服务的组成部分，即在他们使用和部署云时可以考虑的用例、设计模式以及部署模型。第1章还介绍了不同的云服务模型：基础设施即服务、平台即服务以及软件即服务。本节介绍对于服务供应商来说，为什么IaaS是其他两种服务模型的基础，并描述IaaS在支持典型的用例和设计模式时所需要的组件。回顾第1章介绍的SaaS和PaaS定义是：
■SaaS：向使用者提供的，使用供应商在云基础设施上运行应用程序的功能。
■PaaS：向使用者提供的，在云基础设施上部署使用者创建或购买的且用供应商支持的编程语言及工具开发的应用程序的功能。
SaaS和PaaS都提高了供应商对于IaaS上的服务所承担的责任。如果供应商还需要提供实现基本云所需的自助服务特征和弹性，则有必要在IaaS解决方案上部署SaaS和PaaS，以便利用构成IaaS基础的功能、系统和过程。这并不意味着SaaS供应商或PaaS供应商必须先部署 IaaS。但是，如果先部署 IaaS，SaaS 和 PaaS，解决方集伸缩起来就会更容易。本节后面将从总体上介绍构成不同服务模型的组成部分。图2-5从使用者和供应商两个角度描述了组成部分。
图2-5的一个要点是：所有服务模型中都包含应用程序栈。从标准的定义角度来看，IaaS通常被当成纯粹的基础设施，所以服务器上不提供操作系统或应用程序，但在实践中，多数云供应商都提供应用程序即服务的选择。但是，在每种服务模型中应用程序的性质是不同的，分别描述如下。
■SaaS：使用者真正感兴趣的只是使用最终应用程序，所以内容和数据是最重要的。如果要使用多种设备（智能手机、笔记本电脑、平板电脑等）访问应用程序，那么应用程序的表示方式也会成为重要的影响因素。如果只是用不同的应用程序“皮肤”向不同的租户提供应用程序，那么元数据在这个层次上也有意义。
■PaaS：使用者感兴趣的主要是在这个环境内开发和测试应用程序，所以这里使用的应用程序可能是集成开发环境（IDE）、测试工具、中间件平台等。元数据方案在这里开发，操作系统（OS）以及必需的库也可以在这一层管理（可选）。
■IaaS：使用者感兴趣的主要是交付基础设施，以便他可以在这个基础设施上添加他负责的应用程序。根据服务的范围，这里的基础设施可以包括网络基础设施、操作系统以及基本的应用程序，例如Linux、Apache、MySQL和PHP（LAMP）栈。图2-5 组成部分总体视图
SaaS和PaaS都需要服务器、操作系统等基础设施才能支持服务用户使用的应用程序。随着服务供应商对这些应用程序的责任等级提高，以更有效的方式管理它们的需求也随之提升。以 SaaS 为例，尤其在应用程序本身并不支持多租户模式（例如，某个托管服务供应商想在某个IP电话解决方案之上提供某种形式的监控应用程序）时，可以看到，对于每个租户，都必须创建应用程序的新实例。手动进行这种操作对于服务供应商来说既费时又费力，所以使用IaaS解决方案快速部署新实例对于供应商来说有很大的商业意义。这还意味着需要有一个过程，以自动一致的方式来支持其他新的单租户应用程序、添加新实例来处理负载（横向伸缩）或修改现有应用程序的 vRAM 或vCPU来处理负载（纵向伸缩）。IaaS/PaaS解决方案的用户经常需要访问操作系统库、补丁、代码示例，还需要能够备份计算机或制作计算机的快照，这些对于任何IaaS解决方案来说都是关键的功能。在实现的时候，不应该直接构建这些功能，即不应该直接构建SaaS或PaaS功能，即使没有直接提供IaaS服务，也应该构建一个基础的IaaS层。这样做的话，架构会更灵活、更敏捷。以一致的方式构建基础设施，还意味着不论IaaS、PaaS、SaaS（以及三者的任意组合）使用什么样的基础设施，都能够用一致的方式进行管理、收费或计费。
云的使用者通常并不关心服务的实现方式或管理方式，他们只会要求供应商在他使用服务实例的生命周期内为服务水平、治理、变更、配置管理等负责，而不关心供应商管理的是基础设施、平台还是软件。因此，服务供应商需要以一致的方式管理服务的实现、保证以及收费/分摊。另外，如果供应商提供了不止一个服务模型（例如，SaaS+PaaS），那么理想的方式是用一个集成的管理栈来提供这些功能，而不是分散在不同的地方管理。
不论云使用者要求什么样的应用程序设计模式、用例或部署模型，为云选择的使用者运营模型都至关重要，运营模型构成了下一章讨论的云参考框架的基础。2.4 云使用者的运营模型
运营模型描述的是组织如何设计、创建产品，并向使用者推销和提供产品。在云的上下文环境内，运营模型描述的是云使用者如何向他的用户提供基于云的 IT 服务。图2-6所示的模型显示了云使用者角度的运营模型。对于云供应商来说，也存在类似的模型，显示的是供应商如何提供和管理云服务，但云供应商的模型要考虑众多不同的使用者和市场，因此更为复杂。图2-6 云使用者运营模型
所有运营模型的核心是了解云解决方案中承载的用例和设计模式。理解了用例和设计模式并达成一致后，必须解决以下几方面的问题。
■组织：当资源托管在企业外或第三方时，使用者如何组织他的IT功能以支持更多按需使用或公用模型。
■服务产品组合：哪些服务由内部提供，提供给谁，如何建立新的服务。
■流程：转移到效用计算时要修改哪些流程，要做哪些修改。
■技术架构：要支持议定的用例和部署模型，需要部署、修改或者购买哪些系统或技术。
■SLA管理：要向最终用户提供哪种服务水平协议（SLA），根据这个协议，组织和云供应商（对于私有云来说，可以是内部的IT部分）之间需要提供什么样的服务水平协议。
■供应商管理：要选择哪个云供应商或工具厂商，选择的标准，许可证的类型，以及要使用的合约模型。
■治理：使用者如何进行云决策、如何划分决策的优先级、如何管理决策，在引入效用计算模型时如何降低风险。
熟悉开放组架构框架（The Open Group Architecture Framework，TOGAF）架构开发方法（Architecture Development Method，ADM）的人可以看出图 2-6和ADM之间存在一些相似之处。这是有意而为之的，因为云更多的是业务的转变而不是技术的转变，所以后续章节介绍的运营模型和管理参考架构是云策略的关键组成部分。2.5 小结
云的采用首先是个业务的转变，然后才是技术的转变。在考虑采用某种云使用模型时，应该充分理解以下这些方面。
■需要在云中支持哪些设计模式和用例？
■哪个部署模型在遵守任何规定或安全要求的同时提供了最佳的商业优势？
要想回答这些问题，需要开发一个云运营模型，这涉及转变到效用计算时需要对组织、流程和技术进行的转变2.6 参考资料
1 NIST对云计算的定义，http://csrc.nist.gov/groups/SNS/cloud- computing。
2 开放组TOGAF ADM，www.opengroup.org/architecture/togaf8- doc/arch/chap03.html。
3 VMware vCloud API，www.vmware.com/pdf/vcd_10_api_guide.pdf。
4 Cisco网络容器@ Openstack，http://wiki.openstack.org/networkContainers。第3章 数据中心的架构与技术
本章概述了在数据中心中支持新一代实时管理 IT 服务用例所需要的架构原则和基础设施设计。有许多流程框架和技术可供架构师用来交付一个既有灵活性，又有伸缩性的服务平台。从运营的角度看，保持数据中心的可见性和控制，以满足公司的治理、风险以及合规等方面的需求，是必不可少的。本章讨论的组成部分、技术和概念既有助于简化设计和运营，又能给企业提供真正的IT价值，即业务的持续性和业务的变化。本章完成时，您将能够了解下列内容：
■如何清晰地描述“架构”在IT设计中的具体含义；
■描述数据中心的架构组成部分；
■描述数据中心网络设计的发展过程及虚拟化带来的冲击；
■描述云的基础设施即服务（IaaS）解决方案以及它的功能性组件；
■描述提供“端到端”服务水平协议所必需的网络服务。3.1 架构
架构是从其他行业借用的一个术语，这个术语在技术论坛中总是被广泛使用。牛津英语字典对“架构”的定义是“设计和建设建筑物的艺术或实践”，引申为“计算机或基于计算机的系统的概念结构和逻辑组织。”
一般来说，除了建筑领域，就很少有人能够正确地理解架构这个术语。虽然我们能够理解在建筑物中这个具体概念，也了解建造建筑物的过程，但许多人还是无法理解更加抽象的计算机或网络的概念，同样也不能理解构建服务平台之类的IT系统的过程。同建筑物一样，服务平台也有许多不同的类型，不同类型的平台是基于不同的架构原则建设和展现的。
作为早期的架构原则、需求/指南（也称为工件）的示例，图3-1描绘的是达芬奇的名画《维特鲁威人》。据说这幅作品是按照古罗马建筑师Marcus Vitruvius Pollio的理念绘制的，这位建筑师认为：“完美的建筑物”应该基于这样一个事实建造，即人体提供了“完美比例”，即，身体各部分之间长度的比例是固定的。人们相信，在设计建筑物的时候，可以将这些比例作为一套架构原则，因此，“完美的建筑物”是可以实现的。显然，我们今天对架构和设计的观点更基于科学。也就是说，《维特鲁威人》为架构与设计以及设计实现之间的关系提供了一个好例子。图3-1 达芬奇名画《维特鲁威人》（名字源于古罗马建筑师维特鲁威）
即使架构包含一些定义良好的活动，我们开始研究架构的定义时，仍然要在科学之外使用艺术一词。糟糕的是，从实用的角度来讲，这个定义太模糊。但是，这个间接定义告诉我们一件事：架构仅仅是事物构建过程中的一个部分。例如，在构建新的服务平台时，是为了实现某种目的构建的，在建成之后，应该具备某些必需的品质。
在向架构师描述“服务交付平台”的目的时，通常采用需求文档来描述要构建的平台目标和用途信息。架构师通常是拥有特定IT系统丰富构建经验的人，擅长构建可满足特定业务需求的IT系统，并擅长将业务需求转变成IT工程的需求。而主题专家（例如，服务器虚拟化工程师、网络工程师或存储工程师）则负责将高层的架构性需求解读为低层的设计，并最终实现（构建）一个可用的系统。图3-2显示了架构、设计和实现之间的多对一关系。注意，在所有利害干系人之间实现清晰的沟通和良好理解，在整个项目交付的各个阶段对于确保成功来说都是至关重要的。图3-2 架构决定了一个系统或服务的设计与实现
因此，架构主要用来向利害干系人沟通系统未来的行为，并规定了满足业务要求所需的组成部分（这个数据通常称为工件）。所谓利害干系人，通常是指为产品或项目买单，并使用最终成果的人。例如，利害干系人可以是未来服务平台的拥有者或者租户，也可能是公司所有者，或者是未来网络的用户。在系统实际构建出来之前，会频繁地使用架构蓝图向利害干系人介绍系统的各种属性。实际上，在介绍多种属性的时候，通常需要采用多个架构文档或多个蓝图。糟糕的是，架构图（通常是多张图）经常被错误地用作了设计图，或者错误地将设计图当成了架构图。
对于云服务来说，架构必须超越内部（私有云）部署，支持混合云模型（托管云、公共云、社区云和虚拟私有云等）。架构还必须考虑Web 2.0技术（使用者社交媒体服务）以及数据访问的普遍性（移动性）。
今天的服务平台要求的架构原则通常包含（但不限于）效用、伸缩性、可靠性、互操作性、灵活性、健壮性以及模块化。随着技术的发展，这些原则在解决方案中的设计和实现方式也在时刻发生变化。
对于架构的实现和管理来说，现在大量地采用流程框架和方法论来确保质量和及时交付，这里面会在业内公认的最佳做法上进行大笔投入。第6章将详细介绍各种框架。
在这里，有必要花些时间讨论一下从业务的角度来看，“IT 的价值”到底是什么。衡量IT投入的价值一直以来都不是一门精确的学科。后果就是：许多IT项目都没有能够实现它们的预期目标。因此，今天的许多CIO/CTO对于总体拥有成本（TCO）的准确性都没有太大信心，或者更远一点，对于与潜在IT投资有关的投资回报（ROI）模型没有太大信心。在业界合作伙伴的参与下，学术界开展了许多研究项目，试图寻找解决这一挑战的更好途径。
例如，创新价值学会（http://ivi.nuim.ie/ITCMF/index.shtml）与Intel合作开发了IT能力成熟度框架（IT-CMF）。基本上，IT-CMF提供了一个“能力成熟度曲线”（5级成熟度），并辅之以许多志在提高IT价值，最终使企业能够在市场上保持差异性或者持续发展差异性的配套策略。
能力成熟度这个概念源于自软件工程学会（SEI），该学会最先开发了称为能力成熟度集成（CMMI）的模型。除了前面提到的IT-CMF，组织还可以使用CMMI，从COBIT （信息及相关技术的控制对象）规定的IT流程的角度，明确自己与最优水平的差距和自己的位置，也可以从 ITIL（为 IT 服务管理提供的信息技术基础设施库）等最佳做法指南的角度，明确自己与最优水平的差距和自己的位置。第4章将详细介绍COBIT。3.2 数据中心的架构组成部分
数据中心的设计目前发展到了十字路口。海量的数据增长，严峻的经济状况，电源、温度、空间的物理限制，不断给企业带来沉重的压力。寻找一个能够将成本、复杂性以及相关风险从数据中心剥离出来，同时又能提升服务水平的架构，已经成为多数大企业的一个重要目标。所以请考虑企业的IT部门今天所面临的挑战。
数据中心的IT人员通常被要求解决以下数据中心挑战。
■提高资产利用率，减少或推迟资本开支。
■更好地管理工作负载高峰，从而降低资本开支。
■确保数据和资源实时可用，提供灵活性并能根据当前及未来业务敏捷性的需求进行调整。
■减少电源和空调方面的开支，削减运营成本，采用“绿色”企业的做法。
■减少现有/新服务的部署/调整时间，节约运营成本，赢得市场竞争优势。
■在架构中采用新的使用模型和新的抽象层，从而支持及增加创新。
■提高服务的可用性，避免或减少服务组件的意外灾难或故障对业务的冲击。
■采取一致而强健的安全姿态和流程来实现信息保障。
从这套挑战出发，可以推导出新服务平台解决上述挑战所需呈现的一整套架构原则（如表3-1所示）。这些架构原则又可以被映射成为一组支撑的技术需求。表3-1 支持架构原则的技术3.2.1 行业方向、运营阶段和技术阶段
新技术，例如多核CPU、多插槽主板、便宜的内存、外围组件互联（PCI）总线技术，代表了计算环境的发展。这些发展，在抽象技术（例如，虚拟机监视器[VMM]，也称为虚拟机监控程序[hypervisor]软件）之外，也为数字数据呈现指数性增长和互联网全球化的时代，提供了更优良的性能和更好的资源利用率。为使用这些资源而设计的多线程应用程序设计既要求更高的带宽，又要求底层基础设施提供更高的性能和效率。
在几年前，虚拟基础设施经历了几轮发展。基本的虚拟机监控程序技术（虚拟机监控程序/VMM内核中内置相对简单的虚拟交换机）已经让位于更加精密的第三方分布式虚拟交换机（DVS）（例如，Cisco Nexus 1000V），将虚拟服务器和网络的运营领域融为一体，提供了一致而且集成的策略部署。至于其他用例，例如虚拟机的实时迁移，则要求协调（物理的和虚拟的）服务器、网络、存储以及其他依赖项，以实现不间断的服务持续性。能力和功能用在何处需要仔细考虑。不是每个能力和功能都能在虚拟实体上找到理想的实例，因为性能或合规的原则，有些能力和功能可能就是要求使用物理的实例。所以下面我们将看到一个混合模型，在它的架构和设计中，对于每个能力和功能都要进行评估，以寻找理想的位置。
虽然数据中心的性能需求不断增长，但IT管理人员一直在寻找办法，通过提高当前资源的利用率来限制数据中心的物理扩张。通过服务器虚拟化实现的服务器聚合已经成为一个很有吸引力的选择。利用多台虚拟机全面利用物理服务器的计算潜力，实现对数据中心转移需求的快速响应。计算能力的这种快速提升，与虚拟机环境的使用增长，共同提出了对更高带宽的需求，同时给支持网络带来了额外挑战。
能耗和电源利用率仍是一些数据中心运营人员和设计师的首要考虑因素。数据中心的设施在设计时就有具体的电源预算，以每机柜多少千瓦（或者每平方尺多少瓦）表示。过去几年内，每机柜的能耗和冷却容量一直在稳步增长。服务器数量的增长和电子元件的发展，导致能耗呈现指数性增长。每机柜的电源需求制约着数据中心能够支持的机柜数量，即使数据中心仍有富余空间，也会出现容量不足。
目前有多个指标可以协助判断数据中心的运营效率。这些指标分别适用于不同类型的系统，例如，设施、网络、服务器、存储系统。例如，Cisco的IT部门采用每工作单元电源用量指标，而未使用每端口电源用量，因为后者没有覆盖某些用例：在邮件、文件、打印服务的可用性、电源容量以及密度配置方面，与关键任务的网站和安全服务相比会有很大差异。另外，Cisco的IT部门还认识到，仅仅网络一个指标并不能代表整个数据中心的运营情况。这是Cisco加入绿色网格（www.thegreengrid.org）组织的原因之一，该组织致力于开发出适合整个数据中心的电源效率测量指标。“The Green Grid Metrics: Describing Data Center Power Efficiency”文档中详细描述的电源使用效率（PUE）和数据中心效率（DCE）指标，是开始应对这一挑战的途径。典型情况下，数据中心耗电最大、电源效率最低的系统就是机房空调（CRAC）。在本书编写的时候，最顶级的数据中心的PUE值在1.2/1.1左右，而典型的PUE值一般在1.8～2.5范围内。
布线也是典型数据中心预算的重要构成部分。无序的线缆增加会阻塞气流，导致需要复杂的空调解决方案，从而限制数据中心的部署。全世界的IT部门都在寻找创新性的解决方案，好让他们经济高效地跟上这种快速增长。我们将在本章后面讨论统一交换架构（Unified Fabric）（通过网络 I/O的虚拟化实现）。3.2.2 当前影响云／效用计算/ITaaS采用的障碍
很明显，对于当前的云产品缺乏信任，是影响云计算被采用的主要障碍。没有信任，云计算的经济性和更高的灵活性就没有太大意义。例如，从工作负载安排的角度来看，如果提供的信息不透明，客户如何在成本和风险（治理、风险、合规[GRC]）之间进行评估呢？透明性要求服务定义、审计、责任都有明确的定义。对行业所做的多个调研也证明了这点。例如，如图3-3所示，Colt技术服务公司对CIO进行的2011年云调查表明，多数CIO认为安全性是影响云服务采用的一个障碍，这成为支持云服务的一个拦路虎（集成问题）。那么我们该如何应对这些担心呢？图3-3 CTS的CIO云调查2011（www.colt.net/cio-research）
Cisco认为，对于云的信任集中在五个核心概念上。这些挑战使商业领袖和IT专家夜不能寐，而Cisco正在与合作伙伴一起来解决这些问题。
■安全性：是否有足够的信息保障（IA）流程和工具可以保障企业数据资产的私密性、完整性和可用性？对多租户的担心、对有效地监控和记录能力的担心以及对安全事件透明性的担心，是客户最关注的问题。
■控制：在多租户模式和虚拟且不断变换的基础设施上，IT部门能否保持直接控制，由他们决定如何部署软件、在哪里部署软件、如何使用和销毁软件？
服务水平管理：服务是否可靠？即，能否得到合适的资源使用记录（Resource Usage Record，RUR），对资源使用正确测量，并准确收费？出现断电怎么办？每个应用程序能否得到必要的资源和优先级，确保应用程序在云中的运行符合预期（容量规划和业务持续性计划）？
■合规：我的云环境是否符合强制性的管制要求、法律要求、通用的行业要求（例如，PCI DSS、HIPAA）？
■互操作性：考虑到目前的公共云实际都是厂商私有的，是否会出现厂商锁定的风险？今天的互联网在企业界流行，部分原因是因为多穴（multihoming），它能够与拥有不同物理基础设施的多个互联网服务供应商连接，从而降低了风险。
想要让人相信云解决方案是真正安全可信的，Cisco 认为这些云解决方案需要一个可靠的底层网络来支持云的工作负载。
为了解决数据中心的一些基本挑战，许多组织已经开始了探索。图3-4代表IT行业目前的大方向。图中划分了不同的运营阶段（合并、虚拟化、自动化等）以及技术阶段（统一交换架构、统一计算等）。图3-4 IT的运营和技术发展阶段
准备采用云服务的组织通常会经历下面这些技术阶段。
1．采用高可用的宽带IP广域网（通过ISP或者自建），以实现IT服务的集中和合并。应用程序型的服务放在广域网顶层，以便智能化地管理应用程序的性能。
2．采用虚拟化策略，进行服务器、存储、网络、网络服务（会话负载均衡、安全应用程序等）的虚拟化，在与位置无关的情况下实现服务实例更好的灵活性，进而使这类服务能够优化对基础设施的利用率。
3．服务自动化，在变更控制方面实现更高的运营效率，最终为采用更经济的按需服务使用模型铺平道路。换句话讲，就是构建“服务工厂”。
4．效用计算模型具有按使用量付费（PAYU）方式对客户进行测量、分摊以及收费的能力。反馈也是一个流行的服务，即能够显示当前的实时服务和配额使用/消费情况，以及未来的趋势。这样客户就能了解并控制他们的IT使用情况。反馈是服务透明性的一个基本要求。
5．通过公共的框架建立新市场，公共框架将治理与服务技术融合，有助于对不同的服务产品和服务供应商的服务进行裁决。
第1阶段：采用高可用的宽带IP广域网
远程地点之间的高可用宽带IP广域网使得过去分布式（地理上的分布或从组织角度的逻辑分布）的IT服务现在改为集中式，从而对这些IT资产提供更好的运营控制。
这个阶段面临的限制是：许多应用程序都是按照在局域网上运行编写的，不是为了在广域网环境上运行编写的。如果不想重新编写应用程序，比较经济的理想方法是利用能够感知应用程序的、通过网络部署的服务，为服务的最终使用者提供一致的体验质量（Quality of Experience，QoE）。这些服务通常属于应用程序性能管理（APM） （www.cisco.com/go/apm）类程序。APM包含的功能有：对应用程序响应时间的可见性、对哪个应用程序和分支机构带宽使用情况的分析、划分关键任务应用程序（例如来自Oracle和SAP，以及协同应用程序，例如Microsoft SharePoint和Citrix）优先级的功能。
实现APM所需要的具体功能包括以下几个方面。
■性能监控：在网络（事务）和数据中心（应用程序处理）两方面。
■报告：例如，应用程序SLA报告要求能够区分监控数据所处的服务上下文环境，以便从预期性能参数或请求性能参数的角度理解这些数据。这些参数源于服务的所有者及其服务合同承诺的条款。
■应用程序可见性和控制：应用程序控制为服务供应商提供了动态的自适应的工具，用来监控和保证应用程序的性能。
第2阶段：采用虚拟化策略，进行服务器,存储,网络,网络服务的虚拟化
市场上有许多支持服务器虚拟化的解决方案。虚拟化就是创建一个“沙箱”环境，将计算机的硬件从操作系统抽象出来。对操作系统呈现的是通用的硬件设备，由虚拟化软件将信息传递给物理硬件（例如 CPU、内存、磁盘和网络设备）。这些沙箱环境也称为虚拟机（VM），其中包含操作系统、应用程序、物理服务器的配置。虚拟机是与硬件独立的，具备很强的移植性，所以能够在任何服务器上运行。
虚拟化技术也可以在其他许多领域使用，例如组网和存储。例如，局域网交换中就有虚拟局域网（VLAN）的概念，路由领域则有虚拟路由和转发（VRF）表；存储区域网络则拥有虚拟存储网络（VSAN）、NFS存储虚拟化则有vFiler等。
但是，所有这些虚拟化都有一个代价，即管理的复杂性。由于虚拟资源从物理资源抽象出来，所以在控制效率，尤其在等式中加入伸缩这一因素之后，现有的管理工具和方法就不适用了。新的管理功能，不论是基础设施组件中隐含的，还是在外部管理工具中公开的，都需要为服务运营团队提供管理业务风险所需的可见性和控制。
基于 IEEE数据中心桥接（DCB）标准的统一交换架构（Unified Fabric）是一种抽象，这是虚拟化的是以太网。但是，这个技术统一了服务器和存储资源之间的连接方式，统一了应用程序交付和核心数据中心服务的提供方式，统一了服务器和数据中心资源之间相互连接以实现伸缩的方式，统一了服务器和网络虚拟化协调的方式。
作为虚拟机使用的补充，数据中心架构中还引入了虚拟应用程序（vApp），在新的虚拟基础设施中实现策略的强制执行，这也有助于管理风险。能够感知虚拟机的网络服务（例如VMware的vShield和来自Cisco的虚拟网络服务）允许管理员提供能够感知虚拟机的租户所有权的服务，并强制执行服务域的隔离（即 DMZ）。Cisco 的虚拟网络服务解决方案也能感知虚拟机的位置。最终，这项技术允许管理员将服务策略与虚拟机容器内的应用程序的位置和所有权绑定在一起。
Cisco Nexus 1000V vPath技术允许进行基于策略的流量“调用”vApp服务（也称为策略执行点（Policy Enforcement Points[PEP]），即使这些服务位于其他物理ESX主机也可以。这是智能服务交换架构（Intelligent Service Fabric，ISF）的开始，在 ISF中，基于IP或MAC的传统转发行为被“策略拦截”，根据转发行为实例化服务链。
服务器和网络虚拟化的推动力主要来自物理服务器和网络资产合并以及更高利用率的经济收益。通过vApps和ISF，可以根据需要调用网络上的服务和规划服务，不受传统流量操纵方法的设计限制影响，这在效率上带来的收益再次改善了虚拟化的经济性。
虚拟化，或者说从底层物理基础设施抽象出来这件事，提供了新型IT服务的基础，新型的IT服务从本质上讲更加动态，如图3-5所示。图3-5 IT领域抽象/虚拟化对 IT服务的支撑
第3阶段：服务自动化
服务自动化与虚拟基础设施密不可分，是交付动态服务的关键驱动因素。从IaaS的角度来看，这个阶段意味着使用自动化的任务工作流程——不论是业务任务（也称为业务流程操作管理（Business Process Operations Management[BPOM]）还是 IT任务（也称为 IT编排）。
传统情况下，因为要依赖基于脚本的自动化工具，因此成本太高，经济效率低下。脚本的本质就是线性的（很难回滚）；更重要的是，脚本将工作流程、流程的执行逻辑和资产紧密地耦合在一起。换句话讲，如果架构师在响应某个业务需求时，需要修改某个 IT 资产（例如，服务器类型/供应商）、工作流程或者在工作流程步骤/节点中的流程执行逻辑，则必须编写大量的新脚本。这就像是用LEGO玩具搭起一堵墙，然后将所有的部分都用胶水粘在一起。很多时候，比起在旧墙中替换或改动一些砖块，建一堵新墙会更容易，也更便宜。
两个重大发展让服务自动化变成更加经济、更加可行的选择。
■基于标准的Web API和协议（例如，SOAP和RESTful）有助于减少集成的复杂性，重用能力也有助于降低成本。
可编程的工作流程工具流程、流程的执行逻辑从资产解耦/抽象出来。现代的IT编排工具，例如Cisco的Enterprise Orchestrator、BMC的Atrium Orchestrator，允许系统设计师修改工作流程（包括调用和管理并行任务）、插入新的工作流程步骤，或者通过可重用的适配器修改资产，一切无需从头开始。还是用 LEGO 墙比喻，墙的每一个砖块都可以相对容易地更换，不需要建一座新墙。
注意，要让可编程服务自动化取得成功，还必须有第三个组成部分，即智能化的基础设施，通过这个基础设施，可以将底层设备配置语法的复杂性通过北行系统（northbound system）管理工具抽象出来。这意味着上层管理工具只需要知道策略的语义。换句话讲，编排系统只需请求巧克力蛋糕，然后元素管理器可以根据定义好的（编程）基于对象的数据模型将编排系统提出的请求转换成必要的材料，更进一步的话，还能指定如何混合这些材料以及每种材料需要的量。
一个实际的例子就是Cisco统一计算系统（UCS），它通过基于事务的单一富XML API （也支持其他API）公开了它的单一数据模型。这个API支持对物理计算层进行策略驱动的使用。为此，UCS通过应用程序网关在它的XML数据模型和底层硬件之间提供了一层抽象，由应用程序网站对策略语义进行必要的转换，在硬件组件上进行状态修改（例如BIOS设置）。
第4阶段：效用计算模型
这个阶段加入了监视、测量、跟踪资源的使用情况，以实现云计算的分摊和收费。它的目标是实现服务的自助提供（对计算资源按需分配），实际就是将IT变成了公用服务。
在任何IT环境中，掌握资源的分配和使用情况都至关重要。测量这些资源并进行性能分析，从而实现成本效率、服务一致性，并提供IT后续需要的趋势预测、容量管理、阈值管理（服务水平协议[SLA]）以及根据使用情况分摊费用等功能。
在今天的许多IT环境中，专用物理服务器及其相关的应用程序，还有维护和许可证的成本，都可以分摊到使用它们的部门身上，因此对这类资源的收费相对简单。而在共享的虚拟环境中，实时计算每个使用者的IT运营成本则是一个需要解决的挑战性问题。
按使用量付费，即根据服务的使用和消费情况对最终客户收费，公用事业、无线电话供应商之类的企业一直使用这种收费方式。因为IT部门要在基础设施、应用程序和服务上降低成本，按使用量付费在企业计算中日益获得接纳。
IT领导团队实施效用平台时的首要考虑之一是：如果按使用量付费的承诺正在促进云服务的采用，那么服务的供应商如何跟踪服务的使用情况，并根据使用情况计费？
IT供应商经常为收费解决方案的度量指标苦恼，因为这些指标不能正确地表达指定服务使用的所有资源。对于任何分摊解决方案来说，首要的目标都要求对基础设施有一致的可见性，以便度量每个用户的资源使用情况，度量指定服务的服务成本。现在需要结合多个解决方案，甚至开发自定义解决方案才能进行度量。
这样不仅需要投入前期成本，从长期来看，效率也不高。如果每增加一个服务或基础设施组件，IT供应商都要向度量系统中加入新功能，那么IT运营商很快就会被这项工作压垮。
虚拟聚合的基础设施及其关联抽象层的动态本质，虽然对IT运营有利，但却增加了度量的复杂性。理想的分摊费用解决方案应该能够帮助企业将聚合基础设施上提供的服务和发生的成本真正分摊开来。
度量和分摊费用通常有以下商业目标。
■根据业务单元或客户来报告资源的分配和使用情况。
■开发一个准确的服务成本模型，将使用率分摊到每个用户。
■提供一个方法以管理IT需求、帮助进行容量规划、容量预测及预算安排。
■在合适的SLA性能基础上进行报告。
分摊和收费要求执行三大步骤。
第1步 收集数据。
第2步 分摊仲裁（将从不同系统组件收集到的数据汇总成服务拥有者客户的一条收费记录）。
第3步 收费和报告（在收集到的数据上应用定价模型）并定期生成收费报表。
第5阶段：市场
根据主流经济学的观点，市场的概念指的是允许买卖双方交换任何类型的商品、服务以及信息的结构。以金钱（共同认可的交换媒介）为标的交换商品或服务就构成了交易。
要想建立一个将IT服务当成任意交换的日用品来交换的市场，市场的参与者需要就公共的服务定义达成一致，或者在技术定义和业务定义上有一套共同的体系。市场参与者之间就流程和治理方式达成一致是必需的，将不同供应商/作者的服务组件“混合”在一起来提供端对端服务的时候更是如此。
具体来讲，一个服务有两个方面。
■业务：业务方面对于技术来说是必须的，而技术方面对于交换和交付是必须的。业务部分需要产品定义、关系、担保和定价等。
■技术：技术方面需要履行、保障和治理等方面。
市场上会有不同的参与者分别承担不同的角色和角色组合。会有交换供应商（也称为服务聚合商或云服务中介）、服务开发人员、产品生产商、服务供应商、服务零售商、服务集成商以及最终消费者（甚至生产使用者）。3.3 数据中心设计的发展
本节概述目前正在浮现的数据中心技术，在前面介绍的架构原则中对这些技术的支持，它们对基础设施设计和实现的影响以及它们在IT即服务的交付中的价值。
首先，我们来考察第2层物理拓扑和逻辑拓扑的发展。图3-6显示了数据中心OSI第2 层拓扑设计的发展过程。由左至右，从数据中心功能层的活动接口数量可以看到物理拓扑的变化。这个发展对于支持目前和未来的服务用例来说是必需的。图3-6 数据中心OSI第2层的发展
虚拟化技术（例如VMware ESX服务器）和集群解决方案（例如Microsoft Cluster服务）目前都要求使用第2层的以太连接才能正常发挥功能。随着这类技术在数据中心的使用日益增多，组织现在要在不同的数据中心地点之间从高度可伸缩的第3层网络模型转移到高度可伸缩的第2层模型。这种转变给管理大型第2层网络的技术带来了变化，包括从使用生成树协议（STP）作为主要环路管理技术迁移到新技术，例如vPC和 IETF TRILL（Transparent Interconnection of Lots of Links，大量链路的透明互联）。
在早期的第 2 层以太网络环境中，必须开发出协议和控制机制来控制网络拓扑环路的灾难性后果。STP 是这一问题的主要解决方案，它为第 2 层以太网络提供了环路检测和环路管理功能。这个协议已经经过了许多增强和扩展，虽然现在已经能够处理非常庞大的网络环境，但仍有一个不太优化的原则：要破坏网络环路，则不论在网络中实际可能存在多少连接，两个设备之间只允许有一个活动路径。虽然STP对于解决第2层网络的冗余来说是个强大而且可伸缩的解决方案，但只允许单个逻辑链路这件事会造成以下两个问题。
■可用的系统带宽中有一半（甚至更多）不能用来传输。
■活动链路发生故障时，由于网络需要重新计算在第2层网络上进行网络转发的“最佳”解决方案，会导致在全系统范围内出现长达数秒的数据丢失。
虽然对STP的增强降低了重新发现过程的开支，使第2层网络可以更加迅速地重新聚合，但对某些网络来说，中间的延迟仍然太长。另外，使用STP进行环路管理时，缺乏一种高效的机制可以充分利用健康网络中的全部可用带宽。
对第2层以太网络早期的一个增强是端口隧道（PortChannel）技术（现在已经标准化成 IEEE 802.3的PortChannel技术），在这项技术中，两个参与设备之间的多个链接可以使用两台设备之间的全部链路转发流量，内部使用的一种负载均衡算法可以在可用的交换机互联链路（Inter-Switch Link，ISL）间平衡流量，同时将这些链路捆绑成一个逻辑链路，以便管理环路的问题。这个逻辑结构可以防止远程设备将广播帧和单播帧转发回逻辑链接，从而打破了网络中实际存在的环路。端口隧道（PortChannel）技术还有另外一个重要的好处：能够在不到一秒的时间内就解决链路丢失问题，解决过程中没有流量损失，对于活动的STP拓扑也没有影响。3.3.1 虚拟端口隧道（vPC）简介
传统的端口隧道（PortChannel）通信最大的限制就是只能在两台设备之间建立端口隧道。在大型网络中，对多台设备提供支持，以提供某种硬件形式的故障备用路径，通常是设计上的一项要求。备用路径的连接方式通常会形成环路，也就将端口隧道技术的好处限制到了单一路径上。为了克服这个限制，Cisco的NX-OS软件平台提供了称作虚拟端口隧道（virtual PortChannel，vPC）的技术。虽然充当 vPC对等端点的一对交换机对于连接到端口隧道的设备来说看起来就像一个逻辑实体，但充当端口隧道逻辑端点的两台设备仍然是两台独立的设备。这个环境结合了硬件冗余的好处和端口隧道环路管理的好处。转移到全部基于端口隧道进行环路管理的另外一大好处是：链路的恢复速度会非常快。STP从链路故障恢复大约需要6秒，而全部基于端口隧道的解决方案能够做到在1秒之内完成故障恢复。
虽然vPC不是提供这个解决方案的唯一技术，但相比之下，其他解决方案总是有许多效率不高的地方，从而限制了它们的实用性，尤其是在密集的高速网络的核心层或分布层中使用时。所有多机箱端口隧道技术在充当端口隧道端点的两台设备之间仍然需要直接链路。这个链路的带宽通常要比连接到端点对的vPC的聚合带宽小许多。Cisco技术（例如vPC）是专门设计的，目的是将这个ISL的用途限定在交换管理流量以及偶尔来自故障网络端口的流量。其他厂商的技术并不是为这个目标设计的，所以在规模上极为有限，因为它们需要使用ISL来控制流量，几乎消耗了对等设备数据吞吐率的一半。对于小的环境来说，这种做法可能合适，但对于可能存在几 TB 数据流量的环境来说，这种做法就非常不明智了。3.3.2 第2层多路径（L2MP）简介
IETF的TRILL是基于第2层拓扑的新功能。通过Nexus 7000交换机，Cisco已经支持了TRILL成为标准前的一版协议，称为FabricPath，使客户在 IETF TRILl标准流行之前就能从这项协议受益（为了让Nexus 7000交换机从Cisco FabricPath迁移到 IETF TRILL协议，已经计划了一个简单的软件更新迁移。换句话讲，不需要进行硬件升级）。一般来说，我们将TRILL和FabricPath称为“第2层多路径（Layer 2 Multi-Pathing，L2MP）。”
L2MP对于运营有以下好处。
■在第2层DC网络上支持第2层多路径（最多16个链路）。这为客户机到服务器（北到南）、服务器到服务器（西到东）流量都提供了更大的跨区域带宽。
■提供了内置的环路防止和缓解机制，无需使用STP。这会显著降低 STP这类不以拓扑为基础的协议的日常管理和故障排除工作的运营风险。
■对于未知的单播、正常的单播、广播和多播流量提供单一的控制。
■更大的OSI第2层域增强了FabricPath网络的移动性和虚拟化。由于需要配置和管理的服务依赖项更少，还有助于简化服务自动化工作流程。
下面这首 Ray Perlner在 IETF TRILL草案中写的一首有趣小诗可以说把握住了不受STP约束构建拓扑的好处。我希望有朝一日我们能看到，一幅比树更可爱的图画。一幅提升效率的图画，而且不用配置。在这个网络里，RBridges能够将包路由到它们的目标局域网。它们能够找到道路，让我们得意的是，它们找的路成本最低！根据我们现在看到的数据包跃点次数，网络再不用担心环路了！RBridges的工作是透明的，没有公共的生成树。（来源：Algorhyme V2，IETF draft-perlman-tril-rbridge-protocol，作者Ray Perlner）3.3.3 数据中心网络服务和结构的发展
这一节从以太网协议（OSI第2层）虚拟化的角度考察数据中心组网的发展。然后考察数据中心网络服务（例如，防火墙、负载均衡器，以及其他）的发展。
图3-7展示了数据中心的两大发展趋势。图3-7 数据中心 I/O结构和服务部署的发展
1．数据中心网络I/O的虚拟化
从提供方的角度来，向聚合I/O基础设施结构的转移，是网络技术当前发展的自然结果，现在一个结构就拥有足够的吞吐量、足够低的延迟、足够的可靠性，而且成本足够低，对数据中心网络业说，这已经成为一个经济可行的解决方案。
从需求方的角度看，多核CPU在虚拟计算基础设施发展中的普及，增加了对数据中心访问层的I/O带宽的需求。除了带宽，虚拟机的移动性也对服务依赖项（例如存储）提出了灵活性要求。统一 I/O基础设施结构支持将覆盖服务（overlay service）（例如，基于文件[IP]或基于块[FC]的存储）抽象出来，从而支持灵活性要求的架构原则，即“连线一次，任何协议，任何时间。”
从策略的执行角度来看，在虚拟网络基础设施和物理组网之间的抽象，会对服务流量的端到端控制带来挑战。虚拟网络链路（Virtual Network Link，VN-Link）是Cisco提供的一套基于标准的解决方案，这个解决方案支持以基于策略的网络抽象将虚拟网络策略域和物理网络策略域重新组合在一起。
Cisco及行业内的其他主要厂商编制了一个IEEE标准提案，用以解决虚拟环境中的组网挑战。形成的标准体系是 IEEE 802.1Qbg的边际虚拟桥接（Edge Virtual Bridging）和 IEEE 802.1Qbh的桥端口扩展（Bridge Port Extension）。
数据中心桥接（Data Center Bridging，DCB）架构的基础是 IEEE 802.1工作组开发的一组开放标准的以太网扩展，它可以提高和扩展数据中心以太网的组网功能和管理能力。它可以确保在不丢包的结构上进行传输，并将I/O聚合成统一的结构。这个架构的每个元素都能增强 DCB 实现，创建满足数据中心当前和未来需求的架构。表 3-2列出了DCB架构的主要功能和益处。表3-2 数据中心桥接的功能和益处
IEEE DCB在传统以太网优势的基础上添加了几项关键的扩展，提供了数据中心网络的下一代基础设施，交付了统一交换架构。下面我们将逐一介绍 DCB 架构构建能够满足当今日益增长的应用程序需求，响应数据中心未来网络所需的强大以太网络的主要功能。
支持链路共享的基于优先级的流控制（PFC），这对I/O聚合至关重要。链路共享要获得成功，一种流量类型的巨大突发不得影响其他流量类型，来自一种流量类型的巨大流量队列不得争抢其他流量类型的资源，而且针对一种流量类型的优化不得造成少量其他流量类型消息的高延迟。可以使用以太网的暂停机制来控制一种流量类型对另外一种流量类型的影响。PFC是对暂停机制的增强。PFC支持根据用户的优先级或服务的类型进行暂停。一条物理链路被分成8个虚拟链路，使用PFC，能够在单一虚拟链路上使用暂停帧，并且不影响其他虚拟链路上的流量（传统的以太网暂停选项会将一条链路上的全部流量都停止）。基于用户优先级的暂停允许管理员为要求不丢包的服务创建没有丢失的链路，例如光纤通道以太网（Fibre Channel over Ethernet，FCoE），同时保持对IP流量的丢包拥塞管理。
同一PFC类内的流量可以组合在一起，同时在每一组内分别对待。ETS可以根据带宽分配、低延迟划分优先级或尽力处理，从而形成在每一组内的流量类型划分。对虚拟链路的概念进一步扩展，网络接口控制器（NIC）也提供了虚拟接口队列，每类流量一个队列。每个虚拟接口队列各自负责给它的流量组分配的带宽，但组内拥有动态管理流量的灵活性。例如，给IP类流量的虚拟链路3（共8个）指派高优先级，IP类流量指派尽力处理，虚拟链路3类按预定比例与其他流量类共享总体链路。ETS支持对同一优先级类型的流量进行区分，形成优先级分组。
除了 IEEE DCB标准，Cisco Nexus数据中心交换机还有FCoE多跳功能和无损结构等方面的增强，支持统一交换架构（Unified Fabric）的构建。
为了避免混淆，注意聚合增强以太网（Converged Enhanced Ethernet，CEE）这个术语是由“CEE 发起人”定义的，这是个临时性组织，由 50 余名开发人员组成，这些开发人员来自各类网络公司，这些公司在 IEEE 802.1工作组完成DCB标准之前向 IEEE提交了标准预备提案。
FCoE是光纤通道组网和小型计算机系统接口（SCSI）块存储连接模型的下一步发展。FCoE将光纤通道映射到第2层以太网，允许将局域网流量和SAN流量组合到一个链路内，允许 SAN 用户充分利用以太网的规模经济性、强大的厂商社区以及路线图。局域网流量和SAN流量在一条链路上的组合，称为统一交换架构（unified fabric）。统一交换架构消除了适配器、网线、设备，带来的节约可以延长数据中心的寿命。FCoE提供的标准服务器I/O提高了进行服务器虚拟化的动力，标准服务器I/O支持局域网以及所有基于以太网的存储组网方式，消除了数据中心的特殊网络需求。开发 FCoE标准的行业主体与创建、维护所有光纤通道标准的主体是相同的标准主体。FCoE 在INCITS之下，被编定为FC-BB-5。
FcoE是革新性的技术，它与现有的光纤通道兼容，只在功能上做了发展。FCoE可以分阶段实现，不破坏目前已安装的SAN。FCoE只是在以太网上为完整的光纤通道帧建立了隧道。通过帧的封装和解封装策略，帧在 FcoE 和光纤通道端口之间的转移没有额外开支，从而与现有的光纤通道建立起连接。
2．网络服务的虚拟化
应用程序的网络服务，例如负载均衡器、广域网加速器，已经是现代数据中心不可或缺的组成部分。这些第4层～第7层的服务可以提供服务的伸缩性，提高应用程序性能，提高最终用户的生产率，通过优化的资源利用率来降低基础设施成本，并能监视服务的质量。它们还提供安全服务（即，策略执行点[PEP]，例如防火墙和入侵检测保护系统[IPS]），与其他控制机制和强化过程一起，在聚合的数据中心和云环境中将应用程序和资源隔离开来，确保实现合规性并降低风险。
但是，在虚拟数据中心部署第4层到第7层服务，是个极为艰苦的任务。传统的服务部署方式完全不适合伸缩性极高的虚拟数据中心设计，后者的工作负载是移动性的、网络是动态的，并且有严格的SLA。前面提到过，仅安全一项必备服务，就被频繁当成企业采用节约成本的虚拟化和云计算架构的最大挑战。
如图 3-8所示，Cisco Nexus 7000系列交换机可以根据业务需要划分为多个虚拟设备。这些划出来的虚拟交换机称为虚拟设备上下文（Virtual Device Context，VDC）。配置出来的每个 VDC 对于连接到这个物理交换机上的每个用户来说，都是单独的一台设备。因此 VDC 能够真正实现网络流量的分段，实现上下文级别的故障隔离，并建立独立的硬件分区和软件分区来进行管理。VDC在交换机内作为独立的逻辑实体运行，维护自己的一套运行软件进程，有自己的配置，由独立的管理员管理。
VDC具有以下的可能用例。
■为多个部门的流量提供安全的网络分区，允许部门独立地管理和维护他们自己的配置。
■消除数据中心原有的众多层次，在资产开支和运营开支方面降低总体成本，提高资产利用率。
■在生产网络中，可以在隔离的VDC上测试新的配置选项或连接选项，这可以大大节省服务部署的时间。图3-8 使用Nexus 7000虚拟设备上下文（VDC）减少垂直层次3.3.4 数据中心内的多租户
图 3-9 显示多租户基础设施在不同租户之间提供了端到端逻辑隔离，并且显示了云IaaS 如何提供强大的端到端多租户服务平台。此上下文中的多租户是指能够在许多利害干系人和客户之间共享单个物理和逻辑基础设施组的功能。这不是什么革命性的内容，像多协议标签交换（Multi-Protocol Label Switching，MPLS）等技术，很早就在广域网（WAN）中建立了出色的将不同客户隔离开的运营模型。因此，数据中心的多租户模型只是对现有成熟范式的发展，只是增加了一些技术，例如 VLAN、虚拟网络标签（VN-Tag）与虚拟网络服务（例如，会话负载均衡、防火墙、IPS PEP实例等）结合。图3-9 端到端“隔离”——构建多租户基础设施
除了多租户，架构师还需要考虑如何提供多层应用程序以及相关的网络设计和服务设计，包括从安全角度考虑的多区域功能。换句话说，要构建安全的、功能正常的服务，架构师需要考虑多种功能需求，如图3-10所示。
这里的挑战是：需要能够将必需的服务组件（各有自己的运营水平协议，OLA 支持SLA）串在一起，构成一个交付端到端服务属性的服务链（法律上由服务水平协议[SLA]规范化），而这正是最终客户期望得到的。这项工作必须在应用程序分层设计和安全分区需求的上下文环境内完成。图3-10 IaaS平台多租户、多层、多区域特性的多层次架构示例（资源来源：Cisco System VMDC 2.0解决方案）
指定基础设施的实时容量以及功能情况报告，仅仅是需要向市场提交的成果的开始。传统的 ITIL配置管理系统（Configuration Management System，CMS）没有设计成在实时环境下运行。后果就是：要部署一个具备已知定性和定量属性的服务链，就必须采取一种结构化的方式来部署服务和激活服务。这种结构化的方式要求预先定义好服务元素容量和功能的基础设施模型，这些元素相互之间还要比较接近。预先定义的服务链，通俗的说法是“网络容器”，在基础设施上激活的时候，则称为“已知使用单元”。服务链是各种技术拓扑构造块的组合，如图3-11所示。
在实时IT容量和功能报告工具出现的同时，在灵活的元模型和数据（即计算机间相互连接的规则，例如防火墙实例可以连接到VLAN，但不能连接VRF）之外，所有基础设施都需要自动发现和报告功能，供应商和客户能够采用非结构化方式进行服务链的部署。换句话讲，客户能够创建自己的蓝图，发布到自己的服务目录内来消费使用，甚至可以将蓝图发布到供应商的服务组合，供其他客户使用，从而实现了一种“生产者即使用者（prosumer）”的模型。图3-11 虚拟私有云部署的网络容器3.4 服务保证
如图3-12所示，SLA由仅仅需要以第1层到第3层的常规网络性能为基础（使用抖动率和可用性等测量指标），逐步发展到以具体应用程序的网络性能为基础（由局域网优化控制器等技术管理），又发展到以特定于应用程序的度量指标和业务流程为基础，甚至发展到以关键性能指标（KPI）为基础，例如生命周期或生产率。使用 KPI 为基础的SLA示例有：航空公司每小时检票的乘客数，或者服务的新客户账户数量。图3-12 SLA边界的扩展
客户希望即使在某台服务器发生故障，或者某个数据中心无法提供服务时，他们的关键业务流程（例如工资处理、订单处理）仍然一直可用，希望服务供应商提供充足的资源来确保这些应用程序的性能。这要求云供应商能够向上扩展的数据中心资源，确保虚拟机在数据中心内部和跨数据中心的移动性，在需要的时候提供其他数据中心的计算机资源作为补充。
通过数据中心和Cisco IP NGN资产的组合，服务供应商能够吸引独立软件供应商提供SaaS产品，最终客户从SaaS供应商那里购买服务，而服务供应商负责交付可靠的端到端应用程序体验。
除了广域网上的性能SLA、应用程序可用性的SLA，客户还希望他们托管的应用程序在外部托管环境中得到必要的安全保护。在许多情况下，他们希望云服务供应商提高应用程序在数据中心的性能和通过广域网的性能，提高应用程序的响应时间，消除延迟和拥塞的影响。
服务供应商利用自己私有的 IP/MPLS 网络，能够增强应用程序在云中的性能和可用性，提供客户所要求的可见性、监视和报告功能。云服务供应商构建他们的解决方案时，应该考虑如何才能持续地改进他们的服务产品，不仅要支持网络和应用程序SLA，还要支持应用程序交易及业务流程的SLA。
今天的服务保证解决方案既需要处理迅速变化的基础设施配置，还要了解拥有服务的客户总在不断变化，并在这一背景下认识服务的状态。解决方案还需要理解，服务的上下文环境可能超越了传统的互相独立的 IT 领域，例如 IP WAN 和数据中心网络（DCN）。
理想情况下，这类解决方案最好基于单一平台和单一代码基设计，这样可以消除理解动态环境下的服务时会产生的一些复杂性。这样更容易理解和支持云服务平台，还能消除昂贵而耗时的产品集成。但是，这种单一平台的设计不应该影响大型虚拟公共云环境必需的伸缩性和性能，这种环境明显需要支持高可用性的部署模型。
对于功能性系统的构建来说，与第三方工具的北行（Northbound）和南行（southbound）集成，与成熟的现有消息格式和工作流程的集成，支持直接的消息交互和 Web 集成API，这些绝对是一个基本的要求。
IaaS的保障部署需要可以支持以下方面的实时、可扩展数据模型。
■对多种设备和域管理器、他们的组件以及配置的标准化对象表达。
■足够灵活地代表网络设备、操作系统、数据中心环境设备、独立服务器、机箱服务器、域管理器（例如 vSphere、vCloud Director、Cisco UCS）。
■能够管理托管资源之间的多种重叠关系。
■对等关系，例如组中的公共成员。
■父子关系，例如UCS机箱和刀片之间的关系。
■固定依赖关系，例如进程和操作系统之间的关系。
■移动依赖关系，例如虚拟机及其当前宿主系统之间的关系。
■跨界发现关系，例如虚拟主机和代表网络上的逻辑存储卷的逻辑单元号（LUN）之间的关系。
■托管对象和管理数据流之间的连接，例如事件数据库和性能度量指标。
■托管对象集合与用户子集之间的安全边界，以支持在多租户环境中使用。
■开发人员可扩展，以便为所有客户开发公共功能。
■现场可扩展，以便服务团队和客户满足不常见的需求或独有的需求。
定义服务元素之间的逻辑关系，表达服务的技术定义，这一功能在提供面向服务的影响分析方面，是一个关键的步骤。
服务包括以下元素。
■物理的：系统、基础设施和网络设备。
■逻辑的：一个服务必须度量或评估的方方面面。
■虚拟的：软件组件，例如进程。
■引用的：由其他域管理器表达的元素。
另外，为了理解服务组件，服务元素关系有固定的和动态的，并且也需要跟踪。固定关系标识各种定义，例如，这个Web应用程序属于这个服务的。动态关系由模型管理，例如Cisco UCS机箱上托管着一台ESX服务器，而支持这个服务的一台虚拟机正在这台服务器上运行。
服务策略评估元素之间的状态和关系，提供影响上滚，这样就能知道受底层设备故障影响的服务。这有助于判断问题的源头，可以从服务开始，逐级看到基础设施的多级故障，提供上升、下降和降级服务状态（例如，如果负载均衡组中的一台Web服务器停机，那么服务可能就要降级）。最后，服务策略可以对事件风暴进行过滤、上滚以及窗口分隔功能。
所有这些信息、服务元素、关系、服务策略共同提供的服务虚拟化，允许运营机构迅速判断服务、服务元素、当前的动态网络及基础设施资源的状态，还支持服务定义和微调。在www.zenoss.com上可以找到支持这些属性和功能的服务保证工具的出色示例。3.5 服务平台的发展
在构建公用服务平台的时候，组织通常会采用分阶段的策略。图3-1显示的四步走方法实际已经对最终客户构建公用服务平台的过程进行了简化。实现这个目标的方式，在很大程度上取决于架构的当前状态。例如，是从一个崭新的部署开始，还是从一个破烂不堪的部署开始？要向谁、以什么价格、何时提供以及提供什么服务？所有这些因素都需要在服务创建阶段提前确定。图3-13 客户对服务平台的需求在不断发展
这个阶段划分基本上与本章前面讨论过的IT行业的发展阶段相吻合。
1．端到端基础设施的虚拟化。
2．从配置到保证的服务生命周期自动化。
3．服务基础设施的部署和集成，即客户门户、收费和CRM。
4．内部云技术和协议的部署，支持工作负载及其依赖项的迁移。
将现有应用程序迁移到新的服务平台，需要进行充分的调研和规划，不仅要研究技术的可行性，还要研究当前运营和治理约束的可行性。本书作者的经验表明，运营和治理约束的可行性是最难做对的方面。要想获得成功，技术和业务的利害干系人必须密切配合，共同协作。
在工具集上构建虚拟化管理策略是第一阶段成功的关键。如果没有高效的虚拟化管理策略，虚拟化的优势就会失去。虚拟服务器管理对运营、命名规范、分摊、安全等方面的策略都提出了变化的要求。虽然许多服务器和桌面虚拟化技术都提供了自己的管理功能集合，公司依然应该考虑用第三方工具填补管理上的空缺。这些工具应该能够实时地回答“我现有多少基础设施容量和功能？”或“服务有哪些依赖项？”之类的问题。
正如前面讨论的，虚拟化有助于交付基础设施的多租户功能。这意味着对有限的（通常是虚拟的）资源集合进行分组和管理的功能，这些资源集合可以专供一个客户使用，在数据和管理层面上都可以同那些为其他客户分配的资源隔离开（例如，客户门户和生命周期管理工具）。实现这个抽象级别的工具实例就是 Cisco 云门户（CCP），它提供了基于RBAC的命名视图和管理。从服务激活方式可以举的例子，就是本章前面提到过的网络容器。
第二个阶段就是通过（理想的话）端到端IT协调（也称为运行资料自动化）和服务保证工具引入服务自动化。这个阶段关心的全部是大规模交付IT时的速度和质量，并用更低的变更管理成本实现可预测性和可用性。简而言之，这个阶段采用最佳做法方法论，以结构化的基于工作流程的方式提供IT服务管理（ITSM）。
第二阶段是用软件开发工具管理数据中心基础设施（物理的和虚拟的）的自然发展。图 3-14 显示了这个阶段发展的时间轴。IT 业目前正在采用“可编程的”的软件来塑造底层基础设施的功能和容量。在这些软件模型内部都置入了技术规则和业务规则，以确保IT基础设施的合规和标准化。第5章在讨论“网络虚拟机监控软件产品”时，将讨论这种可编程模型工具提供方式的一个示例。
第三个阶段是构建和集成服务功能。支持服务的工具包括客户门户和服务目录，加上SLA报告和度量、分摊、报告（服务目录是一个经常被滥用的术语，它实际包含多种功能，例如，组合管理、需求管理、请求目录、生命周期管理）。从运营的角度看，IT协调软件（例如，Cisco Enterprise Orchestrator）与智能的域/资源管理工具的集成，完成了基础设施的服务启用功能。第三阶段还是改变企业文化的阶段，将企业的文化改变成服务导向的，不再是产品导向的。这要求企业内从组织、流程、治理各方面都做出变化。图3-14 数据中心管理工具的发展
在编写本书时，支持这一历程第四阶段的技术在市场上还刚刚开始出现。要想在（云）服务供应商之间远距离迁移工作负载和服务链，需要解决一连串与技术和服务有关的约束。第5章将详细讨论其中的一些约束。3.6 小结
Cisco认为网络平台是公用服务平台的基础性组成部分，因为在数据中心之内和之外，提供智能性的连接功能都是至关重要的。有了合适的内置工具和外部工具，网络可以提供一个安全的、可信任的、强大的服务平台。
网络自然是管理和执行与风险、性能、成本相关策略的核心。只有网络才能看到云内和云间的所有数据、连接的资源以及用户交互。网络因此在监视、测定分布式服务和基础设施的使用情况和性能方面，就具备了独一无二的优势。从这个意义上讲，网络就像人体的自主神经系统（ANS），这个系统（主要在意识级别之下工作）控制着内脏器官的功能。ANS通常分为感觉性（输入性）和运动性（输出性）两个子系统，这与服务平台需要的可见功能和控制功能类似。实际上，在编写本书的时候，有许多关于复杂网络系统管理的学术研究，其中有生物网络、社会网络，也有传统的IT网络。数据中心及范围更广的网络的管理工具已经从以用户为中心（例如，GUI设计）转移到了今天以流程为中心的可编程能力。未来，重点很有可能转移到面向行为，然后发展到以认知能力为基础。
网络在提高弹性和可靠性方面也起到核心作用。例如，网络独有的端到端可见性，有助于通过内嵌的基于策略的控制功能，对工作负载进行动态协调和重定向。网络天生具有知道资源和用户物理位置的能力。能感知上下文的服务可以预测出用户的需求，并相应地部署资源，在服务的最终用户体验、风险管理以及成本之间实现平衡。第4章 IT服务
本章从业务为中心的角度和技术为中心的角度描述了信息技术（IT）服务的分类。本章研究基础设施即服务（IaaS）背后的经济性，在云中放置“工作负载”的上下文，即风险与成本。本章完成时，您将能够了解下列内容：
■IT服务和数据的分类方式及原因；
■服务在企业中的角色、功能和价值；
■云经济的四大基石；
■工作负载放置的上下文处理。4.1 IT服务和信息的分类
在管理基于云的服务时，工作负载放置，或者说 IT 服务放置，已经成为一个重要的决策点，即一个应用程序或 IT 服务应该放在私有云内还是放在托管的云环境中？这个决策的结果可以简化为一个成本和风险的平衡。同所有决策过程一样，一个决策结果的质量和可靠性在很大程度上取决于为该决策所提供的信息。因此，从供应商的角度和客户的角度看运营服务的透明性，如何通过标准化分类和通知方法实现透明分类，都有许多讨论。
我们首先讨论风险这一概念（在这个上下文环境中，风险指的是遭受财务损失的机会），讨论它的分类和表示（定性的、定量的），然后在云经济的基础上讨论成本的概念。
IT服务（信息和信息系统）的分类主要与风险的类别或部分有关，风险则与企业工作执行过程中（即赚钱）信息的遗失或失窃以及服务的重要性（潜在影响）有关。
换言之，分类的目的是正式而公开地保护信息和信息服务在出现信息泄漏或出现故障时不会降低或危及企业的运作水平。4.1.1 风险评估和信息分类
安全风险分析，也称为风险评估，是企业安全的基础。关键在于确保控制措施和开支能够完全应对企业所面对的风险。风险分析一般用定性（考察风险点、威胁、控制措施）或定量方式（可能性[每年]*单次损失预计=年度损失预计）的方式进行。
图4-1显示了用来对数据和数据信息安全控制进行分类的安全分析模型的顶层视图。图4-1 对数据进行分类、评估数据安全控制措施的安全分析模型
作为第一步，组织需要有一个参考模型，用来辨识可能存在的不同数据类型（数据是最低层次的抽象；数据本身并没有任何意义，只有信息才会传达意义。知识是最高形式的抽象，既承载意义，又承载应用的价值）。以客户数据为例，在许多客户处，客户数据都受到法律的严格保护。客户信息和对于客户的了解（例如，客户何时、何地、购买了什么）对于企业的分析和营销来说，具有巨大的价值。
作为风险分类的示例，通过称为信息保证级别（Information Assurance Level，IAL）的明确分类，表示了信息滥用存在的潜在影响，与IAL对应的是一套为了缓解这类暴露的风险而设计的对策和控制措施。虽然各个国家的分类系统各不相同，但多数国家都拥有与英国政府定义的下述业务影响等级（Business Impact Levels，BIL）（从最高级到最低级）的IAL。
■BIL6，顶级机密（TS）：国家级别上对资料分类的最高级别。此类资料如果公开，可能会对国家安全造成“极为重大的破坏”。
■BIL5，机密：此类资料如果公开会对国家安全造成“重大破坏”。
■BIL4，秘密：此类资料如果公开会对国家安全造成“破坏”或“不利”。
■BIL3，限制：此类资料如果公开会造成“不期望见到的后果”。有些国家没有这个分类。
■BIL2，保护：此类信息或资料如果泄漏，会对个人带来实质性的损害，或者违犯了关于信息披露的法律限制。
■BIL1，保护：技术上讲，这不算一个分类级别，但用在不属于以上分类的政府文件上。此类文档有时可以在没有安全许可的情况下查阅。
■BIL0，无分类：可以向大众公开，即使意外或故意泄露给公众，也不会造成任何损害，不会违犯任何法律的信息。
更多详细信息，请参阅公开文档www.cesg.gov.uk/policy_technologies/policy/media/business_impact_tables.pdf。
这份文档在子分类（subcategory）下面（供公共部门主体使用的用例）提供了有用的上下文指南。本章后面将详细讨论BIL。
类似的，对于美国政府来说，Executive Order 13526（于 2009年修订）定义了信息分类。第1.2节划分了三个信息分类等级。
■“顶级机密”适用于未经授权的披露会对国家安全造成极为严重的破坏，而信息的原始分类机构能够辨识或描述此类危害的信息。
■“机密”适用于未经授权的披露会对国家安全造成严重的破坏，而信息的原始分类机构能够辨识或描述此类危害的信息。
■“秘密”适用于未经授权的披露会对国家安全造成破坏，而信息的原始分类机构能够辨识或描述此类危害的信息（美国政府将北约合作伙伴的信息归为“限制”和“秘密”)。
■“无分类”技术上不是一个分类等级。4.1.2 企业中的治理、风险与合规
作为IT架构师和系统设计师，我们通常会从IT安全控制（例如，AAA、防火墙等）的角度考虑风险。但是，我们首先必须从业务方面全面地考虑与治理和合规有关的风险（也称为治理、风险与合规[GRC]）。随着 IT 对企业变得越来越重要，很多时候甚至占据了 50%以上的资本预算，企业负责人会对 IT 加以更多监管，所以理解可以用来交付有效监管的不同框架的功能与角色非常重要。接下来（治理、风险与合规）将介绍有助于进行企业监管的一些相关框架和方法。
1．治理
公司治理包含一整套影响公司管控方式的内部流程、策略以及外部的法律和机构。公司治理还包含众多参与角色（利害干系人）和公司目标之间的关系。主要角色包括股东、管理层、董事会，还包括监管机构等外部角色。
IT治理是为了保证在IT上的投资能够产生真正的商业价值，消除与IT项目有关的风险。
后面这节将详细介绍一些治理框架。
值得一提的是，所有框架和方法都有其优势和不足。具体采用哪个框架和方法，如何运用，完全取决于个人和公司现有的文化。
COBIT（信息及相关技术的控制目标）
COBIT被定位为顶层的治理框架。业务专家和IT专家都可以使用COBIT，而且包含丰富的支持文档和工具来帮助人们使用它。COBIT 最初由信息系统审计与控制协会（ISACA）于1996年开发出来，目前归IT治理学会（ITGI）拥有。
ITGI还开发了一套COBIT管理指南，并整合进COBIT框架之内，这套管理指南包含成熟度模型、关键成功因素（CSF）、关键目标指标（KGI）以及关键性能指标（KPI）。
因此，COBIT全面覆盖了整个 IT治理流程。但是，它的覆盖仅是整体面上的覆盖，在具体方面则侧重于审计和控制。其他框架则更全面地覆盖了整个流程的子集，这些框架包括针对 IT服务管理和交付的 ITIL、针对 IT安全的 ISO 17799。
2．ITIL（信息技术基础设施库）
ITIL由一系列的8本书组成，提供了IT服务管理和交付的最佳做法。ITIL为高质量的IT管理提供了基础，最初是由英国商业部（OGC）开发和发布的。2000年，英国标准化协会（BSI）与OGC联合修订了ITIL，并将它融合进BS15000。目前的版本是ITIL V3。
ITIL的8本书是：
1．计划和实现服务管理 Planning to Implement Service Management
2．业务视角 The Business Perspective
3．软件资产管理 Software Asset Management
4．服务支持 Service Support
5．服务交付 Service Delivery
6．安全管理 Security Management
7．ICT基础设施管理 ICT Infrastructure Management
8．应用程序管理 Application Management
TOGAF（开放组架构框架）
TOGAF 是用来开发企业架构的方法论。企业架构的目的是将企业范围内碎片化的传统流程（包括手工的和自动化的）优化到一个统一的环境中，提高对变化的响应性，提高对公司战略的支撑（即提高项目成功交付的比例，降低风险）。
TOGAF（最新版本是v9）的核心是架构开发方法（ADM）。ADM准备阶段的目的是明确在企业中开发架构的方法，即在哪个框架内工作以及架构原则。IT治理在这个阶段就被融合进来，而且要遵守IT治理的要求。换言之，在这个阶段要开发一个IT架构愿景，这个愿景要将公司架构、驱动因素和目标统一在一起。
3．风险
在企业中进行风险管理，需要对于业务需求、潜在威胁、可能被利用的风险点有透彻的了解，同时还要对发现风险的可能性及影响进行评估。有些公司可能会发布一个风险偏好声明，说明他们为了实现业务目标而可以容忍的整体风险等级。
业务影响分析（BIA）报告要识别企业中最重要的系统和流程，识别IT系统停止对组织可能产生的影响，并对在业务影响等级（BIL）中划分这些影响。潜在影响越大，公司就应该花更多的钱迅速恢复系统或流程。例如，一家大型共同基金可能决定投资一套完全冗余的IT系统，这样，在主办公地点发生故障的时候，公司就可以在另外一个地点立即开始处理交易。BIA可以帮助企业设定恢复次序，确定哪部分业务应该先恢复。
大型企业有专职的风险评估团队（RAT）定期执行风险评估流程。在评估过程中，通常会执行三类定性和定量的测试。
■渗透测试：渗透测试对特定应用程序、主机或系统的风险点的深度进行测试。这类测试对资源的风险最大，应该少用。
■风险点分析（VA）：风险点分析要考虑的是广度，可能包含的测试方法从简单的网络扫描（使用自动工具或手动工具），到用自动化的电子手段执行的复杂测试。
■风险评估模型（ RAM ）：RAM 用不同的构架（标准的或公司内部的）将 ISO27001:2005 的需求与企业的信息安全需求结合在一起。这种结合会形成机构独有的流程，用自己的评分模型来识别信息安全整体情况的强弱之处。
4．ISO 27001
根据www.27001-online.com的定义：“ISO 27001标准的基本目标是采用持续改进的方式（PDCA循环，即计划-行动-检查-纠正）协助建立和维护有效的信息管理系统”。它实现了OECD（经合组合）原则，控制信息和网络系统的安全。它包含的信息分类方法与本章前面讨论过的美国政府信息分类模型类似。但是，这个分类方法更注重于在企业中使用，如表4-1所示。表4-1 ISO 27001:2005 A.7.2.1信息分类策略续表
5．合规
公司合规与伦理（SCCE）协会的定义，合规就是“满足他人预期的过程。”（资源来源：www.corporatecompliance.org）。
不同的地方和不同的行业有着不同的合规要求，例如，某个特定的司法区域的法律、法规提出的法律合规要求。
数据隐私方面的法律直接影响IT基础设施的配置和操作方式。数据受到隐私法形式的法律保护。例如，德国有Bundesdatenschutzgesetz（BDSG），英国有《数据保护法1998》（DPA）。
除了国家颁布的数据隐私法律法规，垂直行业本身也有属于自己的监管主体。流行的例子有《萨班斯法案》（SOX）、《支付卡行业数据安全标准》（PCI DSS）、《健康保险转移和责任法》（HIPAA）。受这些监管框架制约的公司必须考虑在自己内部设立必要的控制等级（IT及非IT），以保护规定的数据不被侵害或使用不当，即保护这些数据的完整性、私密性和可用性。
因为自然的限制，监管机构、法律部门、税务机构都受到地理范围的限制，因此，一项服务或工作负载的物理位置，就决定了需要遵守的控制需求。相应的，在制定工作负载放置决策（工作负载是个业务术语，指的是包含一个或多个应用程序，配以存储、安全等支撑服务的虚拟机），数据的主人或管理者必须了解服务所在区域的监管要求，了解在标准的IT功能以及他们在SLA中提供的容量（vCPU、内存、I/O、IOPS）之外还要达到的合规要求。
而且，最终客户也会评估不同供应商的服务产品。要对市场上的竞争产品进行有效的评判，也要有一套公共的体系。也就是说，行业需要有相应的标准来提供服务的透明性，不仅从产品的角度（描述SLA的体系），还要从活动服务运营状态的角度（即，如果某个基础设施组件的故障导致无法实现SLA，则必须报告这个事件，如果合适，还要给予惩罚或赔偿）来进行这个工作。
服务供应商一直在想办法将云服务SLA的信息标准化，并将风险管理能力整合进来。
云安全联盟就是定义这类标准的一个行业主体，该联盟开发了GRC栈（www.cloudsecurity alliance.org/grcstack.zip）。GRC栈为企业、云服务供应商、安全解决方案供应商、IT审计人员以及其他关键利害干系人提供了一个工具包，用行业最佳做法、标准和关键合规要求来武装和评估私有云和公共云。
云安全联盟的GRC栈是由三个CSA计划集成得到的套件。
■CSA云审计：允许云服务供应商自动执行审计、判断、评估、保证的流程。
■CSA 控制矩阵：提供对云厂商进行指导的基本安全原则，帮助潜在的云客户评估某个云供应商的整体安全风险——从合规到安全架构，共分为11个控制领域。
■CSA统一评估计划：云安全联盟统一评估计划（CAI）启动的目的是为进行调研、建立工具、建立行业合作关系，以支持对云计算的评估。4.1.3 服务的评估和分类
如图4-2所示，我们可以根据企业价值需求的范围对服务或应用程序进行分类（为了说明问题而做了简化）。核心服务或核心应用程序可以帮助企业在市场上保持竞争优势。换言之，如果核心应用程序出现问题，就会妨害企业与众不同的能力，进而损害企业有效地展开竞争的能力。核心应用程序的示例包括（但不限于）企业资源计划（ERP）系统、协作系统，以及这些系统的实现。图4-2 IT服务梳理：简化视图
定义 IT 服务价值或应用程序价值的一个方法是：从它的服务角色角度对其进行分类（参见表4-2）。通过这种分类，可以更好地了解某项IT服务或应用程序对企业来说是核心的还是可有可无的，而且了解的粒度会更细。这就提供了一种简便的方法，将未来的投资计划从记录系统转移到更加核心的服务类型，即差异系统和创新系统。记住，这些系统仍然需要尽可能地以协调、高效的方式协作配合。因此，元框架、元模型、元数据以及治理标准和架构原则也都是必需的。表4-2 系统价值分类*资源来源：ERP战略：在企业软件中发现创新，作者 Jim Shepherd，副总裁&著名分析师，Gartner公司
还是看看图 4-2，在水平轴上，关键任务提供了一个实际的划分，即应用程序或服务相对于公司经营的关键程度。简单点讲，如果某项IT服务停止，公司运营能坚持多久？允许某项服务停机的最大限度是什么？
关键任务要求与每个服务组件内置的高可用（HA）能力及其依赖项直接相关。进一步讲，这与管理恢复点目标（RPO）所需要的灾难恢复（DR）投资有关：即多久备份一次数据，恢复时间目标（RTO）是什么，在出现计划外停机时，需要多长时间可以让服务恢复上线运行。换言之，多久备份一次系统，多久复制一次系统状态？IT系统在发生故障之后需要多长时间能恢复运营？一个实际的例子是：Cisco的IT部门用关键性索引对构成应用和支撑依赖项的业务服务（例如，网络、网络服务、数据库和存储等）进行分类，分类的结果如表4-3所示。
这些分类也有助于判断企业是否愿意采用来自第三方厂商的“黑盒子”解决方案。包含企业知识产权的内部应用程序通常属于核心应用程序（差异系统或创新系统），对于这些应用程序，需要掌握其特征（制定基线，进行基准测试）并进行互操作性测试，以便第三方机构能够开发一个管理企业内部应用程序或服务的SLA（或者在企业内部的私有云，或者在企业外部的托管云，也称为混合云模型）。表4-3 弹性框架：服务关键等级，Cisco IT*主要功能：与组织的顶级目标直接对应的功能（例如，业务流程）。对Cisco来说，顶级目标是创收、盈利、成长。**一段时间：24小时或更长。
从基础设施资源的角度来看，计划将工作负载放在一个云服务平台上的时候，需要将基线性能和可伸缩性需求与基础设施的能力进行匹配。图4-3提供了这个概念的抽象表示。这样做的话，管理员就能迅速看清某个集成计算栈（ICS）或交付点（POD）是否能够支持某个应用程序工作负载，是否需要对基础设施进行某些增强才能满足这些要求。图4-3 应用程序到基础设施功能和容量的映射
在考虑使用云服务的时候（这里专指 IaaS），需要考虑应用程序或服务对于公司的关键性级别，它的核心程度，在以IT为核心的度量指标（例如性能、伸缩性）之外，还要考虑所需的信息保证等级。
如图4-4所示，这个三维模型的三个轴分别代表关键性、角色和信息保证。球代表服务或应用程序（我们称其为服务A）。在这个模型里，接近左上角的工作负载是“业务必需的”（以Cisco的IT定义为例），对于公司来说也是核心的（即，使公司在市场上形成差异）。最后，这些工作负载中包含的数据属于公司的机密，所以需要较高的安全等级（私密性和完整性）。图4-4 服务/应用程序三维映射
属于这一分类的工作负载不允许出现任何停机事件。必须时刻保持信息的私密性和完整性，只要其中的任何一个事件发生，那么信息泄漏导致的财务影响，即使对公司而言不是致命的，也是性命攸关的。
下面这些服务属性有助于确定相关的服务与服务产品属性之间的映射（此处指IaaS）。
■网络容器：定义了性能、可伸缩性、服务依赖项（属性和变量，定性的和定量的）。
■互联容器：定义了类型（OSI第2层或第3层）、连接类型，以及到远程数据中心的方法协议（例如，LISP、VPLS、OTV等）。
■安全区域：定义了安全态度、策略执行、决策点类型，以及它们的实现和操作。
■高可用性领域：定义了应用程序或服务的HA模型（例如，N+1），包括数据备份和保护服务。
■灾难恢复链路激活器：定义了RTO、RPO、优先级分类，初始化两个网络容器之间的灾难恢复服务。使用WAN连接的互联容器连接到远程灾难恢复数据中心站点。
图4-5展示了构成服务架构组成部分的服务能力。图4-5 服务架构能力的组成部分
秘诀在于：能够将服务产品（服务[等级]描述）换成特定工作负载需要的服务要求，并将两者关联起来。正如前面提到过的，非标准的定义和缺乏规范的参考，将这项工作变成了一件可怕的任务。最近，电信管理论坛（TMF）在服务定义的标准化方面做了一些工作。我们将在第5章中讨论市场的发展。
在具体的服务或应用程序的生命周期中，必需的服务属性可能各不相同。可以将这个过程描述为服务孕育阶段。例如，Cisco IT在转移应用程序通常要经过多个阶段：alpha、ACE、生产。每个阶段都有特定的治理规则。更通用的命名方式是：研发（R&D）、alpha和beta（测试）、最终全面可用（GA）或生产。
之所以出现所有这些复杂性，都是因为我们正在将传统的企业级面向服务的架构（SOA）映射到新的基于 Web/云的横向服务平台。这个遗产会伴随我们相当长一段时间，就像许多主机应用程序今天仍然伴随我们一样。“云经济学”的法则及相关的横向扩展架构原则（例如设计故障）还需要经历一段时间才能实现，为云模型构建的新一波应用程序将缓慢地接手现有应用程序的工作负载。在中间过程中，我们必须将现有的应用程序向新的云运营范式转换，最终实现标准化和灵活性这两个对立又统一的目标。
试读结束[说明：试读内容隐藏了图片]