云集成高级编排器 Cloud Integrated Advanced Orchestrator （Ciao） 是一个新的负载调度程序，用来解决当前云操作系统项目的局限性。Ciao 提供了一个轻量级，完全基于 TLS 的最小配置。它是 工作量无关的、易于更新、具有优化速度的调度程序，目前已针对 OpenStack 进行了优化。

其设计决策和创新方法在对安全性、可扩展性、可用性和可部署性的要求下进行：

• 可扩展性： 初始设计目标是伸缩超过 5,000 个节点。因此，调度器架构用新的形式实现：

  • 在 ciao 中，决策制定是去中心化的。它基于拉取模型，允许计算节点从调度代理请求作业。调度程序总能知道启动器的容量，而不要求进行数据更新，并且将调度决策时间保持在最小。启动器异步向调度程序发送容量。
  • 持久化状态跟踪与调度程序决策制定相分离，它让调度程序保持轻量级。这种分离增加了可靠性、可扩展性和性能。结果是调度程序让出了权限并且这不是瓶颈。
• 可用性： 虚拟机、容器和裸机集成到一个调度器中。所有的负载都被视为平等公民。为了更易于使用，网络通过一个组件间最小化的异步协议进行简化，只需要最少的配置。Ciao 还包括一个新的、简单的 UI。所有的这些功能都集成到一起来简化安装、配置、维护和操作。
• 轻松部署： 升级应该是预期操作，而不是例外情况。这种新的去中心化状态的体系结构能够无缝升级。为了确保基础设施（例如 OpenStack）始终是最新的，它实现了持续集成/持续交付（CI/CD）模型。Ciao 的设计使得它可以立即杀死任何 Ciao 组件，更换它，并重新启动它，对可用性影响最小。
• 安全性是必需的： 与调度程序的连接总是加密的：默认情况下 SSL 是打开的，而不是关闭的。加密是从端到端：所有外部连接都需要 HTTPS，组件之间的内部通信是基于 TLS 的。网络支持的一体化保障了租户分离。

初步结果证明是显著的：在 65 秒内启动一万个 Docker 容器和五千个虚拟机。进一步优化还在进行。

• 文档：https://clearlinux.org/documentation/ciao/ciao.html
• Github 链接： https://github.com/01org/ciao(link is external)
• 邮件列表链接： https://lists.clearlinux.org/mailman/listinfo/ciao-devel

via: https://clearlinux.org/ciao

作者：ciao 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

基于 Linux 击败了专有软件一样的原因，开源应该成为云原生环境的首选。

让我们回溯到上世纪 90 年代，当时专有软件大行其道，而开源才刚开始进入它自己的时代。是什么导致了这种转变？更重要的是，而今天我们转到云原生环境时，我们能从中学到什么?

基础设施的历史经验

我将以一个高度武断的、开源的视角开始，来看看基础设施过去 30 年的历史。在上世纪 90 年代，Linux 只是大多数组织视野中一个微不足道的小光点而已——如果他们听说过它的话。你早早购入股票的那些公司们很快就发现了 Linux 的好处，它主要是作为专有的 Unix 的廉价替代品，而部署服务器的标准方式是使用专有的 Unix，或者日渐增多的使用 Microsoft Windows NT。

这种模式的专有本性为更专有的软件提供了一个肥沃的生态系统。软件被装在盒子里面放在商店出售。甚至开源软件也参与了这种装盒游戏；你可以在货架上买到 Linux，而不是用你的互联网连接免费下载。去商店和从你的软件供应商那里只是你得到软件的不同方式而已。

Ubuntu 包装盒出现在百思买的货架上

我认为，随着 LAMP 系列（Linux、Apache、MySQL 和 PHP / Perl / Python）的崛起，情况发生了变化。LAMP 系列非常成功。它是稳定的、可伸缩的和相对用户友好的。与此同时，我开始看到对专有解决方案的不满。一旦客户在 LAMP 系列中尝过了开源的甜头，他们就会改变他们对软件的期望，包括：

• 不愿被供应商绑架，
• 关注安全，
• 希望自己来修复 bug ，以及
• 孤立开发的软件意味着创新被扼杀。

