sap_storage_setup: not working after 1.2.3 about community.sap_install HOT 5 CLOSED

@herrmie TL;DR - you'll need to re-code

In v1.3.0 feature added sap_storage_setup: Overhaul/Rewrite with breaking changes. Prior to this, the Ansible Role was extremely incomplete (for example accidental first day of coding dev notes left in the codebase)

The storage setup Ansible Role is now able to parse and setup block storage or file storage (NFS) e.g. SAP NWAS (ABAP/JAVA) for High Availability

The LVM LV is set by default to 100%, and the other LVM operators are optional in the definition, for example:

sap_storage_setup_definition:
  - name: hana_data
    mountpoint: /hana/data
    disk_size: 384                 # size in GB, integer
    filesystem_type: xfs           # default: xfs
    #lvm_lv_name:                  # default: lv_<element_name>
    #lvm_lv_stripes: 2             # default: null, number of disks to stripe over
    #lvm_lv_stripe_size: 128K      # default: 64K, defined by the OS. Akin to Virtualized Block Size
    #lvm_vg_name:                  # default: vg_<element name>
    #lvm_vg_options:               # default: none, additional LVM VG options as string in LVM options syntax (e.g. "--dataalignment XX ..." to override MiB offset from disk start before first LVM VG Physical Extent)
    #lvm_vg_physical_extent_size:  # default: 4, uses 4 MiB default and difficult to change once set. Akin to Physical Block Size
    #lvm_pv_device:                # default: discovered ansible_devices matching the target size
    #lvm_pv_options:               # default: none, additional LVM PV options as string in LVM options syntax (e.g. "--dataalignment XX ..." to override MiB offset from disk start before first LVM PV Physical Extent)
    #nfs_path:                     # subdirectory path on the NFS server
    #nfs_server:                   # NFS server and parent directory (e.g. nfs.com:/share1). default: {{ sap_storage_setup_nfs_server }}
    #nfs_filesystem_type:          # default: {{ sap_storage_setup_nfs_filesystem_type }}
    #nfs_mount_options:            # default: {{ sap_storage_setup_nfs_mount_options }}
    #swap_path:

from community.sap_install.

I think @herrmie want to define the disks and uses then the define size which are used for each mount point manually as an option. Like:

sap_storage_setup_definition:
  - name: hana_data
    mountpoint: /hana/data
    disk_size: 38
    filesystem_type: xfs
    ***disk: /dev/sdb***
    

from community.sap_install.

Correct @rainerleber.
@sean-freeman, because if I want to add 2 LVMs to one disk, that is not possible with the code. And also not possible is what I said above: I want to have e.g. 20 GB in the vg for later extensions. You know what I mean?

from community.sap_install.

@herrmie By best practice any SAP mountpoints should really be a 1:1:1 ratio to preserve extensibility and ease of long-term maintenance

• 1 mountpoint (e.g. hana/data)
• 1 LVM LG
• 1 LVM VG
  • 1..n LVM PV

I can fully understand for any on-premise physical hardware though, this could be far less efficient. For Virtual Machines or using SAN LUNs, the principle above should hold?

In the Ansible Role....

The ability to overwrite LVM LV static as 100% of the LVM VG can be added to backlog - but would be a very low priority given the existing complexity of trying to scope control storage setup variance. This Ansible Role required extensive testing to scan volumes, find available, and handle all setup - and still remain idempotent. A line has to be drawn somewhere.

If you need to go down this road (Multi LVM LG for 1 LVM VG) immediately, truthfully it will be easier to customize your own specific scenario by looking at the underlying Ansible Modules used for the block/local storage within this Ansible Role:

• community.general.lvg
• community.general.lvol
• community.general.filesystem
• ansible.posix.mount

from community.sap_install.

Documentation resolved by 67f7376

Closing GH Issue

from community.sap_install.