openstack中的self-service和provider网络

openstack中的self-service和provider网络，在网上很多地方都有说明。大家可以去看看上面对这两种网络的详细说明。可以参考：https://www.cnblogs.com/weiyongjie/p/12960327.html这个是使用kolla创建基于VLAN的网络，以及https://blog.csdn.net/u013469753/article/details/119039418 这个主要是讲解self-service和provider网络的原理
这里我只是简单结合我自己的实践说一下自己的理解：
self-service是租户创建的网络，是一个完全的虚拟网络，是使用VXLAN来构建的一个二层网络。
provider网络则不允许由租户自己创建，而是由管理员创建的。它实际上是一个跟物理网络桥接的虚拟网络，这个可能 比较难理解。后面我给出一个具体的例子，结合具体的例子来理解就更容易一点。
我们可以在WEB管理页面上创建provider网络也可以在命令行创建。WEB管理页面上注意是在管理员----网络里面创建，而一般的self-service网络则是在项目----网络里面创建。
一般常用的provider网络有两种，flat和VLAN。你会发现在创建flat类型的provider网络的时候需要你提供 物理网络这个参数，对应命令行的--provider-physical-network。在创建vlan类型的provider网络的时候需要你提供物理网络和段ID两个参数，对应命令行的--provider-physical-network和--provider-segment这两个参数。那这个物理网络或者说是--provider-physical-network要填写什么呢？这个当然不是随便填写的，是要根据你安装neutron时的配置来填写的。如果你是用kolla安装的，在主控节点和网络节点的/etc/kolla/neutron-server/ml2_conf.ini 文件里面找到以下内容：
[ml2_type_flat]
flat_networks = physnet1
这里physnet1 就是创建flat类型的provider网络时，所要填写的物理网络。之前说过provider网络是一个跟物理网络桥接的虚拟网络。这个怎么理解了，我们在这个配置里面里面找到以下内容：
[ovs]
bridge_mappings = physnet1:br-ex,default:br-ex
其中physnet1:br-ex就指明了physnet1这个物理网络是通过桥接到ovs的网桥br-ex来实现的，而br-ex这个网桥它实际上桥接到一个物理网卡。这个物理网卡则是在安装时指定的。想一下在安装kolla时的global.yam文件里面有下面几行：
neutron_external_interface: "ens33"
neutron_plugin_agent: "openvswitch"
这里面就指定了ovs的网桥br-ex是桥接到ens33的
我们在网络节点上执行以下命令查看ovs网桥配置：
docker exec openvswitch_vswitchd ovs-vsctl show
在最后我们可以看到以下配置：
   Bridge br-ex
        Controller "tcp:127.0.0.1:6633"
        fail_mode: secure
        datapath_type: system
        Port phy-br-ex
            Interface phy-br-ex
                type: patch
                options: {peer=int-br-ex}
        Port "ens33"
            Interface "ens33"
        Port br-ex
            Interface br-ex
                type: internal
可以看到br-ex确实是跟ens33桥接在一块的。
这里给出一个创建flat类型的provider网络的实例：
network create --share --external --provider-physical-network physnet1 --provider-network-type flat out
这个provider网络名字是out,物理网络是physnet1，这个physnet1是从配置文件ml2_conf.ini得来的，你也可以在WEB页面创建：管理员----网络，记得在选择供应商网络类型为flat，物理网络是physnet1。也是可以成功创建的。
有了前面flat网络的成功例子，VLAN类型的provider网络就容易理解了。还是回到ml2_conf.ini文件找到以下内容：
[ml2_type_vlan]
network_vlan_ranges =
这是我安装完openstack后的默认内容，从这里面可以看出，没有配置有vlan类型的物理网络，所以就不能创建vlan类型的provider网络。那我们修改一下配置，使得其支持VLAN类型。
在主控节点修改：
[ml2_type_vlan]
network_vlan_ranges = default

在网络节点修改：
[ml2_type_vlan]
network_vlan_ranges = default:1000:4000
[ovs]
bridge_mappings = default:br-ex

有过上面的经验就不难理解了，vlan类型对应的物理网络为default，VLAN范围是1000到4000。这个物理网络桥接到br-ex这个网桥上的，并最终通过ens33访问真实的网络。从这里面也应该知道段ID即--provider-segment这参数在这里面的意义是VLAN ID。

在主控节点重启一下docker：
docker restart neutron_server
在网络节点重启docker:
docker restart neutron_openvswitch_agent

然后我们再来创建VLAN类型的provider网络:
network create --share --external --provider-physical-network default --provider-network-type vlan --provider-segment 3000 out_vlan
这个provider网络名字是out_vlan,物理网络是default，VLAN ID是3000。当然WEB页面也是可以创建的，记得物理网络要填写default，类型要选择VLAN。

最后再谈一下什么情况下使用self-service和provider网络。一般情况下在公有云场景，云服务提供商会让用户使用self-service来创建自己定义的网络，这样更加灵活也能支撑更多数量的租户。比如天翼云，用户创建的VPC实际上就是一个self-service网络。而最终用户访问外网，是通过浮动IP或者NAT网关访问公网的。浮动IP或者NAT网关其底层还是基于provider网络实现的。
而在私有云场景就比较简单了，一般不提供self-service网络。用户使用的子网都是管理员事先配置好的基于VLAN的provider网络。这样配置简单且性能更好。缺点就是不够灵活，且网络数量受限于可用VLAN（最多只能4096）。