在技术方面，我们也看到了各种组织在如何使用软件上的巨大变化。忽然有一天，网站的宕机变成不可接受的了。这就对扩展性和自动化有了更多的依赖。特别是在过去的十年里，我们看到了基础设施从传统的“宠物”模式到“群牛”模式的转变，在这种模式中，服务器可以被换下和替换，而不是一直运行和被指定。公司使用大量的数据，更注重数据留存和数据到用户的处理和返回速度。

开源和开源社区，以及来自大公司的日益增多的投入，为我们改变如何使用软件提供了基础。系统管理员的岗位要求开始 要求 Linux 技能和对开源技术和理念的熟悉。通过开源类似 Chef cookbooks 和 Puppet 模块这样东西，管理员可以分享他们的模式配置。我们不再单独配置和调优 MySQL；我们创建了一个掌控基础部分的系统，我们现在可以专注于更有趣的、可以给我们雇主带来更高价值的工程作业。

开源现在无处不在，围绕它的模式也无处不在。曾经仇视这个想法的公司不仅通过协同项目与外界拥抱开源，而且进一步地，还发布了他们自己的开源软件项目并且围绕它们构建了社区。

转向云端

今天，我们生活在一个 DevOps 和云端的世界里。我们收获了开源运动带来的创新成果。在公司内部采用开源软件开发实践的情况下， Tim O'reilly 所称的 “内部开源” 有了明显增长。我们为云平台共享部署配置。像 Terraform 这样的工具甚至允许我们编写和分享我们如何部署特定的平台。

但这些平台本身呢？

“大多数人想都不想就使用了云……许多用户将钱投入到根本不属于他们的基础设施中，而对放弃他们的数据和信息毫无顾虑。" —Edward Snowden, OpenStack Summit, May 9, 2017

现在是时候要更多地想想本能地转移或扩展到云上的事情了。

就像 Snowden 强调的那样，现在我们正面临着对我们的用户和客户的数据的失控风险。抛开安全不谈，如果我们回顾一下我们转向开源的原因，个中原因还包括被厂商绑架的担忧、创新难以推动、甚至修复 bug 的考虑。

在把你自己和/或你的公司锁定在一个专有平台之前，考虑以下问题：

• 我使用的服务是遵循开放标准，还是被厂商绑架的？
• 如果服务供应商破产或被竞争对手收购，什么是我可以依赖的？
• 关于停机、安全等问题，供应商与其客户沟通中是否有一个明确而真诚的历史过往？
• 供应商是否响应 bug 和特性请求，即使那是来自小客户？
• 供应商是否会在我不知情的情况下使用我们的数据（或者更糟，即便我们的客户协议所不同意）？
• 供应商是否有一个计划来处理长期的，不断上升的增长成本，特别是如果最初的成本很低呢？

您可以通过这个问卷，讨论每个要点，而仍然决定使用专有的解决方案。这很好，很多公司一直都在这么做。然而，如果你像我一样，宁愿找到一个更开放的解决方案而仍然受益于云，你确实有的选择。

基于私有云

当您寻找私有云解决方案时，您的首选是开源，投资一个云提供商，其核心运行在开源软件上。 OpenStack 是行业领袖，在其 7 年的历史中，有 100 多个参与组织和成千上万的贡献者（包括我）。 OpenStack 项目已经证明，结合多个基于 OpenStack 云不仅是可行的，而且相对简单。云公司之间的 API 是相似的，所以您不必局限于特定的 OpenStack 供应商。作为一个开放源码项目，您仍然可以影响该基础设施的特性、bug 请求和发展方向。

第二种选择是继续在基础层面上使用私有云，但在一个开源容器编排系统中。无论您选择 DC/OS（基于Apache Mesos) 、Kubernetes 或 Docker Swarm 模式 ，这些平台都允许您将私有云系统提供的虚拟机作为独立的 Linux 机器，并在此之上安装您的平台。您所需要的只是 Linux 而已，不会立即被锁定在特定云的工具或平台上。可以根据具体情况来决定是否使用特定的专属后端，但如果你这样做，就应该着眼于未来。

有了这两种选择，你也可以选择完全离开云服务商。您可以部署自己的 OpenStack 云，或者将容器平台内部架构移动到您自己的数据中心。

做一个登月计划

最后，我想谈一谈开源项目基础设施。今年 3 月，在召开的 南加州 Linux 展会 上，多个开放源码项目的参与者讨论了为他们的项目运行开源基础设施。（更多的，请阅读我的 关于该会议的总结）我认为这些项目正在做的这个工作是基础设施开源的最后一步。除了我们现在正在做的基本分享之外，我相信公司和组织们可以在不放弃与竞争对手相区分的“独门秘方”的情况下，进一步充分利用他们的基础设施开源。

