详情
本书全面彻底地解释了策略驱动型数据中心的架构，概念和方法。基于丰富的企业行业经验，提出了针对虚拟化数据中心，高性能计算，超低延迟环境，和大规模数据中心的有效的解决方案。除了讨论相关的概念和方法，作者还针对硬件，拓扑结构，自动化和可扩展性进行了相关的设计考虑。本书涵盖了关键技术的概念，包括Python脚本和REST在内的最新的数据中心使用工具，全新的设计理念和现代交换矩阵的方法。
书名：策略驱动型数据中心——ACI技术详解
ISBN：978-7-115-38768-4
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
• 著 [美] Lucien Avramov [意] Maurizio Portolani
译 刘 军 周 超
责任编辑 赵 轩
• 人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
网址 http://www.ptpress.com.cn
• 读者服务热线：(010)81055410
反盗版热线：(010)81055315
The Policy Driven Data Center with ACI: Architecture, Concepts, and Methodology
Lucien Avramov and Maurizio Portolani
Copyright@ 2015 Cisco Systems, Inc.
本书中文简体字版由美国Cisco Press授权人民邮电出版社出版。未经出版者书面许可，对本书任何部分不得以任何方式复制或抄袭。
版权所有，侵权必究。
从业二十余载，我亲身经历了中国企业网络由“无”到“有”，由追随欧美先进企业之“形”到取领先实践之“意”，由“粗放管理”到“卓越运营”的巨变。欣然之余，伴随着对企业网络“供”与“需”两方之间的更深层次接触，我感受到从业者与业务方之间的“距离”感在增大。与数据管理、应用开发等IT的其他领域相较，企业网络近年来缺乏“质”的革新，始终围绕着“盒子”在做文章，越做越专，却且行且远。一方面网络技术专业性令系统管理员和开发人员都望而生畏，另一方面网络资源难以做到云时代“按需获取”、“自如扩展”的要求，更不必说和应用与业务事实上的“脱媒”。毫不夸张地说，自IP一统企业网络天下以来，这个行业再一次站在了“不破不立”的三岔路口。
思科在2013年末推出了ACI解决方案，以从应用出发的视角构建企业级数据中心网络，通过开源开放的方式来包容云化的基础架构资源，更重要的是具化网络与应用、与业务之间的关联，从而凸显网络对于企业的价值。当然，天下没有免费的午餐，企业网络从业人员需要用全新的视角来审视自身的工作，从枯燥的网络协议和命令行中抬起头来，更多地去理解企业应用和背后的技术架构，从思考“How：怎么实现”到更多思考“Why & What：为什么实现 & 实现什么”。
ACI（Application Centric Infrastructure，以应用为中心的基础架构）的出现，引领了网络行业，尤其是SDN新的发展趋势，并得到了业内的积极响应，为此这本关于ACI的技术专著也于2014年末孕育而生，本书同时还是思科公司成立30周年纪念特别版。
作为20年来中国市场和客户值得信赖的合作伙伴，思科中国公司在第一时间组织并推动了该书中文版的出版，以最快速度将这一革命性的网络新技术与中国客户分享。以实现“思科将一如既往地为中国客户提供全球最领先的技术与最佳实践经验，助力客户实现更大的商业价值与创新，为消费者打造前所未有的全新体验，并与客户一道，共同推动中国信息通信产业的变革”的“互信互励，相益相成”的承诺。
我希望读者能在学习ACI这项企业网络近年来最重要的革命性技术的同时，能够思考网络从业人员如何增添自身价值，实现“破局”。
——思科全球副总裁，大中华区企业业务部总经理，张思华
以应用为中心的基础架构（ACI）是思科一次前所未有的战略布局，在IT市场建立了一个新的标准，更为广大客户提供了新的承诺、新的前景。它不仅仅是一项技术或产品的创新，更是一种思维模式的转变。
今天行业转变正从各个层面重新定义IT。众所周知，企业内部IT消费模式正逐步转变为使用云服务。传统IT采用孤立的操作视图，应用、网络、安全、服务器、存储之间没有关联的操作模式将被云架构通用的操作模式取而代之。以硬件为中心的管理模式正在迁移到以应用为中心的管理模式。
而业界对SDN的情有独钟正是因为它的概念基于开放、可互操作、可控性、高度可编程性、可扩展性、灵活性等优势。从某种程度上看，SDN是对传统网络硬件产品模式的巅覆。它正确地提出了一个全新的理念。
思科的ACI正是在这样的背景下孕育、开发并投入市场，它真正地将SDN的概念付诸实现，并创立了新的网络架构和运维思路。ACI改变了传统以硬件为核心的产品和服务策略，它提供一个具有集中式自动化功能和策略驱动型应用配置文件的整体架构。ACI的核心基础是以提供开放式软件灵活性和硬件扩展性有机的结合方式管理和运营支持网络。
本书的两位专家作者Lucien Avramov和Maurizio Portolani是我多年的思科同事和朋友，他们参与了ACI的设想、概念、硬件及软件的开发、整体架构的部署和测试，同时花费了很多精力及时间撰写本书，非常高兴看到本书的问世，更为其中文版作序而感到荣幸。
本书涵盖了数据中心很多相关技术领域，如服务器、网络、存储、虚拟化、安全和运维。前半部从数据中心的架构，云架构的建立谈到ACI如何实现完整的策略驱动管理模式，虚拟和物理的集成，以及ACI（APIC）和OpenStack的集成合作及运营管理优势。后半部则着重探讨了ACI的网络设计思考，服务的嵌入，自动监测等。最后具体介绍了硬件设计。这是一本由浅入深、内容丰富的综合技术专业书，能帮助广大读者深入了解目前实现SDN的最佳实践方案ACI。更希望国内的同行、IT专家和思科一起来探讨和描绘ACI的蓝图。
——思科大中国区首席技术执行官 曹图强
中国的企业网络建设至今有20多年的历史，我们作为第一代的网络“攻城狮”也经历和见证了整个过程。记得曾经有一段时间大家也在谈论所谓“建设企业信息高速公路”的话题。通俗的比喻是：只要把网络建设得足够快（像高速公路一样），不管上面跑什么样的应用（车），都应该没问题。可我现在看看窗外的北京长安街及交汇东三环的CBD地区：路足够宽了-6车道或8车道，可怎么还是那么堵车呢？车是比以前多了许多，但比起其它国际大城市来说应该还是可以承受的。回想起来，我们企业的传统应用在信息化初期受到当时条件的限制，应该说对网络带宽和服务的要求还是比较“节俭”的，而且更关键的是信息流的方向上比较单一；而在现在的企业数据中心中新的“大容量”应用不断上线，东西向的数据流的迅猛发展，对承载的网络来说提出了前所未有的要求和挑战。这时候我们是否要重新审视：什么是网络设计与建设的重要依据？最终这是一个网络为什么服务的问题。
网络当然是要为应用服务 - 其实这也是一个比较显而易见的答案。围绕应用的需求和发展，即以应用为中心，我们更加精细地理解未来网络的特征，未来网络所应具备的服务和策略上的特性，这才应该是未来网络设计的基础。
同时，软件定义网络（SDN）作为网络方面一个大的变革趋势，已经在过去的几年里被热烈地讨论着，但最终在企业网络中还没找到合适并具有重大业务影响力的场景，一直还处于实践的摸索阶段。其实我们的一些客户谈到：他们日常压力最大的就是新应用的上线- 通常要经过几个月的努力，从准备硬件软件环境，到测试验证和压力，都要协调IT各个部门（应用、系统、网络、安全，等等）的共同努力。而且一旦业务上线，特别是初期，一定要严密监控应用运行的状态和健康状况，这又演变成一个常态的压力。
Application Centric Infrastructure（ACI）是实际上结合以上的需要，提供给企业用户一个更加针对应用的、商用的SDN环境，可以根据应用对于网络的连接，策略及服务等方面的需要给予快速的响应，并配合虚拟化实施，从而使新应用的部署时间从几个月缩短到几周，几天甚至几小时。
现在企业尤其是大型企业用户已经在考虑（或已在进行）云计算的实施，一个开放的、开源的云管理平台也是其中非常重要的组成部分。这对原本“简单”的网络提出了更高的要求，同时也拉近了网络和应用的距离。
针对这些问题，我们希望在书中可以找到答案。
——思科中国企业技术总监 苏哲
组织：思科系统
年营收：近500亿美元
位置：加利福尼亚州，圣荷西
挑战：优化思科的数据中心（其中运行着4000多个生产应用），使其能够快速、安全且低成本地部署关键业务应用。
随着新应用（特别是来自云和移动环境的新应用）成为主要业务推动因素，思科面临的挑战也困扰着越来越多的企业IT部门。传统的IT基础架构阻碍或放缓了企业对应用的部署，不仅是一些新应用的部署，即使是对现有应用的升级也是一大难题。
面对挑战，思科给出了漂亮的解决方案——以应用为中心的基础架构（ACI）——来完成数据中心的升级和转型。ACI将软硬件、系统和专用集成电路芯片（ASIC）中的创新与基于开放式API的动态应用感知网络策略模型完美结合在一起，可将应用部署时间从数月缩短至几分钟。
从ACI诞生之日起，它就不是一个自我封闭的系统。思科通过开放API，引入管理、协调、控制、虚拟化、网络服务和存储合作伙伴，形成了一个开放有活力的ACI生态系统，其中包括NetApp、Citrix、EMC、VMware、BMC、Red Hat、Microsoft、IBM、SAP、Symantec和F5 Networks 等。同时思科致力于与开源社区OpenStack、OpenDaylight、Open vSwitch等合作，带来了丰富的ACI扩展。作为新一代数据中心的基础架构，ACI得到了行业的广泛认可。
需要特别指出的是，随着新一代数据中心架构的演化，设计和管理数据中心所需要的IT技能也正在发生着快速的变化，除了传统的CCIE网络知识，ACI所需要的Python编程、自动化脚本和基于REST的Web服务模型正逐渐成为网络工程师和架构师的核心技术技能。
本书是业界第一本详细介绍思科ACI架构的原理，软硬件结构和用户实例的专著。阅读本书将会是一个相当有趣的体验，作者将新一代数据中心的架构设计原则、概念和方法娓娓道来，让读者深入理解思科创新思维的来龙去脉，更好地掌握新一代数据中心的建设和运维。
——思科全球研发总监 鲁子奕
纵观网络控制的发展历史，您可能想知道为什么如此简单的概念中出现了如此高深的复杂度。网络管理系统在传统上专注于控制功能，而未将网络视为系统。从核心上讲，任何网络控制方案的目的都是为解决两件事：终端行为控制和路径优化问题。终端行为控制也称为访问控制，在此领域已经有了许多规则来控制哪些终端集能否通信；路径优化问题通过管理众多网络控制平面协议来帮助解决。不幸的是，这种自然的分离已很少有实现了，最终得到的控制模型不仅难以使用，而且在运营上又很脆弱。
IT不是为了其自身的利益而存在的。任何IT组织的目的都是运作业务应用。应用所有者、架构师和开发人员都非常了解他们的应用。他们完全了解应用的基础架构需求和通信所需的其他应用组件。但是，一旦涉及部署，所有这些知识、初衷就会永远埋藏在应用需求与基础架构的实际配置之间的转换实现的细节中。由此导致的不幸后果是，无法轻松地将资源和配置映射回应用。现在，如果需要扩展应用，添加更多组件，或者只是从数据中心撤销它，该怎么办？余下的配置会发生什么？
在我们创立Insieme时，首要的目标之一就是要让以下不需要理解网络的人们能够使用它：需要识别其应用如何与数据中心的其他应用组件交互的应用开发人员，需要配置集群扩展的操作人员，需要确保没有企业级的业务规则被违反的合规性管理人员。我们认为，需要转变运营团队与网络交互的方式，这样网络才能在演进中进入下一个逻辑发展阶段。
Lucien 和 Maurizio 阐述了新的策略驱动型数据中心和与它相关联的运营模型。一方面，本书将重点介绍构建现代数据中心来打破此范例所涉及的架构、概念和方法；另一方面，还会详细介绍思科ACI解决方案。
——思科全球杰出工程师、首席科学家兼Insieme Networks联合创始人，Mike Dvorkin
Lucien Avramov：
感谢亲爱的父母Michel和Regina奉献了一生，给了我更好的未来。
Maurizio Portolani：
谨以本书献给我的好友和家人。
思科给网络界带来了本行业历史上最重要的变革之一：策略模型。策略模型通过思科ACI（以应用为中心的网络架构）解决方案和产品来实现。策略模型是近几年来讨论得最为火热的话题，这种概念有可能将网络配置从传统的VLAN、IP和ACL构架转变成更加抽象的模型。
作为本书的作者，我们非常感谢刘军和周超为将本书推向中国市场而做的辛勤工作。我们希望能够为您，在这个网络行业，特别是从数据中心开始发生重大变革时做好准备工作，并相信本书的知识也会扩展到其他很多网络实际应用案例中。
我们希望您能充分利用已有的ACI脚本，以及GitHub上已有的应用，并且也能贡献您自己的代码。
Lucien Avramov和Maurizio Portolani
Lucien Avramov（CCIE 19945），思科资深技术营销工程师。Lucien的技术专长是Nexus数据中心产品和ACI技术。Lucien设计过世界各地的数据中心网络，在交换机架构、QoS、超低延迟网络、高性能计算设计和OpenStack领域拥有丰富的经验。Lucien是Cisco Live大会的杰出演讲者和前TAC技术主管，拥有多项行业认证，撰写过IETF的RFC，还拥有一项有效的技术专利。Lucien拥有计算机科学硕士学位和法国阿莱斯国立高等矿业学校通用工程专业学士学位。在闲暇时，Lucien 喜欢在世界各地徒步旅行、骑自行车和跑马拉松。读者可在Twitter上@flying91找到他。
Maurizio Portolani，思科全球杰出技术营销工程师，专长从事数据中心网络设计。他作为联名作者编写了Cisco Press的《数据中心基础》一书，拥有多项有关最新数据中心技术的专利。他曾就读于都灵理工大学（工程学学士）和巴黎中央理工大学（工程师文凭），主修电子学。
Tom Edsall是思科Insieme事业部的首席技术官、思科科学院院士，以及Insieme Networks的联合创始人，同时也是以应用为中心的基础架构产品的开发主管，负责系统架构和产品的传道授业解惑。Insieme Networks在Network World中被描述为“过去18个月中网络行业最令人期待的事件之一”。之前就有消息透露说，思科投资创建了这家孵化公司来应对软件定义的网络趋势。在Insieme（最近被思科回购），Edsall领导了以应用为中心的基础架构（ACI）的开发，这包括组建应用感知交换矩阵的新的Nexus 9000交换机系列，以及同时管理虚拟和物理网络基础架构的集中控制器。
Tom 自1993年起就一直效力于思科，期间曾短期担任过孵化公司Andiamo Systems（开发SAN交换机）的CTO兼联合创始人。作为思科顶尖的交换机架构师之一，他一直负责MDS、Nexus 7000及Catalyst 5000和6000产品线的设计。他设计的两款产品Catalyst 6000和Nexus 7000获得了著名的思科先驱奖（Cisco Pioneer Award）。在此期间，他在网络行业获得了70多项专利，最近作为作者之一，他所撰写的论文《CONGA：数据中心的分布式拥塞感知负载均衡技术》获得了SIGCOMM 2014年最佳论文奖。
加入思科之前，Tom是Crescendo Communications（思科收购的第一家公司）的联合创始人及高级工程管理团队成员。Edsall拥有斯坦福大学的BSEE和MSEE学位，他还是该校的访问学者和特约讲师。
Mike Cohen是思科产品管理总监。Mike的职业生涯始于VMware虚拟机管理程序团队的最初的工程师，随后在Google和Big Switch Networks从事基础架构产品管理。Mike拥有普林斯顿大学电气工程专业的BSE学位，以及哈佛商学院的MBA学位。
Krishna Doddapaneni负责ACI的交换基础架构和iNXOS部分的研究。之前他在SAVBU（思科）（收购公司Nuova Systems的一个部门）担任总监。在Nuova Systems，他负责实现第一代FCoE交换机。他负责开发过多代Nexus 5k/2k产品线。在加入Nuova之前，他是Greenfield Networks（被思科收购）的第一位员工。他拥有德州农工大学计算机工程专业的理学硕士学位。他在网络领域拥有许多专利。
感谢Mike Dvorkin、Tom Edsall和Praveen Jain创立了ACI。
Lucien Avramov：
首先，感谢我的家人、好友、同事、客户和导师在写作期间对我的支持，使我真正了解自己。这对我很重要。感谢Mike Dvorkin分享自己的知识、人生观和友谊。感谢好友Mike Cohen总是抽空并愿意辛勤地审阅和发表自己的观点。感谢Tom Edsall提供了宝贵的反馈意见并为我们这个项目预留了足够时间。感谢Takashi Oikawa的善意和睿智。在写作期间，我结交了许多朋友并留下了难以置信的共同回忆。写一本书基本上是个人的一场独自旅行，其回报就像登上顶峰一样。在与合著者共同写作时，旅程会变得更充实：我很幸运在此过程中结识了一位好友，Maurizio Portolani。
其次，感谢Ron Fuller介绍我荣幸地参加本书项目。感谢我在思科的同事一路上为我提供支持：感谢Francois Couderc分享了宝贵的知识，花时间思考本书的章节安排，提供建议和审阅；感谢Chih-Tsung Huang、Garry Lemasa、Arkadiy Shapiro、Mike Pavlovich、Jonathan Cornell和Aleksandr Oysgelt一路上的鼓励、审阅和支持。深深感谢Cisco Press的团队：Brett Bartow的和蔼可亲、随叫随到和耐心对我很重要，让我有机会编写本书。感谢Marianne Bartow花了大量的时间进行质量评审。感谢Bill McManus进行编辑。感谢Chris Cleveland一路上的支持。感谢Mandie Frank做的所有工作，包括让此项目按时完成；感谢Mark Shirar在设计上提供帮助。
最后，感谢在我的专业生涯中给予我机会的人，首先是Jean-Louis Delhaye在Airbus多年来为我提供的指导并自那时起成为我的好友，Didier Fernandes在思科给予我引荐和指导，Erin Foster给予我机会加入思科并将我调到美国，Ed Swenson和Ali Ali在Cisco TAC为我提供了一份全职工作，John Bunney带着我一起组建TAC Data Center团队并给予我指导。感谢Yousuf Khan给予机会，先加入技术营销团队，后加入Nexus团队，最终加入ACI团队，并在此过程中为我提供指导；感谢Jacob Rapp、Pramod Srivatsa和Tuqiang Cao引领并开拓了我的职业生涯。
Maurizio Portolani：
我个人想要感谢许多人，他们让我拓展了视野，看到了与ACI给网络带来的变化密切相关的现代软件开发方法和技术。特别感谢Marco Molteni在XML与JSON和Yaml的技术对比方面提供深入的哲学观点，以及在GitHub和Python方面给予我的启发。我还想特别感谢Amine Choukir带来在持续集成上的洞察力，以及Luca Relandini带来自动化方面的专业知识。
欢迎您阅读本书。您即将踏上了解最新的思科数据中心矩阵及其所蕴含的众多创新的旅程。
本书的目的是阐述构建新一代数据中心矩阵所涉及的架构设计原则、概念和方法。本书的一些关键概念，例如策略数据模型、编程和自动化，它们的适用领域已经超越了 ACI技术本身，构成了网络工程师和架构师的核心技术技能集。
思科以应用为中心的基础架构（ACI）是一种数据中心矩阵，可帮助您在高度可编程的多虚拟机管理程序（Hypervisor）环境中集成虚拟和物理工作负载，该环境是专为任意多服务或云数据中心而设计的。
要全面理解ACI的创新之处，需要理解网络领域关键的新行业趋势。
编写本书时，网络行业中的新的运营模式不断涌现。其中许多变化深受服务器领域或应用领域中出现的创新和方法的影响。
下面列出了当前影响新数据中心设计的部分趋势。
其中一些趋势被统称为“应用加速”，这是指以比以往更快的方式建立新服务器和网络连接，缩短应用从开发到生产（以及在需要时返回到测试）的周期的能力。
根据使用“应用”这个词汇的人的周围环境或工作角色的不同，其含义会有所不同。对于网络专业人员，应用可能是DNS服务器、虚拟化服务器、Web服务器等。对于在线订购工具的开发人员，应用是订购工具本身，它包含多种服务器：演示服务器、数据库等。对于中间件专业人员，应用可能是IBM WebSphere环境、SAP等。
出于本书的目的，在思科ACI上下文中，应用指的是为一组给定的工作负载提供连接的一组网络组件。这些工作负载的关系就是ACI中所说的“应用”，该关系由ACI所称之的“应用网络配置文件（将在图1之后介绍）”来表示。
图1 “应用”的示例
图1提供的示例演示了某个应用，它可从公司内联网访问，并连接到提供了一些业务功能的外部公司。例如，这可能是一个差旅预定系统、订购工具、计费工具等。
在 ACI 中，此关系可使用应用网络配置文件（ANP）的概念来表示，该概念是对组建模块所在的特定VLAN或子网的抽象。网络连接的配置使用策略来表示，策略定义哪些终端使用（或提供）其他终端所提供（或使用）的服务。
使用ACI不需要深入理解这些应用关系。这些关系常常以VLAN和访问控制列表的方式隐含在现有的网络配置中。因此，可只使用ANP和相关策略作为现有配置的容器，而无需映射到精确的服务器与服务器间的通信模式。
ANP 的使用价值是，它使网络管理员能够以更抽象的方式表达网络配置，网络配置与业务应用（比如订购工具、差旅预定系统等）的组建模块具有更密切的对应关系。定义应用后，可在测试环境中对它们进行验证并立即迁移到生产环境。
即使没有 ACI，各种应用如今也可以在数据中心运行。网络管理员通过使用VLAN、IP地址、路由和 ACL 来在组建模块之间建立连接，转换 IT 组织支持给定工具的需求。但是，没有ACI，管理员就无法真正以与网络具有对应关系的格式来直接表达这类配置，他们唯有选择表达一种非常开放的连接策略，确保公司内部的服务器可彼此通信，DMZ或外联网上的服务器可与外部通信。这需要管理员加固 ACL 和设置防火墙，限制服务客户端和其他服务器在一组给定服务器中的访问范围。
此方法所产生的配置不是很容易移植。它们在实现它们的特定的数据中心环境硬编码。如果必须在不同的数据中心中构建同样的环境，则必须执行重新配置IP地址和VLAN并判读ACL这样的单调工作。
ACI彻底改良了这一过程，引入了创建应用网络配置文件，创建配置模板来表达计算网段之间的关系的能力。然后，ACI将这些关系转换为路由器和交换机可实现的网络构造（例如VLAN、VXLAN、VRF、IP地址等）。
思科ACI矩阵由一些独立组件组成，这些组件发挥着路由器和交换机的作用，但却是作为单个实体来配置和监测。它的操作类似于一种分布式的交换机和路由器配置，提供了高级的流量优化、安全性和遥测功能，将虚拟和物理工作负载缝合在一起。控制器称为应用策略基础架构控制器（APIC），是该矩阵的中央管理节点。此设备将ANP策略分发给该矩阵中所包含的设备。
思科ACI Fabric OS在该矩阵的组建模块上运行，在编写本书时，这些组建模块是思科Nexus 9000系列节点。思科ACI Fabric OS是面向对象的，支持针对系统的每个可配置元素来执行对象编程。ACI Fabric OS将策略（例如ANP和它的关系）从控制器呈现到一个在物理基础架构中运行的具体模型中。这个具体模型类似于已编译的软件；它具有交换机操作系统可执行的模型形式。
思科 ACI 的设计适用于许多类型的部署，包括公有云和私有云、大数据环境，以及众多虚拟和物理工作负载的主机托管业务。它提供了几乎实时地具现化新网络和同样快地删除它们的能力。ACI旨在简化自动化，可轻松集成到通用编排工具的工作流中。
图2演示了包含主干-叶节点架构和控制器的ACI矩阵。物理和虚拟服务器可连接到ACI矩阵，也可接收与外部网络的连接。
图2 ACI矩阵
思科ACI引入了以下众多创新。
第1章：数据中心架构考虑因素
本章介绍不同服务器环境的网络需求，以及如何在网络设计上满足它们。
第2章：云架构的组建模块
在编写本书时，大多数大规模数据中心部署都是按照云计算原则设计的。不管是运营商还是大型企业，他们所构建的数据中心都是如此。本章演示构建云的设计和技术需求。
第3章：策略数据中心
本章阐述对业务应用进行建模的思科ACI设计方法。此方法提供了将软硬件功能映射到应用部署的独创方法组合，可以是通过思科应用策略基础架构控制器（APIC）GUI来图形化地映射，或者是通过思科APIC API模型以编程方式映射。本章将详细介绍APIC概念和原则。最后，ACI矩阵不仅适用于全新部署，许多用户还会考虑如何将ACI矩阵部署到现有的环境中。因此，本章最后一部分介绍如何将ACI矩阵与现有网络相集成。
第4章：运营模型
命令行界面（CLI）是对配置进行交互式更改的好工具，但它们的设计既不利于自动化，也不利于轻松地解析（CLI抓取既不高效又不实用）或自定义。此外，CLI没有能力与Python 等复杂脚本语言可提供的解析能力、字符串操作或高级逻辑抗衡。本章介绍新管理员和操作员必须熟悉的关键技术和工具，还将介绍如何在基于ACI的数据中心使用它们。
第5章：基于虚拟机管理程序的数据中心设计
本章介绍在数据中心使用虚拟机管理程序时的网络需求和设计考虑因素。
第6章：OpenStack
本章详细介绍OpenStack及其与思科ACI的关系。本章的目的是解释OpenStack的概念，提供思科ACI APIC OpenStack驱动程序架构的详细信息。
第7章：ACI矩阵设计方法
本章介绍 ACI 矩阵的拓扑结构，以及如何以基础架构管理员和租户管理员身份来配置它。本章的内容涵盖物理接口、PortChannel、虚拟PortChannel和VLAN命名空间的配置，这些都是基础架构配置的一部分。本章还会介绍租户配置中的分段、多租户、与物理和虚拟服务器的连接，以及外部连接等议题。
第8章：在ACI中实现嵌入式服务
思科ACI技术提供了使用服务图的方法来实现4层至7层功能的嵌入式服务。业界通常将在终端之间的路径中嵌入4层至7层设备的能力称为服务嵌入。思科ACI服务图技术可被视为嵌入式服务的超集。本章介绍服务图概念，以及如何使用服务图来设计嵌入式服务。
第9章：高级遥测
本章介绍了ACI提供用来隔离问题的集中化故障排除技术。本章包含原子计数器和健康评分等议题。
第10章：数据中心交换机架构
本章详细解释了数据中心交换机的架构。本章内容分为3节：硬件交换机架构、数据交换的基本原理和数据中心的服务质量。
节点：物理网络设备。
主干节点：放在数据中心核心部分的网络设备，它通常是具有高密度端口和较高速率的设备。
叶节点：位于数据中心接入层的网络设备，它是定义数据中心网络矩阵的第一层网络设备。
矩阵：一组叶节点和主干节点，它们一起定义数据中心网络物理拓扑结构。
工作负载：虚拟机，用来定义单个虚拟实体。
双层拓扑结构：通常由主干-叶节点矩阵拓扑来定义。
三层拓扑结构：包含接入层、汇聚层和核心层的网络拓扑结构。
服务：由以下设备（未穷举）定义的类别：负载均衡器、安全设备、内容加速器、网络监控设备、网络管理设备、流量分析器、自动化和脚本服务器等。
ULL：超低延迟。其特征是网络设备的延迟低于1微秒。目前的技术可达到纳秒级别。
HPC：高性能计算。使用结构化数据方案（数据库）或非结构化数据（NoSQL）的应用，其中性能的可预测性、低延迟和扩展性很重要。流量模型是东西向的。
HFT：高频交易。通常发生在金融交易环境中，要求数据中心矩阵上的延迟达到最低，以便向最终用户提供尽可能实时的信息。流量模型是南北向的。
Clos：多级交换网络，有时称为“胖树”，来源于Charles Leiserson在1953年发表的一篇论文。Clos的理念是构建一个超高速、非阻塞的交换矩阵。
本章介绍数据中心架构所需考虑的因素。其中将介绍设计时的考虑因素和设计过程中使用的方法，以便对于数据中心矩阵项目，使架构师能高效地选择端到端的网络设计，为其演进提供所需的增长能力。
在数据中心网络设计过程中，在架构选择和最终设计方面需要注意以下一些关键考虑因素。
大多数的数据中心矩阵部署是用于虚拟化数据中心的。本章还介绍了数据中心的其他应用场景：大数据、超低延迟、高性能计算和超大规模数据中心。数据中心呈现出朝主干-叶节点架构发展的趋势，该架构是全书中介绍的以应用为中心的基础架构（ACI）的组建模块。
设计数据中心时，最常见的方法是使用三层方法。此方法包括经典的接入层、汇聚层和核心层，常被称为三层拓扑结构。数据中心设计正在从这种三层方法向更特定的数据中心演变，呈现出朝两层主干-叶节点架构发展的现代趋势。理解数据中心的不同技术趋势和项目需求，将引导读者考虑设计中的多个基本问题。这种理解将给读者以关键的知识来帮助设计最佳的解决方案，从而满足数据中心项目的需求。本节介绍当前实现端到端数据中心设计的推荐方法。
本章将介绍如何使用最新的设计方法来满足以下工作负载类型的需求。
许多数据中心都拥有上述几个类别的工作负载组合。对于这些类型的数据中心，需要构建一种多用途的矩阵；例如，基于思科Nexus 9000交换机系列产品的矩阵。
现代数据中心包含大量虚拟化服务器。本章将介绍针对虚拟化工作负载的设计考虑因素。
虚拟化数据中心占目前数据中心矩阵项目部署的大多数。这些部署包括小型、中型商业企业，以及大型企业。完整的思科数据中心矩阵产品系列被广泛使用，从虚拟机管理程序级交换机（例如Nexus 1000v）到Nexus 9000产品系列，包括拥有刀片机箱服务器或机架式服务器的思科统一计算系统（UCS）服务器。光纤通道存储是整合在以太网上的，可与其他以太网流量和IP流量共存。还可使用NFS存储流量来存储虚拟机（VM）。FCoE并不是必须的；许多虚拟化数据中心的部署都使用IP存储。
虚拟化数据中心是围绕着一种或多种必须共存的或通信的虚拟机管理程序类型而构建的。该数据中心网络不仅需要处理虚拟化流量，而且它还必须是高度可用的。它需要在发生工作负载移动事件时最大程度地减少VM中断，例如当VM需要转移到另一台主机上的时候。不同虚拟化数据中心的一个重要区别在于网络矩阵本身。第一条连接到架顶式（ToR）交换机的电缆在某种意义上讲已属于“矩阵”，因为它承载着从多台主机传输到连接的第一台物理网络设备的流量，这台设备是ToR或接入交换机。连接的第一台交换机现在可能会是一台虚拟交换机设备。：例如vSwitch、vEthernet、vNIC等带有字母v前缀的每个熟知的网络设备。
构建数据中心网络矩阵时，一定要考虑到将来会在每台主机上运行的虚拟机数量和应用数量，这些信息可为使用超载比提供指导。虚拟化具有多个层面。例如，运行虚拟环境的云提供商可能允许其用户也运行自己的虚拟机管理程序。这会创建出一个处理多个虚拟化级别的数据中心环境。因而不同封装的数量将得以扩展。这会在虚拟机管理程序内创建更多层级，当连接到第一个虚拟访问端口时，在这些层级中的不同属性（服务质量QoS、带宽限制、安全、端口镜像等）会被实现。
在虚拟化层中，不同类型的流量都可以作为IP或以太网的应用流量，例如视频、语音和存储。因此，虚拟化数据中心设计会使用各种QoS功能来对使用和连接第一台ToR交换机相同的上行链路的各种流量模式提供不同的优先级。在虚拟化数据中心运行的典型应用类型常常采用所谓的三层应用模型：由特定的应用、数据库和Web服务器组合而成。每一层通常运行在一台专门的虚拟机上。在企业部署中，数据库常常托管在裸机服务器上。
数据中心的虚拟化不仅仅限于服务器。因此，现代数据中心使用以下技术。
服务器虚拟化是最常见的硬件虚拟化类型。在运行单个操作系统及其应用时，目前的x86计算机硬件在很大程度上并未得到充分使用。借助虚拟化，通过在同一台物理计算机上运行多个虚拟机和应用，硬件资源就能得到更有效的利用，如图1-1所示。物理服务器与虚拟机之间存在着一个虚拟机管理程序软件层，用于模拟在逻辑上与真实物理主机服务器隔离的专用物理计算机。它允许多个操作系统共享一台硬件主机，同时运行相互独立的功能和应用。虚拟机以文件形式存储，这使在相同或不同的物理主机上的自愈功能成为可能。由于服务器虚拟化优化了数据中心项目（也称为整合项目），因而物理服务器能得到更高效的使用。
图1-1 服务器虚拟化
存储虚拟化是特定数据中心项目中所有物理存储设备的一种逻辑和抽象的视图。用户和应用通过存储虚拟化来访问存储，而无需知道存储位于何处，如何访问或如何管理。这将进一步支持跨多个应用和服务器来共享功能：存储被视为一个没有物理边界的资源池。存储虚拟化适用于大型的存储区域网络（SAN）阵列，本地工作站硬盘驱动器的逻辑分区，或者独立磁盘冗余阵列（RAID）。存储虚拟化提供以下4个重要优势。
数据中心的服务虚拟化指的是一些服务设备的使用，例如防火墙、负载均衡器、缓存加速引擎等。数据中心对外显示的虚拟接口也称为虚拟IP地址，它表现为Web服务器。然后，该虚拟接口管理与Web服务器之间进行按需连接。负载均衡器提供了更可靠的拓扑结构和安全的服务器访问，允许用户将多个Web服务器和应用作为一个实例来访问，而不是采用每台服务器一个实例的方法。向外部用户显示一台服务器，将多台可用的服务器隐藏在一个反向代理设备之后。网络设备可以是物理的或虚拟的。在编写本书时，市场上有多种虚拟防火墙和虚拟负载均衡器。
虚拟化服务器还需要变更网络基础架构，才能保证虚拟机之间的隔离。其主要变化是服务器内的网络接入层转移到了虚拟机管理程序级别上，而在传统的裸机服务器上，从物理网线连接到的第一个访问端口，并一直到最终的服务器都是接入层。网络虚拟化可采用以下一种或多种技术。
编排指的是协调地配置虚拟化资源池和虚拟实例。这包括虚拟资源到物理资源的静态和动态映射，以及管理功能，例如容量规划、分析、计费和服务等级协议（SLA）。服务通常抽象为一个客户门户层，其中最终用户选择服务，然后该服务使用各种域和中间件管理系统并按以下步骤自动配置（如图1-2所示）。
图1-2 协调
在网络上使用虚拟化数据中心的影响包括下列内容。
虚拟化使NFS可用于存储虚拟机，使以太网光纤通道（Fibre Channel over Ethernet，FCoE）可用于存储虚拟机管理程序。目前的趋势是向IP存储以及虚拟机管理程序存储发展。正因为如此，高带宽容量或QoS对于保障存储阵列与生产计算节点之间的存储数据传输来说至关重要。
本节详细介绍大数据数据中心趋势。
Gartner和其他市场分析公司指出，大数据可由它的主要属性来粗略定义：数据量、速率、种类和复杂性。大数据由结构化和非结构化数据组成。尽管大量的记录都是结构化数据，并且常常高达数PB，但非结构化数据（绝大部分由人为生成）通常占总数据量的更大比例。多元化和一些生态系统因素导致了生成如此多的信息。
大数据是社交网络和基于Web的信息公司的基础元素。因此，大数据（尤其是来自于外部时）可能包含错误、不正确的内容和缺失。此外，大数据通常不包含唯一标识符。这些问题为实体解析和实体消歧带来了重大的挑战。对于通过关联邻近数据来为客户提供服务和实现服务差异化的Web门户和互联网公司来说，数据生成、使用和分析为他们带来了业务上的竞争优势。
一些对互联网极具影响力的公司出于以下原因使用大数据。
传统企业数据模型对应用、数据库和存储资源的需求逐年增长，这些模型的成本和复杂性也在不断增加，以满足大数据的需求。这一快速变化推动了描述大数据存储、分析和访问方式的基础模型的变化。新模型基于横向扩展、无共享的架构，给企业带来了决定使用哪些技术，在何处使用它们和如何使用的新挑战。不再有一体化适用的解决方案，传统的三层网络模型（接入/汇聚/核心）现在正在扩展，纳入了新的组建模块来解决这些挑战，使用新的专用信息处理框架来满足大数据需求。但是，这些系统还必须满足集成到当前业务模式、数据战略和网络基础架构的内在需求。
企业堆栈中业已增加了两个主要的组建模块来容纳大数据，如图1-3所示。
图1-3 大数据企业模型
一种趋势是将此数据存储在闪存或RAM存储器中，以供更快速的访问。NoSQL已变得更加流行，这是因为要处理的数据量比SQL类型的数据库结构更大。
大数据组件需要与企业当前的业务模式相集成。通过使用为大数据而优化的思科Nexus网络基础架构，可让这种新的、专用的大数据模型集成完全透明，如图1-4所示。
图1-4 大数据模型集成进企业网络架构
分而治之的策略，对多种处理大量数据的工作负载来说非常有效。一个大型工作负载可被拆分或映射到更小的子工作负载，然后通过合并、浓缩和化简来自子工作负载的结果来获取最终的结果。Hadoop的初衷是利用工作负载的这一功能，将更小的子工作负载分配给使用通用硬件搭建的廉价节点所组成的庞大集群，而不是使用昂贵的容错硬件。此外，处理大量数据需要存储空间。Hadoop采用分布式的集群文件系统，它可被扩展以容纳这些海量数据。集群的构建，使整个基础架构具有自愈和容错能力，尽管拥有极高的组件平均无故障时间（MTBF）比率，但是个别组件的失效，仍会显著降低系统级MTBF比率，如图1-5所示。
图1-5 集群设计
大数据应用采用分布式IP存储。它是共享文件系统，通常为NFS或直接附加存储（DAS）。该存储位于每个服务器节点上。大数据领域的一些高性能应用，类似于位于每个节点的易失性存储器（而不是硬盘）上的超低延迟应用存储。在此环境中也可以扩展为闪存硬盘。
一个能正常运行且具有自愈能力的网络对有效的大数据集群来说至关重要。但是，分析证明，网络以外的因素对集群的性能具有更大的影响。而且一些相关的网络特征和它们潜在的影响也值得考虑。图1-6显示了在广泛测试期间验证的主要参数的相对重要性。
网络设备的失效可能影响Hadoop集群的多个数据节点。然后，受影响的节点上的任务需要在其他正常运行的节点上重新安排，这就增加了它们的负载。此外，Hadoop基础架构可能启动一些维护作业，例如数据再平衡和复制，以弥补失效节点上的损失，这进一步增加了集群上的负载。这些事件是导致集群性能降级的关键因素。项目因为会需要更长的时间才能完成，这降低了安排新作业的能力。
图1-6 影响工作完成的参数的相对重要性
构建一个随时可用且具有自愈能力的网络很重要。首先需要关注网络架构：需要部署不仅提供了所需冗余，而且也可随集群增长而扩展的架构。允许在数据节点之间包含多个冗余路径的网络设计的技术，在本质上比拥有一两个故障点的技术更好。
架构框架布局好后，就需要考虑单台设备的可用性。运行经业内证明具有自愈能力的操作系统的交换机和路由器，会向服务器提供更高的网络可用性。可在不破坏数据节点的情况下进行升级的交换机和路由器，也提供了更高的可用性。此外，经证明易于管理、易于排除故障和升级的设备，有助于确保更短的网络宕机时间，从而提高了网络（进而增加集群）的可用性。
在Hadoop类型的大数据作业中，操作和过程将会是突发的。无法有效处理突发流量的网络将会丢弃数据包，因此设备需要优化缓冲区来承受突发流量。任何因缓冲区不可用而被丢弃的数据包都会导致重新传输，大量重传这些数据包会导致作业需要更长的时间才能完成。在选择交换机和路由器时，一定要确保其架构采用了可有效处理突发流量的缓冲区和队列策略。第10章“数据中心交换机架构”给出了突发和缓冲区使用的示例。
优秀的网络设计必须考虑到网络中的关键位置在真实负载下发生不可接受的拥塞的可能性。如果ToR设备从服务器接收20Gbps流量，但仅仅配置了两个 1-Gbps 上行链路（总共2 Gbps）（超载比为20:2或10:1），那么它就可能会丢弃一些数据包，导致糟糕的集群性能。但是，超载配置网络会需要很高的成本。一般可接受的超载比是，服务器接入层约为4:1，接入层与汇聚层或核心之间为2:1。如果需要更高的性能，应考虑更低的超载比。在某些设备发生故障时，如何增加超载比？确保为网络中的关键点（例如核心）配置了足够的资源。多路径技术，例如具有或没有VXLAN或ACI的3层等价多路径，会实现与每台设备的故障率呈线性关系的超载比增幅，这比在故障期间显著降级的架构要好。
必须为数据节点配置足够的带宽，以便高效地完成工作。还要记得在向节点添加更多带宽时所要求的性价比。一个集群的推荐配置依赖于工作负载特征。典型的集群会为每个数据节点配置一到两个 1-Gbps 上行链路。选择经证明具有自愈能力且易于管理，而且可随数据增长而扩展的网络架构，将会使集群管理变得更为简单。10-Gbps服务器访问带宽的使用主要取决于成本/性能的权衡。工作负载的特征和在规定的时间内完成工作的业务需求，决定了对10-Gbps服务器连接的需求。随着未来10-Gbps以太网板载网卡（LAN-on-motherboard，LOM）连接器在服务器上的更加普及，更多的集群会更有可能采用10Gb以太网数据节点上行链路。Nexus 2000矩阵扩展器（FEX）并不是Hadoop环境中的通用最佳实践。
可以看出，交换机和路由器延迟的变化对集群性能的影响是有限的。从网络角度讲，任何与延迟相关的优化都必须从网络级分析开始。“先架构，后设备”是一种有效的策略。与具有较高的总体延迟但较低的单台设备延迟的架构相比，在整体上始终具有较低延迟的架构会更好。应用级延迟对工作负载的影响比网络级延迟大得多，应用级延迟主要是由应用逻辑造成的（Java虚拟机软件堆栈、套接字缓冲区等）。在任何情况下，网络延迟的细微变化都不会给作业完成时间带来明显的影响。2层网络不是必须的。有些设计允许带有BGP或OSPF协议的L3在计算节点上运行。
本节详细介绍高性能计算数据中心趋势。
高性能计算（HPC）指的是整合了比常规工作站更高性能的计算能力，以解决工程、工业、科学、商业等方面的大型问题的工程实践。
网络流量在数据中心内通常为东西向的流量模式。规模性部署可通过POD模型来实现，此议题将在“设计考虑因素”一节中介绍。可预测性和超低延迟是关键。提供类似低延迟的数据中心网络矩阵（无论服务器是否连接到同一个机架、同一个集群或同一列中）都会减少HPC应用的计算时间。足够的吞吐量和缓冲区（能够随计算节点的增长而弹性扩展）是关键。
HPC和大数据在网络需求和设计上是非常相似的，其主要区别是：大数据基于IP，而HPC通常基于以太网而不是IP。相对于大数据而言，这限制了为HPC构建数据中心矩阵的选择机会。其他网络属性仍旧是相似的。可采用2层数据中心矩阵协议（例如思科vPC和VXLAN）来构建大型HPC集群。
HPC的网络需求可总结为如下所示。
当存储包含在每台主机上时；此模型称为分布式存储模型。存储由HPC应用处理。HPC存储通常不需要光纤通道，任何特定的存储网络也不受交换机上的地址约束。
流量可以是IP，也可以是非IP（在以太网上传输）。本书不会探讨非以太网的超级计算能力。借助如今的以太网技术，非以太网流量可以被封装并通过标准以太网介质传输到标准的、整合的以太网数据中心（例如，通过使用思科Nexus产品建立的数据中心）。思科的实现方法是构建基于以太网的HPC集群。
典型的HPC环境使用包含32个节点的集群。一个节点代表了机架式服务器中的一个逻辑实体，它拥有24核CPU和一张10-GE网卡。这为每个机架提供了768个CPU核心。典型的HPC环境初始时可以仅有一个包含32个节点的机架。通常的部署至少拥有4个机架，共有128个节点。
定义POD的大小很重要。项目的初始大小至关重要。随着项目的增长，可重复采用POD概念来添加更多HPC集群。本节中提供的示例演示了一个POD，它包含128节点的服务器和相应的交换机，它们形成了一个逻辑计算实体。
思科的HPC实现方法是整合了UCS-C机架式服务器和名为usNIC的特定HPC网卡。思科用户空间NIC (usNIC）提供了从Linux用户空间直接访问NIC硬件的能力。它通过linux Verbs API （UD）和OpenMPI实现了操作系统旁路机制。此NIC提供了1.7微秒的端到端延迟，还在512个CPU核上提供了高达89.69%的HPL效率。此NIC的优势取决于以太网标准，而不是RDMA网络介质的使用。请注意，RDMA解决方案可通过基于以太网的RDMA协议将思科Nexus交换机和ACI结合起来。iWarp是另一种能够加速的TCP协议，它的性能慢于usNIC。
HPC网络需要尽可能快速，以在节点之间提供尽可能低的延迟。在编写本书时，延迟最低的产品是思科Nexus 3548交换机，它可提供仅有190纳秒（ns）延迟的线速转发。它可用作叶节点层的ToR，也可在超载比足够时用在主干层上。网络矩阵需要承载以太网流量；因此，思科vPC和思科VXLAN等矩阵技术非常适合构建一个能够承载从任何主机到另一台设备的HPC流量的以太网矩阵。HPC设计的典型网络超载比为2:1。要想实现更低成本的设计，可增加超载比，最高通常为5:1。
在HPC拓扑结构中，典型的设计为一层或两层网络基础架构。这也可称为主干/叶节点设计类型，其中的主干发挥着汇聚设备的作用。设计拓扑结构的目的是在给定的服务NIC速率下提供必要的端口数量。最常见的是从接入层到网络层的10-GE设计；可使用40-GE上行链路来连接聚合设备。在选择设计时，必须考虑到端到端的延迟。图1-7描绘了可用于HPC集群的不同拓扑结构，它们可划分为10-GE矩阵和40-GE矩阵。这些矩阵都是非阻塞矩阵，拥有端到端、不含超载比的10-GE或40-GE速率。最佳实践是将10-GE服务器访问连接与40-GE主干交换机相聚合。
图1-7描绘了包含160个服务器节点的HPC集群，它使用了2:1的超载比。
图1-7 一个HPC集群示例，其中包含160个具有2:1超载比的节点
本节详细介绍超低延迟数据中心趋势。
超低延迟（ULL）数据中心设计是一场实现零延迟的竞赛。这些数据中心的目标是设计具有最低的端到端延迟的最快的以太网络。
将端口密度降到最低限度，对应用进行集群化，可以将每种环境的网络设备数量严格控制到最低。在大多数典型的ULL设计中，整个ULL数据中心的服务器端口数量都在500个以下。高频交易（HFT）环境是最具代表性的ULL数据中心，每个机架通常使用24到48个端口。HFT数据中心在交易所的数据中心设施上搭建，这样可以减少信息从交易所本身传递到HFT公司的延迟。
在HFT数据中心，必须尽可能快地以最低延迟从股票交易所获取信息。构建最快网络的能力使HFT公司能够向客户提供更有竞争力的解决方案。因此，HFT客户选择此公司而非另一家的主要标准是其数据中心的延迟。
HFT数据中心设计与其他设计具有很大的不同。例如，此环境中没有虚拟化，使用了具有内核旁路技术的NIC来最大限度地减少服务器处理端的延迟，并避免CPU延迟。在网络端，由于CX-1线（双绞线）比光纤使用距离长5米，故为首选。该设计常常是非阻塞性的，它提供了10-GE到40-GE的端到端速率。拥塞和排队对数据中心交换机的影响被尽可能地降低。如果要减少对缓存的需求，可将应用拆分到多台服务器上，以减少速率不匹配或网络设备上的多打一的流量等因素。东西向和南北向流量模式在网络中是分离的，通常位于不同的数据中心拓扑结构上。这消除了网络端对QoS的需求。在ULL环境中，所有设计都是为了避免对QoS的需求。
现在所获得的延迟几近于0，IP/以太网交换的性能延迟低至50纳秒，这是线路上最小帧的串行延迟：以10-GE的速率传输64字节（byte），而且减少数据中心交换设备延迟的主要工作已非常成熟。这使设计模式现在转为注重NIC、服务器、闪存以及最重要的应用优化。
图1-8演示了网络端上的不同组件以及中间件和应用的延迟的数量级。这并不是一个详尽的列表，只是一个帮助理解延迟水平的概览列表。
图1-8 延迟数量级
对于超低延迟，网络需求如下。
减少延迟的要求还催生了一个新的数据中心架构设计领域：数据分析。因为不可能改进无法度量的指标，并且低至1.5Mb的瞬时拥塞事件就可能导致1毫秒（ms）的网络延迟（这已是非拥塞期间交换机延迟的100万倍），所以监测也成为了数据中心的要求。以这样的超低延迟运行的生产环境需要监测。在应用出现问题时，数据中心运维团队必须检查网络，确定此问题是否发生在网络环境中（例如交换机缓冲区）。正因为如此，网络监测和以应用为中心的视图就变得非常重要了。
在HFT环境中，存储位于主机本地，遵循分布式模型。存储空间非常小，而且出于性能原因，在数据处理期间以RAM或闪存类型存储器形式仅存在于主机之上。HFT网络的备份存储也可使用诸如NFS/CIFS的集中化IP存储模型。
减少端到端数据中心延迟的10条设计原则如下。
本节介绍的两种主要的拓扑结构设计是源复制和HFT。
源复制提供了将市场数据信息复制到处理市场数据的不同目标服务器（称为源处理器）的最快方式。借助思科Nexus 3548，可用50纳秒的延迟实现从北向南的流量复制。源处理器进而从交易所的数据源接收流量，而网络附加的延迟只有50纳秒。返回流量（从南到北，用于订单交易）可实现190纳秒的延迟。这种设计的目的是最大限度地减少交易所的数据源与源处理器服务器之间的交换机数量、电缆长度等。图1-9描绘了包含Nexus 3548的源复制设计示例，其中从交易所的数据源传来的从北到南流量的交换机延迟可以低至50纳秒。借助思科Nexus 9000 独立式的架顶交换机，可实现约0.600微秒的性能；使用ACI交换机，延迟控制在1微秒范围内。
图1-9 源复制设计示例
在HFT拓扑结构中，典型的设计为一层或两层网络基础架构。这也称为主干/叶节点设计类型，其中的主干发挥着聚合设备的作用。设计拓扑结构的目的是在给定的服务 NIC 速度下提供必要的端口数量。最常见的是从接入层到网络层的10-GE设计。可使用40-GE上行链路来连接聚合设备。在选择设计时需考虑端到端的延迟。图1-10描绘了可用于HFT集群的不同拓扑结构，它们可划分为10-GE矩阵和40-GE矩阵。这些矩阵是非阻塞矩阵，拥有端到端、无超载比的10-GE或40-GE速率。最佳实践是将10-GE服务器访问连接与40-GE主干交换机相聚合。但是，引入的速率变化造成了in-cast缓冲区场景，这增加了并发对网络的影响。因此，只有在它提供了最低的端到端的延迟时，才应考虑这种设计类型。目前最快的解决方案是采用Nexus 3548双层10-GE矩阵设计。
图1-10提供了HFT的拓扑结构设计；第一个包含最多12台服务器，第二个包含最多48台服务器和10-GE带宽、无阻塞且每台服务器中有两张NIC。
图1-10 HFT主机托管设计
本节详细介绍MSDC数据中心趋势。
超大规模数据中心（MSDC）并不是行业标准术语，而是思科用于表示此类数据中心的名称。MSDC系统是一种基于Clos矩阵（拓扑结构），使用思科平台构建的参考架构。MSDC系统的目的是建设拥有数十万台服务器的非常大型的数据中心，这些服务器通过10-GE接口以非阻塞方式连接到一个拥有3层邻接关系的网络。甚至可以让路由协议从主机本身对接进入网络设备，进而给来自主机的路径提供判断和优化的能力。在拥有结构化和非结构化数据模型的Web搜索引擎、社交网络和云托管设备中，通常会见到这种类型的数据中心。
MSDC架构由两种关键的细分应用类别所驱动：内容服务和大数据分析。
内容传送应用包括：Akamai公司的内容传送网络（CDN）、Apple的iTunes、YouTube的视频，Facebook照片等。通过数十万台设备向数百万用户提供媒体内容的大规模应用的挑战，所要求使用的工具和技术通常是没有现成产品的。服务提供商需要自行搭建这些集群或网格。如今这些自产的基础架构成为了这些服务提供商的差异化优势。其中一些提供商，例如LinkedIn、Facebook和Google，已开源了它们的基础架构以发展其生态系统。
大数据分析是一种新应用，它采用并行存储和处理来分析包含非结构化数据（非元数据）的大型数据仓库。目前已有多种处理大数据的框架。但开源Hadoop现在被视为是明显的胜出者。在社交应用中，这些技术用于为网站的访问者生成自定义的网页。为填充网页的各部分而执行的后端分析工作，可通过Hadoop或相关的并行处理基础架构来实现。
图1-11显示了典型的社交应用Web基础架构解决方案的工作流。
图1-11 典型社交网络应用
MSDC客户系统的特征已总结在表1-1中。
表1-1 MSDC客户设计的系统的特征
| MSDC系统特征 |
描述 |
|---|---|
| 多根、多路径网络拓扑结构 |
针对数据中心的传入/传出流量而优化的传统网络架构，对这些数据中心来说这并不够。这些数据中心的大部分流量都在服务器之间传输。为优化这种东西向的流量（两段式带宽），客户采用了以前仅在HPC细分市场使用的拓扑结构。例如，Web搜索客户在其拥有大约20000台服务器的搜索引擎应用中使用扁平化的蝶型拓扑结构 |
| 扩展计算集群上的分布式计算 |
这些客户使用应用中的并行性来改善延迟和吞吐量。基于集群的计算是包含分布式应用组件的标准 |
| 包含NoSQL、分片和缓存的并行和分布式数据库 |
为这些应用提供了持久性功能的数据库非常大，但不会成为串口查询和SQL语义的瓶颈。数据存储在Bigtables中或分片到多个节点中，然后使用MapReduce等并行框架来检索，或者缓存在MemCache等分布式缓存存储中 |
| 内存中计算 |
为了处理到达这些数据中心的对同一个数据集的大量请求，客户部署了内存型数据库和缓存来改善页面视图的延迟 |
| 功耗成本节省 |
数据中心运维预算在功耗上分配了足够的资金，使这些客户能发现、资助和部署创新，减少数据中心的功耗/热/碳占用 |
以下3种主要需求，推动着数据中心网络去适应MSDC系统。
协议作为控制平面。Clos拓扑结构也称为非阻塞拓扑结构或胖树拓扑结构。
下面总结了MSDC系统的网络需求。
目前，更先进的拥塞控制、传输机制和负载均衡算法（PFC、DCTCP等）的研发工作正在积极地开展之中。但是，最常见的功能是用于上行链路转发路径选择的基于主机的等价多路径（ECMP）和简单的尾部丢包队列管理。
MSDC存储通常是分布式的，直接托管在服务器上。在一些情况下，它托管在专用存储设备上。
MSDC类型的数据中心的关键设计考虑以下因素。
图1-12展示了一个MSDC系统，它使用三级Clos拓扑结构，可扩展到以1:1的超载比连接多达12,288个节点端口，或者以3:1的超载比连接36864个节点端口。所有主机都是具有10-GE接口的物理节点。它还支持使用3层协议的邻接方式，使用1-Gbps连接支持多达122880个（1:1）和368640个（3:1）物理节点。该系统不依赖于生成树协议来实现自愈。相反地，它使用ECMP管理多个路径，ECMP充当着叶节点交换机上的路由协议。该网络提供了可用在每一跳（从叶节点开始）上的3层查找功能。该网络具有边界网关或边界叶节点，这些节点提供了与互联网或DCI链接的10-Gbps吞吐量。
图1-12 MSDC设计拓扑结构
虚拟化数据中心、大数据、HPC、ULL和MSDC（主干-叶节点）设计拓扑结构可使用思科ACI或独立的思科Nexus 9000交换机来实现。图1-13中总结了CLOS非阻塞架构的3个示例，其中每个10G的面向主机端口可发送线速流量。此设计示例是基于思科Nexus 9396叶节点交换机及思科Nexus 9336、9508和9516主干交换机（每台交换机拥有36个40GE主干线卡）。给定的示例包含N个主干；其目的是展示一个中小型到大型架构的示例。该计算基于主干数量N，主干中的端口数量或主干线卡：36个40GE端口，叶节点交换机为48个下行10GE端口提供了12个40GE上行链路。主干类型与图1-13中显示的公式中描述的非阻塞叶节点端口的潜在数量之间存在着直接关联。这里的主干和叶节点之间的互联使用了一个 40-GE 端口。未来预计在面向叶节点的级别上会是40-GE，主干和叶节点之间的互联使用100-GE。同样的方法也适用于该设计，但端口密度可能会更改。
图1-13 拥有40-GE互联的ACI矩阵/N9K CLOS结构示例
本节介绍POD的概念，具体分析来自于思科和NetApp的FlexPod架构。
数据的使用方式在不断动态地演进。如今，数据中心项目具有固定的预算，特定的范围和需求。一旦设计最终确定后，这些需求会转换为某种网络拓扑结构、交换机数量等。大多数项目的目标是不仅要满足最初的需求，还要提供未来按需在相同站点或不同的物理位置扩展的能力。当前的行业趋势表明，数据中心正在发生朝共享基础架构和云计算的巨大转变之中。因此，在数据中心使用信息的方式是一种“按需付费模式”，其中计算、存储和网络组件可以不断添加。
正是认识到需求和数据中心计划可能不断变化，思科设计了思科Nexus系列交换机，以保证在迁移过程中增量化地增长——不同代的数据中心矩阵共存，例如思科 Nexus 7000、6000-5000、2000系列的三层设计，最新的思科Nexus 9000 独立式或包含以应用为中心的基础架构软件。手动使用所有思科Nexus网络设备的替代方案是，创建支持这种使用模型的设计；已存在包含计算、存储和网络的一体化解决方案。已经有不同类型的一体化、按需付费的解决方案，例如FlexPod和Vblock。这些解决方案的目的在于提供允许通过复制同一个块模型或“POD”并朝数据中心扩展此模型来实现增量增长的模型。通过引入这种标准化，POD可帮助客户减轻对数据中心的扩展或新数据中心基础架构执行规划、设计、实现和自动化所涉及的风险和不确定性。这种模式会形成一个易于预测并对未来扩展拥有自适能力的架构。
FlexPod模型与Vblock模型的关键区别在于存储：FlexPod使用NetApp存储，而Vblock使用 EMC 存储。这两种解决方案都在计算功能上使用了思科 UCS，在网络功能中使用了思科Nexus系列交换机。在选择模型时，理解所需要的VM数量和数据中心所使用的应用是很重要的，因为这些因素将决定解决方案是存储密集型的还是 CPU 密集型的。例如，Oracle Database是存储密集型的，而大数据是 CPU 密集型的。在存储选择上，一个关键的技术选型是给应用使用的存储类型：集中化的共享存储还是主机上的分布式本地存储？光纤通道类型的存储还是基于IP的存储？存在让用于不同用途的不同应用和POD类型在同一个数据中心矩阵中运行的可行性。
这种POD模型解决了以下设计原则和架构目标。
通过使用FlexPod、Vblock和Hitachi，在创建详细的文档、信息和成功案例，帮助客户将其数据中心转型为这种共享基础架构模型的过程中，该解决方案架构和它的许多用例都得到了全面的检验和验证。此产品组合包括但不限于以下内容。
FlexPod是一种最佳数据中心架构实践，它包含以下3个组成部分。
这些组件依据思科和NetApp的最佳实践来连接和配置。FlexPod可纵向扩展来实现更高的性能和容量（根据需要单独添加计算、网络或存储资源），或者它可针对需要多种一致部署的环境而横向扩展（部署额外的FlexPod堆栈）。此模型提供了一种基准配置，而且还能够灵活地调整和优化来适应许多不同的用例。
通常，解决方案越灵活越可扩展，能够跨每种实现而提供相同特性和功能的单一统一架构的维护就会变得越来越困难。这正是FlexPod的关键优势之一。每个组件系列提供了一些平台和资源选项来扩展或缩减基础架构，同时支持FlexPod的配置和最佳连接实践所要求的相同特性和功能。
POD设计方法使数据中心项目能够按需增长，保持包含计算、网络和存储的相同的初始架构，并随着项目需求扩大而扩大规模。
数据中心网络基础架构设计，还包括定义交换机如何互联和如何保证网络中的数据通信。在包含接入、汇聚和核心的三层设计方法中，思科vPC是数据中心最常用的部署技术。还有一种被称之为“主干-叶节点”的新型两层矩阵的设计方法。这两种方法都会在本章后面的“采用主干-叶节点的ACI基础架构的逻辑数据中心设计”小节中介绍。
物理数据中心有3种基本的设计方法：列端式（EoR）、列中式（MoR）和架顶式（ToR）。该命名约定表示网络交换机在数据中心列中的位置。
这些部署模型的选择将基于以下的数据中心项目需求
这个列表并不是最全面的，这只是为了解释主要的列中式或架顶式方法的最终选择决策背后的概念。目前的发展趋势是使用ToR方法来设计数据中心。这并不意味着ToR是唯一可采用的设计方法，因为每个数据中心的需求是不同的，但它是目前最常见的部署方法。
EoR是经典的数据中心模型，其中的交换机放在数据中心机柜列的一端。每个机架有电缆连接到列端网络设备，如图1-14所示。EoR模型减少了需要管理的网络设备数量，优化了网络的端口利用率。在此模型中，机架中的服务器布局决策所受的约束更少。要实现冗余设计，可使用两束铜线来连接每个机架，二者都连接到相反的EoR网络基础架构。此模型的不足在于，必须在每列上要预先水平铺设大量的电缆，以及从列的每端通过架空托架或地下连接大量的电缆。此外，它会为每列生成一个很大的网络故障域。当服务器是虚拟化的，而且每台服务器运行数十到数百个VM时，这方面的影响会更大。这些不足使EoR模型不适合在现代数据中心中采用，在现代数据中心中，机架以各种不同的方式部署，而且不同机架的速率和电缆的需求可能会不同，所以需要经常重新布线。EoR模型非常适合具有高可用性的机箱式交换机，其中服务器接入端口事实上是连接到模块化的机箱式交换机上的。
图1-14 EoR连接模型
MoR是EoR模型的一种变形。MoR模型定义了将服务器连接到位于机柜列中部的交换机的架构。MoR 模型减少了对从列的一端连接到另一端的更长的电缆的要求，因为使用MoR，网络位于中部。MoR不仅在电缆长度上，而且在电缆类型上减少了布线成本。7至10米长的CX-1双绞线可用于将设备与MoR网络设备互联，而不需要包含配线架在内的更长的光纤。
前面已经提到，ToR方法是目前最常用的。它更适合POD设计并且包含一个故障域。ToR模型定义了将服务器连接到位于同一个机架内的交换机的架构。这些交换机通常使用水平光纤电缆来连接到汇聚交换机。此模型提供了接入层向优化的高带宽网络和低成本低运维开销布线设施架构的清晰的迁移路线图。它还支持按需付费的计算机部署模型，这增加了业务敏捷性。数据中心的接入层给架构师带来的挑战最大，因为他们需要选择布线架构来支持数据中心计算机的互联需求。
ToR网络架构和布线模型建议使用光纤作为连接机架的主干电缆，而在机架上主要使用铜线或光纤介质来连接服务器。来自每个机架的光纤的使用还有助于保护基础架构投资，因为在采用任何其他传输机制之前，不断演变的标准（包括40-GE和100-GE）更可能使用光纤实现。例如，40-GE能够使用在现有的多模10-GE光纤基础架构上开发的思科QSFP BiDi光模块作为收发器来运行。通过限制机架内的铜线的使用，ToR模型可将最常更改的布线隔离到最常变更的数据中心组件中：即机架本身。对于来自机架的光纤的使用提供了一种灵活的数据中心布线基础架构，以支持从1-GE过渡到现在的10-GE和40-GE，同时支持在未来过渡到100-GE和更高速率。ToR方法的主要不足在于要管理的交换机数量。这对思科Nexus 2000方法来说不是问题，它可以进行集中管理。此外，借助思科ACI矩阵，此问题更不需要担忧，因为所有的矩阵都由应用定义和控制。本书大部分篇幅将涉及ACI矩阵。
采用ToR方法，叶节点、主干或汇聚交换机可在EoR（如图1-15所示）或MoR（如图1-16所示）上连接，同时显著减少了电缆数量，在机架级别上提供了可扩展的按需付费模式。
图1-15 包含EoR聚合/主干/叶节点的ToR部署
图1-16 包含MoR聚合/主干/叶节点的ToR部署
在 ToR 上，服务器与上行链路带宽之间典型的超载比为 5:1。这就是最初为 ToR 配置基于48 个端口的非阻塞交换机的原因，其中40个端口是面向服务器的，8个端口用于上行链路。根据部署需求，可实现非阻塞ToR设计或较高的超载比设计。例如，HFT环境需要非阻塞且无超载比的网络，而高度密集的虚拟化环境或虚拟桌面需要更高的比率。根据是否是虚拟化环境，双宿主或单宿主服务器可通过1-GE、10-GE或40-GE NIC卡来部署。在100-GE或更高速率的NIC变得可用时，同样的原则也将适用。
机架大小正从标准的42个机架单元（RU）和19英寸宽的插槽演变为更密集和更高的模型。机架大小有许多选择，目前最宽为23英寸，高度选项涵盖从44个RU到包含57个RU的超高的自定义机架设计。一个RU表示1.75英寸的高度。在当前的设计中，48个RU的大小变得更常见，因为它将42个RU的大小拉伸到更密集的形式，而且仍符合货运卡车、入户门大小等的实际情况。
通常需要2至4个RU用于管理带外网络、接线板、配置电缆等。因为能够容纳40个RU的服务器密度是常见的需求，这就为ToR交换机留出了4至6个RU。ToR交换机的通风气流是从前往后的，而且不需要在交换机之间增加空间。它们应堆叠在服务器上。可以通过更换思科Nexus交换机中的风扇盘和电源，将气流方向更改为从后往前。在列端式设计中可以看到这种从后往前的气流设计。
对于单宿主服务器，通常在机架中部署单个ToR交换机。ToR交换机为服务器提供了交换端口，还提供了连接到汇聚层的上行链路端口，汇聚层可能是 MoR、EoR 等。通常，ToR 交换机的所有端口都拥有相同的功能。没有特定的专用上行链路端口，除了思科 Nexus 2000产品系列之外，其上行链路端口是特定的，而且它们只能连接到上游的 Nexus 5000、5500、6000、7000、7700或9000产品。通过采用网络vPC、VXLAN、IP或最新的端到端以应用为中心的ACI基础架构来支持上行流量，矩阵技术或连接技术可以在2层或3层中使用。
对于双宿主服务器，会在机架中部署一对ToR交换机。在此场景中，给定服务器上的每张NIC连接到一台不同的ToR交换机。
服务器可以在以下场景中运行。
矩阵或连接技术可拥有与具有ToR的矩阵的第2层和第3层冗余连接，或者具有采用vPC技术的第2层的冗余性。在ToR上游，可使用与单宿主服务器设计类似的技术。
传统的网络是基于生成树协议的冗余模型搭建的。后来，vPC的使用带来了双活连接方式，与STP主备拓扑结构相比，该双活连接获得了两倍带宽的增强。过去5年来在数据中心最常用的就是vPC设计和拓扑结构，但本节并不介绍它们。数据中心设计的新趋势是，使用主干-叶节点两层设计，ACI矩阵所采用的也是这种设计。本节介绍主干-叶节点架构和设计，然后介绍ACI主干-叶节点的优势。
数据中心网络通常是在物理上配置于单个管理域内。不同于传统的企业网络，数据中心的大部分流量都是东西向传输（在数据中心内的服务器之间）而不是南北向（在数据中心内的服务器与外部之间）。数据中心内的设备倾向于均匀分布（服务器、网络工具、NIC、存储和连接）。在服务器端口方面，数据中心网络可涵盖3000个到100000个端口。它们对成本也更加敏感，但没有传统企业网络那么丰富的功能。最后，数据中心内的大多数应用都会被量身调整来使用这些常规特征。
主干-叶节点数据中心架构旨在满足这些需求，它由一个拓扑结构、一组开放协议和每个网络节点中最少的功能组成。它的物理拓扑结构的最简单形式是基于两层、“胖树”拓扑结构，也称为Clos或非阻塞拓扑结构。此拓扑结构包含一组叶节点设备，它们连接到一个完整的二分图中的一组主干设备。也就是说，每个叶边界设备连接到每个主干，反之亦然，如图1-17所示。
图1-17 主干-叶节点架构
此架构拥有以下4个基本特征。
此架构的优势包括以下几点。
每个节点是一台全功能的交换机。例如，每个节点可接收标准网络数据包并转发它，就像典型的交换机或路由器那样。此外，每个节点有一个关联的控制平面，用于确定该节点的转发状态。
此拓扑结构大量使用了多路径以在节点之间获得所需带宽。用于主干-叶节点架构的转发模式可基于2层转发（网桥）或3层转发（路由），具体可根据特定客户的需求。每种方式都有其实际（且能感觉到）的优势和不足。本节不讨论这些优劣的权衡。例如，ACI架构依赖于路由主机方法或主干-叶节点架构的3层转发。
主干-叶节点架构提供了细粒度冗余性的优势，意味着许多组件会并行工作，因此任何一个组件或少量组件的故障都不会给网络的整体功能带来重大影响。如果交换机失效了，对网络管理员来说这并不是很重要。这会是一个微妙但非常有趣的概念。细粒度冗余性的优势可通过一个比较示例来很好地演示。对于传统的数据中心网络设计，在树的顶部有两台交换机，如果其中一台交换机出于任何原因发生故障，网络将会损失50%的性能。一台交换机发生故障的概率与它的可靠性相关，典型的可靠性目标为5个9，也就是说有0.00001%的几率失去网络性能的50%。尽管这是个很小的几率，但客户显然喜欢更好的。
在基于主干-叶节点的网络中，主干中有20台交换机。要损失同样的带宽量，也就是50%，就要10台交换机同时失效。这显然是非常不可能的，为了得到具体的数字，让我们做一个假设和简单的计算。假设出于某种原因，交换机的可靠性非常差，只有两个9；也即交换机发生故障的几率为 1%。这些交换机中的 10 台同时发生故障的几率为 0.01^10 或0.000000000000000001%。这与高度可用的交换机的0.00001%的几率相比不是很差。这里的基本理念是，在设计网络时会假设一些组件是会发生故障的，而不是尝试让网络组件完美无瑕。没有组件是“大而不倒”的。例如，MSDC客户应采用此方法计算所需资源和基础架构。与说服某人任何单个组件极不可能发生故障，因此他们就可以高枕无忧相比，说服某人其网络的设计能很好地处理故障会更容易。
同样的观点也可应用于网络的运维方面。在交换机的软件必须升级时，甚至在该交换机支持思科在线软件升级（ISSU）时，人们通常非常担忧该升级对网络服务的影响。借助细粒度冗余性，管理员只需让该交换机停止运行，升级它，重新启动它，或者执行其他必要的操作，而无需担心对整体网络设备的影响。在主干-叶节点架构中，高可用性由整个矩阵来处理，无需让单台设备支持ISSU，以预防应用中断。
最后，端口间的延迟会很低，并且延迟是固定的。假设队列延迟为0，许多MSDC客户想要获得稳定的任意端口到任意端口的延迟。
在主干-叶节点架构中，无论网络有多大，数据包从一个端口传输到任何其他端口的最大延迟是相同的。该延迟是边缘设备延迟的两倍加上主干的延迟。随着业界和思科开发了更优化延迟的新交换机，主干-叶节点架构将无缝地采用这些进步。事实上，使用思科目前正在开发的交换机很容易为100000个非阻塞10-GE端口实现最大1.5毫秒的延迟。因此，此网络甚至可满足低延迟网络需求。类似的考虑因素适用于缓存和转发表大小。这些是交换机已实现的功能。如果需要更大的缓冲，则使用具有更大缓存区的交换机。表项大小也是如此。这种依据开发小组可能拥有的具体权衡因素和市场考虑因素而设计每个网络组件的自由，是主干-叶节点架构所提供的灵活性。超大规模、固定的每端口成本以及较低、一致的延迟，都是主干-叶节点架构非常有吸引力的特征。
ACI架构依赖于本节所介绍的主干-叶节点模型。ACI矩阵还采用了中央管理点，同时保留了独立设备分布式控制平面。这允许该矩阵提供单一的交换机操作模式，同时获得主干-叶节点架构的所有好处。
在数据中心网络设计过程中，在架构选择和最终设计上需要注意以下一些关键的考虑因素。
主干-叶节点架构发展的趋势，解决了这些考虑因素和数据中心的需求。ACI矩阵依赖于本章介绍的主干-叶节点架构和ToR设计方法。此矩阵设计方法适应于不同应用和存储类型的所有发展趋势，在数据中心设计中提供了一定的灵活性，读者可将同一种技术用于不同的应用和存储实例。
表1-2总结了5种不同的应用趋势和矩阵选型。新的主干-叶节点ACI架构适合所有的使用场景，后续章节将介绍ACI所带来的好处。
表1-2 5种不同的应用趋势和每种趋势的网络选择总结
| 应用类别 |
存储 |
结构 |
结构技术 |
端口数量 |
超额订购率 |
|---|---|---|---|---|---|
| ULL |
分布式IP |
L2、L3 |
ACI、vPC、路由 |
小于100 |
1:1 |
| 大数据 |
分布式IP |
L2、L3 |
ACI、vPC、路由 |
小于100到2000 |
高 |
| HPC |
分布式非IP |
L2 |
ACI、vPC、FabricPath |
小于100到1000 |
2:1到5:1 |
| MSDC |
分布式IP |
L3 |
ACI、路由、OTV |
1000到10000 |
高 |
| 虚拟DC |
分布式FC或IP |
L2、L3 |
ACI、vPC、VXLAN、路由、OTV |
小于100到10000 |
高 |
备注：图1-1和图1-2由Cisco Press出版社提供：《云计算与数据中心自动化》
在编写本书时，大多数大规模数据中心的部署都是按照最新的云计算原则而设计的。运营商或大型企业所构建的数据中心也是如此。本章演示构建云的设计和技术需求。
美国国家技术与标准研究所（NIST）将云计算定义为“一种支持便捷、按需地通过网络访问可配置计算资源（例如网络、服务器、存储、应用和服务）的共享池的模型，它可快速配置和发布，只需极少的管理工作或和服务运营商交互”（参见http://csrc.nist.gov/groups/ SNS/ cloud-computing）。
数据中心资源（例如服务器或应用）以弹性服务的方式提供，这意味着容量可按需添加，并且在计算或应用不需要时，可将为其服务的资源下线。Amazon Web Services（AWS）常常被视为采用此概念和如今出现的许多类似服务的先驱。
云计算服务常常依据两个不同类别来分类。
云交付模型指定在何处配置计算能力，常常使用以下术语。
服务交付模型表明了用户会采用哪些云服务。
使用IT服务的云模型，而且特别是对于IaaS，基于的概念是用户通过自助门户来从目录中提供服务，其配置工作流是完全自动化的。这可确保使用服务的用户不需要等待IT人员分配VLAN，安装负载均衡器或防火墙等。其重要优势在于，用户的请求可以接近实时地完成。
直到最近，配置仍是通过CLI来执行，并且是逐台机器地进行操作。现在，ACI提供了可通过使用可扩展标记语言（XML）或JavaScript对象表示法（JSON）的非常紧凑的描述来大规模地实例化“虚拟”网络的能力。
Cisco UCS Director （UCSD）和Cisco Intelligent Automation for Cloud（CIAC）等工具将ACI服务与计算配置编排在一起（例如通过Cisco UCS、VMware vCenter或OpenStack），以向整个基础架构（业界将此称为虚拟私有云、虚拟数据中心或容器）提供快速的配置服务。
图2-1概要描绘了云基础架构的组成部分。云服务（b）的用户（a）订购一个独立的环境（c），该环境由包含防火墙负载均衡和虚拟机（VM）的容器来表示。CIAC提供服务目录功能，而UCSD和OpenStack发挥组件管理器的作用。
此请求由服务目录和门户通过编排层（d）来处理。编排层可由多个组件构成。举例而言，思科提供了CIAC，它与各种组件管理器进行交互来配置计算、网络和存储资源。
图2-1还解释了应用中心型基础架构（ACI），以及更准确地说是思科应用策略基础架构控制器（APIC）会融入到云架构中的何处。
图2-1 基础架构的组建模块
为云部署提供支持的网络基础架构必须满足以下多个需求。
第一和第二条需求几乎是不兼容的，因为如果数据中心是使用传统的生成树技术构建的，它会引起两个问题。
为了满足这些需求，ACI矩阵基于VXLAN叠加方式来构建，这使交换机能够在3层网络上保持所认知的2层邻接关系，进而从交换基础架构中消除与生成树相关的控制平面负载。为了解决3层基础架构上的移动性需求，转发是以全长的/32地址与映射数据库相结合的基于主机的转发为基础的。
像大多数情况一样，这种叠加需要网络边缘的数据路径从报文中的租户终端地址（即它的标识符）映射到终端的位置（即它的定位符）。这种映射在被称为隧道终端（TEP）的功能中执行。此种映射的挑战在于，需要针对非常大的数据中心进行扩展，这是因为映射状态必须存在于许多网络设备中。
扩展的第二个问题是，在终端移动（也即它的定位符更改）时，必须在整个网络中所有拥有该映射的TEP中更新映射状态。
ACI解决方案通过结合使用在数据报文所经过的数据路径中，以线速和在数据路径中实现缓存机制的方式，也就是在TEP上，通过实现中央数据库的映射解决了这些问题。（第7章“ACI矩阵设计方法”https://www.safaribooksonline.com/library/view/the-policy-driven/ 9780133589436/ ch07.html - ch07详细解释了ACI中的流量转发）。
构建云解决方案的另一个关键需求是，要能够以编程方式实例化网络。如果逐台机器、逐条链接地管理网络，脚本或自动化工具必须访问各台机器并跟踪工作负载在何处，才能在链接上启用VLAN中继。它还必须确保端到端路径依据抽象模型而配置。ACI通过使用集中化的配置点，APIC控制器，同时仍旧在矩阵中的每个节点上保留各个控制平面功能，来解决了此问题。该控制器将整个网络展现为树中的一个对象分层结构。它将与工作负载相关的网络属性描述为逻辑属性，而不是物理属性。所以，是要定义工作负载的连接需求，而不需要说明特定工作负载是在哪个物理接口上。
此外，该矩阵还展现了所有交换机的网络属性，所以它们都可以通过表述性状态传递（REST）调用对单台大型交换机/路由器进行配置和管理。APIC REST API接受并返回包含JSON或XML文档的HTTP或HTTPS消息。编排工具可使用REST调用来轻松地对网络基础架构进行编程（第4章“运营模型”演示了这种新模型，以及如何使用REST调用和脚本来自动化配置）。
通过将网桥域、VRF上下文和应用网络配置文件的所有配置表示为fvTenant类型的对象的子对象，在管理信息模型中就可以实现多租户模型。网络传输的分段使用不同的VXLAN VNID来加以保证。
防火墙和负载均衡器的嵌入也已实现自动化，以简化包括物理或虚拟防火墙和负载均衡服务的虚拟容器在内的创建工作（第8章“在ACI中实现嵌入式服务”将更详细地演示服务的建模，以及如何将它们嵌入到矩阵中）。
本节介绍Amazon Web Services提供的一些服务和AWS命名约定。AWS提供了非常广泛的服务，本节的目的不是描述所有这些服务。虽然如此，但本节对网络管理员还是很有用，原因有二。
下面的列表提供了一些关键的AWS术语。
Amazon Elastic Compute Cloud（EC2）服务支持在用户选择的区域和用户选择的可用性专区内启动AMI。实例由防火墙保护。实例也带有一个IP地址和一个DNS条目。EC2服务也可附带Elastic Load Balancing，后者将流量在EC2计算实例上分发。Auto Scaling可帮助基于利用率来配置足够的EC2实例。Amazon CloudWatch提供了每个EC2实例的CPU负载、磁盘I/O速率和网络I/O速率的信息。
备注
更多信息可在以下地址找到：
http://docs.aws.amazon.com/general/latest/gr/glos-chap.html
http://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/Using_Query_API.html
Amazon Simple Storage Service（S3）可通过基于SOAP的Web 服务API进行访问，或者借助使用标准的HTTP动作（GET、PUT、HEAD和DELETE）的HTTP API来访问。对象可使用协议名称、S3终端（s3.amazonaws.com）、对象键和所谓的桶名称来标识。
所有资源都可使用Amazon SDK来创建和操控，这些SDK具有各种编程语言版本，例如Python和PHP SDK，它们可分别在以下URL上获得：
http://aws.amazon.com/sdk-for-python/ http://aws.amazon.com/sdk-for-php/
借助此方法，可彻底实现以下自动化功能。
备注
有关更多信息，请参阅图书：
《借助Amazon Web Services在云中轻松托管网站》，作者为Jeff Barr（SitePoint，2010年）。
可通过多种方式访问AWS托管的Amazon Virtual Private Cloud（VPC）。一种方式是配置一台跳转主机，可使用AWS生成的公钥通过SSH登录到它。另一种方法是通过VPN将企业网络连接到Amazon VPC。
在包含数千台物理和虚拟服务器的大规模云部署中，管理员必须能够以一致且及时的方式配置服务器。
出于以下原因，网络管理员将会对本节感兴趣。
服务器自动化配置的总体方法包括以下步骤。
由于上述原因，云部署的典型设置需要以下组件。
现代数据中心的管理员很少通过可移动介质（例如DVD）安装新软件。管理员反而采用PXE（预启动执行环境）启动映像服务器。
启动过程按以下顺序进行。
1．主机启动并发送DHCP请求。
2．DHCP服务器提供PXE/TFTP服务器的IP地址和位置。
3．主机将对pxelinux.0的TFTP请求发送到TFTP服务器。
4．TFTP服务器提供pxelinux.0。
5．主机运行PXE代码并请求内核（vmlinuz）。
6．TFTP服务器提供vmlinuz代码和启动配置文件的位置（NFS/HTTP/FTP等）。
7．主机从服务器请求启动配置。
8．HTTP/NFS/FTP服务器提供启动配置。
9．主机请求安装包，例如RPM。
10．HTTP/NFS/FTP服务器提供RPM。
11．主机运行Anaconda，即安装后的处理脚本。
12．HTTP/NFS/FTP服务器提供这些脚本和Puppet/Chef安装信息。
大型数据中心的管理员需要处理的重要任务之一是，通过必要级别的补丁软件、最新的软件包，并启用需要的服务，来保持计算节点的更新。
用户可创建VM模板或黄金映像并将它们实例化来维护配置，但此过程会生成文件尺寸极大的映像，而且在每次需要变更时，重复此过程都将是一项漫长的任务。将配置或库的更新信息传送到以模板生成的所有服务器上，也是非常困难。更好的方法是使用工具，例如Chef、Puppet或CFengine。借助这些工具，可创建一个基本的黄金映像或VM模板，并在次日推送到服务器上。
这些工具提供了使用从底层操作系统抽象出的语言来定义节点最终状态的能力。例如，不需要知道使用“yum”还是“apt”来安装文件包，只需定义一个需要给定的文件包即可。不需要在不同的机器上使用不同的命令来设置用户、文件包、服务等。
如果需要创建Web服务器配置，可使用高级语言来定义它。然后，该工具创建必要的目录，安装需要的文件包，并启动在最终用户指定的端口上进行监听的进程。
这些工具的关键特征是，它们基于例如“声明性”模型（因为它们定义了想要的最终状态）和幂等配置的原则（因为可重新运行相同的配置多次，而始终会得到同样的结果）。策略模型依赖于声明性方法（可在第3章“策略数据中心”中，找到声明性模型的更多细节”）。
借助这些自动化工具，可以在实际执行给定操作之前就模拟其结果，实现变更，预防配置漂移。
下面这个列表提供了Chef使用的一些关键术语的参考信息。
图2-2 Chef流程和交互
与要在设备上执行的操作相关的秘诀，会在Chef工作站上配置，并上传到Chef服务器。
图2-3演示了Puppet的操作原理。使用Puppet语言，可以定义想要的资源（用户、软件包、服务等）状态，模拟在清单文件中定义的目标最终状态的部署，然后将该清单文件应用到基础架构上。最后，可以跟踪所部署的组件，跟踪变更，纠正偏离了目标状态的配置。
以下是Puppet中使用的一些重要术语的列表。
图2-3 Puppet
Amazon EC2、VMware vCloud Director、OpenStack和Cisco UCS Director都是IaaS编排器，它们统一了虚拟机、物理机器、存储和网络的配置，可启动针对特定用户环境（称为容器、虚拟数据中心或租户）的整个基础架构。
这些工具支持以下常见的操作。
VMware支持使用vCloud Director来实现云应用。vCloud Director构建于vCenter之上，后者进而通过大量运行vSphere的主机来协调VM。图2-4演示了vCloud Director的特性，它提供了租户抽象和资源抽象，它还为云计算服务的用户提供了vApp Catalog。
图2-4 vCloud Director组件
图2-5展示了vCloud Director如何以不同方式组织资源并在一个分层结构中提供它们，“组织”位于该分层结构的顶层。在“组织”内，有多个vDC。
图2-5 vCloud Director的资源组织结构
第 6 章“OpenStack”将介绍与ACI相关的OpenStack的详细信息。本节的目的是解释OpenStack如何融入到云架构中。
OpenStack的每个功能区域都是一个独立的项目。对于云部署，不需要使用完整的OpenStack功能集，可以仅使用一个特定项目的API。
项目列表如下所示。
由于不同的版本在功能上可能有着很大的变化，所以版本命名非常重要。在编写本书时，将可能会遇到以下版本：
备注
可在以下地址找到版本列表：
http://docs.openstack.org/training-guides/content/associate-getting-started.html#associate- core-projects
网络管理员目前特别感兴趣的版本是Folsom（因为它引入了Quantum组件来管理网络）和Havana（它用Neutron组件取代Quantum）。Neutron在同时管理多个网络组件上具有更高的灵活性，尤其是对于ML2架构，这将在第6章中介绍。
Neutron的插件概念非常重要。它是网络供应商向OpenStack架构中嵌入功能的途径。Neutron提供了OpenStack可使用的插件，该插件通过通用API来配置其特定的网络设备。
OpenStack通过Nova组件来管理计算，该组件控制着以下各种各样的计算实例。
安装OpenStack会是一个很大的话题，因为在过去安装OpenStack是很复杂的。事实上，思科对此已经采取措施，提供了一个OpenStack快速脚本安装程序，以方便OpenStack的部署。目前已经有许多其他的安装程序。
安装OpenStack用于概念验证用途时，常常会听到以下术语。
要开始使用OpenStack，通常需要下载一个提供了最新的，完整的、而且是最佳版本的devstack发行版。Devstack是开发人员在OpenStack完整环境中快速“堆叠”和“取消堆叠”的途径，使他们能够开发和测试自己的代码。很自然地，devstack的应用规模会很有限。
如果想要对一个特定版本执行一体化安装，可按照以下地址说明，使用思科Havana安装程序：http://docwiki.cisco.com/wiki/OpenStack:Havana:All-in-One，它结合使用了git repo和以下地址上的代码：https://github.com/CiscoSystems/puppet_openstack_builder 。第6章提供了与安装过程相关的更多信息。
目前有以下多种快速安装程序。
将OpenStack部署在数据中心时，需要考虑以下组件：
思科产品提供了在OpenStack编排过程中配置网络功能的插件。图2-6演示了OpenStack中的网络基础架构的框架。
图2-6 OpenStack网络插件
OpenStack中的网络表示一个隔离的2层网段，类似于物理网络世界中的VLAN。它们可以映射到VLAN或VXLAN，从而成为ACI终端组（EPG）和应用网络策略（ANP）的一部分。如图2-6所示，核心插件基础架构提供了使用供应商插件的选项。此议题将在第6章中介绍。
备注
有关OpenStack的更多信息，请访问http://www.openstack.org。
UCS Director是一种自动化工具，可用于将配置从组件管理器的使用中抽象出来，在自动化的工作流中配置计算、存储和ACI网络，并对应用进行配置。UCS Director提供了工作流，为管理员定义服务器策略、应用网络策略、存储策略和虚拟化策略，并在整个数据中心执行这些策略，如图2-7所示。
图2-7 UCS Director
该工作流可通过使用图形化的工作流设计器，以一种非常直观的方式定义。
UCSD同时拥有北向API和南向API。南向API允许UCSD用作可扩展的平台。
备注
有关UCS Director的更多信息，请访问https://developer.cisco.com/site/data- center/converged-infrastructure/ ucs-director/overview/
Cisco Intelligent Automation for Cloud工具实现了自助门户，并在编排引擎的支持下对虚拟和物理服务器进行自动化配置。尽管UCSD与CIAC之间存在着一些模糊的界线，CIAC使用UCSD北向接口并对编排功能进行补充，从而提供了对某些操作（例如提供自助门户，开具通知单，执行退款等）进行标准化的能力。CIAC对UCSD、OpenStack和Amazon EC2进行编排，并与Puppet/Chef集成。它还提供了用于定价的资源利用率度量方法。监测的资源包括vNIC、硬盘使用等。
图2-8演示了CIAC for PaaS使用Puppet所执行的操作。
图2-8 CIAC操作
图2-9演示了该过程配置部分的更多细节。
CIAC使用以下分层结构来组织数据中心资源。
图2-10演示了CIAC使用的分层结构。
图2-9 CIAC工作流
图2-10 CIAC中的分层结构
CIAC为用户提供了完整的自助目录，其中包含具有经典的金银铜等不同等级的“容器”或数据中心的不同选项，如图2-11所示。
图2-11 容器
管理员的任务之一是创建云基础架构，将所提供的服务的抽象模型映射成组成云的组件的抽象形式。
典型的产品可能由基于VMware的工作负载、包含ACI网络的基于OpenStack/KVM的工作负载，以及UCSD/CIAC编排组合而成。每种技术都拥有自己的方式来创建分层结构，虚拟化计算和网络。
表2-1 对不同的环境进行比较
| 平台类型/属性 |
|||||||
|---|---|---|---|---|---|---|---|
| 计算POD |
数据中心 |
组织 |
账户 |
账户 |
服务器 |
不适用 |
|
| 租户 |
文件夹 |
组织 |
不适用 |
账户 |
不适用 |
租户 |
安全域 |
| 组织 |
文件夹 |
不适用 |
不适用 |
不适用 |
组 |
组织 |
租户 |
| VDC |
资源池 |
组织 VDC |
项目 |
账户 |
VDC |
VDC |
租户 |
| VLAN实例 |
vCenter网络 |
组织网络/网络池 |
网络ID |
网络ID |
网络策略 |
网络 |
子网 |
| VM模板 |
完整路径 |
VM模板 HREF |
映像ID |
AMI ID |
目录 |
服务器模板 |
不适用 |
表2-1 VMware vCenter Server、VMware vCloud Director、OpenStack、Amazon EC2、UCS Director、CIAC和ACI之间的区别。
在ACI中，网络按租户来划分，租户的管理通过安全域的概念来组织。不同的管理员与一个或多个安全域相关联，类似地，每个租户网络可与一个或多个安全域相关联。结果会得到一种多对多的映射，这将有助于创建复杂的分层结构。如果两个租户网络代表CIAC中的同一个“租户”，但是同一个“租户”中的两个不同组织，则可以共享资源并在它们之间启用通信。
在CIAC中，一个租户可包含不同的组织（例如部门），每个组织可拥有一个或多个虚拟数据中心（物理和虚拟资源的汇聚）。网络和其他资源需要共享或隔离，ACI控制器（APIC）向编排器公开的API很容易实现上述目的。
备注
有关Cisco在OpenStack领域的发展情况的更多信息，请访问以下链接：
http://www.cisco.com/web/solutions/openstack
http://docwiki.cisco.com/wiki/OpenStack
本章介绍了云基础架构的组件，以及ACI如何为云提供网络自动化。解释了Amazon Web Services方法。本章还介绍了各种编排工具的作用，例如OpenStack、Cisco UCS Director和Cisco Intelligent Automation for Cloud。还介绍了如何对服务器进行自动化配置和一些如何开始使用OpenStack的相关重要概念。还解释了OpenStack对云基础架构的建模，并将其与CIAC和ACI的相似建模进行了比较。本章还讨论了管理员将IaaS服务的需求映射到这些技术模型上所需的任务。
