Why to use Ansible Playbooks instead of manual configuration: -

·      Consistency and Accuracy: Manual operations are prone to human errors such as typos or configuration mismatches, especially when repeated across multiple nodes. Ansible playbooks ensure that every task is executed the same way every time, reducing the risk of mistakes.

·      Idempotency: The greatest advantage of using Ansible Playbook is that they are idempotent i.e. If the desired things are already done/configured, it will just say "Ok" to the task and will move on to the next one.

·      Automation and Efficiency: Playbooks allow you to automate multi-step processes like creating management portset, assigning IPs, and configuring partitions. What might take hours manually can be done in minutes, freeing up valuable time.

·      Scalability: Manually configuring large number of systems becomes impractical. Ansible can manage and configure multiple operations at once, making it easy and ideal for large-scale deployments.

PBHA and partition mobility:
PBHA and partition mobility help keep systems running smoothly and adapt to changes in FlashSystem. Partitions can move across systems during migration or failover and PBHA ensures undisruptive availability by relocating workload to HA partner system. To support this each partition requires a unique management IP that moves with it unlike static cluster or system IP.

Why partition IP…?
Traditionally administrators access FlashSystem by cluster or system IP. However with the introduction of multi-tenant support via partition and their ability to move between systems, this approach no longer meets modern management needs.

Partition IP provide a dedicated floating IP address that moves with the partition. This ensures that management applications maintain persistent access to the partition even during migration or HA failover. These IPs are crucial for scenarios involving:

·       Partition mobility across systems.

·       PBHA

·       External integrations (Cinder, vSphere)

Task to be performed by Ansible Playbook via Rest API on the Cluster: -

·       Create a portset of type "management".

·       Assign an IP address on the above portset.

·       Create/Assign the management portset using the "managementportset" parameter to the partiton

Task a Ansible Playbook can perform using IBM Ansible collection: -

·       Assign a management portset to a partition during partition creation.

·       Assign a management portset to an existing partition.

·       Removing a management portset from a partition.

How to change an existing partition(management) IP

Structure of the Ansible Playbook: -

    - name: Create a management portset

      ibm.storage_virtualize.ibm_svc_manage_portset:

        clustername: "culster_ip"

        username: "username"

        password: "password"

        name: test_mgmt

        portset_type: management

        state: present

    - name: Create IP provisioning

      ibm.storage_virtualize.ibm_svc_manage_ip:

        clustername: "culster_ip"

        username: "username"

        password: "password"

        node: node1

        portset: test_mgmt

        ip_address: "ip"

        subnet_prefix: 24

        state: present

    - name: Create partition with management portset

      ibm.storage_virtualize.ibm_sv_manage_storage_partition:

        clustername: "culster_ip"

        username: "username"

        password: "password"

        name: "partition_name"

        managementportset: test_mgmt

        state: present

IBM storage virtualize ansible collection is used in the playbook: -

·      The Playbook uses ibm_svc_manage_portset module for creating a portset of type “management”.

·      The Playbook then uses ibm_svc_manage_ip module for creating IP on the created portset.

·      Lastly the playbook uses ibm_sv_manage_storage_partition module for creating/assigning management IP on the partiton.

Link for IBM Ansible Collection

IBM Ansible Collection