By Victor Ifediora

As storage management experts, NetApp IT leans on tools like Red Hat Ansible to help automate the delivery of consistent storage environments, reduce configuration errors, and respond to threshold limits. Two years ago, our team started using ONTAP^® Ansible modules to reduce day 0 build times from a 2-day manual process to a 10-minute automated process.

Today, our use of Ansible has grown to include the following:

– Manage adaptive quality of service (AQoS)

– Enforce Snapshot™ policies

– Manage inode full alerts

– Provision end-to-end storage virtual machines (SVMs)

Ansible’s main goals are simplicity and ease of use. I find that Ansible does not requires special coding skills. It’s very easy to use and decipher. There are many Ansible modules for NetApp^® ONTAP, Element^®, and E-Series systems that are fully supported and documented.

To use Ansible, you need to install the Ansible engine on your control machine.

Manage Adaptive QoS (AQoS) Policies

The Ansible playbook does the following:

– Creates new AQoS policy groups on each SVM

– Disassociates the volumes from the old QoS policy groups and deletes the policy groups

– Assigns AQoS policy groups to volumes, depending on the hosting SVM and aggregate

– Scans the clusters every hour to identify new SVMs and creates all the policies for those SVMs

– Identifies all the new volumes that were created and assigns the AQoS policy to the volumes

Enforce Snapshot Policy

Enforcement of Snapshot policy uses the NetApp Ansible module in these ways:

– Creates a playbook that assigns Snapshot policy based on the type of volume

– Automation determines the type of volume, database, data protection, read only, nondatabase, and VMDK volumes

– If a volume is a database or VMDK or nondatabase, assigns the proper Snapshot policy

– Skips data protection volumes because they always have a Snapshot policy of None (ONTAP does not allow you to modify Snapshot policy for data protection volumes.)

Manage Inodes by Using Ansible, Zenoss, and ServiceNow

The Ansible play book does the following:

– Active IQ^® Unified Manager generates an inode full alert and sends a trap to Zenoss

– Zenoss automatically opens a ServiceNow incident and assigns it to Storage Operations

– Simultaneously, Auto Response kicks in and activates Ansible playbook

– Ansible playbook modifies the inode, then closes the ticket in ServiceNow

– Sends email to the operations team

Provision End-to-End Storage Virtual Machine

Provisioning the SVM uses the NetApp Ansible module in these ways:

– Playbook prompts for the cluster name to create the SVM

– Prompts for the username and password and the name of the SVM to create

– The playbook uses the cluster management subnet because all of the SVM management interface is in the same subnet as the cluster management interface

– The playbook queries the Infoblox for the next available IP in that subnet

Infoblox returns the next available IP and the playbook uses that IP to create a DNS entry for the SVM and also to configure the management interface for the SVM.

Want to know more?

Check out our webinar on how we used Ansible and ONTAP – in concert with CyberArk – to manage passwords and security.

---