OpenStack Cloud Computing Cookbook（Third Edition）
上QQ阅读APP看书，第一时间看更新
上一章目录下一章

Using Neutron networks for different purposes

In Neutron, it is easy to create many private networks that allow communication between your instances. Sometimes, you might require certain features of a particular network such as when utilizing a dedicated 10G interface; creating a VLAN network to operate with a physical network device, for example, a load balancer; or a SQL Server cluster. With Neutron's SDN, an administrator can set up networks to cater for these purposes.

The following figure shows an example environment with another interface that we can use within Neutron. The physical SQL servers in this environment could be on a Subnet of 192.168.200.0/24 on VLAN 200. To use to this network from within OpenStack, we can specify another interface, eth4, that will be used to connect OpenStack Virtual instances to physical servers using this same subnet and VLAN.

The network on eth4 can be configured for a number of different VLANs as you would expect on this type of network.

Using Neutron networks for different purposes

Getting ready

Ensure that you are logged in to both the Network and Compute nodes, as we will be configuring a new interface for use with OpenStack Networking on each. If you created these nodes with Vagrant, you can execute the following command:

vagrant ssh network
vagrant ssh compute

As we will be utilizing the Neutron client too, log in to the controller node (or a suitable computer that has the python-neutronclient available). If you created these nodes with Vagrant, you can execute the following command:

vagrant ssh controller

Ensure that you have set the following credentials (adjust the path to your certificates and key file to match your environment if not using the Vagrant environment):

export OS_TENANT_NAME=cookbook
export OS_USERNAME=admin
export OS_PASSWORD=openstack
export OS_AUTH_URL=https://192.168.100.200:5000/v2.0/
export OS_NO_CACHE=1
export OS_KEY=/vagrant/cakey.pem
export OS_CACERT=/vagrant/ca.pem

How to do it...

An example environment might have a tenant Neutron network configured such that the tunneling occurs over 1G interfaces; in our environment, this could be our eth2 bridge, br-eth2. The environment can also utilize any number of network interfaces that might route to different devices or be cabled up to different segments of the network. In OpenStack networking, we create new bridges that Neutron knows about that an administrator can use when creating networks.

As an administrator of the tenant, carry out the following instructions to set up this new interface bridge and specify a Neutron network, of type VLAN, that allows us to communicate with the physical servers on 192.168.200.0/24:

  1. We first configure this new interface on both the network and compute nodes: 
    sudo ifconfig eth4 down
sudo ifconfig eth4 0.0.0.0 up
sudo ip link set eth4 promisc on

    Tip

    On a physical server running Ubuntu, we would configure this in our /etc/network/interfaces file as follows:

    auto eth4
iface eth4 inet manual 
  up ip link set $IFACE up
  down ip link set $IFACE down
  2. We then create a new bridge in OVS that includes the new eth4 interface. We do this on all Compute and network nodes in our environment using the following commands: 
    sudo ovs-vsctl add-br br-eth4
sudo ovs-vsctl add-port br-eth4 eth4
  3. As we are using VLANs for this example, we need to configure our ML2 Plugin configuration to be aware of the interface(s) used for VLAN networks. To do so, edit the /etc/neutron/plugins/ml2/ml2_conf.ini file so it has the following content: 
    [ml2]
type_drivers = gre,vxlan,vlan
tenant_network_types = vxlan
mechanism_drivers = openvswitch,l2population

[ml2_type_gre]
tunnel_id_ranges = 1:1000

[ml2_type_vxlan]
vxlan_group =
vni_ranges = 1:1000

[vxlan]
enable_vxlan = True
vxlan_group =
local_ip = 10.10.0.202

[agent]
tunnel_types = vxlan
vxlan_udp_port = 4789

[ml2_type_vlan] 
network_vlan_ranges = physnet4:100:300

[ovs]
bridge_mappings = physnet4:br-eth4
[securitygroup]
firewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
enable_security_group = True
  4. We can use the new bridge (via bridge_mappings of physnet4) when creating a VLAN network. In this example, the SQL servers exist on the subnet 192.168.200.0/24 with VLAN ID 200. To create a Neutron network with these details, we use the following commands: 
    neutron net-create sqlServerNet \
 --provider:physical_network=physnet4 \
 --provider:network_type=vlan \
 --provider:segmentation_id=200 \
 --shared
  5. We can now use this network to create the subnet details. To do this, we will use a segment of the subnet 192.168.200.0/24 for use by OpenStack by restricting the DHCP range to avoid conflict with any physical servers already on that subnet. To do so, we issue the following commands: 
    neutron subnet-create sqlServerNet 192.168.200.0/24 \--name sqlServerSubnet \--allocation-pool start=192.168.200.201,end=192.168.200.240 \
 --gateway 192.168.200.1

We can now spin up OpenStack instances using this network, defined as sqlServerNet on the subnet 192.168.200.0/24, that can communicate with physical servers on the same subnet.

How it works...

We created another interface bridge on our Compute and network nodes that we can then use when creating VLAN Neutron networks. By using VLAN networks in this way with OpenStack, we can set up communication between our OpenStack Compute cloud environment and physical servers on that same Subnet and VLAN.

To do this, we ensured that our new eth4 interface was set to promiscuous mode and we created a bridge called br-eth4 within OVS. This bridge is then referenced in the /etc/neutron/plugins/ml2/ml2_conf.ini file within the [ovs] section, as shown here:

[ovs]
bridge_mappings = physnet4:br-eth4

We assign a mapping between that bridge and a name we can use on the neutron command line when specifying it for use, as shown in the following neutron net-create command:

neutron net-create sqlServerNet \
 --provider:physical_network=physnet4 \
 --provider:network_type=vlan \
 --provider:segmentation_id=200 \
 --shared

As you can see, we also specify that we are creating a network of type vlan and we are assigning the VLAN ID 200.

Finally, as we are creating this as an admin user, the --shared flag allows us to ensure that this network is available to all tenants.

With this network in place, we assign the relevant subnet associated with the VLAN and restrict the DHCP range to avoid conflict with the other part of this subnet. We do this within the neutron subnet-create command by specifying the --allocation-pool flag as shown here:

neutron subnet-create sqlServerNet 192.168.200.0/24 \--name sqlServerSubnet \--allocation-pool start=192.168.200.201,end=192.168.200.240 \
 --gateway 192.168.200.1

We only allow OpenStack to spin up instances between the IP addresses 192.168.200.201 and 192.168.200.240.

上一章目录下一章