开源了他们的基础设施的开源项目，已经证明了允许多个公司和组织向他们的基础设施提交训练有素的 bug 报告，甚至是补丁和特定论文的价值。突然之间，你可以邀请兼职的贡献者。你的客户可以通过了解你的基础设施，“深入引擎盖子之下”，从而获得信心。

想要更多的证据吗？访问 开源基础设施 的网站了解开源基础设施的项目（以及他们已经发布的大量基础设施）。

可以在 8 月 26 日在费城举办的 FOSSCON 大会上 Elizabeth K. Joseph 的演讲“基础架构开源”上了解更多。

（题图：Jason Baker. CC BY-SA 4.0. Source: Cloud, Globe. Both CC0.）

via: https://opensource.com/article/17/8/open-sourcing-infrastructure

作者：Elizabeth K. Joseph 译者：wenzhiyi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

你有没有问过自己，我应该在哪里运行 OpenShift？答案是任何地方 - 它可以在裸机、虚拟机、私有云或公共云中很好地运行。但是，这里有一些为什么人们正迁移到围绕全栈和资源消耗自动化相关的私有云和公有云的原因。传统的操作系统一直是关于硬件资源的展示和消耗 - 硬件提供资源，应用程序消耗它们，操作系统一直是交通警察。但传统的操作系统一直局限于单机 ^注1 。

那么，在原生云的世界里，现在意味着这个概念扩展到包括多个操作系统实例。这就是 OpenStack 和 OpenShift 所在。在原生云世界，虚拟机、存储卷和网段都成为动态配置的构建块。我们从这些构建块构建我们的应用程序。它们通常按小时或分钟付费，并在不再需要时被取消配置。但是，你需要将它们视为应用程序的动态配置能力。 OpenStack 在动态配置能力（展示）方面非常擅长，OpenShift 在动态配置应用程序（消费）方面做的很好，但是我们如何将它们结合在一起来提供一个动态的、高度可编程的多节点操作系统呢？

要理解这个，让我们来看看如果我们在传统的环境中安装 OpenShift 会发生什么 - 想像我们想要为开发者提供动态访问来创建新的应用程序，或者想象我们想要提供业务线，使其能够访问现有应用程序的新副本以满足合同义务。每个应用程序都需要访问持久存储。持久存储不是临时的，在传统的环境中，这通过提交一张工单实现。没关系，我们可以连到 OpenShift，每次需要存储时都会提交一张工单。存储管理员可以登录企业存储阵列并根据需要删除卷，然后将其移回 OpenShift 以满足应用程序。但这将是一个非常慢的手动过程，而且你可能会遇到存储管理员辞职。

在原生云的世界里，我们应该将其视为一个策略驱动的自动化流程。存储管理员变得更加战略性、设置策略、配额和服务级别（银、黄金等），但实际配置变得动态。

动态过程可扩展到多个应用程序 - 这可能是开发者测试的业务线甚至新应用程序。从 10 多个应用程序到 1000 个应用程序，动态配置提供原生云体验。

下面的演示视频展示了动态存储配置如何与 Red Hat OpenStack 平台（Cinder 卷）以及 Red Hat OpenShift 容器平台配合使用，但动态配置并不限于存储。想象一下，随着 OpenShift 的一个实例需要更多的容量、节点自动扩展的环境。想象一下，推送一个敏感的程序更改前，将网段划分为负载测试 OpenShift 的特定实例。这些是你为何需要动态配置 IT 构建块的原因。OpenStack 实际上是以 API 驱动的方式实现的。

OpenShift 和 OpenStack 一起更好地交付应用程序。OpenStack 动态提供资源，而 OpenShift 会动态地消耗它们。它们一起为你所有的容器和虚拟机需求提供灵活的原生云解决方案。

注1：高可用性集群和一些专门的操作系统在一定程度上弥合了这一差距，但在计算中通常是一个边缘情况。

via: https://blog.openshift.com/openshift-on-openstack-delivering-applications-better-together/

作者：SCOTT MCCARTY 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

