第一章、引言

一直到近些年来，存储、计算和网络资源，这三者才被人为地从物理层和操作层上分离开来。即使是用来管理他们的系统，通常也要从物理层分离出来。与这些资源进行交互的所有应用程序（如操作监控系统）为了安全，都需要与访问策略、访问系统和访问过程保持严格的距离[1]。这种方法受到IT部门的喜爱。紧随着廉价算力、存储和网络资源而发展起来，数据机构们必须将这些资源整合到一起。

数据中心的设计初心是为将传统计算组件（如PC服务器）、他们的存储资源、以及与他们相联系的终端用户相分离。在各种各样类型的数据中心存在的计算资源往往就更专注于运行特定的功能性服务，如：邮箱服务器、数据库服务器以及现在广泛应用的桌面客户端（desktop clients）。从前，那些在大企业机构中运行的数以千计的电脑都是由部门服务器（department server）提供服务的，其支持范围也只专用于本地。随着时代的发展，部门服务器前移到了数据中心，有这么几个原因：首要原因就是便于管理，其次就是能够在企业中的各个用户之间能够共享数据。

这一有趣的变化大概是十年前左右发生的。VMware公司研发了一个有趣的科技，允许一台主机操作系统上运行一个或多个客户操作系统。VMware公司做的不过是创造了一个小型的程序，用来创建一个虚拟的环境，并把一个真实的计算机环境合成到这个虚拟环境中。该监控程序称为虚拟层（hypervisor）

最初的时候，VMware一开始是为了那些想在Linux上小不然地跑跑Windows的工程师预备的，他们跑Linux是常态，用Windows是形势所迫。用完了就像关一个普通的Windows程序窗口一样关掉，然后继续用他的Linux。这就产生了一种很有趣的现象：用户在对待客户端操作系统的时候，可以像对待一个拥有许多文件的大程序一样。拥有的这些文件可以像其他人和文件一样，移动或者复制。更有趣的是，客户端操作系统可以在主操作系统不知道的情况下自己暂停挂起，实际上也就是进入了一种“假死状态”（suspended animation）

随着操作系统虚拟化技术的来临，像MS Server之类的这些通常是单机运行、专门应用的服务器，以及那些专门为这些操作系统专门设计的应用程序，都可以被看作是一个无处不在的计算存储平台。随着内存大小、计算能力、存储空间的不断提升，数据中心的计算服务器能够越来越地胜任运在虚拟环境下运行各种操作系统的任务。VMware将他的单机版本扩展到一个对数据中心更加友好的版本，该版本能在一个主机上运行并控制成百上千个虚拟机。Windows Server这样的操作系统，之前占据一整个“裸机”(bare metal)，而现在被当做虚拟机运行，每一台上都按照客户需求运行着相应的程序。后者和前者的唯一区别就是，每个操作系统都在自己独立的环境中运行，可以被暂停、转存、克隆、复制（作为备份）。这一现象，开启了弹性计算（elastic computing）时代。

在弹性计算环境中，业务部门就能够通过简单地将虚拟机暂停后复制文件，来实现将服务器移动到数据中心的任何地方。他们甚至可以克隆一个文件然后简单地跑起来一个新的虚拟机，然后告诉管理程序将它当做一个新的实例跑起来。这一种灵活性就使得网络运营商开始对数据中心的资源进行优化，从而根据散热指标和功耗指标来优化资源利用率。通过将所有活动的机器统一运行，数据中心其他地方的机器就可以睡眠或者空转，进而运营商就可以将这部分地方的空调关掉，于是数据中心的制冷负载就被优化了。相似的，运营商可以根据不同地方的需求，移动或动态地扩展运算力、存储设备和网络资源。

