一种基于SDN的跨域容器虚拟网络组建方法与流程

文档序号:14574586发布日期:2018-06-02 01:13阅读:153来源:国知局
一种基于SDN的跨域容器虚拟网络组建方法与流程
本发明涉及一种网络组建方法,尤其涉及一种基于SDN的跨域容器虚拟网络组建方法。
背景技术
:近几年,私有云和公有云得到了广泛部署和使用,但通常情况下,私有云数据中心规模有限,但安全性、性价比优于公有云;公有云由于面向公众提供服务,因此规模较大,且支持用户按需使用,按使用量支付费用。混合云提供了连通异构的公有云、私有云,提供跨域部署、跨域资源管理的能力,可在私有云资源不够用时,按需到公有云申请资源,结合了公有云和私有云两者的优势。当今计算机技术已进入以网络为中心的计算时期。SDN在近几年得到了大规模发展与应用,SoftwareDefinedNetwork软件定义网络,是网络虚拟化的一种实现方式,其核心技术OpenFlow通过将网络设备控制面与数据面分离开来,从而实现了网络流量的灵活控制。SDN要求遵循一定的通信协议,编写控制器程序来配置和动态管理网络。OpenFlow协议是最通用的SDN协议之一,大部分SDN设备对其兼容,包括虚拟交换机OpenVswitch和各种物理OpenFlow交换机。层叠网是指为构建逻辑网络连接,将一个逻辑网络叠加到另一个逻辑网络或物理网络上。层叠网内的节点通过虚拟链路连接,每条虚拟链路都被映射到底层网络的实际链路上,这段实际链路可能包含多个网络设备及物理线路。租户隔离:云计算用共享的基础设施支撑多租户的使用,不同租户之间需要进行有效隔离,在确保安全的同时避免不同租户相互影响。本专利面向基于OpenFlow虚拟交换机部署的混合云网络,其中包含使用Docker部署用户应用程序的混合云。Docker容器可以让开发者打包他们的应用以及依赖包到一个轻量级、可移植的容器中,也可以实现虚拟化。容器性能开销极低,因此支持快速、大量部署。同时,本专利提出的方法也适用于通过嵌套虚拟化封装的混合云服务。混合云中,用户应用程序部署在Docker容器里,具有以下优势:1.支持应用的跨域部署:当私有云资源余量足够时,优先使用私有云;当私有云资源不足或应用负载突然增加时,可动态将应用扩展到公有云上。2.支持应用跨域迁移:传统的虚拟机依赖于底层虚拟化平台的具体实现,不同虚拟化平台上运行的虚拟机无法灵活迁移。Docker不依赖底层虚拟化平台,因此结合现有的迁移技术,可实现用户应用跨域在线迁移,即在不影响上层应用的正常运行的前提下跨域迁移。现有技术中,Docker原生支持的网络配置由如下几种:(1)bridge(桥接)方式:通过网络地址转换方式实现跨主机通信,配置复杂,不利于大规模自动化部署,不利于进行租户间的容器隔离和访问控制;阻碍了部署在不同主机上的Docker容器的网络协同;不利于网络访问策略的实时更新等;(2)host(主机)方式:容器同样使用宿主机的ip地址等网络配置信息,通过主机IP+端口号的方式访问主机内部的资源,因此容器和主机网络之间没做隔离,安全性得不到保障。且存在与bridge方式相同的缺陷。(3)none(不配置):启动Docker容器时不进行网络配置,在容器运行之后开始配置网络,此种方式配置灵活但操作复杂。(4)overlay(层叠网)网络:在现有的网络架构之上构建不同主机容器间的二层虚拟网络,以实现多主机间的通信和调度,多用于规模比较大的容器集群环境。overlay(层叠网)网络的信息需要存储在K-V模式的数据库里,K-V对应了容器overlay(层叠网)网络地址和真实网络地址之间的映射关系。以上(1)、(2)种方式不适用于跨主机大规模Docker部署的情况,第(4)种方式支持跨主机部署,但灵活性不够,即网络管理和网络策略更新不够方便。同时,以上几种方案一般使用基于VLAN的租户隔离方式支持的租户数量较少,不能满足混合云场景下的大量租户、大量容器的隔离需求。技术实现要素:本发明提供一种基于SDN的跨域容器虚拟网络组建方法,为属于同一用户的跨域Docker容器集群提供虚拟二层网络连通,为属于不同用户的容器集群提供流量隔离。概括而言,主要包括:1.地址复用,在混合云中所有租户共享的网络基础设施上,运用网络虚拟化技术,向用户提供虚拟化的、地址可复用的网络抽象;二层连通,为满足应用内部的网络需求,提供基本的跨域虚拟网络功能;租户隔离,为分属于不同用户的Docker容器提供网络隔离。附图说明图1为本发明的第二层ovs执行流程图;图2为本发明的第一层ovs执行流程图;图3位本发明的跨域Docker容器的二层网络拓扑图。具体实施方式为了使本发明的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本发明进行进一步详细说明。应当理解,此处所描述的具体实施例仅仅用以解释本发明,并不用于限定本发明。此外,下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。本发明中示例的混合云的架构如图1所示,包含一个私有云和若干公有云,混合云能适配不同的公有云和私有云,允许跨多个云申请、伸缩规模,动态调整服务范围。用户应用是以Docker容器集群的形式部署,所有Docker容器均部署在虚拟机里。所有交换机均工作在OpenFlow模式下。本发明面向的混合云SDN网络均依托于OpenVswitch虚拟交换机部署,这样屏蔽了底层物理网络。底层物理网络即可以是传统TCP/IP网络,也可以是SDN网络。本文面向的部署模式为:容器均部署在虚拟机里,由混合云统一维护虚拟机资源。系统初始化时,混合云在每个接入的云里创建一台虚拟机。当用户数量和容器数量逐渐增加,某个云里虚拟机不够用时,混合云动态扩展出新的虚拟机;当某个云里一直没有虚拟机建立时,混合云动态缩减虚拟机的数量。在默认情况下,同一用户的容器优先部署在同一台虚拟机中;若必须跨主机部署,则优先部署在同一个云中;若用户需要跨域部署容器,则跨云部署。混合云默认同一用户的所有容器之间网络二层互通;不同用户之间所有容器之间网络二层不互通。在每台虚拟机里部署两个层级的ovs交换机,我们分别称之为第一层ovs和第二层ovs,第二层ovs挂载在第一层ovs的端口上。其中,第一层ovs负责虚拟机内部与虚拟机外部之间的通信,第二层ovs负责本ovs连接的Docker容器之间及其与第一层ovs之间的通信。Docker容器连接到第二层ovs上。特别地,每台虚拟机中的第一层ovs只有一个,第二层ovs可以有多个,最多16个。网络设备的MAC地址是用于网络二层寻址的设备地址,通常情况下,MAC地址是无意义的。由于MAC地址一共有12位16进制数字,表达能力极为丰富,因此,本发明具有拓扑信息编码结构,将MAC地址赋予以下结构。具体如下表所示。位次1-456-910-12编码内容主机id局部交换机id用户id局部容器id第1-4位是主机id,混合云里最多支持部署65536台虚拟机,本发明中将其简称为主机。在本发明相关联的混合云中,Docker容器均部署在虚拟机里,这四位MAC地址用来作为主机位置寻址的主要依据。第5位为局部交换机id,本发明中局部交换机指的是主机上的第二层ovs,第二层ovs承担类似桥梁的作用,负责连接Docker容器和第一层ovs。第6-9位为用户id,本发明中混合云支持的最大用户数为65546个用户,因此用4位16进制数id作为用户id。第10-12位为局部容器id,局部容器id用来区分连接在同一台第二层ovs上的不同Docker容器,这类容器最多可有4096个。由于单个第二层ovs的性能有限(流表数量及端口数量),因此总容量为4096的id完全够用;同时很显然可知,连接在不同第二层ovs上的Docker容器没有必要用id区分。本发明中,默认混合云里不同租户的容器相互之间网络二层不可达,这保证了不同租户的网络互相不干扰。本发明中,由于了租户之间二层网络在MAC层隔离,因此不同租户的容器的二层网络地址(即局域网ip地址)可以复用。我们默认为每个用户分配一个带16位掩码的局域网ip网段,此网段理论上最多可容纳65536台主机,去掉两个特殊地址,实际可容纳主机65534台。由于我们的租户隔离技术的应用,不同租户之间的此类网络互不可知。使用上述MAC地址编码方式,很容易便可以基于ovs设置高效的OpenFlow流表规则,并利用流表聚合,可以使用最少数量的流表支撑大量Docker的部署(类似于传统TCP/IP网络中的聚合路由)。系统初始化后,在每一台主机上,分别建立一个第一层ovs和一个第二层ovs,将网络初始化信息更新。由于每一台主机上只有一个第一层ovs,因此我们第一层ovs的MAC地址前1-4位即为主机id;在此基础上,第二层ovs前1-4位MAC地址与与其直接连接的第一层ovs的前1-4位MAC地址相同;在此基础上,分布在同一台主机的同一个局部交换机下的每个用户的每一台容器的MAC地址前1-5位与局部交换机相同,并且隶属于相同用户的容器的MAC地址的6-9位相同。没有用到的位被设置为“0”(这里的“位”是指二进制位)。当一个用户的Docker容器跨多个主机部署时,为支撑其网络通信,在其部署Docker容器时,同时为两个主机之间建立隧道,在不需要通信的主机之间,两两之间不建立隧道。特别地,主机之间的隧道建立在第一层ovs之间。建立隧道后,为第一层ovs下发使用隧道通信的流表,供主机互相之间互相通信时使用。在本发明的网络中,由第二层ovs作为接入交换机,提供Docker接入SDN网络的入口。其中,当一个数据报文从Docker容器中发出,到达接入交换机时,接入交换机根据混合云按照上表为其分配的MAC地址,将其原有MAC地址进行改写和替换。为了区分两个MAC地址,我们将混合云SDN网络使用到的MAC地址称为VMAC(VirtualMAC,虚拟MAC),将Docker容器本身具有的MAC地址称为PMAC(PhysicalMAC,物理MAC)。当Docker容器发出一个数据报文到达其直接相连的第二层ovs时,在本ovs执行PMAC到VMAC的改写;相反方向来的数据报文到达接入交换机时,进行相反的替换,即将VMAC替换为PMAC,然后发到Docker容器中。因此,本方法具有很强灵活性,因为可以确保用户不可知的情况下改写MAC地址,并使用MAC地址蕴含的信息进行路由。如图1所示为本发明的第二层ovs执行流程图,当第二层ovs收到一个报文时,①若是从Docker容器中发来的,则首先判断是否需进行网络隔离,即源地址和目的地址是否可达,将源地址和目的地址不可达的报文直接丢弃。对可达的报文,将其源PMAC替换为VMAC,并根据目的地址将此报文从合适的端口发送出去,若报文目的地址位于本二层ovs的其他端口,则将其目的MAC地址由PMAC替换为VMAC,并从相应端口发送出去;若报文目的地址位于其他位置,则直接发送至第一层ovs;否则,产生数据包进入事件并将报文发往控制器。②若报文是从第一层ovs发来的,则将其目的VMAC替换为PMAC,并根据流表查找其对应的Docker容器所在端口,从所在端口发出给容器,若没有匹配到合适的流表,则产生数据包进入事件并将报文交由控制器。若数据报文被通过第二层ovs与第一层ovs的接口发到第一层ovs,则由第一层ovs判断此报文是否是跨主机报文;若是跨主机报文,则从相应的隧道发出;否则,若目的地址为本主机其他二层ovs,则发至相应的接口;否则,若为访问Internet的报文,则将此报文发往物理网关,并由物理网关使用网络地址转换映射将其发出;否则,则产生数据包进入事件,发至控制器。如图2所示为本发明的第一层ovs执行流程图,当第一层ovs收到一个来自远程隧道端口或物理网关的报文时,此报文必然是发往本机某个Docker容器的,因此第一层ovs根据流表寻找目的Docker所在的第二层ovs所在端口,并发出。若没有合适的流表满足匹配要求,则产生数据包进入事件,将此报文交由控制器处理。本发明根据混合云的特点,估计了混合云中可能部署的虚拟机的最大数量、Docker容器的最大容量,混合云可能的用户的数量等,并依此设计了MAC地址转换方案。本发明提出的方法最多可支持65536(164)台跨域主机,65536个混合云用户(支持的用户数量即为支持的虚拟网络的数量),及理论上最多可容纳1612台容器部署在混合云的网络最大容量。最后应说明的是:以上实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。当前第1页1 2 3 
当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1