OpenDaylight 及开源软件网络的兴起

Presentation on theme: "OpenDaylight 及开源软件网络的兴起"— Presentation transcript:

1 OpenDaylight 及开源软件网络的兴起
Colin Dixon OpenDaylight 技术指导委员会主席 博科高级首席工程师 部分内容由 David Meyer、Neela Jaques 及 Kevin Woods 提供

2 摘要 网络及 SDN 的现状 开源（网络）概述 OpenDaylight 简介 哪些人在使用 OpenDaylight？为什么使用？
有待解决的研究问题

3 网络不能适应需求的变化 过去 20 年  快速变化的网络需求 相反，网络却未怎么变化
规模大幅度增加（终端设备数、交换机数、字节数和流量等） 静态终端（周–月）  动态终端（小时–天） 大多为北南向（north-south）流量  大部分为东西向（east-west）流量 相反，网络却未怎么变化 链路速度有所提高，但是 … 大多数情况下仍通过 CLI 逐个设备进行网络管理 如果您够幸运，能够以几台设备的粒度进行编排 We’ve been hearing all day that the world of IT is changing. The scale is increasing across nearly all dimensions and the needs are increasingly dynamic. By contrast the network hasn’t changed much

4 需要改变什么 逐设备  全网范围 开放标准  开放标准 + 开源 专用软件  开源 网络，存储和计算  融合 IT 硬件  软件
从很大程度上讲，这代表了开源网络的崛起

5 传统 SDN（OpenFlow） 控制和数据平面的隔离
安装表项目（table entry），发送数据包 SDN 控制器 当今的交换机 控制/数据平面均在交换机上 数据平面：速度快，读取转发表 项 控制平面：缓慢，写入转发表项 SDN 控制/数据平面隔离开来 数据平面在交换机上 控制平面在别处，如 x86 服务器 上，可以完成更重要的工作 0C->4 大多数功能特性 迁移到这里 控制平面 CPU 没有表格，发送到控制器上 变得更小，使控制器变为交换机芯片转换器（translator） dst 端口 0E 6 0A 1 0C 4 dst port 0E 6 dst port 0E 6 0A 1 交换机 芯片 0A->0E 0A->0E 0A->0C 端口，1-6

6 隔离（Disaggregation）和开源软件 保罗一切的现代化 SDN
逻辑上 集中部署的 SDN 控制器 北向 API 厂商 A 控制 管理 厂商 B 厂商 C 控制 管理 行业标准的 控制/管理协议 控制 管理 管理 管理 管理 标准 建模 语言 控制 控制 控制 厂商 A 厂商 B 厂商 C 逐设备操作 各厂商专用的垂直堆栈，用于控制、管理 和编排 独立的孤岛，有限的创新能力 全网范围的操作 开放的控制、管理和编排，使用开放控制协议/ 建模语言 每个堆栈层上的独立创新

7 开源

8 主要开源项目 OpenStack：整个 IT 行业的编排。 （提供网络服务的 Neutron 组件）[编排]
OpenDaylight：全行业范围的 SDN 控制器 [控制/管理平面] Open vSwitch：Linux 内核中的可编程软件 [数据平面] 其它：Open Network Linux、ONOS、CloudRouter、Quagga、 OVN、ONIE、Open Compute、Prescriptive Topology Manager、 SocketPlane、Weave、Akanda、MidoNet、OpenContrail

9 我的观点：这实际上比 SDN 技术本身更重要
Title Goes Here 11/30/2015 为何选择开源技术？ 避免厂商锁定 在市场上赢得一席之地 更快速的创新 可互操作性和集成 您会注意到我还没说成本 我的观点：这实际上比 SDN 技术本身更重要 简便易用性 成本 灵活性 开源 构建 购买 Define interfaces well In human-readable documents Define behavior with some ambiguity Usually move slowly Leave interoperability testing to others, e.g., users, integrators Sometimes provide open source implementations Define interfaces well In code Define behavior in code so it can be tested and understood Move and adapt quickly Can do interoperability testing as part of development Often implement open standards © 2015 博科通讯系统公司版权所有。保密信息-仅供内部使用

