검색

이 콘텐츠는 선택한 언어로 제공되지 않습니다.

Chapter 7. ML2 networking-ansible

download PDF

This section contains information on the networking-ansible ML2 driver in OpenStack Networking (neutron), integration with OpenStack Bare Metal (ironic), and instructions on enabling and configuring this driver on an overcloud.

7.1. Modular Layer 2 (ML2) networking-ansible

OpenStack Networking (neutron) contains networking-ansible, which is an ML2 driver that uses Ansible Engine Networking to manage network switches. This driver also integrates with OpenStack Bare Metal (ironic) to configure VLANs on switch ports for the bare metal guests. This means that the overcloud deployment process triggers the networking-ansible driver to configure any bare metal guests that use a VLAN neutron network and their respective the physical switch.

The current networking-ansible driver includes the following functionality:

  • Define a VLAN on the switch when creating a network in OpenStack
  • Assign a VLAN to an access port on the switch when creating or updating a port in OpenStack
  • Remove a VLAN from an access port on the switch when deleting a port in OpenStack

7.2. Networking requirements for networking-ansible

The following list outlines the networking requirements to enable networking-ansible functionality.

  • A network switch with Ansible Network Automation support. Red Hat currently only supports the use of Juniper Networks (junos ) switches.
  • The network switch also requires an SSH user so that Ansible Network Automation can interact with the device. This user requires certain permissions on the switch:

    • Access mode
    • Assign a VLAN to a port
    • Create VLANs

    For security purposes, do not provide the SSH user with administrator access to the switch.

  • If managing VLAN manually, prepare the VLANs you intend the switch to use, which involves creating the VLANs for the respective switch ports. This requirement is based on the manage_vlans option when enabling the networking-ansible functionality.
  • The network switch ports reserved for bare metal guests initially require configuration to connect to the dedicated network for introspection. Beyond this, these ports require no additional configuration.

7.3. Openstack Bare Metal (ironic) requirements for networking-ansible

The networking-ansible driver integrates with the Openstack Bare Metal (ironic) service. To ensure successful integration, deploy the ironic service to your overcloud with the following recommendations:

  • The overcloud requires a provisioning network. Use one of the following options:

    • A bridged network for Ironic services.
    • A custom composable network for Ironic services.

    For more examples of configuring the provisioning network, see Chapter 3, Deploying an Overcloud with the Bare Metal Service.

  • The overcloud requires a tenant network for the bare metal systems to use after the provisioning process. The examples in this guide use the default baremetal network mapped to a bridge named br-baremetal. This network also requires a range of VLAN IDs. The following Heat parameters set these values to suit examples in this guide:

    parameter_defaults:
      NeutronNetworkVLANRanges: baremetal:1200:1299
      NeutronFlatNetworks: datacentre,baremetal
      NeutronBridgeMappings: datacentre:br-ex,baremetal:br-baremetal

For more information on deploying OpenStack Bare Metal (ironic), see Chapter 3, Deploying an Overcloud with the Bare Metal Service.

7.4. Enabling networking-ansible ML2 functionality

This procedure contains information on how to enable the networking-ansible ML2 driver in your overcloud. This involves adding two environment files to your deployment:

/usr/share/openstack-tripleo-heat-templates/environments/neutron-ml2-ansible.yaml
This file enables the networking-ansible driver and sets the network type to vlan. This file already exists in the core Heat template collection.
/home/stack/templates/ml2-ansible-hosts.yaml
This file contains details about your switches. You create this file manually.

