logo网站在线制作,文学网站做编辑,网页首页设计教程,emeinet亿玫网站建设vrrp
在一个网络中#xff0c;通常会使用vrrp技术来实现网关的高可用。 vrrp#xff0c;即Virtual Router Redundancy Protocol#xff0c;虚拟路由冗余协议。
应用场景
典型的如下面这个例子#xff1a;
当Router故障后#xff0c;将会导致HostA-C都无法连接外部的I…vrrp
在一个网络中通常会使用vrrp技术来实现网关的高可用。 vrrp即Virtual Router Redundancy Protocol虚拟路由冗余协议。
应用场景
典型的如下面这个例子
当Router故障后将会导致HostA-C都无法连接外部的Internet。
而引入VRRP技术后则可以解决Router单点故障问题引入VRRP技术后的拓扑如下
当某一路由器再次出现故障时其对应的Backup路由器将承担起原网关的功能。 主机和网关进行通信时使用虚拟路由器的vip(虚拟ip)和vmac(虚拟mac)进行通信。
在VRRP中需要关注的点有
VRRP使用虚拟ip和虚拟mac实现VRRP报文只有一种报文且使用组播发送为advertisement报文VRRP节点间使用定时机制选举出Master节点VRRP中有两个定时器分别为 ADVER_INTERVAL定时器由Master节点定时发送默认周期为1秒MASTER_DOWN定时器运行在Backup节点负责监听Master节点是否超时其周期为计算公式为 MASTER_DOWN (3*ADVER_INTERVAL)Skew_time(偏移时间)Skew_time256-Priority/256 节点成为Master节点后会主动发送免费ARP广播通告到它所连的设备和主机以更新设备和主机的ARP表
bfd
通过上面的介绍我们了解到在vrrp中故障监测周期为秒级如要达到更快速的监测周期可以使用bfd机制一起实现。
BFDBidirectional Forwarding Detection双向转发检测可实现毫秒级监测数据包使用UDP实现。
BFD包协议如下
BFD的会话建立机制分为静态建立与动态建立。
bfd检测模式 BFD检测模式分为两种
异步模式查询模式 一般使用异步模式如需要监测的设备较多担心且不怎么要求时效性就也可以考虑使用查询模式。
bfd单臂回声 bfd单臂回声也就是bfd中的echo功能。主要应用场景为两个直连的设备中仅一台支持bfd功能。
这种情况下要实现两台设备间的故障监测由支持BFD的设备发起回声请求不支持BFD的设备收到该报文后直接进行回包。
bfd的应用场景有很多在ospf节点、静态路由、VRRP等场景中得到了广泛的应用。
BFD包占用字节量较小一般为几十个字节通信时使用udp包进行传输。RFC规定单跳检测时目的端口为3784。多跳检测时目的端口为4784。
keepalived
通过前文的了解我们知道了vrrp可以实现节点的冗余备份再配合bfd可实现毫秒级的故障检测。 总结来说vrrpbfd是一个实用性很强的技术方案其使用虚拟ip和虚拟mac这种思想来实现高可用(HA)是十分有用的。
凭借vrrpbfd强大的特点许多大牛也将其运用到软件上其中最具代表的非keepalived莫属。
如keepalived官网所述那样keepalived是一款实现了vrrp和bfd的路由软件在负载均衡(loadbalancing )和高可用(high-availability)场景得到了广泛的应用而且还开源github上的星星和活跃度也挺不错的。
应用场景
keepalived实现HA的核心之一仍是VRRP实现了虚拟ip在主备节点中的漂移。以keepalived实现软件高可用的场景非常多比较经典的有keepalivednginx、keepalivedmysql、keepalivedredis。
keepalivedmysql 在mysql的高可用场景中mysql客户端直接使用keepalived的VIP地址连接mysqlServer。mysql节点间使用mysql自带的副本机制实现数据的同步当某个节点出现故障后mysql客户端便可实现mysql的连接自动转移。
这里需要注意的是在mysql的连接中client与server使用的是tcp长连接一个连接由4元组(4-tuple)构成即源IP地址、目的IP地址、源端口、目的端口。client端与server端断连后tcp连接也需要进行重连使用keepalived实现mysql长连上则需要确保配置了mysql的自动重连即url参数中的 autoReconnecttrue 或者使用mysql的数据库连接池间接与数据库进行连接。
keepalivednginx keepalived的另一个应用非常多的场景非keepalivednginx莫属。 如上图所示在两个nginx间配置keepalived用户流量最终通过vip访问到nginx一般会配置一个LVS流量让LVS转发到vipvip在两个nginx间漂移且始终位于nginx的master节点。详细配置方式这里不做展开此方案也非常成熟网上的资料也很多。
openflow交换机
通过上文我们了解到了在路由设备和软件设备间可以使用vrrp、bfd、keepalived实现HA。接下来再来了解下openflow交换机和控制器实现HA的一些知识。
openflow交换机——即实现了openflow协议的交换机如实现了openflow协议的ovs交换机。
openflow1.5.1协议文档http://sdn.ifmo.ru/Members/shkrebets/sdn_4115/sdn-library/openflow-switch-v1.5.1.pdf/view
会话建立过程
直接看一下openflow交换机与控制器建立连接的过程。
我们知道openflow交换机与控制器的通信好比是一个client/server通信这个过程免不了会话(session)的建立。
这个过程在openflow协议中可找到对应的描述描述片段如下 When an OpenFlow connection is first established, each side of the connection must immediately send an OFPT_HELLO message with the version field set to the highest OpenFlow switch protocol version supported by the sender After the switch and the controller have exchanged OFPT_HELLO messages and successfully negotiated a common version number, the connection setup is done and standard OpenFlow messages can be exchanged over the connection. One of the first things that the controller should do is to send a OFPT_FEATURES_REQUEST message to get the Datapath ID of the switch 上述内容转换为下图
主要为在tcp(6653或6633端口)建连后相互发送OFPT_HELLO包之后再由控制器向交换机发送OFPT_FEATURES_REQUEST包以获得交换机ID等信息。
Multiple Controllers
在协议文档中的OpenFlow Channel and Control Channel部分可以找到如下描述
The OpenFlow channel is the interface that connects each OpenFlow Logical Switch to an OpenFlow
controller. Through this interface, the controller configures and manages the switch, receives events
from the switch, and sends packets out the switch. The Control Channel of the switch may support
a single OpenFlow channel with a single controller, or multiple OpenFlow channels enabling multiple
controllers to share management of the switch.openflow channel是openflow交换机与控制器的通信接口交换机的控制通道(control channel)支持只和一个交换机的一个通道连接也支持多个通道实现交换机的多控制器多交换机连接。
协议文档中描述的Multiple Controllers即为openflow交换机连接多个控制器的场景。使用这种方式可以实现交换机和控制器间的高可用如某台控制器down掉后其他存活的控制器仍然可以操作openflow交换机。
为了避免脑裂问题一台交换机与控制器的关系有一个角色的概念即ROLE。 根据openflow协议的描述交换机与控制器的角色有以下几种类型
Equal对等关系意味着控制器可以完全访问交换机并和其他拥有Equal角色的控制器为平等关系可接收来自交换机的所有异步消息如pktIn、flow-removed消息Master主节点关系在访问控制权限部分和Equal一样都具有完全访问权限不同在于一个交换机仅有一个Master角色。Slave副节点关系仅具有对交换机的可读权限不能向交换机下发消息如flowMod、packetOut。此种模式下的控制器仅接收交换机的Port-status消息其他诸如pkt-in、flow-removed之类的异步消息都不会被接收到。
此部分更为详尽的说明也可查看openflow协议的官方文档。部分内容截图片段如下
Auxiliary Connections
在openflow协议的1.3版本以后新增了Auxiliary Connections的功能。
协议描述信息如下 In previous versions of the specification, the channel between the switch and the controller is exclusively made of a single TCP connection, which did not allow the exploitation of the parallelism available in most switch implementations. OpenFlow 1.3 enables a switch to create auxiliary connections to supplement the main connection between the switch and the controller (EXT-114). Auxiliary connections are mostly useful to carry packet-in and packet-out messages. Enable switch to create auxiliary connections to the controller.Enable switch to create auxiliary connections to the controller.Mandate that auxiliary connection can not exist when main connection is not alive.Add auxiliary-id to the protocol to disambiguate the type of connection.Enable auxiliary connection over UDP and DTLS.
openflow交换机除了和控制器保持单连接外还可与多个控制器连接实现辅助控制。使用多控制器控制同一个交换机在一定条件下可以提高处理性能也让多控制器的并性执行得到最大限度的发挥。
关于openflow交换机连接辅助控制器的示例可参考此链接 https://github.com/mininet/mininet/blob/master/examples/controllers.py
参考 http://sdn.ifmo.ru/Members/shkrebets/sdn_4115/sdn-library/openflow-switch-v1.5.1.pdf/view
https://github.com/opennetworkinglab/onos/blob/master/tools/dev/mininet/examples/multicluster.py
https://mp.weixin.qq.com/s/c6deR_QKIZmZbXj17q2sMA