OpenStack 部署完就是一个 “ 僵栈 StuckStack ”，一般出于技术原因，但有时是商业上的原因，它是无法在没有明显中断，也不花费时间和成本的情况下升级的。在关于这个话题的最后一篇文章中，我们讨论了这些云中有多少陷入僵局，以及当时是怎么决定的与如今的大部分常识相符。现在 OpenStack 已经有 7 年了，最近随着容器编排系统的增长以及更多企业开始利用公共和私有的云平台，OpenStack 正面临着压力。

没有魔法解决方案

如果你仍在寻找一个可以没有任何问题地升级你现有的 僵栈 StuckStack 的解决方案，那么我有坏消息给你：没有魔法解决方案，你最好集中精力建立一个标准化的平台，它可以有效地运营和轻松地升级。

廉价航空业已经表明，虽然乘客可能渴望最好的体验，可以坐在头等舱或者商务舱喝香槟，有足够的空间放松，但是大多数人会选择乘坐最便宜的，最终价值等式不要让他们付出更多的代价。工作负载是相同的。长期而言，工作负载将运行在最经济的平台上，因为在高价硬件或软件上运行的业务实际上并没有受益。

Amazon、Microsoft、Google 等大型公共云企业都知道，这就是为什么他们建立了高效的数据中心，并使用模型来构建、操作和扩展基础设施。长期以来，企业一直奉行以设计、制造、市场、定价、销售、实施为一体的最优秀的硬件和软件基础设施。现实可能并不总是符合承诺，但它现在还不重要，因为 成本模式 cost model 在当今世界无法生存。一些组织试图通过改用免费软件替代，而不改变自己的行为来解决这一问题。因此，他们发现，他们只是将成本从获取软件变到运营软件上。好消息是，那些高效运营的大型运营商使用的技术，现在可用于所有类型的组织。

什么是软件模型？

虽然许多年来，软件程序由许多对象、进程和服务而组成，但近年来，程序是普遍由许多单独的服务组成，它们高度分布在数据中心的不同服务器以及跨越数据中心的服务器上。

OpenStack 服务的简单演示

许多服务意味着许多软件需要配置、管理并跟踪许多物理机器。以成本效益的方式规模化地进行这一工作需要一个模型，即所有组件如何连接以及它们如何映射到物理资源。为了构建模型，我们需要有一个软件组件库，这是一种定义它们如何彼此连接以及将其部署到平台上的方法，无论是物理的还是虚拟的。在 Canonical 公司，我们几年前就认识到这一点，并建立了一个通用的软件建模工具 Juju，使得运营商能够从 100 个通用软件服务目录中组合灵活的拓扑结构、架构和部署目标。

Juju 建模 OpenStack 服务

在 Juju 中，软件服务被定义为一种叫做 Charm 的东西。 Charms 是代码片段，它通常用 python 或 bash 编写，其中提供有关服务的信息 - 声明的接口、服务的安装方式、可连接的其他服务等。

Charms 可以简单或者复杂，具体取决于你想要赋予的功能。对于 OpenStack，Canonical 在上游 OpenStack 社区的帮助下，为主要 OpenStack 服务开发了一套完整的 Charms。Charms 代表了模型的说明，使其可以轻松地部署、操作扩展和复制。Charms 还定义了如何升级自身，包括在需要时执行升级的顺序以及如何在需要时优雅地暂停和恢复服务。通过将 Juju 连接到诸如 裸机即服务（MAAS） 这样的裸机配置系统，其中 OpenStack 的逻辑模型可以部署到物理硬件上。默认情况下，Charms 将在 LXC 容器中部署服务，从而根据云行为的需要，提供更大的灵活性来重新定位服务。配置在 Charms 中定义，或者在部署时由第三方工具（如 Puppet 或 Chef）注入。

这种方法有两个不同的好处：1 - 通过创建一个模型，我们从底层硬件抽象出每个云服务。2 - 使用已知来源的标准化组件，通过迭代组合新的架构。这种一致性使我们能够使用相同的工具部署非常不同的云架构，运行和升级这些工具是安全的。

通过全面自动化的配置工具和软件程序来管理硬件库存，运营商可以比使用传统企业技术或构建偏离核心的定制系统更有效地扩展基础架构。有价值的开发资源可以集中在创新应用领域，使新的软件服务更快上线，而不是改变标准的商品基础设施，这将会导致进一步的兼容性问题。

