Q3 2024 Update for Ansible Integrations with Dell Infrastructure
Fri, 20 Sep 2024 13:13:08 -0000
|Read Time: 0 minutes
In this post I will cover what’s new in the Ansible collections for the Dell ISG portfolio that have become available in Q3 2024. The following are new releases:
- Ansible collection for PowerScale: v3.2 and v3.3
- Ansible collection for PowerMax: v3.1
What’s new in PowerScale Ansible collection v3.2 and v3.3
The main theme of enhancements for PowerScale Ansible collections in v3.2 and 3.3 is alert management. In Dell PowerScale OneFS, the events and alerts system is a key component for monitoring the health and performance of a cluster. It allows administrators to detect, track, and respond to various conditions that might affect cluster operation, such as hardware failures, network issues, and file system changes.
Through the OneFS web administration interface, administrators can view, modify, and resolve event groups, set up alert rules, and configure alert channels. The system also provides options for setting retention and storage limits for event data and suppressing alerts during maintenance windows. This flexibility allows administrators to fine-tune their monitoring and response to suit the cluster’s specific operational context. In the OneFS UI you can access the Events and alerts section from the Cluster management menu:
Key elements of Events and Alert Management
Events: These are individual instances that indicate specific changes or conditions within the cluster, such as system errors, warnings, or operational changes. Each event is tagged with a unique ID to make it easier to track and manage.
Event groups: When multiple related events stem from a single underlying issue, they are grouped into event groups. This provides a consolidated view of related occurrences, allowing administrators to monitor, resolve, or ignore these groups efficiently. By aggregating events, event groups help identify patterns and provide a clearer picture of the cluster’s health. Here is how OneFS UI displays the Event groups:
Alerts: Alerts are notifications that report changes in the state of Event groups. They serve as an early warning system, helping administrators respond promptly to potential problems, such as low disk space, hardware failures, or security issues. Here is the Alert management section in the OneFS UI:
Alert Rules: Alert rules are the criteria used to monitor events and event groups and determine when alerts should be triggered. Administrators can configure alert rules to specify the types of event groups to monitor, the conditions or thresholds that must be met (such as error severity or the time since an event occurred), and the corresponding actions to take. For example, an alert rule can be set up to notify administrators when CPU usage exceeds a certain percentage, or when storage capacity drops below a defined limit. Here is the Alert rule section of the Alert management section in the OneFS UI:
Alert Channels: These define how and where alerts are sent, for example through email, SNMP, or other communication methods. By creating alert channels, administrators can customize the content, format, and frequency of alerts to suit their operational needs. Here is how you can configure Alert channel in the OneFS UI:
Here is a schematic of how these elements work together:
The following are the new Ansible modules to manage the various aspects of Alerts management in PowerScale:
New module: alert_settings
This module helps you manage alert settings on a PowerScale Storage System. Here is a single comprehensive example task that can be modified depending on the CRUD operation you would like to perform with it:
- name: Configure CELOG maintenance mode and settings
dellemc.powerscale.alert_settings:
onefs_host: "{{ onefs_host }}" # PowerScale cluster host or IP address
api_user: "{{ api_user }}" # Username for API authentication
api_password: "{{ api_password }}" # Password for API authentication
verify_ssl: "{{ verify_ssl }}" # Verify SSL certificate (true/false)
enable_celog_maintenance_mode: true # Enable or disable CELOG maintenance mode (true/false)
prune: 0 # Prune CELOG history. Set to 0 to remove all history.
New module: alert_channel
This module helps you manage alert channel on a PowerScale Storage System. Here is a single comprehensive example task that can be modified depending on the CRUD operation you would like to perform with it:
- name: Manage PowerScale Alert Channel - Comprehensive Example
hosts: localhost
gather_facts: false
tasks:
- name: Create or modify an alert channel
dellemc.powerscale.alert_channel:
onefs_host: "{{ onefs_host }}" # PowerScale cluster host or IP address
port_no: "{{ port_no }}" # Port number for the API (default is 8080)
api_user: "{{ api_user }}" # Username for API authentication
api_password: "{{ api_password }}" # Password for API authentication
verify_ssl: "{{ verify_ssl }}" # Verify SSL certificate (true/false)
name: "{{ channel_name }}" # Name of the alert channel
enabled: true # Enable or disable the alert channel (true/false)
type: "smtp" # Type of alert channel ('smtp', 'connectemc', etc.)
allowed_nodes: # List of node numbers to include in the alert channel
- 1
- 2
excluded_nodes: # List of node numbers to exclude from the alert channel
- 3
smtp_parameters: # Parameters specific to SMTP alert channels
address: # List of email addresses to send alerts
- "alert@sample.com"
send_as: "sender@sample.com" # Email address to use as the sender
subject: "Alert Notification" # Subject line for alert emails
smtp_host: "smtp.sample.com" # SMTP server address
smtp_port: 25 # SMTP server port (default is 25)
batch: "ALL" # Email batching option ('ALL', 'NONE', etc.)
batch_period: 120 # Batching period in seconds
smtp_use_auth: false # Use SMTP authentication (true/false)
update_password: "on_create" # Password update behavior ('always', 'on_create')
send_test_alert: false # Flag to send a test alert (true/false)
state: "present" # Desired state of the alert channel ('present' or 'absent')
New module: alert_rule
This module helps you manage alert rules on PowerScale. Here is a single comprehensive example task that can be modified depending on the CRUD operation you wish to perform with it:
- name: Manage PowerScale Alert Rules - Comprehensive Example
hosts: localhost
gather_facts: false
tasks:
- name: Create or update an alert rule
dellemc.powerscale.alert_rule:
onefs_host: "{{ onefs_host }}" # PowerScale cluster host or IP address
api_user: "{{ api_user }}" # Username for API authentication
api_password: "{{ api_password }}" # Password for API authentication
verify_ssl: "{{ verify_ssl }}" # Verify SSL certificate (true/false)
port: "{{ port }}" # Port number for API access (default is 8080)
state: present # Desired state of the alert rule ('present' or 'absent')
name: "test_alert_rule" # Name of the alert rule to create or modify
condition: "NEW" # Condition to trigger the alert (e.g., "NEW")
categories: # List of event categories to include (e.g., 'all', specific categories)
- all
channels: # List of alert channels to use (fetched from `dellemc.powerscale.info`)
- "{{ result_info.alert_channels[0]['channels'][0].name }}"
eventgroup_ids: # List of event group IDs to include in the rule
- "{{ result_info.event_groups[0]['eventgroup_definitions'][0].id }}"
- "{{ result_info.event_groups[0]['eventgroup_definitions'][1].id }}"
exclude_eventgroup_ids: # List of event group IDs to exclude from the rule
- "{{ result_info.event_groups[0]['eventgroup_definitions'][3].id }}"
interval: 10 # Interval in minutes between alert notifications
transient: 5 # Duration (in minutes) for which an event must persist before alerting
limit: 10 # Maximum number of alerts to send within the interval
severities: # List of severities to include in the rule (e.g., 'emergency', 'critical')
- emergency
- critical
New module: writable_snapshots
Writable snapshots in Dell PowerScale OneFS allow the creation of space-efficient, modifiable copies of a source snapshot while keeping the original source snapshot in a read-only state. These writable snapshots are useful for tasks like testing data recovery scenarios or quality assurance. Here is a single comprehensive example task that can be modified depending on the CRUD operation you would like to perform with it:
- name: Manage PowerScale Writable Snapshots - Comprehensive Example
hosts: localhost
gather_facts: false
tasks:
- name: Create, modify, or delete writable snapshots
dellemc.powerscale.writable_snapshots:
onefs_host: "{{ onefs_host }}" # PowerScale cluster host or IP address
verify_ssl: "{{ verify_ssl }}" # Verify SSL certificate (true/false)
api_user: "{{ api_user }}" # Username for API authentication
api_password: "{{ api_password }}" # Password for API authentication
writable_snapshots: # List of writable snapshot operations
- dst_path: "{{ dst_path1 }}" # Destination path for the writable snapshot
src_snap: "{{ src_snap_id }}" # Source snapshot (can be specified by ID or name)
state: "{{ state_present }}" # Desired state ('present' to create, 'absent' to delete)
- dst_path: "{{ dst_path2 }}" # Second snapshot operation with a different destination path
src_snap: "{{ src_snap_name }}" # Source snapshot specified by name
state: "{{ state_present }}" # State set to 'present' to create the snapshot
- dst_path: "{{ dst_path3 }}" # Additional operation for deleting a snapshot
state: "{{ state_absent }}" # State set to 'absent' to delete the snapshot
- dst_path: "{{ dst_path4 }}" # Example for creating and deleting in a single task
src_snap: "{{ src_snap_id }}" # Source snapshot ID for creation
state: "{{ state_present }}" # Create the snapshot
- dst_path: "{{ dst_path5 }}"
state: "{{ state_absent }}" # Delete another snapshot
What’s new in PowerMax Ansible collection v3.1
Restore capability in the snapshots module
Here is how you can run a restore job using a snapshot with the snapshot ID or generation number of the snapshot:
- name: Restore PowerMax Storage Group Snapshot - Comprehensive Example
hosts: localhost
gather_facts: false
tasks:
- name: Restore Storage Group Snapshot using generation or snapshot_id
dellemc.powermax.snapshot:
unispherehost: "{{ unispherehost }}" # Unisphere host for PowerMax
universion: "{{ universion }}" # Unisphere API version
verifycert: "{{ verifycert }}" # Verify SSL certificate (true/false)
user: "{{ user }}" # Username for Unisphere API authentication
password: "{{ password }}" # Password for Unisphere API authentication
serial_no: "{{ serial_no }}" # Serial number of the PowerMax array
sg_name: "{{ sg_name }}" # Name of the storage group
snapshot_name: "{{ snapshot_name }}" # Name of the snapshot to restore
restore: true # Set to true to perform a restore operation
# Specify either 'generation' or 'snapshot_id' to identify the snapshot for restoration
generation: "{{ generation }}" # Generation number of the snapshot (optional)
# snapshot_id: "{{ snapshot_id }}" # Snapshot ID (optional) for restore instead of Generation of the snapshot
state: "{{ state_present }}" # Desired state ('present' to restore the snapshot)
Adding “Unisphere port” as parameter for authentication
Starting from version 3.1, you can change the default port number of 8443 to access PowerMax using the new unisphere_port parameter.
That’s it for Ansible in Q3 2024. Check out what’s new with Terraform providers for Dell infrastructure in this blog post.
Author: Parasar Kodati, Engineering Technologist, Dell ISG