DevOps 网络管理指南（一）

原文：annas-archive.org/md5/b436360b9a3bff3c3cdcdb394d5f5b1a

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

本书的标题是《面向网络的 DevOps》。你可能已经非常了解，DevOps 是“开发（Development）”和“运维（Operations）”的缩写，那么它为什么与网络有关系呢？的确，DevOps 的名称中并没有“Net”，尽管可以说，DevOps 的职责范围已经远远超出了最初的目标。

最初的 DevOps 运动旨在消除开发与运营团队之间的“把问题扔过墙”的被动心态，但 DevOps 可以有效地用于促进 IT 所有团队之间的协作，而不仅仅是开发和运营人员。

DevOps 作为一个概念，最初旨在解决开发人员编写代码、做出重大架构更改时，不考虑需要将代码部署到生产环境的运营团队的情况。所以，当运营团队准备将开发人员的代码变更部署到生产环境时，这通常会导致部署失败，意味着关键的软件修复或新产品无法按计划到达客户，部署过程通常需要几天甚至几周才能修复。

这导致了所有相关团队的挫败感，因为开发人员不得不停止编写新功能，而是要帮助运营人员修复部署过程。运营团队也会感到沮丧，因为他们通常没有被告知部署新版本到生产环境时需要对基础设施做出更改。因此，运营团队没有准备好生产环境，以支持架构变更。

这一常见的 IT 场景突出了一个断裂的流程和操作模型，这种情况不断发生，并在开发和运营团队之间引发摩擦。

“DevOps”是一个旨在促进之前有冲突的团队之间的合作与沟通的倡议。它鼓励团队每天进行沟通，彼此了解变更，从而避免可避免的情况发生。因此，恰恰是开发和运营人员是 DevOps 最早试图解决的孤岛。结果，DevOps 被标榜为一种将团队统一为一个流畅的整体功能的方式，但它本来也可以叫别的名字。

DevOps 旨在改善团队之间的工作关系，并创造一个更愉快的工作环境，因为坦白说，没有人喜欢每天处理冲突或修复可以避免的问题。它还旨在促进团队之间的知识共享，以防止开发团队被视为“对基础设施一无所知”，而运营团队则被视为“变更的障碍”和“拖慢开发进度”。这些是各个部门孤立工作时常见的误解，因为他们没有花时间去理解彼此的目标。

DevOps 努力构建一个团队之间彼此欣赏、尊重共同目标的办公环境。DevOps 无疑是当今 IT 行业讨论最多的话题之一。它的流行与敏捷软件开发的兴起并非偶然，因为敏捷软件开发是作为瀑布式方法的替代方案出现的。

瀑布式开发和“V 模型”包括了分析、设计、实现（编码）和测试的不同阶段。这些阶段传统上被划分为不同的孤立团队，并设有正式的项目交接日期，这些日期是固定不变的。

敏捷诞生于意识到在快节奏的软件行业中，长期运行的项目并不是最佳选择，不能为客户提供真正的价值。因此，敏捷推动项目进入更短的迭代周期，将分析、设计、实现和测试纳入两周一轮的周期（冲刺），并采用原型化方法。

原型化方法采用增量开发的概念，使得公司能够在发布周期的早期收集产品反馈，而不是使用“大爆炸”方法，在实施阶段结束时一次性交付完整解决方案。

在瀑布式实施阶段结束时以瀑布方式交付项目，存在交付客户不需要的产品或开发人员误解需求的风险。这些问题通常仅在最终测试阶段被发现，此时项目已经准备好推向市场。这常常导致项目被认为是失败，或者出现巨大的延迟，而此时可以进行昂贵的返工和变更请求。

敏捷软件开发大部分时间推动了团队之间的孤岛现象的打破，这种孤岛现象通常与瀑布式软件开发相关，并且加强了每天进行协作的需求。

随着敏捷软件开发的引入，软件测试的方式也发生了变化，DevOps 的原则同样被应用于测试功能。

质量保证测试团队再也不能只是被动应对，就像之前的运营团队一样。因此，这促使测试团队需要更高效地工作，不再拖延产品进入市场的时间。然而，这不能以牺牲产品质量为代价，因此他们需要找到一种方式，确保应用程序得到充分测试，并通过所有质量保证检查，同时以更智能的方式工作。

已广泛接受质量保证测试团队不能再与开发团队分开孤立运作；相反，敏捷软件开发推动了测试用例与软件开发并行编写，因此它们不再是一个独立的活动。这与将代码部署到测试环境中，并交给测试团队执行手动测试或运行一组测试包来被动处理问题的做法截然不同。

敏捷方法促进了开发人员和质量保证测试人员每天在敏捷团队中共同工作，在软件打包部署之前进行测试，之后这些相同的测试将得到维护、更新，并用于生成回归测试包。

这已被用来减轻由于开发人员提交的代码更改破坏了质量保证测试团队的回归测试包所引起的摩擦。在独立的测试团队中，一个常见的摩擦场景是开发人员突然更改了图形用户界面（GUI），导致部分回归测试失败。这个更改没有通知测试团队。测试失败是因为它们是为旧版 GUI 编写的，而突然变得过时，而不是因为开发人员实际上引入了软件故障或 bug。

这种反应式的测试方法没有建立对自动化测试包报告的测试失败有效性的信心，因为这些失败并不总是完全由于软件故障，而且由于 IT 结构的次优，导致了不必要的延迟。

如果开发和测试团队之间的沟通更好，运用 DevOps 提倡的原则，那么这些延迟和次优的工作方式是可以避免的。

最近，我们看到了 DevSecOps 的兴起，它通过将安全性和合规性集成到软件交付过程中，取代了手动操作和分离的反应性举措。DevSecOps 借助 DevOps 和敏捷哲学，并采用了将安全工程师嵌入到敏捷团队中的想法，以确保在项目开始时就满足安全要求。

这意味着安全性和合规性可以作为自动化阶段集成到持续交付管道中，在每次软件发布时运行安全合规检查，并且不会延缓开发人员的软件开发生命周期，同时生成必要的反馈循环。

因此，网络团队也可以从 DevOps 方法论中学习，就像开发、运维、质量保证和安全团队一样。这些团队已经利用敏捷流程来改善与软件开发过程的互动，并从使用反馈循环中受益。

网络工程师有多少次不得不推迟软件发布，因为需要实施网络变更，而这些变更通过与其他部门流程不对接的票务系统低效地进行？网络工程师手动实施的网络变更又有多少次导致生产服务中断？这并不是对网络团队或网络工程师能力的批评，而是认识到运营模型需要改变，并且他们有能力做到这一点。

本书内容概览

本书将探讨如何提高网络变更的效率，以免影响软件开发生命周期。它将帮助概述网络工程师可以采用的自动化网络操作策略。我们将重点讨论如何建立成功的网络团队，使其能够在一个自动化驱动的环境中协作工作，从而提高效率。

本书还将展示网络团队需要建立新的技能，学习如 Ansible 这样的配置管理工具，以帮助他们实现这一目标。书中将展示这些工具带来的优势，使用它们提供的网络模块，并将帮助简化自动化过程，成为一个自我启动的指南。

我们将重点讨论需要克服的一些文化挑战，以便影响和实施网络功能的自动化流程，并说服网络团队充分利用目前供应商提供的可信网络 API。

本书将讨论公有云和私有云，如 AWS 和 OpenStack，以及它们如何为用户提供网络服务。还将讨论软件定义网络解决方案的出现，如 Juniper Contrail、VMWare NSX、CISCO ACI，并重点介绍诺基亚 Nuage VSP 解决方案，旨在将网络功能变成自服务商品。

本书还将重点讲解如何将持续集成和交付流程以及部署管道应用于网络变更的管理。还将展示如何将单元测试应用于自动化网络变更，以便将其与软件交付生命周期集成。

本书的详细章节概述如下：

第一章，云对网络的影响，将讨论公有云的 AWS 和私有云的 OpenStack 的出现如何改变了开发者对网络的需求。它将探讨 AWS 和 OpenStack 提供的一些即插即用的网络服务，并展示它们提供的部分网络功能。书中将举例说明这些云平台如何将网络变成像基础设施一样的商品。

第二章，软件定义网络的出现，将讨论软件定义网络如何出现。它将探讨方法论，并重点介绍 AWS 和 OpenStack 提供的开箱即用体验之上，软件定义网络所带来的一些扩展性优势和特性。它将展示市场领先的 SDN 解决方案之一 Nuage 如何应用这些概念和原理，并讨论市场上其他 SDN 解决方案。

第三章，将 DevOps 引入网络运营，将详细说明自上而下和自下而上的 DevOps 网络倡议的利弊。它将为读者提供一些成功的策略和通常失败的策略的思考。此章节将帮助首席技术官（CTO）、高级经理和工程师，尤其是那些试图在公司网络部门启动 DevOps 模型的人，概述他们可以使用的不同策略，以实现他们期望的文化变革。

第四章，使用 Ansible 配置网络设备，将概述使用配置管理工具安装和推送配置到网络设备的好处，并讨论目前可用的一些开源网络模块及其工作原理。它将举例说明可以采用的一些流程，以维持设备配置。

第五章，使用 Ansible 编排负载均衡器，将描述使用 Ansible 编排负载均衡器的好处，以及在无需停机或人工干预的情况下将新软件版本推送到服务中的方法。它将举例说明可以采用的一些流程，以便编排不可变和静态服务器，探讨不同的负载均衡技术。

第六章，使用 Ansible 编排 SDN 控制器，将概述使用 Ansible 编排 SDN 控制器的好处。它将概述软件定义网络的好处，以及为什么自动化 SDN 控制器暴露的网络功能至关重要。这包括动态设置 ACL 规则，允许网络工程师提供网络即服务（NaaS），使开发人员能够自助满足其网络需求。它将讨论部署策略，如蓝绿网络，并探索一些可以用来实现 NaaS 方法的流程。

第七章，使用持续集成构建进行网络配置，将讨论如何转向一种将网络配置存储在源代码管理系统中的模式，以便于审计、版本控制和回滚变更。

它将探讨使用如 Jenkins 和 Git 等工具设置网络配置 CI 构建的工作流。

第八章，测试网络变更，将概述在将网络变更应用到生产环境之前，使用测试环境进行测试的重要性。它将探讨一些可用的开源工具，并详细介绍一些可以应用的测试策略，确保网络变更在应用到生产环境之前经过充分测试。

第九章，使用持续交付流水线部署网络变更，将展示读者如何使用持续集成和持续交付流水线将网络变更交付到生产环境，并通过相关测试环境进行验证。它将给出一些可以采用的流程示例，说明如何将网络变更轻松地与基础设施和代码变更一起放入部署流水线。

第十章，容器对网络的影响，专用容器技术，如 Docker，以及容器编排引擎，如 Kubernetes 和 Swarm，越来越受到迁移到微服务架构的公司的青睐。因此，这改变了网络需求。本章将探讨容器的运作方式及其对网络的影响。

第十一章，网络安全，将探讨这种方法如何使安全工程师在审计网络时的工作变得更加轻松。它将分析软件定义网络中的可能攻击路径，以及如何将安全检查集成到 DevOps 模型中。

本书所需的内容

本书假设读者具备中级的网络知识、基础的 Linux 知识、基础的云计算技术知识以及广泛的 IT 知识。重点主要放在可以实施的特定流程工作流上，而非基础技术，因此这些思想和内容可以应用于任何组织，无论使用何种技术。

然而，尽管如此，在消化某些章节内容时，读者访问以下技术可能会有所帮助：

• AWS aws.amazon.com/free/

• OpenStack trystack.org/

• Nuage VSP nuagex.io/

本书适合的人群

本书的目标读者是希望自动化其工作中手动和重复部分的网络工程师，或者希望自动化所有网络功能的开发者和系统管理员。

本书还将为 CTO 或经理提供有价值的见解，帮助他们了解如何使其网络部门更加敏捷，并在其组织内部发起真正的文化变革。

本书还将帮助那些希望了解更多关于 DevOps、持续集成和持续交付的人，并了解它们如何应用于现实世界场景，以及一些可用的工具，以便于自动化。

约定

本书中有多种文本样式，用于区分不同类型的信息。以下是这些样式的几个例子及其含义的解释。

文本中的代码词、数据库表名、文件夹名、文件名、文件扩展名、路径名、虚拟 URL、用户输入和 Twitter 用户名将如下所示：“这些服务随后将绑定到lbvserver实体。”

任何命令行输入或输出都将如下所示：

ansible-playbook  -I inevntories/openstack.py  -l qa  -e environment=qa  -e current_build=9 playbooks/add_hosts_to_netscaler.yml

新术语和重要词汇以粗体显示。你在屏幕上看到的词语，例如在菜单或对话框中，出现在文本中如下：“点击 Google 上的搜索按钮。”

注意

警告或重要说明将以这样的框显示。

提示

提示和技巧如下所示。

读者反馈

我们始终欢迎读者的反馈。让我们知道你对本书的看法——你喜欢或不喜欢什么。读者反馈对我们非常重要，因为它帮助我们开发出你能从中获得最大收益的书籍。

如需发送一般反馈，请直接发送电子邮件至<feedback@packtpub.com>，并在邮件主题中注明书名。如果你对某个主题有专长，并有兴趣撰写或参与编写书籍，请参考我们的作者指南：www.packtpub.com/authors。

客户支持

既然你已经成为 Packt 书籍的自豪拥有者，我们提供了多项帮助你最大化利用购买的内容。

下载本书的彩色图片

我们还为你提供了一个 PDF 文件，其中包含本书中使用的截图/图表的彩色图像。这些彩色图像将帮助你更好地理解输出的变化。你可以从www.packtpub.com/sites/default/files/downloads/DevOpsforNetworking_ColorImages.pdf下载该文件。

勘误

尽管我们已尽力确保内容的准确性，但错误仍然可能发生。如果您在我们的书籍中发现错误——可能是文本或代码中的错误——我们将非常感激您向我们报告。通过这样做，您不仅能为其他读者避免困惑，还能帮助我们改进后续版本的书籍。如果您发现任何勘误，请通过访问www.packtpub.com/submit-errata，选择您的书籍，点击勘误提交表格链接，并填写勘误的详细信息。一旦您的勘误得到验证，我们将接受您的提交，并将勘误上传到我们的网站，或将其添加到该书标题下的现有勘误列表中。

若要查看之前提交的勘误，请访问www.packtpub.com/books/content/support并在搜索框中输入书名。所需信息将显示在勘误部分。

盗版

网络上的版权盗版问题在各类媒体中普遍存在。在 Packt，我们非常重视版权和许可证的保护。如果您在互联网上发现我们作品的任何非法复制品，请立即向我们提供该位置地址或网站名称，以便我们采取相应措施。

如果您发现涉嫌盗版的内容，请通过<copyright@packtpub.com>与我们联系，并提供盗版内容的链接。

我们感谢您在保护我们的作者和帮助我们为您提供有价值内容方面的帮助。

问题

如果您对本书的任何部分有问题，可以通过<questions@packtpub.com>与我们联系，我们将尽最大努力解决问题。

第一章：云计算对网络的影响

本章将探讨过去几年内私有数据中心中网络的变化以及如何演变。重点将放在公有云中的亚马逊网络服务（AWS）和私有云中的OpenStack的出现，以及它们如何改变开发人员使用网络的方式。它还将探讨 AWS 和 OpenStack 提供的现成网络服务，并展示它们提供的一些功能。最后，它将展示这些云平台如何将网络变成了类似基础设施的商品。

本章将涉及以下主题：

• 云计算方法概述

• 跨越树（Spanning Tree）网络与叶脊（Leaf-Spine）网络的区别

• 公有云引入后，网络发生的变化

• 亚马逊网络服务（AWS）网络方法

• OpenStack 网络方法

云计算方法概述

云服务提供商市场目前已经饱和，存在多种不同的私有云、公有云和混合云解决方案，因此对于希望实施公有云、私有云或混合云解决方案的公司来说，选择不再是问题。

因此，选择云解决方案有时会是一个令人生畏的任务，因为市场上有众多不同的选择。

公有云与私有云之间的竞争仍处于起步阶段，尽管公有云被认为非常流行，但只有大约 25%的行业在使用公有云，解决方案如亚马逊网络服务、微软 Azure 和谷歌云占据了市场的大部分份额。然而，这仍意味着云市场有 75%的市场份额尚未被占领，因此云计算市场在未来几年可能会经历多次迭代。

那么，为什么许多公司最初考虑使用公有云，公有云与私有云和混合云又有什么不同呢？

公有云

公有云本质上是一组数据中心和基础设施，通过互联网公开提供给消费者。尽管名字中带有“云”，但它并非魔法或虚无缥缈的东西。亚马逊网络服务（Amazon Web Services）推出公有云的初衷是，在一年中忙碌的时期，他们可以将空闲的服务器租借给其他公司使用。

公有云资源可以通过图形用户界面（GUI）或通过一组 API 端点以编程方式访问。这使得公有云的最终用户能够创建基础设施和网络，以托管他们的应用程序。

企业使用公有云有多种原因，例如配置速度快，并且使用公有云资源的成本相对较低。一旦提供了信用卡信息，最终用户就可以自由创建自己的基础设施和网络，并在其上运行应用程序。

这种基础设施可以根据需要弹性地扩展和缩减，当然，所有这些都需要一定的费用，通过信用卡支付。

公有云已经变得非常流行，因为它解决了一些与影子 IT相关的历史性障碍。开发者不再受到官僚化和缓慢的内部 IT 流程强加的限制。因此，许多企业将公有云视为跳过这些障碍、以更灵活的方式工作的途径，使他们能够更频繁地将新产品推向市场。

当企业将其运营迁移到公有云时，他们是在迈出大胆的一步，停止托管自己的数据中心，而是使用一个公开的公有云服务提供商，如 Amazon Web Services、Microsoft Azure、IBM BlueMix、Rackspace 或 Google Cloud。

随后，依赖于公有云的正常运行时间和服务等级协议（SLA），这对一个成熟的企业来说可能是一个巨大的文化转变。

已经迁移到公有云的企业可能会发现，他们不再需要庞大的内部基础设施团队或网络团队，所有基础设施和网络都由第三方公有云提供，因此在某些情况下，这可能被视为放弃内部 IT。

公有云证明了对于许多初创公司来说是一个非常成功的模式，因为它提供的灵活性，初创公司可以迅速推出产品，利用软件定义的构件，而无需建立自己的数据中心，保持产品专注。

然而，运行所有企业基础设施在公有云中的拥有总成本（TCO）是一个备受争议的话题，如果没有正确的管理和维护，这可能是一个昂贵的模式。关于公有云与私有云 TCO 的辩论仍在继续，一些人认为公有云是一个很好的短期解决方案，但随着时间的推移，成本的增长意味着它可能不是与私有云相比的可行长期解决方案。

私有云

私有云实际上只是虚拟化解决方案（如 VMware、Hyper-V 和 Citrix Xen）最初带来的好处的延伸，这些虚拟化解决方案曾是虚拟化市场的基石。私有云的世界已经不再仅仅提供虚拟机，而是提供软件定义的网络和存储。

随着公有云的推出，如 Amazon Web Services，私有云解决方案已试图通过在当前基础设施上加一个软件定义层来提供类似的功能。这个基础设施可以像公有云一样通过图形界面（GUI）或通过 API 编程方式进行控制。

私有云解决方案，如 Apache CloudStack 和开源解决方案如 OpenStack，已被创建来弥合私有云和公有云之间的差距。

这使得厂商可以通过在现有硬件和网络之上叠加软件定义的构件，获得在自有数据中心内运行私有云操作的灵活性。

然而，私有云的主要好处在于这可以在公司自有数据中心的安全性范围内完成。并非所有企业都能出于合规性、常规性或性能原因使用公共云，因此一些企业在特定工作负载上仍然需要私有云。

混合云

混合云通常可以被视为多个云的结合体。这使得企业能够通过网络结构无缝地在多个云之间运行工作负载。企业可以根据成本或性能指标来选择工作负载的部署位置。

混合云通常可以由私有云和公共云组成。因此，举个例子，一个企业可能有一套需要在特定繁忙时期进行扩展的 Web 应用，这些应用更适合运行在公共云中，因此它们被部署在那里。然而，该企业还需要一个高度受监管、符合 PCI 标准的数据库，后者更适合部署在私有的本地云中。因此，真正的混合云为企业提供了这类选择和灵活性。

混合云的真正运作前提是根据不同的用例使用不同的云，其中每匹马（应用工作负载）需要跑特定的赛道（云）。因此，有时可以使用厂商提供的平台即服务（PaaS）层来跨多个云部署工作负载，或者使用不同的配置管理工具或容器编排技术来协调跨云的应用工作负载部署。

软件定义

公共云、私有云或混合云的选择实际上取决于企业，因此没有绝对的对错答案。随着公司文化和流程在未来几年内的发展，它们可能会使用混合云模型。

如果一个企业正在使用公共云、私有云或混合云，那么所有实现方式的共同主题就是它们都朝着软件定义的运营模式发展。

那么，软件定义到底是什么意思呢？简而言之，软件定义意味着在硬件上运行一个软件抽象层。这个软件抽象层允许对硬件进行图形化或编程化控制。因此，像基础设施、存储和网络这样的构件可以被软件定义，从而帮助简化操作、提高可管理性，尤其是在基础设施和网络扩展时。

在运行私有云时，需要对现有的数据中心进行修改，以使其准备好成为私有云；有时，这一点非常重要，因此私有数据中心需要进化以满足这些需求。

跨树和叶脊网络的区别

在考虑私有云时，传统上，公司的私有数据中心已实现基于生成树协议（STP）的 3 层二层网络，这对于现代的软件定义网络并不十分适用。因此，我们将深入了解什么是 STP 以及现代的叶脊网络架构。

生成树协议

STP 的实现为网络架构师提供了多种实现选项，但也为网络增加了一层复杂性。实施 STP 可以让网络架构师确信它能够防止网络中发生二层环路。

典型的 3 层基于 STP 的二层网络表示如下：

• 核心层为数据中心的其他部分提供路由服务，并包含核心交换机

• 聚合层提供与相邻接入层交换机的连接，并位于生成树核心的顶部

树的底部是接入层；这是裸金属（物理）或虚拟机连接到网络并使用不同 VLAN 进行分段的地方。

使用二层网络和 STP 意味着网络的接入层将使用遍布整个网络的 VLAN。这些 VLAN 位于接入层，虚拟机或裸金属服务器连接在此。通常，这些 VLAN 按应用类型分组，防火墙用于进一步隔离和保护它们。

传统网络通常被划分为以下几种组合：

• 前端：通常包含需要外部访问的 Web 服务器

• 业务逻辑：通常包含有状态服务

• 后端：通常包含数据库服务器

应用程序通过这些防火墙之间的隧道进行通信，使用特定的访问控制列表（ACL）规则，这些规则由网络团队提供服务，并由安全团队进行管理。

在二层网络中使用 STP 时，所有交换机都通过选举过程来确定根交换机，根交换机会授予具有最低桥接 ID 的交换机，桥接 ID 包括交换机的桥接优先级和 MAC 地址。

一旦选举完成，根交换机成为生成树的基础；生成树中的所有其他交换机被视为非根交换机，它们将计算到根交换机的最短路径，然后阻止任何冗余链路，从而形成一条清晰的路径。计算最短路径的过程称为网络收敛。（更多信息请参阅以下链接：etutorials.org/Networking/Lan+switching+fundamentals/Chapter+10.+Implementing+and+Tuning+Spanning+Tree/Spanning-Tree+Convergence/)

Network architects designing the layer 2 Spanning Tree network need to be careful about the placement of the root switch, as all network traffic will need to flow through it, so it should be selected with care and given an appropriate bridge priority as part of the network reference architecture design. If at any point, switches have been given the same bridge priority then the bridge with the lowest MAC address wins.

Network architects should also design the network for redundancy so that if a root switch fails, there is a nominated backup root switch with a priority of one value less than the nominated root switch, which will take over when a root switch fails. In the scenario, the root switch fails the election process will begin again and the network will converge, which can take some time.

The use of STP is not without its risks, if it does fail due to user configuration error, data center equipment failure or software failure on a switch or bad design, then the consequences to a network can be huge. The result can be that loops might form within the bridged network, which can result in a flood of broadcast, multicast or unknown-unicast storms that can potentially take down the entire network leading to long network outages. The complexity associated with network architects or engineers troubleshooting STP issues is important, so it is paramount that the network design is sound.

Leaf-Spine architecture

In recent years with the emergence of cloud computing, we have seen data centers move away from a STP in favor of a Leaf-Spine networking architecture. The Leaf-Spine architecture is shown in the following diagram:

In a Leaf-Spine architecture:

• Spine switches are connected into a set of core switches

• Spine switches are then connected with Leaf switches with each Leaf switch deployed at the top of rack, which means that any Leaf switch can connect to any Spine switch in one hop

Leaf-Spine architectures are promoted by companies such as Arista, Juniper, and Cisco. A Leaf-Spine architecture is built on layer 3 routing principle to optimize throughput and reduce latency.

Both Leaf and Spine switches communicate with each other via external Border Gate Protocol (eBGP) as the routing protocol for the IP fabric. eBGP establishes a Transmission Control Protocol (TCP) connection to each of its BGP peers before BGP updates can be exchanged between the switches. Leaf switches in the implementation will sit at top of rack and can be configured in Multichassis Link Aggregation (MLAG) mode using Network Interface Controller (NIC) bonding.

MLAG 最初与STP一起使用，使得两个或更多交换机绑定在一起，模拟成一个交换机，作为冗余使用，从而在 STP 中显示为一个交换机。在发生故障时，这提供了多个上行链路作为冗余，因为交换机是对等的，并且可以绕过禁用冗余路径的需求。Leaf 交换机之间通常会配置内部边界网关协议（iBGP）以实现容错。

在 Leaf-Spine 架构中，Spine 交换机不会与其他 Spine 交换机连接，Leaf 交换机也不会直接与其他 Leaf 交换机连接，除非使用 MLAG 网卡绑定在机架顶部进行绑定。Leaf-Spine 架构中的所有链接都被设置为无环转发。Leaf-Spine 架构通常配置为实现等成本多路径（ECMP），允许在交换机上配置所有路由，从而可以访问层 3 路由结构中的任何 Spine 交换机。

ECMP 意味着 Leaf 交换机的路由表已配置了指向每个 Spine 交换机的下一跳。在 ECMP 配置中，每个 Leaf 节点都有多条与每个 Spine 交换机等距离的路径，因此如果某个 Spine 或 Leaf 交换机故障，只要还有其他活跃路径连接到相邻的 Spine 交换机，就不会受到影响。ECMP 用于负载均衡流量，并支持通过多条路径路由流量。与 STP 相比，STP 会在网络收敛时关闭除一条路径外的所有路径。

通常，为了实现高性能，Leaf-Spine 架构在 Leaf 交换机上使用 10G 接入端口，映射到 40G 的 Spine 端口。当设备端口容量成为问题时，可以通过将新 Leaf 交换机连接到网络中的每个 Spine 交换机，并将新配置推送到每个交换机，来添加新的 Leaf 交换机。这意味着网络团队可以轻松地横向扩展网络，而无需管理或中断交换协议，也不会影响网络性能。

后续会展示 Leaf-Spine 架构中使用的协议图示，Spine 交换机通过 BGP 和 ECMP 与 Leaf 交换机连接，Leaf 交换机位于机架顶部，并使用 MLAG 和 iBGP 配置以实现冗余：

Leaf-Spine 架构的优势如下：

• 网络中的一致性延迟和吞吐量

• 所有机架的一致性性能

• 网络一旦配置完成，复杂性会大大降低

• 通过在机架顶部添加新的 Leaf 交换机，可以简单地扩展新机架。

• 所有机架之间的一致性性能、订阅和延迟

• 东西向流量性能优化（虚拟机到虚拟机的通信），以支持微服务应用

• 解决 VLAN 扩展问题，控制广播和故障域

Leaf-Spine 拓扑的一个缺点是它在数据中心中消耗的电缆数量。

OVSDB

现代交换机已经开始采用开源标准，这样它们就可以使用相同的可插拔框架。虚拟交换机的开源标准是Open vSwitch，它源于需要提出一个开放标准，使虚拟交换机能够将流量转发到同一物理主机和物理网络上的不同虚拟机。Open vSwitch 使用Open vSwitch 数据库（OVSDB），该数据库具有标准的可扩展架构。

Open vSwitch 最初在虚拟化管理程序层面部署，但现在也被用于容器技术，这些技术为网络提供了 Open vSwitch 实现。

以下超管程序目前将 Open vSwitch 作为其虚拟交换技术：

• KVM

• Xen

• Hyper-V

Hyper-V 最近已开始支持使用 Cloudbase (cloudbase.it/) 创建的 Open vSwitch 实现，Cloudbase 在开源领域做出了出色的工作，这也证明了微软的商业模式在近年来如何发展并拥抱开源技术和标准。谁能想到呢？现在，微软的技术可以原生运行在 Linux 上。

