【跟我一起读】《云数据中心网络与SDN：技术架构与实现》

[one-time]

【管理员说-奖励设置】
参与奖：每周跟帖回复主题相关内容即可获得20积分
优质参与奖：每周优质回复内容可额外获得奖励50积分/条（上限200积分/周）
幸运奖：每周从优质参与奖获奖用户中随机抽取2人赠送50元京东E卡
领读者福利： 100元京东卡+500积分奖励（你也想成为领读者，为大家分享好书？立即私信联系管理员）

读书规划：

第一周：11月5日 – 11月11日，1-2章，云数据中心网络演进、杂谈SDN
第二周：11月12日 – 11月18日，3-4章，SDDCN概述、商用SDDCN解决方案
第三周：11月19日 – 11月25日，5-7章，开源SDDCN：OpenStack Neutron、OpenDaylight、ONOS相关项目的设计与实现
第四周：11月26日 – 12月2日，8-10章，学术界相关研究、番外：容器网络、异构网络与融合

我的心得及分享：

第一周
第1章作为背景知识，对云数据中心网络演进和技术进行介绍，由浅入深讲明SDN在云数据中心中应用的来龙去脉；第2章以杂谈的形式介绍了SDN的基本概念，紧紧围绕SDN的三大特点展开，让我们可以重新认识SDN、SDN与传统网络间的关系。
第二周
第3章中结合SDN在云数据中的应用，通过举例对SDDCN需求、实现的架构以及关键技术进行高度精炼的介绍；在第4章中收录了主流厂商和具有技术代表性创业公司的SDDCN产品，可以让大家了解这些方案内部的设计机制与技术细节，同时在本章中有很多笔者的个人观点供参考。
第三周
第5-7章分别对OpenStack Neutron、OpenDaylight和ONOS的设计架构以及SDDCN相关项目的核心代码实现进行了剖析，在实际部署中，大家可以有针对性地对相关设计机制进行二次开发。
第四周
第8章对学术界在相关领域的研究进展进行了介绍，包括与SDN相关的设计，也包括很多非SDN的设计，能够让我们拓展技术视野，并从中选择有实际意义的、可操作手指思科进行实现，启发大家的设计灵感；第9、10章番外篇，对于容器和融合等新型业务进行了概要性的介绍。

我的问题：

1. Segment Routing是什么？相比OpenFlow、OVSDB有什么优势？
2. 简述SDN的三大特征？
3. 云数据中心成为了SDN落地的主战场，主要得益于数据中心网络的哪些特征？
4. SDDCN有哪些关键技术？
5.Neutron OVS对租户三层流量的处理存在什么问题？有什么解决思路？
6. SFC中classifier的主要工作是什么？
7. 简述ONOS分层架构？
8. 在容器网络的基础中，容器有什么接入方式？
9. 为什么说存储在企业级网络和数据中心中都占有基础性的地位？
推荐理由：
SDN是未来的大方向，而云计算是SDN的主战场。本书垂直切入SDN在数据中心的应用，传统技术演进、商用与开源SDDCN方案，以及相关的学术论文等等，主流技术系统、全面覆盖。从多个角度对云数据中心技术进行讲解，对SDN在云数据中心网络中如何应用做了完整、详细的阐述，是一本相关从业者放在枕边的参考书籍。

内容简介：
全书讲解了4个方面的内容。1.对SDDCN的背景知识进行介绍，主要包括传统的数据中心网络和SDN，并对SDDCN的顶层设计进行概括性的介绍。2.对SDDCN的典型的商用、开源方案进行具体的分析，包括技术背景、架构设计以及各方案的横向测评。对于一些开源的SDDCN解决方案还会深入地剖析其代码实现。3.从学术界的角度出发，对SDDCN未来的发展方向进行展望。4.对与SDDCN的外延技术进行分析，如容器网络和数据平面技术等。
购书链接：
https://item.jd.com/12325486.html
http://product.dangdang.com/25243425.html

【管理员说-注意事项】
1. 禁止发表不当言论，不涉及政治、国家、党派等信息，禁止刷帖灌水行为，审核发现后将不能获得活动积分，对于在论坛中多次出现此行为者，将采取至少禁言一周的处罚。
2. 积分奖励在管理员审核通过后即刻发放，优质回复奖在活动结束发布获奖公告后进行发放。
3. 思科服务支持社区对本次活动有最终解释权。

