OVA Installation Guide
OVA Installation Guide
THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO
CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS
MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY
PRODUCTS.
The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB’s public
domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.
NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS” WITH
ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT
LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF
DEALING, USAGE, OR TRADE PRACTICE.
IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING,
WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO
OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this
URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership
relationship between Cisco and any other company. (1721R)
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display
output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in
illustrative content is unintentional and coincidental.
Preface v
ii-viii
Overview 1-1
This preface describes the audience, organization, and conventions of the Cisco DCNM 7.0 OVA
Installation Guide. It also provides information on how to obtain related documentation.
This preface includes the following topics:
• Audience, page v
• Document Conventions, page v
• Document Conventions, page v
• Related Documentation, page vi
• Obtain Documentation and Submit a Service Request, page viii
Audience
This publication is for experienced network administrators who plan to install Cisco Data Center
Network Manager (DCNM) Open Virtual Appliance (OVA) to configure, monitor, and maintain
applications that provide a central point of management for Cisco Dynamic Fabric Automation (DFA).
Cisco DFA works with only certain Cisco Nexus products. Consult your Cisco DFA documentation for
specific information about products that work with Cisco DFA.
Document Conventions
This document uses the following conventions:
Note Means reader take note. Notes contain helpful suggestions or references to material not covered in the
manual.
Caution Means reader be careful. In this situation, you might do something that could result in equipment
damage or loss of data.
• Cisco Data Center Network Manager Open Virtual Appliance is also referred to as Cisco DCNM
OVA.
• Cisco Dynamic Fabric Automation is also referred to as Cisco DFA.
Related Documentation
This section contains information about the documentation available for Cisco DCNM OVA, Cisco DFA,
and for the platforms that Cisco DCNM OVA and Cisco DFA manages.
This section includes the following topics:
• Cisco DCNM Documentation, page vi
• Cisco Nexus 1000V Series Switch Documentation, page vii
• Cisco Nexus 2000 Series Fabric Extender Documentation, page vii
• Cisco Nexus 3000 Series Switch Documentation, page vii
• Cisco Nexus 4000 Series Switch Documentation, page vii
• Cisco Nexus 5000 Series Switch Documentation, page viii
• Cisco Nexus 6000 Series Switch Documentation, page viii
• Cisco Nexus 7000 Series Switch Documentation, page viii
• Cisco Network Services Controller Documentation, page viii
• Cisco Dynamic Fabric Automation Documentation, page viii
Release Notes
Virtual Device Context Configuration Guide, Cisco DCNM for LAN, Release 6.x
Virtual Device Context Quick Start, Cisco DCNM for LAN, Release 5.x
Web Services API Guide, Cisco DCNM for LAN, Release 5.x
System Management Configuration Guide, Cisco DCNM for SAN, Release 6.x
Interfaces Configuration Guide, Cisco DCNM for SAN, Release 6.x
Fabric Configuration Guide, Cisco DCNM for SAN, Release 6.x
Quality of Service Configuration Guide, Cisco DCNM for SAN, Release 6.x
Security Configuration Guide, Cisco DCNM for SAN, Release 6.x
IP Services Configuration Guide, Cisco DCNM for SAN, Release 6.x
Intelligent Storage Services Configuration Guide, Cisco DCNM for SAN, Release 6.x
High Availability and Redundancy Configuration Guide, Cisco DCNM for SAN, Release 6.x
Inter-VSAN Routing Configuration Guide, Cisco DCNM for SAN, Release 6.x
SMI-S and Web Services Programming Guide, Cisco DCNM for SAN, Release 6.x
This chapter describes how to install Cisco Data Center Network Manager (DCNM) Open Virtual
Appliance (OVA) components and includes the following sections:
• Information About the Cisco DCNM OVA section, page 2-1
• Cisco DCNM OVA and Cisco Dynamic Fabric Automation section, page 2-1
• Installing the Cisco DCNM OVA section, page 2-2
• Configuring the Oracle Database for DCNM section, page 2-8
• Upgrading Cisco DCNM 7.0(1) to Version 7.0(2) section, page 2-9
Note For more information about Cisco Dynamic Fabric Automation, see to the Cisco Dynamic Fabric
Automation Solutions Guide.
Note For detailed information about each of the applications that provide the Cisco DFA CPOM functions in
Cisco DCNM, see Chapter 3, “Managing Applications After the DCNM OVA Deployment .’.
Note If you are using a high-availability (HA) environment for applications that are bundled within the DCNM
OVA, you must download the OVA and deploy twice, once for Active and once for Host-Standby. For
more information, see Chapter 4, “Managing Applications in a High-Availability Environment .’.
Verifying Prerequisites
Before you install the Cisco DCNM OVA, you will need to meet following software and database
requirements:
• VMware vCenter Server 5.1.0 that is running on a Windows server (or alternatively, running as a
virtual appliance)
• VMware ESXi 5.1.0 host imported into vCenter
• Two port groups on the ESXi host: one for the dcnm-mgmt-network and one for the
enhanced-fabric-mgmt network.
• VMware vSphere client application installed on your desktop
Note The OVA cannot be deployed by connecting the vSphere client directly to the ESXi server.
• Determine the number of switches in your Cisco DFA fabric that will be managed by the Cisco
DCNM OVA.
– If you will be managing more than 50 switches or you expect the number of switches to grow
over time, use an Oracle database.
See “Configuring the Oracle Database for DCNM” section on page 2-8 for information on
configuring the Oracle database.
Note Once you start using the PostgreSQL database that is built in to the Cisco DCNM OVA, you
cannot migrate the data to an Oracle database.
Note For a complete list of prerequisites that are associated with Cisco DCNM, see the Cisco DCNM
Installation and Licensing Guide, Release 7.x.
Note To accommodate for HA application functions, additional prerequisites are required. See the
Prerequisites for Cisco DCNM OVA HA section, page 4-2.
Note If you plan to use HA application functions, you must deploy the dcnm.ova file twice.
DETAILED STEPS
Step 3 In the Select a Product section, navigate to the DCNM software by choosing Products > Switches >
Data Center Switches > Data Center Network Management > Cisco Prime Data Center Network
Manager.
A list of the latest release software for Cisco DCNM is available for download.
Step 4 In the Latest Releases list, choose 7.0.(x)
Step 5 Locate the DCNM OVA Installer and click the Download button.
Step 6 Save the dcnm.ova file to your computer in a place that will be easy to find when you start to deploy the
OVF template.
DETAILED STEPS
Note You cannot deploy the OVA by connecting the vSphere Client directly to the ESXi server.
Some of the details about the Cisco DCNM virtual appliance include:
• Version number
• Download size
• Size on disk:
– Thin provision for the amount of disk space consumed by the virtual appliance immediately
after deployment. It is the minimum amount of disk space needed to deploy the virtual
appliance.
– Thick provision for the maximum amount of disk space the virtual appliance can consume.
Note For more information on thick and thin provision, see "Step 11 - Choose the disk format."
task on page 2-5
Step 5 Read and accept the End User License Agreement and click Next.
Step 6 Specify the name and location of the Cisco DCNM OVA.
a. In the Name box, enter a name for the virtual appliance. This name is not the hostname, but the name
of the virtual appliance hardware and is specific to the vSphere infrastructure.
The name can contain up to 80 alphanumeric characters and must be unique within the Inventory
folder.
b. In the Inventory Location tree, choose the folder location for the virtual appliance.
c. Click Next.
Step 7 Choose the deployment configuration:
• Choose Small to configure the virtual machine with two vCPUs and 8G RAM.
• Choose Large to configure the virtual machine with four vCPUs and 12G RAM.
Note We recommend that you use a Large deployment configuration when you are managing more
than 50 devices (and up to the upper limit of the Cisco DFA fabric) to leverage better RAM, heap
memory, and CPUs.
Choose Small for proof-of-concept and other small-scale environments with fewer than 50
switches that are not expected to grow with time.
Note A host will not be available if you already selected a host in the vSphere Client before you deploy
the OVA.
Step 10 Choose the a destination storage for the virtual machine files and click Next.
Step 11 Choose the disk format.
• Choose one of the thick provision types if you have enough storage capacity as required by the
virtual appliance and want to set a specific allocation of space for the virtual disks:
– Thick Provision Lazy Zeroed: The space that is required for the virtual disk is allocated when
the virtual disk is created. The data that remains on the physical device is not erased when the
virtual disk is created but is zeroed out on demand at a later time on first write from the virtual
disk.
– Thick Provision Eager Zeroed: The space that is required for the virtual disk is allocated when
the virtual disk is created. Unlike the Lazy Zeroed option, the data that remains on the physical
device is erased when the virtual disk is created.
• Choose Thin Provision if you have less than 100 GB of disk space available. The initial disk
consumption will be 2.8 GB and will increase as the size of the database increases with the number
of devices being managed.
Step 12 Click Next.
Step 13 Choose your network mapping.
a. The dcnm-mgmt network provides connectivity (ssh, scp, http, https) to the Cisco DCNM OVA. In
the Destination Network column, associate the network mapping with the port group that
corresponds to the subnet that is associated with the Cisco DCNM management network.
b. Map the enhanced-fabric-mgmt network to the port group that connects to the management network
of switches.
Note If you are deploying more than one OVA for HA functionality, you must meet the following criteria:
• Both OVAs should have their management access (eth0) and enhanced fabric management (eth1)
interfaces in the same subnet.
• Both OVAs should be deployed with the same administrative password. This is to ensure that both
OVAs are duplicates of each other for application access.
Step 14 Click Next.
Step 15 Choose the Cisco DCNM OVA Properties.
a. The Application Management check box is selected by default to install applications related to
DFA.
DFA includes implementations for the following protocols:
– XMPP
– LDAP
– DHCP
– AMQP
DFA includes implementations for the following repositories:
– TFTP
– SCP/SFTP
b. In the Management Properties section, enter a password in the Enter Password and Confirm
Password boxes to establish the password that will be used to connect all applications in the DCNM
OVA.
Note The password must be at least eight characters long and must contain at least one alphabetic
and one numeric character. It can contain the only the following special characters: .(dot), +
(plus), _ (underscore), and - (hyphen).
If you do not comply with these password requirements, you can continue with the OVA
deployment; however, you subsequently may not be able to log in to other applications like
DCNM.
– Hostname (should be a fully qualified domain name, otherwise you may encounter issues when
using the XMPP application after deployment)
– IP Address (for the outside management address for DCNM)
– Subnet Mask
– Default Gateway
– DNS IP
d. In the Enhanced Fabric Management section, complete each of the required fields:
– IP Address (for the inside fabric management address or OOB Management Network)
– Subnet mask
– DNS IP
Step 16 Click Next
Step 17 Review each of the deployment settings that you have established. Press the Back button to go to any
settings if you want to change them.
After you have reviewed each of the deployment settings in the OVF template, perform the following
procedure to deploy the virtual machine.
Note The time for the OVA deployment could take 5 to 6 minutes (or more) depending on the network
latency.
Note For more information about verifying application status see the Verifying the Application Status
after Deployment section, page 3-8.
Note If you are deploying multiple OVAs for HA functions, you should deploy both the OVAs with
the same administrative password. This action ensures that both OVAs are duplicates of each
other for application access.
Note See the DCNM 7.0 Fundamentals Guide for configuration information.
Note Once you start using the PostgreSQL database that is built in to the Cisco DCNM OVA, you cannot
migrate the data to an Oracle database.
Note If you configure a remote Oracle database for both DCNM and XMPP in an appliance (OVA/ISO), create
two separate database users—one for the DCNM and the other for XMPP.
Step 1 Prepare the Oracle database as described in the Cisco DCNM Installation and Licensing Guide, Release
7.x.
Note If you are configuring the Oracle database for an HA environment, only Step 1 is required. If
you are configuring the Oracle database for a standalone DCNM, continue with the following
steps in the procedure.
Step 2 Get the JDBC database URL, database username, and database password.
Step 3 Stop the Cisco DCNM application in the OVA.
Step 4 Open the Secure Shell (SSH) terminal and enter the following CLI command:
appmgr update dcnm -u <DB_URL> -n <DB_USER> -p <DB_PASSWORD>
Step 5 Enter the root password of the Cisco DCNM OVA. This password is used to access AMQP/LDAP by
default. You can change this password later in Cisco DCNM by using the following path: Admin -> DFA
Settings.
[root@DCNM ~]# appmgr update dcnm -u jdbc:oracle:thin:@10.77.247.11:1521:XE -n extuser -p
extuserpwd
The external DCNM DB will be configured so that all DFA applications can be accessed using
the root password of this server. You can later change them in the DCNM Web UI: Admin >
DFA Settings
Root password :
Enter it again for verification:
Please wait...this could take a few minutes
done.
Step 6 Start the Cisco DCNM application in the OVA.
Step 7 Update the DFA setting in Cisco DCNM, if necessary.
Step 1 Use the appmgr backup all command to backup all applications associated with the installation of
Cisco DCNM 7.0(1).
Step 2 Back up Cisco DCNM 7.0(1) license files.
a. Backup the license files saved in the following directory: /usr/local/cisco/dcm/licenses/.
b. On Cisco Prime DCNM 7.0(2), ensure that the MAC address along with all network settings such
as the IP address, default gateway, hostname, etc., are identical to the Cisco DCNM 7.0(1)
installation.
c. Copy the contents of the Cisco DCNM 7.0(1) files you backed up from the
/usr/local/cisco/dcm/licenses/ directory into the Cisco DCNM 7.0(2) /usr/local/cisco/dcm/licenses/
directory.
Step 3 If you are using customized scripts like vCDclient.py, CPNR.py, move these files manually.
a. Backup the following files and put these files in the same location by changing the name.
(For example - /root/utils/vCDclient_backup.py).
/root/utils/vCDclient.py
root/utils/vCDclient-ini.conf
root/utils/CPNRclient.py
root/utils/CPNRclient-ini.conf
Note If you are using a customized poap_dcnm.py script in Cisco DCNM 7.0.(1), after migration the
script will be saved as /var/lib/dcnm/poap_dcnm_backup.py in Cisco DCNM 7.0(2) and the new
poap_dcnm.py will be there.
Note If you choose option [2] Standalone DCNM with External Oracle database, make sure that
the external database is up and running.
Note For more information on Active and Standby peers in a High Availability environment, see “Managing
Applications in a High-Availability Environment”.
Step 1 Make sure that Cisco DCNM 7.0(2) Active and Standby peers are both deployed but not powered on.
Note Make sure that the MAC address and all network settings, such as the IP address, default
gateway, hostname, etc., are identical to the Cisco DCNM 7.0(1) installation.
Step 2 Verify that the appmgr backup all command was run on both the Active and Standby peers and that
separate tar archives were stored in an external file system (for example, as active.tar.gz and
standby.tar.gz)
Step 3 Follow the same steps for the license files and other script files (vCDclient.py, CPNRclient.py etc) as
instructed in “Migrating Cisco DCNM with a Local PostgreSQL Database and an External Oracle
Database” section on page 2-9.
Step 4 Power off the Cisco DCNM 7.0(1) Active peer.
Step 5 Wait 4 to 5 minutes and then stop the DCNM application on the Cisco DCNM 7.0.(1) Standby peer.
This is to ensure that write operations to LDAP are prevented (which could lead to LDAP getting into
an inconsistent state).
Step 6 Power-on the Cisco DCNM 7.0(2) Active peer.
Step 7 Stop all of the applications on the Cisco DCNM 7.0(2) Active peer.
Step 8 Use the appmgr upgrade <active.tar.gz> command to run the upgrade script.
a. Choose option [3] High Availability when prompted.
Choose option [1] Standalone DCNM with Local PostgreSQL database
[2] Standalone DCNM with External Oracle database
[3] High Availability
Step 9 All applications are running on the Cisco DCNM 7.0(2) Active peer; power-off the Cisco Prime DCNM
7.0(1) Standby peer.
Step 10 Power on the Cisco DCNM 7.0(2) Standby peer.
Step 11 Stop all applications on the Cisco DCNM 7.0(2) Standby peer. (After waiting for all applications to start
during OS boot up).
Step 12 Use the appmgr upgrade <standby.tar.gz> command to run the upgrade script.
a. Choose option [3] High Availability when prompted.
Choose option[1] Standalone DCNM with Local PostgreSQL database
[2] Standalone DCNM with External Oracle database
[3] High Availability
Step 13 Invoke the following on the Active peer to establish SSH trust to the Standby peer:
sh /root/sshAutoLogin.sh <STANDBY_PEER_IP>
This chapter describes how to verify and manage all of the applications that provide Cisco Dynamic
Fabric Automation (DFA) central point of management functions after the DCNM open virtual appliance
(OVA) is deployed. This chapter includes the following sections:
• Cisco DCNM OVA Applications, page 3-1
• Application Details, page 3-2
• Managing Applications, page 3-8
• Backing Up Cisco DCNM and Application Data, page 3-12
• Restoring Applications, page 3-14
Note For instructions on installing these applications with the Cisco DCNM OVA, see the “Installing the Cisco
DCNM OVA” section on page 2-2.
Note For information about managing these applications in a high-availability (HA) environment, see
“Managing Applications in a High-Availability Environment” section on page 4-1.
Protocol
Category Application Username Password Implemented
Network Data Center admin User choice1 Network
Management Network Management
Manager
Network Services Cisco Prime created by Cisco created by Cisco Network services
Network Prime Network Prime Network (firewall and
Services Services Services load balancing)
Controller Controller Controller
Adapter administrator administrator
Orchestration RabbitMQ admin User choice1 Advanced
Messaging
Queuing
Protocol
Orchestration OpenLDAP cn=admin User choice1 Lightweight
dc=cisco Directory Access
dc=com Protocol
Group Provisioning Cisco Jabber admin@fully User choice1 Extensible
of Switches Extensible qualified domain Messaging and
Communications name (FQDN)2 Presence
Platform (XCP) Protocol
Device Power On Dhcpd — — Dynamic Host
Auto-Provisioning Configuration
Protocol
Device Power on Tftp servers2 — — Trivial File
Auto-Provisioning Transfer
SSH/SFTP
server Protocol
1
User choice refers to the administration password entered by the user during OVA deployment.
2FQDN is the one that was entered during OVA deployment
2
Place the files that you want to be accessed from outside through TFTP at /var/lib/dcnm/.
Application Details
This section describes the details of all the applications within the functions they provide in Cisco
DCNM. The functions are as follows:
• Network Management
• Network Services
• Orchestration
• Power On Auto Provisioning (POAP)
• Group provisioning of switches
Network Management
The data center network management function is provided by the Cisco Prime Data Center Network
Manager (DCNM) server. Cisco DCNM provides the setup, visualization, management, and monitoring
of the data center infrastructure. Cisco DCNM can be accessed from your browser: http://[host/ip].
Network Services
In the Cisco DFA solution, traditional services, such as firewalls and load balancers, are deployed at
regular leaf nodes within the spine-leaf topology, and at border leaf nodes, unlike more traditional data
centers where these services are deployed at the aggregation layer.
Cisco Prime Network Services Controller (Prime NSC) provides the orchestration and automation of
network services in Cisco DFA. The Prime NSC supports integration with virtual computer and storage
managers such as vCenter and System Center Virtual Machine Manager (SCVMM) and provides
end-to-end orchestration and automation for services in Cisco DFA.
Note For more information about the Prime NSC, see the Cisco Prime Network Services Controller
documentation at the following URL:
http://www.cisco.com/en/US/partner/products/ps13213/tsd_products_support_series_home.html
A Prime NSC Adapter is bundled within the Cisco DCNM OVA. It performs the following functions:
• Enables DCNM to interoperate with one or more instances of the Prime NSC.
• Provides translation of DCNM language and objects into the Prime NSC language and objects.
• Ensures that the Prime NSC and DCNM are always synchronized.
• Maps the tenants and virtual data centers to the Prime NSC instances responsible for network
services
Note The Prime NSC Adapter supports DCNM-to-Prime NSC integration for multiple Prime NSC instances. A
single Prime NSC instance is not able to fulfill DFA scalability requirements for tenants and VMs.
Consequently, multiple instances are required to achieve the scale that DFA requires.
You can create instances with the help of a Prime NSC Adapter Manager CLI feature. See the “Cisco
Prime Network Services Controller Adapter Manager Command-Line Interface” section on page 3-5.
• The Prime NSC web UI does not allow any admin or tenant-admin to modify any of the tenant
scoped L2 network- and subnetwork-related information. This restriction does not apply to
management on HA L2 networks and subnetworks that are managed by the Prime NSC
administrator.
• If you create, update, or delete a network service in Prime NSC, it will be reflected in both DCNM
and the Prime NSC.
Before you begin to configure connectivity with DCNM, confirm the following:
• DCNM is running
• Enhanced fabric management network was enabled during DCNM deployment
• You have network access to DCNM
• You have appropriate privileges for configuring DCNM
• You have deployed the Prime NSC in Orchestrator mode.
• The Prime NSC administrator has created a user account, with administrator role, for use only by
Prime NSC Adapter in DCNM
Command Description
nsc-adapter-mgr [-h|--help] Displays help
nsc-adapter-mgr adapter{start | stop | status | connections} Starts/stops or displays the running
status of the Prime NSC Adapter, or
displays the status of the NSC
Adapter connections
nsc-adapter-mgr dcnm update ip-address username Updates Cisco DCNM instances with
password provided IP address, user name, and
password.
nsc-adapter-mgr nsc {[add ip-address user name password | Adds, updates, or removes an
update ip-address username password | remove ip-address existing Prime NSC instance
[force] | list-instances [{org | tenant} org/tenant {partition | identified by the provided IP address
vdc} partition/vdc] | list {org | tenants} instance ip-address]} with provided user name and
password.
When using list-instances, shows the
status of all Prime NSC instances or
displays the status of Prime NSC
instances belonging to the provided
Tenant or the provided VDC.
Note See the Cisco Prime Network Services Controller User Guide for more information about Cisco Prime
Network Services Controller.
Config Profiles
When you are using autoconfiguration for DFA, the network is associated with a configuration profile
(config profile). A config profile template instance is created on leaf nodes wherever a network appears.
When using services in the Cisco Prime Network Services Controller (Prime NSC), you must select the
correct config profile to orchestrate and automate the services in the DFA network.
Table 3-3 includes the sample guidelines for edge firewall with regards to selecting config profiles when
you are using services.
Orchestration
Three components provide orchestration functions.
• RabbitMQ
Rabbit MQ is the message broker that provides the Advanced Messaging Queuing Protocol
(AMQP). The RabbitMQ message broker sends events from the vCloud Director/vShield Manager
to the Python script for parsing. You can configure this protocol by using certain CLI commands
from the Secure Shell (SSH) console of the OVA.
The orchestration Python script receives and parses events from VMware’s vCloud Director/vShield
Manager through the RabbitMQ message broker. It communicates with vCloud Director/vShield
Manager through web service APIs for detailed information and then calls Cisco DCNM REST APIs
to populate data that is to be used by the fabric.
The Python integration scripts and the configuration files in the OVA are as follows:
/root/utils/vCDclient.py
/root/utils/vCDclient-ini.conf
You should edit the vCDclient-ini.conf file with your specific information and start the integration
using Python2.7 as python2.7 vCDclient.py
Tip By invoking the script with the Python command, you will invoke the default Python 2.6 version,
which might fail; the integration script requires certain modules that are available only in Python
2.7.
Note You should always configure DHCP through Cisco DCNM web UI by choosing: UI >
Config > POAP > DHCP Scopes. Editing the /etc/dhcp/dhcp.conf file from an SSH
terminal might lead to unexpected behavior.
• Repositories
The TFTP server hosts boot scripts that are used for POAP.
The SCP server downloads the database files, configuration files, and the software images.
Note Before a switch can participate in XMPP, it must be added to the XMPP database by using the appmgr
CLI command shown in Table 3-4. See the“XMPP User and Group Management” section on page 3-9
for information.
Managing Applications
You can manage the applications for Cisco DFA in the Cisco DCNM OVA through commands in an SSH
terminal.
Enter the appmgr command from the SSH terminal by using the following credentials:
• Username: root
• Password: Administrative password provided during OVA deployment.
Note For your reference, context sensitive help is available for the appmgr command. Use the appmgr ?
command to display help.
Use the appmgr tech_support command to produce a dump of the log files. You can then provide this
information to the TAC team for troubleshooting and analysis of your setup.
Note This section does not describe commands for Network Services using Cisco Prime Network Services
Controller. For network services commands, see the “Cisco Prime Network Services Controller Adapter
Manager Command-Line Interface” section on page 3-5.
Note Context-sensitive help is available for the appmgr status command. Use the appmgr status ? command
to display help.
DCNM Status
LDAP Status
AMQP Status
TFTP Status
XMPP Status
DHCP Status
Note A switch that has gone through POAP does not need to be added to the XMPP database using the
appmgr CLI commands.
When POAP definitions are created in DCNM Web UI for a given switch, an XMPP user for that switch
is automatically created in the XMPP database with the switch hostname “XMPP user” and with an
XMPP password specified in the POAP definitions.
When the Cisco DCNM OVA is deployed, an XMPP user named “admin” and a group named “dcnm-dfa”
are created. This can be changed later in the DCNM Web UI by choosing Admin > DFA Settings.
Table 3-4 CLI Commands for XMPP user and group management
Note If you configure a remote Oracle database for both DCNM and XMPP in an appliance (OVA/ISO), create
two separate database users—one for the DCNM and the other for XMPP.
added key-alias=<<key-alias-name>>
<Connector port="8443"
protocol="HTTP/1.1" SSLEnabled="true"
maxThreads="100" strategy="ms" maxHttpHeaderSize="8192"
emptySessionPath="true"
server="Apache"
scheme="https" secure="true" clientAuth="false" sslProtocol = "TLS"
keystoreFile="${jboss.server.home.dir}/conf/fmserver.jks" keystorePass="fmserver_1_2_3"
allowTrace="false" key-alias="<<key-alias-name>>"/>
Note You must import the certificates in the order: intermediate, root and server certificates.
Step 4 If it is required to use the CA signed certificates for both Fabric server and the LAN server, the
certificates must be imported in both the files
/fm/conf/fmserver.jks
and
../dcnm/conf/fmserver.jks)
Step 5 Use the following commands to import the certificates:
/usr/local/cisco/dcm/java/jre1.6/bin/keytool -importcert -alias inter -file inter.pem
-keystore ""/usr/local/cisco/dcm/jboss-4.2.2.GA/server/dcnm/conf/fmserver.jks" -storepass
fmserver_1_2_3
Note For your reference, context sensitive help is available for the appmgr backup command. Use
the appmgr backup ? command to display help.
Note Configuration archive directories are not part of this backup. The command backs up only the
local PostgreSQL database used by Cisco DCNM.
Command Description
appmgr backup all Backs up data for all applications.
appmgr backup dcnm Backs up data for DCNM.
appmgr backup ldap Backs up data for LDAP.
appmgr backup xmpp Backs up data for both the XMPP/XCP
configuration files and the local XMPP/XCP
database.
appmgr backup amqp Backs up data for AMQP.
appmgr backup repo Backs up data for the repository contents (under
/var/lib/dcnm).
The appmgr backup repo command excludes the
backup of image files (all files ending in the .bin
extension under /var/lib/dcnm) to prevent the
backup file from becoming too large.
appmgr back dhcp Backs up data for the DHCP server.
Note Before upgrading or restoring backed-up data onto another OVA setup, the files under folder
/usr/local/cisco/dcm/fm/pm/db needs to be backed-up since these files locally saved in the DCNM
server instead of database.
Restoring Applications
Restoring an application clears all the existing data from that application. Before you restore an
application, you should shut down the application.
Because all data will be cleared, you should perform a backup of the application that you are going to
restore.
Use the following procedure to back up application data and restore the application on a new OVA.
Note A backup and restore procedure is supported only on either the same OVA or a new OVA deployed with
an identical network configuration as the backed-up OVA.
Step 1 Stop all the DCNM services, by using the appmgr stop all command.
Step 2 Use the appmgr backup command on the existing OVA.
You must take the backup of the NX-OS images in the devices separately.
Step 3 Transfer the backup file to any repository.
Step 4 Power off the first OVA.
Step 5 Deploy another OVA with the same network configuration as the existing one, using the same
IP/Netmask/Gateway/Hostname/DNS.
Step 6 Transfer the backup file to the second OVA.
The NX-OS images backup file must be restored to the /var/lib/dcnm folder.
Step 7 Run the appmgr restore with the new backup on the new OVA.
Note See Table 3-6 for a list of CLI commands to restore applications.
Command Description
appmgr restore all file Restores all applications.
appmgr restore dcnm file Restores DCNM.
appmgr restore ldap file Restore LDAP.
appmgr restore amqp file Restores AMQP.
appmgr restore repo file Restores the repository contents
appmgr restore dhcp file Restores the DHCP server.
appmgr restore xmpp file Restores the XMPP server.
Note Before restoring backed-up data onto another OVA setup, the files under folder
/usr/local/cisco/dcm/fm/pm/db needs to be restored back in the same location.
This chapter describes how to configure a high-availability (HA) environment in your Cisco DCNM
OVA deployment for your Cisco Dynamic Fabric Automation (DFA) solution. It also includes details
about the HA functionality for each of the applications bundled within the Cisco DCNM OVA.
This chapter includes the following sections:
• Information About Application Level HA in the Cisco DCNM OVA, page 4-1
• Prerequisites for Cisco DCNM OVA HA, page 4-2
• Application High Availability Details, page 4-4
• Configuring DCNM OVA HA, page 4-10
Note For instruction about installing these applications with the Cisco DCNM OVA, see the“Installing the
Cisco DCNM OVA” section on page 2-2.
Note This document refers to these appliances as OVA-A and OVA-B, respectively.
In this scenario:
1. All applications run on both appliances.
The application data is either constantly synchronized or applications share a common database
as applicable.
2. Only one of the applications running on the two appliances serves the client requests. Initially
this would be the applications running on OVA-A. The application continues to do so until one
of the following happens:
3. At this point, the application running on the other appliance (OVA-B) takes over.
For DCNM REST API and AMQP, this transition is done by a load-balancing software that
hides the interface address of the appliances using a Virtual IP (VIP) address.
For LDAP, both nodes are configured as duplicates of each other. The LDAP clients (switches)
are configured with primary and secondary LDAP IPs, so if the active LDAP fails they try
contacting the LDAP running on the standby.
For DHCP, when the first node fails, the second node starts serving the IP addresses.
4. The existing connections to OVA-A are dropped and the new connections are routed to OVA-B.
This scenario demonstrates why one of the nodes (OVA-A) is initially referred to as the Active
node and OVA-B is referred as the Standby node.
Automatic Failover
The application-level and virtual machine (VM)-level and switchover process is as follows.
• If any of the applications managed by the load-balancing software (DCNM/AMQP) goes down on
OVA-A, the Active node that handles the client requests detects the failure and redirects subsequent
requests to the Standby node (OVA-B). This process provides an application-level switchover.
• If the Active node (OVA-A) fails or is powered-off for some reason, the Standby node (OVA-B)
detects the failure and enables the VIP address for Cisco DCNM/AMQP on OVA-B. It also sends a
gratuitous ARP to the local switch to indicate the new MAC address that is associated with the IP
address. For applications not using VIP, the DHCPD runninG on OVA-B detects the failure of
DHCPD on OVA-A and activates itself; whereas LDAP running on OVA-B continues running as
LDAP is deployed Active-Active. Consequently, a VM-level failover is accomplished for all four
applications (DCNM/AMQP/DHCP/LDAP).
Note When the OVA is started up for the first time, please wait for all the applications to run before you shut
down any of the applications or power off the virtual appliance.
Note For instructions on deploying the Cisco DCNM OVA, see Chapter 2, “Installing Cisco DCNM OVA
Management Software”.
Note The server has to be in the enhanced fabric management network because the switches will use this
server to download images and configurations.
Make sure that the exported directory is writable from both peers. The procedure to export a directory
/var/lib/sharedarchive on a CentOS server is listed in the following paragraph. The steps will vary based
on your environment.
Note You might need root privileges to execute these commands. If you are a nonroot user, please use them
with ‘sudo’.
The same folder /var/lib/sharedarchive can also be accessed through SCP with SCP credentials.
The /var/lib/sharedarchive * (rw,sync) command provides read-write permissions to all servers on
/var/lib/sharedarchive. Refer to CentOS documentation for information on restricting write permissions
to specific peers.
Note Although DCNM OVA in HA sets up a VIP, the VIP is intended to be used for the access of DCNM,
REST API. For GUI access, we still recommend that you use the individual IP addresses of the DCNM
HA peers and use the same to launch LAN/SAN Java clients, etc.
See the following table for a complete list of DFA applications and their corresponding HA mechanisms.
Network Management
The data center network management function is provided by the Cisco Prime Data Center Network
Manager (DCNM) server. Cisco DCNM provides the setup, visualization, management, and monitoring
of the data center infrastructure. Cisco DCNM can be accessed from your browser at http://[host/ip].
HA Implementation
Cisco DCNMs that run on both OVAs are configured in clustering and federated modes for HA.
• Cisco DCNM clustering is an HA mechanism for LAN devices. Internally it uses JBoss clustering.
The first OVA that is HA-enabled becomes the master and takes care of all updates to the database.
• Cisco DCNM federation is the HA mechanism for SAN devices. Groups of SAN devices can be
managed by each node in the DCNM federated setup. All the devices can be managed using a single
client interface.
You can enable automatic failover in the Cisco DCNM UI by choosing: Admin > Federation. If you
enable an automatic failover and the Cisco DCNM that is running on OVA-A fails, the automatic failover
moves only the fabrics and shallow-discovered LANs that are managed by OVA-A to OVA-B
automatically.
An OVA HA setup has two VIP addresses (one for each network) for the Cisco DCNM at the default
HTTP port. These VIPs can be used for accessing the DCNM RESTful services on the OVA management
network and the enhanced fabric management network. For example, external systems such as Cisco
UCS Director can point to the VIP in the OVA management network and the request gets directed to the
active Cisco DCNM. Similarly, the switches in an enhanced fabric management network access the VIP
address on the enhanced fabric management network during the POAP process.
You can still directly connect to Cisco DCNM real IP addresses and use them as you would in a DCNM
in a cluster/federated set up.
Note We recommend that you use a VIP addresses only for accessing DCNM RESTful API. To access the
Cisco DCNM Web UI/DCNM SAN/LAN thick client, connect to the server’s real IP address.
Licenses
For Cisco DCNM, we recommend that you have licenses on the first instance and a spare matching
license on the second instance.
Application Failovers
Enable an automatic failover option in the Cisco DCNM UI when an OVA HA pair is set up by choosing:
Admin > Federation. This process ensures that if the DCNM that is running on OVA-A fails, all the
fabrics and shallow-discovered LANs managed by DCNM-A are managed by DCNM-B automatically
after a given time interval (usually about 5 minutes after the failure of DCNM on OVA-A).
The Cisco DCNM VIP address still resides on OVA-A. The Representational State Transfer Web
Services (REST) calls initially hit the VIP addresses on OVA-A and get redirected to the Cisco DCNM
that is running on OVA-B.
Application Failbacks
When the Cisco DCNM on OVA-A comes up, the VIP address automatically redirects the REST requests
to DCNM-A.
Virtual-IP Failovers
The VIP address that is configured for Cisco DCNM REST API on OVA-A can fail due to two reasons:
• The load-balancing software running on OVA-A fails.
• OVA-A fails.
In both cases, the VIP address of Cisco DCNM automatically migrates to OVA-B. The only difference
is which DCNM will be used after the failover.
– If a load-balancing software failure occurs, the VIP address on OVA-B directs the requests to
DCNM-A.
– If an OVA-A failure occurs, the VIP address on OVA-B directs the requests to DCNM-B.
The automatic failover ensures that the ownership of all of the fabrics and shallow-discovered LANs
managed by DCNM-A automatically change to DCNM-B.
Virtual-IP Failbacks
When OVA-A is brought up and Cisco DCNM is running, the VIP addresses keep running on the Standby
node. The failback of Virtual IP addresses from OVA-B to OVA-A occurs only in the following sequence.
1. OVA-A comes up.
2. Cisco DCNM runs on OVA-A.
3. OVA-B goes down or the load-balancing software fails on OVA-B.
RabbitMQ
RabbitMQ is the message broker that provides the Advanced Messaging Queuing Protocol (AMQP).
HA Implementation
Enabling the HA on the OVA creates a VIP address in the OVA management network. Orchestration
systems such as vCloud Director, set their AMQP broker to the VIP address.
Enabling the HA on the OVA also configures the RabbitMQ broker that runs on each node to be a
duplicate of the broker that is running on the other node. Both OVAs act as “disk nodes” of a RabbitMQ
cluster, which means that all the persistent messages stored in durable queues are replicated. The
RabbitMQ policy ensures that all the queues are automatically replicated to all the nodes.
Application Failovers
If RabbitMQ-A fails, the VIP address on OVA-A redirects the subsequent AMQP requests to
RabbitMQ-B.
Application Failbacks
When RabbitMQ-A comes up, the VIP address automatically starts directing the AMQP requests to
RabbitMQ-A.
Virtual-IP Failovers
The VIP address configured for the AMQP broker on OVA-A can fail due to two reasons:
• The load-balancing software running on OVA-A fails.
• OVA-A fails.
In both cases, the VIP address of the AMQP automatically migrates to OVA-B. The only difference is
which AMQP broker will be used after the failover.
– In a load-balancing software failure, the VIP address on OVA-B directs the requests to
RabbitMQ-A.
– In an OVA-A failure, the VIP address on OVA-B directs the requests to RabbitMQ-B.
“Virtual-IP” Failbacks
When OVA-A is brought up and AMQP-A is running, the VIP addresses keep running on the OVA-B
(directing the requests to AMQP-A). The failback of the RabbitMQ VIP from OVA-B to OVA-A occurs
only in the following sequence.
1. OVA-A comes up.
2. RabbitMQ runs on OVA-A.
3. OVA-B goes down or the load-balancing software fails on OVA-B.
Both LDAP IP address show up in the Cisco DCNM Web UI (Admin->DFA Settings) in the following
order: LDAP-A, LDAP-B.
Cisco DCNM always attempts to write on LDAP-A as follows.
• If the write operation succeeds, the data gets replicated to LDAP-B.
• If the write operation fails, then Cisco DCNM writes to LDAP-B.
The data on LDAP-B eventually gets replicated to LDAP-A when it becomes available.
When you configure the asset databases, every switch is configured with multiple LDAP servers, as
shown in the following example.
The first active LDAP server that is configured in the switch becomes the Active LDAP server. The
Active LDAP server is queried first for autoconfigurations.
For every read operation that the switch needs to perform, the Active LDAP server is contacted first,
followed by the rest of the LDAP servers.
Leaf-0 # fabric database type network
Leaf-0 (config-fabric-db)# server protocol ldap host <LDAP-1-IP> vrf management
Leaf-0 (config-fabric-db)# db-table ou=networks,dc=cisco,dc=com key-type 1
Leaf-0 (config-fabric-db)# server protocol ldap host <LDAP-2-IP> vrf management
Leaf-0 (config-fabric-db)# db-table ou=networks,dc=cisco,dc=com key-type 1
Use the show fabric database statistics command to find the Active LDAP server, which is marked by
an asterisk (*) in the output.
Leaf-0 # show fabric database statistics
In the previous example, during autoconfiguration, a leaf switch first queries 10.77.247.148, which is
the active network database (indicated by “*n”). If that is not available, it automatically contacts the
second LDAP server configured as an network database (10.77.247.147 in this example).
Cisco DCNM allows only two external LDAP servers that are assumed to be synchronized with each
other.
The switch and LDAP interaction that use the remote LDAP server is the same interaction as when you
are using the OVA-packaged LDAP. The Active LDAP server is contacted first; if it is not reachable, the
switch then attempts to read from the next available LDAP server.
DCHP HA
DHCP on both OVAs listen on the interface of the enhanced fabric management network. The native
Internet Systems Consortium (ISC) DHCPD failover mechanism is be used for HA. The lease
information is automatically synchronized using native code.
DHCP POAP
The switches do a DHCP broadcast and get response from the Active DHCP server.
DHCP Autoconfiguration
When a tenant host or virtual machine (VM) comes up, it sends a broadcast that is relayed by the leaf
node. In such a scenario, the VM profiles should be configured with both relay addresses of OVA-A and
OVA-B.
interface vlan $vlanid
. . .
ip dhcp relay 1.2.3.4 vrf ..# eth1 IP of OVA-A
ip dhcp relay 1.2.3.5 vrf ..# eth1 IP of OVA-B
Note You must update the IP range for the default scope before creating the new scope, otherwise DHCP will
be unable to star. See the “Starting DHCP in an HA Setup” section on page 4-14 for information on
updating the IP range for the DHCP scope through the Cisco DCNM UI.
Repositories
All repositories must be remote.
XMPP
Extensible Messaging and Presence Protocol (XMPP) HA is currently not available. The OVA HA
configuration does not affect the XMPP servers that are running on either of the nodes in any way.
*********************************************************
Do you want to continue? [y/n] [y]
Step 2 Make sure that each prerequisite is in place and press y; if not all of the pre-requisites are in place, press
n to exit.
A prompt for the root password appears.
. . .
Enter the root password of this DCNM : <root-password-of-active-peer>
Enter it again for verification: <root-password-of-active-peer>
. . .
Step 5 Enter the VIP addresses for both the management access (eth0) and enhanced fabric management
networks (eth1).
Make sure that the VIP addresses are currently not used by any other interfaces in their respective
networks.
Setting the Virtual IP addresses
=============================
The Virtual IP in the eth0 network.
It serves as a single point of access for the following applications: DCNM REST API, AMQP
Enter the VIP : <a free IP from eth0 subnet>
Step 6 Enter the database URL to set the database. The script uses a JDBC thin driver, so you should enter the
URL in the same format.
a. Enter the database password.
b. Enter the database password again for verification.
The script tries to do a sample query from the database to check the details entered. The Cisco
DCNM schema and related data are loaded after you confirm that all the data are valid.
Setting the Database for DCNM
=============================
Enter the DB URL {ex. jdbc:oracle:thin:@10.2.3.4:1521:XE} :
jdbc:oracle:thin:@x.x.x.x:1521:XE
Enter the DB username : <dbuser>
Enter the DB password :
Enter it again for verification:
note: A repository server in the DFA network that has both NFS and SSH/SCP capability.
=======================
Enter the SCP/NFS repository IP : <repository IP>
NFS Exported location {ex. /var/shared/dcnm/} : /var/lib/dcnmuser
Performing a test mount to ensure that the server is reachable..
Performing a test-write to ensure the exported directory is writable
test-write successful. Proceeding..
Enter the SCP username for <repository IP> : <repository user>
Enter the SCP password :
Enter it again for verification:
Performing a test-write to ensure the directory is writable through SCP..
root@<repository-ip>'s password:
test-write successful. Proceeding..
Enter an NTP server for time synchronization : 10.56.14.161
Step 8 A summary of the details entered will be displayed. If you want to reenter the details, press n.
Once the HA setup is complete, you can check the role of the ha as follows:
OVA-A # appmgr show ha-role
Active
The standby OVA generates a pair of authentication keys and transfers it to the peer’s authorized keys.
a. Enter the root password of the Active peer when prompted.
All the other network information entered during active the OVA setup is automatically picked up
by the Standby peer and displayed for confirmation.
b. Carefully check if it is the correct peer and press y to continue.
Retrieving information from details entered on Active...
Generating ssh keys..
Enter the root password of the peer
Warning: Permanently added '10.77.247.147' (RSA) to the list of known hosts.
Peer Details :
=============
Hostname : somehost.cisco.com
Eth0 IP : 10.77.247.147
Eth1 IP : 192.168.57.147
****************************************
Summary of details entered
****************************************
Virtual IP
=========================
Virtual IP in eth0 n/w : 10.77.247.143
Virtual IP in eth1 n/w : 192.168.57.143
Archives/Repositories
=========================
SCP/NFS repository IP : 10.77.247.11
NFS Exported location : /var/lib/dcnmuser
SCP username : root
NTP server : 10.56.14.161
***************************************
Do you want to continue? [y/n] [y]
Once confirmed, OVA-B is configured to be a Standby peer, and the following message is displayed.
…
******************************************************************************
This node has been configured as standby
Please run 'appmgr start all' first on the active peer (10.77.247.147), and then on the
standby peer(10.77.247.148) to start using applications.
** note ** : dhcpd will not be up until the default poap scopes are updated with free IP
addresses from DCNM GUI
******************************************************************************
Note For information about updating default POAP scopes and starting DHCP using HA, please see,
Starting DHCP in an HA Setup, page 4-14
Step 3 Check the HA role of the node by entering the appmgr show ha-role command.
OVA-A # appmgr show ha-role
Standby
Note To start DHCP using HA, see the “Starting DHCP in an HA Setup” section on page 4-14.
Note For starting DHCP using HA, please see, Starting DHCP in an HA Setup, page 4-14
Note You must update the IP range for the default scope before creating the new scope, otherwise DHCP will
be unable to start.