Open vSwitch 交换OpenFlow数据，在虚拟交换机和物理交换机之间进行通信，并且可以通过编程扩展以适应供应商的需求。在下面的图示中，你可以看到 Open vSwitch 的架构。Open vSwitch 可以在使用 KVM、Xen 或 Hyper-V 虚拟化层的服务器上运行：

ovsdb-server 包含 OVSDB 架构，保存虚拟交换机的所有交换信息。ovs-vswitchd 守护进程与任何控制与管理集群通信，控制与管理集群可以是任何可以使用 OpenFlow 协议通信的 SDN 控制器。

控制器使用 OpenFlow 在虚拟交换机上安装流状态，OpenFlow 决定当虚拟交换机接收到数据包时应采取哪些操作。

当 Open vSwitch 接收到一个它从未见过并且没有匹配流条目的数据包时，它会将该数据包发送给控制器。控制器随后根据流规则决定如何处理此数据包，是阻止它还是转发它。在 Open vSwitch 上，可以配置服务质量（QoS）和其他统计信息。

Open vSwitch 用于在虚拟化管理程序的交换机级别配置安全规则并提供 ACL 规则。

Leaf-Spine 架构允许轻松构建覆盖网络，这意味着云环境和租户环境可以轻松地连接到第 3 层路由结构。硬件Vxlan 隧道端点（VTEPs）的 IP 地址与每个 Leaf 交换机或 MLAG 模式下的一对 Leaf 交换机关联，并通过虚拟可扩展局域网（VXLAN）与安装在虚拟化管理程序上的每个 Open vSwitch 连接到每个物理计算主机。

这使得由厂商提供的 SDN 控制器，例如思科（Cisco）、诺基亚（Nokia）和瞻博网络（Juniper），能够构建一个覆盖网络，通过 Open vSwitch 创建到物理虚拟化主机的 VXLAN 隧道。如果有新的计算节点扩展，新的 VXLAN 隧道会自动创建，之后 SDN 控制器可以在 Leaf 交换机上创建新的 VXLAN 隧道，因为它们与 Leaf 交换机的硬件VXLAN 隧道终端（VTEP）建立了对等连接。

现代交换机厂商，如 Arista、思科、Cumulus 等，使用 OVSDB，这使得 SDN 控制器能够在控制与管理集群层级进行集成。只要 SDN 控制器使用 OVSDB 和 OpenFlow 协议，它们就可以与交换机无缝集成，并且不受特定厂商的限制。这为最终用户在选择交换机厂商和 SDN 控制器时提供了更大的选择空间，因为它们使用相同的开放标准协议进行通信。

公有云引入后网络领域发生的变化

毋庸置疑，2006 年推出的 AWS 的出现彻底改变并塑造了网络格局。AWS 使公司能够在 AWS 平台上快速开发其产品。AWS 为最终用户创造了一套创新的服务，使他们能够管理基础设施、负载均衡，甚至数据库。这些服务引领了 DevOps 理念的实现，允许用户按需弹性地扩展和收缩基础设施。开发人员不再受到基础设施等待时间的限制，可以更高效地进行产品开发。AWS 丰富的技术功能集允许用户通过点击门户来创建基础设施，或者更多的高级用户通过配置管理工具（如Ansible、Chef、Puppet、Salt或平台即服务（PaaS）解决方案）来编程创建基础设施。

AWS 概述

2016 年，AWS 的虚拟私有云（VPC）保护一组 Amazon EC2 实例（虚拟机），这些实例可以通过 VPN 连接连接到任何现有网络。这个简单的构造改变了开发人员希望和期望的网络消费方式。

2016 年，我们生活在一个以消费为主导的社会，手机让我们能即时访问互联网、电影、游戏，或是各种不同的应用程序来满足我们的一切需求，换句话说，我们生活在即时满足的时代，因此不难理解 AWS 对最终用户的吸引力。

AWS 允许开发人员通过 AWS 门户的图形用户界面，通过几次点击，选择不同的规格（CPU、RAM 和磁盘）来在他们自己的个人网络中配置实例（虚拟机），或者通过简单的 API 调用或使用 AWS 提供的 SDK 进行脚本编写。

那么现在有一个合理的问题，为什么开发人员在 AWS 可用的情况下，仍然需要在本地数据中心等待长时间才能处理基础设施或网络工单？这个问题其实不难回答。解决方案肯定是将其迁移到 AWS，或者创建一个能够提供相同敏捷性的私有云解决方案。然而，答案并非总是如此简单，下面是反对使用 AWS 和公有云的一些理由：

• 不知道数据实际上存储在哪里以及在哪个数据中心

• 无法将敏感数据存储在远程地点

• 无法保证所需的性能

• 高昂的运行成本

所有这些问题对于一些受高度监管、需要符合 PCI 合规性或必须满足特定监管标准的企业来说，都是实际的障碍。这些问题可能会阻碍一些企业使用公有云，因此，像大多数解决方案一样，并不是“一个解决方案适用于所有”。

在私有数据中心，有一个文化问题，即团队被设置为在孤岛中工作，并没有为成功的敏捷业务模型做准备，因此，很多时候，使用 AWS、微软 Azure 或谷歌云只是对破碎的运营模型的一个快速修复。

工单系统，作为破碎的内部运营模型的典型代表，并不是一个与速度相匹配的概念。提交给相邻团队的 IT 工单可能需要几天或几周才能完成，因此在虚拟或物理服务器提供给开发人员之前，请求会被排队等待。此外，对于网络变更也同样如此，例如对 ACL 规则的简单修改，由于工单积压，可能需要很长时间才能实施。

开发人员需要能够随时扩展服务器或原型化新功能，因此，长时间等待 IT 工单处理会妨碍新产品推向市场或现有产品的 bug 修复。在内部 IT 中，信息技术基础架构库（ITIL）的某些从业者将每周处理的工单数量作为成功的主要指标，这表明他们完全忽视了开发人员的客户体验。一些操作需要转交给开发人员，这些操作传统上是由内部 IT 或影子 IT 负责的，但在业务层面需要对操作流程进行调整，才能推动这些变化。

简而言之，AWS 改变了开发人员的期望以及对基础设施和网络团队的期望。开发人员应该能够像在手机上修改应用程序一样迅速满足自己的需求，摆脱公司内部 IT 操作模型带来的拖延。

但是对于可以使用 AWS 的初创公司和企业来说，若不受监管要求的限制，它就省去了雇佣团队去安装服务器、配置网络设备和支付数据中心运营成本的需求。这意味着他们可以通过输入信用卡信息来启动可行的业务并在 AWS 上运行，就像在亚马逊或 eBay 上购买新书一样简单。

OpenStack 概述

对 AWS 的反应在竞争者中引起了恐慌，因为它打乱了云计算行业，并促使了Cloud Foundry和Pivotal等 PaaS 解决方案的出现，为混合云提供了一个抽象层。

当市场遭遇颠覆时，它会引发反应，由此催生了新的私有云的构思。2010 年，由 Rackspace 和 NASA 共同发起了一项名为 OpenStack 的开源云软件计划，因为 NASA 无法将其数据存储在公共云中。

OpenStack 项目旨在帮助组织提供基于标准硬件运行的云计算服务，并直接模仿 AWS 提供的模式。与 AWS 的主要区别在于，OpenStack 是一个开源项目，领先的供应商可以使用它将 AWS 类似的能力和敏捷性带到私有云中。

自 2010 年成立以来，OpenStack 已发展成为超过 500 家会员公司的一部分，这些公司通过 OpenStack 基金会积极推动社区发展，其中包括全球最大的 IT 供应商的铂金会员和黄金会员。

OpenStack 基金会的铂金会员包括：

OpenStack 是一个开源项目，这意味着它的源代码是公开的，其底层架构可以供分析使用，不像 AWS 那样像一个魔法盒子，外表光鲜亮丽，但我们并不了解它是如何在内部运作的。

OpenStack 主要用于在私有云中提供基础设施即服务（IaaS）功能，它使得普通的 x86 计算、集中存储和网络功能可以被终端用户自助服务，无论是通过 Horizon 仪表板，还是通过一套常用的 API。

许多公司现在正在实施 OpenStack 来建立自己的数据中心。与自己独立完成不同，一些公司正在使用不同供应商提供的社区上游项目的加固发行版。已经证明，使用供应商加固的 OpenStack 发行版，可以大大提高 OpenStack 实施成功的可能性。对于一些公司来说，实施 OpenStack 最初可能会觉得很复杂，因为它是一个公司可能尚不熟悉的新技术。使用知名供应商的专业服务支持时，OpenStack 实施不太可能失败，并且它可以为企业解决方案（如 AWS 或 Microsoft Azure）提供一个可行的替代方案。

如 Red Hat、HP、Suse、Canonical、Mirantis 等供应商为客户提供不同的 OpenStack 发行版，并附带不同的安装方法。尽管源代码和功能相同，这些 OpenStack 供应商的商业模式是将 OpenStack 加固以便企业使用，而他们对客户的差异化服务是专业服务。

有许多不同的 OpenStack 发行版可供客户选择，以下供应商提供 OpenStack 发行版：

• Bright Computing

• Canonical

• HPE

• IBM

• Mirantis

• Oracle OpenStack for Oracle Linux，或称 O3L

• Oracle OpenStack for Oracle Solaris

• Red Hat

• SUSE

• VMware 集成 OpenStack（VIO）

OpenStack 供应商将支持构建、持续维护、升级或客户所需的任何定制服务，所有这些都将反馈给社区。OpenStack 作为开源项目的优势在于，如果供应商为客户定制了 OpenStack，并创造了真正的差异化或竞争优势，他们不能将 OpenStack 分支或单独销售此功能。相反，他们必须将源代码贡献回上游开源 OpenStack 项目。

这意味着所有竞争供应商都在推动 OpenStack 的成功，并从彼此的创新工作中受益。然而，OpenStack 项目不仅仅是为了供应商，任何人都可以贡献代码和功能，推动项目向前发展。

OpenStack 维持一个发布周期，每六个月会创建一个上游发布版本，并由 OpenStack 基金会进行管理。需要注意的是，许多公共云服务，如 AT&T、RackSpace 和 GoDaddy，也基于 OpenStack，因此它不仅限于私有云，它无可否认地已成为 AWS 公有云的私有云替代方案，并且现在广泛用于 网络功能虚拟化（NFV）。

那么 AWS 和 OpenStack 在网络方面是如何工作的呢？AWS 和 OpenStack 都由一些必需的和可选的项目组成，所有这些项目集成在一起，形成其参考架构。必需的项目包括计算和网络，这是任何云解决方案的基础，而其他项目则是可选的附加组件，用于增强或扩展功能。这意味着最终用户可以根据自己的兴趣挑选项目，形成个人化的组合。

AWS 的网络方法

在讨论完 AWS 和 OpenStack 后，首先我们将探讨 AWS 的网络方法，然后再看看使用 OpenStack 的替代方法，并对这两种方法进行比较。在 AWS 中首次设置网络时，AWS 中的租户网络是通过 VPC 实例化的，VPC 在 2013 年之后废弃了 AWS 经典模式；但 VPC 到底是什么？

亚马逊 VPC

VPC 是新客户访问 AWS 时的默认设置。VPC 也可以通过允许 AWS 云扩展私有数据中心来连接到客户的网络（私有数据中心），以提高灵活性。将私有数据中心连接到 AWS VPC 的概念使用了 AWS 所称的客户网关和虚拟私有网关。简单来说，虚拟私有网关只是两个冗余的 VPN 隧道，它们从客户的私有网络实例化。

客户网关暴露来自客户站点的一组外部静态地址，这些地址通常是网络地址转换穿越（NAT-T），以隐藏源地址。UDP 端口4500应该在私有数据中心的外部防火墙中可访问。一个客户网关设备可以支持多个 VPC。

VPC 提供了一个隔离的视图，展示了 AWS 客户在 AWS 公有云中配置的所有内容。不同的用户账户可以使用 AWS 身份与访问管理（IAM） 服务设置到 VPC 上，并可以设置自定义权限。

以下是一个 VPC 示例，展示了与一个或多个安全组映射并连接到不同子网的实例（虚拟机），这些子网通过 VPC 路由器连接：

VPC通过将构件集成到软件中，大大简化了网络操作，并允许用户执行以下网络功能：

• 创建映射到子网的实例（虚拟机）

• 创建应用于实例的域名系统（DNS）条目

• 分配公共和私有 IP 地址

• 创建或关联子网

• 创建自定义路由

• 应用与关联的 ACL 规则的安全组

默认情况下，当一个实例（虚拟机）在 VPC 中实例化时，它将被放置在默认子网中，或者如果指定了自定义子网，则会放置在自定义子网中。

所有 VPC 在创建时都会有一个默认路由器，路由器可以添加额外的自定义路由，路由优先级也可以设置为将流量转发到特定的子网。

亚马逊 IP 地址分配

当一个实例在 AWS 中启动时，它将自动由动态主机配置协议（DHCP）分配一个必需的私有 IP 地址，并且还会分配一个公共 IP 和 DNS 记录，除非另有规定。私有 IP 地址用于 AWS 中的虚拟机之间的东西-东西流量路由，当虚拟机需要与同一子网上的相邻虚拟机进行通信时，而公共 IP 地址则通过互联网可用。

如果需要为实例分配一个持久的公共 IP 地址，AWS 提供了弹性 IP 地址功能，每个 VPC 账户最多可使用五个弹性 IP 地址，任何失败的实例的 IP 地址可以快速映射到另一个实例。需要注意的是，使用 AWS 时，公共 IP 地址的 DNS 生存时间（TTL）传播可能需要长达 24 小时。

在吞吐量方面，AWS 实例支持 最大传输单元 (MTU) 为 1,500，这可以传递给 AWS 中的实例，因此在考虑应用性能时需要考虑这一点。

亚马逊安全组

AWS 中的安全组是一种将许可访问控制列表（ACL）规则分组的方式，因此不允许显式拒绝。AWS 安全组充当实例的虚拟防火墙，可以与一个或多个实例的网络接口相关联。在 VPC 中，您可以将网络接口与最多五个安全组相关联，并为每个安全组添加最多 50 条规则，每个 VPC 的最大安全组数量为 500 个。AWS 账户中的 VPC 默认具有一个默认安全组，如果没有指定其他安全组，将自动应用此默认安全组。

默认安全组允许所有出站流量和来自同一 VPC 中其他使用默认安全组的实例的所有入站流量。默认安全组无法删除。自定义安全组在首次创建时不允许任何入站流量，但允许所有出站流量。

与安全组相关联的许可访问控制列表（ACL）规则控制入站流量，并可以通过 AWS 控制台（GUI）添加，如后文所示，或者可以通过 API 进行编程添加。与安全组相关联的入站 ACL 规则可以通过指定类型、协议、端口范围和源地址来添加。请参阅以下截图：

亚马逊区域和可用区

VPC 可以访问共享计算的不同区域和可用区，这决定了 AWS 实例（虚拟机）将部署在哪个数据中心。AWS 中的区域是完全隔离的地理区域，其中可用区是该特定区域中的独立位置，因此，可用区是区域的一个子集。

AWS 为用户提供了将资源放置在不同位置以实现冗余的能力，因为有时特定区域或可用区的健康状况可能会出现问题。因此，AWS 鼓励用户在部署生产工作负载时使用多个可用区。用户还可以选择在多个区域之间复制他们的实例和数据。

在每个独立的 AWS 区域内，存在子可用区。每个可用区通过低延迟链接与同区域的其他可用区相连。不同区域之间的所有通信都是通过公共互联网进行的，因此使用地理上距离较远的区域时会产生延迟。托管跨区域发送数据的应用时，还应考虑数据加密。

亚马逊弹性负载均衡

AWS 还允许在 VPC 中配置 Elastic Load Balancing (ELB) 作为附加服务。ELB 可以是内部的也可以是外部的。当 ELB 为外部时，它允许通过关联的 DNS 条目创建一个面向 Internet 的入口点，并在不同实例之间进行负载均衡。安全组会被分配给 ELB 以控制需要使用的访问端口。

下图展示了一个弹性负载均衡器，正在对 3 个实例进行负载均衡：

OpenStack 的网络架构

在考虑了 AWS 网络之后，我们将探索 OpenStack 的网络架构，并查看其服务是如何配置的。

OpenStack 部署在数据中心的多个控制节点上，这些控制节点包含所有 OpenStack 服务，可以安装在虚拟机、裸机（物理）服务器或容器上。在生产环境中部署时，OpenStack 控制节点应以高度可用和冗余的方式托管所有 OpenStack 服务。

不同的 OpenStack 供应商提供不同的安装程序来安装 OpenStack。一些来自最著名的 OpenStack 发行版的安装程序示例包括 RedHat Director（基于 OpenStack TripleO）、Mirantis Fuel、HP 的 HPE 安装程序（基于 Ansible）和 Canonical 的 Juju，它们都可以安装 OpenStack 控制节点，并用作 OpenStack 工作流管理工具，帮助扩展 OpenStack 云上的计算节点。

OpenStack 服务

安装在 OpenStack 控制节点上的核心 OpenStack 服务的详细说明如下：

• Keystone 是 OpenStack 的身份服务，允许用户访问，发放令牌，并可以与 LDAP 或 Active Directory 集成。

• Heat 是 OpenStack 基础设施的编排配置工具。

• Glance 是 OpenStack 的镜像服务，用于存储虚拟机或裸机服务器的所有镜像模板。

• Cinder 是 OpenStack 的块存储服务，允许集中式存储卷的配置，并可以将其附加到虚拟机或裸机服务器上，之后可以进行挂载。

• Nova 是 OpenStack 的计算服务，用于配置虚拟机，并使用不同的调度算法来决定将虚拟机放置在哪些可用的计算节点上。

• Horizon 是 OpenStack 的仪表板，用户可以通过它查看运行在租户网络中的虚拟机或裸机服务器的状态。

• Rabbitmq 是 OpenStack 的消息队列系统。

• Galera 是用于存储 OpenStack 数据的数据库，它存储所有 Nova（计算）和 Neutron（网络）数据库中的虚拟机、端口和子网信息。

• Swift 是 OpenStack 的对象存储服务，可以作为一个冗余的存储后端，在多个服务器上存储对象的复制副本。Swift 与传统的块存储或文件存储不同；对象可以是任何非结构化数据。

• Ironic 是 OpenStack 的裸金属配置服务。最初是 Nova 代码库的一个分支，它允许将镜像部署到裸金属服务器，并使用 IPMI 和 ILO 或 DRAC 接口来管理物理硬件。

• Neutron 是 OpenStack 的网络服务，包含 ML2 和 L3 代理，并允许配置网络子网和路由器。

就 Neutron 网络服务而言，Neutron 架构在结构上与 AWS 非常相似。

注意

关于 OpenStack 服务的有用链接可以在以下位置找到：

docs.openstack.org/admin-guide/common/get-started-openstack-services.html

www.youtube.com/watch?v=N90ufYN0B6U

OpenStack 租户

一个项目，在 OpenStack 中通常被称为租户，提供一个团队在 OpenStack 云中所部署的所有资源的隔离视图。然后，可以通过 Keystone 身份服务为一个项目（租户）设置不同的用户帐户，Keystone 可以与 轻量目录访问协议（LDAP）或 Active Directory 集成，支持可定制的权限模型。

OpenStack Neutron

OpenStack Neutron 执行 OpenStack 中的所有网络功能。

以下网络功能由 OpenStack 云中的 Neutron 项目提供：

• 创建与网络映射的实例（虚拟机）

• 使用内建的 DHCP 服务分配 IP 地址

• DNS 条目从命名服务器应用到实例

• 分配私有 IP 地址和浮动 IP 地址

• 创建或关联网络子网

• 创建路由器

• 应用安全组

OpenStack 被设置为其 模块化第二层（ML2）和 第三层（L3）代理，这些代理配置在 OpenStack 控制节点上。OpenStack 的 ML2 插件允许 OpenStack 与使用 Open vSwitch 或 Linux Bridge 的交换机厂商集成，并充当一个与交换机厂商无关的插件，因此厂商可以创建插件，使其交换机与 OpenStack 兼容。ML2 代理在 hypervisor 上运行，通过 远程过程调用（RPC）与计算主机服务器进行通信。

OpenStack 计算主机通常使用一个 hypervisor 部署，该 hypervisor 使用 Open vSwitch。大多数 OpenStack 厂商发行版在其参考架构中默认使用 KVM hypervisor，因此这一组件由所选的 OpenStack 安装程序在每个计算主机上进行部署和配置。

OpenStack 中的计算主机连接到 STP 三层模型的接入层，或者在现代网络中连接到 Leaf 交换机，VLAN 与每个单独的 OpenStack 计算主机相连接。租户网络随后用于提供租户之间的隔离，并使用 VXLAN 和 GRE 隧道连接第二层网络。

Open vSwitch 在 KVM hypervisor 上的内核空间运行，并通过使用从交换机推送流数据的 OpenStack 安全组管理防火墙规则。 neutron L3 代理允许 OpenStack 在租户网络之间进行路由，并使用在租户网络内部部署的 neutron 路由器来完成此操作，没有 neutron 路由器，网络将彼此隔离以及其他所有内容。

配置 OpenStack 网络

在 Project（租户）网络中使用 neutron 设置简单网络时，将配置两个不同的网络，即内部网络和外部网络。内部网络用于实例之间的东西流量。如下所示在适当的网络名称下使用地平线仪表板创建：

子网名称和子网范围随后在子网部分指定，如下截图所示：

最后，在网络上启用 DHCP，并选择性配置任何名为分配池（指定子网中可用地址范围的名称）以及任何名为DNS 名称服务器，如下所示：

还需要创建外部网络，以便从 OpenStack 外部访问内部网络，当由管理员用户创建外部网络时，需要选择设置外部网络复选框，如下一截图所示：

然后在 OpenStack 中创建路由器以路由数据包到网络，如下所示：

创建的路由器随后需要与网络关联；通过为私有网络上的路由器添加接口来实现，如下截图所示：

创建的外部网络随后需要设置为路由器的网关，如下截图所示：

这样就完成了网络设置；内部和外部网络的最终配置如下所示，显示了一个连接到内部和外部网络的路由器：

在 OpenStack 中，通过选择部署实例时选择私有网络 NIC 将实例配置到内部私有网络。 OpenStack 有一个公共 IP 地址池（浮动 IP）的分配约定，用于需要在 OpenStack 外部可路由的实例。

为设置一组浮动 IP 地址，OpenStack 管理员将使用来自外部网络的分配池来设置分配池，如下截图所示：

与 AWS 类似，OpenStack 使用安全组来设置实例之间的防火墙规则。与 AWS 不同，OpenStack 支持传入和传出的 ACL 规则，而 AWS 允许所有的出站通信，OpenStack 可以同时处理传入和传出的规则。根据需要创建定制的安全组，以便对 ACL 规则进行分组，如下所示：

然后可以针对安全组创建传入和规则。SSH 访问被配置为针对父安全组的 ACL 规则，该规则被推送到 Open VSwitch 内核空间中的每个虚拟化主机，如下图所示：

一旦项目（租户）拥有两个网络，一个内部网络和一个外部网络，并且配置了适当的安全组，实例就可以在私有网络上启动。

通过在 Horizon 中选择启动实例并设置以下参数来启动实例：

• 可用区

• 实例名称

• 规格（CPU、RAM 和磁盘空间）

• 镜像名称（基础操作系统）

然后选择私有网络作为实例的NIC，并在网络选项卡下进行配置：

这意味着当实例启动时，它将使用 OpenStack 的内部 DHCP 服务从分配的子网范围中选择一个可用的 IP 地址。

还应该选择一个安全组来管理实例的 ACL 规则；在这个例子中，选择了 testsg1 安全组，如下图所示：

一旦实例已配置完成，可以从外部网络关联一个浮动 IP 地址：

然后，从外部网络浮动 IP 地址池中选择一个浮动 IP 地址，并将其与实例关联：

浮动 IP 地址将 OpenStack 部署在内部公网 IP 地址上的实例通过 NAT 映射到外部网络的浮动 IP 地址，从而允许实例从 OpenStack 外部访问。

OpenStack 区域和可用区

与 AWS 一样，OpenStack 在实例创建时也使用区域和可用区。OpenStack 中的计算主机（虚拟化主机）可以被分配到不同的可用区。

在 OpenStack 中，可用区只是计算资源的虚拟划分。可用区可以进一步细分为主机聚合。需要注意的是，一个计算主机只能分配给一个可用区，但可以是同一可用区中多个主机聚合的一部分。

Nova 使用一个名为Nova 调度器规则的概念，规定了实例在资源配置时如何在计算主机上进行部署。Nova 调度器规则的一个简单例子是 AvailabilityZoneFilter 过滤器，意味着如果用户在配置时选择了一个可用性区，那么实例将只会被部署到该可用性区下的任意计算实例上。

另一个例子是 AggregateInstanceExtraSpecsFilter 过滤器，意味着如果一个自定义的 flavor（CPU、RAM 和磁盘）被标记为某个键值对，且一个主机聚合被标记为相同的键值对，那么如果用户使用该 flavor 部署，AggregateInstanceExtraSpecsFilter 过滤器将会把所有实例放置在该主机聚合下的计算主机上。

这些主机聚合可以分配给特定团队，这意味着团队可以选择性地决定与哪些应用共享其计算资源，同时也可以用来防止“噪声邻居”问题。OpenStack 提供了多种过滤器，允许以不同的顺序应用来决定实例调度。OpenStack 使得云操作员可以创建一个传统的云模型（有大量竞争资源的计算），也可以创建更为定制化的使用场景，在这些场景中需要为特定应用工作负载隔离计算资源。

以下示例显示了带有组的主机聚合，并展示了一个名为1-Host-Aggregate的主机聚合，归类在名为DC1的可用性区下，包含两台计算主机（hypervisors），它们可以分配给特定团队：

OpenStack 实例资源配置工作流。

当在 OpenStack 中配置实例（虚拟机）时，将执行以下高级步骤：

• Nova 计算服务将使用从 glance 镜像服务中选择的镜像发出请求以创建新的实例（虚拟机）。

• Nova 请求可能会先通过RabbitMQ排队，然后才会被处理（RabbitMQ 使得 OpenStack 能够处理多个同时的资源配置请求）。

• 一旦新实例的请求被处理，该请求将在 Nova Galera 数据库中写入一个新行。

• Nova 将查看在 OpenStack 控制节点上定义的 Nova 调度器规则，并使用这些规则将实例部署到一个可用的计算节点（KVM hypervisor）。

• 如果找到一个符合 Nova 调度器规则的可用 hypervisor，则资源配置过程将开始。

• Nova 将检查所选 hypervisor 上是否已经存在镜像。如果不存在，镜像将从 hypervisor 转移并从本地磁盘启动。

• Nova 将发出一个 Neutron 请求，这将创建一个新的 VPort 并将其映射到 Neutron 网络。

• 然后，VPort 信息将被写入 Nova 和 Neutron 数据库中的 Galera，以将实例与网络关联。

• Neutron 将发出 DHCP 请求，从它所关联的子网中分配一个私有 IP 地址给实例。

• 随后，将分配一个私有 IP 地址，并且实例将开始在私有网络上启动。

• 随后，将联系 neutron 元数据服务以检索云初始化信息，并在启动时从指定的命名服务器为实例分配 DNS 条目（如果已指定）。

• 一旦 cloud-init 运行完毕，实例将准备就绪。

• 然后，可以为实例分配浮动 IP，以通过网络地址转换（NAT）访问外部网络，使实例能够公开访问。

OpenStack LBaaS

像 AWS 一样，OpenStack 也提供负载均衡即服务（LBaaS）选项，允许将传入请求均匀地分配到指定的实例，使用虚拟 IP（VIP）。LBaaS 所支持的功能和特性取决于所使用的厂商插件。

OpenStack 中流行的 LBaaS 插件包括：

• Citrix NetScaler

• F5

• HaProxy

• Avi networks

这些负载均衡器向 OpenStack LBaaS 代理暴露不同程度的特性。利用 OpenStack 的 LBaaS 的主要驱动因素是，它允许用户将 LBaaS 作为负载均衡解决方案的中介，用户可以通过 OpenStack API 或通过 Horizon GUI 配置负载均衡器。

LBaaS 允许在 OpenStack 的租户网络中设置负载均衡。使用 LBaaS 意味着，如果用户出于某种原因希望使用新的负载均衡厂商而不是现有厂商，只要他们使用 OpenStack LBaaS，这一过程就变得更加简单。由于所有调用或管理都是通过 LBaaS 的 API 或 Horizon 进行的，因此不需要修改用于配置和管理负载均衡器的编排脚本，也不会绑定到每个厂商的自定义 API 中，负载均衡解决方案就成为了一种商品化的服务。

总结

在本章中，我们介绍了一些现代数据中心中使用的基本网络原理，特别关注了 AWS 和 OpenStack 云技术，这两者是当前最流行的解决方案之一。

