有些人就是喜欢折腾

最近又心血来潮，打算把两年前的坑填上，整了两天，算是把部署OpenStack的坑踩得差不多了。部署方法和之前一样，还是采用的kolla-ansible，主要是neutron_external_interface的文档还是写的比较模糊，加上OpenVirtualSwitch一起，折腾了不少时间。

总结起来，这次折腾的主要结论是，能用，但没必要。由于OpenStack本来就是工业级的设计，开发者原本就是基于企业环境控制网络和外网分离的假设做的实现，因而把两个网络合并势必会受到操作系统等外部组件的设计阻碍，这次的坑基本上都是来自这方面。

首先一开始是打算虚拟一个接口给外网，然后用系统做流量转发给物理网口，但是因为技艺不精，一直失败，只好作罢。后来看到OpenStack的开发文档中提到，由于开发者电脑不一定像工业级服务器一样有两个网口，因而还是允许使用单网口机器部署的。只不过由于ovs要独占外网网口，对外网的访问要从原本的物理网口转移到虚拟网口，导致网络配置丢失，因而必须要使用非远程的方法进行配置（BMC除外）。

大致配置流程如下（假设网卡为eth0）：

  1. 按照正常流程配置OpenStack安装，并将network_interface和neutron_external_interface都设置为eth0；
    安装到一半的时候，由于kolla-ansible配置了ovs，导致原有网络配置失效，无法访问外网，表现为某些docker pull失败，说无法连接到quay.io。
  2. 此时可以发现eth0被连接到了ovs-system，但是用ovs-vsctl查看，发现eth0又被分配给了br-ex。用nmcli手动进行网络地址的配置： 
    nmcli connection modify br-ex connection.autoconnect yes
nmcli connection modify br-ex ipv4.addresses xxx.xxx.xxx.xxx
nmcli connection modify br-ex ipv4.gateway xxx.xxx.xxx.xxx
nmcli connection modify br-ex ipv4.method manual
nmcli connection modify br-ex ipv4.dns xxx.xxx.xxx.xxx

    其中xxx.xxx.xxx.xxx设置为网卡正常访问外网时的配置即可。需要注意这几条命令的顺序最好不要修改，因为nmcli会做参数检查，如果没设置好某些参数是设置不了另一些的。

  3. 执行nmcli device set br-ex managed yes，将br-ex的网络配置交给nmcli执行，此时可以用ping检查网络是否配置完成；
  4. 修改kolla-ansible的globals.yml，将network_interface配置为br-ex，因为此时eth0已经无法正常用于访问网络；
  5. 重新执行kolla-ansible的deploy指令，等待部署完成即可。

由于nmtui似乎没法快捷方便地管理ovs的网卡配置，因而每次重启后需要手动将br-ex设置为managed模式，才能由NetworkManager进行配置，即手动执行第三步。

接下来如果有新坑的话，就是在Linux上配个子网，然后让OpenStack用本地虚拟子网作为外网了

标签: none

添加新评论