【探讨】什么是网络虚拟化和SDN？

分享一些文章给大家，带有下划线的都是一篇文章，可惜没有直接的链接，感兴趣的朋友直接复制粘帖标题到Google/Bing/Baidu搜下，很容易找到对应的文章：

InformationWeek Industry Report

Strategy Networking in a Virtualized World

Understanding Flat Networks

SR-IOV

What is SR-IOV?

I/O Virtualization (IOV) Revisited

Software/Virtual Switching

The Rising of Software Switching

The Great vSwitch Debate

Access Layer Virtualization

Access Layer Virtualization: VN-Tag and VEPA

Network Virtualization Overlay

IETF nvo3 Work Group

Understanding Layer 2 over Layer 3

Coding Relic: The Care and Feeding of VXLAN

Coding Relic: NVGRE Musings

Do We Really Need Stateless Transport?

SDN/OpenFlow

Software DefinedNetworking: The New Norm for Networks

SDN Standards: What and What Not

Network Management in Cloud

OpenStack Networking - Quantum

NV in CTO office / Labs China

Network Virtualization Overview

Network Virtualization - Dave Cohen - Teach the Research

网络虚拟化：正在进行的网络变革

虚拟化的逆袭：网络虚拟化之OpenFlow和SDN

存储网络虚拟化——曾经的北大荒，还是撒哈拉沙漠？

TekTalk （弯曲评论）

拨云见日：虚拟化的最后一公里–虚拟化网卡

下一代数据中心的虚拟接入技术–VN-Tag和VEPA

Open vSwitch – 开放虚拟交换标准

OpenFlow技术深入分析

Open Network Summit 2012参会随笔

业界动态

2013年异军突起的10家SDN初创网络公司

     NV的目标就是如何呈现一个完全的网络给云环境中的每一个租户，租户可能会要求使用任何其希望使用的IP地址段，任何拓扑，当然更不希望在迁移至公共云的情况下需要更改其原本的IP地址，因为这意味着停机。所以，客户希望有一个安全且完全隔离的网络环境，保证不会与其他租户产生冲突。既然vMotion之类的功能能够让虚拟机在云中自由在线漂移，那网络是否也能随之漂移呢？这里简单介绍下微软的Hyper-v networking virtualization，到不是因为技术有多先进，只不过他的实现细节比较公开，而其它公司的具体做法相对封闭，难以举例。

     其实微软的思路很简单，就是将原本虚拟机的二层Frame通过NVGRE再次封装到 IP packet中进行传输，使得交换机能够通过识别NVGRE的Key字段来判断数据包的最终目的地。这其实就是一个Network Overlay的做法，它将虚拟网络与物理网络进行了分离。试想，公司A和公司B都迁移到公有云且就那么巧，他们的一些虚拟机连接到了同一个物理交换机上，现在的问题是，他们各自的虚拟机原本使用的私有IP段是一样的，如果没有VLAN就会导致IP冲突。但现在看来，这已经不是问题，因为虚拟机之间的通信都要通过NVGRE的封装，而新的IP包在物理网络上传输时是走物理地址空间的，而物理地址空间是由云服务提供者所独占的，因此不存在IP冲突的情况。

     总结一下就是，这里的网络虚拟化可以认为是IP地址虚拟化，将虚拟网络的IP与物理网络完全分离，这样做就可以避免IP冲突，跨子网在线迁移虚拟机的问题，微软的要求是：虚拟机可以在数据中心中任意移动，而客户不会有任何感觉，这种移动能力带来了极大的灵活性。