阅读完本章后，你应该已经了解了 Leaf-Spine 与 Spanning Tree 网络架构的区别，理解了 AWS 网络架构，并对如何在 OpenStack 中配置私有网络和公共网络有了基本的了解。

在接下来的章节中，我们将基于这些基础网络结构，探讨如何使用配置管理工具以编程方式控制它们，并利用这些工具自动化网络功能。但首先，我们将关注一些软件定义网络控制器，这些控制器可用于进一步扩展 OpenStack 在私有云中相较于 neutron 的功能，以及它们带来的一些特性和优势，帮助简化网络运维管理。

注意

亚马逊内容的有用链接包括：

aws.amazon.com/

www.youtube.com/watch?v=VgzzHCukwpc

www.youtube.com/watch?v=jLVPqoV4YjU

OpenStack 内容的有用链接包括：

wiki.openstack.org/wiki/Main_Page

www.youtube.com/watch?v=Qz5gyDenqTI

www.youtube.com/watch?v=Li0Ed1VEziQ

第二章：软件定义网络的出现

本章将讨论开放协议的出现，这些协议帮助了软件定义网络（SDN）解决方案。它将重点介绍 Nuage VSP SDN 解决方案，这是诺基亚（前身为阿尔卡特朗讯）提供的 SDN 平台，允许用户创建虚拟覆盖网络。我们将了解 Nuage VSP 在扩展性方面相对于 AWS 和 OpenStack 的开箱体验所提供的一些优势和特点。它将阐述这些网络解决方案为什么成为著名复杂私有云网络的必需品，通过简化网络结构并通过提供一套可编程 API 和 SDK 来帮助网络自动化。

本章将详细讨论以下主题：

• 为什么 SDN 解决方案是必要的

• Nuage SDN 解决方案的工作原理

• OpenStack 与 Nuage VSP 平台的集成

• Nuage VSP 软件定义对象模型

• Nuage VSP 如何支持 Greenfield 和 Brownfield 项目

• Nuage VSP 的多播支持

为什么 SDN 解决方案是必要的

SDN 解决方案是必要的，因为它们使企业能够简化网络操作，同时还可以实现网络功能的自动化。它与 DevOps 倡议和使网络操作更灵活的需求非常契合。

SDN 的副产品是，它使得网络功能变得像在虚拟机监控器上创建新虚拟机一样精确且可重复。

来自供应商的 SDN 解决方案由一个集中式控制器组成，该控制器被实现为网络的神经中枢。SDN 控制器在很大程度上依赖于Open vSwitch 数据库（OVSDB），这是一种可编程的开放标准模式，利用 OpenFlow 协议，直接与交换机集成，用于路由网络中的数据包，并将 ACL 策略应用于特定的虚拟机、物理服务器或容器。

只要交换机能够支持 OVSDB 和 OpenFlow，就可以与常见的 SDN 控制器集成。目前市场上有各种各样的 SDN 控制器：

• CISCO ACI

  www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/index.html

• 诺基亚 Nuage VSP

  www.nuagenetworks.net/products/virtualized-services-platform/

• Juniper Contrail

  www.juniper.net/uk/en/products-services/sdn/contrail/

• VMWare NSX

  www.vmware.com/products/nsx.html

• Open Daylight

  www.opendaylight.org/

• MidoNet Midokura

  www.midokura.com/midonet/

SDN 控制器为企业做以下事情：

• 为网络功能提供一个易于使用的解决方案，SDN 控制器将网络功能从硬件设备中抽象出来，而是暴露图形用户界面（GUI）和 API 端点，可以通过编程方式进行修改以控制网络操作。

• SDN 控制器适用于 DevOps 模型，例如为开发人员提供自服务的网络操作，允许持续交付网络功能并增加团队间的协作。

• 提供更高的网络配置可见性，并通过易于理解的软件构造进行描述。

• 通过使用开放的网络标准提供更好的基础设施集成，这使得公司在选择集成的交换机厂商时有了更多选择。

• 允许在私有数据中心应用相同的策略，并跨私有和公有云进行应用。这使得将不同工作负载分配到不同云服务提供商的目标成为现实，并使得混合云的安全治理对于安全团队来说更加容易。

AWS 的出现无疑影响了网络厂商，使他们的解决方案更加注重软件方法，而非硬件，这反过来简化了网络操作，并使网络更容易扩展。

厂商现在已采用并实现开放协议，以允许集中管理网络功能，并使网络运营商能够使用 SDN 控制器管理整个网络。

企业正在使用软件定义网络（SDN）来最大化其网络性能，并创建可重复的网络操作工作流，就像虚拟化技术帮助基础设施团队自动化服务器配置和管理一样。

然而，根据我的个人经验，私有云中的软件定义网络被用于大规模运行 OpenStack。许多大型公司（如 Walmart、Ebay、PayPal、Go Daddy 以及我的公司 Paddy Power Betfair）不断采用 OpenStack 项目，这意味着公司正在转向 SDN 解决方案，以便达到必要的扩展目标并简化网络操作。

Nuage SDN 解决方案如何工作

市场领先的 SDN 解决方案之一是 Nuage SDN（VSP）平台，它是诺基亚的 SDN 解决方案（前身为阿尔卡特朗讯），因此我们将探索这种市场领先的 SDN 解决方案是如何工作的。

Nuage VSP 平台包含三个主要组件——VSD、VSC 和 VRS。

• 虚拟化服务目录（VSD）：这是整个平台的策略引擎，提供图形用户界面，并暴露一个 restful API 供网络工程师使用和与网络功能进行交互。

• 虚拟化服务控制器（VSC）：这是 Nuage 的 SDN 控制器，使用 OpenFlow 和 OVSDB 管理协议将交换和路由信息分发给虚拟机监控器、裸金属服务器或容器。

• 虚拟路由与交换（VRS）：这是 Nuage 定制版本的 Open vSwitch，安装在计算节点（虚拟化主机）上。

Nuage VSP 可以与 OpenStack、CloudStack 和 VMWare 私有云平台或公共云解决方案（如 AWS）集成。Nuage 创建了一个覆盖网络，能够在隔离的租户网络中保护虚拟机、裸金属服务器和容器，因此根据需要部署的工作负载类型，具有高度的灵活性。

虚拟机当然是在物理虚拟化主机上作为虚拟抽象进行部署的，容器可以在虚拟机或物理服务器上运行。容器用于通过 Linux 命名空间和控制组隔离特定的进程或资源，这些命名空间和控制组在操作系统级别划分资源，因此虚拟机和容器的网络要求非常不同。容器因其可移植性而被使用，可以在虚拟机或裸金属（物理）服务器上运行。另一个优点是它们被 Linux 操作系统封装，多个容器可以在虚拟机或物理服务器上运行。

Nuage 还支持通过虚拟化主机或物理机在基础网络中路由多播流量，并将其泛洪到租户网络中的特定虚拟或物理机器，从而实现租户网络之间的多播。这在云解决方案中一直是一个问题，但 Nuage 提供了针对这一问题的解决方案。

Nuage VSP 的 SDN 控制器（VSC）通过硬件 VTEP（由交换机在网络的接入或叶层暴露）与交换机通过 OVSDB 集成。VSC 被冗余部署，并通过多路径边界网关协议（MP-BGP）与彼此通信，并将 VXLAN 封装程序编程到交换机上，因为它们是硬件 VTEP 识别的。

VSD 组件在一个包含三台 VSD 服务器的活动集群中设置，这些服务器通过可行的负载均衡器解决方案进行负载均衡。负载均衡器提供一个虚拟 IP（VIP），通过轮询模式对三台 VSD 服务器进行负载均衡。

VSD 的 VIP 提供 Nuage VSP 平台的图形用户界面，并作为 API 入口点，允许通过 REST 调用程序化控制覆盖网络。对 Nuage VSD GUI 执行的任何操作都会触发一个 REST API 调用到 VSD，因此 GUI 和 REST API 执行的是相同的程序化调用，所有操作都通过 REST API 公开。

Nuage VSD 管理第二层和第三层的域、区域、子网和 ACL 策略。VSD 使用可扩展消息和存在协议（XMPP）将策略信息传递给 VSC，VSC 使用 OpenFlow 将流信息推送到计算主机（虚拟化主机）上的定制版 Open vSwitch（VRS），以为应用程序创建防火墙策略。

Nuage VSP 还允许裸金属服务器通过将 OpenFlow 数据推送到虚拟化服务网关（VSG）并将路由信息泄漏到覆盖网络中，连接到覆盖网络。

以下图表概述了 VSP 平台协议集成：

将 OpenStack 与 Nuage VSP 平台集成

私有数据中心网络可能非常复杂，因此使用标准的 OpenStack Neutron 来满足所有用例可能无法提供所需的所有功能。需要注意的是，Neutron 中的功能随着每个新的 OpenStack 版本的发布而快速成熟，因此未来 Neutron 可能会与专用的 SDN 控制器一样功能丰富。

Neutron 通过提供 REST API 扩展，便于与 SDN 控制器集成，因此如果需要提供非常丰富的网络功能，SDN 控制器可以轻松地用来扩展 Neutron 提供的基础网络功能。

SDN 解决方案的使用帮助 OpenStack 实现了大规模扩展，因为它将 OpenStack 的网络方面从集中式的 L3 代理移开，转而将请求发送到专用的 SDN 控制器，并实现分布式防火墙功能。

这意味着一个 OpenStack 云可能会横向扩展支持的计算实例数量，而无需担心与当前 Neutron 网络架构相关的瓶颈或扩展问题。

OpenStack 是最受欢迎的私有云解决方案之一，Nuage VSP 平台通过 Nuage 插件与 OpenStack 集成。Nuage 插件安装在每个高可用（HA）OpenStack 控制器上。

在控制器上，Neutron ML2 和 L3 代理都被关闭，取而代之的是 Nuage 插件。下图展示了 OpenStack Neutron 的 SDN 控制器框架架构，其中 SDN 控制器通过 REST API 调用与 OpenStack Neutron 进行通信：

VSD，作为 Nuage 策略引擎，通过设置网络分区与 OpenStack 集成，网络分区可用于将一个 Nuage VSP 映射到 OpenStack 云，并通过 REST API 调用与 Neutron 进行通信。

通过使用网络分区，多个 OpenStack 实例可以映射到单一的 Nuage VSP。网络分区是一种方式，用来告诉 Nuage VSP 平台将哪个 OpenStack 实例映射到其子网，并等待发出 VPort 命令，这些命令表示 OpenStack nova 计算服务已经配置了需要由 Nuage ACL 策略管理的虚拟机实例。

当 Nuage VSP 与 OpenStack 集成时，OpenStack 厂商安装程序需要原生支持 Nuage，或者安装程序需要稍作定制，以便在 OpenStack 控制器上安装 Nuage 插件。每个部署在 OpenStack 云中的计算节点（虚拟化主机）上也需要安装 Nuage 版本的 OpenvSwitch（VRS）。

Nuage 插件通过以下工作流程与 OpenStack 控制器和 KVM 计算进行集成：

当发出一个 neutron 命令到 OpenStack 时，Nuage 插件使用 REST API 调用与 Nuage VSD 通信，告知已创建新的网络或在该网络上创建了新的 VPort，这得益于 neutron 的 SDN 控制器可插拔 REST API 架构。

Nuage VSD 策略引擎然后与 VSC 通信，通过 XMPP 推送流数据。VSC（SDN 控制器）随后将流数据（OpenFlow）管理到 Nuage VRS（Open vSwitch），并且 Nuage VRS 使用预定义的防火墙策略保护 OpenStack 虚拟机或物理服务器。

防火墙策略可以是 OpenStack 安全组或 Nuage ACL 规则，具体取决于选择了 OpenStack 管理模式还是 Nuage VSD 管理模式。

Nuage 或 OpenStack 管理的网络

Nuage OpenStack 插件可以在两种操作模式下使用，以管理在 OpenStack 中配置的网络：

• Nuage VSD 管理模式

• OpenStack 管理模式

Nuage VSD 管理模式允许 Nuage 成为网络配置的主控；这使得 Nuage VSP 平台可以提供丰富的功能集来管理 OpenStack 环境中的网络。网络功能通过 VSD 直接配置，使用 Nuage REST API 通过 GUI 或直接 API 调用进行，并与 OpenStack 子网一对一映射。

另一种操作模式是 OpenStack 管理模式，该模式不需要在 VSD 上进行直接配置。所有命令通过 neutron 发出；但是，功能仅限于 OpenStack neutron 支持的命令。

所有在 Nuage 中创建的网络都在 OpenStack 中以一对一的映射方式复制，其中 Nuage VSD 在 VSD 管理模式下作为主控，而 OpenStack neutron 在 OpenStack 管理模式下作为配置主控。

在 OpenStack 管理模式下，所有的 ACL 规则由 OpenStack 安全组控制，而在 VSD 管理模式下，ACL 规则由 Nuage VSD 控制，并且安全组被禁用。

Nuage 通过设置网络分区与 OpenStack 集成。通过网络分区，单个 Nuage VSP 平台可以映射到多个 OpenStack 实例。网络分区是将 OpenStack 云映射到 Nuage 组织实体的方式。

使用 Nuage VSP 平台并命名组织为Company时，每当在组织下创建一个子网时，它会在创建时被分配一个唯一的nuage_subnet_uuid。为了将组织和 Nuage 子网映射到 OpenStack Neutron，发出以下命令：

neutron subnet-create "Subnet Application1" 10.102.144.0/24 --nuagenet nuage_subnet_uuid --net-partition "Company" --name "Subnet Application1"

一旦通过 Nuage VSP 平台和 OpenStack 建立了网络分区，防火墙策略会通过 Nuage VRS 在计算主机（虚拟化服务器）上得到保障。当在 Nuage 管理的子网中创建新实例时，会触发以下工作流：

Nuage 或 OpenStack 管理的网络

1. 一个实例被添加到一个由 Nuage VSP 平台拥有的 OpenStack 网络和子网中。

2. 一个占位符 VPort（虚拟机 ID，MAC 地址）由Nuage 插件在请求的第三层域内创建于VSD上。

3. Nova 服务在Hypervisor上创建虚拟机。这被VRS（虚拟机 ID，MAC 地址）检测到。

4. VRS查询VSC，然后VSC查询VSD以从占位符 VPort 中检索相关的网络信息。

5. VSD根据虚拟机 ID、MAC 地址与其创建的 VPort 进行匹配，并将虚拟机与正确的网络服务关联。

6. 策略通过VSD通过VSC下载到VRS，使用 OpenFlow，所需的流将动态创建。

Nuage VSP 软件定义对象模型

由于 Nuage 在软件中创建了覆盖网络，它需要一个简单的对象模型来让网络管理员进行管理。Nuage VSP 软件定义对象模型提供了一个网络的图形化层级结构，使得覆盖结构能够被轻松查看和审计。

对象模型概览

• 组织：它管理所有的第三层域。对象模型概览

• 第三层域模板：在创建子第三层域之前，需要一个第三层域模板。第三层域模板用于管理所有子第三层域将传播的整体默认策略。如果在模板级别更新了第三层域模板，那么该更新会立即在其下已创建的所有第三层域上实施。对象模型概览

• 第三层域：这可以用来划分不同的环境，以便用户无法从第三层测试域下部署的子网跳跃到相邻的第三层生产域。对象模型概览

• 区域：一个区域在应用层面上划分防火墙策略，因此每个微服务应用可以有自己的区域，并且每个第三层域可以有各自的 Ingress 和 Egress 策略。对象模型概览

• 第三层子网：这是虚拟机或裸金属服务器被部署的地方。

  在此示例中，我们看到子网应用 1和子网应用 2，如下所示：

  对象模型概览

Nuage VSD 中的层级结构如下所示：

• 创建了名为 Company 的一个组织。

• 创建了名为 Test 和 Production 的两个层 3 域在公司之下。

• Test 层 3 区域具有 Application1 和 Application2 的区域，Application1 和 Application2 区域下各有 1 个子网。

• Production 层 3 区域具有 Application1 和 Application2 的区域，Application1 下只有 1 个子网。Application2 区域目前没有子网。

出于安全和合规目的，向安全审计人员展示 开发 和 生产 环境之间的分隔非常重要。通常情况下，开发 环境不会应用与生产环境一样严格的控制。生产应用可以使用最小权限的约定进行安全保护，以最大程度地减少访问并降低安全漏洞的可能性。

Nuage VSP 平台可以使用其层 3 域模板结构设置环境之间的分隔。域模板可以设置默认的 拒绝所有 策略在入口和出口级别。这是所有策略中优先级最高的策略，将明确拒绝所有数据包无论协议是入站还是出站连接，除非对该特定应用程序的策略明确允许。默认的 拒绝所有 是应用于应用程序的 ACL 规则列表中的底部策略。

域模板上的 出口安全策略 显示为以下的 底部策略：

出口安全策略 的内容显示为具有最高可能优先级，如下所示：

同样，入口的明确禁用被应用到域模板作为 底部策略：

虽然域模板上的 入口安全策略 明确禁用如下所示：

应用于域模板 Company L3 Domain Template 的默认入口和出口策略如下图所示，显示应用于所有子层 3 域，例如 Production 和 Test。

域模板 Company L3 Domain Template 被显示链接到子层 3 域 Production 和 Test，显示从域模板继承的出口策略：

同样，域模板 Company L3 Domain Template 被链接到子层 3 域 Production 和 Test，显示从域模板继承的入口策略：

需要注意的是，由于使用 OpenFlow 将策略推送到 VRS，Nuage 中的入口和出口的 ACL 规则遵循以下原则：

• 出口：这是一个数据包从 VRS 流向子网或区域。

• 入口：这是一个数据包从子网或区域流向 VRS。

举个例子，一个出口 ACL 规则将指定来自 VRS 的任何出口流量从端口 80 将被转发到 子网 Application1：

在这个示例中，一个入口 ACL 规则将指定任何入口流量可以从端口 80 离开 子网 Application1 并转发到 VRS：

如果应用程序所有者遵循这样的原则：他们的应用程序部署所在的第 3 层子网，总是作为源或目的出现在各自应用程序策略的 ACL 规则中，那么一个应用程序的 ACL 规则将只存在于该自包含的策略中。如果遵循这一概念，它使得每个应用程序的 ACL 规则能够封装在独立的策略中，在第 3 层域内，这反过来意味着，安全团队审计这些规则将变得更加简便。这也意味着应用程序遵循最小权限原则，仅开放必要的端口以便应用程序之间通信，并且对那些不符合规则的流量施加显式丢弃。

显示了两项策略，分别适用于两个应用程序，Application1 和 Application2，它们分别有入口和出口的独立策略，默认入口策略指定对任何未显式允许的流量进行显式丢弃。

入口安全策略如下所示：

出口安全策略如下所示：

Nuage VSP 平台的第 3 层域模板允许使用区域进行第二级分段，因此传统的网络被划分为三个区域，其中应用程序将部署在以下层级：

• 前端

• 业务逻辑

• 后台

随着微服务架构的崛起，每个应用程序的配置文件并不总是适应这三种广泛的配置文件。有时，应用程序既可以是前端应用程序，也可以是业务逻辑应用程序，那么这种微服务应用程序应该如何放置在传统的三层架构中呢？

与可以在区域级别应用的前端、业务逻辑和后台分隔策略不同，应用程序之间在每个子网间的有意义微分段成为可能。那么，这如何在 Nuage 中实现呢？

如果一个应用程序希望与另一个应用程序进行通信，它将拥有一个 ACL 规则，指定子网到区域的通信，以便在第 3 层域中相邻子网上的应用程序之间进行东西向通信。Nuage 通过允许应用程序进行子网到区域的通信来实现这一点。

为了允许这种通信，Application1可以具有 ACL 策略，允许Application2区域允许流量进入22端口的子网，实现东西向通信，因此无论使用多少不同的子网，Application1都将始终能够与位于Application2区域下的任何应用程序进行通信。

在安全策略方面，这使得开发和安全团队能够通过查看应用程序策略了解哪些应用程序正在相互通信以及它们使用的端口。

Nuage VSP 平台如何支持绿地和棕地项目

覆盖网络通常作为新的网络（绿地）站点进行设置，但单独的全新网络是没有用的，除非计划进行一次性的大规模迁移，将所有应用程序从遗留网络迁移到新网络。

如果选择阶段性应用程序迁移，仅将部分应用程序迁移到新网络中，那么新的覆盖网络将需要与遗留网络进行通信，并要求在棕地环境中运行。

棕地环境通常意味着应用程序会分阶段迁移到新平台，而不是一次性全部迁移，这有助于增加对新网络及其相关技术的信心。在将应用程序迁移到新平台时，通常需要在新网络中对迁移后的应用程序进行性能测试，之后才会将现有遗留网络的实时流量转移到迁移到新覆盖网络中的应用程序。

阶段性迁移的一个主要要求是要连接回遗留网络，以便处理托管在其中的应用程序依赖关系。这种连接是必要的，以便迁移后的应用程序能够有效运行。

Nuage VSP 平台使用其虚拟化服务网关（VSG）提供新覆盖网络和遗留网络之间的连接。两台 Nuage VSG 在虚拟底盘模式下冗余连接，并连接到位于遗留网络中路由器上的接口。VSG 根据从连接路由器接口的 VLAN 进入的数据包的目标 IP 执行路由表查找；然后它更新目标 MAC 地址为下一个跳跃地址，并将数据包转发到相应的 VXLAN 段。所有数据包都通过基础网络从遗留网络路由到 VSG。

这将新覆盖网络和遗留网络通过 VXLAN 终结于 VSG 进行连接。

以下是 Nuage VSD 中的一对活动 VSG：

Nuage VSG 通过将路由泄露到覆盖网络来允许与传统网络进行通信。每个 VSG 将使用 BGP 会话接收并通告 IPv4 路由，当使用叶脊拓扑结构并使用 iBGP 时，此 BGP 会话将在 VSG、VSC 和叶交换机之间建立。

VSG 必须将其本地系统 IP 通告给传统网络中的路由器，并且所有从本地网络接收到的路由将随后通过下层网络泄露到覆盖网络中的选定层 3 域。

在 Nuage VSP 平台中，泄露路由所需的设置是创建一个GRThubDomain层 3 域。在这个示例中，主机接口连接到传统网络中的前端、业务逻辑和后端路由器：

然后，Nuage VSP 平台允许将新创建的GRThubDomain与Production或Test层 3 域相关联，通过将泄露域与它们相关联。

在下面的示例中，GRThubDomain与Production层 3 域相关联。

在 Nuage GUI 中，泄露域通过以下图标显示，显示的是一个名为GRThubDomain的泄露域：

具有关联泄露域的生产域在 Nuage GUI 中显示如下：

泄露域的关联允许 Nuage VSP 平台通过下层网络将路由从传统网络泄露到新覆盖网络中，这意味着覆盖网络中的应用程序可以与传统网络中的应用程序进行通信，只要它们具有适当的 Ingress 和 Egress ACL 策略。

如前所述，Test和Production层 3 域有一个Deny All规则，用于 Ingress 和 Egress，这是公司 L3 域模板的一部分。因此，尽管所有路由都泄露到覆盖网络中，但除非明确说明，否则它们会被 VRS 丢弃。

Nuage VSP 平台具有应用 ACL 规则的能力，针对从外部传统网络泄露的路由，使用一种名为网络宏的概念。在 Nuage VSP 平台中，网络宏只是外部网络范围的一个花哨名称。

如果一个应用程序，Application3就是其中之一，位于传统网络中，并且它的路由已经通过GRThubDomain泄露域并泄露到Test层 3 域中，那么可以设置一个网络宏来描述所需的范围，并通过 Nuage ACL 规则隔离与之的连接。

在此实例中，网络范围10.58.11.0/24是Application3所在的范围，它是GRThubdomain中的前端范围的一部分，并已泄漏到覆盖网络中。Application3的网络宏在 Nuage 中显示如下：

然后，可以配置一个出站 ACL 策略，通过创建一个网络宏到子网的 ACL 规则，允许Application3的网络宏与Subnet Application1在端口8080上进行通信。

允许Application3 网络宏与Subnet Application1通过端口8080通信的出站安全策略如下所示：

创建后，ACL 列表将更新，显示新的网络宏ACL：

这使得 Nuage VSP 能够锁定策略，并且覆盖网络仅允许来自传统网络的特定流量，就像它在同一第 3 层域内的子网或区域之间控制 ACL 策略一样。网络宏也可以用于在多个云技术以及不同数据中心之间进行路由，因此它们是连接网络并控制网络之间策略的强大方式。

多个网络宏可以组合成一个网络宏组，这样可以通过一个 ACL 规则控制多个范围。然后，这些范围在 VRS 的 OpenFlow 级别上被展开。Nuage 在 3.x 版本中每个 VPort 的 ACL 规则数量限制为 100，因此目前每个实例（虚拟机）只能应用 100 个 ACL 规则，因此在组合网络宏时需要特别小心。在 Nuage 平台的 4.x 版本中，ACL 规则的数量已增加到 500 个。

以下是一个网络宏组的示例，然后可以在出站 ACL 规则中使用前端服务 网络宏组，而不是为Application3和Application4指定单独的策略：

允许前端服务 网络宏组与Subnet Application1之间通过端口8080连接的出站安全策略：

实施前端服务网络宏的 ACL 可以在此找到：

Nuage VSP 的多播支持

Nuage VSP 平台具有在以下 Nuage VSD 实体之间路由多播的能力：

• 第 2 层和第 3 层域

• 区域

• 子网

• 附加到虚拟机的 VPorts

多播可以路由到覆盖网络，这是 Nuage VSP 平台的独特功能。在 Nuage 中，通过在底层二层网络上配置专用 VLAN，并将其附加到计算节点上，将多播流量路由到覆盖网络。这使得底层网络上的计算节点（虚拟化管理程序）可以使用按机架分配的专用 VLAN 来发送和接收多播流量。

为了在底层网络上路由多播流量，Nuage VRS 将复制多播数据包，并以受控的方式将其泄漏到覆盖网络中。这样可以避免覆盖网络被不必要的多播流量洪泛，如果不加以控制，可能会对覆盖网络性能造成影响。这使得 Nuage 的多播设置具有高度的可扩展性，因为它只将多播流量引导到覆盖网络中需要的地方。

Nuage VSP 使用专用 VLAN 用于计算节点（虚拟化管理程序）的多播发送和接收。每个 VLAN 可以在每个虚拟化管理程序上进行配置，以便支持有多播需求的应用程序。

每个虚拟化管理程序都会为多播发送和接收分配一个 VLAN 和唯一的 IP 地址，这取决于虚拟化管理程序所在的机架，以便使用相应的交换机。

端口通道映射是 Nuage VSD 中用于将多播从底层网络泄露到覆盖网络的实体。如果多播需要在覆盖网络中从子网到子网路由，则需要端口通道映射。如果多播仅在同一子网中使用，则不需要端口通道映射，多播将在一个隔离的三层子网内工作，无需通过虚拟化管理程序上的 VLAN 路由流量。

在以下示例中，使用多播通道映射来为应用程序 2创建多播范围，该应用程序广播多播。这将通过虚拟化管理程序上的底层 VLAN，将多播从子网应用程序 2路由到 Nuage VRS，并将其洪泛到子网应用程序 1。

多播通道映射图标如下所示：

以下场景描述了一个应用程序在覆盖网络中将多播流量从一个三层子网路由到另一个子网的工作流程。

应用程序 1将部署在一个三层域下，属于自己的区域，位于一个/26 微子网中，并且在该子网下，两个虚拟机将连接到两个虚拟端口（VPort）。在 Nuage 中，虚拟机可以设置为多播的发送方或接收方，或者两者兼有：

在此实例中，应用程序 1是多播的发送方，想要将多播流发送到应用程序 2，该应用程序部署在一个三层域下，属于自己的区域，位于一个/26 微子网中，并且在该子网下，只有一台虚拟机将连接到一个虚拟端口。

所以需要在Application1上设置一个端口通道映射，并将其与每个Application1的 VPort 关联，这样 Nuage 就知道Application1是组播的发送方。

Application2将配置其 VPort 并设置端口通道映射，以便接收组播。

当Application1的两台虚拟机广播组播流量时，Nuage 现在知道将组播流量路由到与端口通道映射中指定的匹配组播范围相符的超管上，Application1部署于此。

Nuage 将使用发送者 VLAN 在超管二层域上传输组播。

每个超管的接收 IP 上的接收 VLAN 将会接收到组播的传输。

如果在超管上的任何虚拟机上指定了端口通道映射，并且匹配了已配置的Multicast Ranges，如Application2所做的那样，那么 Nuage VRS 将复制组播数据包，并将它们泄漏到覆盖网络中，传递给Application2。

这就是 Nuage 如何使用基础网络和发送者与接收者 VLAN 将组播流量泄漏到覆盖网络的方式。

总结

本章中，我们介绍了 Nuage VSP SDN 解决方案提供的一些高级网络功能，并简要介绍了市场上其他可用的 SDN 解决方案。阅读本章后，你应该已经熟悉了 Nuage SDN 控制器，并理解了 SDN 控制器能为 OpenStack 和私有云带来的丰富功能。

