波仔
☁️ 第四章 构建云服务的技术
📄 一句话概括

SDN（软件定义网络）做的事只有一件：把【决定包怎么走】这件事从每台设备里拿出来，集中到控制器上——设备从【既要想又要做】退化成【只管做】；所以真正变的不是速度（虽然配置 100 台从 50 小时降到 5 分钟），而是【谁说了算】：从几十台设备各自的局部规则，变成一张全局的图。

📝 本节和前面几节的关系

上一节（4-11）讲了 VLAN，它的两个天花板里有一个是：跨 VLAN 的策略要一台台设备去配。这一节就从这个天花板上接住。

它和前面讲的计算虚拟化（4-3）是同一个套路的两次应用：虚拟机化是把【硬件】抽象成软件可以操作的对象，SDN 是把【网络行为】抽象成软件可以操作的对象。 两件事合起来，才有【点一下就能开一套环境】这种能力——因为网络不再是【要人去配的设备】，而是【可以跟着一起被创建的资源】。

一、旧做法的问题在哪

传统网络里，每台设备（交换机、路由器、防火墙）都是自己决定、自己执行：

问题的根源不是【配得慢】，是【没有全局视图】：

麻烦 具体表现
一致性无法保证 漏配一台，就有一个漏洞，且很难发现
排障要逐台看 出问题时要把路径上的设备一台台查过去
变更风险高 每次改动都要考虑【会不会和别处的规则冲突】
没法按业务来 你知道的是【哪个口通哪个口】，而不是【哪些业务能互相访问】

最后一行是根本问题：业务的语言是【财务系统不能访问测试环境】，而设备听得懂的是【VLAN 20 到 VLAN 30 不通】——中间那层翻译，由人来完成，且每天都可能出错。

二、SDN 的答案：拆成三个平面

SDN 把网络拆成三层来看：

平面 传统网络 SDN
应用平面 没有这一层概念 业务策略写在应用里
控制平面 分散在每台设备里 集中到控制器，全局一张图
数据平面 设备自己转发 设备只按控制器给的规则转发

这个拆法的关键在中间那一层：把【决定怎么走】和【实际转发】分开。

于是【加一条业务策略】这件事变成了一次操作：在控制器上描述【财务不能访问测试】，由它算出需要在哪些设备上做什么改动，一次下发。

三、动手 Demo：同一条策略，两种下法

看到什么算成功：

==================================================================================================
【Demo 12】SDN：把【决定怎么走】这件事从设备里拿出来
==================================================================================================
  传统网络里，每台交换机自己决定包怎么转发，你想统一改一条策略，
  就得一台台登录上去改。

  场景：100 台交换机，要加一条【财务网段不能访问测试网段】的策略。

  做法                      单台耗时      100 台合计      风险
  --------------------------------------------------------------------------------------------
  人工逐台登录配置          30 分钟       50.0 小时       漏一台就是策略漏洞
  脚本批量下发              1 分钟        约 1.7 小时     脚本出错会一起错
  SDN 控制器统一下发        —             约 5 分钟       一次下发、一处留痕
  --------------------------------------------------------------------------------------------
  时间差 600 倍，但 SDN 真正改的不是速度，是【谁说了算】：

    平面            传统网络                  SDN
    --------------------------------------------------------------------------------
    应用平面        没有这一层概念            业务策略写在应用里
    控制平面        分散在每台设备里          集中到控制器，全局一张图
    数据平面        设备自己转发              设备只按控制器给的规则转发
    --------------------------------------------------------------------------------
  一句话：设备从【既要想又要做】变成【只管做】，想的事交给控制器。
  代价是控制器成了关键点——它挂了，全网改不动配置。

读结果：

30 秒实验

打开任意一家公有云控制台的【网络 ACL】或【安全组】页面（文档截图也行），做两件事：

  1. 看一条规则长什么样——它是【源、目的、端口、允许/拒绝】这种描述，还是【在某个交换机的某个口上做某事】这种描述？
  2. 看这条规则的作用范围——它作用在一台设备上，还是一个网络段上？

做完这个你会看到一件事：云上的网络配置几乎没有【设备】这个概念的痕迹——你描述的永远是【哪些东西之间能不能通】。这个变化就是 SDN 落到用户界面上之后的样子：设备被抽象掉了，你面对的是【策略】。

常见误区

  1. 错误：SDN 是一个具体产品，买了就能用。——纠正：SDN 是一套设计思路，实现方式有很多种。有的是云服务商自研的控制器，有的是开源方案，有的是设备厂商在自家产品上做的集中管理。它们的共同点只有【控制与转发分离】这一条。所以判断一个方案算不算 SDN，看的是这个结构，而不是它的名字。

  2. 错误：SDN 会让网络变快。——纠正：它不改变转发性能，改变的是管理性能。路还是那条路，包还是那么快——变快的是【改动一次网络要多久】和【出问题时能多快看清全貌】。把 SDN 当作性能优化会失望；把它当作可编程性和可观测性的提升才对。这一点和 IaaS 很像（2-7 里那句【IaaS 买的是机器能换，不是系统自动活着】是同一个道理）。

  3. 错误：控制器集中了，所以安全性更高了。——纠正：集中既是效率也是风险。效率来自【一次下发、全局一致】；风险来自【它一旦被攻破或配错，影响的是全网】——传统网络里配错一台只影响一台。所以 SDN 环境里，对控制器的权限管理、变更审计、配置回滚这些要求比传统网络更高，而不是更低。集中化从不减少责任，只是把责任挪到了一个地方。

  4. 错误：有了 SDN 就不需要懂网络了。——纠正：恰恰相反，它要求更高的抽象能力。传统网络里你是【照着拓扑配命令】，SDN 里你要先用业务语言描述清楚【谁该通、谁不该通】——描述错了，控制器会忠实地把错误策略下发到全网。工具把执行变简单了，但把【想清楚】这件事的责任还给了人——这和 4-8 讲【不可变基础架构要求你先想清环境的定义】是同一类问题。

自测三问（点开对答案） 1. 为什么说 SDN 真正改变的是【谁说了算】而不是【快了多少】？ —— 因为**速度提升是【全局视图】带来的副产品**。如果只是把命令下发自动化（比如写脚本），你得到的只是【快】，但**一致性仍然靠人保证**——脚本漏了一台，结果一样是漏。而 SDN 的前提是【控制器知道全网的构成】，所以它是**从全局状态推导出该改哪里**——**漏配这件事在结构上被消除了**。速度是这个结构的结果，不是它的本质。 2. 控制器成了关键点，这个风险该怎么处理？ —— 分两层。**第一层是控制器本身要高可用**（多副本、自动切换）——这是常规做法。**第二层更重要**：**让数据平面在控制平面不可用时仍能按已有规则继续转发**。因为业务真正依赖的是【包能不能过去】，而不是【能不能改配置】——**紧急时刻宁可【暂时改不了】也不能【突然全断】**。这个原则适用于所有【集中控制】的设计：**控制挂了要能降级运行，不能一起崩。** 3. 【用业务的语言描述网络】这件事，为什么比配命令更难？ —— 因为**业务语言的描述必须完整且无歧义**。说【财务不能访问测试】，那【财务能不能访问测试用的共享存储】【测试里的人能不能访问财务】这些边界情况，都要一条条想清楚——**而传统配置方式下，这些边界是自然存在的**（因为物理上就是分开的），不需要人明确说出来。**抽象程度越高，越要求把隐含的假设显式地写出来**——这是 SDN 真正的门槛。

相关笔记