Procedure

  1. Create the /home/stack/templates/ml2-ansible-hosts.yaml and add the following initial content:

    parameter_defaults:
      ML2HostConfigs:
  2. Include a dict definition in the ML2HostConfigs parameter for each switch in your environment. Each dict key is the name of the switch and defines a specific ansible:[switchname] section in your OpenStack Networking (neutron) ML2 configuration. The dict value for each switch contains the switch details. For example, to configure three switches, add three switch keys to the ML2HostConfigs parameter:

    parameter_defaults:
      ML2HostConfigs:
        switch1:
          [SWITCH DETAILS]
        switch2:
          [SWITCH DETAILS]
        switch3:
          [SWITCH DETAILS]
  3. Include the following key value pairs for each switch dict:

    ansible_network_os
    (Required) The operating system of the switch. Red Hat currently only supports junos.
    ansible_host
    (Required) The IP or hostname of the switch.
    ansible_user
    (Required) The user that Ansible uses to access the switch.
    ansible_ssh_pass
    (Required) The SSH password that Ansible uses to access the switch.
    mac
    Chassis MAC ID of the network device. Used to map the link layer discovery protocol (LLDP) MAC address value to the switch name defined in the ML2HostConfigs configuration.
    manage_vlans
    A Boolean variable to define whether OpenStack Networking (neutron) controls the creation and deletion of VLANs on the physical device. This functionality causes the switch to create and delete VLANs with IDs respective to their Neutron networks. If you have predefined these VLANs on the switch and do not require Neutron to create or delete VLANs on the switch, set this parameter to false. The default value is true.
  4. The following example shows how to map these values to their respective keys in a full ML2HostConfigs parameter:

    parameter_defaults:
      ML2HostConfigs:
        switch1:
          ansible_network_os: junos
          ansible_host: 10.0.0.1
          ansible_user: ansible
          ansible_ssh_pass: "p@55w0rd!"
          mac: 01:23:45:67:89:AB
          manage_vlans: false
  5. Save the /home/stack/templates/ml2-ansible-hosts.yaml file.
  6. When running the overcloud deployment command, include the /usr/share/openstack-tripleo-heat-templates/environments/neutron-ml2-ansible.yaml and /home/stack/templates/ml2-ansible-hosts.yaml files with the -e option:

    $ openstack overcloud deploy --templates \
      ...
      -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-ml2-ansible.yaml \
      -e /home/stack/templates/ml2-ansible-hosts.yaml \
      ...

The director enables the driver as a part of the OpenStack Networking (neutron) API on the neutron_api container.

7.5. Configuring networks for networking-ansible

After deploying the overcloud with bare metal provisioning and the networking-ansible driver enabled, create the following networks for your bare metal nodes:

Provisioning network
Bare metal systems use this network for their initial creation.
Tenant network
Bare metal systems switch to this network after provisioning and use this network for internal communication.

Procedure

  1. Create the provisioning network and subnet. This depends on the type of provisioning network you are using. See Chapter 4, Configuring for the Bare Metal Service After Deployment for information on configuring the provisioning network.
  2. Create a tenant network and subnet:

    $ openstack network create --provider-network-type vlan --provider-physical-network baremetal tenant-net
    $ openstack subnet create --network tenant-net --subnet-range 192.168.3.0/24 --allocation-pool start=192.168.3.10,end=192.168.3.20 tenant-subnet

    Ensure that you set the --provider-network-type option to vlan to ensure networking-ansible functionality.

7.6. Configuring ports for bare metal guests

Bare metal guests require port information to connect to the switch. To accomplish this, set the OpenStack Networking (neutron) port configuration. Use this method if your overcloud does not include bare metal introspection functionality.

Procedure

  1. Create a port for the bare metal node. Use the following example command as a basis to create the port:

    $ openstack baremetal port create [NODE NIC MAC] --node [NODE UUID] \
        --local-link-connection port_id=[SWICH PORT ID] \
        --local-link-connection switch_info=[SWITCH NAME] \
        --local-link-connection switch_id=[SWITCH MAC]

    Replace the following values in brackets with your own environment details:

    [NODE NIC MAC]
    The MAC address of the NIC connected to the switch.
    --node [NODE UUID]
    The UUID of the node that uses the new port.
    --local-link-connection port_id=[SWITCH PORT ID]
    The port ID on the switch connecting to the bare metal node.
    --local-link-connection switch_info=[SWITCH NAME]
    The name of the switch connecting to the bare metal node. The switch name must match the respective switch name you defined in the ML2HostConfigs parameter.
    --local-link-connection switch_id=[SWITCH MAC]
    The MAC address of the switch. This must match the respective mac value from the switch configuration from the ML2HostConfigs parameter. This is an alternative option to using switch_info.

7.7. Testing networking-ansible ML2 functions

After the networking-ansible configuration for the bare metal node is complete, test the functionality to ensure it works. This involves creating a bare metal workload.

Prerequisites

  • An overcloud with OpenStack Baremetal (ironic) services.
  • An enabled networking-ansible ML2 driver.
  • The ML2HostConfigs parameter contains switch access details.
  • A registered bare metal node.

    1. Configuration of the respective bare metal port used for the node connection on the switch.
  • A VLAN-based provisioning network defined in OpenStack Networking (neutron) for initial provisioning.
  • A VLAN-based tenant network defined in OpenStack Networking (neutron) for internal communication.

Procedure

  1. Create the bare metal system:

    openstack server create --flavor baremetal --image overcloud-full --key default --network tenant-net test1

    The overcloud initially creates the bare metal system on the provisioning network. When the creation completes, the networking-ansible driver changes the port configuration on the switch so that the bare metal system uses the tenant network.

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.