鉴于程序化 SDN 控制器、AWS 和 OpenStack 解决方案带来的优势，我们现在将转向关注在组织内实现这些令人振奋的技术所需的文化变革。仅仅实施新技术而不改变操作模型是不够的，人员和流程是成功 DevOps 模型的关键。

网络工程师的角色正在经历多年来最大的变革，因此企业不能仅仅实现新技术并期望更快的交付，而不处理人员和文化问题。首席技术官有责任通过实施包括网络功能的 DevOps 转型，为其网络团队的成功奠定基础，同时网络团队也需要学习新技能，如编程，以通过草根倡议推动自动化。

注意

关于 Nuage Networks 实际应用案例的有用链接如下：

www.youtube.com/watch?v=_ZfFbhmiNYo

www.youtube.com/watch?v=aKa2idHhk94

www.youtube.com/watch?v=OjXII11hYwc

第三章：将 DevOps 引入网络运维

本章将重点转向人员和流程，而不是技术。DevOps 的初衷是打破开发与运维团队之间的壁垒，并改变公司运营模式。它将重点介绍解锁 IT 员工、帮助他们以更高效的方式工作的方法，但这些思维方式如今已被扩展到质量保证测试、安全性，甚至网络运维。本章将主要关注网络工程师的角色演变，这一角色与之前的运维工程师一样正在发生变化，网络工程师需要学习新技能，以便在行业朝着完全程序化控制的运营模型发展时，依然能保持现有的价值。

本章将探讨两种不同的角色：CTO / 高级经理与工程师，详细讨论可以用来促进所需文化变革的一些举措，这些变革对于实现整个组织的 DevOps 转型至关重要，或者至少帮助某个单独的部门通过自动化所有工作来改善其内部流程。

本章将涵盖以下主题：

• 启动行为变革

• 自上而下的 DevOps 倡议针对网络团队

• 针对网络团队的自下而上的 DevOps 倡议

启动行为变革

网络的 OSI 模型包含七个层级，但广泛建议在 OSI 模型中增加一个名为“用户层”的第八层，负责管理终端用户如何与网络进行集成和互动。显然，人与技术相比，更难以掌握和管理，因此不存在一刀切的解决方案来应对大量的人员问题。OSI 的七层结构如下图所示：

启动文化变革和行为变革是组织将面临的最困难任务，而且这不是一蹴而就的。要改变行为，首先必须有明显的商业利益。重要的是要先概述这些文化变革将为组织带来的好处，这将使经理或变革推动者能够为实施所需的变革提供商业正当性。

文化变革以及应对人员和流程的挑战是众所周知的困难，因此，将工具与人员和流程分开，专注于人员和流程的管理是任何 DevOps 项目或倡议成功的关键。文化变革需要经过精心规划，并成为公司的一项倡议。在最近一项由 Gartner 进行的研究中，数据显示，选择错误的工具并不是云项目失败的主要原因，失败的主要原因是未能改变操作模型：

实施 DevOps 的原因

在实施 DevOps 时，常常会流传一些误解，比如 DevOps 只适用于初创公司，它对某个特定团队没有任何价值，或者它只是一个流行词和潮流。

如果正确实施，DevOps 项目的可量化收益是不可否认的。这些收益包括对以下方面的改进：

• 变更的速度

• 平均解决时间

• 提升的正常运行时间

• 部署次数的增加

• 团队间的跨技能培训

• 消除单一故障点的风险

IT 行业中的任何团队都会从这些改进中受益，因此团队实际上不能不采用 DevOps，因为这无疑会改善他们的业务功能。

通过实施 DevOps 项目，能够促进可重复性、衡量和自动化。实施自动化自然提高了变更的速度，增加了团队在任何给定一天内可以进行的部署次数，并改善了产品上市时间。部署过程的自动化使得团队能够快速将修复推送到生产环境，同时也让组织能够将新产品和新功能迅速推向市场。

自动化的副产品是，基础设施问题的平均解决时间也会变得更快。如果基础设施或网络变更是自动化的，那么它们的应用效率要远高于人工执行。人工变更取决于实施变更的工程师的速度，而不是能够更精确地衡量的自动化脚本。

实施 DevOps 还意味着需要有效地进行衡量和监控，因此在所有基础设施和网络的各个部分拥有有效的监控至关重要，因为这意味着根本原因分析的速度得以提升。有效的监控有助于促进平均解决时间的缩短，因此当生产问题发生时，可以比让大量工程师登录控制台和服务器进行调试问题更快地找到问题的根源。

相反，一个良好实施的监控系统可以提供快速的通知，定位问题的根源，并消除因初步根本原因导致的任何警报，使问题能够高效地得到解决。

然后，监控会交给可重复的自动化流程，这些自动化流程可以将本地修复推送到生产环境。这个过程提供了一个高度精确的反馈循环，流程会日益改进。如果遗漏了警报，它们理想情况下会随着时间推移被纳入监控系统，成为事件事后分析的一部分。

有效的监控和自动化会导致更快的平均解决时间，从而带来更满意的客户，并改善产品的正常运行时间。利用自动化和有效的监控也意味着团队的所有成员都有机会看到流程如何运作以及修复和新功能是如何推送出去的。

这将减少对关键个人的依赖，消除巴士因子问题——即某个关键工程师需要做团队中的大部分工作，因为他是最熟练的个体，且所有系统知识都掌握在他脑中。

使用 DevOps 模型意味着非常高技能的工程师可以将他们的才华用来帮助跨技能其他团队成员，并创建有效的监控系统，帮助任何团队成员执行他们通常手动完成的根本原因分析。这将深厚的知识融入监控系统中，因此，监控系统，而非工程师本身，将成为发生问题时的首选参考点，或者理想情况下，监控系统将成为警报源，及时提醒事件，避免客户问题。为了提高跨技能，工程师理应帮助编写自动化流程，这样他们就不是唯一能够完成特定任务的团队成员。

实施 DevOps 以改善网络的原因

那么，DevOps 的一些好处如何适用于传统的网络团队呢？今天独立的网络团队常见的抱怨包括以下几点：

• 反应性工作

• 慢，通常通过工单系统进行协作

• 使用管理员终端执行手动操作

• 缺乏前期测试

• 手动错误导致网络中断

• 一直处于应急模式

• 日常流程中缺乏自动化

网络团队像之前的基础设施团队一样，通常习惯于在独立的团队中工作，通过工单系统或使用不够理想的流程与大组织中的其他团队互动。这种工作方式既不流畅也不优化，正是这种情况促使了 DevOps 倡议的诞生，旨在打破开发和运维团队之间的壁垒，但其范围已扩大。

网络团队似乎最初并未被纳入 DevOps 运动，但软件交付只能以最慢的组件速度运作。最慢的组件最终会成为整个交付过程的瓶颈或障碍。这个最慢的组件通常会成为一个独立团队中的明星工程师，因为他无法手动处理足够的工单来跟上需求，从而成为“巴士因子”（bus factor）。如果该工程师休假或生病，工作就会被阻塞，整个公司对他依赖过大，无法高效运作。

如果一个团队的运作方式与其他部门不同，那么所有其他部门的工作效率都会受到影响，因为该部门的工作不够灵活。简单来说，大多数公司中网络团队存在的原因是为开发团队提供服务。开发团队需要部署网络，这样他们才能测试产品更改，并将产品部署到生产环境中，一旦部署到生产环境，业务就能开始通过这些产品盈利。

网络对访问控制列表（ACL）策略、负载均衡规则以及为新应用程序提供新子网的变更，若需要数天、数月甚至数周才能完成，就不能再被视为成功。网络直接影响变更速度、平均修复时间、正常运行时间以及部署次数，这些都是成功 DevOps 倡议的四个关键绩效指标。因此，企业需要将网络纳入 DevOps 模型，否则这些可量化的收益将受到制约。

考虑到 AWS、Microsoft Azure、OpenStack 和软件定义网络（SDN）能够快速地在私有和公有云中配置网络功能，现在网络团队不再适应他们的运营流程并学习新技能已经不可接受。但有一个前提是，网络的演变非常迅速，他们需要支持和时间来完成这一过程。

如果实施了云解决方案，但运营模型没有改变，那么组织将无法感受到任何真正的可量化收益。云项目传统上并不是因为技术失败，而是因为现有的运营模型阻碍了它们的成功。如果公司不改变其运营模型，并允许最终用户使用 API 自助服务其请求，那么构建一个全新的 OpenStack 私有云——具备用于管理计算、网络和存储的开放可扩展 API——将毫无意义。

如果网络工程师仍在使用图形界面（GUI）进行指点、点击和复制粘贴，那么这并不能带来真正的业务价值，因为复制粘贴最慢的网络工程师就是瓶颈。公司完全可以继续使用现有的技术和流程，因为采用手动流程的私有云解决方案并不会加速市场发布的时间，也不会缩短从失败中恢复的时间。

然而，云不应成为贬低内部网络员工的借口，因为公司中现有的运营模型通常不是由当前的员工设计或设置的，而是继承下来的。迁移到公有云并不能解决公司网络团队的运营敏捷性问题，它只是一种权宜之计，掩盖了更深层次的文化挑战。

然而，更智能的工作方式结合自动化、测量和监控的使用，能帮助网络团队完善内部流程，并促进他们与开发和运营人员的日常协作。文化变革可以通过两种方式启动：一种是来自工程师的自下而上的草根倡议，另一种是来自高层管理的自上而下倡议。

面向网络团队的自上而下 DevOps 倡议

自上而下的 DevOps 倡议是指 CTO、总监或高级经理需要从公司获得支持，以对操作模型进行改变。这些改变是必要的，因为现有的操作模型被认为不够理想，并且无法像竞争对手一样快速交付软件，从而导致新产品或重要修复的推迟，影响市场的及时交付。

当从自上而下的管理层进行 DevOps 转型时，如果要对操作模型进行重大更改，必须先与相关团队进行一些基础工作，因为这种大规模的变动往往会导致现场员工的不安或压力。

在实施操作变革时，高层管理人员需要获得现场员工的支持，因为他们每天将会在这一模型下工作。让团队获得支持是非常重要的一环，否则，公司将面临员工不满的局面，这最终意味着最优秀的员工将离开。

在实施新的操作流程时，让高层管理人员与员工积极互动，并从一开始就透明处理任何担忧是非常重要的，而不是去参加一个外部管理会议，然后带着一个强制性的计划回来，这种情况太常见了。

管理层应对团队进行调查，以了解他们每天是如何运作的，喜欢当前流程的哪些方面，以及他们在哪些方面感到困惑。改变操作模型的最大障碍是误解现有的操作模型。所有的倡议理想情况下应该是由团队主导，而不是强加的。所以让我们重点关注一些可以帮助的具体自上而下的倡议。

分析成功的团队

一种方法是管理层查看组织内其他团队的运作情况，特别是那些流程运作良好且采用增量敏捷方式交付的团队。如果组织内没有团队以这种方式运作，可以联系其他公司。

询问是否可以参观其他公司的一天运营方式。大多数公司会很高兴将成功的项目作为案例在会议或聚会中展示，因为他们喜欢展示自己的成就，所以寻找那些已经克服了类似文化挑战的公司应该不难。参加一些 DevOps 会议并看看谁在发言，接触这些发言人，他们无疑会乐意提供帮助。

管理团队应首先与高效能团队安排一次会议，并进行问答环节，重点关注以下几点，如果是外部供应商，那么一次简单的介绍电话也可以。

在初次会议中需要提出的一些重要问题如下：

• 哪些流程通常运作得很好？

• 他们每天实际上使用什么工具？

• 工作是如何分配的？

• 他们如何跟踪工作进展？

• 团队结构是什么？

• 其他团队是如何向该团队提出请求的？

• 工作是如何优先排序的？

• 他们如何处理中断？

• 会议是如何组织的？

不要重新发明轮子，如果组织中的某个团队已经有一个经过验证的模板并且运行良好，那么这个团队在帮助推动网络团队的文化变革中也可能是无价的。如果将焦点放在外部团队作为传播者上，会稍微更具挑战性，因为这会带来一些借口，比如说他们公司因为 x、y、z 的原因，所以更容易做到。

当组织中的本地团队作为传播者时，一个好的策略是将一名网络工程师嵌入该团队几周，观察并反馈其他团队如何运作并记录他们的发现。这是至关重要的，确保网络工程师理解现场的流程。

灵活性同样重要，因为只有部分成功团队的流程可能适用于网络团队，因此不要期望两个团队的工作方式完全相同。团队的整体和个人的差异意味着每个团队都是不同的，因此应专注于目标，而不是严格的流程执行。如果团队通过稍微不同的方式达成相同的结果，只要工作可以追踪且对管理层可见，并且能够轻松报告，就不应该成为问题。

确保优先考虑节奏，选择特定的变革推动者，以确保团队对新流程感到舒适，因此，赋予网络团队的变革推动者选择工作方式的权力，通过与团队互动创建新流程，同时让他们负责最终的工具选择。然而，在选择任何工具之前，重要的是从流程开始，并就新的操作模型达成一致，以防止工具推动流程，这在 IT 领域是一个常见错误。

绘制活动图

一个好的建议是使用活动图作为视觉辅助工具，帮助理解团队互动如何运作以及如何改进。

这里展示了一个典型的开发活动图，包含手动交接给质量保证团队的流程：

使用活动图作为视觉辅助工具非常重要，因为它能够突出不理想的业务流程。在这个例子中，我们看到一个开发团队的活动图。这个流程是不理想的，因为它在本地测试和同行评审阶段没有包括质量保证团队。相反，它有一个正式的 QA 交接阶段，这个阶段出现在开发周期的后期，这种做法很不理想，因为它促成了开发和 QA 的孤岛效应，这是 DevOps 反模式。

更好的方法是让质量保证工程师负责创建测试任务和创建自动化测试，而开发团队负责编码任务。这将允许开发同行评审流程在开发生命周期的早期由质量保证工程师审查和测试开发人员的代码，并确保每段编写的代码在提交之前具有适当的测试覆盖率。

流程中的另一个缺点是，它未考虑到质量保证团队或客户在生产中发现的软件缺陷，因此将这些工作流引入活动图中也很有用，以展示所有潜在的反馈循环。

如果在整体活动图中漏掉了反馈循环，那么可能会导致流程流失，因此捕捉在映射工具前可以促进流程的所有排列组合是非常重要的。

每个团队都应考虑缩短互动时间的方法，以帮助减少解决时间并提高工作能够流经整体流程的速度。

管理层应该在他们的日程中安排一些时间与开发、基础设施、网络和测试团队会面，并绘制出他们认为各自团队流程的图示。保持高层次，这应该是一个简单的活动泳道，利用从接受工作开始到团队进行工作交付的过程。

每个团队绘制出初始方法后，应专注于优化它，并去除他们不喜欢的流程部分，并讨论团队如何改进流程的方式。可能需要多次迭代才能有效绘制出这一过程，所以不要急于此过程，应该将其视为每个团队的学习经验。

最终的活动图通常会以优化的方式结合管理和技术功能，以展示整体流程。在此阶段不要使用业务流程管理（BPM）软件，简单的白板足以保持简单和非正式。

在活动图中使用两层是一个良好的做法，因此第一层可以是一个简单的方框，仅写着同行评审，然后引用一个嵌套的活动图，概述团队的同行评审过程。两者都需要精细化，但业务流程的嵌套层应由各个团队决定，因为这些是特定于他们需求的，所以在这个层面给团队所需的灵活性非常重要。

将这两个层次分开是很重要的；否则，活动图的整体顶层将过于复杂，无法从中提取任何真正的价值，因此尽量减少顶层的复杂性，因为这将需要与其他团队的流程集成。这个活动不需要包含团队特定的细节，比如内部团队的同行评审流程如何操作，因为这将始终是该团队主观的；这应该包括在内，但将是一个不会被分享的嵌套层次活动。

另一个团队应该能够查看团队的顶层活动图并理解流程而无需解释。有时首先绘制高效团队的顶层活动图可以很有用，以展示一个集成的、连贯的业务流程应该是什么样子。

这将帮助那些在这些概念上有些困难的团队，并允许他们使用那个团队的活动图作为指南。这可以作为参考点，并展示这些团队如何解决他们的跨团队互动问题，并促进一个或多个团队在没有摩擦的情况下互动。这个练习的主要目的是连接业务流程，使它们不再在团队之间孤立，以便为集成的计划和执行尽可能地整合工作。

一旦每个团队完成了他们的个人活动图并将其优化到团队希望的方式，流程的第二阶段可以开始。这涉及将每个团队的顶层活动图分层，以创建一个集成的流程。

团队应该将这个分层练习作为借口来讨论次优的流程以及整个业务流程应该如何从头到尾看起来。利用这个会议来消除团队之间的感知瓶颈，完全忽略现有工具以及当前工具的约束，整个练习应该集中在流程而非工具上。

一个受工具约束的次优流程流程的良好示例是顶层活动图上的一个阶段，表示使用工单系统提出工单。应将其细分为以人为中心的工作，请求变更的人实际需要什么？

开发者的日常工作包括编写代码和构建优秀的功能和产品，所以如果一个新功能需要网络变更，那么网络应被视为该功能变更的一部分。因此，网络变更所需的时间需要作为该功能的规划和估算的一部分考虑，而不是作为一个单独的请求，当其作为事后想法被动执行时，会阻碍变更的速度。

当参与度高时，这通常是一次非常成功的练习，最好利用每个团队中的高级工程师和经理参与组合活动图层练习，更初级的工程师参与各自团队特定活动图练习。

更改网络团队的运营模式

活动图工作结束后，网络团队的操作模型应该理想地与整个业务完全融合。一旦新的操作模型与所有团队达成一致，就可以开始实施它。

需要注意的是，因为现场团队创建了操作模型并完成了协同活动图，它应该由所有相关方签署作为新的业务流程。因此，这消除了管理层强制模型的问题，因为使用该模型的人们参与了其创建。操作模型可以随着时间的推移进行迭代和改进，但互动不应该发生大的变化，尽管可能会增加最初遗漏的新互动点。然后，可以存储并更新业务流程的主副本，这样新加入公司的员工就知道如何与其他团队进行互动。

从短期来看，新的方法可能会使开发估算变慢，因为网络功能尚未实现自动化，因此当开发人员的功能需要网络更改时，估算会变得更高。

这通常只是对现实的更真实反映，因为最初的估算没有考虑到网络更改，这些更改后来成为了阻塞因素，尽管它们是票据，但一旦报告出来，就可以随着时间的推移进行优化和改进。

一旦整体活动图已合并并与所有团队达成一致，重要的是要记住，如果流程得到了妥善优化，图表上不应该有一大堆高层次的操作。如果互动过于冗长，任何变更都会需要几个小时来遍历活动图上的每一个步骤。

后面提到的活动图展示了一个协同的业务流程，其中工作从单一的路线图定义，产生适用于所有团队的用户故事。新的用户故事，作为工作单元，将由跨职能团队（包括开发人员、基础设施、质量保证和网络工程师）进行估算。每个团队将审查用户故事，确定完成功能所需的跨职能任务。

用户故事随即成为冲刺的一部分，跨职能团队一起工作，确保它在检查之前具备运行所需的一切。经过同行评审后，功能或更改将交给自动化流程，将代码、基础设施和网络更改交付到生产环境。

已检查的功能会经过单元测试、质量保证、集成和性能测试质量关卡，这些关卡将包括质量保证团队在检查前编写的任何新测试。一旦通过每个阶段，自动化流程将在按下按钮后被触发，将更改推送到生产环境。每个环境应用相同的网络更改，因此网络更改会先在测试环境中进行，然后再在生产环境中进行。

这一切依赖于将网络视为代码，意味着需要创建自动化的网络流程，以使网络团队能够像开发人员一样敏捷。

一旦达成一致的运营模式制定完毕，DevOps 转型才应开始。这将包括在每个阶段选择最合适的工具，以实现预期的结果，重点关注以下几个好处：

• 变更的速度

• 平均解决时间

• 提高正常运行时间

• 部署次数增加

• 跨团队技能共享

• 消除单点故障风险

每个公司的业务流程都不同，因此让各个部门参与其中，并获得所有管理者的支持，以确保这一活动的成功至关重要。

改变网络团队的行为

一旦新的运营模式在公司内建立起来，就要防止网络团队成为 DevOps 导向的持续交付模型中的瓶颈。

传统上，网络工程师习惯于操作命令行，并登录到网络设备的管理员控制台进行更改。基础设施工程师由于已经具备bash和PowerShell脚本编写经验，并且在 Linux 或 Windows 操作系统方面有扎实的基础，因此过渡到配置管理工具并不是一项艰巨的任务。

然而，最初说服网络工程师做出同样的转变可能会更为困难。让网络工程师向 API 编程并采用配置管理工具的过程可能最初看起来令人畏惧，因为这对入门门槛更高，但有经验的自动化工程师在场，可以帮助网络工程师顺利完成这一过渡。

保持耐心很重要，因此可以通过逐步设置一些自动化目标来改变网络团队的行为。这将鼓励正确的行为，并尝试给予奖励。可以通过提供培训或为团队购买特定的编码书籍来启动自动化计划。

还可以考虑举行一次初步的自动化黑客日；这将给网络工程师一天的时间，远离他们的日常工作，并尝试自动化一个他们每天都会重复执行的小流程。如果可能的话，可以将其设为强制性活动，要求工程师们参与，并安排其他团队替代网络团队的工作，这样他们就不容易分心。这是一个了解哪些网络团队成员可能愿意推广 DevOps 和自动化的好方法。如果某个特定的成员表现突出，可以与他们合作，帮助推动自动化计划向整个团队推广，使他们成为流程自动化的推动者。

建立一个内部的 DevOps 聚会，让各团队展示他们的自动化成就，也是推广网络团队自动化的好方法，并能保持动力。鼓励每个团队在每个季度展示他们所取得的有趣成果，并通过允许参与的团队从日常工作中抽出时间来参与，来激励他们。这样可以培养团队之间的社区感，展示他们是一个更大运动的一部分，这个运动为公司带来了真正的成本效益。这也有助于将团队的注意力集中在使公司变得更好的共同目标上，并在过程中打破团队之间的障碍。

必须避免的做法之一是让其他团队为网络团队编写所有的网络自动化。理想情况下，应该是网络团队自己发展并采纳自动化，因此赋予网络团队对网络自动化的所有权感非常重要。然而，这需要网络团队的全力支持，并且需要有纪律性，不能在出现问题时回归到手动任务。

为了顺利过渡，可以考虑从基础设施或开发团队中派一位自动化工程师加入网络团队，但这应该只是一个临时措施。重要的是选择一位受网络团队尊敬且具备网络知识的自动化工程师，因为没有人应该尝试自动化他们无法手动操作的网络流程，所以找一个精通网络的人员来帮助网络自动化至关重要，因为他们将负责培训网络团队，必须受到尊重。如果分配给网络团队的自动化工程师既不具备知识也不受尊重，那么这项计划可能会失败，因此必须谨慎选择。

重要的是要早期接受这样一个现实：向 DevOps 和自动化的过渡可能并不适合每个人，因此并不是每个网络工程师都能够走这条路。关键在于网络团队抓住机会，展现主动性和学习新技能的意愿。对于新的自动化倡议，任何破坏性或负面的行为都应该及早制止，因为它可能会对网络团队产生不良影响。

起初对新事物保持怀疑态度是可以理解的，但不尝试改变或学习新技能是不应该被容忍的，因为这会破坏团队的动态，应该对此进行监控，确保不会因为个别成员成为阻碍者或破坏者，导致自动化倡议失败或停滞不前。

每个组织都有其独特的文化，公司的变化速度将取决于新流程和新工作方式的文化接受度。在推动文化变革时，需要变革推动者，这些推动者可以来自内部 IT 员工或外部资源，具体取决于员工的变革能力和意愿。每个变革项目都是不同的，但确保有合适的人员参与，以及得到正确的管理层支持和背书，是成功的关键。

网络团队的自下而上的 DevOps 举措

自下而上的 DevOps 举措是指当工程师、团队领导或低层管理人员未必得到公司支持以改变操作模型时，他们意识到虽然不能对现有的操作模式进行整体性变革，但可以在自己的团队中运用 DevOps 思想，推动积极的变化，帮助团队更好地表现，并提高生产力。

在从自下而上的 DevOps 举措中实施时，有时会面临更多的困难和挑战，因为有些个人或团队可能不愿意改变自己的工作方式和操作方式，因为他们并没有必须改变的压力。但重要的是不要灰心丧气，尽力为业务做出最好的工作。

通过基层举措证明这一过程带来真正的业务好处，最终仍然有可能说服高层管理层实施 DevOps 举措。

在网络团队中推广 DevOps

尽量保持积极的态度，推动自下而上的举措有时可能会令人感到疲惫，但重要的是要适应各种挑战，不要太过于个人化。始终保持积极，先在自己的团队内部推广 DevOps 流程和正向行为的好处。首要的挑战是说服自己的团队，接受 DevOps 方法的优点，之后再尝试说服其他团队。

一种有效的做法是展示 DevOps 方法给其他公司带来的好处，比如 Google、Facebook 和 Etsy，重点讲述他们在网络领域所做的工作。个人可能会反驳，认为这些公司是独角兽企业，DevOps 之所以有效是因为它们的特殊性，因此要准备好接受挑战。寻找这些公司已经实施的、网络团队可以采纳的实际举措，这些举措也能真正适用于你的公司。

为了促进变革环境的形成，了解同事们的驱动力，是什么激励着他们？尝试根据个人的动机来调整说服策略，对工程师或经理的说服方式可能完全不同。一线工程师可能会受到以下因素的激励：

• 做更有趣的工作

• 发展技能和经验

• 帮助自动化繁琐的日常任务

• 学习受欢迎的配置管理技能

• 理解开发生命周期

• 学习编程

另一方面，经理可能更倾向于通过提供衡量关键绩效指标（KPI）来激励自己，使团队看起来更出色，例如：

• 实施变革所需时间

• 解决故障的平均时间

• 提高网络的正常运行时间

另一种促进参与的方法是邀请你的网络团队参加由前瞻性的网络供应商安排的 DevOps 聚会。他们可能会惊讶于大多数网络和负载均衡供应商现在都在积极推广自动化和 DevOps，而他们可能对此还不知情。这个领域的一些新创新可能足以改变他们的看法，并激发他们对一些新方法的兴趣，这样他们就能跟上行业的步伐。

寻求受人尊敬的经理或工程师的赞助

在让网络团队了解 DevOps 举措之后，下一步是将其推进到更高的层次。寻找网络团队中一个受人尊敬的经理或资深工程师，他们可能愿意尝试 DevOps 和自动化。重要的是要向此人推销这个“梦想”，阐明你对实施一些变革、帮助团队的热情，并表示你希望利用一些已经在其他成功公司中证明有效的最佳实践。

保持谦逊非常重要，尽量避免对同事大发牢骚或抛出泛化的 DevOps 术语，这可能会让人反感。始终要提出合理的论据并加以辩护，同时避免做出泛泛的陈述或概括。尽量避免让人觉得你在削弱经理或资深工程师的权威，相反，应该寻求他们的帮助，争取他们的支持和认可。此时，可能需要展开一些魅力攻势来说服经理或工程师这确实是一个好主意，但逐步推进请求可以帮助避免让人觉得请求毫无诚意。如果请求突然提出，可能会显得不真诚。可以尝试在午餐或饮品时分析情况，并判断他们是否对此感兴趣，因为如果对方固执己见，可能很难改变他们的态度，除非该举措来自上级。

一旦你鼓起勇气提出这个话题，接下来就是提出多个建议，说明在项目经理作为中介的帮助下，团队如何以不同的方式工作。请求在小范围内试行这个方法，并主动提出领导这一举措，同时请求他们的支持和背书。经理或资深工程师可能会对你的主动性印象深刻，并允许你继续推进这个想法，但他们可能会选择你执行的具体举措。因此，永远不要提出自己无法实现的建议，你可能只有一次机会，所以留下好印象至关重要。

尝试从一个小任务入手，这通常是一个痛点，并尝试自动化它。任何人都可以编写自动化脚本，但要尽量让自动化过程易于使用，找出团队在当前流程中喜欢的部分，并尝试将其融入其中。例如，如果他们经常看到命令行输出以特定方式显示，就编写自动化脚本，使输出仍然以相同的方式显示，这样流程就不会让他们感到完全陌生。

尽量避免将值硬编码到脚本中，而是将其提取到配置文件中，使自动化更具灵活性，这样它可能在不同的场景中再次使用。通过向工程师展示自动化的灵活性，能够鼓励他们更多地使用它，向团队中的其他人展示你如何编写自动化脚本，以及他们如何调整它来应用于其他活动。如果做得聪明，自动化将会被团队中的热情成员采纳，而你也将获得足够的动力，给赞助者留下深刻印象，从而推进更复杂的任务。

与网络团队一起自动化复杂问题

在通过自动化小的重复性任务建立信任之后，下一阶段的过程是解决一个更复杂的问题，这可以用来巩固未来在网络团队中使用自动化的地位。