作为一种新兴科技，这种新发现的灵活性在运营部署计算、存储和网络资源时产生
了新问题： 运营效率不仅要求存储和计算资源的使用率达到最高， 而且要求在电力和冷却方面也达到最优。如前所述,网络运营商开始意识到计算能力需求一般会随着时间的推移而增加。 为了满足计算需求， IT 部门（一般它们的预算会逐年递增）将根据预估，订购它们下一年所需要的所有设备。然而，一旦这个设备到达并放置在机架上，即使它尚未使用， 它也会消耗电力，增加冷却设备负载并占用空间。 这种窘境是在亚马逊（Amazon）的运营中初次出现的。当时，亚马逊的业务量是以“曲棍球棒”曲线图的模式增长——即每六到九个月，业务量便翻一番。 因此，为了保证零售订购业务， 股票， 仓库管理系统以及内部 IT 系统的正常运营，必须保证计算服务能力满足业务需求。亚马逊的 IT 部门为此被迫订购了大量的存储、网络和计算设备，但却面临着前面所讲进退两难的局面：这些设备为等待未来的业务需求而不得不闲置着。为了利用这个未使用的资源库，亚马逊推出了 Amazon Web Services（AWS），在商业化的运作下，使得这些未使用资源的利用率接近 100%。 当内部需要更多资源时， 以前的做法是将零售用户的服务请求推迟，但现在零售用户可以通过 AWS 使用那些未被利用的资源。 某些文献把这些称为弹性计算服务， 但本书将这称为超虚拟化（Hyper Virtualization）。

像亚马逊和 Rackspace 这样的大公司，为了其定价有效性（Pricing Efficiency） 购买了大量的存储和计算资源后， 发现他们没有有效地利用他们所有的计算和存储资源。因此，他们为了回收部分投资，会向外部用户转售其闲置的存储和计算资源。 这样，便产生了多租户数据中心（Multitenant Data Center）。多租户数据中心的诞生也带来了新问题， 要将成千上万潜在租户的资源需求划分开来，并将这些需求提交给不同数据中心的虚拟机来处理，把这些做好并不容易。以上所阐述的窘境还有另一层理解。 超虚拟化的环境一般由企业或组织运营， 也就是说，他们通常拥有并可以操作的所有计算资源和存储空间（包括某些租用的空间），就好像它们连接着大量虚拟或实际的机器和网络附加存储（Network Attached Storage.），但操作上却像一个单一且扁平的局域网（LAN） 一样。（除了在金融机构中，其监管部门规定某些部分要强制分离。） 然而， 这种情况的部门数量较少， 一般在 100 以下， 所以这些可以很容易由 OSI第 2 层或第 3 层的 MPLS 、 VPN 等工具解决。 在多数情况下，使用网络组件将所有的计算和存储资源连接到一点是相当容易的， 一般可以通过一个扁平的以太网，将所有的物理机器和
虚拟机器连接起来。 这类环境大多要为其同一网络（可能是与 IP 子网）上的所有设备（虚拟或物理） 分配 IP 地址， 使得拥有这些机器的企业用户可以对它们进行访问。 这也意味着，将虚拟机在企业内部的不同数据中心之间转移一般不会出现问题。 因为无论怎样移动，他们都处于在同一个路由域内， 虚拟机发送的数据可以到达域内任一目的地，与在物理上所处的位置无关。

在多租户数据中心中，计算、 存储和网络资源一般是被分割成彼此独立的部分后再提供用户。 实际上，保持各部分的独立性这一点是至关重要的。这带来了一些有趣的挑战，并且是在过去单一租户数据中心的环境下所没有的。 这种环境允许任意数量的操作系统及操作系统中的应用程序同时运行，但如果他的所有者或外部用户（如客户）要对其进行访问，则需要对每一台设备指定一个唯一的网络地址。在过去，地址可以从一个内部私有地址段内进行分配， 内部网络间的路由也是容易实现的；然而现在则需要指定一个可以从外部路由到达并访问的唯一地址。此外， 要考虑每个虚拟机有一个独特的 OSI 第二层地址（MAC 地址）的问题。当路由器转发一个数据包时，它最终会通过以太网（不仅仅只使用 IP 地址） 来递交数据包， 这通常不会有问题。 但虚拟机具有可迁移（VM mobility）的特点，当虚拟机因电力，冷却，或计算负载等原因要进行物理上的迁移时， 问题便出现了。 因为物理位置的改变意味着物理地址的改变。 为了确保先前发往该虚拟机所在的实际机器的数据包可以到达，需要改变第三层路由，使得数据包转向到虚拟机新的实际位置。