【获奖公告11.19更新】【跟我一起读】《云数据中心网络与SDN：技术架构与实现》

[ilay]

7. 简述ONOS分层架构？
ONOS在架构设计上一直保持分层的结构，由中间层负责在应用和南向协议间进行适配，以屏蔽掉南向协议的差异性。ONOS架构中，从上到下分为APP、Core、Provides+Protocol三层。
APP层 为ONOS集成的一些应用，向上对控制器外部应用和管理员开放接口，向下调用Core层提供的接口来实现网络应用逻辑
Core层 负责收集底层网络状态，向上与APP层交互执行网络的逻辑，向下经Providers适配，通过Protocols对设备进行操作，在水平方向会在多个ONOS实例间进行状态同步或信息交互。（Core将APP与Protocols进行了隔离，它将南向协议中各异的网络资源抽象为通用的网络资源，使得APP开放无需关心底层网络接口特征，降低了app开发难度。）
Protocols层 是各类南向协议的实现，向上通过providers适配到Core层，向下对网络设备进行管理、控制。

[Rockyw]

6. SFC中classifier的主要工作是什么？
SFC中classifier的主要工作是识别网络流量。Classifier可以运行在任意设备上，并且一条SFC中可以有多个Classifier，通常情况下，Classifier存在于SFC的头结点。SFC Classifier还将给网络流量包加上SFC识别符。具体的说，它会在网络包里加上一个SFC Header，也就是说它会改变包的结构。这个Header包含一个SFC的唯一识别ID。

[Rockyw]

7. 简述ONOS分层架构？
ONOS的分层架构从上到下分为App、Core、Providers+Protocls三层。App层是ONOS集成的一些应用，向上通过RESTful API、GUI和CLI对控制器外部应用和管理员开放接口，向下调用 Core层提供的接口，以实现网络应用的逻辑。Core层负责收集底层网络的状态，向上与App层交互执行网络应用的逻辑，向下经Providers适配，通过Protocls对网络设备进行操作，水平方向会通过集群机制，在多个ONOS实例间进行状态的同步或者信息的交互。Protocls层是各类南向协议的实现，向上通过Providers适配到Core层，向下到网络设备进行管理或者控制。

[moxiuli]

5.Neutron OVS对租户三层流量的处理存在什么问题？有什么解决思路？
答：存在两个问题：(a)、路径上跳数太多增加了时延；(b)、vRouter会成为单点降低了可用性。
解决思路是：(1).部署多个网络节点，通过算法将三层流量在不通的vRouter间进行调度和负载均衡。不足之处在于实现复杂，难以同步路由状态；(2).在vRouter间通过VRRP来同步router状态。只是这样只能工作在准备模式，三层流量仍需要绕行到网络节点上进行处理。(3).把vRouter的功能分布在各个计算节点中实现。如此三层流量的通信路径可以得到最优的处理，分布式架构也消除了单点故障的问题。

[ni-weijian]

5.Neutron OVS对租户三层流量的处理存在什么问题？有什么解决思路？
Neutron OVS对租户三层流量的处理和传统网络三层流量的处理方式是一样的。经典设计，但存在问题，
1是路径上的跳数太多增加了时延，
2是vRouter会成为单点降低了可用性。
解决办法
1）部署多个网络节点，并通过算法将三层流量在不同的vRouter间进行调度和负载均衡，实现复杂而且路由的状态也很难同步。
2）在vRouter间通过VRRP来同步Router状态。不过只能工作在主备模式，而且三层流量仍然需要绕行到网络节点上进行处理。
3）把vRouter的功能分布在各个计算节点中实现。这种方式最优。

[moxiuli]

6. SFC中classifier的主要工作是什么？
答：SFC（服务链， Service Function Chain）中Classifier的主要工作是识别网络流量，并分发给不同的SFC。即：
1） 识别SFC流量： Classifier可以运行在任意设备上，并且一条SFC中可以有多个Classifier，通常Classifier存在于SFC的头结点，SFC Classifier将给网络流量包加上SFC识别符，即加上一个SFC Header，而这个Header包含一个SFC的唯一识别ID。由此来识别SFC流量。
2） 对SFC流量进行封装并送往 first SFF：Classifier是进入Service Chain的第一个点，Classifier映射Traffic进入Service Chain，并将Traffic封装到VXLAN-GPE-NSH tunnel中。