这个过程的部分内容是让其他人有能力承担责任，并在未来主导自动化的工作，因此会花费更多的时间。至关重要的是，之前可能在初步自动化建设过程中故意避开的难合作工程师，这次必须参与进来。

这些工程师在这一阶段很可能完全没有涉及过自动化。这可能意味着团队中最有认证的成员和团队的领导者，没有人说过这会容易，但从长远来看，成功地说服最大的怀疑者相信 DevOps 和自动化的价值，将是值得的。在这个阶段，网络团队的自动化应该已经具备足够的可信度和动力，可以通过引用成功的使用案例来讨论这个话题。

在过程中涉及所有难以合作的个体，比起在过程结束时再向他们提出建议，要容易得多。如果难缠的高级工程师或经理在创建过程中参与其中并有所贡献，他们在同事面前更不可能驳回你的想法。

尽量保持尊重，即使你不同意他们的观点，但如果你认为自己是对的，也不要退缩或放弃。要以事实为基础，避免情绪化的争论，列出利弊，并记录任何担忧，不要忽视它们，你必须愿意妥协，但不能到贬低解决方案的程度。

实际上可能存在需要解决的真正风险，因此有效的观点不应被忽视或轻描淡写。如果你对某些问题不确定，或者感觉某些人态度不合理，尽量寻求你的赞助商的支持。

在实施复杂的自动化任务时，要作为团队而非个人进行工作，这对你自己以及其他人都是一种学习经历。尝试教网络团队使用配置管理工具，他们可能只是不敢尝试新事物，所以要采取温和的方法。可以适当暂停，尝试一些在线教程，让每个人熟悉工具，并尝试各种方法，以尽可能简单的方式解决问题。

尝试向网络工程师展示使用配置管理工具的简单性及其好处。不要使用复杂的配置管理工具，因为这可能让他们反感。目前大多数网络工程师不会编程，但这一点可能在未来几年发生变化。正如前面所说，基础设施工程师至少有一些 bash 或 PowerShell 的基础，这有助于他们入门，因此要选择他们喜欢的工具，并提供选择。尽量避免强制使用他们不喜欢的工具。在使用自动化时，网络工程师最关心的问题之一是同行评审，因为他们天然不信任自动化是否有效。尝试建立一些门控流程来解决这些问题，自动化并不意味着不需要同行评审，因此要创建一个轻量级的流程来帮助。通过使用源代码控制显示差异，确保自动化易于评审，并教育网络工程师如何执行此操作。

编码最初可能是一个令人生畏的任务，因此建议每周做一些团队练习，进行编码或配置管理任务。作为一个团队共同完成。这样可以减轻威胁感，重要的是要听取反馈。如果大家达成共识，认为某些东西没有发挥作用或没有带来好处，那就寻找替代方法，找到一种适合整个团队的方式实现相同的目标。在发布任何新的自动化流程之前，先在预生产环境中进行测试，并与经验丰富的工程师一起进行同行评审，并尝试让它在多个测试案例下失败。新流程只有一次给人留下第一印象的机会，因此一定要确保它是成功的。

尝试在团队之间设立知识共享会议，讨论自动化，并确保每个人都知道如何手动执行操作，这样他们就能轻松调试未来可能出现的问题，或者扩展或修改自动化。确保输出和日志对所有用户都是清晰的，因为在生产环境中使用时，所有人都需要支持自动化。

总结

在本章中，我们介绍了实践中的措施，这些措施结合起来，将使 IT 人员能够在其组织中实施成功的 DevOps 模型。它不仅仅关注部门问题，还提倡使用一套实用的策略来改变约束团队的日常操作模式。它还强调了网络工程师需要学习新技能和技术，以充分利用新的操作模型，避免成为交付过程中的瓶颈。

本章提供了实际的真实世界示例，帮助高级管理人员和工程师提升自己公司的能力，强调团队间的合作，并指出如今网络部门需要自动化所有网络操作，以满足企业的交付节奏。

本章的关键要点是，DevOps 不仅仅适用于开发和运维人员，它同样可以应用于网络团队。重要的是，在启动 DevOps 计划之前，要花时间分析成功的团队或公司，专注于他们成功的原因，但高级管理层的支持是创建成功 DevOps 模型的关键。

你们公司自己的模型不会完全照搬其他公司的模型，所以尽量避免照搬照抄。调整模型，使其适应你们公司的实际情况，允许团队创建自己的流程，但不要强制规定流程。同时，也要允许变革推动者发起团队可以接受的变更。

尝试自动化所有操作工作，从小做起，一旦团队适应了新的工作方式，再逐步解决更大、更复杂的问题。始终记住，成功的变革不会一蹴而就。它只能通过持续改进的模式来实现。

在接下来的章节中，我们将探讨如何将自动化应用于网络，并重点关注配置管理工具，例如Ansible。这些配置管理工具可以提高网络工程师实施变更的速度，并确保所有的网络变更都是以相同的方式进行，从而减少出错的可能性。

注意

关于 DevOps 的有用链接如下：

www.youtube.com/watch?v=TdAmAj3eaFI

www.youtube.com/watch?v=gqmuVHw-hQw

第四章。使用 Ansible 配置网络设备

本章将重点关注当今市场上最受欢迎的几个网络供应商，即 Cisco、Juniper 和 Arista，并探讨这些市场领先供应商如何开发自己的专有操作系统来控制网络操作。本书的目的不是讨论哪家网络供应商的解决方案更好，而是探讨网络运营商如何利用现有的配置管理工具来管理网络设备，因为大多数网络供应商已经创建了用于以编程方式控制网络的 API 和 SDK。

一旦建立了每个操作系统的基础知识，我们将转向来自 Red Hat 的非常流行的开源配置管理工具 Ansible（www.ansible.com/）。

我们将探讨如何使用它来以编程方式配置网络设备并帮助网络运营。本章将展示可用于管理网络设备的实际配置管理流程。

本章将涵盖以下主题：

• 网络供应商的操作系统

• Ansible 简介

• 当前用于网络自动化的 Ansible 模块

• 管理网络设备的配置管理流程

网络供应商的操作系统

市场领先的网络供应商，如 Cisco、Juniper 和 Arista，都开发了自己的操作系统，允许网络运营商通过命令行界面（CLI）向网络设备发出一系列命令。

每个供应商的 CLI 都是从他们专门的操作系统运行的：

• Cisco IOS 和 Nxos

• Juniper Junos

• Arista Eos

所有这些操作系统都使得通过编程方式控制交换机、路由器和安全设备变得更加容易，因为它们试图简化操作网络设备。

在行业中 DevOps 的兴起也意味着不再可以不提供编程 API 或 SDK 来帮助自动化，现在网络供应商与配置管理工具（如 Puppet、Chef、Ansible 和 Salt）集成，以插入 DevOps 工具链。

Cisco IOS 和 Nxos 操作系统

当 Cisco IOS 操作系统发布时，它是首个提供一组命令行的操作系统，网络运营商可以使用这些命令行来改变网络状态。然而，它仍然存在一些挑战；它具有单片架构，意味着所有进程共享相同的内存空间，并且在并行进程之间没有保护，因此它不适合并行更新，但在当时它是明确的市场领导者。这改变了网络操作方式，意味着网络工程师需要分别登录到网络交换机和路由器上，使用其功能齐全的 CLI 进行更新。

当时，这大大减少了网络操作的复杂性，Cisco 规范化了数据中心中网络操作的方式。网络管理员将登录到设备，运行一系列行业标准的命令行来修改路由器或交换机，Cisco 还开设了认证项目，教授管理员如何操作设备并学习所有命令。

如今，在效率和成本削减对于企业生存至关重要且业务流程向更加灵活的方式转变的背景下，这种现代数据中心模型在网络工程师与网络设备的比例上存在明显的扩展问题，每个网络设备所需的网络工程师数量。

私有云的出现意味着每个网络工程师需要管理的网络设备数量急剧增加，因此自动化成为了以一致的方式管理大量设备的关键。如果一个企业的竞争对手通过自动化的运营模型能够更快地将产品推向市场，那么他们将能比进行手动更改的组织更快地推出产品。自动化已成为跟上网络快速变化所必需的条件。随着 IT 的变化和发展，自动化已成为促进这一演变的前提。

随着近年来网络市场的演变，Cisco 开发了一个新的操作系统 Nxos，使其能够与开源技术集成并支持自动化。Nxos 操作系统已部署在所有新的 Nexus 交换机和路由器上，这一操作系统通过集成开源协议（如 BGP、EVNP 和 VXLAN）将 Cisco 推向开放和模块化的标准，且这些设备甚至可以运行 LXC 容器，这是一种操作系统级虚拟化方法，用于在虚拟机或物理服务器上运行多个隔离的进程。

Cisco 还提供了一套 REST API，允许网络运营商运行原生 Linux 和 bash shell 来执行常规的服务器端管理命令。在 AWS 和 OpenStack 提供的编程 API 可以用来变更网络基础设施的时代，网络供应商需要适应才能生存，否则就可能被淘汰。因此，Cisco 将其交换机和路由器的配置和操作简化到与虚拟设备一样容易。

Nxos 操作系统允许使用 Red Hat 企业版 Linux rpm 包管理器来控制软件更新。这意味着，软件更新可以以行业标准的方式在 Nxos 上进行，就像通过基础设施系统管理员对 Linux 客户操作系统进行打补丁一样。因此，Cisco 网络设备现在对 Linux 系统管理员来说更加直观，并且对最终用户来说更像原生 Linux，这无疑使得它们的管理变得更简单。

Cisco Nxos 操作系统意味着网络变更的推送速度得以提升，因为运营人员可以使用他们自己的工具链和配置管理工具来自动化更新。Nxos 操作系统已经变得不那么依赖厂商，因此，使用网络产品和自动化其产品套件的门槛变得更低。

Juniper Junos 操作系统

Juniper Junos 操作系统驱动程序通过程序化控制来控制网络操作，Junos 操作系统的设计旨在提供 CLI，用户可以通过它执行以检索运行系统的相关信息。Junos 操作系统基于一个明确的层次模型，而不是使用一系列不相关的配置文件。层次模型还完整支持操作模式和配置模式。

直观地说，操作模式用于升级操作系统、监控系统以及检查 Juniper 设备的状态。而配置模式则允许网络管理员配置用户访问和安全性、接口、硬件以及设备上使用的协议集，这为安装系统的人员和操作系统的人员之间提供了清晰的角色分离。Junos 操作系统支持所有开放协议，如 BGP、VXLAN 和 EVPN，并且具备内建的前滚和回滚功能。

Juniper 提供了一款名为PyEZ的 Python 库，适用于 Junos 操作系统，并为 Windows 管理员提供了一个 PowerShell 选项，该选项利用了 Python 中封装的 PowerShell。Python 库 PyEZ 可以通过使用表格和视图来检索任何配置信息，这些表格和视图允许网络管理员根据 Junos 操作系统提供的运行时信息进行脚本编写。一旦通过利用 get() 方法的 Python 脚本提取了表格项，表格可以随后被视为 Python 字典并进行迭代，这使得用户可以在需要时执行复杂的脚本，从而允许网络管理员自动化所有网络操作。Junos PYEZ 库也完全可扩展，网络管理员可以使用其小部件系统添加他们认为合适的功能。

Arista EOS 操作系统

Arista EOS 操作系统基于开放标准，旨在促进网络功能的自动化。它依赖于集中式的CloudVision eXchange（CVX），CVX 服务器保存网络的集中状态。EOS 操作系统通过 Sysdb 来分离每个交换机上的功能控制，Sysdb 是 Arista EOS 操作系统的数据库。Arista Sysdb 是一个运行在用户空间的内存数据库，包含 Arista 交换机的完整状态。Sysdb 存储在设备内存中，因此如果 Arista 交换机重新启动或断电，所有与该交换机相关的信息将丢失。

CVX 服务器作为聚合器，管理从每个交换机的 Sysdb 中收集的所有状态信息，并根据 CVX 服务器集群启用的服务，将信息汇总到网络范围的数据库中。当交换机的 Sysdb 中发生状态变化时，变化会推送到 CVX 集中数据库，随后更新其配置并通知 CVX 上运行的代理程序。

Arista EOS 操作系统支持现代开放协议，如 MLAG、ECMP、BGP 和 VXLAN。它利用 VXLAN 等覆盖技术，使得应用能够在现代数据中心中部署并保持可移植性。Arista 大力推广在 ECMP 下使用 Leaf-Spine 架构，允许实现扩展模型；这一架构与现代云解决方案如 OpenStack 一致，并使其与 SDN 控制器解决方案保持独立。

Arista EOS 操作系统是一个基于 Linux 的操作系统，旨在被程序化控制。EOS 操作系统的主要驱动力是允许网络操作员使用一套结构化的 API，包括 eAPI、CLI 命令以及作为其 SDK 产品组合的一部分的 Python、Ruby 和 GO 库，来执行网络操作。

EOS 操作系统还支持智能系统升级（SSU），通过实时修补和升级的简化及更直观的方式，支持 Arista 设备的扩展，这有助于支持企业的 99.99% 在线时间目标。交换机现在可以由数据中心运营团队在数据中心安装并接线，然后交给 Arista 的零接触配置（ZTP）过程，自动化交换机初始化，零接触替换（ZTR）允许交换机在数据中心中进行更换。

Arista EOS 解决方案 CVX 产品可以通过门户自动化网络工作流任务，如果用户需要交换机和路由器的可视化视图，CVX 允许通过 OVSDB、eAPI 或 OpenFlow 与 SDN 控制器集成。像 Cisco 和 Juniper 一样，EOS API 由于提供了多种 SDK 选项，因此 Arista 产品可以通过配置管理工具（如 Puppet、Chef、Ansible 和 Salt）轻松管理，从而避免手动进行任何网络操作。

Ansible 简介

Ansible 主要是一个基于推送的配置管理工具，它使用一个 Ansible 控制主机，并且可以通过 SSH 连接到多个 Linux 客户操作系统以对其进行配置，最近还新增了 WinRM 支持，因此它现在也可以像配置 Linux 系统一样配置 Windows 客户机。由于 Ansible 可以同时连接到多个服务器，它帮助操作员通过允许他们在多个 Linux 或 Windows 服务器上同时执行统一的操作，从而简化了自动化重复任务的过程。Ansible 还可以作为一个集中式编排工具，连接到 API 端点并对 API 操作进行排序。

在这里，我们可以看到 Ansible 控制主机如何连接到服务器或充当集中式编排工具的示例：

Ansible 执行的每个操作都应该是幂等的，这意味着如果服务器上已经配置了期望的状态，Ansible 将检查来自 playbook 或角色的目标状态，如果服务器已处于正确状态，则不会采取任何操作。只有在状态与 playbook 或角色中指定的状态不同的情况下，操作才会被执行，从而改变服务器的状态。

Ansible 是一个基于 Python 的配置管理工具，它通过一个基于 Linux 的控制主机控制服务器，使用 YAML 文件来定义和描述期望的状态。Ansible 配备了一组丰富的可扩展模块，这些模块主要是用 Python 编写的，但也可以用任何用户希望的语言编写。Ansible 模块允许 Python SDK 或 REST API 被封装在 Ansible 的插件框架中，然后可以通过 Ansible 角色或 playbook 在易于使用的架构中进行调用。在深入了解更详细的示例之前，了解一些 Ansible 的术语是非常重要的。

Ansible 目录结构

Ansible 由一系列 YAML 文件组成，这些文件布局在一个可自定义的目录结构中。

在这个自定义结构中，Ansible 控制节点具有以下目录结构：

• inventories 文件夹包含 Ansible 库存

• library 文件夹包含任何自定义的 Python 插件

• playbooks 文件夹包含所有的 playbook

• roles 文件夹包含所有的 Ansible 角色

总体目录结构如下所示：

这提供了所有 Ansible 组件的逻辑分组，随着 playbook 或角色的增多，这将非常有用。最好将 ansible 文件夹结构在源代码管理系统中进行版本控制，如 Git。Git 是一个分布式的开源版本控制仓库，旨在对开发代码进行版本控制，以提高速度和效率（en.wikipedia.org/wiki/Git）。。)

Ansible 库存

Ansible 库存文件实际上是一个在 YAML 文件中定义的 DNS 主机名或 IP 地址的集合。这允许 Ansible 连接到这些目标主机，并在服务器上执行特定命令。

Ansible 允许用户使用库存文件将服务器分组为特定类型或用例。例如，在网络术语中，当使用 Ansible 设置 Leaf-Spine 架构时，网络操作员可以为 Leaf 交换机创建一个组，为 Spine 交换机创建另一个组。这是因为配置每种交换机所需的运行手册命令不同，因此可以在执行时施加限制，只对特定组中的一小部分服务器执行命令。

以下图片展示了定义 Leaf 和 Spine 交换机的库存文件示例，显示了在库存文件中定义的两个组，一个是为 Leaf 交换机命名的leaf，另一个是为 Spine 交换机命名的spine，包含所有交换机的 DNS 条目：

相同的库存可以用简化的格式描述：

Ansible 模块

Ansible 模块通常是用 Python 编写的，或者也可以用其他编程语言编写。Ansible 模块的代码定义了一组操作，用于向客户操作系统添加或删除功能，或者如果用于编排，它也可以针对 API 执行命令。Ansible 模块可用于封装简单的命令行、API 调用或用户希望程序化编写的任何其他操作。模块是以可复用的方式设置的，以便在多个剧本或角色中使用，从而促进代码重用和操作标准化。

在 Ansible 模块中指定的代码被封装在 Ansible 的模块模板中，模块模板结构化了模块的布局。该模板推动了一组标准，因此每个模块在设计上都是幂等的，这意味着代码会首先检测系统的状态，然后判断是否需要在执行操作之前更改状态。

当 Ansible 执行状态更改时，控制台会以黄色输出标明。如果没有进行任何操作，它将显示绿色，表示操作成功运行，但没有更改状态，而红色的控制台输出则表示模块失败。

Ansible 模块公开了一组命令行参数，这些参数可以是必需的也可以是可选的，并且可以有默认值。遵循 Ansible 标准的模块是通过一个包含 present 或 absent 的状态变量创建的，作为命令行变量之一。当模块设置为present时，它将添加由剧本指定的功能；而当设置为absent时，它将移除指定的功能。所有模块通常都具有处理这两种用例的代码。

一旦编写了 Ansible 模块，它就会被放置在library文件夹中，这意味着它作为库对 Python 解释器可用，代码可以通过在 Ansible 的playbooks或roles中定义来使用。Ansible 提供了一组预打包的核心模块和附加模块，所有这些模块都可以通过编写一些 YAML 来描述所需的操作进行访问，所有模块都附带有文档，文档是模块的样板部分，并且可以在 Ansible 官网上找到。

核心模块由 Ansible 核心团队与软件供应商的联合项目维护，通常具有较高的质量。附加模块也可以具有良好的质量，但不是由供应商维护的，有时是由用户维护的，这些用户将模块提交回 Ansible，以帮助开源社区。

在下面的截图中，可以看到一个简单的核心yum模块，由yum:提供，它带有两个命令行变量name，用于指定要安装的 rpm，以及state，它决定是否在目标服务器上安装或移除该 rpm：

Ansible 角色

角色是 Ansible 中的进一步抽象层，也使用 YAML 文件定义。角色可以从剧本中调用；这旨在尽可能简化剧本。随着playbooks功能集的增加，它们可能变得杂乱且难以维护。如果将所有功能都放在一个文件中，剧本可能会变得很难管理。所以角色允许操作员创建最小化的剧本，然后从 Ansible 目录结构中拉取所有信息，从而决定需要在服务器上执行的配置步骤或本地运行的操作。

Ansible 角色试图剥离剧本中的可重复部分并将其分组，以便在需要时可以由多个剧本使用。角色是为了确定服务器配置文件应该是什么，而不仅仅是专注于多个临时指令，因此剧本可以命名为spine.yml，并且该剧本可以包含一组模块化的角色，用于定义特定 Spine 交换机的运行列表，执行此剧本时，它将在 Ansible 清单中指定的每个目标服务器上构建 Spine 交换机。如果设计得当，这些角色应该具有足够的模块化，以便在创建 Leaf 交换机时重复使用。

Ansible 剧本

Ansible 剧本是一个 YAML 文件，用来指示在 Ansible 清单文件中定义的特定主机集上执行的运行列表。剧本指定了一组有序的指令，从 Ansible 控制节点或在 Ansible 清单文件中指定的目标主机上本地执行命令。

Ansible 剧本可以用来创建一个运行列表，调用模块或特定的角色，指示应该在服务器上执行的操作。

在这个示例中，我们看到一个针对清单文件中spine主机的剧本，并执行多个roles来设置 Spine 服务器：

另一个可行的剧本可能完全不使用角色，直接调用 Ansible 的 yum 核心模块，在名为 server 的清单组上安装 apache 的 httpd-2.2.29 yum 包：

剧本还可以指定 when 条件，以决定是否根据前一个操作的输出执行剧本中的某个操作。register 命令用于存储任务的 JSON 输出，后续任务可以通过读取 JSON 结果并评估 when 条件来验证是否应当执行该任务。

从 2.x 版本开始，Ansible 剧本现在也可以使用块式恢复功能。因此，如果嵌套在块命令中的操作失败，则会触发剧本中的恢复部分。这对于清理失败的操作非常有用，使剧本更加健壮。

不应低估块式恢复操作的有用性，当需要将一个大数据库 dmp 文件复制到备份位置时，由于复制的数据量大，这个操作有时可能容易出错。所以，如果目标目录的磁盘空间太低，那么操作可能在中途失败，导致只有部分文件被复制，且服务器处于不可用状态，服务器也可能耗尽磁盘空间。因此，可以使用恢复命令立即清理复制的文件，这样在复制操作失败时，服务器就不会处于不良状态。恢复命令执行完成后，剧本将退出并报告错误，但保持在原始状态。

在以下示例中，我们可以看到一个剧本使用 copy: 模块将源文件 /var/files/db.dmp 复制到 /backups/db.dmp，如果原始命令失败，file: 模块将用于删除该文件：

执行 Ansible 剧本

在创建了剧本和清单文件，并使用了指定的文件夹结构后，可以通过指定 ansible-playbook 命令来执行它。

在以下示例中：

• ansible-playbook 告诉 Ansible 应该指定一个 YAML 剧本文件

• -i 标志用于指定清单文件

• -l 限制执行仅限于清单组（servers）下的服务器

• -e 在此示例中传递额外的变量到剧本，例如 production

• -v 设置输出的详细程度：

  ansible-playbook –i inventories/inventory –l servers –e environment=production playbooks/devops-for-networking.yml -v
  
  

Ansible var 文件和 jinja2 模板

Ansible 的 var 文件只是另一种 YAML 文件，指定了一组变量，这些变量将在运行时通过 Ansible 的 include_vars 语句被替换到剧本中。

var 文件只是一种方式，用于分离剧本或角色在运行时所需的变量。这意味着可以在运行时传递不同的 var 文件，而无需将变量硬编码到剧本或角色中。

以下截图展示了一个 var 文件语法示例，内容为包含一个名为 cert_name 的定义变量的 common.yml var 文件：

以下示例展示了上面提到的 common.yml 变量和其他 environment.yml 变量，二者都被加载到 playbook 中。{{ environment }} 变量非常有用，因为它意味着可以从 ansible-playbook 命令行传递不同的值，通过在运行时使用 -e “environment=production” 选项来控制导入到 playbook 中的变量：

common.yml 中的 var 文件变量值 cert1 可以通过在 playbook 中指定 {{ cert_name }} 变量来使用：

Ansible 还具有利用 Python jinja2 模板的能力，这些模板可以在运行时进行转换，以使用一组 var 文件填充配置信息；例如，在前面的示例中，{{ environment }} 变量可以在运行时指定，以加载填充唯一环境信息的变量。使用模板模块转换后的 jinja2 模板将被参数化，使用在 environment.yml 文件中指定的变量。

在以下示例中，我们可以看到 Ansible 的 template: 模块作为角色的一部分被执行，复制一个 jinja2 模板 network_template.j2 并将其转换为 /etc/network.conf：

使用 Ansible 配置网络设备的前提条件

本章中 Ansible 入门 部分介绍的基本构建块与 Ansible 网络模块密切相关，并且适用于希望使用 Ansible 进行配置管理的网络团队。在开始之前，重要的是与网络供应商确认所使用的网络操作系统版本是否能够与 Ansible 一起使用。下一步是配置一个小型的预配服务器，将其用作 Ansible 控制主机，通常该服务器会创建在管理网络上，以便它能够适当地访问所有交换机。

配置服务器可以相对较小，因为它只需要通过 SSH 连接到基于 Linux 的网络操作系统。确保在网络设备上启用了 API 命令行。创建一个临时用户帐户在每个网络设备上也是一个好主意，这将允许你在 Ansible 控制主机上设置公钥，并使用临时帐户将创建的 id_rsa.pub 通过 安全复制 (SCP) 复制到网络设备上的 authorized_keys 文件夹。这将允许 Ansible 使用该私钥连接到所有主机，而无需处理密码。完成此设置活动后，可以从每个网络设备中删除临时密码，甚至可以使用 Ansible 作为第一步活动来完成此操作。

如果一切顺利，下一步将在配置服务器上创建 Ansible 文件夹结构，并填写 Ansible 清单文件，其中包含所有网络设备的 DNS 名称，最后安装 Ansible，当你准备开始执行 playbook 时即可使用。Ansible 现在由 Red Hat 以 rpm 格式打包，因此只要 Ansible 控制主机能够通过 CentOS 镜像或 Red Hat 企业 Linux 访问 Red Hat 仓库，就可以通过简单的 yum install 来安装 Ansible。当然，Ansible 也能在任何基于 Linux 的操作系统上运行，因为它仍然可以作为 PyPi 包在 Ubuntu 上安装。

Ansible Galaxy

如果网络操作员寻找起点而且不擅长编码，他们可以在 Ansible Galaxy 上查找示例，Ansible Galaxy 托管了由开源社区开发的角色，这些角色执行了许多复杂的命令。

网络工程师可以导航到 Ansible Galaxy 仓库：galaxy.ansible.com/。

Ansible Galaxy 拥有成千上万的 Ansible 角色，这些角色由开源社区开发。

一些可用的网络角色示例包括 Arista EOS 角色，它可以用于自动化 Arista 交换机设备。或者，Cisco EVPN VXLAN Spine 角色可以用于在 Cisco 设备上构建 Spine 交换机，或者 Juniper Junos 角色可以用于自动化 Juniper 网络设备。因此，针对各种技术和用例，提供了广泛的模块选择。

请查看以下有用的链接：

• Arista EOS (galaxy.ansible.com/arista/eos-system/)

• Cisco (galaxy.ansible.com/rogerscuall/evpn_vxlan-spine/)

• Juniper (galaxy.ansible.com/Juniper/junos/)

用户可以浏览角色并搜索特定的网络厂商。在这个示例中，搜索 Arista 返回了 eos 角色，如下图所示：

每个返回的角色都有一个指向其对应 GitHub 仓库的链接：

Ansible Galaxy 是一个非常有用的工具，用户可以以角色（roles）作为起点，并根据自己的需求进行自定义。而不仅仅是从社区获取，任何可能对其他人有用的新角色都应该回馈到 Ansible 社区。

Ansible 核心模块可用于网络操作

自 Ansible 2.0 发布以来，Ansible 配置管理工具已经打包了来自 Arista、Citrix、Cumulus 和 Juniper 的一些核心网络模块。Ansible 可以用于编辑任何网络设备的配置，而不仅仅限于这些模块。Ansible Galaxy 拥有由开源社区开发的各种角色。

以下截图展示了 Ansible 2.x 网络模块的一个子集，重点展示了 Junos（Juniper）、Eos（Arista）、Nxos（Cisco）和 Ios（Cisco）：

Ansible 2.x 旨在通过为所有模块提供一组标准化的操作，简化网络模块的使用，使网络工程师感觉更加直观。由于许多网络工程师不熟悉配置管理工具，模块间的标准化简化了初次使用的门槛。当网络工程师看到他们日常使用的命令作为 playbook 或角色的一部分时，Ansible 可以首先作为调度工具使用，然后再深入使用更复杂的模块。

网络工程师在初次使用配置管理工具时的主要担忧之一是不信任系统或不了解其背后的运作方式。因此，能够轻松阅读 playbook 或角色，并查看正在执行的操作，有助于建立对工具的信心，并使其更容易被接受。

完全可以预见，随着时间的推移，开源社区将构建出更复杂的网络模块，其中一些已经通过 Ansible Galaxy 中的角色提供，例如来自 Arista、Juniper 和 Cisco 的角色。然而，以下 Ansible 核心模块已经标准化，允许以相同的方式配置 Arista、Cisco 和 Juniper 网络设备。这些模块可以在任何 playbook 或角色中使用。

_command 模块

在 Ansible 2.x 中，主要与供应商的网络模块一起打包的模块是_command模块。这是 Ansible 的有意选择，因为网络工程师在初次使用配置管理工具时，使用原生网络命令更加直观。

