PDF专用全球网络：谷歌转向 SDN
与 Amin Vahdat、David Clark 和 Jennifer Rexford 的讨论
关于谷歌的一切都是大规模的，当然——传奇般的市值，无与伦比的人才库，足以让律师大军一辈子穿 Gucci 的知识产权，哦，对了，还有一个比你能想象的还要大的私有 WAN（广域网），而且它的增长速度也大大超过了整个互联网。
不幸的是，越大并不总是越好，至少在网络方面是这样，因为伴随着巨大的规模而来的是巨大的成本、更大的管理挑战，以及传统解决方案可能无法胜任的认知。还有一点：专门的网络设备价格不菲。
总而言之，谷歌发现自己处于一条它认为不可持续的成本曲线上。更糟糕的是，它发现自己受制于少数几家网络设备供应商，这些供应商在交付公司要求的功能方面已被证明速度缓慢。这就是为什么谷歌最终决定应该更多地掌控自己的网络命运。毕竟，真正的大规模这时被证明是一项不错的资产，因为达到谷歌的规模意味着你可以独自颠覆市场。
所以这就是谷歌最终为摆脱其骨干网络所处的困境而采取行动的故事。剧透一下：SDN（软件定义网络）发挥了重要作用。谷歌网络技术主管 Amin Vahdat 帮助我们讲述了这一切是如何发生的。他既是一位杰出的工程师，也是一位谷歌院士。不知何故，他还能抽出时间在加州大学圣地亚哥分校和杜克大学任教。
Jennifer Rexford 是普林斯顿大学的计算机科学教授，以其在 SDN 方面的专业知识而闻名，她也参与了讨论，借鉴了她早期在 AT&T 骨干网络中部署的类 SDN 架构的设计工作，以及她最近在 SDN 控制器平台的新型编程抽象方面的研究。
最后，推动这次讨论的大部分问题都来自 David Clark，这位互联网先驱曾在 20 世纪 80 年代担任网络首席协议架构师。他还是麻省理工学院计算机科学与人工智能实验室的高级研究科学家，在那里他已经工作了近 45 年。
DAVID CLARK 我想知道人们是否充分认识到你们私有广域网的规模。
AMIN VAHDAT 可能没有。我认为我们的面向私有的 WAN 是世界上最大的 WAN 之一，其增长特性实际上超过了互联网。最近的一些外部测量表明，我们的骨干网承载的流量相当于全球互联网总流量的 10%。该流量的增长速度快于整个互联网。
这意味着构建、扩展和管理广域网的传统方法并没有完全针对谷歌的用例进行优化或定位。正因为如此，我们一直为私有 WAN 分配的资金，无论是在资本支出还是运营支出方面，都开始显得不可持续——这意味着我们真的需要转向不同的曲线。因此，我们开始寻找一种不同的架构，它能为我们提供不同的属性。
实际上，我们有很多独特的特征需要考虑。首先，我们基本上运行着两个独立的网络——一个面向公共的网络和一个面向私有的网络，后者连接着我们在全球各地的数据中心。面向私有的网络的增长率超过了面向公共的网络；然而，可用性要求并没有那么严格，而且需要支持的互连站点数量实际上相对较少。
在提出新架构方面，从流量工程的角度来看，我们很快得出结论，全局需求的集中视图将使我们能够比完全去中心化的协议更快地做出更好的决策。换句话说，考虑到我们控制着这个特定网络中的所有元素，从单个路由和交换元素的角度重建系统视图显然比从中心角度查看它们更困难。此外，集中视图可能在专用服务器上运行——可能在多台专用服务器上运行，每台服务器都比在传统交换机中运行的嵌入式处理器拥有更强的处理能力和更大的内存。因此，利用通用硬件的能力也成为我们的优先事项。这些考虑因素以及许多其他因素最终引导我们走向了 SDN 架构。
JENNIFER REXFORD 我想补充一点，SDN 提供了全网可见性、全网控制以及对网络流量的直接控制。这代表着与现有分布式控制平面工作方式的重大背离，后者迫使网络管理员哄骗网络按照他们的意愿行事。基本上，我认为谷歌和其他一些公司觉得 SDN 有吸引力的地方在于，能够从一个位置以全局网络视图更直接地影响策略。
DC 你们是什么时候开始关注这个的？
AV 我们在 2008 年开始考虑这个问题，最初的实施工作可能在 2009 年启动，最初的部署是在 2010 年。
DC 当您的工程师在 2008 年首次尝试解决这些问题时，他们发现 SDN 的哪些特性最吸引人？
AV 首先要说明的是，事后诸葛亮总是看起来更明智，我认为回答这个问题的最好方法是谈谈为什么我们当时对主流架构不满意。我们最大的挫败感是硬件和软件通常捆绑在一个平台上，这基本上让你受制于某些供应商，让他们想出你需要满足已经面临的要求的任何新功能。因此，如果我们从供应商那里购买硬件来处理我们的交换和路由，那么我们也将依赖该供应商来提供我们以后可能需要的任何新协议或软件功能。
这对我们来说是一个巨大的问题，因为我们已经在高端、专业的环境中工作，这需要专业的平台——这意味着极其昂贵的平台，因为大型供应商很自然地希望从他们有希望销售的相对较少的单元中收回他们大量的工程投资。
更重要的是，从供应商那里购买捆绑解决方案意味着购买该供应商的任何客户可能想要的所有功能，包括硬件和软件。在许多情况下，这对我们的用例来说是过度的。我应该补充一点，我们最初只希望为高容量但相对低价值的流量提供支持。这可能有助于解释为什么我们不想投资于完全防弹、坚如磐石的系统，这些系统提供最先进的容错、最精密的路由协议以及所有其他花哨的功能。随着时间的推移，当我们开始将更高价值的流量转移到网络时，这种情况发生了变化。尽管如此，我们的基本理念仍然是：在功能和管理方面，尽可能以最简单的方式添加必要的支持。
对我们来说，另一个大问题是，我们意识到去中心化协议不一定会给我们带来对网络的预测性和控制力，而当时这已经让我们感到不安，因为网络收敛到某种状态取决于已经跨网络和从一个链路到另一个链路发生的事件的排序——这意味着我们对系统最终会收敛到的最终状态几乎没有控制权。当然，我们无法达到“全局最优”，除此之外，我们甚至无法预测系统可能收敛到哪个局部最优。这使得网络规划变得更加困难。这也迫使我们过度配置的程度超过了我们的预期。请注意，我不认为这些考虑因素是谷歌独有的。
这里还有另一个我们非常熟悉的痛点——我相信 Dave 你对此会有很多看法——那就是，我们厌倦了在将新功能引入我们的基础设施方面受制于 IETF（互联网工程任务组）标准化流程。我们真正想要的是达到我们可以编写自己的软件的程度，这样我们就可以在我们需要的任何时候获得我们需要的功能。
JR 面向传输提供商的高端设备不仅具有可能比此特定网络所需更广泛的可靠性机制，而且还支持广泛的链路技术，以适应传输网络可能最终连接到的所有不同客户、对等方或提供商。这就是为什么你会发现其中的一切，从串行链路到 SONET 上的数据包。另一方面，谷歌的私有 WAN 更加同质化，这意味着实际上没有必要支持如此广泛的线路卡技术。此外，由于私有 WAN 无需与全球互联网通信，因此显然也不需要支持大型路由表。因此，由于各种原因，大型运营商可能希望购买的那些盒子显然不适合谷歌，无论是从线路卡多样性还是路由可扩展性的角度来看。
DC 我当然可以理解，购买商业高端路由器不符合成本效益。
AV 有趣的是，即使是思科和瞻博网络现在也越来越多地开始利用商用硅，至少对于他们的低端数据中心产品而言是这样。
DC 你们不是在构建自己的路由器吗？
AV 嗯，它们在某种意义上是路由器，因为它们提供外部 BGP（边界网关协议）对等互连，但它们永远不会被误认为是思科路由器。然而，我们发现，通过仅为我们需要的目的而构建，而无需支持曾经发明过的每一种协议，我们可以实现可观的成本节约。
DC 还有集中控制的问题。我的感觉是，有些人对 SDN 在这方面提供的功能有一种过于简单的看法，他们认为你有一堆路由器和一个集中式控制器，但你实际拥有的比这更复杂。事实上，据我所知，这个网络中存在一个控制层次结构，每个站点都有一个控制器。
AV 是的，没错。
DC 而且这也不是运行对等分布式算法。你获得了概念上的集中控制，但它是以相当复杂的方式实现的。因此，这提出了两个问题。首先，这种思维模式是否普遍符合 SDN 在实践中将涉及的复杂程度？另外，你们最终自己构建了多少？我的印象是，你们必须编写大量的控制器代码，这似乎是为了避免被标准所困而付出的相当大的代价。
AV 是的，我们构建了大量的基础设施，并编写了所有的软件。我们也与一些外部人员合作。但我想说的是，我们设法用一个中等规模的团队做到了这一点——不算小，但肯定不像一家主要供应商的软件团队。再说一遍，那是因为我们是为特定目的而构建我们的基础设施。
尽管如此，我还是同意这不是一个简单的系统。考虑到隔离故障域的需要，维护分层、多级控制所涉及的一些复杂性是固有的。我不会说 SDN 一定比现有架构更简单，但我确实认为它在实现快速演进、更高程度的专业化和更高的效率方面提供了一些明显的优势。
JR 尽管大家都在谈论这可能会走向何方，但我注意到，在您描述这个网络的 SIGCOMM 论文 [B4: Experience with a Globally Deployed Software-Defined WAN, 2013] 中，您还谈到了为将 IS-IS（中间系统到中间系统）和 BGP 纳入解决方案而付出的所有努力。这让我感到奇怪，因为 B4 网络内部或连接到 B4 网络的每个端点都在谷歌的控制之下——这意味着您显然可以选择不使用任何遗留协议。您认为保留它们有什么价值？
AV 这实际上是一个至关重要的决定，所以我很高兴你提到了它。经过深思熟虑，我们决定采用增量部署策略，当我们在撰写 SIGCOMM 论文时，我们希望为 ISP 强调这一点。
问题是：我们是想在某个特定的日子将我们所有的数据中心一次性切换到 SDN 吗？还是我们想一次切换一个数据中心，同时让所有其他站点看起来一切都和以前一样？所以你可以说我们最终投入了巨额资金来重新创建我们已经拥有的东西，只是使用了一个不太成熟的系统。这花了相当长的时间。
此外，在相当长的一段时间里，我们只部署了基线 SDN——没有任何流量工程——。基本上，在我们一次启动一个数据中心的 SDN 的整个时期内，情况都是如此。我仍然认为这是正确的方法，因为它给了我们一个获得 SDN 方面急需经验的机会。
所以，虽然我同意 BGP 和 IS-IS 不是我们长期希望的目标，但它们无疑为我们从非 SDN 网络过渡到 SDN 网络提供了至关重要的演进路径。
DC 您在这里提出了一些非常重要的观点。对于像康卡斯特这样的大型 ISP 来说，例如，一次做一个数据中心的等效做法可能是专注于一次只做一个都市区。但即使只是过渡一个都市区也已经足够复杂了，因此最好从增量方法来考虑，这样他们就可以始终退回到已知可行的东西，例如最短路径路由。
AV 哦，是的，我认为这至关重要。你真的需要拥有那种混合部署模型。事实上，即使现在我们仍然有一个红色大按钮，如果我们需要这样做，它可以让我们退回到最短路径路由。这甚至还没有考虑到向后兼容性等长期考虑因素。只是无论何时你部署像互联网或我们的私有 WAN 这样庞大而复杂的系统，采取混合方法都非常非常重要。
与任何开创性努力一样，谷歌向软件定义网络的迈进也伴随着许多风险——最值得注意的是可能破坏互联网长期以来的命运共享原则，以及其已建立的分布式共识机制。对于过去几十年受过教育的任何网络工程师来说，这应该足以敲响警钟，因为长期以来人们一直认为，任何可能导致大脑和身体独立失败的场景都可能很容易导致奇怪的失败模式，从中恢复可能极其困难。但是现在，在仔细重新审视当前的互联网格局之后，似乎这些风险实际上可以通过集中控制和一些巧妙的流量工程相结合来缓解。
DC 在推出网络时，您面临的最大风险是什么？
AV 可能最让我担心的是我们正在打破命运共享原则——也就是说，我们让自己处于这样一种境地，即控制器可能会在交换机不发生故障的情况下发生故障，或者交换机可能会在控制器不发生故障的情况下发生故障。这通常会导致分布式计算中的大问题，正如许多人在远程过程调用成为主导范例后痛苦地认识到的那样。
DC 我觉得你关于命运共享的评论有点可笑，因为当我们开始做互联网的时候，我们非常批评电话公司，因为它实际上没有一个好的动态路由系统。因此，它会用金箔包裹所有的技术，然后运行这些愚蠢、脆弱的路由器，这些路由器总是崩溃，因为基本上当时只能使用这些路由器。动态路由本应为我们提供网络弹性，我们需要这种弹性才能在运行这些糟糕的路由器的情况下生存下来。但我认为我们已经认识到，如果协议实际上被证明足够响应，能够让人们及时做出补偿性工程决策，那么动态路由可能是一个好主意。
然而，在路由的早期，我们不知道如何做到这一切。我们选择分布式协议的简单原因是它们是我们唯一知道如何构建的协议。我的意思是，打破命运共享的想法绝对让我们感到恐惧，因为我们知道网络中的分区可能会将控制器与需要管理的交换机分隔开来。
基本上，如果控制器失去了对网络的视图，那么就无法进入网络并将其重新组合起来。在那个年代，我们根本不知道如何处理这个问题。这让我们走上了原始互联网宗教信仰的道路，即如果我们有一种在某些东西发生故障后重建网络的策略，我们就不必让交换机变得极其强大，假设重建速度足够快且足够有效，能够让我们恢复必要的服务。
JR 我们还应该注意到，除了命运共享之外，SDN 还因打破分布式共识而受到批评，分布式共识是指路由器之间相互通信，以就网络状态的共同视图达成一致。无论如何，人们的看法是，分布式共识最终可能会被打破，因为一个或多个控制器可能会妨碍它。
但我只想说，我认为这两场战斗无论如何都已经输了——甚至在 SDN 变得特别突出之前。也就是说，我认为如果你仔细观察思科或瞻博网络的当前高端路由器，你会发现它们也采用了分布式系统架构，其中控制平面可能在与数据平面运行的刀片服务器不同的刀片服务器中运行。这意味着这些系统也受到这些相同问题的困扰，即大脑和身体可能会独立失败。
DC 来自旧时代的另一个担忧是，每当您必须依靠分布式协议从头开始重建网络时，您必须意识到，一旦您考虑到除连接性之外的任何其他因素，您最终可能会得到一个不完全符合您期望的网络。基本上，这是因为我们一直不擅长构建能够做任何超出简单地恢复最短路径连接的分布式协议。
一直以来都有这样的担忧，即故障知识绝对必须传播到控制器，以便控制器能够响应它。请注意，这种担忧与计划外的瞬时故障无关，我认为这恰恰表明我们对网络管理员实际上会面临的问题的预期有多么少。但是当你仔细想想时，计划外的瞬时故障的知识确实需要传播。让我们担心的一部分是，根据网络中事物发生故障的顺序，控制器可能最终无法看到所有已发生故障的事物，直到它真正开始修复事物为止。
当然，这可能会导致一些奇怪的故障模式，可能是由多个同时发生的故障引起的，或者仅仅是由于负责控制其他几个逻辑组件的组件丢失引起的——让您遇到巴尔的摩隧道火灾或类似情况，控制器必须一遍又一遍地构建网络，以获得修复网络并将其恢复到以前状态所需的拓扑信息。这是您现在运行的系统仍然面临的问题吗？
AV 像这样的故障模式正是我们试图解决的问题。正如您所说，最初的互联网协议完全专注于连接性，传统的经验法则是您需要将所有链路过度配置三倍，才能满足高可用性“网络结构”的要求。但是在这个特定网络的规模上，将所有配置乘以三根本不是一个可持续的模型。我们必须找到摆脱这种困境的方法。
DC 这让我们回到了需要实现更高的网络利用率。我发现真正有趣和与众不同的事情之一是，您如何设法利用流量工程来实现一些非常高的链路负载。我一直记在脑海里的是，通过识别流量类别，其中一些类别比其他类别更能容忍减速，然后采用一些流量工程和服务质量，您应该能够仅仅通过了解哪些流量可以减速来获得更高的链路负载。SDN 在多大程度上对于实现这一点是必要的？在此之前，谷歌似乎一直在使用 DiffServ 标记，所以我只是认为 DiffServ 标记可以用来通过确保对延迟敏感的流量不会中断来提高链路负载。流量工程在多大程度上依赖于转向 SDN 架构或至少 SDN 方法？
AV 这并不依赖于 SDN。在这方面，没有什么东西是无法通过其他方式实现的。我认为这真的归结为效率和迭代速度。我应该补充一点，你的假设绝对正确：DiffServ 确实可以用来提高链路负载。不过，我们主要关注的是故障，我们无法预测系统将如何收敛。因此，过度配置始终是为了保护对延迟敏感的流量——或者，如果你愿意的话，是产生收入的流量。基本上，为了让我们达到我们的 SLA（服务级别协议），这意味着在去中心化环境中过度配置以覆盖最坏情况下的收敛场景。然而，在转向集中式环境后，我们发现我们实际上可以预测在故障条件下事物将如何收敛，这意味着我们可以在整个全球网络中减少大量过度配置，同时仍然设法达到我们的 SLA。
JR 另外，您可以精确控制网络从一种配置过渡到另一种配置时所经历的中间阶段，而如果您让分布式协议来完成，那么关于哪个路由器最终先启动的所有赌注都无效了。
AV 完全正确。所以我认为，与稳态下的去中心化方案相比，我们通过集中式方案实现的改进总量实际上被证明是相对适度的——假设在最佳情况下改进了 10%，也许是 15%。更重要的是故障下的可预测性、分析故障条件的能力以及以可预测的方式将系统从一种状态过渡到另一种状态的手段——再次以允许保护对延迟敏感的流量的方式。这才是真正使我们有可能减少过度配置的原因。
JR 此外，如果您正在使用遗留协议，即使在您可以预测它们将要做什么的程度上，您用来进行预测的网络管理工具也基本上需要反转控制平面，以便您可以建模一旦以各种方式戳和戳它，它可能会做什么。但是，对于集中式网络，如果您想能够预测当您执行计划内维护或需要处理某些特定故障场景时会发生什么，您可以只运行控制器将要运行的完全相同的代码，这样您就可以确切地知道会发生什么。
AV 为了从某种角度来看待这个问题，我们真正设法完成的是奠定了一些重要的基础。也就是说，我认为我们仍然有很长的路要走，但流量工程是这段旅程中重要的早期一步。它推动了大量的资本支出节省，现在它也是一个架构，在此基础上，我们将能够更快地在软件控制下交付新功能——也就是说，我们将能够在我们的控制下交付该功能。我们将不再需要等待其他人向我们交付关键功能。在小型团队中工作，我们应该能够在短短几个月内在经过测试、可重现的环境中交付大量功能，然后在全球范围内推出该功能。最终，我认为这将是最大的胜利——而这的第一个证明就是流量工程。
当然，自主性的提高并不是唯一的胜利。显著提高的链路负载以及快速扩展以响应需求增长的能力是谷歌已经通过其私有骨干 WAN 实现的另外两个明显的优势。事实上，到目前为止，SDN 和集中式管理的经验已经足够令人鼓舞，以至于目前正在努力在改造谷歌面向公共的网络时采用大致相同的方法。然而，在那里将遇到的挑战预计会更大。
DC 直接切入主题，您认为通过采用 SDN，您设法实现的最大改进是什么？
AV 嗯，正如我们之前所说，通过集中式流量工程和服务质量区分的结合，我们设法区分了高价值流量和延迟敏感性远不如前者的大容量流量。这使得我们有可能以接近 100% 的利用率水平运行我们的许多链路。
DC 我认为这个评论很可能会引起一些关注。
AV 当然，我们在这个面向私有的 WAN 方面的经验并非完全是积极的。我们一路走来肯定遇到过挫折和挑战。但是，总的来说，它超出了我们最初的所有预期，并且它被用于我们最初认为不那么重要的流量的关键程度更高的流量方面，这超出了我们的预期。更重要的是，增长率非常可观——实际上比我们在面向公共的网络中经历的增长率还要大。
现在，考虑到我们必须在面向公共的网络上支持所有不同的协议复选框功能和线路卡，那里的成本结构甚至更糟，这就是为什么我们正在努力将相同的方法——不是完全相同的技术，而是通用方法——也推向我们面向公共的网络。这项工作已经在进行中，但这肯定将是一项长期的努力。
DC 面向公共的网络和私有网络之间您需要考虑的一些关键区别是什么？
AV 首先，正如您可以想象的那样，我们在面向公共的网络中有更多的对等点。我们的可用性要求也更高。我们必须支持的协议集更大。我们必须携带的路由表更大——当然，仅仅对于初学者来说，就超过了一百万个互联网前缀和数百万个来自我们对等方的不同通告。因此，基本上，当我们从私有网络转向公共网络时，站点的总数、流量交换的大小、与外部对等方通信所需的健壮性以及我们必须支持的接口类型都将发生重大变化。这意味着公共网络显然是一个更难的问题，但是鉴于我们从私有网络的经验中获得的理解，我想说，现在这项任务看起来远没有几年前那么令人生畏。
DC 这是否暗示大型运营商也需要进行类似的转型？
AV 我个人认为在这方面令人兴奋的是我称之为SDN 对等互连的可能性。BGP 对世界采取不信任的态度，但是如果各个 ISP——或者对等方，如果你愿意的话——决定他们至少希望有选择地动态开放一些关于他们网络的额外信息呢？天真地来看，我认为如果他们共享一些关于下游流量模式的信息，他们将能够使端到端传输时间更快，并基本上极大地改善用户体验。通过使 ISP 能够更好地利用他们负载较轻的路径，运营商自身也将受益。
JR 总的来说，当前的路由严格基于目的地，而不考虑应用程序的性质。因此，您可以想象，SDN 可能是让流量接收者向上游请求说“不，丢弃此流量”或“限制此流量的速率”或“以不同方式路由此流量，因为我可以告诉您一些关于到达我的最佳路径的信息，而上游方不知道”的好方法。同样，我可能会说，“嘿，我希望此视频流量采用此其他路径”，或“我希望它通过此其他盒子”，这同样是使用今天的基于目的地的转发难以实现的。
AV 我们已经与一些对基于 SDN 的对等互连感兴趣的客户进行了交谈，我可以告诉你，他们对特定于应用程序的对等互连特别感兴趣。他们希望能够说，“嘿，我希望我的视频流量通过这个对等方，而我的非视频流量通过这个其他对等方”，无论是出于性能还是定价原因。而这目前来说很难做到。
DC 我认为，一些关于不同技术如何能够在原本是对抗性利益之间实现双赢的证据，实际上将有助于澄清当前正在进行的一些业务对话。
JR 对于像康卡斯特或 AT&T 这样的 ISP 来说，如果他们决定转向 SDN，他们面临的挑战之一是，他们的终端节点比谷歌少得多。传输网络确实需要承载完整的路由，如果你愿意的话。此外，大型 ISP 的边缘路由器设备往往具有极大的异构性，而且他们也不会同时升级所有设备，因此其中一些设备可能已经有四五年甚至更久的历史。
因此，对于大型运营商来说，SDN 部署将比谷歌面临的挑战大得多。我仍然认为这是他们应该追求的有希望的方向，但由于各种实际原因，他们需要更长的时间才能实现目标。
DC 早些时候，您暗示了您认为 SDN 提供的流量工程优势。鉴于您的特定问题集，您能否详细介绍一下您希望解决的一些具体挑战，以便构建更具成本效益的网络？
AV 据我所知，网络管理方面的最先进水平仍然是登录到单个网络交换机，并通过 CLI（命令行界面）管理它们。这在人力成本方面扩展性非常差。当涉及到一个人在一个盒子上采取的某个操作可能会最终导致整个网络结构中的连锁反应时，它在人类需要跟踪的大量网络交互方面也扩展性非常差。
DC 对于没有真正生活在网络运营世界中的人来说，可能很难理解这实际上有多糟糕。人们仍然使用 CLI 对路由器进行编程的想法有点令人难以置信。而人们被期望找出如果他们在这里做一个小小的修复或在那里做另一个小小的修复可能会发生的全局后果的想法……这就像我们从未逃脱 20 世纪 80 年代一样！
我相信一些传统的网络工程师会为自己能够记住所有那些繁杂的知识而感到非常自豪。事实上，我猜想，对于转向更高级的管理工具，一定存在一些阻力，就像当年有些人拒绝使用高级编程语言一样——他们确信这样做会降低效率。但是当谈到 SDN 时，我听到您说的却恰恰相反——您实际上可以通过转向集中控制变得更加高效。
AV 是的，但变革总是会遇到一定的阻力。这里需要回答的一个基本问题是，关于网络的真相究竟存在于各个独立的设备中，还是存在于一个集中控制的基础设施中。对于一些网络运营商来说，要接受他们不应该再从各个独立的设备中寻找真相，这确实是一个巨大的转变。但这对于我们来说一直不是问题，因为我们很幸运能够在谷歌与一个才华横溢且包容的运营团队合作，他们非常愿意接受基于 SDN 的管理的挑战和陷阱。
转向 SDN 的另一个有趣的方面是，当事情出现故障，或者至少没有像您期望的那样工作时，除非您对控制器试图做什么有一个合理的心理模型，否则您可能会发现很难诊断问题所在。事实上，我认为现在网络运维人员在使用他们非常熟悉的这些协议时，他们的优势之一在于——尽管他们可能只有非常有限的视野，因此在诊断所有问题时会遇到困难——但至少他们有一个熟悉的心理模型，可以在尝试调试和诊断问题时作为参考。然而，对于 SDN 来说，每当出现问题时，一个最初没有参与编写软件的人可能会发现调试问题要困难得多。
DC 这引出了我现在听到很多人问的一个更大的问题：网络工程师是否需要接受计算机科学方面的培训？许多人目前还没有。虽然通过思科认证过程是一回事，但有人可能会认为，在 SDN 的世界里，人们可能需要提升一个层次，掌握更通用的计算机科学概念，尤其是那些与分布式系统相关的概念。
AV 我认为这可能是一个公平的评论。但我也认为有很多非常有才华的网络工程师，他们完全有能力适应新技术。
DC 话虽如此，我认为大多数网络工程师可能目前并没有做大量的软件开发。更可能的是，他们只是认为自己更多地扮演系统集成角色。在未来的某个时候，SDN 的倡导者可能会尝试提供足够的组件，以便那些拥有系统集成技能而不是编码技能的人更容易有效地使用 SDN。但我想知道，到那时，SDN 的复杂性是否会开始类似于您一直试图通过精简网络来摆脱的复杂性。也就是说，我想知道，编写自己的代码还是利用已经为您提供了大量附加功能的东西之间的权衡，在某种程度上是固有的——这意味着您将无法通过迁移到 SDN 来完全摆脱这种权衡。
AV 我会认为很多这种情况是由管理需求驱动的。我当然同意谷歌模式并不适用于所有人。我们能够在这项工作中取得成功的最大原因之一是我们有一个支持引入新的高风险功能的运营团队。
关于您提出的关于我们是否真的能够摆脱一些复杂性的问题，我当然希望如此。通过将网络管理的视角从以设备为中心转变为以 Fabric 为中心，我们应该能够使事情本质上更简单。然而，我认为这仍然是 SDN 最大的开放性问题：我们在简化运营管理方面究竟能取得多大的进展？
JR 我认为，SDN 最早的两个最引人注目的成功案例——即作为网络虚拟化的平台，以及我们在这里讨论的 WAN 部署工作——都是控制器平台以及在控制器之上运行的应用程序都高度集成并由同一批人开发的例子。如果 SDN 要在一个更广泛的背景下被证明是成功的——在一个您没有庞大的软件开发团队供您支配，也没有一个支持您的组织作为后盾的背景下——那将是因为有可重用的平台可用，以及在这些平台上构建应用程序的能力。
同样重要的是，您会希望相信许多应用程序可以来自平台创建者以外的其他方。我们实际上开始看到这个领域现在有很多创新，在许多不同的控制器平台上正在进行工作，人们开始考虑应该可以构建应用程序的抽象层。
但即使在那之前，SDN 也带来了一些东西，这些东西对于谷歌来说可能不是至关重要的，但在其他环境中可能会被证明是有用的。其中之一是，SDN 可以减少设备接口中的大量异构性。许多从事企业网络管理的公司雇佣了大量的开发人员，仅仅是为了构建设备驱动程序，以便在 CLI 级别与许多不同的交换机、路由器、防火墙等等进行通信，这意味着逐步转向更标准和开放的设备通信接口，应该会在很大程度上降低自动化管理的底层复杂性。
除此之外，我认为谷歌的设计表明，如果您可以将网络控制逻辑所需的分布式状态管理与网络控制逻辑本身分离，您可以避免重复发明如何进行可靠的分布式状态管理的轮子，同时也可以将它与每个单独的协议分离。基本上，对于我们设计的每个新协议，我们都在重新发明如何进行分布式状态管理。但事实证明，分布式系统社区已经有很多非常好的可重用解决方案。
DC 我从这里得到的一个理解是，并非谷歌在其私有 WAN 中所做的一切都能够轻易地转移到其他运营商的场景中。有很多充分的理由说明这种方法特别适合谷歌，无论是考虑到谷歌的具体需求，还是考虑到谷歌手头充裕的特定技能。此外，正如 Amin 指出的那样，谷歌的商业文化在遵循最初将弹性和可靠性置于稍微更大的风险之下的路径时，也更加宽容，这也有帮助。
JR 但我认为，一些相同的成本论证最终也将适用于大型运营商以及许多大型企业，因此这最终可能会成为至少一部分组织集体补贴开发一套合适的 SDN 产品的研发工作的动力，然后他们可以使用这些产品。否则，他们在购买和运营新网络设备方面的成本曲线可能会变得不可持续。
例如，如果您看看其他领域，例如蜂窝核心网，您会再次发现堆满了极其昂贵的设备的后台机房，这些设备通常非常脆弱。我认为您在企业中也会发现非常相似的情况。在这些环境中，变革显然会进行得更慢，因为它们面临着更困难的部署挑战、更严格的可靠性要求，甚至可能是一些更困难的扩展要求。我的意思是，我们看到 SDN 首先在数据中心和私有 WAN 中出现是有充分理由的。尽管如此，我认为资本支出 (CAPEX) 和运营支出 (OPEX) 最终将被证明在这些其他环境中也具有说服力。
AV 例如，如果您认为所有视频内容在不久的将来都不可避免地将在互联网上分发，那么我们肯定会看到惊人的网络增长，这表明大型运营商至少很快就会对抓住他们可能获得的任何资本支出和运营支出节省机会非常感兴趣。
最初发表于 Queue 杂志第 13 卷，第 8 期—
在 数字图书馆 中评论这篇文章
更多相关文章
David Collier-Brown - 你对带宽一窍不通
当您的员工或客户说他们的互联网性能很差时，带宽可能不是问题。一旦他们拥有 50 到 100 Mbps 范围内的带宽，问题就是延迟，即 ISP 的路由器处理他们的流量需要多长时间。如果您是一家 ISP 并且所有客户都讨厌您，请振作起来。现在这是一个可以解决的问题，这要归功于一群敬业的人，他们追查到了这个问题，解决了它，然后在家庭路由器中验证了他们的解决方案。
Geoffrey H. Cooper - 使用 FDO 和不可信安装程序模型的设备上线
设备的自动上线是处理正在安装的越来越多的“边缘”和物联网设备的重要技术。设备的上线与大多数设备管理功能不同，因为设备的信任从工厂和供应链转移到目标应用程序。为了加快自动上线的流程，供应链中的信任关系必须在设备中正式化，以允许自动化的转移。
Brian Eaton, Jeff Stewart, Jon Tedesco, N. Cihan Tas - 通过关键路径追踪进行分布式延迟分析
低延迟是许多谷歌应用程序（如搜索）的重要特性，延迟分析工具在维持大规模低延迟方面发挥着关键作用。对于包括不断发展功能和数据的服务的复杂分布式系统，保持整体延迟最小化是一项具有挑战性的任务。在大型、真实的分布式系统中，现有的工具（如 RPC 遥测、CPU 分析和分布式追踪）对于理解整个系统的子组件很有价值，但不足以在实践中执行端到端延迟分析。
David Crawshaw - 一切 VPN 焕然一新
VPN（虚拟专用网络）已经有 24 年的历史了。这个概念是为与我们今天所知的互联网截然不同的互联网而创建的。随着互联网的增长和变化，VPN 用户和应用程序也随之改变。在 2000 年代的互联网中，VPN 经历了一个尴尬的青春期，与其他广泛流行的抽象概念交互不佳。在过去的十年中，互联网再次发生了变化，这个新的互联网为 VPN 提供了新的用途。一种全新的协议 WireGuard 的开发，为构建这些新的 VPN 提供了技术基础。
© 保留所有权利。