在下一篇文章中，我将介绍部署完全建模的 OpenStack 的一些最佳实践，以及如何快速地进行操作。如果你有一个现有的 僵栈 StuckStack ，那么虽然我们不能很容易地拯救它，但是与公有云相比，我们将能够让你走上一条完全支持的、高效的基础架构以及运营成本的道路。

即将举行的网络研讨会

如果你在旧版本的 OpenStack 中遇到问题，并且想要轻松升级 OpenStack 云并且无需停机，请观看我们的在线点播研讨会，从 Newton 升级到 Ocata 的现场演示。

联系我们

如果你想了解有关迁移到 Canonical OpenStack 云的更多信息，请联系这里。

（题图：乐高的空客 A380-800模型。空客运行 OpenStack）

作者简介：

专注于 Ubuntu OpenStack 的云产品经理。以前在 MySQL 和 Red Hat 工作。喜欢摩托车，遇见使用 Ubuntu 和 Openstack 做有趣事的人。

via: https://insights.ubuntu.com/2017/07/18/stuckstack-how-modelling-helps-you-avoid-getting-a-stuck-openstack/

作者：Mark Baker 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

想了解更多关于 OpenStack 的内容？这些免费资源可能只是你所需要的。

云基础设施是一个非常需要的技能。如果你正在为你的云基础架构需求寻找开源解决方案，那么 OpenStack 就是其中之一。

OpenStack 是一个巨大的项目集合，为云服务的几乎每一个部分都提供了解决方案和集成。虽然这个巨大范围使得它成为一个强大的工具，但这也意味着可能很难跟上并了解整个项目，了解如何使用它们、如何自定义它们以及如何向其提供代码。

幸运的是，有很多选择可以帮助你。除了官方项目文档、纸质书籍和认证培训计划外，还有大量社区创造的优秀资源。我们每个月可以在 Opensource.com 上查看它在博客和其他网站上最近发布的指南和教程，这会给你启发。我们来看看这次我们发现了什么。

• 首先在本月的这一批中，我们有一篇来自 Antony Messerli 的指南，介绍如何通过 Ansible 设置 OpenStack 云。Messerli 将引导我们完成实验室环境中的配置以及在集群上运行 OpenStack 所需的 playbook，还有添加镜像、设置网络等的基础知识。如果你正在考虑使用 Ansible 安装 OpenStack 小型本地测试环境，这是一篇很好的文章。
• 接下来，你有没有想过 Neutron 网络如何在 OpenStack 中的工作的？应用程序中发生的事情如何对应于底层代码？Arie Bregman 在这篇文章中提供了一段 OpenStack Neutron 代码。你需要熟悉一般的网络原理，至少有一点 OpenStack 代码基础才能跟上。
• Gerrit是 OpenStack 使用的开源代码审查项目，用于管理上传的修补程序，并允许在将更改合并到主 OpenStack 代码库之前进行反馈和测试。对于那些习惯于不同的代码审查系统（或根本没有的），Gerrit 可能会有点混乱，尽管它具有很好的仪表板功能，因此你只能看到对你很重要的信息。Dougal Matthews 在这篇文章中带我们看了他的 Gerrit 仪表板设置，这可能会帮助你设置自己的。
• 上个月在波士顿举办的 OpenStack 峰会的视频已经发布了，无论你是否参加过上个月的活动，这都包含了技术和非技术专题的宝库。不知道从哪里开始？这有个来自 Julio Villarreal Pelegrino 关于如何规划、构建、运行一个成功的 OpenStack 云计算的演讲。
• 任何云管理员都应该担心安全问题。但你从哪里开始？Naveen Joy 发布了一个很好的十个安全问题的清单，用于加固你的 OpenStack 网络；你可以在上个月的同一主题演讲中查看这个视频。
• OpenStack 中的内部消息服务在一个公共库中进行管理，该库存在于一个称为 Oslo 的项目中，自然它被称为 Oslo.Messenging。要了解这个库的基础知识，它在这个分为两个部分的博客中提到。

想要了解更多？可以从这三年来社区说提供的内容中找到我们完整的 OpenStack 指南、如何做和教程，以帮助你学习成为一名高效的 OpenStack 开发人员或管理员。

有很棒教程、指导或者如何做需要我们分享的么？在下面的评论中分享。

作者简介：

Jason Baker - Jason 热衷于使用技术使世界更加开放，从软件开发到阳光政府行动。Linux 桌面爱好者、地图/地理空间爱好者、树莓派工匠、数据分析和可视化极客、偶尔的码农、云本土主义者。在 Twitter 上关注他。