该模块允许 Ansible 使用 SSH 连接到主机，因为网络设备的操作系统主要是基于 Linux 的操作系统。

_command 模块允许网络操作员通过从 Ansible 控制主机连接应用配置更改。Ansible 在此命令中使用的语法与网络操作员在网络设备上使用 CLI 执行的语法相同。

在下面的示例中，EOS 命令 show ip bgp summary 由 eos_command 执行，它连接到每个指定的 {{ inventory_hostname }}，这是一个特殊的 Ansible 变量，会替换为清单文件中指定的主机组中每个节点的 DNS 名称。然后，它将命令的输出注册到 eos_command_output 变量中。

Junos 语法是相同的。在下面的示例中，执行了一个类似的网络命令，在 Junos 上显示接口，并将 JSON 输出捕获到 junos_command_output 变量中。

Cisco 示例显示的是 Nxos，但配置在 IOS 中也是相同的。nxos_command 命令执行 show version 命令，并将结果放入 nxos_command_output 变量中：

The _config module

_config 模块用于以确定性方式配置更新，可用于实现变更请求，通过批量执行多个命令。

此模块允许操作员以编程方式更新网络设备上的运行配置中的选定行或块。该模块将连接到设备，提取运行配置，然后以完全可预测的方式推送批量更新。

在下面的示例中，Arista 交换机的配置将通过该模块加载。如果运行配置与现有状态不匹配，no spanning-tree vlan 4094 命令将在 EOS 操作系统上执行，从而在交换机上实现所需的最终状态。

The _template module

_template 模块用于利用 jinja2 模板文件更新配置。可以从网络设备的运行配置中提取该模板，进行更新，然后再推送回设备。

_template 模块的另一个使用场景是，允许网络管理员从一个网络设备中提取运行配置到 jinja2 模板，然后将其应用于其他交换机，以传播相同的更改。

_template 模块只会推送增量更改，除非指定强制命令作为命令行变量，这将执行覆盖操作。

在下面的示例中，eos_config jinja2 模板被推送到 Arista 设备上，并且如果 jinja2 模板中有配置变更，它会对配置进行增量更新。

配置管理流程，用于管理网络设备

DevOps 主要关注的是人和流程，因此，仅仅专注于一些单独的 playbook 或角色示例来操作交换机或防火墙，并不能帮助网络工程师解决他们每天遇到的现实网络挑战。在明确项目的实际目标后，选择正确的工具来促进流程也很重要。工具的选择应在业务需求明确之后，而不是反过来。

网络工程师可以像输入命令到 Ansible playbook 一样，轻松地将这些命令输入到网络操作系统中，因此，重要的是要考虑使用像 Ansible 这样的配置管理工具能为业务带来哪些真正的价值。

单独实现一个新工具并不能真正帮助网络团队提升效率，但在 Ansible 中创建的用于管理 Arista、Juniper 和 Cisco 的模块，是简化和标准化流程与方法的促进工具。然而，真正的关键区别在于将这些模块包裹和利用起来的流程。

Ansible 可以以多种方式帮助网络操作，但最好尝试将任务归类为以下几类：

• 期望状态

• 变更请求

• 自助服务操作

期望状态

第一天的 playbook 应该用于设置网络的期望状态，利用一组角色和模块来构建全新的网络设备，并控制网络的预期状态。一个第一天的 playbook 示例可能是网络工程师第一次配置使用 Arista Leaf 和 Spine 交换机的 Leaf-Spine 架构，刚开始时这可能看起来是个相当复杂的任务。但其中的优点是，整个底层网络的状态可以在 Ansible 中进行描述，同样的道理也适用于防火墙或任何其他设备。

在 Leaf-Spine 网络中，活动将包括配置多个 Leaf 和 Spine 交换机，因此，创建一组角色来抽象常见操作，并在 playbook 中调用它们是可取的，因为相同的配置将需要在多个服务器上执行。

网络工程师将从设置 Ansible 控制主机开始，如 Ansible 先决条件部分所述。接着，他们将创建自己的清单文件，用于配置 Leaf-Spine 架构中的网络设备。

网络工程师应定义他们计划配置的所有网络设备的清单。在以下示例中，我们看到两个主机组，包含两个 spine 交换机和四个 leaf 交换机：

网络操作员还需要指定他们希望在 spine.yml playbook 中执行的角色，如以下屏幕截图所示，首先使用期望的配置构建 Spine 交换机。

在以下的操作手册示例中，我们看到该操作手册针对 Spine 主机组，并对服务器执行 common、interfaces、bridging、ipv4 和 bgp 角色：

执行的角色执行以下配置：

• 通用角色：此角色用于配置 Spine 上的 IP 路由表。

• 接口角色：此角色用于配置 Spine 上的接口。

• 桥接角色：此角色用于配置 Spine 上的所有必要 VLAN 和交换端口。

• ipv4 角色：此角色用于配置 Spine 的 IP 接口。

• bgp 角色：此角色用于配置 BGP 协议，使交换机能够相互连接。

所有这些可重用的角色将用于配置 Arista Spine 交换机，并大量使用 eos_command 模块。

类似地，许多相同的模块可以用于在 leaf.yml 操作手册中配置 Leaf 交换机，该操作手册针对库存中的 Leaf 主机组，并执行 common、interfaces、bridging、ipv4、bgp、ecmp 和 mlag 角色，如下图所示：

执行的角色用于执行以下配置：

• 通用角色：此角色用于配置 Spine 上的 IP 路由表。

• 接口角色：此角色用于配置 Spine 上的接口。

• 桥接角色：此角色用于配置 Spine 上的所有必要 VLAN 和交换端口。

• ipv4 角色：此角色用于配置 Spine 的 IP 接口。

• bgp：此角色用于配置 BGP 协议，使交换机能够相互连接。

• ecmp：此角色用于确保在 Leaf-Spine 拓扑中配置了等成本多路径。

• mlag：此角色用于通过 mlag 在机架顶部配置交换机的冗余。

这表明，如果角色保持足够精细，角色可以被重用，var 文件提供必要的配置更改给角色，因此避免任何硬编码值是非常重要的。

Leaf-Spine 架构是一个从第一天开始的操作手册，但为什么网络工程师要花费大量时间设置这个架构，而它只会使用一次呢？当然，这是一种常见的误解，因为操作手册和角色描述了整个网络的期望状态，一旦初步的角色被写好，之后它们可以在任何时候用来修改网络的期望状态。

Ansible 操作手册和角色还可以以相同的方式用于构建第二个数据中心，作为灾难恢复解决方案，帮助在数据中心重新配置 IP 时修改状态，或者在数据中心扩展更多的 Spine 和 Leaf 交换机。

以最后一个例子为例，在扩展数据中心方面，这就像是向 Ansible 清单中添加更多 Spine 或 Leaf 交换机一样简单。一旦附加的 Arista 交换机在数据中心运维团队完成机架和布线后被零接触配置。

网络操作员然后只需要对var文件做小幅更新，以指定需要使用的 VLAN，并更新清单。

在下面的示例中，通过修改清单文件，基础设施扩展到 15 个 Spine 交换机和 44 个 Leaf 交换机：

尽管这是一个相当极端的扩展示例，但它应该突显投资于自动化的意义和好处。因为这样的扩展会让网络工程师花费数周的时间，而一旦初始角色搭建完成，Ansible 可以在几分钟内执行相同的操作。

这真的是值得投资的，这也意味着交换机的建设方式与其他交换机一致，从而减少了人工错误，并使网络变更的交付更加精确。有些人认为自动化是关于速度的，但在网络领域，它应该真正关注一致性。

相同的spine.yml和leaf.yml剧本也可以在扩展过程中对现有交换机执行，因为 Ansible 本质上是幂等的，意味着只有在配置发生变化时，状态变更才会被推送到交换机。如果角色不是幂等的，那么被调用的模块就是问题所在。

这种幂等性意味着相同的第一天剧本（site.yml）调用spine.yml和leaf.yml，可以在现有交换机上运行，不会改变任何配置，并且可以在不单独指定变化交换机的情况下重复使用。需要注意的是，所有 Ansible 变更在投入生产前应先在测试环境中进行测试。

变更请求

尽管有了自动化，网络工程师仍然需要一个单独的手动变更请求流程，对吧？简单的答案是否定的，手动变更会破坏在第一天的剧本中描述的期望状态。今后的所有网络变更都应该通过相同的配置机制进行推动；不应该存在单独的工作流或临时命令。

在流程外进行变更只会破坏用于维护期望状态的 Ansible 剧本和角色，从而破坏自动化。需要注意的是，利用网络自动化是一种全或无的方法，必须由所有团队成员采纳，且不能在流程外进行任何更改，否则会破坏可重复性和可靠性变更的模型。如果功能缺失，第一天的剧本应该扩展以纳入这些变更。

自助服务操作

使用 Ansible 进行网络操作时，典型的瓶颈之一是网络工程师不愿意让开发团队自己进行网络变更，因此这为网络团队带来了瓶颈，因为通常公司里开发人员的数量多于网络工程师。

这种不情愿是因为网络变更传统上较为复杂，而开发人员的专长是开发代码和创建应用程序，而不是登录到网络设备上为他们的应用程序进行防火墙配置更改。

然而，如果网络工程师创建了一个自助服务剧本，定义了一组安全的工作流操作，那么开发人员可以使用它以安全的方式与网络设备进行交互，这就打开了一个全新的机会，去消除瓶颈。

这使得网络工程师处于主题专家(SME)角色，通过架构设计和运用他们的网络经验来创建体现网络最佳实践的网络自动化，以服务开发团队的需求。

这意味着网络工程师不再执行手动操作，如在开发人员提交工单时手动打开防火墙端口。当然，这是一种角色变化，但自动化的方法正是行业发展的方向。

以防火墙请求为例，开发团队创建了一个新的应用程序，并需要一个测试环境来部署它。在配置测试环境时，它需要网络，网络工程师会询问开发人员需要在防火墙中打开哪些端口。

开发人员暂时不知道如何回答这个问题，因为他们还没有完成应用程序的最终版本，并希望在测试环境中逐步开发它。因此，每当需要打开新端口时，就意味着需要一个新的网络工单来打开开发团队发现的增量端口。这不是网络工程师或开发人员时间的最佳使用方式，因为这会导致双方的不满。网络工程师的时间应该更好地用于优化网络或增加改进的警报，而不是处理工单来打开防火墙端口。

相反，可以使用 Ansible 创建一个自助服务文件。开发人员可以创建一个 jinja2 模板，并将其提交到源代码管理中，列出用于通过 template: 模块进行防火墙变更的配置文件。该模板展示了现有的防火墙条目，并可供开发人员添加新的条目并提交拉取请求，以便在防火墙上打开端口。

网络工程师随后审查变更并批准或拒绝它。经过批准后，Ansible 可以自动触发，将变更推送到测试环境；这确保了配置的有效性。

在以下示例中，我们看到的是一个剧本，它用更新后的 jinja2 firewall.j2 模板替换了 firewall.config 文件，然后从新的模板中重新加载防火墙配置：

这使得网络团队能够启用自助服务模型。这加快了网络变更的速度。它还消除了网络团队作为瓶颈的角色，并推动他们为网络变更创建适当的测试和控制。

自助服务并不意味着网络工程师不再需要。这意味着他们成为流程的守门人，而不再是每天应对接连不断的临时请求。

总结

在本章中，我们探讨了如何使用 Ansible 进行网络设备的服务器端配置管理，并查看了一些行业领先的网络厂商，如 Arista、Cisco 和 Juniper，这些厂商已经改变了他们的运营模式，采用了适合自动化的开放标准和协议。

阅读本章后，您应该已经熟悉来自 Cisco、Juniper 和 Arista 的网络操作系统。了解了 Ansible 配置管理工具及其概念，如 Ansible Inventory、Ansible Modules、Ansible Playbooks、Ansible Roles、Ansible 变量文件和 Jinja2 模板。读者还应熟悉 Ansible Galaxy，这是用于网络自动化的核心 Ansible 模块，以及通过 Ansible 管理网络设备的方法。

本章让读者了解了可以使用像 Ansible 这样的工具来自动化网络工程师日常执行的网络操作的用例。同时，它也应当让读者了解到如何通过利用配置管理工具来改进网络自动化。

本章的主要收获是，像 Ansible 这样的配置管理工具现在本地支持网络操作，并且像 Cisco、Juniper 和 Arista 等厂商已经创建了模块来促进网络操作的自动化。现在没有理由不开始自动化网络操作，因为这些方法得到了领先网络厂商的完全支持，他们明白 SDN 操作是网络操作的未来。

我们已经见证了 Ansible 是一个非常灵活的工具。它的主要优点之一是能够编排 API 并帮助安排软件发布。负载均衡应用程序是软件开发发布过程中的一个基础组成部分，因此在下一章中，我们将探讨能够帮助编排负载均衡器的配置管理原则，帮助网络团队轻松维护复杂的负载均衡解决方案。

注意

Ansible 网络自动化的有用链接：

www.youtube.com/watch?v=7FphWEFQbac

www.youtube.com/watch?v=VYEVjKvMKqU

Cisco 的有用链接：

pynet.twb-tech.com/blog/automation/cisco-ios.html

www.cisco.com/c/en/us/support/switches/nexus-7000-series-switches/products-command-reference-list.html

Juniper 的有用链接：

www.juniper.net/documentation/en_US/junos15.1/topics/concept/junos-script-automation-overview.html

www.juniper.net/techpubs/software/junos-security/junos-security10.4/junos-security-cli-reference/junos-security-cli-reference.pdf

Arista 的有用链接：

www.arista.com/en/products/eos/automation

www.arista.com/docs/Manuals/ConfigGuide.pdf

第五章：使用 Ansible 编排负载均衡器

本章将重点介绍一些当今流行的负载均衡解决方案，以及它们在负载均衡应用程序方面的策略。

随着云解决方案的出现，如 AWS、Microsoft Azure、Google Cloud 和 OpenStack，我们将探讨这些技术对负载均衡的影响，特别是分布式负载和集中式负载均衡策略。本章将展示可用于通过 Ansible 编排负载均衡器的实际配置管理过程，以帮助自动化应用程序的负载均衡需求。

本章将涵盖以下主题：

• 集中式和分布式负载均衡器

• 流行的负载均衡解决方案

• 负载均衡不可变和静态服务器

• 使用 Ansible 编排负载均衡器

集中式和分布式负载均衡器

随着微服务架构的引入，允许开发团队更频繁地对生产环境中的应用程序进行更改，开发者不再仅仅需要按季度发布软件。

随着持续交付（Continuous Delivery）和 DevOps 的推进，应用程序现在每周、每天，甚至每小时都会发布，且通常只更新和发布其中一个或部分微服务。

组织发现微服务架构更易于管理，因此逐渐摒弃了构建单体应用程序的方式。微服务应用程序将较大的应用程序拆分成更小的、可管理的模块。这使得应用程序功能可以更频繁地发布给客户，因为业务在每次发布时不需要重新部署整个产品。这意味着只需重新部署一个小的微服务即可发布一个新功能。由于发布过程更为频繁且持续进行，因此它更容易被理解，通常是完全自动化的，并最终得到负载均衡。

微服务架构对于跨多个办公室或国家的庞大企业也有益处，因为不同的团队可以拥有不同的微服务，并独立发布它们。

这当然意味着开发团队需要一种方式来测试依赖管理，并且要确保充分测试，以保证微服务在发布时不会破坏其他微服务。

结果是，开发者需要创建模拟和存根服务，以便在不部署完整生产环境的情况下有效测试微服务应用程序对多个软件版本的兼容性。

创建微服务架构是企业的一大思维转变，但这是保持竞争力的必要措施。发布单体应用程序通常对企业来说既困难又耗时，而采用季度发布周期的企业最终会被能够以更快、更精细的方式发布功能的竞争对手超越。

微服务架构的使用意味着，由于环境的动态性，能够在测试环境中使用与生产环境相同的负载均衡变得更加重要。

因此，测试环境的负载均衡配置必须尽可能接近生产环境。可以使用配置管理工具来控制负载均衡器的期望状态。

责任的委托也需要审查，以支持微服务架构，因此，部分负载均衡配置的控制应移交给开发团队，而不是向网络团队提出请求，这样既能使其易于管理，又不妨碍开发团队。这当然是一种文化变革，需要高级管理层的支持，以推动操作模型的必要变革。

使用微服务应用时，负载均衡的要求将随着应用程序的开发或规模的扩大而演变，因此，重要的是这些方面要提供给开发人员进行自助请求，而不是等待集中式网络团队来进行负载均衡的更改。

由于向微服务架构的转变，网络和负载均衡的领域也需要不断发展，以支持这些需求，许多供应商创建了 PaaS 解决方案来处理跨混合云的应用程序部署和负载均衡。

现成的 PaaS 解决方案是对于那些可能不太懂技术且无法使用配置管理工具（如 Chef、Puppet、Ansible、Salt 等）创建自己部署管道的公司来说的一个不错选择，帮助他们将应用程序部署到云环境中。

无论是采用哪种部署方式，自建还是现成的 PaaS 解决方案。在考虑公有云、私有云和混合云时，微服务和单体应用仍然需要得到支持。

因此，网络和负载均衡需要具备适应性，以支持不同的工作负载。虽然组织的最终目标是实现微服务架构，但大多数公司现实中必须采用混合方式，兼顾集中式和分布式负载均衡方法，以支持单体应用和云原生微服务。

集中式负载均衡

传统上，负载均衡器作为外部物理设备安装，设计非常复杂，并且使用非常昂贵的设备。负载均衡器会配置为为 Web 内容提供服务，并在昂贵的物理设备上终止 SSL 请求。

负载均衡器将有复杂的配置来通过上下文切换将请求路由到应用程序，且请求会直接传递给静态后端服务器。

这对单体配置来说是最优的，因为应用程序通常是自包含的，并且遵循三层模型：

• 前端 Web 服务器

• 业务逻辑层

• 数据库层

这并不需要大量的东西向流量，因为流量是南北向的，穿越了前端、业务逻辑和数据库。网络设计的目的是最小化处理请求并将其返回给最终用户所需的时间，并且每次都由核心网络提供服务。

分布式负载均衡

随着微服务架构的发展，应用程序的运行方式发生了一定变化。应用程序不再是自包含的，而是需要与同一租户网络内或跨多个租户的依赖微服务应用程序进行通信。

这意味着数据中心内的东西向流量大大增加，并且数据中心中的流量不再像以前那样始终通过核心网络。

微服务应用程序的集群被实例化并在租户网络内进行负载均衡，使用 x86 软件负载均衡解决方案，微服务集群的虚拟 IP（VIP）暴露给需要使用它的相邻微服务。

随着虚拟机、容器和软件定义覆盖网络的日益普及，这意味着软件负载均衡解决方案现在被用来在租户网络内部对应用程序进行负载均衡，而不再需要回到集中式的负载均衡解决方案。

因此，负载均衡供应商不得不适应并生产虚拟化或容器化版本的物理设备，以与开源软件负载均衡解决方案竞争，而这些解决方案通常与微服务一起使用。

常见的负载均衡解决方案

随着应用程序从单体架构转向微服务架构，负载均衡的需求无疑发生了变化。今天，我们看到有向开源负载均衡解决方案的转变，这些解决方案与虚拟机和容器紧密集成，用于在 AWS 中的 VPC 之间或 OpenStack 中的租户网络之间提供东西向流量，而不是依赖于集中式物理设备。

现在，开源负载均衡解决方案已经由Nginx和HAProxy提供，帮助开发人员对他们的应用程序进行负载均衡，或使用 AWS 的弹性负载均衡功能：

aws.amazon.com/elasticloadbalancing/

几年前，Citrix NetScalers（www.citrix.com/products/netscaler-adc/）和 F5 Big-IP（f5.com/products/big-ip）解决方案在企业负载均衡领域拥有垄断地位，但随着众多新解决方案的出现，负载均衡领域发生了显著变化。

新兴的负载均衡初创公司，如 Avi Networks （avinetworks.com/），专注于 x86 计算和软件解决方案，以提供负载均衡解决方案，这些解决方案旨在支持现代微服务应用程序和单体应用程序，支持分布式和集中式负载均衡策略。

本书的目的是讨论哪种负载均衡供应商解决方案最好；没有一刀切的解决方案，选择的负载均衡解决方案将取决于组织所需的流量模式、性能和可移植性。

本书不会深入探讨性能指标；它的目标是探讨当前各供应商提供的不同负载均衡策略以及可以用来完全自动化和编排负载均衡器的配置管理方法，这将帮助网络团队实现负载均衡网络操作的自动化。

Citrix NetScaler

Citrix NetScaler 提供一系列产品来满足组织的负载均衡需求。Citrix 提供多种不同的产品供最终用户使用，如 MPX、SDX、VPX，以及最近推出的 CPX 设备，每种产品的许可证费用根据其支持的吞吐量提供灵活的定价。

MPX 和 SDX 是 NetScaler 的硬件设备，而 VPX 是虚拟化的 NetScaler，CPX 是容器化的 NetScaler。

所有这些产品根据所购买的许可证支持不同的吞吐量（www.citrix.com/products/netscaler-adc/platforms.html）。

Citrix NetScaler 系列产品共享相同的 API 和代码集，因此软件完全一致。NetScaler 提供 REST API 以及 Python、Java 和 C# Nitro SDK，暴露所有可以在 GUI 中进行操作的 NetScaler 功能。所有 NetScaler 产品允许以编程方式控制需要设置的 NetScaler 对象和实体，以控制 MPX、SDX、VPX 或 CPX 上的负载均衡或路由。

NetScaler MPX 设备是一个集中式的物理负载均衡设备，用于处理大量的每秒事务数（TPS）；MPX 具有众多安全特性，并且符合有害物质限制（RoHS）和联邦信息处理标准（FIPS），因此该解决方案可以被需要遵守特定监管标准的高监管行业所使用。

MPX 通常用于进行 SSL 卸载；它支持大量的 SSL 吞吐量，这对于需要高性能的应用程序非常有用，因此 SSL 卸载可以在硬件设备上完成。

MPX 可以通过第 4 层负载均衡和第 7 层上下文切换将流量引导到不同的租户网络，或者将流量引导到第二层负载均衡级别。

NetScaler SDX 设备也是一种集中式物理设备，用于处理高 TPS（每秒事务数）。SDX 允许多个 VPX 设备作为 HA 对在 SDX 上设置并部署，从而提高吞吐量和可靠性。

NetScaler 还支持 全局服务器负载均衡（GSLB），它允许在多个 VPX HA 对之间分配负载，采用扩展模型，并利用 CNAME 将流量引导到多个 HA 对：

VPX 可以安装在任何 x86 虚拟化平台上并作为虚拟机设备使用，此外还推出了新的 CPX，它将 NetScaler 放入 Docker 容器中，因此可以在租户网络内部署，而不是在集中式模型中设置。所有设备都允许分配和使用 SSL 证书。

每个 NetScaler 设备，无论是 MPX、SDX、VPX 还是 CPX，都采用相同的 IP 对象模型和代码，其中定义了以下显著的实体来执行应用负载均衡：

• 服务器：NetScaler 上的服务器实体将虚拟机或裸机服务器的 IP 地址绑定到服务器实体。这意味着一旦绑定到其他 NetScaler 实体，该 IP 地址就成为负载均衡的候选者。

• 监控器：NetScaler 上的监控器实体附加到服务或服务组，并提供用于监控附加服务器实体健康状况的健康检查。如果健康检查结果不正常（例如简单的网页 ping），则服务或服务组将被标记为不可用，NetScaler 将不会将流量引导到该服务。

• 服务组：服务组是 NetScaler 实体，用于将一个或多个服务器绑定到 lbvserver 实体；服务组可以与一个或多个监控器关联，以对关联的服务器进行健康检查。

• 服务：服务实体用于将一个服务器实体和一个或多个监控健康检查绑定到 lbvserver 实体，该实体指定用于检查服务器的协议和端口。

• lbvserver：lbvserver 实体确定负载均衡策略，如轮询或最少连接，并与服务组实体或多个服务实体连接，暴露一个虚拟 IP 地址，供终端用户访问 Web 应用程序或 Web 服务端点。

• gslbvserver：当需要在 NetScaler 设备之间进行 DNS 负载均衡时，使用 gslbvserver 实体来指定 gslb 域名和 TTL。

• csvserver：csvserver 实体用于提供从 gslbvserver 域或 lbvserver IP 地址到其他 lbvservers 的第七层上下文切换。这用于通过 NetScaler 设备路由流量。

• gslbservice: gslbvservice 实体将 gslbvserver 域绑定到一个或多个 gslbservers 实体，从而在 NetScaler 设备之间分配流量。

• gslbserver: gslbserver 实体是启用了 gslb 的 NetScaler 设备的 IP 地址。

通过利用服务器、监视器、服务组/服务和 lbvserver 的组合，可以实现简单的负载均衡。通过 gslbvserver 和 csvserver，上下文切换允许复杂路由和弹性要求。

F5 Big-IP

F5 Big-IP 套件基于 F5 自有的定制 TMOS 实时操作系统，该操作系统是自包含的并运行在 Linux 上。TMOS 包含一系列操作系统和固件，所有这些都运行在 BIG-IP 硬件设备或 BIG-IP 虚拟实例中。BIG-IP 和 TMOS（甚至 TMM）可以根据使用案例互换使用。

TMOS 是每个 F5 设备的核心，允许流量检查。它根据流量类型做出转发决策，功能类似防火墙，只允许预定义的协议通过 F5 系统。

TMOS 还具有 iRules，它是使用 F5 自有的 工具命令语言（TCL）编写的程序化脚本，使用户能够创建由特定事件触发的独特功能。这可以用于内容交换流量或重新排序 HTTP cookies；TCL 完全可扩展和可编程，能够执行众多操作。

F5 Big-IP 解决方案主要是硬件负载均衡解决方案，提供多种物理硬件设备，客户可以根据其吞吐量要求购买，硬件设备可以集群在一起以实现冗余。

F5 Big-IP 套件提供了多种产品，提供负载均衡、流量管理，甚至防火墙服务。

F5 Big-IP 套件提供的主要负载均衡服务如下：

• Big-IP DNS: F5 的全球负载均衡解决方案。

• Local traffic manager: F5 Big-IP 套件的主要负载均衡产品。

F5 Big-IP 解决方案与 Citrix NetScaler 类似，采用对象模型允许负载均衡被程序化定义和虚拟化。F5 允许将 SSL 证书与实体关联。

以下本地流量管理器对象实体允许 F5 Big-IP 进行应用负载均衡：

• Pool members: 池成员实体映射到虚拟或物理服务器的 IP 地址，并且可以绑定到一个或多个池。池成员可以关联健康监视器。

• Monitor: 监视器实体返回特定池成员的状态，并充当健康检查功能。

• Pool: 池实体是一个逻辑分组，包含已关联的池成员集；池也可以与健康监视器以及 服务质量（QoS）相关联。

• 虚拟服务器：虚拟服务器实体与一个或多个池关联，虚拟服务器决定负载均衡策略，例如轮询或最少连接。F5 解决方案也提供基于容量或最快连接的负载均衡解决方案。利用 iRules 的第七层配置文件可以针对虚拟服务器进行配置，并用于暴露 IP 地址以访问池成员。

• iRules：iRules 使用编程语言 TCL，用户可以基于事件（如切换到不同池）编写特定的负载均衡规则。

• 速率类别：速率类别实现了速率整形，用于控制特定负载均衡操作的带宽消耗，以限制吞吐量。

• 流量类别：流量类别实体用于根据特定事件调节流量流向。

Avi Networks

Avi Networks 是一家相对较新的初创公司，但他们拥有一款非常有趣的负载均衡产品，真正体现了软件定义的理念。这是一款企业级软件负载均衡解决方案，包含可以部署在 x86 计算平台上的 Avi Controller。Avi 是一种纯软件解决方案，将分布式 Avi 服务引擎部署到租户网络中，并与 AWS VPC 及 OpenStack 租户进行集成：

Avi Networks 解决方案提供自动化的负载均衡服务配置功能，支持在 x86 虚拟化平台上进行自动扩展，根据用户配置的利用率规则，灵活地根据负载均衡需求进行扩展。

Avi Networks 解决方案支持多个或隔离的租户，并且拥有一个实时应用监控和分析引擎，可以定位网络中延迟的发生位置及数据包的路由来源地。

Avi 还支持丰富的图形界面，显示负载均衡实体，用户可以直观地查看负载均衡情况，同时还支持抗 DDoS 防护。

所有通过 GUI 或 API 发出的命令都使用相同的 REST API 调用。Avi Networks 解决方案支持 Python 和 REST API。Net Networks 对象模型有许多实体，类似于 NetScalers 和 F5，能够定义负载均衡。

• 健康监测配置文件：健康监测池配置文件实体指定池服务器的健康检查，使用健康属性进行监控。

• 池：池实体指定虚拟或物理服务器的 IP 地址，以服务器列表的形式呈现，并具有关联的健康监测配置文件；如果池出现故障，还可以通过数据脚本指定事件。一个或多个池与虚拟服务实体绑定。

