Home > Blogs > VMware vCenter Orchestrator Blog > Tag Archives: SNMP

Tag Archives: SNMP

vCenter Operations integration with vCenter Orchestrator in 5 minutes or less

Ever imagined if you could automatically resolve the operational issues that vCenter Operations has identified using vCenter Orchestrator workflows? That’s what the vCenter Operations remediation workflow package is about.

vCenter Operations performs constant analysis of the datacenter health, and launches alerts when certain problems or risks arise. These alerts can be sent externally via mail, or as SNMP trap messages. On the other hand, through its scripting API and its library of workflows that can be downloaded from VMware Solutions Exchange, vCenter Orchestrator is powerful enough to perform reconfiguration actions at almost any level of vCenter. And guess what? It can receive SNMP traps using its SNMP plug-in. I guess you already get the idea. And here is the picture to visualize it:

You said 5 minutes or less

Really anyone can write his/her own implementation of this scenario, using a vCenter Orchestrator appliance and the SNMP plug-in. However, it can take some time to track down what exactly happens on the SNMP level, parse all the valuable information, code the mapping between trap messages and remediation workflows in a clear and maintainable fashion. That’s why we decided to spare that effort to any user who does not necessarily feel the urge to be a code-hero. So we created a vCO .package with the following goals in mind:

  • Be easy to work with
  • Be easy to configure
  • Do the task, of course, of launching workflows on events from vCenter Operations
  • No programming required

So here we are – ready to share the vCenter Operations remediation workflow package!

Here’re all the things you need to try this out:

Installation/Prerequisites

To quickly run this solution, the following items must be installed:

Installation

Basic vCenter and vCenter Orchestrator configuration skills are required, in order to install the vCenter Orchestrator VA and the SNMP plugin.

  1. Deploy the virtual appliance ovf in your datacenter.
  2. Install the SNMP plugin from the vCenter Orchestrator Configurator interface.
  3. Install the vCenter Operations integration package in vCenter Orchestrator, using the vCenter Orchestrator client.

Setup/Post-installation configuration

(In vCenter Operations)

  • Set the vCenter Operations server to be sending SNMP traps to the vCenter Orchestrator server address.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

(In vCenter Orchestrator)

  • Register vCenter Operations server. Register the vCenter Operations server (vCenter Operations Analysis VM IP address) in the SNMP inventory of vCenter Orchestrator, using the “Library/SNMP/Device Management/Register an SNMP device” workflow (only add the address and optionally a friendly name, leave defaults to the other settings).

 

 

 

 

 

 

 

 

 

 

 

 

  • Apply Policy. Go to the “Policy Templates” tab in the “Administer” menu, select “Library/SNMP/vCenter Operations SNMP Trap” element, and perform “Apply Policy…” operation. As SNMP device parameter, specify the vCenter Operations server that was added in the previous step.

 

 

 

 

 

 

 

 

 

 

 

 

  • Start the policy. Start the newly created policy. If you want this policy to start automatically with server restart, edit it and change the Startup parameter on the General tab.
  • Attach remediation workflows. Go to the “Configuration elements” tab in “Design” menu, and locate the “SNMP/vCOps Configuration” element. In the attributes tab, you can find the mapping between vCenter Operations alerts (in the Name column) and workflows in the “Value” column.

There are two sample remediation workflows included in the package:

  • Default Action – it only prints the trap parameters in the log.
  • Capacity Remediation Action – It is a real remediation action, that takes the trap-specific inputs (like EntityName, EntityType, Criticality, etc.), takes only the ones needed, and forwards them to the real remediation workflow – “Library/vCOps Remediation/Capacity Remediation Action/vCOps Remediation Datastore Capacity”. This is a non-intrusive workflow, that finds the Datastore object, corresponding to the datastoreName parameter, checks for its powered off VMs, analyses their disk usage, and the disk usage of their snapshots, then prepares an email report and sends it to the user. For this workflow to work, you have to add your email in the “toAddress” attribute in the General tab of the workflow. You also have to setup the right smtp server in the settings of the Mail plugin in vCenter Orchestrator Configurator. This workflow has to be assigned to the “riskCapacityNew” alert, so it can be triggered correctly.
  • Filtering. As there may be a lot of Alerts coming from vCenter Operations, we provide the possibility to filter the incoming traffic, and not launch any workflows, unless the filtering criteria are met.