10 “简而言之，OpenDaylight是最开放的。”
在开源社区中定义“开放” 对于项目 对于产品 谁可做出贡献？ 谁正在做出贡献？ 如何做出决策？谁可以评论？ 谁可以投票？ 使用什么许可证？ 它能否与其它厂商的其它解决方案 相集成？ 是否具有 API？ 是否符合开放标准？ 是否基于开源组件？ 是否向上与开源项目相关？ “简而言之，OpenDaylight是最开放的。”

11 开源与开放标准 开放标准 开源 有效地定义接口 有效地定义接口 定义行为，有一定的含糊性 在代码中定义行为，确保可测试 而且易于理解
使用人类可读的文档 定义行为，有一定的含糊性 通常速度更慢 将互操作性测试工作留给他人， 如用户和集成商 有时候提供开源实施 开源 有效地定义接口 使用代码 在代码中定义行为，确保可测试 而且易于理解 可快速移动和修改 可在开发过程中进行互操作性测 试 通常实施开放标准

12 开源机会 生产环境中的 SDN 现在使用和研究人员和学者使用的相同的工 具 同时也有很多挑战 Linux 和其它例子中都是一样
有望带来重大的真实环境影响 同时也有很多挑战 具体的代码意味着真正的复杂性 使“上游”接受代码的难度很大 持续不断的贡献更有效但成本更高

13 OpenDaylight

14 什么是 OpenDaylight？ OpenDaylight 是 Linux Foundation 组织实施的一个 开源软件（Open Source Software） 项目，旨在通过创建一个全行业支持的通用平台来进一步推动 软件定义网络（SDN） 的普及和创新。 代码 普及 社区 创建一个强大、可扩展的开源代 码库，涵盖构建 SDN 解决方案所 需的主要常用组件 获得业内广大开发商和用户的广 泛接受: 直接或通过开发商产品使用 开发商在商用产品中使用 OpenDaylight 建立一个生机勃勃而且不断壮大 的技术社区，为开发代码库做贡 献，在商用产品中使用代码并全 方位增加价值。

15 OpenDaylight 的不同版本 Hydrogen（第 1 版） Helium （第 2 版） Lithium（最新版）
2014 年 2 月 13 个项目，130 万行代码 Helium （第 2 版） 2014 年 10 月 25 个项目，210 万行代码 Lithium（最新版） 2015 年 6 月 40 多个项目，230 万行代码

16 核心架构 集群中的控制器 应用/服务 应用/服务 模式驱动的服务 抽象层（MD-SAL） 通知 数据 RPCs 插件 插件 YANG 模型

17 OpenDaylight Lithium 架构

18 OpenDaylight 社区

19 OpenDaylight 社区 与所有开源项目一样，OpenDaylight 也主要由愿意脚踏实地做出贡献的 人员组成。
过去 12 个月中每周约 250 项提交，而且在不断增加 30 天：约 625 项提交，约 100 位贡献者 （7/13/15–8/12/15；在一个版本中） 后一个版本中迅速增加到了 2 倍 12 个月：约 13,250 项提交，约 365 位贡献者 （8/12/14–8/12/15） 强大的集成和测试社区 这一点至关重要 资料来源：

20 人们为什么用它？

21 哪些人在使用 OpenDaylight？为什么使用？
调查对象 31% 为电信公司/服务提供商 24% 为科研/学术机构 20% 为企业 10% 为服务/咨询公司 9% 为软件/硬件公司 6% 其它

22 生产环境应用 AT&T Telstra CERN/LHC 腾讯

23 网络虚拟化 单一 OpenStack Neutron 服务代理 选择适合您的实施方法 部署（具体说明请点击下面的链接查看）
完成大多数记录工作 选择适合您的实施方法 基于用户组的策略 LISP OVSDB VPN 服务（仅适用于 VPNaaS） VTN 部署（具体说明请点击下面的链接查看）

24 全网范围的安全策略 过去，策略大多 新的策略相关工作正改变这一局面 OpenDaylight 是至少 3 大面向策略的项目的试验场
由物理拓扑（如网关上的防火墙）以僵化的方式实施 通过逐设备的接入控制列表（ACL）“动态地”配置 新的策略相关工作正改变这一局面 网络功能虚拟化（NFV）和服务功能链（Service Function Chaining，SFC） 基于全网策略自动生成的 ACL OpenDaylight 是至少 3 大面向策略的项目的试验场 Service Function Chaining、Group-Based Policy 和 Network Intent Composition

25 可编程的 EMS 和/或 NMS 大量南向协议驱动因素 只需简单几步，您就可以为网络编写“Shell 脚本”，以收集信 息或自动完成各种任务
OpenFlow、NETCONF、OVSDB、SNMP、BGP、PCEP、PCMM/COPS 等 只需简单几步，您就可以为网络编写“Shell 脚本”，以收集信 息或自动完成各种任务 自动触发基于网络事件的活动，根据来自 IDS 的信息，采用 L2 ACL，实现主机的隔离

26 Title Goes Here 11/30/2015 分析师眼中的发展态势 “OpenDaylight 强势来袭，有望成为行业的中流砥柱。” – Andrew Lerner，Gartner “OpenDaylight 可能是第 3 大重心” “OpenDaylight 已成为网络堆栈的'Linux'：网络厂商和用户构建下一代产品和服务的基础。” – Kurt Marko，福布斯 实现软件定义网络（SDN）的开源方法，在这周又向成为事实标准的目标前进了几步。 – Mike Vizard，IT Business Edge © 2015 Brocade Communications Systems, Inc. CONFIDENTIAL—For Internal Use Only

27 参与方式 IRC：freenode 上的 #opendaylight：http://webchat.freenode.net/
邮件列表： Wiki： 文档： On github： Git/Gerrit： 创建帐户： 项目： 各页上都有链接到会议时间、代码、故障、IRC 频道等的链接 会议：

28 尚待解决的问题

29 如何实现目标 不是绿地（green field）环境时我们如何部署 可信赖性和稳定性 没有多少东西其实就是绿地
混合交换机、混合网络和传统协议，实现互操作性等 OpenDaylight 支持 SNMP、BGP、LISP、NETCONF 等 可信赖性和稳定性 当前的网络是利用 40 年前的代码/经验构建的 SDN 如何与之竞争？ 从传统代码中借鉴好的代码/理念 提供更出色的可视性和调试功能等 模型检查和验证等

30 集中式与分布式对比 （一致性、集群和联合（Federation））
SDN 有望提供一个（逻辑上）集中的控制平面 实际上，我们有一个分布式控制器集群，而不光是一台控制器，因 此可以： 容忍故障 扩展性能 网络分区中两侧都有控制器 提供一致性、联合（federation）、横向扩展和应对 CAP 折中（trade- off）等工作很困难

31 这实际上事关如何提供 可移植的抽象化功能 硬件多样性 OpenFlow 1.0 提供了最常用的 API
实际上硬件更为多样化 而且功能也多得多 应对这一多样性而不增加开发人员负担（不让他们逐个设备进行编程）很难 一些尝试 P4：编程协议独立的数据包处理器 （Programming Protocol-Independent Packet Processor） 来自 ONF 的 FAWG 的 TTPs Protocol Oblivious Forwarding（华为）

32 应用构成 我们如何让多种 SDN 应用共享网络？ 一些想法 PC OS 分区和分配资源 您不可能轻松完成网络分区
它的价值来自它涵盖一切这一事实 有时候您可以完成，如通过地址空间（FlowVisor） 一些想法 大多数应用应该是中间设备（middleboxes），即 NFV 以正确的顺序将他们连在一起 所要做的不限于此，但线性链（linear chaining）非常强大 其它应用只关心物理路径 人们希望这些冲突可以得到妥善解决