OpenStack:Grizzly-Nexus-Plugin

From DocWiki

(Difference between revisions)
Jump to: navigation, search
m
m
Line 24: Line 24:
<br>
<br>
-
== Installing the COI Cache and Build Servers ==<br>
+
<br>
 +
 
 +
<br>
 +
 
 +
<br>
 +
 
 +
<br>
 +
 
 +
<br>
 +
== Installing the COI Cache and Build Servers ==

Revision as of 14:54, 5 August 2013

This article describes how to use the COI (Cisco OpenStack Installer) to setup a working OpenStack cluster, which utilizes Nexus ToR switches in VLAN mode.

Contents

Setting up the Nexus switch

The following items need to be considered before proceeding with the Cisco Nexus Plugin deployment on the OpenStack Grizzly release.

  • Your Nexus switch must be connected to a management network separate from the OpenStack data network. By default, we use the eth0 interface for this purpose. The plugin communicates with the switch over this network to set up your data flows.
  • The switch must have SSH login and XML API enabled.
  • Each compute host on the cloud should be connected to a port on the switch over a dedicated interface just for OpenStack data traffic. By default we use eth1 for this.
  • The link from the node running the DHCP agent (by default, this is the OpenStack control node) should be a trunk link trunking all VLANs used for OpenStack traffic.
  • Inter switch links should be trunk lings trunking all VLANs.


Diagram

Figure 1 Can be used to visualize the layout of the OpenStack compute nodes and the attached Nexus switches.


'Figure 1:Nexus Plugin Diagram

Nexus-plugin-diagram.png









Installing the COI Cache and Build Servers

Customization of the Puppet Manifests

The OpenStack installation is driven by Puppet. All of the site specific parameters are configured in a file called /etc/puppet/manifests/site.pp. This is only file you need to edit before starting the Puppet install. Here are the items that may require customization in order to enable the use of the Nexus switch in VLAN mode. Other customizations for your site, such as host names, network address ranges, proxies and repositories are not explained here, but are documented as comments in the site.pp file. A few explanations follow the example:

$public_interface          = 'eth0'
$external_interface        = 'eth1'
$ovs_vlan_ranges           = 'physnet1:500:600'
$ovs_bridge_uplinks        = ['br-eth1:eth1']
$ovs_bridge_mappings       = ['physnet1:br-eth1']
$quantum_core_plugin       = 'cisco'
$cisco_vswitch_plugin      = 'ovs'
$cisco_nexus_plugin        = 'nexus'
$nexus_config = {
                  '10.4.4.1' => {
                                   'my_compute_server_1' => '1/5',
                                   'my_compute_server_2' => '1/6'
                                },
                  '10.5.5.1' => {
                                   'my_compute_server_3' => '2/8',
                                   'my_compute_server_4' => '2/9',
                                   'my_compute_server_5' => '2/10',
                                }
                }
$nexus_credentials = ['10.4.4.1/my_username/my_password',
                      '10.5.5.1/my_username/my_password’]
$tenant_network_type = 'vlan'

Before specifying the VLAN address ranges in the $ovs_vlan_ranges parameter, please log into the switch to confirm that the specified address range is indeed free to use. Please avoid the use of VLAN IDs above 1000. The $nexus_config value is mapped, where for each Nexus switch (here identified by their IP addresses 10.4.4.1 and 10.5.5.1) we define a further map, specifying by hostname the various OpenStack compute servers, which are attached to that switch, as well as the port on that switch, to which the eth1 interface of that compute server is connected. In $nexus_credentials we specify for each of the Nexus switches a username and password for a user with management credentials.

Rating: 5.0/5 (2 votes cast)

Personal tools