• 自定义策略：自定义策略允许用户以编程方式指定虚拟服务的策略。

• 应用配置文件：应用配置文件实体允许将每个应用程序建模，并为其指定相关的 HTTP 属性、安全性、DDoS、缓存、压缩和 PKI 属性，这些都作为与虚拟服务关联的应用配置文件的一部分。

• 分析配置文件：分析配置文件利用 Avi 分析引擎，捕获威胁、指标、健康评分、延迟阈值以及失败代码，这些都映射到虚拟服务实体。

• TCP/UDP 配置文件：TCP/UDP 配置文件管理是否使用 TCP 或 UDP，并设置任何 DDoS L3/L4 配置文件。

• SSL 配置文件：SSL 实体管理虚拟服务实体将使用的 SSL 密码套件。

• PKI 配置文件：PKI 配置文件实体绑定到虚拟服务实体，并指定虚拟服务的证书颁发机构。

• 策略集：策略集实体允许用户设置安全团队为每个虚拟服务设置针对请求和响应的策略。

• 虚拟服务：虚拟服务实体是负载均衡服务器池的入口点 IP 地址，并与所有配置文件关联，用于定义应用池的负载均衡，同时绑定到 TCP/UDP、应用、SSL、SSL 证书、策略和分析配置文件。

Nginx

Nginx (www.nginx.com/) 支持商业版和开源版。它是一个基于 x86 的软件负载均衡解决方案。Nginx 可以作为 HTTP 和 TCP 负载均衡器使用，支持 HTTP、TCP，甚至 UDP，还可以支持 SSL/TLS 终结。

Nginx 可以通过使用 keepalived 设置冗余模式，以便在一个 Nginx 负载均衡器发生故障时，能够无缝切换到备份服务器，并且零停机时间。

Nginx Plus 是商业版，功能比开源版更完整，支持主动健康检查、会话持久性和缓存等功能。

Nginx 的负载均衡是通过在 nginx.conf 文件中声明语法来设置的。其工作原理是简化负载均衡配置。与 NetScalers、F5 和 Avi Networks 不同，它不使用对象模型来定义负载均衡规则，而是通过声明式语法将负载均衡的虚拟或物理机器描述为后端服务器。

在以下简单示例中，我们看到三台服务器，10.20.1.2、10.20.1.3 和 10.20.1.4，所有的负载均衡都使用 Nginx 声明式语法在端口 80 上进行，并且它通过 http://www.devopsfornetworking.com/devops_for_networking 提供服务：

默认情况下，Nginx 会使用轮询负载均衡方法来负载均衡服务器，但它也支持其他负载均衡方法。

Nginx 的 least_conn 负载均衡方法会将请求转发到当前连接数最少的后端服务器，而 Nginx 的 ip_hash 负载均衡方法则意味着用户可以将相同的源地址绑定到同一目标后端服务器，以便整个请求过程中保持一致。

这对于某些应用程序非常有用，它们要求所有请求在事务处理过程中绑定到同一服务器上，即使用粘性会话。

然而，专有版本的 Nginx Plus 支持一种额外的负载均衡方法，名为 least_time，该方法基于后端服务器的活动连接数计算最低延迟，并根据这些计算结果适当地转发请求。

Nginx 负载均衡器在进行负载均衡时始终使用权重系统；默认情况下，所有服务器的权重为 1。如果服务器的权重设置为 1 以外的值，除非后端的其他服务器无法处理请求，否则该服务器不会接收请求。此功能在对后端服务器进行流量限制时非常有用。

在以下示例中，我们可以看到后端服务器配置了最少连接数的负载均衡方法。服务器 10.20.1.3 的权重为 5，这意味着只有当 10.20.1.2 和 10.20.1.4 达到最大负载时，才会将请求发送到 10.20.1.3 后端服务器：

默认情况下，Nginx 使用轮询负载均衡时，不会停止向未响应的服务器转发请求，因此需要利用 max_fails 和 fail_timeouts 进行处理。

在以下示例中，我们可以看到服务器 10.20.1.2 和 10.20.1.4 的 max_fail 计数为 2，并且 fail_timeout 为 1 秒；如果超过这个值，Nginx 将停止将流量引导到这些服务器：

HAProxy

HAProxy (www.haproxy.org/) 是一款开源的 x86 软件负载均衡器，具有会话感知功能，并可以提供 4 层负载均衡。HAProxy 负载均衡器还可以根据请求的内容进行 7 层上下文切换，并支持 SSL/TLS 终止。

HAProxy 主要用于 HTTP 负载均衡，并可以通过使用 keepalived 配置和两台 Apache 配置以冗余方式进行设置，这样如果主服务器出现故障，备份服务器将成为主服务器，以确保终端用户服务不中断。

HAProxy 使用声明式配置文件来支持负载均衡，而不是采用专有负载均衡解决方案（如 NetScaler、F5 和 Avi Networks）所采用的对象模型。

HAProxy 配置文件包含以下声明式配置部分，以允许设置负载均衡：

• 后端：后端声明可以包含一个或多个服务器；后端服务器可以以 DNS 记录或 IP 地址的形式添加。可以在 HAProxy 服务器上设置多个后端声明。还可以选择负载均衡算法，如轮询或最少连接数。

  在以下示例中，我们看到两个后端服务器 10.11.0.1 和 10.11.0.2，使用轮询算法在端口 80 上进行负载均衡：

  

• 检查：检查可以避免用户在服务器因某种原因变得不可用时手动将其从后端移除，从而减少停机时间。HAProxy 的默认健康检查总是尝试使用默认端口和 IP 建立与服务器的 TCP 连接。如果服务器无法提供请求，HAProxy 会自动禁用该服务器以避免停机。服务器只有在通过健康检查后才会重新启用。如果后端所有服务器都未通过健康检查，HAProxy 会将整个后端报告为不可用。

  可以通过使用 {health-check} 选项对后端服务器进行多种健康检查；例如，在以下示例中，即使端口 443 正在进行负载均衡，tcp-check 也可以检查端口 8080 的健康状况。

  

• 访问控制列表（ACL）：ACL 声明用于检查头信息并根据头信息将流量转发到特定的后端服务器。HAProxy 中的 ACL 将尝试根据条件触发动作。

• 前端：前端声明允许 HAProxy 负载均衡器支持不同类型的流量。

  在以下示例中，HAProxy 将接受端口 80 上的 http 流量，使用 ACL 只匹配以 /network 开头的请求，并且当匹配 /web-network 的 ACL 时，它将被转发到 high-perf-backend：

  

负载均衡不可变和静态基础设施

随着 AWS 和 OpenStack 等公共和私有云解决方案的出现，已转向使用不可变基础设施，取代传统的静态服务器。

这引发了关于 宠物与牲畜 的争论，或者正如 Gartner 定义的那样，双模式 (www.gartner.com/it-glossary/bimodal/)。

Gartner 表示需要采取两种不同的策略，一种用于新的微服务，牲畜，另一种用于传统基础设施，宠物。牲畜是指一旦完成任务或出现问题就会被淘汰的服务器，通常生命周期为一个发布周期。相对地，宠物是指那些会有数月或数年正常运行时间并会由运维人员进行修补和照顾的服务器。

Gartner 将宠物定义为模式 1，将牲畜定义为模式 2。据说，牲畜方法更适合无状态的微服务云原生应用，而宠物则是指任何单体应用，或者是包含数据的应用，比如数据库。

很多人认为，不可变基础设施和像 OpenStack 和 AWS 这样的解决方案更倾向于牲畜，而单体应用和数据库仍然作为宠物，仍需要一个适用于长期运行服务器的平台。

就个人而言，我觉得宠物与牲畜的辩论是一个非常懒散的争论，令人有些疲惫。与其将应用程序划分为两类，不如把应用程序看作是一个软件交付问题，这就变成了无状态的读取应用和有状态的应用，后者涉及缓存和数据。云原生微服务应用仍然需要数据和状态，因此我对这种区分感到困惑。

然而，毫无争议的是，负载均衡器是不可变基础设施的关键，因为至少有一个版本的应用程序始终需要向客户或其他微服务公开，以确保该应用程序在任何时候都没有停机并保持运行状态。

静态和不可变服务器

在历史上，企业通常会使用运维团队执行以下服务器操作：

• 安装机架和电缆

• 提供固件更新

• 配置 RAID 配置

• 安装操作系统

• 打补丁操作系统

这一切发生在将服务器提供给开发人员之前。静态基础设施仍然可以存在于云环境中；例如，由于需要在本地磁盘上持久化大量数据，数据库通常仍作为静态的物理服务器部署。

静态服务器指的是一组通常会包含状态的长期运行服务器。

另一方面，不可变服务器意味着每次虚拟机发生变化时，都会部署一个新的虚拟机，配备新的操作系统和新发布的软件，彻底删除旧的内容。不可变基础设施意味着不会对服务器状态进行就地更改。

这避免了进行就地升级的痛苦，并确保雪花服务器配置成为过去，过去每台服务器尽管有最好的意图，但在一段时间后总会有轻微的偏离其期望状态。

发布软件时，有多少次软件只在五台机器中的四台上正常工作，浪费了数小时或数天的时间来调试为什么某个软件升级在特定服务器上无法正常工作。

不可变基础设施从已知状态构建服务器，推动相同的配置到质量保证、集成、性能测试和生产环境。

云基础设施的部分组件可以完全不可变，以此来获取这些优势。操作系统就是其中一个候选对象；与其进行就地修补，不如创建一个单一的金镜像，并使用自动化工具（如 Packer）进行完全自动化的补丁更新。

需要缓存层的应用程序本质上更有状态，因此缓存需要始终可用，以便为其他应用程序提供服务。这些缓存应用程序应该以集群的形式部署，并进行负载均衡，滚动更新将确保始终有一个版本的缓存数据可用。该缓存层的新软件版本应该在销毁之前的版本之前同步缓存数据。

另一方面，数据是持久的，因此可以存储在持久存储中，然后由操作系统挂载。当进行不可变的滚动更新时，操作系统层可以在发布过程中将数据挂载到持久或共享存储上。

可以将操作系统和数据分开，从而使所有虚拟机无状态。例如，可以利用 OpenStack Cinder（wiki.openstack.org/wiki/Cinder）将持久数据存储在可以附加到虚拟机上的卷中。

考虑到所有这些使用场景，大多数应用程序可以通过适当的配置管理设计为不可变的部署，甚至是单体应用程序，只要它们不是单点故障。如果某些应用程序是单点故障，它们应该被重新架构，因为发布软件不应导致停机。尽管应用程序是有状态的，但每个状态可以分阶段更新，从而保持一个总体的不可变基础设施模型。

蓝绿部署

蓝绿部署过程并不是一个新概念。在云解决方案崭露头角之前，生产服务器通常会有一组由蓝色（无实时流量）和绿色（提供客户流量）服务器组成的服务器集群，这些服务器会交替使用。这些通常被称为蓝绿服务器，每次发布时会进行交替。

简单来说，蓝绿模型意味着，当需要进行软件升级时，蓝色服务器会被升级到最新的软件版本。升级完成后，蓝色服务器将成为新的绿色服务器，实时流量将切换到新升级的服务器上。

切换实时流量通常是通过将 DNS 条目切换到指向新升级服务器来完成的。因此，一旦 DNS 生存时间（TTL）传播完成，最终用户的请求就会由新升级的服务器来处理。

这意味着，如果软件发布出现问题，可以通过将 DNS 条目切换回指向上一个软件版本来实现回滚。

典型的蓝绿部署过程如下所述：

Release 1.1 将部署在服务器 1、2 和 3 上，并通过负载均衡器向客户提供服务，并设置为绿色（上线）：

Release 1.2 将部署在服务器 4、5 和 6 上，然后打上最新的补丁版本，升级到最新的发布版本并进行测试。准备好后，运维团队将切换负载均衡器，将 4、5 和 6 号服务器设置为新的生产发布版本，如后续所示，而之前的绿色（上线）部署将变为蓝色，反之亦然：

当运维团队进行下一个发布时，服务器 1、2 和 3 将被打上最新的版本，升级到 Release 1.3（从 Release 1.1 升级），进行测试，准备好后，运维团队将使用负载均衡器将流量引导到新版本，使 Release 1.2 为蓝色，Release 1.3 为绿色，如下图所示：

传统上，这是使用静态服务器进行蓝绿部署的过程。

然而，在使用不可变模型时，与使用长寿命的静态服务器（例如服务器 1、2、3、4、5 和 6）不同，在发布成功后，服务器将被销毁，如此处所示，因为它们已经完成了使命：

下次需要服务器 4、5 和 6 时，不是进行就地升级，而是会从云环境中的黄金基础镜像创建三台新虚拟机。这些黄金镜像已经打好最新的补丁，因此全新的服务器 7、8 和 9 会在销毁旧服务器后部署 Release 1.4，如后续所示。

一旦服务器 7、8 和 9 上线，服务器 1、2 和 3 将被销毁，因为它们已经完成了使命：

使用 Ansible 协调负载均衡器

在 第四章，使用 Ansible 配置网络设备 中，我们介绍了 Ansible 的基本概念，以及如何使用 Ansible 控制主机、playbooks 和角色进行网络设备的配置管理。然而，Ansible 还有许多不同的核心操作可以帮助协调负载均衡器，我们将在本章中详细讨论。

委托

Ansible 委托是一种强大的机制，意味着从 playbook 或角色中，Ansible 可以通过 SSH 或 WinRM 连接到清单文件中指定的目标服务器，或者从 Ansible 控制主机上交替执行命令。

下图展示了这两种替代连接方法，Ansible 控制主机要么通过 SSH 登录到机器配置它们，要么直接从 Ansible 控制主机运行 API 调用：

这两种选项都可以通过相同的角色或剧本执行，使用 delegate_to，这使得剧本和角色非常灵活，因为它们可以结合 API 调用和服务器端配置管理任务。

委托的一个示例可以在后面找到，那里使用了 Ansible 附加的 HAProxy 模块，并使用 delegate_to 来触发一个协调操作，该操作禁用库存文件中的所有后端服务：

利用 serial 控制滚动百分比

为了在不打断服务的情况下发布软件，最好采用零停机时间的方法，因为它不需要维护窗口来安排更改或发布。Ansible 支持 serial 选项，它将百分比值传递给剧本。

serial 选项允许 Ansible 遍历库存，并仅对一部分机器执行操作，完成必要的剧本后，再移动到库存的下一部分。需要注意的是，Ansible 将库存传递为一个无序的字典，因此处理的库存百分比将不是按特定顺序进行的。

使用 serial 选项，Ansible 可以采用蓝绿策略，因此需要将机器从负载均衡器中移除并进行升级，然后再投入使用。与增加机器数量不同，三个机器是足够的，如下图所示，所有这些机器都运行 版本 1.4：

使用以下 Ansible 剧本，结合 delegate_to 和 serial，可以通过滚动更新升级每台服务器：

该剧本将执行以下步骤：

1. serial 30% 表示一次只有一个服务器进行升级。因此，服务器 7 将通过在 Ansible 控制主机上使用本地 delegate_to 操作来从 HAProxy 的 backend_nodes 池中移除，禁用该服务，然后执行 yum 更新，升级服务器版本并安装新的 application1 发布 版本 1.5，如下所示：

2. 服务器 7 将再次启用，并通过本地 delegate_to 操作将其重新投入负载均衡器中。serial 命令将继续作用于 server 8，在 HAProxy 上禁用它，然后执行 yum 更新，升级服务器版本并安装新的 application1 发布 版本 1.5，如下所示：

3. 滚动更新将启用负载均衡器上的服务器 8，然后序列命令将切换到服务器 9，在 HAProxy 上禁用该服务器，然后执行 yum 更新，这将升级服务器并安装新的application1版本1.5，根据需要在本地服务器和远程服务器之间交替执行，如下所示：

4. 最后，剧本将通过在负载均衡器上启用服务器 9来完成，所有服务器将使用 Ansible 升级到版本 1.5，具体如下：

动态库存

在处理云平台时，仅使用静态库存有时并不够。了解已部署在资源中的服务器库存，并根据特征或配置文件选择其中的子集是非常有用的。

Ansible 有一个增强功能，称为动态库存。它允许用户使用 Python 脚本查询他们选择的云平台；这将作为自动发现工具，可以连接到 AWS 或 OpenStack，并返回 JSON 格式的服务器库存。

这允许 Ansible 将此 JSON 文件加载到剧本或角色中，以便进行迭代。同样，静态库存文件也可以通过变量传递。

动态库存适用于相同的命令行结构，而不是传递以下静态库存：

ansible-playbook –i inevntories/inevtontory –l qa –e current_build=9 playbooks/add_hosts_to_netscaler.yml

然后，可以传递 OpenStack 云提供商的动态库存脚本openstack.py：

ansible-playbook –i inevntories/openstack.py –l qa –e environment=qa playbooks/devops-for_networking.yml

动态库存脚本可以设置特定限制。在前述情况下，返回的唯一服务器库存是质量保证服务器，这是通过–l qa限制来控制的。

在使用 Ansible 配置不可变服务器时，可以利用静态库存文件来启动新的虚拟机，而静态库存则可以在虚拟机已经创建后查询资源并执行附加操作。

标签元数据

在 Ansible 中使用动态库存时，元数据变得非常重要，因为在云环境中部署的服务器可以使用标记在虚拟或物理机器上的元数据进行排序和过滤。

在配置 AWS、Microsoft Azure 或 OpenStack 实例时，可以在公共或私有云中为服务器标记元数据，以便对它们进行分组。

在以下示例中，我们可以看到一个剧本使用os_server OpenStack 模块创建新的 OpenStack 服务器。它将遍历静态库存，标记每个新创建的组，并释放机器上的元数据：

然后，可以使用–l参数过滤动态库存，指定group: qa的服务器。这将返回一个合并后的服务器列表。

Jinja2 过滤器

Jinja2 过滤器允许 Ansible 过滤 playbook 或角色，从而控制在执行特定命令或模块之前需要满足哪些条件。Ansible 提供了多种现成的 Jinja2 过滤器，或者也可以编写自定义过滤器。

使用 Jinja2 过滤器的 playbook 示例将仅在服务器的元数据 openstack.metadata.build 值等于当前构建版本时，才将该服务器添加到 NetScaler 中：

执行 ansible-playbook add_hosts_to_netscaler.yml 命令，并通过 –l 限制为 qa，将仅返回 qa 元数据组中的主机作为库存。然后，主机可以在 playbook 或角色中进一步使用 when Jinja2 过滤器进行过滤，只有当主机的 openstack.metadata.build 值与 current_build 变量 9 匹配时，才会执行“加入负载均衡池”命令：

ansible-playbook –I inevntories/openstack.py –l qa –e environment=qa –e current_build=9 playbooks/add_hosts_to_netscaler.yml

结果将是，只有新的主机会被添加到 NetScaler 的 lbvserver VIP 中。

这些主机也可以以类似方式在同一 playbook 中使用 不等于 条件删除：

所有这些可以结合使用，同时配合串行百分比，将新版本逐步部署到负载均衡器中，并利用动态库存、委托、Jinja2 过滤器和 Ansible 的串行滚动更新功能一起实现简单的负载均衡器编排。

创建 Ansible 网络模块

由于 Ansible 可用于调度对负载均衡器的 API 命令，因此可以轻松地用它来构建出流行网络解决方案（如 Citrix NetScaler、F5 Big-IP 或 Avi Networks）所使用的负载均衡器对象模型。

随着微服务架构的推广，负载均衡配置需要拆分以保持可管理性，因此它是以应用为中心的，而不是存储在集中式的单体配置文件中。

这意味着在进行负载均衡更改时会涉及操作问题，因此网络操作员可以使用 Ansible 来构建复杂的负载均衡规则、应用 SSL 证书、设置更复杂的第 7 层上下文切换或公共 IP 地址，并将这些作为服务提供给开发人员。

利用负载均衡供应商提供的 Python API，每个操作可以作为一个模块创建，并使用一组 YAML var 文件来描述负载均衡器的预期状态。

在稍后的示例中，我们将探讨开发人员如何利用 Ansible 的变量文件为每个新的虚拟服务器创建服务和健康监控器，这些虚拟服务器运行在 NetScaler 上。然后，这些服务会绑定到由网络团队创建的 lbvserver 实体，并设置为 10% 的滚动百分比，可以加载到 playbook 的 serial 命令中。playbook 或角色用于创建服务、lbmonitors、34 个服务器并将服务绑定到 lbvservers，而变量文件则描述了这些 NetScaler 对象的期望状态：

摘要

在本章中，我们看到从专有供应商到开源解决方案都提供了各种负载均衡解决方案，并讨论了微服务对负载均衡的影响，将其从集中式模型转变为分布式模型，以帮助应对东西向流量。

然后，我们探讨了蓝绿部署模型、不可变和静态服务器的优点，以及如何在这两种模型中使用 Ansible 协调软件发布。在此过程中，我们展示了 Ansible 在协调负载均衡器时的有用性，通过利用动态库存、滚动更新、委派和 jinja2 过滤器，帮助实现负载均衡的需求。

本章的关键要点是，微服务应用程序改变了应用程序负载均衡的方式，分布式负载均衡在部署微服务应用程序时更为适合，因为微服务应用程序具有更多的东西-西行流量模式。

不可变基础设施为什么非常适合微服务应用程序的原因现在应该很清楚了。本章还定义了如何将状态和数据从操作系统中分离，以及支持无状态和有状态应用程序所需的不同滚动更新模型。在下一章中，我们将研究如何将这些相同的自动化原则应用到 SDN 控制器上，主要聚焦于 Nuage 解决方案。它将涵盖配置防火墙规则和其他 SDN 命令，从而使整个网络可以通过编程进行控制和自动化。

第六章：使用 Ansible 编排 SDN 控制器

本章将重点讨论 SDN 控制器及其如何帮助网络团队简化日常任务。

我们将探讨为什么 SDN 控制器被采纳，并重点介绍它们在正确使用时所带来的即时业务好处。重点讨论的是如何拆分网络操作，以便通过利用自动化扩展网络操作。

本章将讨论利用软件定义网络的好处，并介绍可用于编排 SDN 控制器 API 和对象模型的实际配置管理流程。最后，我们将探讨如何使用 Ansible 执行并包装一些这些配置管理流程，以 Nuage VSP 作为实际示例。

本章将涵盖以下主题：

• 关于软件定义网络的争议

• 为什么公司要使用 SDN？

• 网络操作的拆分

• 不可变的网络

• 使用 Ansible 编排 SDN 控制器

关于软件定义网络的争议

随着 AWS、Microsoft Azure 和 Google Cloud 等公共云的出现，网络现在被视为一种商品，并从硬件转向了软件。这使得开发人员能够根据应用程序的需求调整网络，而不是将应用程序强行适配到一个可能未针对现代微服务应用程序进行优化的老旧网络中。

因此，如果任何企业想要以不同的方式对待其内部数据中心网络，那么这似乎是没有意义的。然而，像所有新思想一样，接受和采用之前总是伴随着恐惧和不确定性，这与新的或不同的工作方式密切相关。

反对使用 Clos Leaf-Spine 架构和 SDN 控制器的常见争论围绕一个共同的主题，那就是它需要变革，而变革是困难的。我们回到 OSI 模型的传说中的第 8 层，那就是用户层：

网络操作员必须对实施的任何解决方案感到舒适。这一点非常重要，但同样重要的是用户层，因为它是由网络团队提供给最终用户的网络服务。因此，易用性在两个层面上都很重要：网络操作和提供给网络消费者的自服务操作。

在公司考虑实施软件定义网络之前，他们需要出于正确的理由，并根据需求来实施。单纯实施一个新工具，在这种情况下是 SDN 控制器，无法单独解决操作性问题。

组织需要弄清楚新的运营模式应是什么，并利用软件定义网络作为这些新业务流程的促进者，专注于运营速度，旨在消除网络作为应用交付瓶颈的存在。简而言之，网络运营需要适应 DevOps，否则它们会妨碍软件交付，拖慢整个应用生命周期。

增加的网络复杂性

反对使用覆盖网络的部分论点是，它们比传统的二层网络更复杂，拥有更多的动态组件，这些组件可能导致更广泛的故障。

尽管覆盖网络和基础网络的构建方式可能不同，但可以公平地说，软件定义网络仍然是一个相对较新的概念，许多人对改变感到恐惧。只要在网络可用性、冗余性、性能和变更速度等基本要求得到满足，就没有理由不实施软件定义网络。

对软件定义覆盖网络的恐惧可以类比为运营人员最初对服务器虚拟化的怀疑，他们最初反对引入虚拟机监控程序。这些新概念最初被视为额外的复杂层和抽象层，可能不会像预期那样具有良好的性能。

然而，通过运行虚拟机监控程序所带来的可移植性和机遇，远远超过了对绝大多数应用场景的性能影响。这些好处包括提高的可移植性、灵活性和操作速度。

当然，仍然存在一些边缘案例和不适用于虚拟化模型的应用，但虚拟化为 99%的数据中心带来的好处意味着，作为一种商业解决方案，它实在不能被忽视。

覆盖网络为网络带来的好处与虚拟机监控程序为服务器带来的好处相似。当然，在实施软件定义覆盖网络时，基础网络应该为冗余性构建，这样一旦发生故障，它会发生在基础网络上，而不会影响覆盖网络。

基础网络应具备横向扩展性且简单，以叶脊架构为例，架构中一系列脊交换机连接到位于每个机架顶部的叶交换机。引入更多配有叶交换机的机架，或者增加新的脊交换机来防止链路过载，可以实现横向扩展性。

关于覆盖网络增加复杂性的问题，任何一位花费数小时调试二层生成树网络中表现不佳的链路的系统可靠性工程师或网络工程师都会证明，生成树网络本身就非常复杂。系统可靠性工程师或网络工程师可能还会展示他们为了解决问题而绘制的网络图，作为复杂性的证据。

因此，网络在最好的时候也很复杂；然而，在使用承载网和叠加网时，承载网的主要关注点应是横向可扩展性和性能。它应确保网络运营商能够根据需求轻松扩展网络。

另一方面，叠加网络的重点是简洁性，因此它应该具有易于理解的软件结构，同时确保 API 端点能够处理来自消费者的所需数量的并发请求。

如果实施得当，网络应该分为两个不同的部分。叠加网络是用户友好的软件，类似于 AWS、Microsoft Azure、Google Cloud 或 OpenStack，而承载网则是需要网络架构师精心设计并为可扩展性构建的硬核网络。

缺乏软件定义网络技能

另一个反对不实施软件定义网络的论点是当前行业内缺乏技能；对于任何新技术来说，最初都会缺乏足够的熟练人员来支持它。一个观点是，公司将不得不雇佣全新的员工来实施软件定义网络。

然而，这可以通过与 SDN 供应商合作或利用提供的员工培训计划来弥补。这是一种业务转型，因此，网络人员需要在一段时间内不断培养新技能。

但是，网络人员需要随着软件定义网络带来的变化而发展，并像 IT 的其他团队一样培养新技能。实施软件定义网络一开始是一个巨大的变化，但优秀的网络人员应该感到兴奋并迎接这些变化。实施软件定义网络所能带来的效率和收益是不可否认的。

改变一开始可能令人畏惧，有时可能看起来像是一次巨大的文化变革或努力。要在大公司甚至小公司中成功发起变革，通常必须有自上而下的支持或支持。

采用软件定义网络将意味着改变业务的运营模式，并且自动化将在每个层面上得到采用；在使用 SDN 控制器时，叠加网络中的网络任务不能再是手动的。实施软件定义网络的组织还需要寻找自动化承载网的方法。在本书中，我们已经研究了如何利用 API 配置网络设备，因此，承载网和叠加网都需要实现自动化。

“软件定义数据中心”这一术语被厂商过度使用，但如果网络团队希望为公司其他部门提供卓越的用户体验，这背后的原则不能被忽视。如果公司将软件定义网络解决方案作为独立的举措来实施，但如果没有编写自动化以利用提供的丰富 API 来加速网络操作，那么它将没有真正的价值。如果公司要部署软件定义网络，并让网络工程师手动输入网络设备上的命令或使用 GUI，那么公司不如不做，因为他们可以使用任何现成的交换机或路由器来做到这一点；他们浪费了软件定义覆盖网络所提供的机会。

仅仅部署软件定义网络解决方案，而仍然让开发人员提出网络工单，将不会带来任何商业价值；它不会提高效率、市场上线时间或变更的可靠性。为了确保组织从软件定义网络中提取出显著的商业利益，你需要一种全有或全无的方法；网络操作要么完全自动化，要么随着时间推移变得碎片化并崩溃。

如果网络工程师坚持在自动化工作流外进行手动更新，那么它可能会打破整个操作模式。它会改变网络的期望状态，并可能完全破坏自动化。

在部署软件定义网络时，首先自动化所有常见操作，并允许开发人员自助服务，如果可能的话，确保它是不可变的。能够从源代码控制管理系统重建网络应该是目标，因为它充当了变更记录。