[moxiuli]

7. 简述ONOS分层架构？
答：ONOS是分层设计的，层次结构自上而下为：
Apps -- NB(Consumer) API -- Core(Device,Host,Link,Topology,Path,Flow,Intent,Network,…) -- SB(Provider) API -- Providers(Device,Host,Link,Flow) -- Protocols -- Network Elements
ONOS三层架构简述如下
• 底层Providers+Protocols：和网络交互的协议感知模块
• 中层Core：协议无关的系统Core，跟踪和服务网络状态信息
• 上层App：基于Core提供的系统信息来进行消费和操作的应用
面向网络的模块通过一个南向（提供者）API与Core进行交互，Core与应用程序通过北向（消费者）API进行交互。南向API定义了协议中立的手段将网络状态信息传递给核心，Core通过面向网络的模块与网络设备交互。北向API为应用程序提供了描述网络组件和属性的抽象，以便它们可以根据策略定义其所需的动作。Providers通过特定协议库与network对接，通过ProviderService接口与core对接，对协议感知（指定协议）的Providers负责通过各种控制和配置协议与网络环境交互，同时为core提供指定服务的感知数据。Providers也能够从其他子系统收集数据，并转换成指定服务的数据 ，一些Providers也可以通过Provider接口接受core的指令，并使用合适的协议将指令作用到网络。

[ni-weijian]

6. SFC中classifier的主要工作是什么？
SFC Classifier： 识别网络流量，并将其分配到不同的SFC。Classifier可以运行在任意设备上，并且一条SFC中可以有多个Classifier，通常情况下，Classifier存在于SFC的头结点。SFC Classifier还将给网络流量包加上SFC识别符。具体的说，它会在网络包里加上一个SFC Header，改变包的结构。这个Header包含一个SFC的唯一识别ID。
7. 简述ONOS分层架构？
一直保持分层架构，具有高可用性、可扩展以及性能良好等基本性能，并且还有强大的北向接口抽象层和南向接口。中间层负责在应用和南向协议间进行分配，以屏蔽掉南向协议的差异性。
ONOS的分层架构从上到下分为App、Core、Providers+Protocls三层。

[nyy123]

1 SFC是实现Networking Service的一种很灵活的方式。由云服务运营商提供各种各样的Service Function，由SDN管理SFC，将Service Function加入到网络流量路径中，即能实现Networking Service（L4-L7），Classifier主要作识别网络流量，并将其分配到不同的SFC。Classifier可以运行在任意设备上，并且一条SFC中可以有多个Classifier。
2.ONOS架构设计伊始就将服务提供商放在首位。可靠性强、灵活度高以及良好的性能都是最基本的要素，同时它还具有强大的北向接口和南向接口。
ONOS具有的核心功能主要包含：北向接口抽象层、分布式核心、南向接口抽象层、软件模块化。

[ni-weijian]

容器的接入6种方式：
1.和host共享network namespace
这种接入模式下，不会为容器创建网络协议栈，即容器没有独立于host的network namespace，但是容器的其他namespace（如IPC、PID、Mount等）还是和host的namespace独立的。
2.和host共享物理网卡
2与1的区别在于，容器和host共享物理网卡，但容器拥有独立于host的network namespace，容器有自己的MAC地址、IP地址、端口号。
3.和另外一个容器共享network namespace
容器没有独立的network namespace，但是以该方式新创建的容器将与一个已经存在的容器共享其network namespace（包括MAC、IP以及端口号等），网络角度上两者将作为一个整体对外提供服务，不过两个容器的其他namespace（如IPC、PID、Mount等）是彼此独立的。
4.Behind the POD
5.连接在的vbridge/vswitch上
最常见的方式，容器拥有独立的network namespace，通过veth-pair连接到vswitch上。这种方式对于网络来说是最为直接的，在vswitch看来，通过这种方式连接的容器与虚拟机并没有任何区别。
6.嵌套部署在VM中
这种方式也比较常见，在自己的虚拟机上运行容器。是一种嵌套虚拟化，这种方式下容器的接入对于host可以是完全透明的。