via: https://opensource.com/article/17/6/openstack-guides-and-tutorials

作者：Jason Baker 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

整个 2016 年，软件定义网络（SDN）迅速发展，开源和云计算领域的众多参与者正帮助其获得增长。结合这一趋势，用在 OpenStack 云计算平台上的流行的 SDN 平台 OpenContrail 正成为许多管理员需要具备的技能的重要工具。

正如管理员和开发人员在 OpenStack 生态系统中围绕着诸如 Ceph 等重要工具提升技能一样，他们将需要拥抱 OpenContrail，它是由 Apache 软件基金会全面开源并管理的软件。

考虑到这些，OpenStack 领域中最活跃的公司之一 Mirantis 已经宣布对 OpenContrail 的提供商业支持和贡献。该公司提到：“添加了 OpenContrail 后，Mirantis 将会为与 OpenStack 一起使用的开源技术，包括用于存储的 Ceph、用于计算的 OpenStack/KVM、用于 SDN 的 OpenContrail 或 Neutron 提供一站式的支持。”

根据 Mirantis 公告，“OpenContrail 是一个使用基于标准协议构建的 Apache 2.0 许可项目，为网络虚拟化提供了所有必要的组件 - SDN 控制器、虚拟路由器、分析引擎和已发布的上层 API，它有一个可扩展 REST API 用于配置以及从系统收集操作和分析数据。作为规模化构建，OpenContrail 可以作为云基础设施的基础网络平台。”

有消息称 Mirantis 收购了 TCP Cloud，这是一家专门从事 OpenStack、OpenContrail 和 Kubernetes 管理服务的公司。Mirantis 将使用 TCP Cloud 的云架构持续交付技术来管理将在 Docker 容器中运行的 OpenContrail 控制面板。作为这项工作的一部分，Mirantis 也会一直致力于 OpenContrail。

OpenContrail 的许多贡献者正在与 Mirantis 紧密合作，他们特别注意了 Mirantis 将提供的支持计划。

“OpenContrail 是 OpenStack 社区中一个重要的项目，而 Mirantis 很好地容器化并提供商业支持。我们团队正在做的工作使 OpenContrail 能轻松地扩展并更新，并与 Mirantis OpenStack 的其余部分进行无缝滚动升级。 ” Mirantis 的工程师总监和 OpenContrail 咨询委员会主任 Jakub Pavlik 说：“商业支持也将使 Mirantis 能够使该项目与各种交换机兼容，从而为客户提供更多的硬件和软件选择。”

除了 OpenContrail 的商业支持外，我们很可能还会看到 Mirantis 为那些想要学习如何利用它的云管理员和开发人员提供的教育服务。Mirantis 已经以其 OpenStack 培训课程而闻名，并将 Ceph 纳入了培训课程中。

在 2016 年，SDN 种类快速演变，并且对许多部署 OpenStack 的组织也有意义。IDC 最近发布了 SDN 市场的一项研究，预计从 2014 年到 2020 年 SDN 市场的年均复合增长率为 53.9％，届时市场价值将达到 125 亿美元。此外，“Technology Trends 2016” 报告将 SDN 列为组织最佳的技术投资之一。

IDC 网络基础设施总裁 Rohit Mehra 说：“云计算和第三方平台推动了 SDN 的需求，它将在 2020 年代表一个价值超过 125 亿美元的市场。丝毫不用奇怪的是 SDN 的价值将越来越多地渗透到网络虚拟化软件和 SDN 应用中，包括虚拟化网络和安全服务。大型企业在数据中心中实现 SDN 的价值，但它们最终将会认识到其在横跨分支机构和校园网络的广域网中的广泛应用。”

同时，Linux 基金会最近宣布发布了其 2016 年度报告“开放云指导：当前趋势和开源项目”。第三份年度报告全面介绍了开放云计算，并包含一个关于 SDN 的部分。

Linux 基金会还提供了软件定义网络基础知识（LFS265），这是一个自定进度的 SDN 在线课程，另外作为 Open Daylight 项目的领导者，另一个重要的开源 SDN 平台正在迅速成长。

（题图：CC0 Pixabay）

via: https://www.linux.com/news/event/open-networking-summit/2017/2/opencontrail-essential-tool-openstack-ecosystem

作者：SAM DEAN 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出