注：不知何故上传的图片失真，有兴趣的朋友可以去微软官方看下：http://technet.microsoft.com/en-us/library/jj134174.aspx

     Nicira的成功不是偶然，他并不是一家突然冒出来的公司，早在05还是06年就有了Nicira的身影，虽然Martin Casado一再强调OpenFlow只是Nicira NVP的很小一部分，但确实因为OpenFlow的崛起，才使得网络虚拟化和SDN变得如此火爆，相继给Nicira带来如此大的价值。

     Nicira至今都没有公布关于其产品的太多细节，白皮书的描述也非常虚幻，不愧是做虚拟化的。。。。Nicira NVP之所以让我兴奋，是因为他们的确到了Bring everhting of Networking onto the Software. 我们的App将全部运行在VM上，而VM则全部连接在Virtual Switch，边缘设备完全被软件化了，更重要的是，这些Virtual Switch支持OpenFlow，使得整个网络架构支持SDN。想像一下，分布式集群控制器+软件交换机，完全OpenSource，这种开放性是否会像Linux一样蓬勃发展？我的理解是一定的。但我本人并不熟知NVP，Martin表示NVP（DVNI架构）在vSwitch之上重新构建了虚拟网络，提供一个完整的网络视图给每一个用户。这一点目前对于我来说，还是比较抽象，没有真正地拿个产品在手边去测试，相信很难理解。所以有兴趣的朋友可以从OpenStack Quantum项目，以及其他厂商的解决方案入手，比较他们在SDN/网络虚拟化上的实现区别，进而了解哪家在架构上更有优越性。就目前来看，Nicira对我有极大的吸引力，不仅是因为其本身的架构深度，也因为VMWawre的支持。

谢谢楼主的心血，信息量很大很大。

看不懂，先mark一下。

终于有同志回复了，感动啊！！二楼的信息量的确很大，我自己也没看几个。

网络虚拟化也是时代趋势了，现在从底层存储到前端应用，都在朝着虚拟化的方向发展。事实证明，确实实用。

是的，网络一直是云计算灵活性的一个绊脚石，因为缺少虚拟化，导致整个基础架构不够灵活，相应的App的灵活性受到限制，最终导致敏捷商务模型无法真正实现。所以，网络虚拟化是相对一块新的领域，值得研究。

恩,感兴趣的方向,研究一下..话说VMWARE也收购了了一个网络虚拟化的厂商Nicira

如果有Nicira的更多资料，不妨共享探讨一下。

本来是根本看不懂，不过这个例子有点引入门的感觉：“但虚拟机的网络依然死死地与物理设备耦合在一起，即便虚拟机从一个子网成功地迁移到另一个子网，但你依然需要改变其IP地址，而这一过程，必然会有停机。也就是说，要实现Full VM Migration，把IP地址与物理网络设备去耦（decouple）才行。这只是一个小小的例子，实际上还有很多问题是需要网络虚拟化来解决的，”

这个例子是IP Addressing decoupling，mac in mac、IP in IP等overlay技术都是具体实现，你有兴趣可以研究一下。

网络虚拟化又有新动向，特此更新：VMware NSX - 网络虚拟化平台

     VMware NSX是一个世界领先的网络和安全虚拟化平台，为虚拟机提供部署在普通IP网络硬件上、提供完整服务（full-service）、可编程以及可移动的虚拟网络。NSX将Nicira NVP和VMware vCloud Network and Security (vCNS)整合进一个统一的平台。NSX提供了一个简化的逻辑网络元素和服务的完整套件，包括逻辑交换机、路由器、防火墙、负载均衡器、VPN、QoS、监控以及安全，通过可编程API部署在任何提供隔离和多租户的拓扑、任何物理IP网络（ip network fabric）、可位于任何hypervisor内部、可连接任何外部网络、可用于任何云管理平台（例如，vCloud、Openstack、CloudStack）。

NSX聚集了五个基本组件：控制器集群、Hypervisor vSwitch、网关、生态系统合作伙伴、NSX管理器。

控制器集群 - 这是一组高可用的、可横向扩展的x86系统集群，负责以编程的方式跨越整个架构部署虚拟网络。控制器集群接收来自管理平台（例如，vCloud、OpenStack）的API请求，计算虚拟网络拓扑，主动编程hypervisor vswitch和网关，赋予适当的实时配置和转发状态。随着计算环境的动态变更，控制器集群更新必要的组件，使虚拟网络状态与虚拟计算状态保持在锁步（lock-step）状态。

NSX控制器集群提供一个逻辑上集中，但物理上分布的控制层。集群中的每一台x86机器共享所有所需工作量的等量部分，为任何丢失的集群节点提供即刻备份的容量（capacity）。当虚拟网络需要扩展时，可按需想集群添加节点。

