企业新闻
当前位置:企业新闻

简单分析软件定义网络SDN

来源:未知 时间:2017-03-23 11:11
 

   其实在今日SDN并不是一个「民生必需品」,因为多数的网络环境,没有它照样可以运行得很好。但是从热门的云端相关应用Infrastructure as a Service、Platform as a Service与Software as a Service等来看,可以发现一个共通点,那就是「Service」。

 
  以「服务」的角度驱动网络建构所需要的环境,并且根据实际网络需要的状态,提供程序化的服务策略及规模的需求,才是我们对于SDN的需要。
 
  这也是当前硬梆梆的网络概念所无法支持的「以服务驱动的网络基础架构」(Service Drives Network Infrastructure)观念。
 
  目前维运的网络是否真的需要这种投资。什么样的环境才会需要这种高灵活及弹性的网络?一定不是静态的服务器或是大型主机,因为这些设备就像大树一样屹立不摇,或许多年也不会有变动网络的需求。
 
  但是被高度虚拟化的服务器(Server Virtualization)可就完全不一样了,Hypervisor根据用户或是服务运行的状态被动地产生、删除、变更、搬移,越来越多应用的环境已经完全架构在服务器虚拟化之上,这对网络营运来说就是很大的负担,因为我们使用的网络概念就像工作了超过30年的老先生,已经跟不上这个跑在云端上的年轻小伙子所需要的弹性和速度。
 
  多租户云非SDN不可
 
  若问哪种网络环境一旦没有SDN就几乎无法顺利营运,目前看来,多租户的云端(Multi-Tenancy Cloud)环境会是首当其衝的痛苦者(Sufferer)。以下举几个例子,希望能帮助读者了解这个网络层面上的苦难。
 
  VLAN数量不足
 
  一个L2 Domain可用的VLAN数量至多支援4094个。如果用户使用4个VLAN,整个网络只可规划(provision)1000左右的用户,并需要建构新的L2 Domain继续提供服务,但是新旧的L2 Domain却无法合併运用,而且平均网络背板(Fabric)的运转效率可能达不到规模的30%。
 
  TCAM记忆体不足(Memory Overflow)
 
  一般机架交换机(ToR)仅需要服务20台左右规模的静态服务器,但在服务器虚拟化之后,即使保守以1:10的比例来看,服务器规模也会立刻成长10倍。
 
  加上以VLAN Trunk为基础的便利连结方式,每一个ToR因为VLAN Trunk所带来的ARP讯息更会呈等比级数增加,最终导致TCAM Overflow成为单点故障。可怕的是,这个问题在许多的除错过程(Troubleshooting)中不易察觉。
 
  服务可控度低
 
  前面提到以服务驱动基础架构的议题,在这裡更可以看出更明显的差异。以多租户的云端环境来看,每一个租户的服务需求各有不同,所以网络管理员几乎不可能以人力一一应对,用户更不可能为此等待数个小时。与时间赛跑的商业服务,需要以SDN这样的技术,建构具有高度弹性的基础建设,才能符合云端服务市场需求。
 
  本末倒置的迷思
 
  观察SDN议题在市场上被广泛讨论,其主轴往往围绕着OpenFlow这个协定,但OpenFlow真的是救世主方案吗?笔者很幸运在前几年加入Nicira公司(现为VMware网络及安全事业群),它是全世界第一个对OpenFlow进行产品化的商业公司,主要成员也是OpenFlow发源地史丹佛大学的早期开发团队。
 
  某次与发明OpenFlow概念的Nicira技术长Martin Casado对谈时,他说,OpenFlow只是一个协定,就像USB Disk所使用的USB协定一样,真正有价值的是USB Disk裡的资料,而非这个协定。
 
  其实如果读者理解前面所提到的「以服务驱动的架构」,到此应该可以理解,有价值的不是OpenFlow这个协定,而是透过它所建构的服务。所以SDN是不是民生必需品?未来不敢说,但至少今天可能是只有特定的服务型态,才需要它的支持。
 
  OpenFlow两大模式
 
  在现今OpenFlow发展中,存在着两个不同类型,一种是Hop by Hop模式,另外一种则是Overlay模式。
 
  Hop by Hop模式
 
  这是OpenFlow最早期的发展模式,Edge Device(OpenFlow交换器)将未知数据流的第一个数据封包发送给OpenFlow Controller作为路径演算的条件,如果一条路径需要经过5个Hop Count,这样的行为至少重复5次才能画出一条 Slice Topology,而OpenFlow Controller也就是坐落在Data Panel之上。
 
  在公开网络中,如果透过这种模式进行Topology的学习,OpenFlow Controller将承受极大的流量压力,成为最主要的瓶颈点。如果要预先载入Flow Table以解决学习的问题,先需要知道完整网络讯息以建立Slice Topology Flow,操作比传统网络更为复杂。
 
  Overlay模式
 
  这是OpenFlow逐渐发展之后所开发出来的新型运作模式,透过API直接对OpenFlow Controller定义需求网络Topology的型态,并且发送Flow更新至Edge(OpenFlow交换器),Edge便可以根据Flow定义结果,在本地建立IP Tunnel作为数据转发的桥樑。
 
 
  ▲Overlay模式透过API直接对OpenFlow Controller定义需求网络拓扑型态,并发送Flow更新至Edge (OpenFlow交换器),在本地建立IP Tunnel作为数据转发的桥梁。
 
  这个模式,因为OpenFlow Controller不坐落在Data Panel上,所以不会成为瓶颈点,并且透过IP Tunnel的模式,同时间也抽象化了物理网络,让由Overlay模式所建立的逻辑网络,不受限于传统L2网络边界或设备可达範围,只要是IP连线能到的地方,SDN Overlay Network就能存在。
 
  目前在市场上,硬体架构的OpenFlow交换器的厂商还是以Hop by Hop模式为主。如果是以Overlay的模式运作,Open vSwitch是广泛被应用的开放式交换器软体,多半是安装在服务虚拟化平台(Hypervisor)。 此运作模式是直接在内部连接虚拟服务器及网络,无须基于OpenFlow的硬体交换器就可达成SDN的需求,尤其对于多租户的云端环境来说,节省了特殊硬体成本的开销,也达成了服务驱动网络架构的目的。
 
  为何使用Tunnel协定
 
  近来市场上也有许多关于Tunnel协定的讨论,如VxLAN、NVGRE、GRE或是STT,主要的课题锁定在如何跨叁层网络延伸二层网络,且应用场景几乎都在高度虚拟化的资讯中心服务内,锁定的痛点也都说明现今网络的规模不足及简化网络的架构。这其实唿应了前文所提及规模化服务网络的需求,及根据服务驱动网络的概念。
 
  Tunnel技术解决了L2网络规模化的问题,但并没有完全命中简化复杂网络的需求。因为这个概念只涉及L2网络连线的建立,而没有满足更细节的网络服务需求,如QoS、MAC Spoofing、ACL或是Layer 3及更高层服务网络的建立。
 
  至于如何利用Tunnel传递更多的网络应用需求,便是OpenFlow Overlay架构的目标,而非建立规模很大但功能单纯的网络来面对用户复杂的需求。
 
  往往有人质疑Tunnel的封装会大量消耗操作系统CPU资源,但很幸运的是,今日许多晶片厂商已开发出x86系统上的卸载(Offload)机制,Tunnel协定本身更可以直接结合于核心(Kernel)之中,事实上在x86系统上,网络传输及同时降低CPU耗损的目标已经实现。
 
  SDN方案谁提供
 
  硬体网络技术已经非常成熟,产品差异变得越来越小,但服务需求的差异却越来越大。如前面所说,网络必须有能力去面对各种不同的动态需求的挑战,目前大致有几种类型的厂商能够提供相关服务:
 
  1.成熟的网络设备商
 
  这一类型的厂商是生产网络硬体设备为主,着重在效能及连接密度,为网络提供非常良好的传输媒介。这也是我们天天都在使用的网络设备。
 
  2.SDN元件商
 
  最重要的就是SDN Controller,毕竟Controller这个控制元件是SDN核心技术之所在。至于OpenFlow交换器,因为在功能上为接受者,所以虽然跟SDN的议题有相关,但毕竟不是主导元件,所以地位相对没有Controller的厂商来得重要,但也还是必要元件之一。
 
  3.网络抽象化(Abstraction)厂商
 
  几乎都是软体和晶片厂商的天下,重点在于把现有的IP网络建立成一个背板资源池(Network Fabric Pool),让用户的网络可以被任意部署,不需要再为L2网络的边界而伤脑筋,这也是让服务网络规模化的新选择,代表技术就是VxLAN、STT、GRE或NVGRE等等。
 
  4.网络虚拟化(Virtualization)解决方案商
 
  此类型厂商并非提供单一技术产品,而是全面性可以部署于生产环境的解决方案,包括了Controller、Edge Switch、Tunnel在同一方案之内,提供高度的网络效能、扩展性及灵活性。对于真正需要SDN网络的用户来说,这才是所需要的统合式网络能力,而不再是元件堆叠后的一座危楼网络基础建设。
 
  一个都不能少
 
  虽然受到业界的高度重视,但毕竟SDN自身无法变成一个独立有价值的东西,真正有价值的是服务。网络、服务器、储存的关係是密不可分的,但是谁来协调这些元件?在云端资讯中心裡,是由CMS(Cloud Management System)来扮演指挥者的角色,没有了它,大家只不过是一群「乌合之众」。
 
  因为服务不可能单独由网络所提供,服务器没有网络也无法传递服务,没有储存,重要的数据该何去何从?对云端资讯中心的运转而言,CMS是非常关键的工具,千万不要忘记这个指挥官。
 
  近期广受关注的OpenStack就是一个代表性的CMS平台,透过协同运作的力量,拥有包含了8000名以上的个人会员、82个国家的社群、150家以上硅谷及其他地区的IT商业公司共同参与,全球超过600名的共同开发者。当然此外VMware vCloud、CloudStack等平台,也都是这方面出色的CMS平台。
 

上一篇:新华三H3C部分XFP、SFP+、QSFP+、CFP光模块产品停止销售公告
下一篇:浅谈路由协定的分类与特性
   蜀ICP备2020034250号-1   川公网安备 51010802000119号

售前客服

售前客服

电话:028-83252151

传真:028-85259033

咨询热线:15378180513
在线客服