在数据中心不断发展的同时，网络设备却似乎在降低能耗和提高速度等方面停滞不前。也就是说，在以后交换阵列容量和接口速度会稳步增长，数据通信却并没有因为 IP ， MPLS和移动技术的出现而产生改进。 IP 和 MPLS 允许网络运营商在基础网络上进一步创建实体网络或虚拟网络，就像数据中心的运营商能在计算虚拟化出现后，在实体机器上创建并运行虚拟机一样。网络虚拟化通常被称为虚拟专用网络（Virtual Private Networks， VPN）。 VPN 包括多种类型，有点对点式 VPN（point-to-point）， 例如可以通过在笔记本上运行个人 VPN 连接到公司网络； 有三层的 VPN（Layer 3 VPNs）， 例如通过虚拟化的 IP 和网络路由，使网络运营商能够安全地承载其他企业在分离出的流量；还有二层的 VPN（Layer 2 VPNs），例如交换网络虚拟化，与三层的 VPN 类似，但使用的是以太网地址）。

商用路由器和交换机通常配备了管理接口，允许网络运营商配置和管理这些设备。管理界面多种多样，包括命令行接口， XML / NETCONF ，图形用户界面（GUI）和简单网络管理协议（SNMP）。 通样这样的方式提供接口，使运营商有适当的访问设备的能力，但这些设备仍然常常隐藏了最底层操作的细节。 例如，网络运营商可以设定静态路由表或其他静态转发表项，但这些最终都是通过向设备的操作系统发出请求来实现。 如果想使用设备内存在的语法语义及功能， 对设备重新进行编程则是不行的。 如果有人想在该设备上尝试一些新的路由协议也是不能实现的， 因为设备的固件中并未加入对该协议的支持。

与此同时， 分布控制层（Distributed Control Plane）（至少逻辑上）的概念也在现实中得到了应用。一个网络设备通常由数据层和控制层组成， 数据层通常是一个在设备上连接有各种网络接口的交换阵列， 控制层是设备的大脑。比如，过去用于构建无回路网络的路由协议现在常常应用在分布式场景中。 也就是说，在网络中的每一个设备有一个实现该协议的控制层。它们通过相互之间的通信共同建立了网络路径。 然而在中央控制层范例中， 只有一个单一的控制层（至少逻辑上） 存在。 这个控制层能够向每一个设备发出命令， 从而去控制它的物理线路交换和路由硬件。 现在有一点十分值得注意， 那些在数据层运行的设备功能比较单一， 并且价格也十分昂贵；而控制层的设备却着朝着便宜、功能通用的方向前进，比如英特尔公司生产的 CPU 就是个典型的例子。

所有上述提到的概念非常重要， 因为这些构成了软件定义网络（ Software Defined
Network, SDN）的运行核心。 早期的 SDN 支持者预见了网络设备供应商不会迎合他们的需求，尤其在功能开发和留有创新空间等方面。 高端的路由和交换设备被认为过高估了他们设备中的控制层组件的价值。 同时， 他们发现通用且灵活的计算力的价格正快速降低， 在一次处理过程中同时使用上千颗处理器进行运算已经可行。然后他们意识到这样的计算力或许可以用与逻辑中央控制层的运行， 甚至有可能用于廉价且有商业价值的交换设备。来自斯坦福大学的一群工程师发明了一项被称为 OpenFlow 的协议， 该协议能够在上述的硬件配置中使用。OpenFlow 是这样一种架构：只包含有大量数据层设备的网络，可以响应来自逻辑上的中央控制器（即抽象封装的单个控制层） 所发出的的命令。 该控制器负责控制所有网络路径， 同时可以它控制的每一个网络设备重新编程配置。在 OpenFlow 协议中， 这些命令和对这些命令的响应都有具体描述。 值得注意的是， 由于开放网络基金会（ONF） 对 SDN 的商业运作，使其成为制定标准时的权威和主要的市场组织者。 基于上述的基本架构， 我们能够想象在商品价格的硬件中， 可以快速并容易的去设计一个新的网络协议，并使它在数据中心中上线。
甚至可以在虚拟机灵活的计算环境中更好的得以实现。