This can most easily be accomplished with the help of the “Library/vCOps Remediation/Configuration/Configure Filters” workflow, although it is also possible to achieve the same directly in the “SNMP/vCOps Filters” configuration element. This workflow could fail validation on prior to vCenter Orchestrator 5.1 systems, and the workaround is to manually open the “SNMP/vCOps Filters” configuration element, and set empty array for each of the five attributes (just click the “Not Set” value and immediately hit the “Accept” button after this).

The examples

Although we are only providing non-intrusive examples, any workflow can be assigned to any alert, moving or deleting VMs based on some criteria, defined by the user. In fact, vCenter Orchestrator provides a library of thousands of out-of-the-box workflows that can integrate various third party management systems.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Implementation details

For the ones eager for technology detail – here is what happens under the cover:

  • A vCenter Orchestrator policy is waiting for trap messages from vCenter Operations.
  • Once a trap is received, the policy translates the trap to a javascript alert object, thus simplifying it quite a lot.
  • Then it checks in a map (associative array, actually) if there is an alert definition for the incoming SNMP OID.

For example:  “1.3.6.1.4.1.6876.0.31” -> “riskCapacityNew”

  • It checks if there are filter conditions defined, and if the trap matches them, if defined.
  • The policy finds if there is workflow assigned to this alert, in the “vCOps Configuration” configuration element.
  • Launches the workflow if such a workflow has been defined.

How are the project goals achieved

  • All the complications, technical details and scripting resides in the policy.
  • Great flexibility can be achieved by setting of correct configuration and filters.
  • All configuration is moved to configuration elements.
  • There is a workflow for even easier configuration of the filtering.

Congratulations! Your system is now installed and configured.

No programming involved.

 

 

 

 

 

 

 

 

 

 

Summary

vCenter Operations is fully integrated with vCenter Orchestrator so you can leverage more of what you already have. Automated workflow triggers let you associate workflows created in vCenter Orchestrator with vCenter Operations alerts. For example, these workflows can be used to automatically delete old VM snapshots when available capacity falls below a critical threshold or to add resources when workload demands are rising above normal. You’re always in control and can customize workflows with simple drag and drop operations. With vCenter Operations you can finally pull the trigger on automation.

SNMP plug-in – integration with vCenter Server

In this post we will show how you can use the SNMP plug-in to receive various vCenter Server alarms in vCO and include these events as part of more complex orchestration logic.

vCenter Server configuration

First, you must register the vCO server in the list of SNMP trap receivers in vCenter Server. This list is accessible in the vSphere client, in vCenter Server Settings, which is accessible from the Administration menu.

Snmp-vc-01-ServerSettings

You can have up to four different receivers, one of which must link to the address of your vCO server and the port defined in the Trap Host node in the SNMP inventory in vCO.

Configure Alarms

After you have registered the vCO server, vCenter Server can send SNMP traps to it. Some traps will start to be sent immediately. Many alarms in vCenter Server are configured to send traps by default.

Some default alarms are defined on the root of the vCenter Server inventory (1), from where they propagate to all child objects. If you go to the Alarm management tab (2), you can check the definitions (3) of the default alarms. Selecting a specific alarm (4), you can check on its Actions tab (5) if sending SNMP traps is active for this specific alarm (6).

Snmp-vc-02-DefaultTraps

These settings can be changed on the object where the alarm is defined. If the fields are not editable, then this is an inherited alarm, and you need to find the parent object that defines the alarm to change the settings.

Create custom alarms

Sometimes you may need to monitor something specific that is not part of the default alarms, or you only want to monitor it for a certain host, virtual machine or other object. Then you need to add a custom alarm to the object (a datastore in this example).

Snmp-vc-03-AddAlarm

Then, you need to add some triggers which define under what conditions this alarm should be triggered.

Snmp-vc-04-AddTrigger

Finally, you need to add an action that will send a trap. Note that you may need to add handlers to state changes. For example, the green to yellow state change does not send a trap, as by default only the yellow to red state change is defined to send a trap.

Snmp-vc-05-AddAction

After this, the vCenter Server instance is ready and is sending traps to vCO.

Configure vCO to receive traps

On the receiving end, you first need to add the vCenter Server instance to your inventory with the “Register an SNMP device” workflow.

Snmp-vc-06-AddDevice

Then you can either apply a policy, which will be receiving all kinds of traps and running scripts on each of them, or start a workflow, which will be waiting for a specific trap.

The policy is applied from the Policy Template “SNMP Trap”, and takes as a parameter the SNMP device that you just registered.

Snmp-vc-07-policy

This exact policy is only printing the trap data to the system log, but it could do other tasks, such as, call actions or workflows that should handle the received traps.

You must start the policy after it is created, or set it to auto-start if you need it to work after server restart.

You can leave this policy to be listening for traps for the moment, and check the other possibility to receive traps – the “Wait for a trap on an SNMP device” workflow.

Snmp-vc-08-waitTrap

After you enter the device and OID parameters and run the workflow it reaches a trigger where it suspends and starts waiting. It can be resumed only by the specified SNMP trap.

Snmp-vc-09-trapWaiting

If the OID field from the workflow presentation was left empty, then the workflow will be resumed by any trap, just like the the policy. Any trap filtering on the policy must be done programatically, after the trap is received. Listening to all incoming traps can help you easily get the correct OID that will be sent from vCenter Server for a specific alarm. These OIDs are also listed in the MIBs that are described in vSphere Datacenter Administration Guide, in the “Monitoring Your Virtual Infrastructure” section, chapter “SNMP and vSphere”.

If everything is configured correctly, vCO should start receiving SNMP traps and trap data will be logged from the policy, like in this example, which is monitoring datastore space usage.

Snmp-vc-10-trapReceived

The SNMP plug-in is not limited only to use with vCenter Server. It can be used with any SNMP-enabled system or device. This is just one scenario that shows how the SNMP plug-in, together with the workflow library from the vCenter Server plug-in, can be used as the basis for the automation of various datacenter administration tasks.

It’s (Almost) All About Plug-ins (in 2011)…

If you missed VMworld Las Vegas, are reading this blog for the first time, or are just new to vCenter Orchestrator, then maybe you haven't heard the news… 

This year, it's all about plug-ins.

That's why we are very glad to announce two new vCO plug-in releases:

  • VMware vCenter Orchestrator Plug-in for vCenter Server 5.0
  • VMware vCenter Orchestrator SNMP Plug-in

As promised in a previous post, the vCenter Server 5.0 plug-in adds over 50 out-of-the-box workflows to extend capabilities around networking and storage operations, and to incorporate new features like Storage DRS into fully-automated, end-to-end cloud provisioning scenarios.  As previous versions, the plug-in provides 100% coverage of the 5.0 vSphere API.  With this new plug-in, organizations can now automate a broader number of use cases, such as dynamic scaling-up and scaling-down of vSphere resources, while taking full advantage of the new vCenter Server 5.0 capabilities.

And to complement this new release, we are also glad to announce a sparkling new SNMP plug-in that enables organizations to automatically trigger workflows based on SNMP messages.  SNMP (Simple Network Management Protocol) is one of the most widely used protocols to manage network devices and systems in IP networks and the default alerting mechanism for vCenter Server and ESX/ESXi. 

With the SNMP plug-in, you'll be able to define policies that automatically trigger specific workflows when SNMP traps are received by vCO. For instance, an administrator could configure a workflow that, upon detecting that a vCenter datacenter is nearing full capacity, would reclaim unused resources or provision additional compute and storage resources.  Of course, the SNMP plug-in is able to process events beyond vCenter Server, so the triggers for workflows can come from virtually any device or system that supports SNMP.

Finally, be sure to check our plug-in documentation site often to get information on update releases.  This week, new updates are available for the Cisco UCS Manager, Microsoft Active Directory and VMware vCloud Director plug-ins. 

For additional information, please see the following sites:

PS.  We'd like to take all of the credit, but we're far from the only ones building plug-ins.  In addition to Infoblox's recent announcement, we're glad to highlight Radware and Uptime Software, who have already released vCO plug-ins. Be sure to give them a try!