在第三章，将 DevOps 引入网络操作，我们讨论了如何启动文化变革。人类是习惯性动物，他们倾向于坚持自己知道的东西；网络工程师花了多年时间获得网络认证，学习如何配置生成树算法和二层网络，因此这是一次巨大的文化转变。

支持常规要求的有状态防火墙

软件定义网络的主要问题之一是缺乏有状态防火墙，因为 Open vSwitch 基于流量数据，并且传统上是无状态的。直到最近，反射规则被用来在内核用户空间级别模拟有状态防火墙。

然而，最近 Open vSwitch 的特性发展使得有状态防火墙得以实现。因此，Open vSwitch 的有状态防火墙问题不再存在。连接跟踪（conntrack），以前仅作为 iptables 的一部分，现在已从 iptables 中解耦，这意味着现在可以同时根据连接和流量数据进行匹配。

Nuage VSP 平台在其 4.x 版本中引入了有状态防火墙。Nuage VSP 平台用有状态规则取代了反射规则，以管理 Nuage VRS（Nuage 定制版 Open vSwitch）上的所有 ICMP 和 TCP ACL 规则：

为什么组织需要软件定义网络？

任何优秀的企业网络都应该以以下目标为基础构建：

• 性能

• 可扩展性

• 冗余性

网络首先需要具备高性能，以满足客户需求。客户可以是数据中心的最终用户，也可以是公共域中应用的最终用户。随着持续交付和部署的推进，如果网络在测试环境中阻碍了开发人员，可能会影响一个潜在功能或 bug 修复上线，因此，低于标准的预生产网络是不可接受的，它们应该设计为生产环境的缩小版功能副本。

可扩展性侧重于将网络横向扩展以支持公司增长和需求的能力。随着更多应用的增加，网络如何实现水平扩展？是否具有成本效益？是否可以轻松适应新的服务需求，如第三方 VPN 访问或点对点网络集成？在创建灵活且强大的网络设计时，所有这些问题都需要得到充分考虑。

冗余性建立在任何企业网络都不应有单点故障的概念上。这样网络可以从交换机故障或核心路由器问题中恢复过来，而不会导致客户中断。网络的每个部分都应该旨在最大限度地提高正常运行时间。

这三点似乎是过去优秀网络设计和建设的基础。然而，随着应用从单体应用转向微服务，成功的网络操作需要额外的要求。

传统上，单体应用通常有一个设置操作，然后保持相对静态，而微服务应用则需要更动态的网络，且网络的变化程度更大。

现代网络的需求已发生变化，网络需要迅速更新，以应对微服务架构的需求，而无需等待网络工程师处理工单。随着持续交付形成反馈循环，过程必须迅速且精益，问题能够快速修复，否则整个流程将崩溃并停滞不前。

软件定义网络增加了灵活性和精准性

软件定义网络，特别是覆盖网络，依然侧重于性能、可扩展性和冗余性；这些因素绝不能妥协，但它也带来了以下好处：

• 灵活性

• 恢复平均时间

• 精准性和可重复性

软件定义网络将网络放入具有关联对象模型的软件覆盖网络中，这使得网络可以通过暴露丰富的 API 集合来进行编程。这意味着，工作流可以用于设置网络功能，就像在云或虚拟化环境中控制基础设施一样。

由于网络是可编程的，请求新的子网或进行 ACL 更改可以像在虚拟机监控程序上启动虚拟机一样迅速完成。软件定义网络消除了传统的阻碍因素或操作限制。过去，这些往往包括需要向网络运维团队提出工单来更改网络，而这个过程通常受到冗长的变更控制流程的制约。相反，利用软件定义网络时，开发人员可以通过 API 调用控制网络操作的子网，从而能够快速进行更改。

使用软件定义网络时，平均恢复时间也得到了改善，因为网络更改是可编程的，因此网络清单可以存储在源代码管理系统中。这使得网络可以版本化，任何更改都会通过源代码管理进行交付，并使网络更改具备模块化、可审计和易于跟踪的特性。

如果覆盖网络发生了重大更改，可以通过源代码管理系统中的版本树查看自上次网络正常发布以来发生了什么变化。然后可以使用相同的可编程脚本快速回滚网络更改至之前的版本，解决问题。当然，这就是实现不可变网络的美妙之处，而不是静态网络，在这种网络中，状态始终保持与初始网络一样干净，可以根据需要向前或向后滚动。

软件定义网络中的可重复性是通过程序化操作工作流来实现的，以便所有网络更改都能以相同的方式由所有用户执行。这些操作可以通过网络团队批准的 API 工作流对覆盖网络进行执行。

程序化工作流的使用意味着网络更改可以融入到应用程序部署过程中，例如持续交付。这意味着，像代码一样，网络更改将被检查到源代码管理系统中，通过程序化工作流操作（以管理网络的期望状态）推送到测试环境，进行测试和验证，然后再推广到下一个测试环境或生产环境。

使用覆盖网络的可重复性确保了质量保证测试环境中的所有构造可以与生产环境相同，因为所有的网络构造都在软件中描述，并且容易复现。

对持续交付有良好的理解是关键。

寻求利用软件定义网络的组织，理想情况下应该已经为代码和基础设施建立了一个成熟的持续交付模型，然后再处理网络操作。那些致力于进行 DevOps 转型的公司，也会从围绕软件定义网络设计新运营模型中大大受益。

那些要求将其所有 IT 操作，包括网络功能，自动化的公司，将从使用 SDN 控制器帮助团队自动化网络中获得不可估量的量化收益。那些本身理解 DevOps、持续集成和持续交付的公司，更有可能充分利用 SDN 控制器的全部能力，并推动创新。

强调一点，如果覆盖网络是由网络工程师手动修改而不是程序化修改的，那么它将不会带来任何商业价值，公司也会错失关键。

实施软件定义网络时，操作模型需要改变，如果发生问题，需要将其纳入自动化流程中进行修复，以避免问题再次发生。任何复杂的流程在最初自动化时，可能会遇到一些意想不到的边缘情况，并在未预料到的条件下失败。因此，持续迭代和改进自动化流程非常重要。让团队采用持续改进的方法论，将确保自动化流程不断迭代和改进，从而随着时间的推移变得越来越稳健。

重要的是要认识到边缘情况会发生，并且在发生时不要惊慌；通过自动化修复问题会使所有用户受益，但同样，自动化中的问题可能会影响多个用户，因此它是一把双刃剑。在创建自动化流程时，进行充分的测试，以尽量在测试环境中捕捉这些边缘情况，变得至关重要。

自动化带来的好处之一是，所有变更都可以像一位高技能的网络工程师一样精确地执行，这位工程师可以将所有的知识传递给自动化系统。这意味着每一次自动化的网络变更都像公司中最优秀的网络工程师一样，经过同样的细心和精确操作。

自动化工作流的预先批准和明确定义的变更可以由公司中的任何人执行，而不仅仅是最优秀的工程师，如果这些变更是自动化的，这样就消除了瓶颈，网络团队可以腾出时间去处理比日常重复的日常业务 (BAU)任务更有趣的任务，这些任务使用自动化会更准确地完成。

简化复杂网络

对于拥有非常复杂遗留网络的组织，软件定义网络将是一个理想的选择，因为修复现有网络可能不可行，原因是必须遵守 99%的正常运行时间目标。相反，可以在现有网络的基础上并行创建一个新的绿地网络。

这将允许应用负载随着时间的推移迁移到新的网络，并在此过程中简化现有网络的复杂性。在迁移期间，新建的绿地网络和旧的遗留网络共存时，可以使用 SDN 覆盖网络将应用程序依赖关系路由回遗留网络，直到这些依赖项迁移完成。

软件定义网络的另一个好处是，它可以让私有云解决方案在更大的规模上运行。如果私有云运行超过 100 个虚拟化管理程序，那么 SDN 解决方案将对其有益，例如扩展 OpenStack Neutron 功能，允许公司在大规模上运行 OpenStack，而不是部署多个较小的 OpenStack 云以应对瓶颈。

分割网络操作

随着软件定义网络（SDN）在公司或企业中的引入，运营责任必须发生转变。如果一个组织运行多个微服务应用程序，一个相当典型的情况是公司有 100 个开发人员开发这 200 个微服务。

这 200 个微服务共同部署公司面向客户的网站。

公司可能采用敏捷软件开发，将 100 个开发人员分成若干个交付团队，每个团队包含约 10 个开发人员，组成 scrum 团队，每个交付团队负责一组相对复杂的微服务。

公司有 10 个网络工程师，负责满足 100 个开发人员的网络需求，同时维护网络的正常运行。

然而，在这种模式下，如果所有网络操作都是手动进行的，那么网络工程师将无法跟上所需的变更请求，因此他们要么不得不加班工作，最终导致精疲力尽，生产力下降。在这种模式下，他们处于应急处理模式。

在这种模式下，开发人员的生产力也可能会受到影响，因为网络工程师将成为吞吐量的瓶颈。所描述的模式显然无法扩展，因此需要进行运营变革。

在描述的场景中，每十个开发人员需要一个网络工程师，随着公司未来的扩展，公司将希望投资开发人员来创造更多的产品。对于组织来说，扩大网络团队以支持这些网络操作无疑是更具挑战性的，因此在这种情况下，网络自动化成为必需，网络团队需要更加智能地工作。

在不改变网络团队操作方式的情况下引入新产品和开发者可能导致过度劳累，因此网络工程师能够支持 10 个开发者，但无法支持 20 个开发者进行所有网络操作手动操作。因此，在提倡自动化时，考虑开发者与网络工程师的比例非常重要，如下所示：

业务部门可能会将软件定义网络视为解决扩展问题的方案，目标是简化网络。这意味着网络工程师可以更快速地进行网络变更，以支持开发者的需求。

但仅仅引入像 CISCO ACI、Juniper Contrail、VMware NSX 或 Nuage Networks 这样的软件定义网络解决方案，并不能解决问题，除非流程已经自动化并且低效的业务流程得到了改进。

基于 API 驱动的网络中的新职责

因此，软件定义网络中网络工程师的角色必须发生变化；他们需要像操作人员为创建基础设施时一样，将部分权限下放给开发者。但软件定义网络不应意味着完全开放 API 访问给开发者。这也是灾难的导火索。需要建立有效的控制机制，作为质量关卡，而不是生产力的抑制器。

覆盖网络中的一些操作工作流程仍然应由合格的网络工程师控制，并受到安全性管理，但不应影响开发者的生产力和需求。

如果期望开发者足够精通网络技术，能够登录路由器并为其应用程序设置路由需求，显然不公平，因此必须找到一些中间解决方案。

允许开发者以不受控制的方式访问网络设备，存在网络中断的风险，这违反了三个主要网络原则之一，并且会妥协冗余性，网络工程师有责任确保系统的正常运行时间。

覆盖架构设置

在设置覆盖网络时，通常会在一个全新的环境中构建，作为应用程序迁移计划的一部分，并作为旧有网络的目标环境。应用程序迁移可以是逐步进行的，也可以一次性完成，其中所有内容都会迁移，然后作为迁移“大爆炸”式活动的一部分进行启用。

无论采用何种应用程序迁移方法，确保覆盖网络的设置能够实现以下目标是非常重要的：

• 敏捷性

• 最小化恢复平均时间

• 可重复性

• 可扩展性

网络性能将由底层组件和使用的硅片决定，但在实施 SDN 对象模型的构造和工作流程时需要正确定义覆盖网络，以确保任何操作都可以快速执行，具有可重复性，并且设计具有可扩展性和支持回滚。在实施 SDN 之前，应对其性能进行测试，以确保虚拟化开销不会影响性能。

因此，让我们快速回顾一下 Nuage VSP 对象模型，该模型在第二章中进行了详细讨论，软件定义网络的出现：

• 组织：管理所有第三层域

• 第三层域模板：在创建子第三层域之前需要一个公司 L3 域模板。公司 L3 域模板用于管理适用于所有子第三层域的总体默认策略。如果在模板级别更新了公司 L3 域模板，则会立即在所有已创建的子第三层域上实施更新。

• 第三层域：可用于将不同环境分割开来，使用户无法从部署在第三层测试域的子网跳转到第三层生产域的子网。

• 区域：区域段的防火墙策略位于应用程序级别，因此每个微服务应用程序可以拥有自己的区域和每个第三层域的入口和出口策略。

• 第三层子网：这是部署虚拟机或裸金属服务器的地方。在此示例中，我们看到子网应用程序 1和子网应用程序 2：

• 应用程序特定出口策略：用于出口规则的唯一应用程序策略，可用于查看每个单独应用程序的连接规则：

• 应用程序特定入口策略：用于入口规则的唯一应用程序策略，可用于查看每个单独应用程序的连接规则：

• 泄露域：用于通过第三层子网将路由泄露到覆盖网络中，以桥接绿地网络和传统网络之间的连接：

  所以，以 Nuage VSP 为例，我们有一个包含两个第三层域的组织，分别是测试和生产，每个微服务应用程序都有自己的区域，包含其独特的微子网和虚拟机：

  

  就网络设置而言，网络团队可以使用自动化，并控制覆盖网络中的以下结构：

• 组织：管理所有第 3 层域：

• 第 3 层域模板：用于管理默认策略：

• 第 3 层域：用于分隔开发和生产等环境之间的责任：

• 泄漏域：用于使遗留网络可以从覆盖网络访问：

组织最有可能是第一天的设置活动，而域模板策略可以由网络和安全团队定义和规定。跨所有网络应用的任何安全策略，不管它们部署在哪个域，都由域模板进行管理。因此，测试环境将与生产环境拥有相同的模板策略，并符合所有的安全、治理和合规要求。

开发团队随后可以在测试第 3 层域下创建独特的测试环境，采用相同的后续策略，无需网络团队逐一审计。开发人员使用的应用安全规则可以由安全团队与开发团队达成一致，网络团队无需直接参与，除非他们被请求提供有关设置 ACL 规则的最佳实践建议。

另一个第一天的设置活动可能是设置访问遗留网络，团队将从中迁移应用程序一段时间，因此它们仍然有依赖的应用程序驻留在该网络中。

Nuage VSG 是一个硬件网关设备，连接外部网络到 Nuage VSP 平台及其相关的泄漏域，能够实现这一功能。Nuage VSG 将外部网络的路由泄漏到覆盖网络中，并进入特定的第 3 层域。

Nuage VSP 平台允许网络团队定义利用 VSG 的软件中的GRThubDomain 泄漏域。在此示例中，泄漏域被设置为 IP 主机接口连接到遗留网络中的前端、业务逻辑和后端路由器：

Nuage VSP 平台随后允许将新创建的GRThubDomain与生产或测试第 3 层域相关联，通过将泄漏域与之关联。

在以下示例中，GRThubDomain 泄漏域与生产第 3 层域相关联，以允许从生产第 3 层域下的区域和子网访问遗留网络路由：

网络团队还将负责监控网络底层，并确保在引入更多计算资源时网络能够适当扩展，因此将根据新机架的扩展引入 Leaf 交换机，同时引入新的 Spine 交换机以避免链路饱和。

自助网络

重要的是要关注开发人员通常需要网络票证的网络操作作为起点。这些是开发人员常见的痛点，通常会成为生产力的障碍。通过查看开发团队在网络票务系统中提出的常见问题，可以有效地将网络操作分离。

这些是网络操作员应该使其成为自助服务的常见业务操作：

• 开放防火墙端口

• 创建新的开发环境

• 与其他应用的连接

这些操作应该作为软件定义网络中的自助服务操作进行设置。

在 Nuage VSP 对象模型中，网络操作员应允许开发人员控制以下对象模型实体：

• 区域：它们封装了一个微服务应用：

• 第 3 层子网：这些定义了微服务应用可用的 IP 范围：

• 应用特定 Egress 策略：定义微服务应用的 Egress ACL 策略：

• 应用特定 Ingress 策略：定义微服务应用的 Ingress ACL 策略：

这将允许网络操作团队为开发团队提供组织、层 3 域和层 3 域模板。

在测试或生产层的第 3 层域下，开发团队可以灵活地为每个微服务应用创建独特的新区域，然后创建任何它们需要配置的相关子网和虚拟机。

子网将是微型子网，因此类似于/26、/27或/28的子网可能是可以接受的。网络团队将提供子网架构，并提供一个预定系统，团队可以在 IPAM 解决方案中预定地址空间，如果他们正在引入一个应用或创建一个新应用，以避免与其他团队的冲突。

只要每个交付团队遵循这些结构，网络团队就无需参与新应用的配置或引入，这将变成自助服务，像 AWS、Microsoft Azure 或 Google Cloud 一样。

然而，为了更好地支持开发团队，网络团队应理想地创建自助服务自动化，使开发团队能够在 Nuage VSP 中与运维团队一起执行以下操作：

• 创建区域

• 删除区域

• 创建子网

• 删除子网

• 创建 Ingress 规则

• 删除入口规则

• 创建出口规则

• 删除出口规则

• 创建网络宏（外部子网）

• 删除网络宏（外部子网）

无论实施何种 SDN 解决方案，所需的自服务构造将是相似的，为了扩展网络操作，许多操作必须自动化并实现自服务。

理想情况下，这些自服务工作流操作可以添加到 Ansible playbooks 或角色中，并包含在部署流水线中，以便在部署基础设施的同时也配置网络。

不可变网络

为了充分利用软件定义网络的优势，使用不可变网络相比静态网络带来了多重好处。就像基础设施即代码一样，网络即代码，并且利用不可变网络意味着每次应用程序部署时，其网络都会从描述网络期望状态的源代码管理系统中重新部署。这意味着网络配置不会随着时间的推移发生漂移。

使用网络即代码模型来驱动不可变网络可以在生产环境之前测试应用程序的连接性。应使用与生产环境相似的测试环境，在将任何网络更改发布到生产之前检查应用程序的连接性。

将网络更改作为持续交付模型的一部分进行实施意味着，如果应用程序连接性在测试环境中被证明是错误的，那么在生产环境中应用程序连接性也将是错误的。因此，错误的连接性更改永远不应进入生产环境，而应通过创建反馈循环来在生产之前捕获这些问题，反馈循环会提醒团队网络更改不适合目的。捕获此类问题将防止停机和应用程序停机。

A/B 不可变网络

因此，网络应该理想地与应用程序发布周期集成，并成为其一部分，网络将在每次发布时从头开始构建，并从源代码管理系统加载。可以使用不可变的 A/B 网络部署网络。

以集成了 OpenStack 的 Nuage VSP 为例：

• 一个网络将位于第 3 层域下

• 每个区域将与特定的微服务应用程序相关联

• 在区域下，将在 Nuage 和 OpenStack 中分别创建一个子网

• 每个发布的虚拟机将在 OpenStack 中创建，并与 Nuage 子网关联

Application1 版本 1.1 的第一次发布被部署到 Test 第 3 层域，在 Subnet A Application1 上部署两台虚拟机，这些虚拟机位于 Application1 区域下：

应用程序版本 1.2 的第二次发布被部署到 Test 第 3 层域，缩减发布，并在 Subnet B Application1 上部署一台虚拟机，该虚拟机位于 Application1 区域下：

一旦版本 1.2 已在负载均衡器上投入使用并进行滚动部署，新的虚拟机将在Subnet B Application1投入服务，Subnet A Application1随后可以与其虚拟机一起销毁，作为部署清理的一部分：

下一版Application1（版本 1.3）将被部署到Subnet A Application1，并再次扩展至两个虚拟机：

一旦版本 1.2 已在负载均衡器上投入使用并进行滚动部署，Subnet A Application1上的新虚拟机将投入服务，Subnet B Application1可以随后与其相关的虚拟机一起销毁，作为部署清理的一部分：

每次发布将交替在Subnet A Application1和Subnet B Application1之间进行，每次都会从源代码管理构建网络，并清理上一次发布的内容。

多余防火墙规则的清理

防火墙面临的主要技术债务问题之一是，随着时间的推移，随着应用程序的退役或网络连接的变化，它们会积累大量过时的 ACL 规则。进行清理往往存在风险，因为网络工程师担心可能会引发停机。因此，网络团队需要手动清理防火墙规则。

在使用 A/B 不变网络部署时，出站和入站策略与子网关联，这意味着在 Nuage VSP 中，当子网被删除时，所有与该子网关联的 ACL 策略也将作为发布过程的一部分自动清理。

在以下示例中，Subnet A Application1具有以下连接性，因此，当子网作为发布过程的一部分被删除时，所有这些特定于子网的 ACL 规则将被清理：

需要注意的是，由于 ACL 规则存在于子网到区域之间以满足应用程序依赖关系，因此如果 A 子网部署在服务中，B 子网部署将与其相关的 ACL 进出规则并行启动，以取代 A 部署。

所有依赖Application1的应用程序将需要一个指向区域而非子网的 ACL 规则，这意味着它们将不会失去与应用程序的连接，因为它们的规则将依赖于区域，而非子网。在不变子网模型中，子网到子网的规则是不可行的。

为了说明这一点，以下示例中，当前部署的子网 Application1 拥有连接到 Application2 的子网到区域的 ACL 规则。因此，尽管 Application2 的出口和入口策略每次在 A 和 B 部署之间交替，如下图所示：

所需的 ACL 规则始终作为Application1的依赖项可用，因为它订阅的是区域级别的连接，而非子网级别的连接：

应用程序退役

使用不可变子网使得当应用程序不再需要时，停用变得简单。子网和关联的 ACL 规则的清理逻辑已经存在，因此可以重新使用已创建的自动化来完全清理需要退役的微服务应用程序。

操作和网络团队可以轻松提供一个清理管道，供开发团队清理不再需要的应用程序。然后，他们分配的子网范围可以由 IPAM 解决方案释放，以便这些范围可以提供给需要入驻平台的新微服务应用程序。

使用 Ansible 编排 SDN 控制器

如在第五章中讨论的，使用 Ansible 编排负载均衡器，可以用来发布和配置服务器，并直接向SDK或REST API发出命令：

这对于编排提供 Restful API 端点和一系列 SDK 来控制软件定义对象模型的 SDN 控制器非常有用，这些模型使网络操作员能够自动化所有网络操作。

就 Nuage VSP 平台而言，构建覆盖网络的 VSD 组件在后台通过 REST API 调用，因此所有操作可以使用 Nuage 的 Java 或 Python SDK 进行编排，SDK 封装了 REST API 调用。

只需在 Ansible 控制主机上安装 Nuage VSPK SDK，然后就可以用它来编排 Nuage。由于 Ansible 是用 Python 编写的，因此可以轻松创建模块来编排 Nuage 实体树中的每个对象模型。

使用 Nuage VSPK 模块可以交替地用任何可用的编程语言编写，例如 Java，但 Ansible 的 Python 样板代码可能是创建模块的最简单方法。

Nuage VSPK 对象模型在实体之间具有父子关系，因此需要对父对象进行查找，以返回与实体相关联的唯一标识符所对应的子实体。

以下示例突出显示了构建 Nuage VSPK 对象树所需的操作列表：

1. 启动一个新的 Nuage session。

2. user 用于创建子级 enterprises。

3. 创建一个 domain_templates，作为企业的子模板。

4. domains 被实例化为域模板的子模板。

5. 在域下创建一个子 zone。

6. 在区域下创建一个子 subnet。

使用 SDN 进行灾难恢复

使用 Ansible 进行编排的主要好处之一是它可以用于创建一组 Day One playbooks，在开发人员自服务之前构建初始网络。因此，Nuage 组织、公司 L3 域模板 和三层域的初始设置可以作为 Day One playbook 或角色来创建，其他必要的操作也可以包含其中。

可以利用 Nuage Python VSPK 来轻松创建名为 公司 的组织、名为 L3 域模板 的三层域模板，以及根据 Nuage VSPK 对象模型创建的两个三层域 Test 和 Prod，如下图所示：

这些 Python 命令可以很容易地封装在 Ansible 中，创建一组模块来利用 delegate_to localhost 创建一个 Day One playbook，该 playbook 将在 Ansible 控制主机上执行每个模块，然后连接到 Nuage APIs。

每个模块默认应该编写为幂等的，并在发出 Create 命令之前检测实体是否存在。如果实体已经存在，则不应该发出 Create 命令，尤其是在覆盖网络已经处于期望状态的情况下。

如果整个网络需要恢复，Day One playbook 可用于在灾难发生时从头构建整个网络。Day One playbook 应该存储在源代码管理中。而每个部署管道将根据最初定义的结构构建应用程序区域、子网和虚拟机。

如果需要，也可以将管理传统网络连接的泄漏域和泄漏域关联添加到 Day One playbook 中。

将 A/B 子网和 ACL 规则存储在 YAML 文件中。

Ansible 还可以用于将自服务子网和 ACL 规则信息存储在 var 文件中，这些文件将作为每个开发团队部署管道的一部分，通过一组自服务 playbook 被调用。每个应用环境可以存储在一组 var 文件中，定义每个 A/B 子网。

用于创建 A 或 B 子网的 playbook 将使用 delegate_to localhost 执行操作，针对 Nuage VSD API 进行创建操作。

该 playbook 将执行以下操作：

1. 如果尚未创建区域，则创建区域。

2. 使用子网 YAML 文件在 Nuage 中创建与 OpenStack 映射的子网。

3. 将 ACL 策略应用于进入和退出规则，直接将它们应用到子网。

与第一天的剧本一样，可以为每个 VSPK 命令编写独特的模块；在这个示例中，Python VSPK 创建了一个名为Application1的区域和一个名为Subnet A Application1的子网：

因此，这些命令也可以封装在 Ansible 模块中，应该是完全幂等的，网络的期望状态由存储在源代码控制中的 var 文件确定。

剧本中的逻辑会在部署时通过从源代码控制中拉取 var 文件来加载它们。然后，剧本会使用 Jinja2 过滤器条件来检测 A 或 B 子网是否存在，或者两者都不存在，并使用 when 条件。

如果两个子网都不存在，将创建子网 A；如果子网 A 存在，则会创建子网 B。

剧本可以从环境特定的 var 文件中读取这些信息，该文件在以下截图中指定。由于其幂等性，它将在区域上运行，如果该区域不存在，则会创建它，并使用 jinja2 剧本的 when 条件来创建子网 A 或 B：

一组独特的 A 和 B 子网将被提交到源代码控制中，作为每个所需环境的前提条件，每个第 3 层域下可以有一个或多个环境。

ACL 规则理想情况下应在所有封装在第 3 层域中的环境中保持一致，因此会创建一组明确的 ACL 规则，并将其分配给应用程序的独特策略，用于跨所有环境的入站和出站规则。

每个环境可以为每个第 3 层子网拥有其独特的入站和出站策略。如果在测试第 3 层域下存在多个环境，Ansible 剧本则可以为该环境的策略名称附加一个唯一标识符，适用于服务器集成、UAT 或其他测试环境。

一个应用程序的独特 ACL 规则可以由开发团队填写，作为将应用程序迁移到新平台的一部分，基于使应用程序功能所需的最小连接性，同时对第 3 层域模板应用“拒绝所有”规则。

ACL 规则应始终是子网到区域的关系，以满足相互依赖性，每个 ACL 规则将以子网作为源进行创建，以便在销毁子网时，ACL 规则会自动清除。

以下展示了自助服务 ACL 规则文件的示例，它将创建两个入站规则和一个出站规则，针对Application1策略：

自服务手册可以提供给开发团队，确保他们始终有一个标准的方式来创建区域和子网。var文件的 YAML 结构还将提供网络所需状态的模板。这意味着，只要将自动化管道指向另一个 Nuage 端点，整个网络就能从源控制中以编程方式构建。

总结

本章中，我们回顾了 SDN 控制器可以帮助自动化的不同网络操作，并试图澄清一些与软件定义网络相关的常见误解。

接下来，我们探讨了公司如何通过使用软件定义网络受益，并研究了 SDN 解决方案如何帮助解决一些与网络操作相关的挑战。

本章然后重点讨论了网络操作如何需要适应并拥抱自动化，使得开发团队能够自助完成一部分不同的网络任务，以及网络如何被划分并共享责任。接着，我们讨论了不可变 A/B 网络的好处，以及它如何帮助简化网络，构建一致的程序化控制网络，同时保持防火墙规则的简洁。

在本章中，您应该已经了解到为什么软件定义网络对于那些希望扩展网络操作的组织来说至关重要。我们还介绍了如何将叠加网络对象模型用于微服务应用程序，以及不可变网络和 A/B 子网的好处。

本章的关键要点还包括 SDN 控制器如何帮助网络运营商构建首日网络的不同方式，哪些网络操作可以实现自服务，以及如何通过 Rest API 调用或 SDK 编程控制网络操作。

在下一章中，我们将探讨持续集成以及网络操作如何借鉴开发团队的一些最佳实践，并将其应用于网络操作，从而确保网络版本管理得当，并能够滚动前进或回滚更改。

一旦我们建立了持续集成的基础，就会进入涵盖网络测试和持续交付的章节，这些章节将概述一套最佳实践，帮助网络团队将网络自动化集成到部署管道中。