Group Details Private

Global Moderators

Forum wide moderators

Member List

  • 如何实现oVirt与Tungsten Fabric的集成

    作者:Tatsuya Naganawa 译者:TF中文社区

    oVirt是一个免费开源的企业级虚拟化解决方案,基于KVM(并整合了libvirt、Gluster、PatternFly和Ansible等开源软件)提供强大的开源虚拟化功能。
    本文重点介绍oVirt与Tungsten Fabric的集成过程。
    

    使用版本

    ovirt 4.2.6.4-1.el7
    tungsten-fabric r5.0.1
    centos7.5
    编者注:本文写于2018年11月,请更新到最新版本

    建立oVirt

    oVirt安装文件
    https://ovirt.org/documentation/quickstart/quickstart-guide/

    所有的虚拟机都来自centos7 libvirt

    libvirt网络如下:
    default, 192.168.122.0/24, nat
    192_168_130_0, 192.168.130.0/24, isolated

    节点如下:
    ovirt-manager: centos161, 192.168.122.161 default
    ovirt-node: centos162, 192.168.122.162, 192.168.130.162, default, 192_168_130_0
    ovirt-node: centos163, 192.168.122.163, 192.168.130.163, default, 192_168_130_0
    contrail-controller: centos164, 192.168.122.164, 192.168.130.164: default, 192_168_130_0

    • 4vcpu, 8GB mem (24GB for contrail-controller), 48GB disk

    oVirt设置

          --== CONFIGURATION PREVIEW ==--
    
          Application mode                        : both
          Default SAN wipe after delete           : False
          Firewall manager                        : firewalld
          Update Firewall                         : True
          Host FQDN                               : centos161
          Configure local Engine database         : True
          Set application as default page         : True
          Configure Apache SSL                    : True
          Engine database secured connection      : False
          Engine database user name               : engine
          Engine database name                    : engine
          Engine database host                    : localhost
          Engine database port                    : 5432
          Engine database host name validation    : False
          Engine installation                     : True
          PKI organization                        : Test
          Set up ovirt-provider-ovn               : True
          Configure WebSocket Proxy               : True
          DWH installation                        : True
          DWH database host                       : localhost
          DWH database port                       : 5432
          Configure local DWH database            : True
          Configure Image I/O Proxy               : True
          Configure VMConsole Proxy               : True
    
          Please confirm installation settings (OK, Cancel) [OK]:
    

    节点设置

    1、添加两台主机和一个NFS数据域。

    注意:需要指定cpu类型“cpu-model”:

    6e291812-907c-4b4c-aefe-37a292c7f3b2-image.png
    afce7780-39f6-4c4d-a9f0-e16fc124f7f5-image.png

    2、从ovirt glance导入cirros镜像。

    3、在两台主机上创建cirros虚拟机,并检查虚拟机是否运行良好。

    安装Tungsten Fabric

    使用Tungsten Fabric r5.0.1版本
    https://hub.docker.com/u/tungstenfabric/

    以及ansible-deployer来安装OpenStack neutron / keystone
    https://github.com/Juniper/contrail-ansible-deployer/wiki/Contrail-with-Openstack-Kolla

    • instance.yaml
    provider_config:
      bms:
        ssh_pwd: root
        ssh_user: root
        domainsuffix: local
        ntpserver: 0.centos.pool.ntp.org
    instances:
      bms1:
        provider: bms
        ip: 192.168.122.164
        roles:
          config_database:
          config:
          control:
          analytics_database:
          analytics:
          webui:
          openstack:
      bms11:
        provider: bms
        ip: 192.168.122.162
        roles:
          vrouter:
            PHYSICAL_INTERFACE: eth1
            VROUTER_GATEWAY: 192.168.130.1
          openstack_compute:
      bms12:
        provider: bms
        ip: 192.168.122.163
        roles:
          vrouter:
            PHYSICAL_INTERFACE: eth1
            VROUTER_GATEWAY: 192.168.130.1
          openstack_compute:
    contrail_configuration:
      RABBITMQ_NODE_PORT: 5673
      AUTH_MODE: keystone
      KEYSTONE_AUTH_URL_VERSION: /v3
      CONTRAIL_VERSION: r5.0.1
    kolla_config:
      kolla_globals:
        enable_haproxy: no
        enable_swift: no
      kolla_passwords:
        keystone_admin_password: contrail123
    global_configuration:
      CONTAINER_REGISTRY: tungstenfabric
    

    对于ovirt-nodes,必须指定“vrouter”和“nova_compute”角色。

    还需要明确指定PHYSICAL_INTERFACE,VROUTER_GATEWAY,以使vrouter能够使用eth1(与ovirtmgmt不同的NIC)。

    终止nova_compute, nova_libvirt

    由于vdsm使用了libvirt端口,因此需要终止nova_libvirt。

    # docker stop nova_compute nova_libvirt
    # docker rm nova_compute nova_libvirt
    # reboot
    

    创建OpenStack虚拟网络

    键入下面的命令,以在Tungsten Fabric上创建虚拟网络。

    # source /etc/kolla/kolla-toolbox/admin-openrc.sh
    # openstack network create vn1
    # openstack subnet create --subnet-range 10.0.1.0/24 --network vn1 subnet1
    

    设置oVirt neutron提供程序

    使用下面的参数,创建Tungsten Fabric提供程序。

    Name: tungsten-fabric
    Network Plugin: LINUX_BRIDGE
    Provider URL: http://192.168.122.164:9696
    Read-Only: Checked
    Requires Authentication: Checked
    Username: admin
    Password: contrail123
    Tenant /name: admin
    Authentication URL: http://192.168.122.164:35357/v2.0
    

    从Tungsten Fabric导入虚拟网络

    添加vdsm hook

    在下面的目录找到文件:
    /usr/libexec/vdsm/hooks/after_device_create/60_tungsten-fabric

    • 注意:部署时需要给出tf_controller_ip
    #!/usr/bin/python
    import os
    import requests
    
    tf_controller_ip='192.168.122.164'
    vnic_id=os.environ['vnic_id']
    
    re = requests.get('http://{}:8082/virtual-machine-interface/{}'.format (tf_controller_ip, vnic_id))
    js = re.json()['virtual-machine-interface']
    mac_addr =  js['virtual_machine_interface_mac_addresses']['mac_address'][0]
    vm_id = js['virtual_machine_refs'][0]['to'][0]
    vn_id = js['virtual_network_refs'][0]['uuid']
    
    cmd = "/var/lib/docker/volumes/opt_plugin/_data/bin/vrouter-port-control --oper=add --uuid={} --instance_uuid={} --vn_uuid={} --vm_name='' --ip_address='0.0.0.0' --ipv6_address=None --tap_name=tap{} --mac='{}' --rx_vlan_id=-1 --tx_vlan_id=-1".format(vnic_id, vm_id, vn_id, vnic_id[:11], mac_addr)
    
    os.popen(cmd).read()
    # chmod 755 /usr/libexec/vdsm/hooks/after_device_create/60_tungsten-fabric
    # chmod 755 /var/lib/docker/volumes/
    

    创建虚拟机并将vNIC附加到TF虚拟网络上

    登录到cirros并检查是否能正常ping通:

    # ping 10.0.1.1 # gw-ip  
    # ping 10.0.1.2 # service-ip  
    # ping (cirros ip on different ovirt node)
    
    [root@centos163 ~]# ip -o a
    1: lo    inet 127.0.0.1/8 scope host lo\       valid_lft forever preferred_lftforever
    1: lo    inet6 ::1/128 scope host \       valid_lft forever preferred_lft forever
    21: ovirtmgmt    inet 192.168.122.163/24 brd 192.168.122.255 scope global ovirtmgmt\       valid_lft forever preferred_lft forever
    21: ovirtmgmt    inet6 fe80::5054:ff:fe7b:b7ac/64 scope link \       valid_lftforever preferred_lft forever
    25: vhost0    inet 192.168.130.163/24 brd 192.168.130.255 scope global vhost0\      valid_lft forever preferred_lft forever
    25: vhost0    inet6 fe80::5054:ff:fecf:54be/64 scope link \       valid_lft forever preferred_lft forever
    26: docker0    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0\      valid_lft forever preferred_lft forever
    27: genev_sys_6081    inet6 fe80::c8b:b5ff:fe21:bbed/64 scope link \       valid_lft forever preferred_lft forever
    28: pkt0    inet6 fe80::f806:bcff:fe7d:fe28/64 scope link \       valid_lft forever preferred_lft forever
    30: tapec01038d-44    inet6 fe80::fc1a:4aff:fe16:105/64 scope link \       valid_lft forever preferred_lft forever
    [root@centos163 ~]#
    [root@centos163 ~]# ip route
    default via 192.168.122.1 dev ovirtmgmt
    169.254.0.0/16 dev ovirtmgmt scope link metric 1021
    169.254.0.3 dev vhost0 proto 109 scope link
    172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
    192.168.122.0/24 dev ovirtmgmt proto kernel scope link src 192.168.122.163
    192.168.130.0/24 dev vhost0 proto kernel scope link src 192.168.130.163
    [root@centos163 ~]#
    [root@centos163 ~]# ssh cirros@169.254.0.3
    The authenticity of host '169.254.0.3 (169.254.0.3)' can't be established.
    ECDSA key fingerprint is SHA256:HVJoTV0MGH9/T8bIw0aofzX7rCAphKDgts36YAXxpoo.
    ECDSA key fingerprint is MD5:03:55:f1:dd:53:ed:c9:87:62:fd:e6:3a:bb:59:aa:cc.
    Are you sure you want to continue connecting (yes/no)? yes
    Warning: Permanently added '169.254.0.3' (ECDSA) to the list of known hosts.
    cirros@169.254.0.3's password:
    $
    $ ip -o a
    1: lo:  mtu 65536 qdisc noqueue qlen 1\    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    1: lo    inet 127.0.0.1/8 scope host lo\       valid_lft forever preferred_lft forever
    1: lo    inet6 ::1/128 scope host \       valid_lft forever preferred_lft forever
    2: eth0:  mtu 1500 qdisc pfifo_fast qlen 1000\    link/ether 00:1a:4a:16:01:05 brd ff:ff:ff:ff:ff:ff
    2: eth0    inet 10.0.1.4/24 brd 10.0.1.255 scope global eth0\       valid_lft forever preferred_lft forever
    2: eth0    inet6 fe80::21a:4aff:fe16:105/64 scope link \       valid_lft forever preferred_lft forever
    $
    $ ping 10.0.1.3
    PING 10.0.1.3 (10.0.1.3): 56 data bytes
    64 bytes from 10.0.1.3: seq=0 ttl=64 time=2.855 ms
    64 bytes from 10.0.1.3: seq=1 ttl=64 time=1.852 ms
    ^C
    --- 10.0.1.3 ping statistics ---
    2 packets transmitted, 2 packets received, 0% packet loss
    round-trip min/avg/max = 1.852/2.353/2.855 ms
    $
    $ ssh 10.0.1.3
    
    Host '10.0.1.3' is not in the trusted hosts file.
    (ecdsa-sha2-nistp521 fingerprint md5 5f:61:d0:f8:c3:c2:aa:8d:07:95:29:b4:52:aa:06:77)
    Do you want to continue connecting? (y/n) y
    cirros@10.0.1.3's password:
    $
    $ ip -o a
    1: lo:  mtu 65536 qdisc noqueue qlen 1\    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    1: lo    inet 127.0.0.1/8 scope host lo\       valid_lft forever preferred_lft forever
    1: lo    inet6 ::1/128 scope host \       valid_lft forever preferred_lft forever
    2: eth0:  mtu 1500 qdisc pfifo_fast qlen 1000\    link/ether 00:1a:4a:16:01:04 brd ff:ff:ff:ff:ff:ff
    2: eth0    inet 10.0.1.3/24 brd 10.0.1.255 scope global eth0\       valid_lft forever preferred_lft forever
    2: eth0    inet6 fe80::21a:4aff:fe16:104/64 scope link \       valid_lft forever preferred_lft forever
    $
    

    以上,我们就实现了oVirt与Tungsten Fabric的集成部署。如有更多问题,请与TF中文社区联系。

    原文链接:
    https://github.com/tnaganawa/ovirt-tungstenfabric-integration


    往期精选

    Tungsten Fabric知识库丨vRouter内部运行探秘
    Tungsten Fabric知识库丨更多组件内部探秘
    Tungsten Fabric知识库丨 构建、安装与公有云部署
    Tungsten Fabric知识库丨测试2000个vRouter节点部署
    Tungsten Fabric知识库丨关于OpenStack、K8s、CentOS安装问题的补充
    Tungsten Fabric知识库丨这里有18个TF补丁程序,建议收藏

    posted in 博客
  • 如何在OpenStack Kolla上部署Tungsten Fabric(附14个常见的配置问题)

    首先,您可以参考下面的链接,使用contil-kolla-ansible-deployer容器在OpenStack Kolla上部署Tungsten Fabric(注:原文为Contrail,本文以功能一致的Tungsten Fabric替换):

    https://github.com/Juniper/contrail-ansible-deployer/wiki/[-Container-Workflow]-Deploying-Contrail-with-OpenStack

    无论是使用contil-kolla-ansible部署kolla容器,或者使用contrail-ansible-deployer部署Tungsten Fabric容器,都涉及以下主要步骤:

    1.设置基本主机
    2.部署OpenStack(kolla)和Tungsten Fabric容器
    

    1. 设置基本主机

    下面给出的步骤假定是在内核为3.10.0-862.3.2.el7.x86_64.的Centos 7.5基本主机上。vRouter与主机内核具有依赖性。

    1.0安装必备软件包

    yum -y install epel-release 
    yum install -y python-pip
    pip install requests
    

    1.1 安装Ansible

    yum -y install git
    pip install ansible==2.5.2.0
    

    1.2 克隆contrail-ansible-deployer

    git clone http://github.com/Juniper/contrail-ansible-deployer
    cd contrail-ansible-deployer
    

    1.3 在适当的参数下配置必要的参数config/instances.yaml

    这是单节点、单接口的多合一集群的最低配置。

    对于多接口设置,请参考以下链接获取推荐的配置:

    https://github.com/Juniper/contrail-ansible-deployer/wiki/Contrail's-multi-interface-setup-in-general

    provider_config:
      bms:
        ssh_pwd: 
        ssh_user: root
        ntpserver: 
        domainsuffix: local
    instances:
      :
        provider: bms
        ip: 
        roles:
          config_database:
          config:
          control:
          analytics_database:
          analytics:
          webui:
          vrouter:
          openstack:
          openstack_compute:  
    contrail_configuration:
      AUTH_MODE: keystone
      KEYSTONE_AUTH_URL_VERSION: /v3
    kolla_config:
      kolla_globals:
        enable_haproxy: no
        enable_ironic: "no"
        enable_swift: "no"
      kolla_passwords:
        keystone_admin_password: 
    

    这里是一个用于类似多合一单节点的文件,用于解释目的。

    provider_config:
      bms:
        ssh_pwd: 
        ssh_user: root
        ntpserver: 
        domainsuffix: local
    instances:
     :
        provider: bms
        ip: 
        roles:
          config_database:
          config:
          control:
          analytics_database:
          analytics:
          webui:
          vrouter:
          openstack:
          openstack_compute:
    global_configuration:
      CONTAINER_REGISTRY: :
      REGISTRY_PRIVATE_INSECURE: True
      CONTAINER_REGISTRY_USERNAME: 
      CONTAINER_REGISTRY_PASSWORD: 
    contrail_configuration:
      CLOUD_ORCHESTRATOR: openstack
      # Default value for OPENSTACK_VERSION is 'queens'
      OPENSTACK_VERSION: ocata
      # Default value for CONTRAIL_VERSION is 'latest'. The version must be available in
      # registry specified in CONTAINER_REGISTRY
      CONTRAIL_VERSION: 5.0-198
      # Set UPGRADE_KERNEL to True to automatically install the latest kernel version
      UPGRADE_KERNEL: True
      CONTRAIL_VERSION:   # Ex: latest or any private-repo containers tag.
      VROUTER_GATEWAY: 
      AUTH_MODE: keystone
      KEYSTONE_AUTH_URL_VERSION: /v3
    kolla_config:
      kolla_globals:
        enable_haproxy: no
        enable_ironic: no
        enable_swift: no
      kolla_passwords:
        keystone_admin_password: 
    

    这里有一些提示:

    a、Provider configuration是指Tungsten Fabric集群主机所在的云服务商。对于裸机服务器,provide将为“bms”。

    b、有关此文件字段的更多详细信息,请参考以下文档:
    https://github.com/tungstenfabric/tf-ansible-deployer/blob/master/README.md#configuration

    c、请参考以下文件,以了解在OpenStack服务的“ kolla_globals”部分和Tungsten Fabric服务的“ contrail_configuration”部分可以自定义哪些字段:

    d、如果您要构建自己的容器,则可以将CONTAINER_REGISTRY设置为本地Docker注册表。如果未指定,它将尝试从docker hub中拉取容器。如果指定了自定义注册表,请注意,您必须在kolla_globals下指定与“contrail_docker_registry”相同的注册表。目前暂时不会自动导出,将在以后的代码更改中完成。

    e、如果未指定,则CONTRAIL_VERSION将默认为“latest”标签。如果您喜欢nightly build的特定版本,则可以指定从以下链接找到的标签:
    https://hub.docker.com/r/opencontrailnightly/contrail-nodemgr/tags/

    f、其它场景的样本配置

    g、如果需要为每个主机指定特定于主机的值(例如,如果集群中的服务器上用于“network_interface”的接口名称不同),请参考此处的示例以了解如何指定这一点:
    https://github.com/Juniper/contrail-ansible-deployer/wiki/Configuration-Sample-for-Multi-Node-Openstack-HA-and-Contrail-(multi-interface)

    h、许多参数会自动导出为默认设置,这是第一种配置的工作方式。如果需要,用户可以显式指定变量以覆盖派生的值。如果您想了解派生逻辑,请查看代码。

    i、如果您希望在多合一节点上配置Tungsten Fabric + OpenStack,并且所有服务都侦听私有子网IP地址(非mgmt),请按以下方式配置OpenStack:

    openstack:
      kolla_internal_address: 192.168.10.10
      network_interface: eth2
    

    如果不需要限制仅访问该子网,则在kolla_globals部分下将“enable_haproxy”设置为“yes”就足够了。

    1.4安装Tungsten Fabric和Kolla要求

    以下Playbook将软件包安装在部署程序主机以及启动Kolla和Tungsten Fabric容器所需的目标主机上。

    ansible-playbook -i inventory/ -e orchestrator=openstack playbooks/configure_instances.yml
    

    2. 配置Tungsten Fabric和Kolla容器

    ansible-playbook -i inventory/ playbooks/install_openstack.yml
    ansible-playbook -i inventory/ -e orchestrator=openstack playbooks/install_contrail.yml
    

    3. 运行OpenStack命令

    3.1 安装OpenStack客户端

    由于kolla_toolbox容器已经安装了客户端,因此无需安装OpenStack客户端。请参阅此处以使用kolla_toolbox。

    https://github.com/Juniper/contrail-ansible-deployer/wiki/Provisioning-F.A.Q#how-to-use-the-kolla_toolbox-container-to-run-openstack-cli-commands

    或者,如果您希望从基本主机上运行命令,请遵循以下说明。

    OpenStack客户端以前是作为Playbook运行的一部分自动安装的。但是在安装python docker组件库时引入了一些必要的python库,这些库现在与从Yum repos中安装python-openstackclients相冲突。获取python-openstackclient软件包的另一个选项是通过“pip”repos进行安装。但是安装这些pip软件包可能会导致Ansible可执行文件崩溃,因为Ansible使用的库也会发生变化。因此,需要使用pip手动安装客户端。

    yum install -y gcc python-devel
    pip install python-openstackclient
    pip install python-ironicclient
    

    3.2 使用VM到VM ping测试您的设置

    source /etc/kolla/kolla-toolbox/admin-openrc.sh
    wget http://download.cirros-cloud.net/0.4.0/cirros-0.4.0-x86_64-disk.img
    openstack image create cirros2 --disk-format qcow2 --public --container-format bare --file cirros-0.4.0-x86_64-disk.img                                      
    openstack network create testvn
    openstack subnet create --subnet-range 192.168.100.0/24 --network testvn subnet1
    openstack flavor create --ram 512 --disk 1 --vcpus 1 m1.tiny
    NET_ID=`openstack network list | grep testvn | awk -F '|' '{print $2}' | tr -d ' '`
    openstack server create --flavor m1.tiny --image cirros2 --nic net-id=${NET_ID} test_vm1
    openstack server create --flavor m1.tiny --image cirros2 --nic net-id=${NET_ID} test_vm2
    

    附:14个常见的配置问题

    检查配置的常见问题以及修补程序/解决方法。

    1. 找不到Kolla的文件/目录:

    [root@a6s14 contrail-ansible-deployer]# ansible-playbook -i inventory/ -e orchestrator=vcenter  playbooks/install_openstack.yml
    ...
    ...
    ERROR! Unable to retrieve file contents
    Could not find or access '/root/contrail-kolla-ansible/ansible/kolla-host.yml'
    [root@a6s14 contrail-ansible-deployer]#
    

    解决方法:在运行install_contrail之前,请先运行以下命令:

    ansible-playbook -i inventory/ playbooks/configure_instances.yml
    

    2. 在Ansible中缺少IPv4:

    TASK [memcached : Copying over config.json files for services] *******************************************************************************************************************************
    task path: /root/contrail-kolla-ansible/ansible/roles/memcached/tasks/config.yml:10
    failed: [192.168.122.84] (item=memcached) => {
       "changed": false,
       "item": "memcached",
       "msg": "AnsibleUndefinedVariable: {{ hostvars[inventory_hostname]['ansible_' + api_interface]['ipv4']['address'] if orchestration_engine == 'ANSIBLE' else '0.0.0.0' }}: 'dict object' has no attribute 'ipv4'"
    }
    

    解决方法:检查是否在instances.yaml文件的“kolla_globals”部分下为“network_interface”指定了正确的值。该接口必须具有一个IP地址。

    3. 如何指定特定于主机的参数(例如,集群中不同服务器的接口名称不同)?

    解决方法:查看以下链接:

    https://github.com/Juniper/contrail-ansible-deployer/wiki/Configuration-Sample-for-Multi-Node-Openstack-HA-and-Contrail-(multi-interface)

    4. 不能通过指定为“CONTAINER_REGISTRY”的专用注册表访问(拉取)容器。

    解决方法:检查“REGISTRY_PRIVATE_INSECURE”是否设置为True。示例如下:

    https://github.com/Juniper/contrail-ansible-deployer/wiki/Contrail-with-Kolla-Ocata#13-configure-necessary-parameters-configinstancesyaml-under-appropriate-parameters

    5. vRouter模块未安装在计算机上。vRouter容器处于错误状态,并且docker日志显示如下错误:

    [srvr5] ~ # docker logs vrouter_vrouter-kernel-init_1
    insmod: ERROR: could not insert module /opt/contrail/vrouter-kernel-modules/???/vrouter.ko: Unknown symbol in module
    ERROR: Failed to insert vrouter kernel module
    

    或像这样dmesg的日志如下:

    [161758.854712] entrypoint.sh (19521): drop_caches: 2
    [161758.861953] vrouter: Unknown symbol __x86_indirect_thunk_r15 (err 0)
    [161758.862025] vrouter: Unknown symbol __x86_indirect_thunk_r11 (err 0)
    [161758.862043] vrouter: Unknown symbol __x86_indirect_thunk_rax (err 0)
    [161758.862047] vrouter: disagrees about version of symbol napi_complete_done
    [161758.862049] vrouter: Unknown symbol napi_complete_done (err -22)
    [161758.862113] vrouter: Unknown symbol __x86_indirect_thunk_rdx (err 0)
    [161758.862158] vrouter: Unknown symbol __x86_indirect_thunk_r14 (err 0)
    [161758.862203] vrouter: Unknown symbol __x86_indirect_thunk_r13 (err 0)
    [161758.862216] vrouter: disagrees about version of symbol __ethtool_get_link_ksettings
    [161758.862218] vrouter: Unknown symbol __ethtool_get_link_ksettings (err -22)
    [161758.862240] vrouter: Unknown symbol __x86_indirect_thunk_r10 (err 0)
    [161758.862287] vrouter: Unknown symbol ether_setup_rh (err 0)
    [161758.862306] vrouter: Unknown symbol __x86_indirect_thunk_rcx (err 0)
    [161758.862327] vrouter: Unknown symbol __x86_indirect_thunk_r9 (err 0)
    [161758.862358] vrouter: Unknown symbol __x86_indirect_thunk_r12 (err 0)
    [161758.862381] vrouter: Unknown symbol napi_schedule_prep (err 0)
    [161758.862444] vrouter: Unknown symbol genl_register_family (err 0)
    [161758.862467] vrouter: Unknown symbol __x86_indirect_thunk_r8 (err 0)
    

    解决方法:vRouter模块现在依赖于内核为3.10.0-862.3.2.el7.x86_64.的主机上。在运行配置之前,请在目标节点上安装此内核版本:

    yum -y install kernel-3.10.0-862.3.2.el7.x86_64                                                                                                                                                    
    yum update
    reboot
    

    您也可以只更新到最新的内核-它应该可以工作。还有一个选择是让contrail-ansible-deployer更新您的内核:

    contrail_configuration:
        UPGRADE_KERNEL: true
    

    6. 检索容器映像时出错

    fatal: [10.87.70.19]: FAILED! => {“changed”: true, “msg”: “’Traceback (most recent call last):
    File   \“/tmp/ansible_x7Zn20/ansible_module_kolla_docker.py\“, line 785, in main\\n    
    result = bool(getattr(dw,  module.params.get(\\‘action\\‘))())\\n  
    File \“/tmp/ansible_x7Zn20/ansible_module_kolla_docker.py\“, line 583, in recreate_or_restart_container\\n
    self.start_container()\\n  File \“/tmp/ansible_x7Zn20/ansible_module_kolla_docker.py\“, line 595, in start_container\\n
    self.pull_image()\\n  File \“/tmp/ansible_x7Zn20/ansible_module_kolla_docker.py\“, line 445, in pull_image\\n    
    repository=image, tag=tag, stream=True\\n
    File \“/usr/lib/python2.7/site-packages/docker/api/image.py\“, line 175, in pull\\n
    self._raise_for_status(response)\\n  File \“/usr/lib/python2.7/site-packages/docker/client.py\“, line 173, in _raise_for_status\\n
    raise errors.NotFound(e, response, explanation=explanation)\\nNotFound: 404 Client Error: Not Found (\“{\“message\“:\“manifest for opencontrailnightly/contrail-openstack-ironic-notification-manager:master-centos7-ocata-bld-33 not found\“}\“)\\n’“}
     to retry, use: --limit @/root/contrail-ansible-deployer/playbooks/install_contrail.retry
    

    解决方法:检查CONTRAIL_VERSION。它应该具有在此处找到的有效标签:opencontrailnightly标签

    https://hub.docker.com/r/opencontrailnightly/contrail-nodemgr/tags/

    7. 看到此如下错误

    2018-03-21 00:47:16,884 p=16999 u=root |  TASK [iscsi : Ensuring config directories exist] *********************************************************************************************************************************
    
    2018-03-21 00:47:16,959 p=16999 u=root |  fatal: [10.0.0.4]: FAILED! => {"msg": "The conditional check 'inventory_hostname in groups['compute'] or inventory_hostname in groups['storage']' failed. The error was: error while evaluating conditional (inventory_hostname in groups['compute'] or inventory_hostname in groups['storage']): Unable to look up a name or access an attribute in template string ({% if inventory_hostname in groups['compute'] or inventory_hostname in groups['storage'] %} True {% else %} False {% endif %}).\nMake sure your variable name does not contain invalid characters like '-': argument of type 'StrictUndefined' is not iterable\n\nThe error appears to have been in '/root/contrail-kolla-ansible/ansible/roles/iscsi/tasks/config.yml': line 2, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n---\n- name: Ensuring config directories exist\n  ^ here\n"}
    
    2018-03-21 00:47:16,961 p=16999 u=root |        to retry, use: --limit @/root/contrail-ansible-deployer/playbooks/install_contrail.retry
    

    解决方法:这是通过Bug#1756133进行的最近更改的结果。在一个用例中,需要在没有nova-compute的情况下配置vRouter。因此,当指定“vrouter”角色时,不会自动推断出“openstack_compute”。需要与“vrouter”一起明确声明“openstack_compute”角色。

    8. 为什么在单个OpenStack集群上需要haproxy和虚拟IP?

    默认情况下,所有OpenStack服务都将侦听“kolla_globals”部分下的kolla_internal_vip_address/network_interface变量提供的IP/接口。在大多数情况下,这将对应于ctrl-data-network。请注意,这意味着即使horizon现在也只能在ctrl-data-network上运行。kolla提供访问管理网络上horizon的唯一方法是使用haproxy和keepalived。依次启用keepalived意味着VRRP需要虚拟IP,而虚拟IP不能是接口IP本身。如果不使用kolla配置参数启用keepalived,则无法启用haproxy。因此,您需要提供两个虚拟IP地址,一个在management上(kolla_external_vip_address),一个在ctrl-data-network上(kolla_internal_vip_address)。一旦指定了此范围,即可通过kolla_external_vip_address在管理网络上访问Horizon。

    9. 如何使用kolla_toolbox容器运行OpenStack CLI命令

    安装了运行OpenStack容器的基本主机的/etc/kolla/kolla-toolbox目录,并且可以从kolla_toolbox容器内部以/var/lib/kolla/config_files对其进行访问。如果用户在执行OpenStack命令时需要其它文件(例如“openstack image create”将需要映像文件),则用户可以将相关文件复制到基本主机的/etc/kolla/kolla-toolbox目录中,然后在容器内使用它们。运行OpenStack命令的方式如下:

    # ON BASE HOST OF OPENSTACK CONTROL NODE
    cd /etc/kolla/kolla-toolbox
    wget http://download.cirros-cloud.net/0.4.0/cirros-0.4.0-x86_64-disk.img
    
    docker exec -it kolla_toolbox bash
    # NOW YOU ARE INSIDE THE KOLLA_TOOLBOX CONTAINER
    (kolla-toolbox)[ansible@server1 /]$ source /var/lib/kolla/config_files/admin-openrc.sh
    (kolla-toolbox)[ansible@server1 /]$ cd /var/lib/kolla/config_files
    (kolla-toolbox)[ansible@server1 /var/lib/kolla/config_files]$ openstack image create cirros2 --disk-format qcow2 --public --container-format bare --file cirros-0.4.0-x86_64-disk.img
    +------------------+------------------------------------------------------+
    | Field            | Value                                                |
    +------------------+------------------------------------------------------+
    | checksum         | 443b7623e27ecf03dc9e01ee93f67afe                     |
    | container_format | bare                                                 |
    | created_at       | 2018-03-29T21:37:48Z                                 |
    | disk_format      | qcow2                                                |
    | file             | /v2/images/e672b536-0796-47b3-83a6-df48a5d074be/file |
    | id               | e672b536-0796-47b3-83a6-df48a5d074be                 |
    | min_disk         | 0                                                    |
    | min_ram          | 0                                                    |
    | name             | cirros2                                              |
    | owner            | 371bdb766278484bbabf868cf7325d4c                     |
    | protected        | False                                                |
    | schema           | /v2/schemas/image                                    |
    | size             | 12716032                                             |
    | status           | active                                               |
    | tags             |                                                      |
    | updated_at       | 2018-03-29T21:37:50Z                                 |
    | virtual_size     | None                                                 |
    | visibility       | public                                               |
    +------------------+------------------------------------------------------+
    (kolla-toolbox)[ansible@server1 /var/lib/kolla/config_files]$ openstack image list
    +--------------------------------------+---------+--------+
    | ID                                   | Name    | Status |
    +--------------------------------------+---------+--------+
    | e672b536-0796-47b3-83a6-df48a5d074be | cirros2 | active |
    | 57e6620e-796a-40ee-ae6e-ea1daa253b6c | cirros2 | active |
    +--------------------------------------+---------+--------+
    

    10. 部署redis失败,出现以下错误

    解决方法:这是由与Ansible的2.5.1.0版本不兼容的代码引起的。在我们修复代码以使其与最新版本的Ansible兼容之前,请坚持使用ansible-2.4.2.0暂时避免此问题。

    The conditional check 'roles[instance_name].webui is defined or roles[instance_name].analytics is defined' failed.
    
    }
    2018-04-21 15:27:24,288 p=23225 u=root | Read vars_file '{{ hostvars['localhost'].config_file }}'
    2018-04-21 15:27:24,289 p=23225 u=root | TASK [install_contrail : create /etc/contrail/redis] *******************************************************************************************************************************************************************
    2018-04-21 15:27:24,289 p=23225 u=root | task path: /var/contrail-ansible-deployer/playbooks/roles/install_contrail/tasks/create_redis.yml:2
    2018-04-21 15:27:24,379 p=23225 u=root | Read vars_file '{{ hostvars['localhost'].config_file }}'
    2018-04-21 15:27:24,391 p=23225 u=root | fatal: [10.87.129.234]: FAILED! => {
        "msg": "The conditional check 'roles[instance_name].webui is defined or roles[instance_name].analytics is defined' failed. The error was: error while evaluating conditional (roles[instance_name].webui is defined or roles[instance_name].analytics is defined): 'dict object' has no attribute u'bms2'\n\nThe error appears to have been in '/var/contrail-ansible-deployer/playbooks/roles/install_contrail/tasks/create_redis.yml': line 2, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n---\n- name: create /etc/contrail/redis\n ^ here\n"
    }
    2018-04-21 15:27:24,491 p=23225 u=root | Read vars_file '{{ hostvars['localhost'].config_file }}'
    2018-04-21 15:27:24,498 p=23225 u=root | fatal: [10.87.140.154]: FAILED! => {
        "msg": "The conditional check 'roles[instance_name].webui is defined or roles[instance_name].analytics is defined' failed. The error was: error while evaluating conditional (roles[instance_name].webui is defined or roles[instance_name].analytics is defined): 'dict object' has no attribute u'bms3'\n\nThe error appears to have been in '/var/contrail-ansible-deployer/playbooks/roles/install_contrail/tasks/create_redis.yml': line 2, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n---\n- name: create /etc/contrail/redis\n ^ here\n"
    }
    

    11.观察Cassandra的状态,例如“DB的磁盘太低”。

    • 将磁盘增加到256Gb以上
    • 设置另一个阈值
    contrail_configuration:
        CONFIG_DATABASE_NODEMGR__DEFAULTS__minimum_diskGB: "2"
        DATABASE_NODEMGR__DEFAULTS__minimum_diskGB: "2"
    

    对于5.0.0版本,您需要指定CONFIG_NODEMGR__DEFAULTS__minimum_diskGB而不是CONFIG_DTABASE_NODEMGR__DEFAULTS__minimum_diskGB。

    12. 控制器虚拟机的大小有16Gb或更小(演示版本)。安装不稳定。所有内存都被几个Java应用程序占用,或者来自daemon的错误响应:grpc: the connection is unavailable

    原因:Java内存可以被配置中的下一条语句所限制。

    解决方法:将以下配置添加到instance.yaml文件。

    contrail_configuration:
        JVM_EXTRA_OPTS: "-Xms1g -Xmx2g"
    

    另外,该语句只能应用于configdb角色,或者可以将不同的内存选项应用于实例定义中的configdb和analyticsdb角色。

    13. libvirt容器无法启动

    ------------------------------------------------------------------------------
    + ./tools/deployment/common/wait-for-pods.sh openstack
    containers failed to start.
    NAME                                  READY     STATUS             RESTARTS   AGE       IP            NODE
    ...
    libvirt-8dhtx                         0/1       CrashLoopBackOff   13         43m       172.17.0.1    ubuntu-2
    nova-compute-default-z8qvb            0/1       CrashLoopBackOff   4          15m       172.17.0.1    ubuntu-2
    ...
    ------------------------------------------------------------------------------
    

    原因:Libvirt默认在许多操作系统上启动。一次只能运行一个libvirt副本。

    解决方法:请检查主机上是否存在libvirtd。如果libvirtd在将成为部署目标的任何计算机上运行,则将其删除/禁用。libvirtd多个实例是不被支持的。

    如何禁用它:

    • 服务libvirt-bin停止
    • update-rc.d libvirt-bin禁用

    在Ubuntu上,apparmor有时会阻止libvirtd正常工作,错误为/usr/sbin/libvirtd: error while loading shared libraries: libvirt-admin.so.0: cannot open shared object file: Permission denied。要修复这个错误,请执行以下命令。

    • sudo apparmor_parser -R /etc/apparmor.d/usr.sbin.libvirtd

    或者只是使用主机的软件包管理器将其删除。

    参考链接:

    https://bugs.launchpad.net/kolla/+bug/1687459/comments/2

    14. 找不到“requests”包而导致的错误

    参考:Bug提交的解决方法(在部署者节点上):

    https://bugs.launchpad.net/juniperopenstack/+bug/1803809

    yum -y install python-pip                                                                                                                                
    pip install requests
    

    直到已经作为容器化解决方案/预安装的一部分得到解决。


    原文链接:

    https://github.com/Juniper/contrail-ansible-deployer/wiki/Contrail-with-Openstack-Kolla

    https://github.com/Juniper/contrail-ansible-deployer/wiki/Provisioning-F.A.Q


    posted in 博客
  • 在K8s上轻松部署Tungsten Fabric的两种方式

    第一种:在AWS的K8s上部署TF

    首先介绍下如何在AWS上使用Kubernetes编排的Tungsten Fabric集群部署沙盒,15分钟就可以搞定。Tungsten Fabric集群由部署节点、一个控制器节点、两个作为EC2 VM运行的计算节点组成。

    要求

    在开始使用沙盒之前,必须订购CentOS 7 x86_64 HVM的正式映像。

    所选区域必须至少具有两个可用区。

    登录到AWS控制台后,请转到AWS Marketplace 的URL。

    点击“继续订购”,然后点击“接受条款”。

    *如果您以IAM用户身份连接,您将无法在AWS Marketplace中执行任务,请查看文档末尾的附录以获取相关解决方案。

    步骤

    1,只需单击以下按钮即可创建沙箱(以AWS CloudFormation堆栈形式运行):

    Launch Stack

    2,点击Next。

    3,指定以下信息:

    4,点击两次Next。

    5,在页面底部选择复选框“ Acknowledge ...”。

    6,点击创建。

    7,重新加载堆栈页面并等待堆栈的CREATE_COMPLETE状态。

    8,选中“Stack”(复选框),然后在底部窗格中选中“Output”选项卡,以找到Sandbox UI的URL。

    579f7f06-bbb0-43f8-930a-0e644b64b6d6-image.png

    9,转到Sandbox UI URL并等待部署(该站点将在创建堆栈后的2-3分钟内可用)。

    10,成功部署后,沙盒界面将提供信息以连接到Tungsten Fabric和Kubernetes服务。

    11,使用Tungsten Fabric用户界面URL,密码登录进行启动。

    重要信息:沙盒使用完毕后,可以使用DELETE SANDBOX按钮清除所有使用的资源。

    75fd2ded-4cf2-4381-ae24-3ebf1345e94f-image.png

    为了双重安全,您可以在删除后检查AWS Interface中的剩余资源。

    访问集群:

    您可以使用在堆栈启动期间指定的ssh密钥来访问具有“centos”用户名的任何VM。

    ssh -i  centos@   #  can be the public IP or the private IP of the node
    sudo -s
    

    沙盒界面将提供有关如何连接到Tungsten Fabric UI和Kubernetes仪表板的信息。

    附录:IAM用户

    如果要使用IAM用户而不是使用root帐户登录,则需要为该用户授予额外的特权。

    • 登录到AWS控制台。
    • 在控制台左上方的AWS服务搜索中,找到IAM并选择它。
    • 在左侧导航栏中,单击需要更改权限的用户。
    • 在右下角单击“Add inline policy)”。
    • 进入“JSON”页签,使用以下内容替换策略内容:
    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "cloudformation:*",
                    "aws-marketplace:*",
                    "sns:*",
                    "s3:*",
                    "ec2:*",
                    "elasticloadbalancing:*",
                    "cloudwatch:*",
                    "autoscaling:*",
                    "iam:*"
                ],
                "Resource": "*"
            }
        ]
    
    }
    
    • 检查策略。添加策略名称。创建策略。

    第二种:通过Centos/Ubuntu“一键安装”

    Tungsten Fabric CNI可以通过多种配置方案安装在Kubernetes集群上。

    这里描述最简单的方法:单个基于yaml的安装。

    先决条件

    1.一个正在运行的Kubernetes集群

    有很多方法可以安装Kubernetes。最简单的是kubeadm:

    https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/

    或者,如果您希望将Tungsten Fabric和K8s集群一起安装,可以使用Tungsten Fabric Ansible Deployer:

    https://github.com/Juniper/contrail-ansible-deployer/wiki/Contrail-microservice-installation-with-kubernetes

    2.所有节点上的Docker版本不低于1.24

    3.Linux内核版本3.10.0-957

    Tungsten Fabric转发使用内核模块来提供高吞吐量和低延迟的网络连接。

    最新的内核模块是针对3.10.0-957内核编译的。

    安装

    将Tungsten Fabric安装到Cento或者Ubuntu上只需要一个步骤。

    注意:将x.x.x.x替换为Kubernetes Master节点的IP。

    对于在Centos系统上安装,请使用以下的命令:

    {% raw %}

    K8S_MASTER_IP=x.x.x.x; CONTRAIL_REPO="docker.io\/opencontrailnightly"; CONTRAIL_RELEASE="latest"; mkdir -pm 777 /var/lib/contrail/kafka-logs; curl https://raw.githubusercontent.com/Juniper/contrail-kubernetes-docs/master/install/kubernetes/templates/contrail-single-step-cni-install-centos.yaml | sed "s/{{ K8S_MASTER_IP }}/$K8S_MASTER_IP/g; s/{{ CONTRAIL_REPO }}/$CONTRAIL_REPO/g; s/{{ CONTRAIL_RELEASE }}/$CONTRAIL_RELEASE/g" | kubectl apply -f -
    

    {% endraw %}

    对于在Ubuntu上安装,请使用以下命令:

    K8S_MASTER_IP=x.x.x.x; CONTRAIL_REPO="docker.io\/opencontrailnightly"; CONTRAIL_RELEASE="latest"; mkdir -pm 777 /var/lib/contrail/kafka-logs; curl https://raw.githubusercontent.com/Juniper/contrail-kubernetes-docs/master/install/kubernetes/templates/contrail-single-step-cni-install-ubuntu.yaml | sed "s/{{ K8S_MASTER_IP }}/$K8S_MASTER_IP/g; s/{{ CONTRAIL_REPO }}/$CONTRAIL_REPO/g; s/{{ CONTRAIL_RELEASE }}/$CONTRAIL_RELEASE/g" | kubectl apply -f -
    

    看看发生了什么?

    太棒了!欢迎来到Tungsten Fabric。

    您已经在Kubernetes节点中安装了Tungsten Fabric CNI。当新的计算节点添加到Kubernetes群集中,Tungsten Fabric CNI也将神奇地自动传播到这些节点,就像背后有Kubernetes DaemaonSet一样。

    同时,您已经安装了整个Tungsten Fabric Networking套件,其中包括Networking、Analytics、Security、Visualization等功能。

    Tungsten Fabric UI在节点的8143端口上可用,可以开始在上面玩了。

    https://x.x.x.x:8143
    Default credentials: admin/contrail123
    

    检查Tungsten Fabric状态

    通过在Kubernetes主节点中运行“contrail-status”命令行工具,可以获得Tungsten Fabric组件的状态。这将列出系统中运行的所有Tungsten Fabric组件。

    71b93b20-7668-4617-8db6-31380dde52b7-image.png 2c5a1217-fc30-4aac-af3e-fd84c76d92fd-image.png

    “Tungsten Fabric+K8s集成指南”系列文章——

    第一篇:部署准备与初始状态
    第二篇:创建虚拟网络
    第三篇:创建安全策略
    第四篇:创建隔离命名空间

    “Tungsten Fabric+K8s轻松上手”系列文章——
    第一篇:TF Carbide 评估指南--准备篇
    第二篇:通过Kubernetes的服务进行基本应用程序连接
    第三篇:通过Kubernetes Ingress进行高级外部应用程序连接
    第四篇:通过Kubernetes命名空间实现初步的应用程序隔离
    第五篇:通过Kubernetes网络策略进行应用程序微分段

    posted in 博客
  • pps数据无法回答“哪种SDN解决方案更好”,你需要考虑这些

    作者:Umberto Manferdini 译者:TF编译组

    原文链接:
    https://iosonounrouter.wordpress.com/2020/04/28/which-sdn-solution-is-better-what-i-learned/

    最近我参与了一个项目,我们在Tungsten Fabric(注:原文为Contrail,本文将以功能一致的Tungsten Fabric替换)集群中部署了虚拟移动网络。移动链虚拟网络的功能类似于Packet Gateway和TCP优化。

    同时,该项目还使用另一个SDN解决方案部署和测试了相同的应用程序链。Tungsten Fabric是L3 SDN解决方案,而另一个是L2 SDN解决方案。

    于是有个大问题跳了出来:哪个方案更好?

    如何看待pps性能数据

    通常,我们倾向于通过性能来回答这个问题。例如“嗯,A方案可以达到10M pps,而B方案只能达到7M pps,所以……”。

    毫无疑问,这很重要,它会对整体解决方案产生影响。例如,如果一种解决方案比另一种快两倍,则可以将虚拟机的数量减少一半(假设虚拟机可以处理所有流量),从而节省了服务器,减少了要管理的设备数量,缩减了许可费用(取决于许可模型)等等……

    是的,pps所代表的性能很重要,而且将永远如此……但是,这并不是全部!

    我认为,在某些情况下,pps所代表的的性能会变得根本不重要。

    考虑在某个计算节点上的情况。通常,你会将它通过以链路聚合(LAG)方式多归属到两个叶子节点(Leaves)的链路连接到IP Fabric。该LAG链路为你提供的总带宽为N*X,其中X是你使用的接口类型(通常为10G或40G)。假设我们使用由2x10G制成的LAG。还要考虑平均数据包的大小(700B)。

    现在,A方案可以达到10M pps性能。通过一些简单的数学运算,我们得到10^7 pps * 710^28 b = 56 Gbps!很高!B方案仅达到7M pps,从而提供约39 Gbps的带宽。在这种情况下,多出来的3M pps将不起作用。因为两种方案都能填充我的LAG,这对我来说足够了……至少在使用平均数据包大小的情况下是这样。

    如果是比较小的数据包(46B),则A方案将达到3.6 Gbps,B方案B仅为2.5 Gbps。这里,我们离LAG 100%的利用率还差得很远,因此pps就更为重要。但问题是,我们是否有必要考虑只有小数据包的网络?

    我们应该确定平均数据包大小,并查看使用这两种解决方案的速度。如果两者都允许达到100%的LAG利用率,那么比较pps并不能帮助我们确定最佳的SDN解决方案。

    “仅仅看原始性能数字还不够”,于是我开始思考其它方面起什么作用,并且是否可以告诉我们A方案和B方案哪个更好。

    为了解决这个问题,我分析了体系架构的各个方面,并从“解决方案角度”而非“纯粹性能角度”进行了研究。

    Overlay的角色

    Tungsten Fabric通过overlay mesh在计算节点之间运行,并且连往SDN网关。MPLSoUDP 或 VxLAN隧道用于承载VM流量。

    这些隧道将发送到虚拟机或从虚拟机发出的实际流量“隐藏”起来。在vRouter内部,每个虚拟网络均配置为众所周知的VRF。就像经典VPN一样,向每个VRF分配MPLS标签,并且VM数据包以封装在DC Fabric中的方式传播(MPLSoUDP是新的MPLSoMPLS,而IP Fabric是新的主干)。

    结果,IP Fabric看不到实际的流量,它只能看到MPLSoUDP(或VxLAN流量)。在这些数据包内部,通过不同的MPLS标签标识了不同的虚拟网络,但这对fabric是完全透明的。

    e1e5df9b-4ed7-43c9-932c-4c86372fab09-image.png

    从fabirc的角度来看这意味着什么?主要是,你只需要配置与Tungsten Fabric数据平面网络关联的单个VLAN。在这个VLAN内有MPLSoUDP,正如我们所说,它隐藏了所有虚拟网络。

    与之不同的是,其它的SDN解决方案使用了另一种方法。不同的虚拟网络作为不同的VLAN退出计算节点。计算节点面向fabric的接口,就像一个经典的中继端口。这意味着每个虚拟网络都成为IP Fabric上的一个VLAN。没有overlay隐藏这种“复杂性”,一切都在那里!

    bdc1eedf-aa7e-44de-8026-9bf8e89b9399-image.png

    归根结底,VM和SDN GW之间的端到端通信在两种情况下均有效,但成本又是多少呢?

    成本与效用

    不要仅仅考虑端点是否可以通信,还要考虑一下配置工作和服务创建的工作量。

    通过使用Tungsten Fabric,你可以一开始就在fabric上创建控制数据平面VLAN。然后,在创建移动链时,不需要在fabric上进行任何更改。

    另一方面,在没有Tungsten Fabric的情况下,每次创建新服务(移动链或其它)时,都必须在SDN和IP Fabric上都配置网络。

    这意味着复杂性增加,出错的几率增加,需要更多的工具实现自动配置(除非你可以接受手动配置fabirc……使用Tungsten Fabric时不建议你这么做),并且通常来说,业务投产并开始从中盈利的周期更长。归根到底,钱永远是很重要的事情。

    这是第一个方面,它帮助我们理解了,当我们以超越纯pps数值来看问题时,两个SDN解决方案会有怎样的不同。

    我说过计算节点使用LAG连接到IP Fabric。理想情况下,你是希望在LAG成员之间平衡流量的。

    使用Tungsten Fabric时,这已经是事实了,我们能够在测试过程中观察到它。

    相反,另一个SDN解决方案使用LAG模式,其中基于源地址对传出流量进行哈希处理。结果,这导致了流量的不均衡。这也意味着不可能完全利用所有LAG带宽。

    从这个角度来看,实际的pps数量的影响甚至更小,甚至不可能100%地使用LAG。

    a306a485-411b-45d1-904c-6f499c7e716b-image.png

    比较结果表明,Tungsten Fabric解决方案能够提供更好的资源利用率,这意味着整个DC基础架构的投资回报率更高。

    路由功能的不同

    正就像我们在电信云中一样,处理移动核心应用程序时,虚拟机不是通常在企业中的那种虚拟机:Web服务器、数据库、前端等……用例不同,因此工作负载也不同。这里的虚拟机使用所需的路由!路由对于交换路由并提供快速收敛至关重要。例如,P-Gateway需要路由至通告地址池。

    Tungsten Fabric原生使用BGP:它使用BGP进行内部通信,使用BGP与SDN GW进行通信,并且将BGP与虚拟机一起使用。最后一个用例通常称为BGPaaS,在VM和vRouter之间建立BGP会话。

    这是可能的,因为Tungsten Fabric是L3 SDN控制器,因此它具有L3功能并且可以识别L3。

    那么,L2 SDN解决方案又有什么不同?

    让我们考虑一个用例:SGi网络。该网络是P-Gateway出口网络。该网络又连接到移动链的下一个元素:在我们的示例中,是TCP优化VNF。

    P-Gateway通过BGP通告用户池……但是去到谁那里呢?

    在Tungsten Fabric当中,P-Gateway通过BGPaaS与TF建立BGP会话。BGPaaS还用于通过TF和TCP优化器之间的另一个BGPaaS会话,将这些路由重新发布到TCP优化器。

    一切都在Tungsten Fabric内部解决和管理了……请记住这一点。

    同样的问题,其它解决方案又是如何面对的呢?

    由于VNF的限制,无法在P-Gateway和TCP优化器之间创建直接会话。结果就是,需要有中间对等节点。由于这是虚拟机之间的对话,因此客户不想让流量流出fabric……因此fabric必须进行路由。这意味着在Spine设备上配置BGP。此外,为了优化流量,P-Gateway发送了数千条“小”路由,所有这些路由都需要在Spine上存储和管理。

    将路由功能迁移到Spine,意味着给本来不作为这个目的的设备带来巨大负担。Spine应该是简单地转发数据包的交换机。在这种情况下,它变成了一个路由器……但是它性能足以成为路由器吗?如果你购买了性能优异的路由器,那么答案是肯定的。而这意味着增加CAPEX,并且花了更多的钱购买功能更强大、价格更高的设备来作为Spine。这是可以接受的吗?没有绝对的答案,但我认为多数时候是“不”会是一个正确的答案。

    另一方面,使用Tungsten Fabric时在fabric上看不到路由:只是在带Tungsten Fabric隧道的单个VLAN上转发数据包。所有这些“小”路由仍然存在,但它们只存在于vRouter上(vRouter作为一种L3设备比交换机更适合这一场景)。那些“小”路由将被进一步通告给SDN GW——这是一个非常合理的路由器,对吗?

    配置上的差别

    b0269625-2b4b-4ecd-8754-79c827f9106f-image.png

    如图所示,在使用Tungsten Fabric时,fabric不参与到控制平面。利用TF内部信号机制,一切都在Tungsten Fabric级别进行管理。

    从fabric上卸下控制平面还意味着更容易创建服务。就像我们之前谈论VLAN时所说的那样,创建服务时不需要在fabric上进行其它配置。整个服务是通过简单地定义一个列出所需虚拟资源的模板(Heat模板)来创建的。如果没有Tungsten Fabric,则需要在fabric上同时具有Heat模板和其它配置……以及我们之前提到的所有后果和考虑因素。

    类似的路由考虑因素都可以对SDN GW执行。在这里,我们考虑的是TCP优化器的出口侧,它发布地址池给SDN GW(此处Fabric仅提供L2)。

    如果没有Tungsten Fabric,则需要配置多个BGP会话(N个TCP优化器和M个SDN GW,即N*M个BGP会话)。

    而在Tungsten Fabric当中,我们可以利用控制节点和SDN GW之间的基础设施BGP会话。在这个会话中,Tungsten Fabric为其所有的虚拟网络发布路由。然后,SDN GW根据VRF中已配置的路由目标将其导入(记得吗?Tungsten Fabric只是DC中的VPN ...)。

    这个过程将会是这样的:VM通过BGPaaS将路由发布到Tungsten Fabric,然后TF通过单个BGP会话将路由重新发布到SDN GW。如果你添加了更多虚拟网络或更多BGPaaS会话,与SDN GW的会话数量也不会改变:始终为1!

    在这种情况下,差异不在于配置的大小层面。两种情况下,你都需要在SDN GW上进行一些配置:是配置一堆VRF,还是一堆路由实例和BGP会话。

    此处的区别在于SDN GW上运行的BGP会话的数量,这可能会影响我们所不能低估的可扩展性。

    fc539453-bb40-4f52-9b14-92f3a22d81c9-image.png

    我们可以看到,Tungsten Fabric和SDN GW之间只有一个BGP会话,而在vRouter和TF控制器之间有多个XMPP(类似BGP协议)。的确如此,但这是Tungsten Fabric体系架构的一部分。Tungsten Fabric启动并运行后,它将自动处理所有这些XMPP内容,对用户是完全透明的。

    从运营人员的角度来看,你只需配置一次Tungsten Fabric-SDN_GW BGP会话,然后就可以在部署应用程序时创建BGPaaS对象。

    运营的视角

    到目前为止,我们已经看到了Tungsten Fabric在服务提供及配置上的优势。当然,SDN解决方案也可以从实际运营的角度进行比较。

    为了获得更高的性能,计算节点使用DPDK进行部署。

    没有Tungsten Fabric的话,很难监视特定的虚拟机接口。

    那么,如果使用Tungsten Fabric,将有一组cli工具,包括类似tcpdump的工具,它们可以识别在dpdk端口上运行的特定VM端口并嗅探通过该端口的流量。

    在故障排除的情景中,使用Tungsten Fabric的解决方案会更加友好。

    故障排除还包含镜像实现的问题。

    TF vRouter支持内置镜像。你可以在一个给定的虚拟机接口上有选择地镜像数据包,并将该流量发送到外部分析器(DPI)。

    如果没有Tungsten Fabric就没法实现了,镜像不得不依赖在IP Fabric上配置的临时解决方案。这意味着给IP Fabric加上了额外的负担,增加了其整体复杂性。

    运营不仅意味着进行故障排除,还意味着监视集群中发生的事情。

    除了OpenStack本地提供的所有元素外,Tungsten Fabric还提供了一个名为Analytics的组件,该组件通过REST API为运营人员提供了大量信息,并能够实时接收警报,以便在出现问题时迅速做出反应。

    这有助于在Tungsten Fabric基础架构上实现更好的控制。

    在这种情况下,基于Tungsten Fabric的SDN解决方案,实际上丰富了由另一个基于L2 SDN的解决方案提供的工具集。

    总之,从更广泛的角度比较这两种解决方案,得出了一些有趣的观点。

    Tungsten Fabric允许使用更薄的IP Fabric——只需要较少的配置更改,并且可以更加专注于其主要目标:以无阻塞并且冗余的方式转发数据包。

    此外,所有与应用程序相关的路由都从fabric上移除了,避免了购买更昂贵的交换机来满足路由所带来的需求的风险。

    节省CPAEX也可以节省OPEX,因为它具有“更稳定的fabric配置”,所需的时间更少。

    由于所有配置都只限于Tungsten Fabric和SDN GW(如果需要),因此可以更快地实施服务。

    同时,基于Tungsten Fabric提供的其它工具,故障排除和监视整个基础设施变得更加容易,这使运营工作更加轻松,因为不再需要为所有事情构建或购买定制化工具,而又降低了成本,。

    “哪种解决方案更好?”一个看起来很简单的问题,实际上包含了很多方面和考虑因素,仅仅比较原始pps数值的做法极易产生误导。

    以上,我主要介绍了由Tungsten Fabric的优点和Tungsten Fabric驱动的解决方案提供的优势。我是站在TF一边的,所以,我得承认我并不是中立的。

    无论如何,我想表达的核心观点是,对比涉及整个DC的SDN控制器之类的复杂解决方案,或者不限于此的方案,不能简化为仅对pps数值进行简单比较。

    posted in 博客
  • TF实战Q&A丨不是一句话可以搞定的

    在TF中文社区,爱折腾的“实战派”们经常探讨有关SDN和Tungsten Fabric的各种问题,我们将其中的精华部分整理出来,形成 “ TF实战 Q&A ” 栏目,他们碰到的困惑、踩过的坑,也许正是你想要了解的——

    9362de2c-4549-416f-a872-257b31da7bb9-image.png
    e686acd2-21a0-44c4-9464-d344d973ce33-image.png
    3a06eacd-6897-4391-926e-3641110c59ea-image.png
    2341e8ef-b66b-41f2-960c-53deae88d8ce-image.png
    9741b9c5-68bd-4762-ab67-be2dbd6ee2a6-image.png
    eb080859-3c36-46d5-9773-6309c93d22a7-image.png
    e58a0530-53ce-492c-afcf-aa3defd6ede3-image.png

    以上,就是本期的TF中文社区问答交流精选集。不知道这几期 【 TF 实战 Q&A 】 有没有戳中你关心的问题?你还希望看到什么内容?

    添加TF中文社区小助手微信:tungstenfabric , 加入CTF技术群。欢迎大家提出您的疑问,我们一起沟通探讨。

    Tungsten Fabric 推荐阅读
    TF实战Q&A丨你不理解透,出了问题都不知道怎么弄
    TF 实战Q&A丨只在此网中,云深不知处
    TF实战 Q&A丨这个问题,我以前也遇到过
    TF实战丨使用Vagrant安装Tungsten Fabric
    Tungsten Fabric实战:对接vMX虚拟路由平台填坑
    Tungsten Fabric实战:基于K8s的部署踩坑

    Tungsten Fabric 架构解析
    第一篇:TF主要特点和用例
    第二篇:TF怎么运作
    第三篇:详解vRouter体系结构
    第四篇:TF的服务链
    第五篇:vRouter的部署选项
    第六篇:TF如何收集、分析、部署?
    第七篇:TF如何编排
    第八篇:TF支持API一览
    第九篇:TF如何连接到物理网络?
    第十篇:TF基于应用程序的安全策略

    posted in 博客
  • Tungsten Fabric知识库丨这里有18个TF补丁程序,建议收藏

    作者:Tatsuya Naganawa 译者:TF编译组

    静态scheduler:用于svc-monitor logic选择可用的vRouter

    diff --git a/src/config/svc-monitor/svc_monitor/scheduler/vrouter_scheduler.py b
    index f40de26..d5c2478 100644
    --- a/src/config/svc-monitor/svc_monitor/scheduler/vrouter_scheduler.py
    +++ b/src/config/svc-monitor/svc_monitor/scheduler/vrouter_scheduler.py
    @@ -200,3 +200,8 @@ class RandomScheduler(VRouterScheduler):
             self._vnc_lib.ref_update('virtual-router', chosen_vrouter,
                 'virtual-machine', vm.uuid, None, 'ADD')
             return chosen_vrouter
    +
    +class StaticScheduler(VRouterScheduler):
    +    """Statically assign vRouter nodes for v1 service-chain, haproxy lb, SNAT e
    +    def schedule(self, si, vm):
    +        return ['bms11', 'bms12']
    

    从svc-monitor logic中解耦analytics

    diff --git a/src/config/svc-monitor/svc_monitor/scheduler/vrouter_scheduler.py b/src/config/svc-monitor/svc_monitor/scheduler/vrouter_scheduler.
    index f40de26..7fd1f0a 100644
    --- a/src/config/svc-monitor/svc_monitor/scheduler/vrouter_scheduler.py
    +++ b/src/config/svc-monitor/svc_monitor/scheduler/vrouter_scheduler.py
    @@ -115,6 +115,8 @@ class VRouterScheduler(object):
             return response_dict
    
         def vrouters_running(self):
    +        ## implement logic to see available vRouter, without checking analytics response (possible choice is xmpp status from control node)
    +
             # get az host list
             az_vrs = self._get_az_vrouter_list()
    

    https://review.opencontrail.org/c/Juniper/contrail-controller/+/59457

    更具扩展性的haproxy负载均衡器和SNAT

    diff --git a/src/config/svc-monitor/svc_monitor/services/loadbalancer/drivers/ha_proxy/driver.py b/src/config/svc-monitor/svc_monitor/services/loadbalancer/drivers/ha_proxy/driver.py
    index 5487b2b..1bee992 100644
    --- a/src/config/svc-monitor/svc_monitor/services/loadbalancer/drivers/ha_proxy/driver.py
    +++ b/src/config/svc-monitor/svc_monitor/services/loadbalancer/drivers/ha_proxy/driver.py
    @@ -92,8 +92,8 @@ class OpencontrailLoadbalancerDriver(
    
             # set interfaces and ha
             props.set_interface_list(if_list)
    -        props.set_ha_mode('active-standby')
    -        scale_out = ServiceScaleOutType(max_instances=2, auto_scale=False)
    +        props.set_ha_mode('active-active')
    +        scale_out = ServiceScaleOutType(max_instances=10, auto_scale=False)
             props.set_scale_out(scale_out)
    
             return props
    diff --git a/src/config/svc-monitor/svc_monitor/snat_agent.py b/src/config/svc-monitor/svc_monitor/snat_agent.py
    index 54ea709..f5bce37 100644
    --- a/src/config/svc-monitor/svc_monitor/snat_agent.py
    +++ b/src/config/svc-monitor/svc_monitor/snat_agent.py
    @@ -169,7 +169,7 @@ class SNATAgent(Agent):
                 si_obj.fq_name = project_fq_name + [si_name]
                 si_created = True
             si_prop_obj = ServiceInstanceType(
    -            scale_out=ServiceScaleOutType(max_instances=2,
    +            scale_out=ServiceScaleOutType(max_instances=10,
                                               auto_scale=True),
                 auto_policy=False)
    
    @@ -181,7 +181,7 @@ class SNATAgent(Agent):
             right_if = ServiceInstanceInterfaceType(
                 virtual_network=':'.join(vn_obj.fq_name))
             si_prop_obj.set_interface_list([right_if, left_if])
    -        si_prop_obj.set_ha_mode('active-standby')
    +        si_prop_obj.set_ha_mode('active-active')
    
             si_obj.set_service_instance_properties(si_prop_obj)
             si_obj.set_service_template(st_obj)
    

    三个XMPP连接(以覆盖双重故障情景)

    diff --git a/src/vnsw/agent/cmn/agent.h b/src/vnsw/agent/cmn/agent.h
    index 3e48812..832b476 100644
    --- a/src/vnsw/agent/cmn/agent.h
    +++ b/src/vnsw/agent/cmn/agent.h
    @@ -284,7 +284,10 @@ extern void RouterIdDepInit(Agent *agent);
     #define MULTICAST_LABEL_BLOCK_SIZE 2048
    
     #define MIN_UNICAST_LABEL_RANGE 4098
    -#define MAX_XMPP_SERVERS 2
    +
    +/* to cover double failure case */
    +#define MAX_XMPP_SERVERS 3 
    +
     #define XMPP_SERVER_PORT 5269
     #define XMPP_DNS_SERVER_PORT 53
     #define METADATA_IP_ADDR ntohl(inet_addr("169.254.169.254"))
    

    静态XMPP分配

    contrail-controller:

    diff --git a/src/vnsw/agent/cmn/agent.cc b/src/vnsw/agent/cmn/agent.cc
    index 607f384..71d27d8 100644
    --- a/src/vnsw/agent/cmn/agent.cc
    +++ b/src/vnsw/agent/cmn/agent.cc
    @@ -469,7 +469,7 @@ void Agent::CopyFilteredParams() {
         if (new_chksum != controller_chksum_) {
             controller_chksum_ = new_chksum;
             controller_list_ = params_->controller_server_list();
    -        std::random_shuffle(controller_list_.begin(), controller_list_.end());
    +        std::random_shuffle(controller_list_.begin(), controller_list_.end()); // commented out for static XMPP assignment
         }
    
         // Dns
    

    基于VLAN的EVPN T2互操作

    diff --git a/src/bgp/evpn/evpn_route.cc b/src/bgp/evpn/evpn_route.cc
    index 36412b2..a830b5c 100644
    --- a/src/bgp/evpn/evpn_route.cc
    +++ b/src/bgp/evpn/evpn_route.cc
    @@ -487,7 +487,7 @@ void EvpnPrefix::BuildProtoPrefix(BgpProtoPrefix *proto_prefix,
                     proto_prefix->prefix.begin() + esi_offset);
             }
             size_t tag_offset = esi_offset + kEsiSize;
    -        put_value(&proto_prefix->prefix[tag_offset], kTagSize, tag_);
    +        put_value(&proto_prefix->prefix[tag_offset], kTagSize, 0);
             size_t mac_len_offset = tag_offset + kTagSize;
             proto_prefix->prefix[mac_len_offset] = 48;
             size_t mac_offset = mac_len_offset + 1;
    

    “enable_nova: no”是可配置的

    (已实施)
    https://review.opencontrail.org/c/Juniper/contrail-kolla-ansible/+/58908

    git clone -b contrail/queens https://github.com/Juniper/contrail-kolla-ansible
    
    diff --git a/ansible/post-deploy-contrail.yml b/ansible/post-deploy-contrail.yml
    index e603207..c700d88 100644
    --- a/ansible/post-deploy-contrail.yml
    +++ b/ansible/post-deploy-contrail.yml
    @@ -63,6 +63,8 @@
           - ['baremetal-hosts', 'virtual-hosts']
         register: command_result
         failed_when: "command_result.rc == 1 and 'already exists' not in command_result.stderr"
    +    when:
    +      - enable_nova | bool
         run_once: yes
    
       - name: Add compute hosts to virtual-hosts Aggregate Group
    

    每个标签的安全端点统计信息作为UVE

    https://review.opencontrail.org/c/Juniper/contrail-specs/+/55761

    kubernetes的多master设置

    (已实施)

    1. https://review.opencontrail.org/c/Juniper/contrail-controller/+/55758

    2. https://github.com/tnaganawa/tungstenfabric-docs/blob/master/TungstenFabricPrimer.md#k8sk8s

    tc-flower卸载

    对此感兴趣的朋友,
    
    我尝试了两种vRouter设置,并在一个节点上键入了这些命令以绕过vRouter数据路径,来使用tc,
    发现基于tc-flower的vxlan数据路径(出口)和vRouter的vxlan数据路径可以互通:)
      -ingress vxlan decap无法正常运作,我仍在调查..
    
    vRouter0: 172.31.4.175 (container, 10.0.1.251)
    vRouter1: 172.31.1.214 (container, 10.0.1.250, connected to tapeth0-038fdd)
    
    [from specific tap to known ip address, vxlan encap could be offloaded to tc]
     - typed on vRouter1
    ip link set vxlan7 up
    ip link add vxlan7 type vxlan vni 7 dev ens5 dstport 0 external
    tc filter add dev tapeth0-038fdd protocol ip parent ffff: \
                    flower \
                      ip_proto icmp dst_ip 10.0.1.251 \
                    action simple sdata "ttt" action tunnel_key set \
                      src_ip 172.31.1.214 \
                      dst_ip 172.31.4.175 \
                      id 7 \
                      dst_port 4789 \
                    action mirred egress redirect dev vxlan7
    
    [although for egress traffic vRouter1 is bypassed, it can still communicate]
    
    [root@ip-172-31-1-214 ~]# tcpdump -nn -i ens5 udp
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on ens5, link-type EN10MB (Ethernet), capture size 262144 bytes
    04:55:41.566458 IP 172.31.1.214.57877 > 172.31.4.175.4789: VXLAN, flags [I] (0x08), vni 7
    IP 10.0.1.250 > 10.0.1.251: ICMP echo request, id 60416, seq 180, length 64
    04:55:41.566620 IP 172.31.4.175.61117 > 172.31.1.214.4789: VXLAN, flags [I] (0x08), vni 7
    IP 10.0.1.251 > 10.0.1.250: ICMP echo reply, id 60416, seq 180, length 64
    04:55:42.570917 IP 172.31.1.214.57877 > 172.31.4.175.4789: VXLAN, flags [I] (0x08), vni 7
    IP 10.0.1.250 > 10.0.1.251: ICMP echo request, id 60416, seq 181, length 64
    04:55:42.571056 IP 172.31.4.175.61117 > 172.31.1.214.4789: VXLAN, flags [I] (0x08), vni 7
    IP 10.0.1.251 > 10.0.1.250: ICMP echo reply, id 60416, seq 181, length 64
    ^C
    4 packets captured
    5 packets received by filter
    0 packets dropped by kernel
    [root@ip-172-31-1-214 ~]#
    
    / # ping 10.0.1.251
    PING 10.0.1.251 (10.0.1.251): 56 data bytes
    64 bytes from 10.0.1.251: seq=0 ttl=64 time=5.183 ms
    64 bytes from 10.0.1.251: seq=1 ttl=64 time=4.587 ms
    ^C
    --- 10.0.1.251 ping statistics ---
    2 packets transmitted, 2 packets received, 0% packet loss
    round-trip min/avg/max = 4.587/4.885/5.183 ms
    / # 
    
    [tap's RX is not incrementing since that is bypassed (TX increments, since ingress traffic still uses vRouter datapath)]
    
    [root@ip-172-31-1-214 ~]# vif --get 8 | grep bytes
                RX packets:3393  bytes:288094 errors:0
                TX packets:3438  bytes:291340 errors:0
    [root@ip-172-31-1-214 ~]# vif --get 8 | grep bytes
                RX packets:3393  bytes:288094 errors:0
                TX packets:3439  bytes:291438 errors:0
    [root@ip-172-31-1-214 ~]# vif --get 8 | grep bytes
                RX packets:3394  bytes:288136 errors:0
                TX packets:3442  bytes:291676 errors:0
    [root@ip-172-31-1-214 ~]# vif --get 8 | grep bytes
                RX packets:3394  bytes:288136 errors:0
                TX packets:3444  bytes:291872 errors:0
    [root@ip-172-31-1-214 ~]# vif --get 8 | grep bytes
                RX packets:3394  bytes:288136 errors:0
                TX packets:3447  bytes:292166 errors:0
    [root@ip-172-31-1-214 ~]#
    
    contrail-controller
    
    diff --git a/src/vnsw/agent/pkt/flow_mgmt.cc b/src/vnsw/agent/pkt/flow_mgmt.cc
    index c888a26..a1b0189 100644
    --- a/src/vnsw/agent/pkt/flow_mgmt.cc
    +++ b/src/vnsw/agent/pkt/flow_mgmt.cc
    @@ -511,6 +511,9 @@ void FlowMgmtManager::LogFlowUnlocked(FlowEntry *flow, const std::string &op) {
         FlowInfo trace;
         flow->FillFlowInfo(trace);
         FLOW_TRACE(Trace, op, trace);
    +
    +    // Add tc flower logic, based on FlowEntry *flow
    + 
     }
    
     // Extract all the FlowMgmtKey for a flow
    

    GCE上的vRouter无法到达同一子网中的其它节点

    在GCE中安装vRouter时,它无法到达同一子网中的某个节点。该补丁是一个临时的解决方法。

    diff --git a/containers/vrouter/agent/entrypoint.sh b/containers/vrouter/agent/entrypoint.sh
    index f4f49f4..01e1349 100755
    --- a/containers/vrouter/agent/entrypoint.sh
    +++ b/containers/vrouter/agent/entrypoint.sh
    @@ -140,7 +140,7 @@ if [ "$gcp" == "Google" ]; then
         for intf in $intfs ; do
             if [[ $phys_int_mac == "$(curl -s http://metadata.google.internal/computeMetadata/v1beta1/instance/network-interfaces/${intf}/mac)" ]]; then
                 mask=$(curl -s http://metadata.google.internal/computeMetadata/v1beta1/instance/network-interfaces/${intf}/subnetmask)
    -            vrouter_cidr=$vrouter_ip/$(mask2cidr $mask)
    +            vrouter_cidr=$vrouter_ip/31  ### this can't be set /32, since in that setup, vrouter can't create ingress flow for some reason ..
             fi
         done
     fi
    

    何时与multus一起使用

    (已实施)

    提交后发现,vRouter可以很好地与multus-cni一起工作(它可以动态识别是直接调用还是由某些元插件调用)。

    (install kubernetes and vRouter by ansible-deployer: container tag: master-latest, ansible-deployer: master)
    git clone https://github.com/intel/multus-cni.git && cd multus-cni
    cat ./images/deprecated/multus-daemonset-pre-1.16.yml | kubectl apply -f -
    

    注意:由于ansible-deployer安装了v0.3.0 CNI,因此默认情况下,桥接CNI不能正常工作。将/opt/cni/bin/bridge(和/opt/cni/bin/static)文件替换为v0.8.6模块时,它可以正常工作。

    多vCenter设置

    Tungsten Fabric控制器节点提供的vCenter插件数量与vCenter数量一样多。

    由于每个vCenter下都有多个ESXi,因此对于某个特定vCenter的ESXi,其vRouterVM上的每个vcenter-manager,都需要使用该租户名称(而不是硬编码的“vCenter”租户)来配置。

    contrail-vcenter-plugin:
    diff --git a/src/net/juniper/contrail/vcenter/VCenterMonitor.java b/src/net/juniper/contrail/vcenter/VCenterMonitor.java
    index d5c0043..294ee99 100644
    --- a/src/net/juniper/contrail/vcenter/VCenterMonitor.java
    +++ b/src/net/juniper/contrail/vcenter/VCenterMonitor.java
    @@ -74,7 +74,7 @@ public class VCenterMonitor {
         private static String _authurl           = "http://10.84.24.54:35357/v2.0";
    
         private static String _zookeeperAddrPort  = "127.0.0.1:2181";
    -    private static String _zookeeperLatchPath = "/vcenter-plugin";
    +    private static String _zookeeperLatchPath = "/vcenter-plugin"; // make this configurable
         private static String _zookeeperId        = "node-vcenter-plugin";
    
         static volatile Mode mode  = Mode.VCENTER_ONLY;
    diff --git a/src/net/juniper/contrail/vcenter/VncDB.java b/src/net/juniper/contrail/vcenter/VncDB.java
    index 9d004b7..a831a37 100644
    --- a/src/net/juniper/contrail/vcenter/VncDB.java
    +++ b/src/net/juniper/contrail/vcenter/VncDB.java
    @@ -61,8 +61,8 @@ public class VncDB {
         Mode mode;
    
         public static final String VNC_ROOT_DOMAIN     = "default-domain";
    -    public static final String VNC_VCENTER_PROJECT = "vCenter";
    -    public static final String VNC_VCENTER_IPAM    = "vCenter-ipam";
    +    public static final String VNC_VCENTER_PROJECT = "vCenter"; // make this configurable
    +    public static final String VNC_VCENTER_IPAM    = "vCenter-ipam"; // make this configurable
         public static final String VNC_VCENTER_DEFAULT_SG    = "default";
         public static final String VNC_VCENTER_PLUGIN  = "vcenter-plugin";
         public static final String VNC_VCENTER_TEST_PROJECT = "vCenter-test";
    
    
    contrail-vcenter-manager:
    diff --git a/cvm/constants.py b/cvm/constants.py
    index 0dcabab..4b30299 100644
    --- a/cvm/constants.py
    +++ b/cvm/constants.py
    @@ -31,8 +31,8 @@ VM_UPDATE_FILTERS = [
         'runtime.powerState',
     ]
     VNC_ROOT_DOMAIN = 'default-domain'
    -VNC_VCENTER_PROJECT = 'vCenter'
    -VNC_VCENTER_IPAM = 'vCenter-ipam'
    +VNC_VCENTER_PROJECT = 'vCenter' ## make this configurable
    +VNC_VCENTER_IPAM = 'vCenter-ipam' ## make this configurable
     VNC_VCENTER_IPAM_FQN = [VNC_ROOT_DOMAIN, VNC_VCENTER_PROJECT, VNC_VCENTER_IPAM]
     VNC_VCENTER_DEFAULT_SG = 'default'
     VNC_VCENTER_DEFAULT_SG_FQN = [VNC_ROOT_DOMAIN, VNC_VCENTER_PROJECT, VNC_VCENTER_DEFAULT_SG]
    

    在所有计算节点上使用相同的ECMP散列,以实现数据包模式下的对称ECMP

    (已实施)

    diff --git a/src/vnsw/agent/pkt/pkt_handler.cc b/src/vnsw/agent/pkt/pkt_handler.cc
    index 28e5637..075bb17 100644
    --- a/src/vnsw/agent/pkt/pkt_handler.cc
    +++ b/src/vnsw/agent/pkt/pkt_handler.cc
    @@ -1304,7 +1304,7 @@ std::size_t PktInfo::hash(const Agent *agent,
         // We need to ensure that hash computed in Compute-1 and Compute-2 are
         // different. We also want to have same hash on agent restarts. So, include
         // vhost-ip also to compute hash
    -    boost::hash_combine(seed, agent->router_id().to_ulong());
    +    ////// boost::hash_combine(seed, agent->router_id().to_ulong());
    
         if (family == Address::INET) {
             if (ecmp_load_balance.is_source_ip_set()) {
    

    使用透明服务链时指定vlan-id

    # diff -u config_db.py.orig config_db.py
    --- config_db.py.orig 2019-08-04 10:54:22.993291899 +0000
    +++ config_db.py 2019-08-04 13:05:23.665843100 +0000
    @@ -3059,6 +3062,21 @@
                                         service_ri1, service_ri2):
             vlan = self._object_db.allocate_service_chain_vlan(vm_info['vm_uuid'],
                                                                self.name)
    +        ####
    +        ## vlan-id is embedded in service-instance name
    +        ## servicename---vm_uuid---vlanid
    +        ####
    +        for servicename in self.service_list:
    +          left_interface_uuid = vm_info['left']['vmi'].name.split (':')[-1]
    +          if (servicename.find(left_interface_uuid ) > -1):
    +            vlan = servicename.split(':')[-1].split('---')[-1]
    +
             self.add_pbf_rule(vm_info['left']['vmi'], service_ri1,
                               v4_address, v6_address, vlan)
             self.add_pbf_rule(vm_info['right']['vmi'], service_ri2,
    @@ -3911,6 +3929,22 @@
                     vlan = self._object_db.allocate_service_chain_vlan(
                         vm_pt.uuid, service_chain.name)
    
    +
    +                ###
    +                # begin: added
    +                ###
    +                for servicename in service_chain.service_list:
    +                  if (servicename.find(self.name.split(':')[-1]) > -1):
    +                    vlan = servicename.split(':')[-1].split('---')[-1]
    +                ###
    +                # end: added
    +                ###
    +
                     service_chain.add_pbf_rule(self, service_ri, v4_address,
                                                v6_address, vlan)
                 #end for service_chain
    

    支持CentOS的旧内核

    Juniper/contrail-packages

    diff --git a/kernel_version.info b/kernel_version.info
    index 8d38f34..d5e711b 100644
    --- a/kernel_version.info
    +++ b/kernel_version.info
    @@ -1,2 +1,3 @@
    +3.10.0-862.2.3.el7.x86_64
     3.10.0-1062.4.1.el7.x86_64
    -3.10.0-1062.9.1.el7.x86_64
    \ No newline at end of file
    +3.10.0-1062.9.1.el7.x86_64
    

    可配置的最小路由目标ID

    diff --git a/src/config/common/cfgm_common/__init__.py b/src/config/common/cfgm_common/__init__.py
    index 088b03b..dd484ab 100644
    --- a/src/config/common/cfgm_common/__init__.py
    +++ b/src/config/common/cfgm_common/__init__.py
    @@ -18,7 +18,7 @@ DCI_VN_FQ_NAME = ['default-domain', 'default-project', 'dci-network']
     DCI_IPAM_FQ_NAME = ['default-domain', 'default-project', 'default-dci-lo0-network-ipam']
     OVERLAY_LOOPBACK_FQ_PREFIX = ['default-domain', 'default-project']
    
    -_BGP_RTGT_MIN_ID_TYPE0 = 8000000
    +_BGP_RTGT_MIN_ID_TYPE0 = 8100000
     _BGP_RTGT_MIN_ID_TYPE1_2 = 8000
     SGID_MIN_ALLOC = 8000000
     VNID_MIN_ALLOC = 1
    

    使用Linux 5.x内核构建vRouter失败问题

    https://review.opencontrail.org/c/Juniper/contrail-vrouter/+/57506


    原文链接:
    https://github.com/tnaganawa/tungstenfabric-docs/blob/master/TungstenFabricKnowledgeBase.md


    往期精选

    Tungsten Fabric知识库丨vRouter内部运行探秘
    Tungsten Fabric知识库丨更多组件内部探秘
    Tungsten Fabric知识库丨 构建、安装与公有云部署
    Tungsten Fabric知识库丨测试2000个vRouter节点部署
    Tungsten Fabric知识库丨关于OpenStack、K8s、CentOS安装问题的补充

    Tungsten Fabric入门宝典系列文章——
    1.首次启动和运行指南
    2.TF组件的七种“武器”
    3.编排器集成
    4.关于安装的那些事(上)
    5.关于安装的那些事(下)
    6.主流监控系统工具的集成
    7.开始第二天的工作
    8.8个典型故障及排查Tips
    9.关于集群更新的那些事
    10.说说L3VPN及EVPN集成
    11.关于服务链、BGPaaS及其它
    12.关于多集群和多数据中心
    13.多编排器用法及配置

    posted in 博客
  • Tungsten Fabric知识库丨关于OpenStack、K8s、CentOS安装问题的补充(下)

    Tungsten Fabric知识库丨关于OpenStack、K8s、CentOS安装问题的补充(上)

    CentOS 8安装过程

    centos8.2
    ansible-deployer is used
    
    only python3 is used (no python2)
     - 需要ansible 2.8.x
    
    1 x for tf-controller and kube-master, 1 vRouter
    
    (all nodes)
    yum install python3 chrony
    alternatives --set python /usr/bin/python3
    
    (vRouter nodes)
    yum install network-scripts
     - 这是必需的,因为vRouter当前不支持NetworkManager
    
    (ansible node)
    sudo yum -y install git
    sudo pip3 install PyYAML requests ansible\           
    cirros-deployment-86885fbf85-tjkwn   1/1     Running   0          13s   10.47.255.249   ip-172-31-2-120.ap-northeast-1.compute.internal              
    [root@ip-172-31-7-20 ~]# 
    [root@ip-172-31-7-20 ~]# 
    [root@ip-172-31-7-20 ~]# kubectl exec -it cirros-deployment-86885fbf85-7z78k sh
    / # ip -o a
    1: lo    inet 127.0.0.1/8 scope host lo\       valid_lft forever preferred_lft forever
    17: eth0    inet 10.47.255.250/12 scope global eth0\       valid_lft forever preferred_lft forever
    / # ping 10.47.255.249
    PING 10.47.255.249 (10.47.255.249): 56 data bytes
    64 bytes from 10.47.255.249: seq=0 ttl=63 time=0.657 ms
    64 bytes from 10.47.255.249: seq=1 ttl=63 time=0.073 ms
    ^C
    --- 10.47.255.249 ping statistics ---
    2 packets transmitted, 2 packets received, 0% packet loss
    round-trip min/avg/max = 0.073/0.365/0.657 ms
    / # 
    
    
     - 为了使chrony在安装路由器后正常工作,可能需要重新启动chrony服务器
    
    [root@ip-172-31-4-206 ~]#  chronyc -n sources
    210 Number of sources = 5
    MS Name/IP address         Stratum Poll Reach LastRx Last sample               
    ===============================================================================
    ^? 169.254.169.123               3   4     0   906  -8687ns[  -12us] +/-  428us
    ^? 129.250.35.250                2   7     0  1002   +429us[ +428us] +/-   73ms
    ^? 167.179.96.146                2   7     0   937   +665us[ +662us] +/- 2859us
    ^? 194.0.5.123                   2   6     0  1129   +477us[ +473us] +/-   44ms
    ^? 103.202.216.35                3   6     0   933  +9662ns[+6618ns] +/-  145ms
    [root@ip-172-31-4-206 ~]# 
    [root@ip-172-31-4-206 ~]# 
    [root@ip-172-31-4-206 ~]# service chronyd status
    Redirecting to /bin/systemctl status chronyd.service
    · chronyd.service - NTP client/server
       Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; vendor preset: enabled)
       Active: active (running) since Sun 2020-06-28 16:00:34 UTC; 33min ago
         Docs: man:chronyd(8)
               man:chrony.conf(5)
     Main PID: 727 (chronyd)
        Tasks: 1 (limit: 49683)
       Memory: 2.1M
       CGroup: /system.slice/chronyd.service
               └─727 /usr/sbin/chronyd
    
    Jun 28 16:00:33 localhost.localdomain chronyd[727]: Using right/UTC timezone to obtain leap second data
    Jun 28 16:00:34 localhost.localdomain systemd[1]: Started NTP client/server.
    Jun 28 16:00:42 localhost.localdomain chronyd[727]: Selected source 169.254.169.123
    Jun 28 16:00:42 localhost.localdomain chronyd[727]: System clock TAI offset set to 37 seconds
    Jun 28 16:19:33 ip-172-31-4-206.ap-northeast-1.compute.internal chronyd[727]: Source 167.179.96.146 offline
    Jun 28 16:19:33 ip-172-31-4-206.ap-northeast-1.compute.internal chronyd[727]: Source 103.202.216.35 offline
    Jun 28 16:19:33 ip-172-31-4-206.ap-northeast-1.compute.internal chronyd[727]: Source 129.250.35.250 offline
    Jun 28 16:19:33 ip-172-31-4-206.ap-northeast-1.compute.internal chronyd[727]: Source 194.0.5.123 offline
    Jun 28 16:19:33 ip-172-31-4-206.ap-northeast-1.compute.internal chronyd[727]: Source 169.254.169.123 offline
    Jun 28 16:19:33 ip-172-31-4-206.ap-northeast-1.compute.internal chronyd[727]: Can't synchronise: no selectable sources
    [root@ip-172-31-4-206 ~]# service chronyd restart
    Redirecting to /bin/systemctl restart chronyd.service
    [root@ip-172-31-4-206 ~]# 
    [root@ip-172-31-4-206 ~]# 
    [root@ip-172-31-4-206 ~]# service chronyd status
    Redirecting to /bin/systemctl status chronyd.service
    · chronyd.service - NTP client/server
       Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; vendor preset: enabled)
       Active: active (running) since Sun 2020-06-28 16:34:41 UTC; 2s ago
         Docs: man:chronyd(8)
               man:chrony.conf(5)
      Process: 25252 ExecStartPost=/usr/libexec/chrony-helper update-daemon (code=exited, status=0/SUCCESS)
      Process: 25247 ExecStart=/usr/sbin/chronyd $OPTIONS (code=exited, status=0/SUCCESS)
     Main PID: 25250 (chronyd)
        Tasks: 1 (limit: 49683)
       Memory: 1.0M
       CGroup: /system.slice/chronyd.service
               └─25250 /usr/sbin/chronyd
    
    Jun 28 16:34:41 ip-172-31-4-206.ap-northeast-1.compute.internal systemd[1]: Starting NTP client/server...
    Jun 28 16:34:41 ip-172-31-4-206.ap-northeast-1.compute.internal chronyd[25250]: chronyd version 3.5 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND>
    Jun 28 16:34:41 ip-172-31-4-206.ap-northeast-1.compute.internal chronyd[25250]: Frequency 35.298 +/- 0.039 ppm read from /var/lib/chrony/drift
    Jun 28 16:34:41 ip-172-31-4-206.ap-northeast-1.compute.internal chronyd[25250]: Using right/UTC timezone to obtain leap second data
    Jun 28 16:34:41 ip-172-31-4-206.ap-northeast-1.compute.internal systemd[1]: Started NTP client/server.
    [root@ip-172-31-4-206 ~]#  chronyc -n sources
    210 Number of sources = 5
    MS Name/IP address         Stratum Poll Reach LastRx Last sample               
    ===============================================================================
    ^* 169.254.169.123               3   4    17     4  -2369ns[  -27us] +/-  451us
    ^- 94.154.96.7                   2   6    17     5    +30ms[  +30ms] +/-  148ms
    ^- 185.51.192.34                 2   6    17     3  -2951us[-2951us] +/-  150ms
    ^- 188.125.64.6                  2   6    17     3  +9526us[+9526us] +/-  143ms
    ^- 216.218.254.202               1   6    17     5    +15ms[  +15ms] +/-   72ms
    [root@ip-172-31-4-206 ~]# 
    
    
    [root@ip-172-31-4-206 ~]# contrail-status 
    Pod      Service      Original Name           Original Version  State    Id            Status         
             rsyslogd                             nightly-master    running  5fc76e57c156  Up 16 minutes  
    vrouter  agent        contrail-vrouter-agent  nightly-master    running  bce023d8e6e0  Up 5 minutes   
    vrouter  nodemgr      contrail-nodemgr        nightly-master    running  9439a304cbcf  Up 5 minutes   
    vrouter  provisioner  contrail-provisioner    nightly-master    running  1531b1403e49  Up 5 minutes   
    
    WARNING: container with original name '' have Pod or Service empty. Pod: '' / Service: 'rsyslogd'. Please pass NODE_TYPE with pod name to container's env
    
    vrouter kernel module is PRESENT
    == Contrail vrouter ==
    nodemgr: active
    agent: active
    
    [root@ip-172-31-4-206 ~]#
    

    原文链接:
    https://github.com/tnaganawa/tungstenfabric-docs/blob/master/TungstenFabricKnowledgeBase.md


    往期精选

    Tungsten Fabric知识库丨vRouter内部运行探秘
    Tungsten Fabric知识库丨更多组件内部探秘
    Tungsten Fabric知识库丨 构建、安装与公有云部署
    Tungsten Fabric知识库丨测试2000个vRouter节点部署

    Tungsten Fabric入门宝典系列文章——
    1.首次启动和运行指南
    2.TF组件的七种“武器”
    3.编排器集成
    4.关于安装的那些事(上)
    5.关于安装的那些事(下)
    6.主流监控系统工具的集成
    7.开始第二天的工作
    8.8个典型故障及排查Tips
    9.关于集群更新的那些事
    10.说说L3VPN及EVPN集成
    11.关于服务链、BGPaaS及其它
    12.关于多集群和多数据中心
    13.多编排器用法及配置

    posted in 博客
  • Tungsten Fabric知识库丨关于OpenStack、K8s、CentOS安装问题的补充(上)

    作者:Tatsuya Naganawa 译者:TF编译组

    多kube-master部署

    3个Tungsten Fabric控制器节点:m3.xlarge(4 vcpu)-> c3.4xlarge(16 vcpu)(由于schema-transformer需要cpu资源进行acl计算,因此我需要添加资源)
    100 kube-master, 800 workers: m3.medium

    在下面这个链接内容中,tf-controller安装和first-containers.yaml是相同的

    Ami也相同(ami-3185744e),但是内核版本通过yum -y update kernel(转换为映像,并用于启动实例)更新

    /tmp/aaa.pem是ec2实例中指定的密钥对

    附cni.yaml文件:

    (在其中一个Tungsten Fabric控制器节点键入命令)
    yum -y install epel-release
    yum -y install parallel
    
    aws ec2 describe-instances --query 'Reservations[*].Instances[*].PrivateIpAddress' --output text | tr '\t' '\n' > /tmp/all.txt
    head -n 100 /tmp/all.txt > masters.txt
    tail -n 800 /tmp/all.txt > workers.txt
    
    ulimit -n 4096
    cat all.txt | parallel -j1000 ssh -i /tmp/aaa.pem -o StrictHostKeyChecking=no centos@{} id
    cat all.txt | parallel -j1000 ssh -i /tmp/aaa.pem centos@{} sudo sysctl -w net.bridge.bridge-nf-call-iptables=1
     -
    cat -n masters.txt | parallel -j1000 -a - --colsep '\t' ssh -i /tmp/aaa.pem centos@{2} sudo kubeadm init --token aaaaaa.aaaabbbbccccdddd --ignore-preflight-errors=NumCPU --pod-network-cidr=10.32.{1}.0/24 --service-cidr=10.96.{1}.0/24 --service-dns-domain=cluster{1}.local
    -
    vi assign-kube-master.py
    computenodes=8
    with open ('masters.txt') as aaa:
     with open ('workers.txt') as bbb:
      for masternode in aaa.read().rstrip().split('\n'):
       for i in range (computenodes):
        tmp=bbb.readline().rstrip()
        print ("{}\t{}".format(masternode, tmp))
     -
    cat masters.txt | parallel -j1000 ssh -i /tmp/aaa.pem centos@{} sudo cp /etc/kubernetes/admin.conf /tmp/admin.conf
    cat masters.txt | parallel -j1000 ssh -i /tmp/aaa.pem centos@{} sudo chmod 644 /tmp/admin.conf
    cat -n masters.txt | parallel -j1000 -a - --colsep '\t' scp -i /tmp/aaa.pem centos@{2}:/tmp/admin.conf kubeconfig-{1}
    -
    cat -n masters.txt | parallel -j1000 -a - --colsep '\t' kubectl --kubeconfig=kubeconfig-{1} get node
    -
    cat -n join.txt | parallel -j1000 -a - --colsep '\t' ssh -i /tmp/aaa.pem centos@{3} sudo kubeadm join {2}:6443 --token aaaaaa.aaaabbbbccccdddd --discovery-token-unsafe-skip-ca-verification
    -
    (modify controller-ip in cni-tungsten-fabric.yaml)
    cat -n masters.txt | parallel -j1000 -a - --colsep '\t' cp cni-tungsten-fabric.yaml cni-{1}.yaml
    cat -n masters.txt | parallel -j1000 -a - --colsep '\t' sed -i -e "s/k8s2/k8s{1}/" -e "s/10.32.2/10.32.{1}/" -e "s/10.64.2/10.64.{1}/" -e "s/10.96.2/10.96.{1}/"  -e "s/172.31.x.x/{2}/" cni-{1}.yaml
    -
    cat -n masters.txt | parallel -j1000 -a - --colsep '\t' kubectl --kubeconfig=kubeconfig-{1} apply -f cni-{1}.yaml
    -
    sed -i 's!kubectl!kubectl --kubeconfig=/etc/kubernetes/admin.conf!' set-label.sh 
    cat masters.txt | parallel -j1000 scp -i /tmp/aaa.pem set-label.sh centos@{}:/tmp
    cat masters.txt | parallel -j1000 ssh -i /tmp/aaa.pem centos@{} sudo bash /tmp/set-label.sh
    -
    cat -n masters.txt | parallel -j1000 -a - --colsep '\t' kubectl --kubeconfig=kubeconfig-{1} create -f first-containers.yaml
    

    在OpenStack上嵌套安装Kubernetes

    可以在all-in-one的openstack节点上尝试嵌套安装kubernetes。

    在ansible-deployer安装了该节点之后,

    此外,需要手动创建为vRouter TCP/9091连接本地服务

    此配置将创建DNAT/SNAT,例如从src: 10.0.1.3:xxxx, dst-ip: 10.1.1.11:9091到src: compute's vhost0 ip:xxxx dst-ip: 127.0.0.1:9091,因此openstack VM中的CNI可以与计算节点上的vrouter-agent直接通信,并为容器选择端口/ip信息。

    • IP地址可以来自子网,也可以来自子网外部。

    在该节点上,将创建两个Centos7(或ubuntu bionic)节点,并将使用相同的程序(见下面链接)安装kubernetes集群,

    当然yaml文件需要嵌套安装。

    ./resolve-manifest.sh contrail-nested-kubernetes.yaml > cni-tungsten-fabric.yaml
    
    KUBEMANAGER_NESTED_MODE: "{{ KUBEMANAGER_NESTED_MODE }}" ## this needs to be "1"
    KUBERNESTES_NESTED_VROUTER_VIP: {{ KUBERNESTES_NESTED_VROUTER_VIP }} ## this parameter needs to be the same IP with the one defined in link-local service (such as 10.1.1.11)
    

    如果coredns接收到ip,则说明嵌套安装正常。

    vRouter ml2插件

    我尝试了vRouter neutron插件的ml2功能。

    使用AWS上的三个CentOS7.5(4 cpu,16 GB内存,30 GB磁盘,ami: ami-3185744e)。

    随附基于本文件的步骤。

    openstack-controller: 172.31.15.248
    tungsten-fabric-controller (vRouter): 172.31.10.212
    nova-compute (ovs): 172.31.0.231
    
    (命令在tungsten-fabric-controller上,使用centos用户(不是root用户))
    
    sudo yum -y remove PyYAML python-requests
    sudo yum -y install git patch
    sudo easy_install pip
    sudo pip install PyYAML requests ansible==2.8.8
    ssh-keygen
     add id_rsa.pub to authorized_keys on all three nodes (centos user (not root))
    
    git clone https://opendev.org/x/networking-opencontrail.git
    cd networking-opencontrail
    patch -p1 < ml2-vrouter.diff 
    
    cd playbooks
    cp -i hosts.example hosts
    cp -i group_vars/all.yml.example group_vars/all.yml
    
    (ssh to all the nodes once, to update known_hosts)
    
    ansible-playbook main.yml -i hosts
    
     - devstack日志位于/opt/stack/logs/stack.sh.log中
     - openstack进程日志写在/var/log/messages中
     - 'systemctl list-unit-files | grep devstack'显示openstack进程的systemctl条目
    
    (openstack控制器节点)
      一旦devstack因mariadb登录错误而失败,请键入此命令进行修复。(对于openstack控制器的ip和fqdn,需要修改最后两行)
      命令将由“centos”用户(不是root用户)键入.
       mysqladmin -u root password admin
       mysql -uroot -padmin -h127.0.0.1 -e 'GRANT ALL PRIVILEGES ON *.* TO '\''root'\''@'\''%'\'' identified by '\''admin'\'';'
       mysql -uroot -padmin -h127.0.0.1 -e 'GRANT ALL PRIVILEGES ON *.* TO '\''root'\''@'\''172.31.15.248'\'' identified by '\''admin'\'';'
       mysql -uroot -padmin -h127.0.0.1 -e 'GRANT ALL PRIVILEGES ON *.* TO '\''root'\''@'\''ip-172-31-15-248.ap-northeast-1.compute.internal'\'' identified by '\''admin'\'';'
    

    下附hosts、group_vars/all和patch的代码。(有些仅是错误修正,但有些会更改默认行为)

    [centos@ip-172-31-10-212 playbooks]$ cat hosts
    controller ansible_host=172.31.15.248 ansible_user=centos
    
    # 此host应为计算主机组中的一个.
    # 单独部署Tungsten Fabtic计算节点的playbook尚未准备好.
    contrail_controller ansible_host=172.31.10.212 ansible_user=centos local_ip=172.31.10.212
    
    [contrail]
    contrail_controller
    
    [openvswitch]
    other_compute ansible_host=172.31.0.231 local_ip=172.31.0.231 ansible_user=centos
    
    [compute:children]
    contrail
    openvswitch
    [centos@ip-172-31-10-212 playbooks]$ cat group_vars/all.yml
    ---
    # IP address for OpenConrail (e.g. 192.168.0.2)
    contrail_ip: 172.31.10.212
    
    # Gateway address for OpenConrail (e.g. 192.168.0.1)
    contrail_gateway:
    
    # Interface name for OpenConrail (e.g. eth0)
    contrail_interface:
    
    # IP address for OpenStack VM (e.g. 192.168.0.3)
    openstack_ip: 172.31.15.248
    
    # 在VM上使用的OpenStack分支.
    openstack_branch: stable/queens
    
    # 也可以选择使用其它插件版本(默认为OpenStack分支)
    networking_plugin_version: master
    
    # Tungsten Fabric docker image tag for contrail-ansible-deployer
    contrail_version: master-latest
    
    # 如果为true,则使用Tungsten Fabric驱动程序安装networking_bgpvpn插件
    install_networking_bgpvpn_plugin: false
    
    # 如果true,则与设备管理器(将启动)和vRouter集成
    # 封装优先级将被设置为'VXLAN,MPLSoUDP,MPLSoGRE'.
    dm_integration_enabled: false
    
    # 带有DM集成拓扑的文件的可选路径。设置并启用DM集成后,topology.yaml文件将复制到此位置
    dm_topology_file:
    
    # 如果为true,则将为当前ansible用户创建的实例密码设置为instance_password的值
    change_password: false
    # instance_password: uberpass1
    
    # 如果已设置,请使用此数据覆盖docker daemon /etc config文件
    # docker_config:
    [centos@ip-172-31-10-212 playbooks]$ 
    
    
    
    [centos@ip-172-31-10-212 networking-opencontrail]$ cat ml2-vrouter.diff 
    diff --git a/playbooks/roles/contrail_node/tasks/main.yml b/playbooks/roles/contrail_node/tasks/main.yml
    index ee29b05..272ee47 100644
    --- a/playbooks/roles/contrail_node/tasks/main.yml
    +++ b/playbooks/roles/contrail_node/tasks/main.yml
    @@ -7,7 +7,6 @@
           - epel-release
           - gcc
           - git
    -      - ansible-2.4.*
           - yum-utils
           - libffi-devel
         state: present
    @@ -61,20 +60,20 @@
         chdir: ~/contrail-ansible-deployer/
         executable: /bin/bash
    
    -- name: Generate ssh key for provisioning other nodes
    -  openssh_keypair:
    -    path: ~/.ssh/id_rsa
    -    state: present
    -  register: contrail_deployer_ssh_key
    -
    -- name: Propagate generated key
    -  authorized_key:
    -    user: "{{ ansible_user }}"
    -    state: present
    -    key: "{{ contrail_deployer_ssh_key.public_key }}"
    -  delegate_to: "{{ item }}"
    -  with_items: "{{ groups.contrail }}"
    -  when: contrail_deployer_ssh_key.public_key
    +#- name: Generate ssh key for provisioning other nodes
    +#  openssh_keypair:
    +#    path: ~/.ssh/id_rsa
    +#    state: present
    +#  register: contrail_deployer_ssh_key
    +#
    +#- name: Propagate generated key
    +#  authorized_key:
    +#    user: "{{ ansible_user }}"
    +#    state: present
    +#    key: "{{ contrail_deployer_ssh_key.public_key }}"
    +#  delegate_to: "{{ item }}"
    +#  with_items: "{{ groups.contrail }}"
    +#  when: contrail_deployer_ssh_key.public_key
    
     - name: Provision Node before deploy contrail
       shell: |
    @@ -105,4 +104,4 @@
         sleep: 5
         host: "{{ contrail_ip }}"
         port: 8082
    -    timeout: 300
    \ No newline at end of file
    +    timeout: 300
    diff --git a/playbooks/roles/contrail_node/templates/instances.yaml.j2 b/playbooks/roles/contrail_node/templates/instances.yaml.j2
    index e3617fd..81ea101 100644
    --- a/playbooks/roles/contrail_node/templates/instances.yaml.j2
    +++ b/playbooks/roles/contrail_node/templates/instances.yaml.j2
    @@ -14,6 +14,7 @@ instances:
           config_database:
           config:
           control:
    +      analytics:
           webui:
     {% if "contrail_controller" in groups["contrail"] %}
           vrouter:
    diff --git a/playbooks/roles/docker/tasks/main.yml b/playbooks/roles/docker/tasks/main.yml
    index 8d7971b..5ed9352 100644
    --- a/playbooks/roles/docker/tasks/main.yml
    +++ b/playbooks/roles/docker/tasks/main.yml
    @@ -6,7 +6,6 @@
           - epel-release
           - gcc
           - git
    -      - ansible-2.4.*
           - yum-utils
           - libffi-devel
         state: present
    @@ -62,4 +61,4 @@
           - docker-py==1.10.6
           - docker-compose==1.9.0
         state: present
    -    extra_args: --user
    \ No newline at end of file
    +    extra_args: --user
    diff --git a/playbooks/roles/node/tasks/main.yml b/playbooks/roles/node/tasks/main.yml
    index 0fb1751..d9ab111 100644
    --- a/playbooks/roles/node/tasks/main.yml
    +++ b/playbooks/roles/node/tasks/main.yml
    @@ -1,13 +1,21 @@
     ---
    -- name: Update kernel
    +- name: Install required utilities
       become: yes
       yum:
    -    name: kernel
    -    state: latest
    -  register: update_kernel
    +    name:
    +      - python3-devel
    +      - libibverbs  ## needed by openstack controller node
    +    state: present
    
    -- name: Reboot the machine
    -  become: yes
    -  reboot:
    -  when: update_kernel.changed
    -  register: reboot_machine
    +#- name: Update kernel
    +#  become: yes
    +#  yum:
    +#    name: kernel
    +#    state: latest
    +#  register: update_kernel
    +#
    +#- name: Reboot the machine
    +#  become: yes
    +#  reboot:
    +#  when: update_kernel.changed
    +#  register: reboot_machine
    diff --git a/playbooks/roles/restack_node/tasks/main.yml b/playbooks/roles/restack_node/tasks/main.yml
    index a11e06e..f66d2ee 100644
    --- a/playbooks/roles/restack_node/tasks/main.yml
    +++ b/playbooks/roles/restack_node/tasks/main.yml
    @@ -9,7 +9,7 @@
       become: yes
       pip:
         name:
    -      - setuptools
    +      - setuptools==43.0.0
           - requests
         state: forcereinstall
    
    
    [centos@ip-172-31-10-212 networking-opencontrail]$
    

    完成安装大约需要50分钟。

    尽管/home/centos/devstack/openrc可以用于“demo”用户登录,但是需要管理员访问权限来指定其网络类型(vRouter为空,ovs为“vxlan”),因此需要手动创建adminrc。

    [centos@ip-172-31-15-248 ~]$ cat adminrc 
    export OS_PROJECT_DOMAIN_ID=default
    export OS_REGION_NAME=RegionOne
    export OS_USER_DOMAIN_ID=default
    export OS_PROJECT_NAME=admin
    export OS_IDENTITY_API_VERSION=3
    export OS_PASSWORD=admin
    export OS_AUTH_TYPE=password
    export OS_AUTH_URL=http://172.31.15.248/identity  ## this needs to be modified
    export OS_USERNAME=admin
    export OS_TENANT_NAME=admin
    export OS_VOLUME_API_VERSION=2
    [centos@ip-172-31-15-248 ~]$ 
    
    
    openstack network create testvn
    openstack subnet create --subnet-range 192.168.100.0/24 --network testvn subnet1
    openstack network create --provider-network-type vxlan testvn-ovs
    openstack subnet create --subnet-range 192.168.110.0/24 --network testvn-ovs subnet1-ovs
    
     - 创建了两个虚拟网络
    [centos@ip-172-31-15-248 ~]$ openstack network list
    +--------------------------------------+------------+--------------------------------------+
    | ID                                   | Name       | Subnets                              |
    +--------------------------------------+------------+--------------------------------------+
    | d4e08516-71fc-401b-94fb-f52271c28dc9 | testvn-ovs | 991417ab-7da5-44ed-b686-8a14abbe46bb |
    | e872b73e-100e-4ab0-9c53-770e129227e8 | testvn     | 27d828eb-ada4-4113-a6f8-df7dde2c43a4 |
    +--------------------------------------+------------+--------------------------------------+
    [centos@ip-172-31-15-248 ~]$
    
     - testvn's provider:network_type为空
    
    [centos@ip-172-31-15-248 ~]$ openstack network show testvn
    +---------------------------+--------------------------------------+
    | Field                     | Value                                |
    +---------------------------+--------------------------------------+
    | admin_state_up            | UP                                   |
    | availability_zone_hints   |                                      |
    | availability_zones        | nova                                 |
    | created_at                | 2020-01-18T16:14:42Z                 |
    | description               |                                      |
    | dns_domain                | None                                 |
    | id                        | e872b73e-100e-4ab0-9c53-770e129227e8 |
    | ipv4_address_scope        | None                                 |
    | ipv6_address_scope        | None                                 |
    | is_default                | None                                 |
    | is_vlan_transparent       | None                                 |
    | mtu                       | 1500                                 |
    | name                      | testvn                               |
    | port_security_enabled     | True                                 |
    | project_id                | 84a573dbfadb4a198ec988e36c4f66f6     |
    | provider:network_type     | local                                |
    | provider:physical_network | None                                 |
    | provider:segmentation_id  | None                                 |
    | qos_policy_id             | None                                 |
    | revision_number           | 3                                    |
    | router:external           | Internal                             |
    | segments                  | None                                 |
    | shared                    | False                                |
    | status                    | ACTIVE                               |
    | subnets                   | 27d828eb-ada4-4113-a6f8-df7dde2c43a4 |
    | tags                      |                                      |
    | updated_at                | 2020-01-18T16:14:44Z                 |
    +---------------------------+--------------------------------------+
    [centos@ip-172-31-15-248 ~]$ 
    
     - 它是在Tungsten Fabric的数据库中创建的
    
    (venv) [root@ip-172-31-10-212 ~]# contrail-api-cli --host 172.31.10.212 ls -l virtual-network
    virtual-network/e872b73e-100e-4ab0-9c53-770e129227e8  default-domain:admin:testvn
    virtual-network/5a88a460-b049-4114-a3ef-d7939853cb13  default-domain:default-project:dci-network
    virtual-network/f61d52b0-6577-42e0-a61f-7f1834a2f45e  default-domain:default-project:__link_local__
    virtual-network/46b5d74a-24d3-47dd-bc82-c18f6bc706d7  default-domain:default-project:default-virtual-network
    virtual-network/52925e2d-8c5d-4573-9317-2c346fb9edf0  default-domain:default-project:ip-fabric
    virtual-network/2b0469cf-921f-4369-93a7-2d73350c82e7  default-domain:default-project:_internal_vn_ipv6_link_local
    (venv) [root@ip-172-31-10-212 ~]# 
    
    
     - 另一方面,testvn-ovs's provider:network_type是vxlan,并且segmentation ID,mtu都是自动指定的
    
    [centos@ip-172-31-15-248 ~]$ openstack network show testvn
    +---------------------------+--------------------------------------+
    | Field                     | Value                                |
    +---------------------------+--------------------------------------+
    | admin_state_up            | UP                                   |
    | availability_zone_hints   |                                      |
    | availability_zones        | nova                                 |
    | created_at                | 2020-01-18T16:14:42Z                 |
    | description               |                                      |
    | dns_domain                | None                                 |
    | id                        | e872b73e-100e-4ab0-9c53-770e129227e8 |
    | ipv4_address_scope        | None                                 |
    | ipv6_address_scope        | None                                 |
    | is_default                | None                                 |
    | is_vlan_transparent       | None                                 |
    | mtu                       | 1500                                 |
    | name                      | testvn                               |
    | port_security_enabled     | True                                 |
    | project_id                | 84a573dbfadb4a198ec988e36c4f66f6     |
    | provider:network_type     | local                                |
    | provider:physical_network | None                                 |
    | provider:segmentation_id  | None                                 |
    | qos_policy_id             | None                                 |
    | revision_number           | 3                                    |
    | router:external           | Internal                             |
    | segments                  | None                                 |
    | shared                    | False                                |
    | status                    | ACTIVE                               |
    | subnets                   | 27d828eb-ada4-4113-a6f8-df7dde2c43a4 |
    | tags                      |                                      |
    | updated_at                | 2020-01-18T16:14:44Z                 |
    +---------------------------+--------------------------------------+
    [centos@ip-172-31-15-248 ~]$ openstack network show testvn-ovs
    +---------------------------+--------------------------------------+
    | Field                     | Value                                |
    +---------------------------+--------------------------------------+
    | admin_state_up            | UP                                   |
    | availability_zone_hints   |                                      |
    | availability_zones        | nova                                 |
    | created_at                | 2020-01-18T16:14:47Z                 |
    | description               |                                      |
    | dns_domain                | None                                 |
    | id                        | d4e08516-71fc-401b-94fb-f52271c28dc9 |
    | ipv4_address_scope        | None                                 |
    | ipv6_address_scope        | None                                 |
    | is_default                | None                                 |
    | is_vlan_transparent       | None                                 |
    | mtu                       | 1450                                 |
    | name                      | testvn-ovs                           |
    | port_security_enabled     | True                                 |
    | project_id                | 84a573dbfadb4a198ec988e36c4f66f6     |
    | provider:network_type     | vxlan                                |
    | provider:physical_network | None                                 |
    | provider:segmentation_id  | 50                                   |
    | qos_policy_id             | None                                 |
    | revision_number           | 3                                    |
    | router:external           | Internal                             |
    | segments                  | None                                 |
    | shared                    | False                                |
    | status                    | ACTIVE                               |
    | subnets                   | 991417ab-7da5-44ed-b686-8a14abbe46bb |
    | tags                      |                                      |
    | updated_at                | 2020-01-18T16:14:49Z                 |
    +---------------------------+--------------------------------------+
    [centos@ip-172-31-15-248 ~]$
    

    Tungsten Fabric知识库丨关于OpenStack、K8s、CentOS安装问题的补充(下)

    posted in 博客
  • “天成云”品牌发布——Tungsten Fabric助力开源开放生态发展

    作者:TF编译组

    作为开源SDN的代表,Tungsten Fabric在多云混合架构网络管理领域,构建了云计算新的发展生态,很多用户基于TF SDN技术栈进行了创新探索和实践。

    华胜天成就是国内应用Tungsten Fabric的一位先行者。9月16日,旗下“天成云”品牌及产品隆重发布,TF中文社区与众多权威专家、行业大咖、千行百业的客户及合作伙伴一起,共同见证了天成云引领云计算时代变革的历史性时刻。

    a87efe73-3c7c-46c6-ba15-d9115cdbabd2-image.png
    华胜天成集团董事长王维航(左三)、总裁赵康(左二)、首席技术官李明军(左一)、北京市经济和信息化局总工程师顾瑾栩(右一)正式宣布华胜天成“天成云”发布
     
    作为TF中文社区创始成员,同时也是众多开源社区的积极参与者与代码的贡献者,华胜天成积极拥抱开源和开放架构。#推荐阅读#华胜天成集团首席技术官兼天成云总经理李明军曾在TF成立大会上分享《异构混合多云管理的需求,如何在SDN平台落地》主题演讲。

    华胜天成现场发布了全栈数据中心云及边缘云解决方案、异构混合多云管理平台、双轮驱动业务全生命周期管理平台、数字化能力交易与交付平台等多款产品及服务,为客户构建场景化的业务底座,赋能数字化转型。

    Tungsten Fabric作为天成云软件SDN技术栈组成部分,出现在多个最新产品和服务中,助力其实现跨技术栈网络平面互通、虚拟网络的二层和三层隔离、Netconf对物理设备的管理、负载均衡及服务链等功能,在大规模快速部署的基础上,支撑异构资源池业务灵活部署和丰富的策略控制,在兼容多厂家设备管理的同时实现开源自主可控。 
    a89c1de7-5ee6-41f3-bb76-e701c0776a32-image.png
    Juniper中国区渠道总监柯楷分享开源SDN方案

    发布会上,Juniper中国区渠道总监柯楷,以同为Tungsten Fabric创始会员的身份,分享了Tungsten Fabric在开源SDN领域的最新进展和情况。

    目前Tungsten Fabric已成为最热门、参与人数最多的多云管理开源社区,也是Linux基金会多云项目下贡献最大的社区。在国内,包括华胜天成在内的众多TF中文社区会员,积极贡献代码和经验,始终保持在开源SDN和多云领域的活跃度。

    现在,华胜天成将Tungsten Fabric集成到云平台,整合进各个资源池,进行了一系列统一网络编排的实践。#推荐阅读#华胜天成集团网络架构师王峻、SDN开发工程师唐志军曾在OpenInfra Days China 2020大会上带来联合演讲—华胜天成基于TF实践:《基于Tungsten Fabric打通异构资源网络》

    柯楷表示,企业IT发展这么多年,由传统架构演化而来的异构多云环境,已成为企业一大现实痛点,我们需要倡导“自动驾驶的网络”。而基于Tungsten Fabric体系架构,以及vRouter、微服务等技术的实现,企业能够更快将网络需求转成服务,具备可控自主驾驶的实现基础。

    基于Tungsten Fabric的统一SDN集成网络方案,企业得以实现一个策略对应多云部署与管理,打通K8s、OpenStack、裸金属、公有云等异构混合资源的网络互连,实现端到端的,统一网络资源管理调度,安全和策略的实施,降低运维和管理人员的工作压力,在满足业务场景基础上轻松驾驭网络。

    #推荐阅读#华胜天成网络架构师王峻曾在TF中文社区线上直播活动TF Live 中与大家进行了在线交流,演示了基于Tungsten Fabric开源SDN功能,如何实现vCenter、OpenStack、K8s之间的异构资源池互通,以及服务链的引流功能

    本次活动不仅是一场品牌及产品发布会,更是对云计算发展趋势的大讨论。

    在随后的圆桌论坛上,TF中文社区发起人、Juniper中国区副总裁叶勇,与联通系统集成CTO杨海明、Intel行业解决方案集团CTO吴闻新、华胜天成集团首席技术官兼天成云总经理李明军等嘉宾,共同就企业用户上云用云的实际需求,及云计算在新阶段的发展路线进行了探讨。

    8f641b0d-8230-438e-bbd1-4e229033017c-image.png
    联通系统集成CTO杨海明博士(左二)、Juniper中国区副总裁叶勇(左三)、Intel行业解决方案集团CTO吴闻新(右二)、华胜天成集团首席技术官兼天成云总经理李明军(右一)共话中国企业云计算发展趋势

    大家都认为,中国企业经过多年IT系统建设和上云实践,异构混合多云已经是目前最大的现实,如何在此环境下满足业务需求,成为摆在云计算行业人士面前的问题,天成云的架构和服务就是一种很好的解决方式。

    叶勇表示,无论是从技术栈层面,还是客户自主可控的需求层面,都需要云计算架构具备开源和云原生的属性。云计算架构未来的趋势是走向开放,不仅是各行业用户,业内各个厂商也希望尽快达成共识,未来将通过软件平台方式实现云服务的集成,根据真实的需求和场景将云计算能力提供给用户。

    虽然Tungsten Fabric国际社区热度很高,但中国大量企业的需求和场景并未完全满足,TF中文社区就是希望集合国内有共识的合作伙伴,通过大量厂商、客户、行业专家的共同参与,解决中国企业客户实际需求场景满足问题,并达到自主可控的要求。

    目前,TF中文社区已经有66个会员,多个技术社群,定期组织线上直播、线下Meetup等活动,期待有更多同仁加入进来,共同为中国企业云计算发展新时代添砖加瓦。


    Tungsten Fabric相关资源
    微信号:TF中文社区( ID: CTFSDN )
    邮箱:tfzw001@163.com
    中文官网: https://tungstenfabric.org.cn/
    英文官网: https://tungsten.io/


    920d11dc-7d7d-4640-99b2-70d6dcf0ca05-image.png

    posted in 新闻
  • Tungsten Fabric知识库丨测试2000个vRouter节点部署

    作者:Tatsuya Naganawa 译者:TF编译组

    由于GCP允许启动多达5k个节点:),因此vRouter的规模测试程序主要针对该平台来介绍。

    • 话虽如此,AWS也可以使用相同的程序

    第一个目标是2k个vRouter节点,但是据我尝试,这不是最大值,可以通过更多的控制节点或添加CPU/MEM来达到更大的数值。

    在GCP中,可以使用多个子网创建VPC,将控制平面节点分配为172.16.1.0/24,而vRouter节点分配为10.0.0.0/9。(默认子网为/12,最多可达到4k个节点)

    默认情况下,并非所有实例都可以具有全局IP,因此需要为vRouter节点定义Cloud NAT才能访问Internet。(我将全局IP分配给控制平面节点,因为节点数量不会那么多)

    所有节点均由instance-group创建,并且禁用了auto-scaling,并分配了固定编号。所有节点都为了降低成本而配置了抢占模式(vRouter为$0.01/1hr(n1-standard-1),控制平面节点为$0.64/1hr(n1-standard-64))

    总体程序描述如下:

    1. 使用此程序设置control/config x 5,analytics x 3,kube-master x 1。

    这一步最多需要30分钟。

    使用了2002版本。JVM_EXTRA_OPTS:设置为“-Xms128m -Xmx20g”。

    需要补充一点的是,XMPP_KEEPALIVE_SECONDS决定了XMPP的可扩展性,我将其设置为3。因此,在vRouter节点故障之后,control组件需要9秒才能识别出它来。(默认情况下设置为10/30)对于IaaS用例,我认为这是一个中等的选择,但如果这个值需要较低,则需要有更多的CPU。

    为了后续使用,这里还创建了虚拟网络vn1(10.1.0.0/12,l2/l3)。

    1. 使用此程序设置一个kube-master。

    这一步最多需要20分钟。

    对于cni.yaml,使用以下URL。

    XMPP_KEEPALIVE_SECONDS:“3”已经添加到env中。

    由于GCP上的vRouter问题,

    vrouter-agent容器已打补丁,并且yaml需要更改。

    3138ad13-a433-4273-9d0f-ecc23f323294-image.png

    set-label.sh和kubectl apply -f cni.yaml此时已完成。

    1. 启动vRouter节点,并使用以下命令转储ips。
    (for GCP)
    gcloud --format="value(networkInterfaces[0].networkIP)" compute instances list
    
    (for AWS, this command can be used)
    aws ec2 describe-instances --query 'Reservations[*].Instances[*].PrivateIpAddress' --output text | tr '\t' '\n'
    

    这大约需要10-20分钟。

    1. 在vRouter节点上安装Kubernetes,然后等待它安装vRouter节点。
    (/tmp/aaa.pem is the secret key for GCP)
    sudo yum -y install epel-release
    sudo yum -y install parallel
    sudo su - -c "ulimit -n 8192; su - centos"
    cat all.txt | parallel -j3500 scp -i /tmp/aaa.pem -o StrictHostKeyChecking=no install-k8s-packages.sh centos@{}:/tmp
    cat all.txt | parallel -j3500 ssh -i /tmp/aaa.pem -o StrictHostKeyChecking=no centos@{} chmod 755 /tmp/install-k8s-packages.sh
    cat all.txt | parallel -j3500 ssh -i /tmp/aaa.pem -o StrictHostKeyChecking=no centos@{} sudo /tmp/install-k8s-packages.sh
    
    ###该命令需要最多200个并行执行,如果不执行该命令,会导致kubeadm连接超时
    cat all.txt | parallel -j200 ssh -i /tmp/aaa.pem -o StrictHostKeyChecking=no centos@{} sudo kubeadm join 172.16.1.x:6443 --token we70in.mvy0yu0hnxb6kxip --discovery-token-ca-cert-hash sha256:13cf52534ab14ee1f4dc561de746e95bc7684f2a0355cb82eebdbd5b1e9f3634
    

    kubeadm加入大约需要20-30分钟。vRouter安装大约需要40-50分钟。(基于Cloud NAT性能,在VPC中添加docker注册表会缩短docker pull time)。

    1. 之后,可以使用replica: 2000创建first-containers.yaml,并检查容器之间的ping。要查看BUM行为,vn1也可以与具有2k replica的容器一起使用。

    创建容器最多需要15-20分钟。

    [config results]
    
    2200 instances are created, and 2188 kube workers are available.
    (some are restarted and not available, since those instance are preemptive VM)
    
    [centos@instance-group-1-srwq ~]$ kubectl get node | wc -l
    2188
    [centos@instance-group-1-srwq ~]$ 
    
    When vRouters are installed, some more nodes are rebooted, and 2140 vRouters become available.
    
    Every 10.0s: kubectl get pod --all-namespaces | grep contrail | grep Running | wc -l     Sun Feb 16 17:25:16 2020
    2140
    
    After start creating 2k containers, 15 minutes is needed before 2k containers are up.
    
    Every 5.0s: kubectl get pod -n myns11 | grep Running | wc -l                                                             Sun Feb 16 17:43:06 2020
    1927
    
    
    ping between containers works fine:
    
    $ kubectl get pod -n myns11
    (snip)
    vn11-deployment-68565f967b-zxgl4   1/1     Running             0          15m   10.0.6.0     instance-group-3-bqv4              
    vn11-deployment-68565f967b-zz2f8   1/1     Running             0          15m   10.0.6.16    instance-group-2-ffdq              
    vn11-deployment-68565f967b-zz8fk   1/1     Running             0          16m   10.0.1.61    instance-group-4-cpb8              
    vn11-deployment-68565f967b-zzkdk   1/1     Running             0          16m   10.0.2.244   instance-group-3-pkrq              
    vn11-deployment-68565f967b-zzqb7   0/1     ContainerCreating   0          15m          instance-group-4-f5nw              
    vn11-deployment-68565f967b-zzt52   1/1     Running             0          15m   10.0.5.175   instance-group-3-slkw              
    vn11-deployment-68565f967b-zztd6   1/1     Running             0          15m   10.0.7.154   instance-group-4-skzk              
    
    [centos@instance-group-1-srwq ~]$ kubectl exec -it -n myns11 vn11-deployment-68565f967b-zzkdk sh
    / # 
    / # 
    / # ip -o a
    1: lo:  mtu 65536 qdisc noqueue qlen 1000\    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    1: lo    inet 127.0.0.1/8 scope host lo\       valid_lft forever preferred_lft forever
    1: lo    inet6 ::1/128 scope host \       valid_lft forever preferred_lft forever
    36: eth0@if37:  mtu 1500 qdisc noqueue \    link/ether 02:fd:53:2d:ea:50 brd ff:ff:ff:ff:ff:ff
    36: eth0    inet 10.0.2.244/12 scope global eth0\       valid_lft forever preferred_lft forever
    36: eth0    inet6 fe80::e416:e7ff:fed3:9cc5/64 scope link \       valid_lft forever preferred_lft forever
    / # ping 10.0.1.61
    PING 10.0.1.61 (10.0.1.61): 56 data bytes
    64 bytes from 10.0.1.61: seq=0 ttl=64 time=3.635 ms
    64 bytes from 10.0.1.61: seq=1 ttl=64 time=0.474 ms
    ^C
    --- 10.0.1.61 ping statistics ---
    2 packets transmitted, 2 packets received, 0% packet loss
    round-trip min/avg/max = 0.474/2.054/3.635 ms
    / #
    
    There are some XMPP flap .. it might be caused by CPU spike by config-api, or some effect of preemptive VM.
    It needs to be investigated further with separating config and control.
    (most of other 2k vRouter nodes won't experience XMPP flap though)
    
    (venv) [centos@instance-group-1-h26k ~]$ ./contrail-introspect-cli/ist.py ctr nei -t XMPP -c flap_count | grep -v -w 0
    +------------+
    | flap_count |
    +------------+
    | 1          |
    | 1          |
    | 1          |
    | 1          |
    | 1          |
    | 1          |
    | 1          |
    | 1          |
    | 1          |
    | 1          |
    | 1          |
    | 1          |
    | 1          |
    | 1          |
    +------------+
    (venv) [centos@instance-group-1-h26k ~]$ 
    
    
    [BUM tree]
    
    Send two multicast packets.
    
    / # ping 224.0.0.1
    PING 224.0.0.1 (224.0.0.1): 56 data bytes
    ^C
    --- 224.0.0.1 ping statistics ---
    2 packets transmitted, 0 packets received, 100% packet loss
    / # 
    / # ip -o a
    1: lo:  mtu 65536 qdisc noqueue qlen 1000\    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    1: lo    inet 127.0.0.1/8 scope host lo\       valid_lft forever preferred_lft forever
    1: lo    inet6 ::1/128 scope host \       valid_lft forever preferred_lft forever
    36: eth0@if37:  mtu 1500 qdisc noqueue \    link/ether 02:fd:53:2d:ea:50 brd ff:ff:ff:ff:ff:ff
    36: eth0    inet 10.0.2.244/12 scope global eth0\       valid_lft forever preferred_lft forever
    36: eth0    inet6 fe80::e416:e7ff:fed3:9cc5/64 scope link \       valid_lft forever preferred_lft forever
    / # 
    
    That container is on this node.
    
    (venv) [centos@instance-group-1-h26k ~]$ ping instance-group-3-pkrq
    PING instance-group-3-pkrq.asia-northeast1-b.c.stellar-perigee-161412.internal (10.0.3.211) 56(84) bytes of data.
    64 bytes from instance-group-3-pkrq.asia-northeast1-b.c.stellar-perigee-161412.internal (10.0.3.211): icmp_seq=1 ttl=63 time=1.46 ms
    
    
    It sends overlay packet to some other endpoints (not all 2k nodes),
    
    [root@instance-group-3-pkrq ~]# tcpdump -nn -i eth0 udp
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
    17:48:51.501718 IP 10.0.3.211.57333 > 10.0.0.212.6635: UDP, length 142
    17:48:52.501900 IP 10.0.3.211.57333 > 10.0.0.212.6635: UDP, length 142
    
    and it eventually reach other containers, going through Edge Replicate tree.
    
    [root@instance-group-4-cpb8 ~]# tcpdump -nn -i eth0 udp
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
    17:48:51.517306 IP 10.0.1.198.58095 > 10.0.5.244.6635: UDP, length 142
    17:48:52.504484 IP 10.0.1.198.58095 > 10.0.5.244.6635: UDP, length 142
    
    
    
    
    [resource usage]
    
    controller:
    CPU usage is moderate and bound by contrail-control process.
    If more vRouter nodes need to be added, more controller nodes can be added.
     - separating config and control also should help to reach further stability
    
    top - 17:45:28 up  2:21,  2 users,  load average: 7.35, 12.16, 16.33
    Tasks: 577 total,   1 running, 576 sleeping,   0 stopped,   0 zombie
    %Cpu(s): 14.9 us,  4.2 sy,  0.0 ni, 80.8 id,  0.0 wa,  0.0 hi,  0.1 si,  0.0 st
    KiB Mem : 24745379+total, 22992752+free, 13091060 used,  4435200 buff/cache
    KiB Swap:        0 total,        0 free,        0 used. 23311113+avail Mem 
    
      PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
    23930 1999      20   0 9871.3m   5.5g  14896 S  1013  2.3   1029:04 contrail-contro
    23998 1999      20   0 5778768 317660  12364 S 289.1  0.1 320:18.42 contrail-dns                        
    13434 polkitd   20   0   33.6g 163288   4968 S   3.3  0.1  32:04.85 beam.smp                                
    26696 1999      20   0  829768 184940   6628 S   2.3  0.1   0:22.14 node                                 
     9838 polkitd   20   0   25.4g   2.1g  15276 S   1.3  0.9  45:18.75 java                                     
     1012 root      20   0       0      0      0 S   0.3  0.0   0:00.26 kworker/18:1                       
     6293 root      20   0 3388824  50576  12600 S   0.3  0.0   0:34.39 docker-containe                                                 
     9912 centos    20   0   38.0g 417304  12572 S   0.3  0.2   0:25.30 java                                                 
    16621 1999      20   0  735328 377212   7252 S   0.3  0.2  23:27.40 contrail-api                                      
    22289 root      20   0       0      0      0 S   0.3  0.0   0:00.04 kworker/16:2                                          
    24024 root      20   0  259648  41992   5064 S   0.3  0.0   0:28.81 contrail-nodemg                                                  
    48459 centos    20   0  160328   2708   1536 R   0.3  0.0   0:00.33 top                                                             
    61029 root      20   0       0      0      0 S   0.3  0.0   0:00.09 kworker/4:2                                                      
        1 root      20   0  193680   6780   4180 S   0.0  0.0   0:02.86 systemd                                                        
        2 root      20   0       0      0      0 S   0.0  0.0   0:00.03 kthreadd         
    
    [centos@instance-group-1-rc34 ~]$ free -h
                  total        used        free      shared  buff/cache   available
    Mem:           235G         12G        219G        9.8M        3.9G        222G
    Swap:            0B          0B          0B
    [centos@instance-group-1-rc34 ~]$ 
    [centos@instance-group-1-rc34 ~]$ df -h .
    /dev/sda1         10G  5.1G  5.0G   51% /
    [centos@instance-group-1-rc34 ~]$ 
    
    
    
    analytics:
    CPU usage is moderate and bound by contrail-collector process.
    If more vRouter nodes need to be added, more analytics nodes can be added.
    
    top - 17:45:59 up  2:21,  1 user,  load average: 0.84, 2.57, 4.24
    Tasks: 515 total,   1 running, 514 sleeping,   0 stopped,   0 zombie
    %Cpu(s):  3.3 us,  1.3 sy,  0.0 ni, 95.4 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
    KiB Mem : 24745379+total, 24193969+free,  3741324 used,  1772760 buff/cache
    KiB Swap:        0 total,        0 free,        0 used. 24246134+avail Mem 
    
      PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                       
     6334 1999      20   0 7604200 958288  10860 S 327.8  0.4 493:31.11 contrail-collec          
     4904 polkitd   20   0  297424 271444   1676 S  14.6  0.1  10:42.34 redis-server           
     4110 root      20   0 3462120  95156  34660 S   1.0  0.0   1:21.32 dockerd                     
        9 root      20   0       0      0      0 S   0.3  0.0   0:04.81 rcu_sched                      
       29 root      20   0       0      0      0 S   0.3  0.0   0:00.05 ksoftirqd/4           
     8553 centos    20   0  160308   2608   1536 R   0.3  0.0   0:00.07 top                
        1 root      20   0  193564   6656   4180 S   0.0  0.0   0:02.77 systemd                 
        2 root      20   0       0      0      0 S   0.0  0.0   0:00.03 kthreadd             
        4 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 kworker/0:0H               
        5 root      20   0       0      0      0 S   0.0  0.0   0:00.77 kworker/u128:0         
        6 root      20   0       0      0      0 S   0.0  0.0   0:00.17 ksoftirqd/0     
        7 root      rt   0       0      0      0 S   0.0  0.0   0:00.38 migration/0    
    
    [centos@instance-group-1-n4c7 ~]$ free -h
                  total        used        free      shared  buff/cache   available
    Mem:           235G        3.6G        230G        8.9M        1.7G        231G
    Swap:            0B          0B          0B
    [centos@instance-group-1-n4c7 ~]$ 
    [centos@instance-group-1-n4c7 ~]$ df -h .
    /dev/sda1         10G  3.1G  6.9G   32% /
    [centos@instance-group-1-n4c7 ~]$ 
    
    
    
    
    kube-master:
    CPU usage is small.
    
    top - 17:46:18 up  2:22,  2 users,  load average: 0.92, 1.32, 2.08
    Tasks: 556 total,   1 running, 555 sleeping,   0 stopped,   0 zombie
    %Cpu(s):  1.2 us,  0.5 sy,  0.0 ni, 98.2 id,  0.1 wa,  0.0 hi,  0.1 si,  0.0 st
    KiB Mem : 24745379+total, 23662128+free,  7557744 used,  3274752 buff/cache
    KiB Swap:        0 total,        0 free,        0 used. 23852964+avail Mem 
    
      PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                      
     5177 root      20   0 3605852   3.1g  41800 S  78.1  1.3 198:42.92 kube-apiserver                                                               
     5222 root      20   0   10.3g 633316 410812 S  55.0  0.3 109:52.52 etcd                                                                         
     5198 root      20   0  846948 651668  31284 S   8.3  0.3 169:03.71 kube-controller                                                              
     5549 root      20   0 4753664  96528  34260 S   5.0  0.0   4:45.54 kubelet                                                                      
     3493 root      20   0 4759508  71864  16040 S   0.7  0.0   1:52.67 dockerd-current                                                              
     5197 root      20   0  500800 307056  17724 S   0.7  0.1   6:43.91 kube-scheduler                                                               
    19933 centos    20   0  160340   2648   1528 R   0.7  0.0   0:00.07 top                                                                          
     1083 root       0 -20       0      0      0 S   0.3  0.0   0:20.19 kworker/0:1H                                                                 
    35229 root      20   0       0      0      0 S   0.3  0.0   0:15.08 kworker/0:2                                                                  
        1 root      20   0  193808   6884   4212 S   0.0  0.0   0:03.59 systemd                                                                      
        2 root      20   0       0      0      0 S   0.0  0.0   0:00.03 kthreadd                                                                     
        4 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 kworker/0:0H                                                                 
        5 root      20   0       0      0      0 S   0.0  0.0   0:00.55 kworker/u128:0                                                               
        6 root      20   0       0      0      0 S   0.0  0.0   0:01.51 ksoftirqd/0      
    
    [centos@instance-group-1-srwq ~]$ free -h
                  total        used        free      shared  buff/cache   available
    Mem:           235G         15G        217G        121M        3.2G        219G
    Swap:            0B          0B          0B
    [centos@instance-group-1-srwq ~]$ 
    
    [centos@instance-group-1-srwq ~]$ df -h /
    /dev/sda1         10G  4.6G  5.5G   46% /
    [centos@instance-group-1-srwq ~]$ 
    
    [centos@instance-group-1-srwq ~]$ free -h
                  total        used        free      shared  buff/cache   available
    Mem:           235G         15G        217G        121M        3.2G        219G
    Swap:            0B          0B          0B
    [centos@instance-group-1-srwq ~]$ 
    
    [centos@instance-group-1-srwq ~]$ df -h /
    /dev/sda1         10G  4.6G  5.5G   46% /
    [centos@instance-group-1-srwq ~]$
    

    附:erm-vpn

    启用erm-vpn后,vrouter会将多播流量发送到最多4个节点上,以避免入口(ingress)复制到所有节点。控制器以生成树的方式,将多播数据包发送到所有节点。

    为了说明此功能,我创建了一个具有20个kubernete worker的集群,并部署了20个副本。

    • 没有使用default-k8s-pod-network,因为它是仅支持l3转发的模式。这里手动定义了vn1(10.0.1.0/24)

    在此设置中,以下的命令将转储下一跳(下一跳将发送overlay BUM流量)。

    • vrf 2在每个worker节点上都有vn1的路由
    • all.txt上具有20个节点的IP
    • 当BUM数据包从“ Introspect Host”上的容器发送时,它们以单播overlay的方式发送到“dip”地址
    [root@ip-172-31-12-135 ~]# for i in $(cat all.txt); do ./contrail-introspect-cli/ist.py --host $i vr route -v 2 --family layer2 ff:ff:ff:ff:ff:ff -r | grep -w -e dip -e Introspect | sort -r | uniq ; done
    Introspect Host: 172.31.15.27
                      dip: 172.31.7.18
    Introspect Host: 172.31.4.249
                      dip: 172.31.9.151
                      dip: 172.31.9.108
                      dip: 172.31.8.233
                      dip: 172.31.2.127
                      dip: 172.31.10.233
    Introspect Host: 172.31.14.220
                      dip: 172.31.7.6
    Introspect Host: 172.31.8.219
                      dip: 172.31.3.56
    Introspect Host: 172.31.7.223
                      dip: 172.31.3.56
    Introspect Host: 172.31.2.127
                      dip: 172.31.7.6
                      dip: 172.31.7.18
                      dip: 172.31.4.249
                      dip: 172.31.3.56
    Introspect Host: 172.31.14.255
                      dip: 172.31.7.6
    Introspect Host: 172.31.7.6
                      dip: 172.31.2.127
                      dip: 172.31.14.255
                      dip: 172.31.14.220
                      dip: 172.31.13.115
                      dip: 172.31.11.208
    Introspect Host: 172.31.10.233
                      dip: 172.31.4.249
    Introspect Host: 172.31.15.232
                      dip: 172.31.7.18
    Introspect Host: 172.31.9.108
                      dip: 172.31.4.249
    Introspect Host: 172.31.8.233
                      dip: 172.31.4.249
    Introspect Host: 172.31.8.206
                      dip: 172.31.3.56
    Introspect Host: 172.31.7.142
                      dip: 172.31.3.56
    Introspect Host: 172.31.15.210
                      dip: 172.31.7.18
    Introspect Host: 172.31.11.208
                      dip: 172.31.7.6
    Introspect Host: 172.31.13.115
                      dip: 172.31.9.151
    Introspect Host: 172.31.7.18
                      dip: 172.31.2.127
                      dip: 172.31.15.27
                      dip: 172.31.15.232
                      dip: 172.31.15.210
    Introspect Host: 172.31.3.56
                      dip: 172.31.8.219
                      dip: 172.31.8.206
                      dip: 172.31.7.223
                      dip: 172.31.7.142
                      dip: 172.31.2.127
    Introspect Host: 172.31.9.151
                      dip: 172.31.13.115
    [root@ip-172-31-12-135 ~]#
    

    举例来说,我尝试从worker 172.31.7.18上的一个容器向一个多播地址($ ping 224.0.0.1)发送ping信息,它向dip列表中的计算节点发送了4个数据包。

    [root@ip-172-31-7-18 ~]# tcpdump -nn -i eth0 -v udp port 6635
    
    15:02:29.883608 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 170)
        172.31.7.18.63685 > 172.31.2.127.6635: UDP, length 142
    15:02:29.883623 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 170)
        172.31.7.18.63685 > 172.31.15.27.6635: UDP, length 142
    15:02:29.883626 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 170)
        172.31.7.18.63685 > 172.31.15.210.6635: UDP, length 142
    15:02:29.883629 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 170)
        172.31.7.18.63685 > 172.31.15.232.6635: UDP, length 142
    

    未定义为直接下一跳的其它节点(172.31.7.223)也接收了多播数据包,尽管它的延迟有所增加。

    • 在这种情况下,需要额外增加2个跃点:172.31.7.18-> 172.31.2.127-> 172.31.3.56-> 172.31.7.223
    [root@ip-172-31-7-223 ~]# tcpdump -nn -i eth0 -v udp port 6635
    
    15:02:29.884070 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 170)
        172.31.3.56.56541 > 172.31.7.223.6635: UDP, length 142
    

    原文链接:
    https://github.com/tnaganawa/tungstenfabric-docs/blob/master/TungstenFabricKnowledgeBase.md


    往期精选

    Tungsten Fabric知识库丨vRouter内部运行探秘
    Tungsten Fabric知识库丨更多组件内部探秘
    Tungsten Fabric知识库丨 构建、安装与公有云部署

    Tungsten Fabric入门宝典系列文章——
    1.首次启动和运行指南
    2.TF组件的七种“武器”
    3.编排器集成
    4.关于安装的那些事(上)
    5.关于安装的那些事(下)
    6.主流监控系统工具的集成
    7.开始第二天的工作
    8.8个典型故障及排查Tips
    9.关于集群更新的那些事
    10.说说L3VPN及EVPN集成
    11.关于服务链、BGPaaS及其它
    12.关于多集群和多数据中心
    13.多编排器用法及配置

    posted in 博客