searchusermenu
  • 发布文章
  • 消息中心
点赞
收藏
评论
分享
原创

SDN、分布式

2022-12-29 07:02:30
68
0

SDN网络控制器分布式架构方案设计

关键词:SDN、分布式

  • 简介

SDN控制器的安全、性能与可扩展性一直是大家比较关注的,在这里和大家进行探讨一下,提供以下几种方案设计思路供大家参考。

  • 模块介绍

众所周知SDN领域中使用管理设备的协议主要包括openflow、ovsdb、netconf三种协议,其中openflow和ovsdb用于管理云虚机资源所在的宿主机,一般宿主机上安装开源或者自研的openvswitch,一般使用最多的是openflow协议,通过openflow协议的主动或是被动连接方式连接ovs建立openflow隧道,通过隧道对ovs进行下发openflow流表、meter表、group表等一系列配置用于对流量的规划,从而达到对宿主机上虚机资源的网络管理;netconf协议用于对其他网元(自研网关、白盒交换机、厂商交换机等)进行管理。

我们大体将控制器分为业务处理模块和协议模块,其中业务模块主要进行对业务进行处理配置拆分下发给协议模块,协议模块和设备进行连接建立隧道,将业务模块下发的配置通过隧道下发给设备,同时把设备上报的信息通知业务模块进行处理。其中业务模块和和协议模块放到一起也可以分开部署,由于协议模块的功能单一性以及需要隧道的长连接性我们把它们进行分开部署,以达到后续快速业务迭代优化的需要。

通过以上的描述我们就下面的图进行各个方案介绍。

方案一:

图一

该方案是一个简单的调用模型,业务模块接收北向rest请求,经过内部处理下发给协议模块,协议模块把请求翻译成相关类型报文通过和设备建立的隧道下发给设备。其中业务模块和协议模块的交互可以采用http类型的同步交互也可以采用异步消息类型。该方案局限性在于业务模块单一,无论在性能还是安全方面都有欠缺。

 

方案二:

图二

该方案在业务模块上方加一个nginx进行北向请求的分发,可以对业务模块进行横向扩展,提供吞吐,其中两个nginx之间加一个HA,达到nginx的安全性,如果后续还有更大需求,添加多对nginx,对外提供域名方案进一步增加能力。

协议模块可以采用主备和负载两种模式,如果管理设备是ovs,由于ovs流表的不依赖性则可以采用负载模式,即主备协议模块都和设备建立连接,且都可以对设备进行配置下发;如果设备是netconf管理,由于netconf配置的依赖性,需要对配置进行顺序下发,则需要采用主备模式,则主备都进行连接,但是只有主可以对设备进行配置下发,如果主挂掉后则备顶替主的位置对设备进行管理。其中主备等的集群选举操作可以引入zookeeper。

分布式架构中涉及的分布式锁大家可以采用redis或者zookeeper都可以,后续如果有机会可以给大家进行讲解openflow、ovsdb和netconf协议模块的开发、优化。

以上是我对SDN控制器分布式架构方案的一些个人见解,希望大家互相学习。

0条评论
0 / 1000
云杨
2文章数
0粉丝数
云杨
2 文章 | 0 粉丝
云杨
2文章数
0粉丝数
云杨
2 文章 | 0 粉丝
原创

SDN、分布式

2022-12-29 07:02:30
68
0

SDN网络控制器分布式架构方案设计

关键词:SDN、分布式

  • 简介

SDN控制器的安全、性能与可扩展性一直是大家比较关注的,在这里和大家进行探讨一下,提供以下几种方案设计思路供大家参考。

  • 模块介绍

众所周知SDN领域中使用管理设备的协议主要包括openflow、ovsdb、netconf三种协议,其中openflow和ovsdb用于管理云虚机资源所在的宿主机,一般宿主机上安装开源或者自研的openvswitch,一般使用最多的是openflow协议,通过openflow协议的主动或是被动连接方式连接ovs建立openflow隧道,通过隧道对ovs进行下发openflow流表、meter表、group表等一系列配置用于对流量的规划,从而达到对宿主机上虚机资源的网络管理;netconf协议用于对其他网元(自研网关、白盒交换机、厂商交换机等)进行管理。

我们大体将控制器分为业务处理模块和协议模块,其中业务模块主要进行对业务进行处理配置拆分下发给协议模块,协议模块和设备进行连接建立隧道,将业务模块下发的配置通过隧道下发给设备,同时把设备上报的信息通知业务模块进行处理。其中业务模块和和协议模块放到一起也可以分开部署,由于协议模块的功能单一性以及需要隧道的长连接性我们把它们进行分开部署,以达到后续快速业务迭代优化的需要。

通过以上的描述我们就下面的图进行各个方案介绍。

方案一:

图一

该方案是一个简单的调用模型,业务模块接收北向rest请求,经过内部处理下发给协议模块,协议模块把请求翻译成相关类型报文通过和设备建立的隧道下发给设备。其中业务模块和协议模块的交互可以采用http类型的同步交互也可以采用异步消息类型。该方案局限性在于业务模块单一,无论在性能还是安全方面都有欠缺。

 

方案二:

图二

该方案在业务模块上方加一个nginx进行北向请求的分发,可以对业务模块进行横向扩展,提供吞吐,其中两个nginx之间加一个HA,达到nginx的安全性,如果后续还有更大需求,添加多对nginx,对外提供域名方案进一步增加能力。

协议模块可以采用主备和负载两种模式,如果管理设备是ovs,由于ovs流表的不依赖性则可以采用负载模式,即主备协议模块都和设备建立连接,且都可以对设备进行配置下发;如果设备是netconf管理,由于netconf配置的依赖性,需要对配置进行顺序下发,则需要采用主备模式,则主备都进行连接,但是只有主可以对设备进行配置下发,如果主挂掉后则备顶替主的位置对设备进行管理。其中主备等的集群选举操作可以引入zookeeper。

分布式架构中涉及的分布式锁大家可以采用redis或者zookeeper都可以,后续如果有机会可以给大家进行讲解openflow、ovsdb和netconf协议模块的开发、优化。

以上是我对SDN控制器分布式架构方案的一些个人见解,希望大家互相学习。

文章来自个人专栏
SDN控制器
2 文章 | 2 订阅
0条评论
0 / 1000
请输入你的评论
0
0