[ni-weijian]

存储提供了数据的管理，复制，快照，迁移，容灾等功能，存储的架构也影响整个系统的效率。
主要有3种， das 直连式存储，直接挂在服务器上。Nas，通过专门的文件服务器来提供文件服务，作为独立节点存在网络中。只提供文件形式的访问，不能提供对数据块的直接访问。 San提供来高速 block级别的数据操作，又提供了组网的可扩展性和灵活性。其中FC成为了san的核心技术。

[Mansur]

之前加班，上周没看书，今天补上：
5.Neutron OVS对租户三层流量的处理存在什么问题？有什么解决思路？
存在的问题：
1），路径上的跳数太多，增加了整体的实验
2），vRouter 会成为单点，降低了可用性。
解决思路：
1），部署多个网络节点，通过算法讲三层流量在不通节点间负载分担，不过这种方式较为复杂且路由状态很难同步。
2），在vRouter间运行VRRP来同步Router状态，不过只能工作在主备模式，流量还是需要绕行到网络节点处理。
3），吧vRouter的功能分布在各个计算节点中实现，这样，三层流量的通信路径可以得到最优处理，同时，这种分布式的架构也消除了单点故障。

[Mansur]

6. SFC中classifier的主要工作是什么？

识别网络流量，并将其分配到不同的SFC。Classifier可以运行在任意设备上，并且一条SFC中可以有多个Classifier，通常情况下，Classifier存在于SFC的头结点。SFC Classifier还将给网络流量包加上SFC识别符。


楼上好像有些说错sfc_driver的作用了

[Mansur]

7. 简述ONOS分层架构？
这张图是《ONOS白皮书》中的配图

这个架构，从上到下分别是App、core、Providers(Adapters)+Protocol的三层。
App层是ONOS集成的一些应用，向上面试控制器外部应用和管理员提供RESTful API, GUI和CLI开放接口；向下是Core提供的北向API，以实现网络应用的逻辑。
Core层负责收集底层网络的状态，向上与APP层交互执行网络应用的逻辑，向下经Adapter适配，通过Protocol对网络设备进行操作；水平方向会通过集群机制，在多个ONOS间进行状态同步或者信息的交互。
Protocol层是各类南向协议的实现，向上通过Adapter适配到Core层，向下到网络设备进行管理和控制。

[ilay]

8. 在容器网络的基础中，容器有什么接入方式？
在容器网络中大致有种接入方式
1、和host共享network namespace
在此接入模式下，容器的进程与host共用L2-L4网络资源，并不会为容器创建网络协议栈，容器没有独立于host的network namespace.但其他的namespace还是和host相独立的。
2、和host共享物理网卡
此接入模式下，容器有独立于host的network namespace，以及自己的MAC地址，IP地址，端口号。此接入方式主要使用了SR-IOV技术，为每个容器分配一个VF，直接通过硬件网卡与外界通信。
3、和另外一个容器共享network namespace
在这种方式中，新创建的容器会与一个已经存在的容器共享器network namespace，在网络角度上两者将作为一个整体对外提供服务，但每个容器没有独立的network namespace，不过其他的namespace是彼此独立的。
4、通过vSwitch/vRouter接入。
这种接入方式中，容器拥有独立的network namespace，通过veth-pair 连接到vSwitch/vRouter上。在vSwitch/vRouter来看，通过这种方式连接的容器与虚拟机没有任何区别，网络上是最直接的，并且vSwitch/vRouter能够提供多种高级功能的支持。
5、MACvlan / IPvlan
MACvlan将一个物理网卡虚拟成多个虚拟网卡分给不同的容器，流量到达物理网卡或者由虚拟网卡发出时，会判断目的MAC地址，如果属于本地容器，则直接发给相应的namespace，否则交由物理网卡处理。IPvlan接入的容器会复用物理网卡mac地址，并获得虚拟IP地址。
6、嵌套部署在VM中
这种方式下容器的接入对于host可以是完全透明的，该方式在生产环境比较常见。