SDN常见问题解析
来源：cnw.com.cn
摘要： SDN（软件定义网络）成为最近网络行业的当红炸子鸡，被众人瞩目。但是关于SDN的一切似乎都不太明晰，疑问在所难免。以下这些问题是否你也曾有疑惑，请看专家的解答。
Abstract：
Key words :
SDN（软件定义网络）成为最近网络行业的当红炸子鸡，被众人瞩目。但是关于SDN的一切似乎都不太明晰，疑问在所难免。以下这些问题是否你也曾有疑惑，请看专家的解答。
软件规划我们的网络已经很长时间了，SDN也与它们之间有什么不同?
确实，由分布式路由算法和管理协议等软件决定转发路径和设置网络设备参数已经很长时间了。尽管如此，这些工具被孤立于每个厂商的网络生态和专利之外。SDN有几个能够改变这种局面的重要理念：集中化控制、编程接口以及与编配/自动化工具整合。
为什么SDN比我们目前使用的传统网络要优秀?
SDN在多大程度上提升你的网络在很大程度上取决于你正在尝试解决哪些问题。通过在适当的地方部署适合的SDN解决方案，你能够让操作流程更为顺畅，减少人为错误，或是像公司独特指标所要求的那样用非常规方式转发流量。简而言之，它们可以让你获得更高的效率和更高的灵活性。
常见的使用案例是什么?
以下是两个目前企业中常见的SDN使用案例。第一个是帮助网络数据采集和网络可视化。在这个使用案例中，感兴趣的网络流量将按软件策略所定义那样被拷贝至采集器中。在采集器中，这些流量可以被分析和直观化。SDN控制器能够在整个网络基础设施中插入虚拟网卡，并将来自任何地方的流量拷贝发送到分析引擎所在地。
第二个案例为创新性转发。在这里，流量的转发将横跨一个工程化网络路径。这个工程化网络路径不同于OSPF 、BGP或MPLS等传统转发机制。常见的应用为专门处理对延时或抖动敏感的流量的应用。它们能够强迫所选择的流量通过监控设备以提高安全性，并且还能够根据费用选择路由。它们可根据时间段或是链路利用率让流量路由经过对于公司来说相比便宜的路径。
为什么开放网络基金会(ONF)采用一个封闭的方式运行，而不像IETF或IEEE一样?
创建ONF的部分初衷是为了促进OpenFlow协议的快速发展。OpenFlow协议是一个独立于厂商的协议。SDN控制器使用该协议为使用多种流量匹配条件和措施的网络交换机编制转发表单。速度将由一小组特定结果中既得利益成员控制。如果像IETF或IEEE那样以开放的方式运行，那么开发程序必然会被放缓，以便涵盖所有的成员、使用案例以及可能涉及到的问题。
目前已经出现了一些关于在某一节点开放ONF议程的讨论，以便让一些规模较大的网络社区可以对OpenFlow规范的讨论进行观察。
OpenFlow能否成为在网络中转发流量的新方式?
OpenFlow的前景目前还不确定。通过依托基于服务器的x86计算能力进行必需的处理，OF已被证明在虚拟层网络边缘运行的软交换机中非常有用。尽管如此，若在传统网络硬件交换机中部署OF，那么OF的优势将取决于交换机芯片的性能，以及芯片在使用案例中处理大规模OpenFlow操作的能力。
网络设计师在评估OpenFlow硬件时必须要仔细评估厂商，因为并不是所有的OF交换机性能都相差无几。OpenFlow最终将替代传统转发的另一个依据是，OF不必复制思科、瞻博和博通等ASIC(专用集成电路)设计公司芯片所具备的全部硬件功能。尽管这些厂商可能会支持OF作为一种充填转发表单和策略的附属手段，但是他们还是会大力推广他们自己的API，宣传这些API能够充分发挥他们硬件的性能。
由于流条目有限以及转出至控制器存在延时，有些人对OF的扩展性提出了质疑。这是真的吗?
带OF功能的网络交换机最大流条目低于10K是真的。这一限制取决于使用案例和整个网络设计。厂商指出，如果在网络边缘使用OF(与在核心使用OF截然相反)，几千条流条目不太可能会达到上限，而简化的内核(在这里边缘租户被覆盖层所遮盖)也能够取得成功。
当OpenFlow交换机的流条目与流量不匹配时，流量必须被转出至控制器。这会产生几十至几百毫秒的延时。此外，OpenFlow交换机CPU仅进行转出速度非常快，但通常转出操作被限制在每秒最多1000次。尽管在习惯以太字节级线速转发L2和L3流量的网络设计师看来这一速度非常缓慢，但是厂商指出在典型部署中，由于控制器知道端点，因此流表可通过流条目被预先充填。这样最大限度地降低了对转出的需求。
一个SDN控制器不是一个单点故障吗?
SDN的一个理念是集中化的控制器知道整个网络的拓扑，因而能够用多种方式替代网络，这点是分布式控制层所无法做到的。厂商已经认识到控制器的关键任务角色，常常会将控制器作为一个能够象聚合工具一样运行的分布式应用，或是作为一个能够利用虚拟层高可靠性的虚拟机。此外，它们会不出现如果控制器发生故障，网络也会跟着发生故障这种情况。虽然厂商会设计许多种架构，但是合理的设想是，即使控制器不存在，网络也将会继续转发流量(至少是一段时间内)。
我能够在现有网络旁边安装SDN吗?
是的。针对在扩建环境中部署的一个常见拓扑是“SDN孤岛”。在这个孤岛中，SDN域中的流量会通过网关设备流至遗留网络。另一个拓扑是混合交换，能够处理OpenFlow和传统网络的交换机会在两个域之间分配它们的端口。不同厂商会提供不同的混合功能。
覆盖层是什么?为什么会有如此多的不同种类?
覆盖层被用于创建虚拟网络容器。尽管共享同一个基础物理网络，但是这些虚拟网络容器在逻辑上彼此相互孤立。VXLAN(虚拟可扩展局域网)、使用通用路由封装的网络虚拟化(NVGRE)和无状态传输隧道(STT)等技术几乎是同时出现的。不同的厂商正在主导不同的技术。
用一句话概括，就是思科正在力推VXLAN，微软正在推动NVGRE，Nicira(目前已经被VMware收购)支持STT。每一个覆盖层都有一些相似的特点，但是在细节上存在区别，这使得它们彼此相似但又彼此不同。随着时间的推移，VXLAN已经获得了一些行业巨头的支持(有意思的是其中包括VMware)，但NVGRE和NVGRE还没有明确被放弃，两者目前仍然拥有支持者。此外，IETF NVO3工作组也正在致力于其它的覆盖层，其封装类型与现有的一种覆盖层相似。
为什么会有如此多的不同类型控制器?
早期上市销售SDN技术的厂商不得不将控制器作为整体解决这群的一部分。目前还没有SDN控制器标准出台。因此每家厂商都会推出满足他们目标市场需求的控制器。
出台获得行业认同的SDN控制器标准不好吗?
随着OpenDaylight 项目的设立，行业貌似也是这么考虑的。OpenDaylight是一个由行业内部为开源SDN贡献代码的厂商组成的联盟。时间将告诉我们SDN控制器标准将如何进入厂商产品当中，以及它们对SDN消费者意味着什么。
网络工程师必须要成为程序员吗?
熟悉脚本和编程的网络工程师将具备利用SDN技术的能力。他们必须要这么做吗?这还将有待观察。我所看到的场景是，厂商将向公司提供带有丰富网络功能的软件。部分工程师将使用这些软件接口配置网络，他们会对符合预期自己预期的网络功能感到满意。还有一部分工程师将使用厂商提供的软件，并精通创建业务所需的独特网络应用所要使用的语言。随着这些网络工程理由逐渐获得编程技能，他们将维持这种能力，以更为高效地监控和维护网络基础设施。
在评估SDN技术时，我应当考虑哪些关键性的东西?
需要搞清楚的一件最重要的事情是并不是所有的SDN解决方案都能解决相同的问题。此外，终端用户对不同的SDN技术有着不同的期望。尽管一些解决方案打算通过提供简单易用的解决方案过滤掉网络和操作的复杂性，但是还有一些解决方案正在提供带有更多工具的工具包，以便用户能够创建自己的应用。因此，搞清楚自己正在尝试解决的问题处于什么层次的技术水平非常重要。越详细地将自己的需求告之厂商，越清楚厂商的解决方案将如何满足自己的需求。
SDN是不是为我的环境带来了新的安全风险?
虽然很难说SDN带来了“新的”风险，但是事实表明通过编程接口暴露的网络设备存在管理风险。也就是，SNMP大致类似于可编程的API，不过它们拥有一个详细的风险消减策略。从在这个意义上说，SDN并没有带来新风险。是的，SDN会带来风险，但是IT部门已经通过访问控制、信任、加密、深层数据包检查等措施缓解了这些风险。
SDN倡导者指出，集中化控制的安全优势是减少了配置网络时所需的人手。对于IT基础设施来说，人为错误是最大的安全风险，SDN可能会被证明是它们实际上一种安全资产。
此内容为AET网站原创，未经授权禁止转载。