NSX控制器集群对所有用NSX调配的网络服务和虚拟机都具有可见能力。有了这样的权威认知，NSX控制器集群能够抢先编程所有NSX组件，实现虚拟网络拓扑。NSX控制器集群完全是带外的（out-of-band），永远不处理数据包（data packet）。

====================================================================================

Hypervisor vSwitch - 每个hypervisor有一个高性能的in-kernel vswitch，带有可编程的L2-L4数据面以及配置数据库。NSX控制器集群编程每一个hypervisor vswitch，使其拥有一个实时的配置和转发状态来匹配所期望的虚拟机使用的虚拟网络拓扑。由于任何一个虚拟网络都可以跨多个hypervisor，控制器动态的在hypervisor之间编程IP封装隧道（STT和VXLAN），将虚拟机地址空间和虚拟网络与物理网络去耦，类似将虚拟机封装并从物理服务器中去耦。

API接口、智能横向扩展控制器、可横向扩展的内核L2-L4软件数据面以及隧道的组合，形成了基本构件，这些构件暴露了简单的L2-L4虚拟网络元素，可用为任何应用程序搭建任何拓扑。

除了简单的网络拓扑虚拟化，NSX还实现了新的、以前从未想过的网络安全虚拟化，例如将网络安全从IP寻址中去耦，通过一个高性能的完全分布式的、有状态的、可直接连接虚拟机的防火墙来实现的，能够引发丰富的一组高级别对象和上下文，远胜基本的TCP/IP头检查。

====================================================================================

网关 - NSX提供可横向扩展的网关服务，可将NSX内的虚拟网络连接到非虚拟主机、远程站点和外部网络。网关节点提供网关服务，实现与hypervisor同样的，由控制器集群管理的可编程vSwitch。

NSX网关服务提供一个进出软件定义的数据中心的安全路径，网关节点可以部署为Active/Active HA对，提供IP路由、MPLS、NAT、防火墙、VPN和负载均衡服务，用于保护和控制一个或多个NSX虚拟网络的north/south边缘的流量。

有些NSX内的应用程序可能需要连接数据中心内的非虚拟化主机上的服务，比如IP存储。对于这种需求，NSX提供了L2网关服务，专用L2网关节点的HA pair、或合作伙伴的ToR交换机，能够在NSX虚拟网络和物理VLAN之间做桥接。L2网关服务也能放置于远程站点，将远程VLAN与一个NSX虚拟网络桥接，用于将workload迁入\迁出云数据中心。

云管理平台通过到控制器集群的API请求定义了任何必要的L2或L3网关服务，计算拓扑并编程网关节点实现必要的隧道（VXLAN、STT）以及转发状态，从而将NSX虚拟网络附加到适当的网关服务。

注意：NSX为广播、多播和未知单播提供了智能复制（在隧道上）能力，在任何标准IP路由网络之上为NSX内的逻辑交换机提供了一个熟悉的L2服务模型，采用或不采用IP多播。NSX还能为扩展至远程站点的虚拟网络和隧道负载IPSec加密。

====================================================================================

生态系统合作伙伴 - NSX的核心是一个可扩展的平台，允许合作伙伴将他们的服务对NSX控制器进行注册，将服务分别无缝的插入虚拟网络。使用开放接口和开发协议使得生态系统合作伙伴能够通过使用广而熟之的、基于广泛使用的开放源软件接口简单的与NSX集成。同样，合作伙伴能够将L4-L7服务设备附加（attach）到NSX，使其成为虚拟网络可用的一种服务。

====================================================================================

NSX管理器 - 采用NSX控制器集群AI提供了一个基于WEB的、用户交互友好的GUI管理仪表板，用于系统安装、管理和排错。系统管理员可以查看所有NSX组件和虚拟网络元素（逻辑交换机、逻辑路由器、网关，等等）的日志以及连接状态。强大的排错工具能够在虚拟网络和底层物理IP网络之间实现映射。

就向虚拟机一样，NSX管理器可以为虚拟网络做完整快照，用于备份、还原、自省和归档。