与软件定义网络相对应，在业界对 SDN 有一种不同的见解，称之为软件驱动网络
（Software-Driven Networks）。 这样类似的文字并不是为了迷惑读者， 而是代表着在思维方式上的很大不同。 在软件驱动方法中， 有些观点认为 OpenFlow 及其架构作因功能的不同，作为目前网络的一个子集， 而不是将网络视为由非智能的网络设备和逻辑上的中央控制层组成。 这种观点认为世界像是旧的和新的东西的混合。 更具体地说， 本质上就是认为将已经存在的网络体系结构推翻， 以便为由开放网络基金会和软件定义网络提出的新世界让路这种做法是不切实际的。抛弃在如今网络技术中的所有优点也是不切实际的， 因为它们还在现在的互联网服务中发挥作用。 反而， 在部分网络中有很多混合方法被逻辑中央控制器所采用， 同时其它部分更多的有传统分布控制层来控制运行。 这也暗示着这两个种观念之间需要更深入的交流。

令人欣慰的是， 有一部分 SDN 和 OpenFlow 的主要支持者在努力使网络设备具有更好及更灵活的可编程性。 他们不关心网络控制层与数据层的位置， 但是他们关心如何对设备进行编程。 发明 SDN 和 OpenFlow 是为了解决如何在网络设备上灵活编程， 而不仅仅是哪里编程的问题。 在现有的 SDN 架构的描述中， 这些问题就都得到了解决。 现在的问题是使网络设备具有可编程性是否是最佳选择。

为了解决网络可编程性的问题， Juniper、 Cisco、 Leve3以及其它供应商和服务提供者牵头制定了路由系统接口（Interface to the Routing System， I2RS） 标准。这些公司中的许多人都曾致力于一些IETF标准的起草， Alia Atlas、 David Ward和Tom等人是最初的需求和框架制定的先驱。 在今后一段时间， 会有一大堆围绕该话题的草案在互联网上出现。 明显对这个方向的努力有很大的兴趣。 I2RS的基本的观点是发明一种使用快速路径协议对网络设备的路由信息库（Routing Information Base ， RIB） 进行编程的组件；再创立可以以快速直通的方式与RIB进行实时的交互的协议， 使RIB的管理器对其进行控制。先前， 仅能通过设备配备的系统对RIB进行访问（如Juniper、 Netconf或SNMP中的例子)。

要了解I2RS首先要知道它不仅是一个协议，而是一个包含了许多重要概念的完整解决方案， 需要对网络组件加速， 网络可编程性、 状态和数据的收集统计， 以及事后处理分析之间的反馈环路等整体性问题的处理。如今， 这个环路的优化相当缓慢。参与I2RS的人认为可编程网络未来的关键依赖于该环路的优化

为此， I2RS依照网络路径、 策略和端口配置的可编程性， 提供不同的抽象层次，但是在所有例子中， 它拥有人工监督的可编程性，意味着它有可以对所提交的命令进行检查的优势。比如， 如今一些协议是为在硬件抽象层（HAL） 编程而制定的， 这种协议为了提高网络效率，对编程要求颗粒度十分精细，细节也很多， 使得实际运行中操作系统的负载很大。另一个例子是业务支持系统（Operational Support Systems， OSS）应用程序，它可以以快速而最优的方式访问RIB， 以达到快速改变程序并得到结果的目的，只有通过快速重新编程的方式才能使最优化网络行为得以实现。 上述这些例子的一个关键方面是， 通过RIB管理器将应用程序和RIB联系起来。 这一点很重要，因为许多运营商在Junos或 IOS-XR等设备的操作系统中运行有智能化的路由选择协议， 它们希望保留这部分投资， 同时利用这种新的且高效的编程范式，在其他层面上优化他们的网络。

I2RS自身的特点也使其能很好的适应逻辑上的集中路由、 路径选择和可编程性的增长。该协议需要运行在一个设备上或者设备的外部。 在这种方式下，分布的控制器功能可以运用到有这种需求的实例中。 而且， 它可以很好地支持更多典型地分布控制的实例。

最终，另一个I2RS的关键子部件是标准化和抽象化拓扑结构， 定义一个常用的和可扩展的对象模型来代表这些拓扑结构。 这种服务还可以表多重抽象的拓扑（Multiple Abstractionsof Topological）。该模型的关键是非路由设备（nonrouters）能够容易地在运作时操纵和改变RIB状态。 现在， 非路由设备一个主要的问题在于如何以最佳方式获得这些信息。 对于今后的网络管理或者OSS、 分析， 或者其它应用程序，我们不能够预见他们可以通过路由状态和网络拓扑快速而有效地交互。

所以， 为了实现这些想法，我们需要恰当的定义SDN。笔者认为SDN的定义及未来的发展趋势如下：

软件定义网络（Software-defined networks, SDN）： 这是一种在实体或虚拟环境下，通过应用程序、网络设备及驱动间更加紧密的交互（如服务提供，消息和警报等），使网络得以优化和简化的架构方式。 这常常是通过逻辑上集中的网络控制达到的， 而这种控制通常是由SDN控制器实现的。 SDN控制器起到协调与介质的作用，使得应用程序可以与网络设备交互通信，网络设备也可以向应用程序提供数据。 控制器通过现代的，应用友好型的双向编程接口，对外提供抽象化的的网络功能和操作。

所以，正如所见到的，软件定义、 软件驱动和可编程网络是伴随着大量复杂的历史传承，挑战和各种问题的解决方案诞生的。 前面提到的软件定义网络、软件驱动网络以及可编程的网络这些技术的成功，使得先进技术可以在这些基础上得以实现。实际上世界上大多数网络，包括因特网， 都是在IP、 BGP、 MPLS和以太网这些技术的基础上运行。 如今的虚拟化技术以多年以前的VMware以及其他相关产品为基础。网络附加存储也有着同样丰富的历史。

如果能解决网络，计算和存储虚拟化的问题，以及这些资源的可编程性，可访问性， 定位和在超虚拟化环境下运行的应用程序位置迁移的问题， I2RS会有相当光明的未来。

SDN控制器从诞生起便一直是主流方式，当我们正在写这本书时， SDN的本身也产生了不少改进。一个非常有趣的例子便是Open Daylight项目。 Open Daylight的任务是促进以社区为主导，行业支持的开源框架， 包括代码和架构， 以加速和推进统一的，健壮的软件定义网络平台。Open Daylight是在Linux基金会的支持下建立起来的， 它是一个为了改变游戏规则以及潜在的致力于SDN控制器领域的发展而成立的项目。 笔者认为，这些努力很可能在应用这方面引发不少创新。 在过去的几年中， 我们已经看了在控制器方面的许多进展，控制器真正代表了SDN功能的应用的基础架构。 本着这一精神，在过去的几年里行业内一直在致力于设计和开发的控制器，而大多忽略了应用程序的改进。我们认为， 不过分的关注基础设施，而是使业内将重点放在SDN架构中应用程序和驱动层的创新上，这才是使SDN优化运行及提高效率的最佳途径。

这本书专注于包括软件定义、软件驱动以及可编程网络的网络方面，同时对虚拟化、定位、存储编程、 网络和计算类似方面给出了丰富全面的介绍。 这本书的目的是， 探索在网络、存储和计算超虚拟化环境下的网络技术的细节和运行机制， 这些技术作为SDN的一部分，正在不断推动着SDN前进。

（第一章完）