How to manage Amazon FSx for NetApp ONTAP with Ansible

In the rapidly evolving digital era, effective data management and accessibility pose significant challenges for businesses. To foster seamless collaboration among global teams working on a project, there is a need for a shared file storage solution that accommodates various protocols, offers robust data management capabilities, and makes sure of reliable data integrity. When deploying infrastructure multiple times or across diverse environments, maintaining consistent reproducibility is crucial in mitigating the potential for configuration errors.

Amazon FSx for NetApp ONTAP is ideal for those looking for a fully managed solution for multi-protocol access, as it allows you to focus on core business activities instead of managing complex infrastructure. You can configure disaster recovery (DR) between two FSx for ONTAP file systems by peering them and replicating. An effective way of managing infrastructure consistently and without errors is to use a configuration management tool such as Ansible.

In this post, we discuss FSx for ONTAP and Ansible. We cover how to setup FSx for ONTAP cluster peering and Storage Virtual Machine (SVM) peering using Ansible and NetApp modules. Ansible playbooks are idempotent, meaning you can run them multiple times without changing the desired state of your infrastructure. This helps maintain the desired configuration and prevents accidental changes. Ansible has close to 100 modules supporting AWS capabilities. Ansible also has over 1,300+ additional modules to help you manage Linux, Windows, UNIX, network infrastructure, and applications, regardless of where they’re deployed. You can incorporate the code in this post in an existing playbook to create, update, and delete an entire stack as a single unit.

Orchestration tools – Ansible

Ansible is an IT automation engine that automates provisioning, configuration management, application deployment, intra-service orchestration, and many other IT needs. When using Ansible with AWS, there are dozens of modules you can choose from. These modules include functionality for Amazon Virtual Private Cloud (Amazon VPC), and Amazon Elastic Compute Cloud (Amazon EC2). We can also use modules from partners such as NetApp. In this post, we cover how to setup FSx for ONTAP cluster peering and SVM peering using Ansible and NetApp modules.

It is recommended to use Ansible if you are just looking for a configuration management tool, refer to the blog Deploying Amazon FSx for NetApp ONTAP using AWS CloudFormation. If you need more flexibility and want to perform operations not supported by AWS CloudFormation, or want to developer friendly automation, refer to the blog How to use NetApp ONTAP REST APIs with Amazon FSx for NetApp ONTAP.

There are wide variety of tools in the Infrastructure-as-Code (IaC), configuration management, and automation market. CloudFormation and HashiCorp Terraform are provisioning tools. Ansible is a configuration management tool. The tool you should use depends on the challenges you need to solve and your posture in terms of automation. For performing Day-0 activities such as provisioning it is recommended to use either CloudFormation or HashiCorp Terraform. If the user is totally in AWS, then we recommend using CloudFormation because of its integration with other AWS services. If you have a need to build and manage hybrid or multi-cloud, then we recommend using HashiCorp Terraform. To learn more, see the blog Deploying Amazon FSx for NetApp ONTAP using HashiCorp Terraform.

For performing day-1 activities such as configuring storage, we recommend that you use Ansible. Ansible offers certified modules for managing NetApp. For a complete list of NetApp modules, refer to the collection documentation Netapp.Ontap. If you need more flexibility than what Ansible can provide, then we recommend using the REST API. In some cases, you might have to use a combination of these tools. Combinations that we recommend for managing FSx for ONTAP are provisioning and configuration management (CloudFormation/Terraform + Ansible) or provisioning and Orchestration (CloudFormation/Terraform + REST API). Refer to the additional reading section to get more insight into the tools mentioned.

Overview of components

FSx for ONTAP is a fully managed service that provides highly reliable, scalable, high-performing, and feature-rich file storage built on NetApp’s popular ONTAP file system. FSx for ONTAP provides a seamless solution for multi-protocol access, allowing the organization to focus on their core business activities instead of managing complex infrastructure. FSx for ONTAP file systems are similar to on-premises NetApp clusters. The following list identifies the main components in FSx for ONTAP:

• File system: A file system is the primary Amazon FSx resource, analogous to an on-premises ONTAP cluster
• Storage Virtual Machine (SVM): A SVM is an isolated virtual file server with its own administrative credentials and endpoints for administering and accessing data
• Volumes: ONTAP serves data to clients and hosts from logical containers called volumes

Ansible is an open-source IT automation tool that automates provisioning, configuration management, application deployment, orchestration, and many other manual IT processes. Ansible is an agentless automation platform, meaning there is no need for installing any agents on the Managed Hosts. Ansible is installed on a single host called Control Host, which can manage multiple remote hosts over SSH or WinRM.

The following table provides a list of features supported by Ansible:

Before diving deep into the post, let’s go over some of the terminology:

• Task: A single action or activity that you want to execute. Each action is executed by calling a Module. Multiple tasks can reside in a single Play. Tasks are executed in the order specified (top to bottom)
• Play: A ‘Play’ is a group of one or more tasks. Multiple Plays can reside in a single Ansible Playbook. Plays similar to Tasks are executed in the order specified (top to bottom)
• Playbook: A Playbook is a group of one or more plays. In simplistic terms, this is the state in which you want your target infrastructure. An Ansible Playbook is a YAML file similar to a CloudFormation template
• Modules: Modules (also referred to as “task plugins” or “library plugins”) are discrete units of code that can be used from the command line or in a playbook task. Ansible uses the modules to execute some tasks on managed hosts
• Roles: In Ansible, a role is the primary mechanism for breaking a complex playbook into multiple files. This makes them easier to reuse. Each role is limited to a particular functionality or desired output. A role cannot be run on its own and has to be used within a playbook. Each role is a pre-defined directory tree in itself
• Collection: Collections are a distribution format for Ansible content that can include playbooks, roles, modules, and plugins. You can install and use collections through a distribution server, such as Ansible Galaxy or even a local source directory
• Control Host: A server that has Ansible installed on it and is used for managing remote hosts or nodes
• Managed Hosts: These are the hosts that you want ansible to manage. You can mention these hosts in /etc/ansible/hosts/

How to automate cluster peering and SVM peering using Ansible

In this article, we peer the source cluster to the destination cluster, and then we peer the source SVM with the destination SVM. Cluster and SVM peering defines network connections that enable clusters and SVMs to exchange data securely.

Prerequisites

The following prerequisites are needed to continue.

• Ansible 2.9 or later – 2.12 or later is recommended
• Python 3 – 3.9 or later is recommended
• Both source and destination FSx for ONTAP file systems are deployed in your AWS account
• Have fsxadmin credentials stored in AWS Secrets Manager

Procedure

1. Create a variable file called clusterpeer-vars.yml with all the input parameters for the playbook:

# Title: clusterpeer-vars.yml

# common variables
netapp_username: fsxadmin
# Source FileSystem: SourceFSx
netapp_hostname: <SourceIP>
source_vserver: <SourceSVM>
# Destination FileSystem: DestFSx
dest_netapp_hostname: <DestIP>
dest_peer_vserver: <DestSVM>

2. Create the main playbook file called yml as follows:

# Title: clusterpeer.yml

---
- hosts: localhost
  collections:
    - netapp.ontap
    - amazon.aws
  gather_facts: false
  name: test Playbook to create a cluster peering

  tasks:
    - name: Create cluster peer
      netapp.ontap.na_ontap_cluster_peer:
        state: present
        source_intercluster_lifs: 10.0.1.150,10.0.1.151
        dest_intercluster_lifs: 172.31.93.79,172.31.25.88
        passphrase: “{{ lookup('amazon.aws.aws_secret', 'FSx.passphrase', nested=true ) }}”
        hostname: "{{ netapp_hostname }}"
        username: "{{ netapp_username }}"
        password: “{{ lookup('amazon.aws.aws_secret', 'FSx.password', nested=true ) }}”
        # next 2 lines are for HTTPS and solving API issues
        https: yes
        validate_certs: false
        peer_options:
          hostname: "{{ dest_netapp_hostname }}"
        encryption_protocol_proposed: tls_psk

    - name: Create vserver peer
      netapp.ontap.na_ontap_vserver_peer:
        state: present
        peer_vserver: "{{ dest_peer_vserver }}"
        peer_cluster: FsxId0789a92f16cfb09e3
        local_name_for_peer: destfsx
        local_name_for_source: sourcefsx
        vserver: "{{ source_vserver }}"
        applications: ["snapmirror"]
        hostname: "{{ netapp_hostname }}"
        username: "{{ netapp_username }}"
        password: “{{ lookup('amazon.aws.aws_secret', 'FSx.password', nested=true ) }}”
        # next 2 lines are for HTTPS and solving API issues
        https: yes
        validate_certs: false
        peer_options:
          hostname: "{{ dest_netapp_hostname }}"

In the hosts section of the preceding playbook, we are mentioning that the playbook is run against localhost. The Collections section is listing all the content that is used in this playbook. The Gather_facts parameter defines whether to collect all the information about the ONTAP clusters. In our case, we set it to false. The last line in the host section we are specifying is the name of the entire playbook.

The tasks section of the playbook contains two tasks. The first task is creating the peering relationship between the source cluster and destination cluster. The second task creates the peering relationship between the source SVM and destination SVM. Each task mentions the module it is using. Let’s look at the first task in detail to understand how it works:

3. The module name follows the pattern of <namespace>.<collection>.<module>.

In our case that would lead to the following output:

4. Each module has its own required and optional parameters. Input for these can be provided in the playbook, such as the values for source_intercluster_lifs and The input can also be provided in a variable file or during runtime. The input for passphrase, hostname, and username are provided by the variable file clusterpeer-vars.yml. Sensitive information such as the password can be read from Secrets Manager secrets as shown. The ‘https: true” sets the module to use https instead of its default http. The “validate_certs: false” is necessary if you are using the self-signed certs. Self-signed certificates are no longer allowed to validate. If you want to use http, then it needs to be enabled on your ONTAP cluster as it is disabled by default and is less secure over https.

5. Finally, to run the playbook, use the following command:

::> ansible-playbook clusterpeer.yml -e @clusterpeer-vars.yml

PLAY RECAP *************************************************************************
localhost : ok=0 changed=2 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0

Once the playbook is run, it shows the result with the details if anything is changed or not.

ONTAP collection has more than 90 modules. You can find the entire list of modules in the netapp.ontap collection. If any operation other than what is natively supported is required, then you can make use of na_ontap_rest_cli module. This can run any CLI command using a REST api/private/cli/ endpoint.

Cleaning up

In order to keep charges to minimum, clean up the resources in the following sequence:

• Delete the SVM peer relationship
• Delete the cluster peer relationship
• Delete both destination and source clusters if they are created as part of this post

Conclusion

This post has given a brief overview of Ansible and how to use it with NetApp to peer two Amazon FSx for NetApp ONTAP file systems and their SVMs. Users can automate and orchestrate FSx for ONTAP based on their needs. Automation not only reduces the potential for manual errors but also saves valuable time for IT teams, enabling them to focus on more strategic tasks than managing infrastructure. FSx for ONTAP supports other tools, such as AWS CloudFormation, HashiCorp Terraform, and REST APIs. More information is available in the Additional Reading section of this post.

If you have any comments or questions, don’t hesitate to leave them in the comments section. More information is available in the “Additional reading” section of this post.

Additional reading

Deploying Amazon FSx for NetApp ONTAP using AWS CloudFormation

Deploying Amazon FSx for NetApp ONTAP using HashiCorp Terraform

How to use ONTAP REST APIs with Amazon FSx for NetApp ONTAP

NetApp ONTAP collection

Amazon AWS Collection