标签:帮助 libtool 启动 das 并且 开机 模块 dep director
参照官网,也查了些资料,编译期间出现些问题,先将正确的流程及问题解决方法记录如下。
正式开始。
获取代码(2.9为例,其他版本可参考官网)
wget 下载
1
|
|
Git 下载
1
|
|
编译环境配置
除此之外,如果需要Linux kernel支持的话,还需要打开以下开关(无需内核支持可参考Open vSwitch without Kernel Support )。
受支持的内核版本。
Ingress policing的支持,需要以嵌入或模块形式打开 NET_CLS_BASIC
、 NET_SCH_INGRESS
和 NET_ACT_POLICE
。
3.11之前的内核,不得加载ip_gre
模块(NET_IPGRE)。
开启CONFIG_TUN
以使能ovs对TAP设备的支持。
与内核相对应的GCC版本。
一个内核构建目录对应于模块要运行的linux内核镜像(linux-header相关文件)。
如果使用git树或者修改了打开的vswitch构建系统或数据库架构,则还需要以下软件:
还有一些 datapath test 相关包,此处不在赘述。对于一个系统,基本下面的命令搞定
1
|
|
为了支持TAP 和 随机,需要/dev/urandom
和/dev/net/tun
这两个文件存在。
构建”configure”脚本
1
|
|
配置
默认情况下,所有的文件都安装在/usr/local
目录下,即下面的命令
1
|
|
此时,openvswitch会在/usr/local/etc/openvswitch
下查找数据库。
但是如果想按照传统安装方式(/usr/local -> /usr, /usr/local/var -> /var, /etc/openvswitch作为默认数据库目录),则
1
|
|
构建Linux内核模块,以便您可以运行基于内核的交换机,在–with-linux上传递内核构建目录的位置。
1
|
|
以上总结,直接运行
1
|
|
除此之前,还可以编译不同架构的ovs,例如
1
|
|
还有其他的选项,可参考官网。
Building
make install
默认将程序及帮助文件装入/usr/local
1
|
|
安装内核模块
1
|
|
如果运行时遇到类似如下错误
1
|
|
恭喜你,和我一样,中招了。
此问题是安装内核模块是遇错,那么手动安装即可,并保持重启已经安装,所以需要以下操作
1
|
// 查看这几个模块的依赖关系是否建立,一般在最后几行
|
开始
全自动执行
1
|
// 加入环境变量,或者直接绝对路径执行
|
半自动(指定启动项)
1
|
//只启动 ovsdb-server
|
手动执行
1
|
//不用 ovs-ctl工具
|
配置ovsdb-serve
以使用数据库
1
|
|
Note:如果openvswitch 不支持ssl
,则忽``–private-key,
–certificate,
–bootstrap-ca-cert`。
初始化数据库
1
|
|
开启openvswitch主要进程
1
|
|
验证
1
|
|
终止进程
本例为默认目录
1
|
|
安装新的openvswitch版本
升级数据库
库内无重要数据则直接删除重建;
有重要数据则先备份数据库,然后利用ovsdb-toolconvert
来进行升级
1
|
|
启动进程。
1
|
|
一句话概括:可利用 ovs-ctl restart
一次性搞定,如果有内核修改则利用ovs-ctl force-reload-kmod
。
升级仅涉及用户空间程序(实用程序、守护进程),确保新的版本与之前加载的内核模块兼容。
用户空间守护进程的升级意味着它们必须重新启动。重新启动守护进程意味着ovs-vswitchd守护进程中的openflow流将丢失。
恢复流量的一种方法是让控制器重新填充它。
另一种方法是使用像ovs-ofctl这样的工具保存以前的流程,然后在重新启动后重新添加它们。只有当新的开放vswitch接口保留旧的“端口”值时,恢复旧流才是准确的。
1
|
// ovs-save 可以保存每个桥的流表。ovs-save COMMAND {bridge1|bridge2}
|
当新用户空间守护进程重新启动时,它们会自动刷新内核中的旧流设置。如果有数百个进入内核的新流程,但用户空间守护进程正在忙于从控制器或ovs-ofctl等实用程序中设置新的用户空间流量,则这可能会很耗时(冲突)。
打开vswitch数据库提供了一个通过open_vswitch表的other_config:flow-restore-wait
列解决此问题的选项。有关详细信息,请参阅ovs-vswitchd.conf.db(5)手册页。
1
|
此选项热升级的过程如下:
|
如果升级还涉及升级内核模块,则需要卸载旧的内核模块,并且应该加载新的内核模块。
这意味着属于开放vswitch的内核网络设备被重新创建,并且内核流程丢失。如果用户空间守护程序立即重新启动并且用户空间流尽快恢复,则可以减少流量的停机时间。
1
|
`force-reload-kmod`卸载 vport* 和 openvswitch模块,重装 openvswitch 模块。
|
ovs-ctl实用程序的重新启动功能仅重新启动用户空间守护程序,确保’ofport’值在重新启动时保持一致,使用ovs-ofctl实用程序还原用户空间流,并使用other_config:flow-restore-wait
列保留交通宕机时间降至最低。
ovs-ctl实用程序的force-reload-kmod
函数完成了上述所有操作,但也用新的内核模块替换了旧的内核模块。
打开debian,xenserver和rhel的vswitch启动脚本使用ovs-ctl的功能,并且建议这些功能也可用于其他软件平台。
验证升级构建的拓扑如下
过程如下
br-tun、br-int、 qbr、netns创建
1
|
|
br-tun、br-int 连接
1
|
|
br-int、qbr连接
1
|
|
qbr、ns连接
1
|
|
br-tun对端连接
1
|
|
进入对端netns ,ping本端netns内部ip地址,且在本端eth0接口抓包验证。
br-int 和 br-tun流表默认都是全通,所以修改一下,为了升级之后进行确认。
升级!(升级之前的准备见上文,升级过程中一直ping)。
不升级内核
1
|
|
流量不中断。
升级内核
1
|
|
流量不中断。
Notes:升级的version >= 2.8.2 时,不会重新加载vport*内核模块,这是因为 在RHEL 7.x上,遇到了一个由iptables启动脚本引起的错误,该脚本尝试删除与linux conntrack相关的所有内核模块。它无法卸载openvswitch内核模块,因为它有一个引用计数。但它成功地卸载了vport-geneve,并转而用上游的“geneve”内核模块。这会导致隧道断开。通过不加载基于vport的内核模块来避免上述情况。 ovs-vswitchd启动时将加载上游模块。
(参考此处)。
验证接口及流表(流量不断基本就没什么问题)。
Notes:ovs在openstack环境中升级时,需要将openvswitch-agent先停止,以防止ovs相关进程终止时其自动拉起。
标签:帮助 libtool 启动 das 并且 开机 模块 dep director
原文地址:https://www.cnblogs.com/dream397/p/12909950.html