IT organizations are looking to balance ever-increasing demands for performance, reduced costs, agility, and speed of deployment. These demands warrant data centers that operate in a cloudlike manner, proactive and predictable storage management, and optimal management of compute and network resources.

 

This blog post brings together the best of both worlds, on the premises and in the cloud, to tackle these challenges and requirements. Puppet is used for automation, and NetApp® Service Level Manager (NSLM) is used to standardize storage management.

 

NSLM provides a framework for NetApp customers who are looking for greater resource utilization and lower operational expenses for their storage service offerings. It allows you to perform storage operations more easily and at scale by using policies based on service-level objectives (SLOs).

 

With Puppet, you can define what your infrastructure looks like by using a common, easy-to-read language. Puppet is open-source software used for configuration management and automation. The NSLM device module allows you to use NSLM for storage management when using Puppet and its network device functionality.

 

This NSLM Puppet module adds one provider for every NSLM object that supports PUT, POST, and DELETE HTTP requests. This module enables Puppet customers to create new manifest files or update existing manifest files to automate storage management operations.

 

By combining these two technologies, you have the visibility and reporting needed to make decisions and prove compliance. This blog post presents examples in which Puppet is used to manage different NSLM objects, including a specific example in which it is used to manage a LUN.

Setup Requirements

  • RHEL 7.2
  • Puppet Enterprise 2017.2.3-el-7
  • Puppet Agent 1.10.5-1.el7
  • NetApp Service Level Manager 1.0 RC3 (minimum version)

Prerequisites

  • Experience with Puppet
  • Working knowledge of the Ruby language
  • A basic understanding of NSLM

Steps to Add NetApp Service Level Manager as a Device to Puppet

  1. Log in to the Puppet master system and go to the /etc/puppetlabs/code/environment/production/module/
  2. Extract the NSLM Puppet module.
  3. Log in to the Puppet agent system and add the device configuration file (conf) at /etc/puppetlabs/puppet/. The format of the device file is as follows:
[<node-name>]

type netapp

url https://<user>:<password>@<api server IP or network host name>:<port>
  1. Run the puppet device command on the Puppet agent to add NSLM as a device:
puppet device --deviceconfig /etc/puppetlabs/puppet/device.conf
  1. Be sure to sign the certificate from the master when running the conffile the first time. This will add the device to Puppet. Any waiting certificates that must be signed are displayed from the master and can be signed using the following commands:
puppet cert list

puppet cert sign
  1. If you have more than one Puppet agent or multiple NSLM servers, repeat steps 2 and 3 for each one.

NSLM Puppet Modules

In the module package download, you will find modules for each of these NSLM functions:

 

  • slo_cifsshare. Use this module to create, modify, and remove CIFS shares. Use slo_cifsshareaclto manage the access control of the CIFS share. Use slo_fileshare to manage the file share itself.
  • slo_cifsshareacl. Use this module to manage access control to a CIFS share. You can add, modify, or remove a user or group to access a control list. Use an slo_cifssharemodule to manage the CIFS shares.
  • slo_exportpolicy. Use this module to manage the export policy, with one or more export rules, which enable client accessibility to the export. Use an slo_nfsshareor slo_cifsshare module to manage the NFS export and CIFS shares, respectively.
  • slo_fileshare. Use this module to manage file shares, for example, creation, modification, and deletion. Use slo_nfsshareor slo_cifsshare, along with slo_fileshare, for creating user files and directories.
  • slo_initiatorgroup. Use this module to manage initiator groups for LUNs. For example, a group of initiators that need access to a LUN would be added to the igroupand mapped. Along with this module, use slo_lun and slo_lunmap to manage access control to the LUN.
  • slo_lun. Use this module to manage LUNs: for example, creating, modifying, and removing a LUN. Along with this module, use slo_initiatorgroupand slo_lunmap to manage the accessibility of the LUN.
  • slo_lunmap. Use this module to map or unmapthe LUN to a specific initiator group.
  • slo_nfsshare. Use this module to manage NFS shares. For example, you can create, modify, or remove an NFS share. Use slo_exportpolicyto manage the client access control. Use slo_fileshare to manage the file share itself.
  • slo_snapshot. Use this module to manage Snapshot™ copies on a volume. Currently, there is no module functionality for cloning or reverting to a Snapshot copy.
  • slo_storageservicelevel. Use this module to manage a storage service level. For system-created storage service levels, only modify is supported.

These modules can be used along with other Puppet modules to build a bigger solution. Refer to the GitHub documentation for more detailed information about these modules.

Creating and Using a LUN with Puppet and NSLM

A LUN can be managed by creating one or more manifest files on the Puppet master in the following directory location: /etc/puppetlabs/code/environment/production/manifests/.

 

Puppet language files are called manifests and are named with the .pp file extension. The description of all the LUNs can be kept in one manifest file, or you can create multiple manifest files using one for each LUN. Another example could be to create a manifest file for each group of LUNs used by teams in your organization, such as finance_luns.pp.

 

The following manifest file creates a LUN using the slo_lun module. It then creates an igroup using an slo_igroup module and finally maps the created LUN and igroup using the slo_lunmap module.

 

node 'nslm-server' {
  slo_lun {
    'lun-management':
      ensure => present,
      name => "finance_lun",
      size => 10737418240,
      storage_service_level_name => "Value",
      storage_vm_name => "Audit_Server",
      storage_vm_storage_system_name => "Finance-Cluster"
}

slo_initiatorgroup {
  'igroup-management':
      ensure => present,
      name => "finance_igroup",
      storage_vm_name => "Audit_Server",
      storage_vm_storage_system_name => "Finance-Cluster",
      initiator_os_type => "default"
}

slo_lunmap {
  'lunmap-management':
    ensure => present,
    initiator_group_storage_vm_name => "Audit_Server",
    initiator_group_storage_vm_storage_system_name => "Finance-Cluster",
    initiator_group_name => "finance_igroup",
    lun_storage_vm_name => "Audit_Server",
    lun_storage_vm_storage_system_name => "Finance-Cluster",
    lun_name => "finance_lun"
}
}

Note: The node name (for example, nslm-server) in the manifest file should be same as the node name in the device configuration file.

 

This video shows the process just described of creating and mapping a LUN using Puppet:

 

Summary

IT departments of large enterprises are under significant pressure to mimic the model of public cloud services. They must also deliver Infrastructure-as-a-Service with the same degree of flexibility and agility provided by public cloud services in an environment of shrinking IT budgets for both equipment and staff.

 

This NSLM Puppet integration solution allows you to use NSLM without needing to grasp advanced storage concepts. With this solution, you can integrate NSLM into your existing Puppet processes, allowing you to manage your storage in an efficient and cost-effective manner.

 

If you have questions, contact us at ng-nslm-queries@netapp.com or using our Slack team in the #configurationmgmt channel.

Hemant Agrawal

Hemant is a member of technical staff at NetApp. He has experience with different devops tools like puppet, ansible, vRO, terraform etc. In his current role, he is engaged as an solution engineer and giving different solutions for NetApp Service Level Manager.

He has passion in finding issues and solution in cloud and big data technologies. Apart from work Hemant has keen to exploring modish things around and travelling new places.

Add comment