Home > Geek ONTAP, General > Snap Creator Deep Dive

Snap Creator Deep Dive

December 30th, 2013

NetApp Snap Creator Framework is data protection software that integrates NetApp features with third-party applications, databases, hypervisors, and operating systems.

Snap Creator was originally developed in October 2007 by NetApp Professional Services and Rapid Response Engineering to reduce (or even eliminate) scripting. Nowadays, Snap Creator is a fully supported software distribution available from the NetApp Support Site.

The Snap Creator Team provides two versions of Snap Creator: a community version and an official NetApp release. The community version includes the latest plug-ins, enhancements, and features but is not supported by NetApp Support. The NetApp Version is fully tested and supported, but does not include the latest plug-ins, features, and enhancements.

Let’s explore the architecture of the recently released Snap Creator 4.1 Community Release in November 2013.

Snap Creator Server Architecture
The Snap Creator Server is normally installed on a centralized server. It includes a Workflow Engine, which is a multi-threaded, XML-driven component that executes all Snap Creator commands.

Both the Snap Creator GUI and CLI, as well as third-party solutions (such as PowerShell Cmdlets), leverage the Snap Creator API. For example, NetApp Workflow Automation can leverage PowerShell Cmdlets to communicate to Snap Creator.

To store its configurations, Snap Creator includes configuration files and profiles in its Repository; this includes global configs and profile-level global configs. If you’re familiar with previous versions of Snap Creator Server, one of the new components is the Extended Repository. This extension provides a database location for every job, imported information about jobs, and even plug-in metadata.

For persistence, the Snap Creator Database stores details on Snap Creator schedules and jobs, as well as RBAC users and roles.

The Storage Interface is the server-side component that handles communication via Data ONTAP APIs to execute storage system operations such as SnapVault, SnapMirror, etc. Snap Creator also includes the Unified Manager Interface that communicates to NetApp OnCommand Unified Manager; it actually uses Unified Manager APIs (instead of ONTAP APIs).

Finally, the Snap Creator Server includes an Agent Interface that communicates with the Agent (which is generally installed on hosts external to the Snap Creator Server). Let’s move on to the Snap Creator Agent.

Snap Creator Agent Architecture
The Snap Creator Agent 4.1 was recently rewritten completely in Java to be multi-threaded on all operating systems. As part of this rewrite, encryption was enabled throughout the software. This means that previous releases (up to and including version 4.0) will communicate only over HTTP; whereas with version 4.1, communication occurs only over (encrypted) HTTPS.

First, the Agent Interface (on the Server) talks with the Agent’s RESTful Interface. The primary component of the Agent is the Operation/Execution Manager. It is responsible for handling any incoming, outgoing, and/or completed requests while the Execution Manager actually completes those requests.

To execute multiple tasks, each Snap Creator Agent includes a Thread Pool; it consists of worker threads, which determine the number of given operations.

But what happens if an operation has exceeded a timeout value after a specified time? This is when the Agent’s Watchdog can be triggered by the Execution Manager. It is oftentimes invoked during quiesce operations.

Moving on, there’s a Context Store which holds information that is needed over the lifetime of the workflow.

The Snap Creator Agent also includes a Plug-in Factory that instantiates the plug-ins and communicates directly to the Context Store.

For Java Plug-ins, it’s also important to note that it can directly talk back to the Context Store on the Agent, as well as to the Snap Creator Server — via token-based storage access. This means that they can execute storage operations without communicating back to the Snap Creator Server. While this is a feature that hasn’t been leveraged to date, it is nevertheless available moving forward.

But what happens if the Plug-in Factory instantiates a non-Java plug-in?

In this scenario, it executes the code of the existing Plug-in Integration Engine, which can run the version 4.0 or 3.6 plug-ins as well as supporting custom plug-ins written in Perl, Unix shell scripting, PowerShell, etc.

To recap, we’ve discussed both the server and agent architecture of Snap Creator 4.1. To learn more about developing plug-ins, visit SnapCreator.com.

Geek ONTAP, General

Comments are closed.

This site is not affiliated or sponsored in anyway by NetApp or any other company mentioned within.
%d bloggers like this: