sap_storage_setup: not working after 1.2.3

[herrmie]

Hello, I have used the sap_storage_setup role for a long time with version 1.2.3, without any issues. Now, I have use the newest version and I am wondering why I can't define the devices like in the 1.2.3 version. I have understand from the code, that the role will use undefined disks. But what is the clarification if I use a disk, is it the disk_size? If yes, this is not good. Because, if I have a disk with 100GB and want to have 20 GB reserved in the VG, that will not be possible I guess. Please check the role and let me know how I get it working.

sap_storage_setup_definition:
- disk_size: "{{ vm_hana_usr_sap }}G"
  filesystem_type: xfs
  name: "usrsap"
  mountpoint: "/usr/sap/{{ SID }}"
  lvm_vg_name: "vg_usr_sap"
  lvm_lv_name: "lv_usr_sap"
- disk_size: "{{ vm_hana_backup }}G"
  filesystem_type: xfs
  name: "backup"
  mountpoint: "/backup"
  lvm_vg_name: "vg_backup"
  lvm_lv_name: "lv_backup"
- disk_size: "{{ vm_hana_shared }}G"
  filesystem_type: xfs
  name: "hanashared"
  mountpoint: "/hana/shared"
  lvm_vg_name: "vg_hana_shared"
  lvm_lv_name: "lv_hana_shared"
- disk_size: "{{ vm_hana_data }}G"
  filesystem_type: xfs
  name: "hanadata"
  mountpoint: "/hana/data"
  lvm_vg_name: "vg_hana_data"
  lvm_lv_name: "lv_hana_data"
- disk_size: "{{ vm_hana_log }}G"
  filesystem_type: xfs
  name: "hanalog"
  mountpoint: "/hana/log"
  lvm_vg_name: "vg_hana_log"
  lvm_lv_name: "lv_hana_log"

Thanks in advance and best regards, Steffen Herrmann

[sean-freeman]

@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:

[rainerleber]

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***
    

[herrmie]

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?

[sean-freeman]

@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

[sean-freeman]

Documentation resolved by https://github.com/sap-linuxlab/community.sap_install/pull/825/commits/67f7376de3df79b538b4f45ac07e441f8d606e8b

Closing GH Issue