OpenStack:Grizzly-Nexus-Plugin

From DocWiki

Revision as of 15:18, 5 August 2013 by Shmcfarl (Talk | contribs)
Jump to: navigation, search

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.

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

Below are the manual install steps for creating a build server.

Perform an update/upgrade and install Puppet, Git and ipmitool on the freshly installed Ubuntu 12.04 LTS node:

apt-get update && apt-get dist-upgrade -y && apt-get install -y puppet git ipmitool

NOTE: The system may need to be restarted after applying the updates. Get the Cisco OpenStack Installer (COI) example manifests. Under the grizzly-manifests GitHub repository you will find different branches, so select the one that matches your topology plans most closely. In the following examples the multi-node branch will be used, which is likely the most common topology:

git clone –b multi-node https://github.com/CiscoSystems/grizzly-manifests
cd ~/grizzly-manifests

With a proxy:

https_proxy=http://proxy.example.com:80 git clone –b multi-node https://github.com/CiscoSystems/grizzly-manifests ~/grizzly-manifests/
cd ~/grizzly-manifests

Copy the puppet manifests from ~/grizzly-manifests/manifests/ to /etc/puppet/manifests/

cp ~/grizzly-manifests/manifests/* /etc/puppet/manifests

Copy the puppet templates from ~grizzly-manifests/templates/ to /etc/puppet/templates/

cp ~/grizzly-manifests/templates/* /etc/puppet/templates

Until the repo moves from "grizzly-proposed" to "grizzly" we need to make a modification in the /etc/puppet/manifests/puppet_modules.py file to point to the correct repo. Edit the /etc/puppet/manifests/puppet_modules.py file and change the following:

  • Change the REPO_NAME from "grizzly" to "grizzly-proposed" (around line 29)

Also, edit the /etc/puppet/manifests/core.pp file and change the following:

  • Change the release from "grizzly" to "grizzly-proposed" (around line 28)

Then get the Cisco OpenStack Installer puppet modules from Cisco's GitHub repository: (cd /etc/puppet/manifests; python /etc/puppet/manifests/puppet_modules.py) With a proxy: (cd /etc/puppet/manifests; http_proxy=http://proxy.example.com:80 https_proxy=http://proxy.example.com:80 python /etc/puppet/manifests/puppet-modules.py)

Running the puppet manifest site.pp file routine.

IMPORTANT! You must copy site.pp.example to site.pp and then edit it as appropriate for your installation. It is internally documented.

cp /etc/puppet/manifests/site.pp.example /etc/puppet/manifests/site.pp 
vi /etc/puppet/manifests/site.pp

In addition to the basic site.pp modification for your environment, changes for the Nexus plugin needs to be made. 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