Linux Configuration Guide (Formerly Known as FAQ 1546)
This topic includes:
The DataCore Server's Settings
Known Issues in Linux Configuration Guide
Overview
This guide provides configuration settings and considerations for hosts running Linux with SANsymphony.
Basic Linux storage administration skills are assumed including how to connect to iSCSI and Fibre Channel target ports and the discovering, mounting and formatting of disk devices.
Change Summary
Refer to DataCore FAQ 838 for the latest version of the FAQ and see Previous Changes that lists the earlier changes made to this FAQ.
| Section(s) | Content Changes | |||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Compatibility Lists |
Updated RedHat Enterprise Linux
SUSE Linux Enterprise Server
Ubuntu
|
Compatibility Lists
Oracle VM Server for x86
|
Version |
With ALUA |
Without ALUA |
|---|---|---|
|
3.3 and earlier |
Not Supported |
Not Supported |
|
3.4.x |
Not Qualified |
Qualified 1 |
- Qualified vs. Not Qualified vs. Not Supported
Refer to Qualified vs. Not Qualified vs. Not Supported for definitions. - DataCore Server Front-end Port Connections
Only Fibre Channel front-end connections are qualified.
Front-end iSCSI connections are not qualified. - Oracle VM Manager
Oracle's VM Manager was not used during DataCore’s qualification testing. - SCSI UNMAP
SCSI UNMAP is supported.
RedHat Enterprise Linux
Applies to all versions of SANsymphony 10.x.
|
Version |
With ALUA |
Without ALUA |
|---|---|---|
|
5.10 and earlier |
Not Supported |
Not Supported |
| 6.0 – 6.4 | Not Qualified 2 | Not Qualified 3 |
| 6.5 – 6.6 | Qualified | Not Qualified 4 |
| 6.7 – 6.10 | Not Qualified 5 | Not Qualified 6 |
| 7.0 | Qualified | Not Qualified 7 |
| 7.1 | Not Qualified 8 | Not Qualified 9 |
| 7.2 – 7.3 | Qualified 10 | Not Qualified 11 |
| 7.4 | Qualified 12 | Not Qualified |
| 7.5 – 7.8 | Not Qualified | Not Qualified |
| 8.x | Not Qualified | Not Qualified |
| 9.x | Not Qualified | Not Qualified |
- Qualified vs. Not Qualified vs. Not Supported
Refer to Qualified vs. Not Qualified vs. Not Supported for definitions. - DataCore Server Front-end Port Connections
Fibre Channel and iSCSI are supported. - Multipath Tools
Always use the most current version of Multipathing Tools available. - SCSI UNMAP
SCSI UNMAP is supported.
SUSE Linux Enterprise Server
Applies to all versions of SANsymphony 10.x.
|
Version |
With ALUA |
Without ALUA |
|---|---|---|
|
11.0 |
Not Supported |
Not Supported |
| 11.0 SP 1 |
Not Supported |
Not Supported |
| 11.0 SP 2 |
Not Qualified |
Not Supported |
| 11.0 SP 3 | Qualified | Not Supported |
| 11.0 SP 4 | Qualified 13 | Not Qualified 14 |
| 12.0 | Not Qualified 15 | Not Qualified 16 |
| 12.0 SP 1 | Qualified 17 | Not Qualified 18 |
| 12.0 SP 2 | Not Qualified 19 | Not Qualified 20 |
| 12.0 SP 3 | Qualified 21 | Not Qualified 22 |
| 12.0 SP 4 - 5 | Not Qualified | Not Qualified |
| 15.0 | Qualified | Not Qualified |
| 15.0 SP 1 - 4 | Not Qualified | Not Qualified |
- Qualified vs. Not Qualified vs. Not Supported
Refer to Qualified vs. Not Qualified vs. Not Supported for definitions. - DataCore Server Front-end Port Connections
Fibre Channel and iSCSI are supported except for SLES 11.0 SP 4 and 12.0 SP 1 where on FC connections are "Qualified", iSCSI connections for these two versions are "Not Qualified". - Multipath Tools
- For SLES 12.x use version 0.5.0+git1.656f8865 or later. Earlier versions are "Not Qualified".
- For SLES 11.x use the most current version available.
- SCSI UNMAP
SCSI UNMAP is not supported.
Ubuntu
Applies to all versions of SANsymphony 10.x.
|
Version |
With ALUA |
Without ALUA |
|---|---|---|
|
14.04 Trusty Tahir |
Not Supported |
Qualified |
|
16.04 Xenial Xerus |
Not Qualified | Qualified |
|
18.04 Bionic Beaver |
Qualified 23 | Not Qualified |
|
20.04 Focal Fossa |
Not Qualified | Not Qualified |
|
22.04 Jammy Jellyfish |
Not Qualified | Not Qualified |
Long Term Support (LTS) releases only. Applies to the Linux distribution provided by Canonical Ltd. only. Debian (and other distributions ‘based on’ Ubuntu) are, for purposes of this document, considered as ‘Other’ Linux distributions, refer to All Other Linux Distributions.
- Qualified vs. Not Qualified vs. Not Supported
Refer to Qualified vs. Not Qualified vs. Not Supported for definitions. - DataCore Server Front-end Port Connections
Fibre Channel and iSCSI connections are supported. - Multipath Tools
Use Multipath Tools version 0.5.0+git1.656f8865 or later. Earlier versions are considered "Not Qualified". - SCSI UNMAP
SCSI UNMAP is supported.
All Other Linux Distributions
Applies to all versions of SANsymphony 10.x.
|
With ALUA |
Without ALUA |
|---|---|
|
Not Qualified |
Not Qualified |
Qualified vs. Not Qualified vs. Not Supported
Refer to Qualified vs. Not Qualified vs. Not Supported for definitions.
SCSI UNMAP Support
Only applies to all ‘Qualified’ Linux distributions with SANsymphony 10.x.
|
Distribution |
SANsymphony 10.x |
|---|---|
| Oracle VM x86 | Tested/Works |
| RHEL | Tested/Works |
| SLES | Does not work |
|
Ubuntu |
Not tested |
SAP HANA Certification and Settings
Refer to SANsymphony with SAP HANA - Sizing Guidelines for information.
Qualified vs. Not Qualified vs. Not Supported
Qualified
This combination has been tested by DataCore and all the host-specific settings listed in this document applied using non-mirrored, mirrored and dual virtual disks.
Not Qualified
This combination has not yet been tested by DataCore using mirrored or dual virtual disk types. DataCore cannot guarantee 'high availability' (failover/failback, continued access etc.) even if the host-specific settings listed in this document are applied. Self-qualification may be possible please see Technical Support FAQ #1506.
Mirrored or dual virtual disk types are configured at the users own risk; however, any problems that are encountered while using Linux distributions that are "Not Qualified" will still get root-cause analysis.
Non-mirrored virtual disks are always considered "Qualified" - even for "Not Qualified" combinations of Linux/SANsymphony.
Not Supported
This combination has either failed 'high availability' testing by DataCore using mirrored or dual virtual disk types; or the operating System's own requirements/limitations (e.g., age, specific hardware requirements) make it impractical to test. DataCore will not guarantee 'high availability' (failover/failback, continued access etc.) if the host-specific settings listed in this document are applied. mirrored or dual virtual disk types are configured at the users own risk. Self-qualification is not possible.
Mirrored or dual virtual disk types are configured at the users own risk; however, any problems that are encountered while using Linux distributions that are "Not Supported" will get best-effort Technical Support (e.g., to get access to virtual disks) but no root-cause analysis will be done.
Non-mirrored virtual disks are always considered "Qualified" – even for "Not Supported" combinations of Linux/SANsymphony.
Linux Versions that are End of Life
For versions that are listed as "Not Supported", self-qualification is not possible. For versions that are listed as "Not Qualified", self-qualification may be possible if there is an agreed "support contract" with your Linux Vendor as well. Please contact DataCore Technical Support before attempting any self-qualification of Linux versions that are End of Life.
For any problems that are encountered while using Linux versions that are EOL with DataCore Software, only best-effort Technical Support will be performed (e.g., to get access to virtual disks). Root-cause analysis will not be done.
Non-mirrored virtual disks are always considered "Qualified".
The DataCore Server's Settings
Operating System Type
When registering the host choose one of the appropriate options:
- Oracle VM Server chose 'Linux (all other distributions)'
- RedHat Enterprise Linux choose 'Linux (all other distributions)'
- SUSE Linux Enterprise Server chose 'Linux SUSE Enterprise Server 11'
- Ubuntu Linux choose 'Linux (all other distributions)'
Port Roles
Ports that are used to serve virtual disks to hosts should only have the front-end role checked. While it is technically possible to check additional roles on a front-end port (i.e., mirror and back-end), this may cause unexpected results after stopping the SANsymphony software.
Any port with front-end role (and is serving virtual disks to hosts) also has either the mirror and/or backend role enabled will remain ‘active’ even when the SANsymphony software is stopped. There is some slight difference in behavior depending on the version of SANsymphony installed.
SANsymphony 10.0 PSP 7 and earlier
Any port that has the mirror and/or back-end role checked will remain ‘active’ after the SANsymphony software has been stopped.
SANsymphony 10.0 PSP 8 and later
Only ports with the back-end role checked will remain ‘active’ after the SANsymphony software has been stopped.
Front-end ports that are serving virtual disks but remain active after the SANsymphony software has been stopped can cause unexpected results for some host operating systems as they continue to try to access virtual disks from the ‘active’ port on the now-stopped DataCore Server. This, in turn, may end up delaying host fail-over or result in complete loss of access from the host’s application/Virtual Machines.
Multipathing
The Multipathing Support option should be enabled so that mirrored virtual disks or dual virtual disks can be served to hosts from all available DataCore FE ports. Refer to Multipathing Support for more information.
Non-mirrored Virtual Disks and Multipathing
Non-mirrored virtual disks can still be served to multiple hosts and/or multiple host ports from one or more DataCore Server FE Ports if required; in this case the host can use its own multipathing software to manage the multiple host paths to the single virtual disk as if it was a mirrored or dual virtual disk.
ALUA Support
Refer to your distribution’s Compatibility Lists.
Serving Virtual Disks
For the first time
DataCore recommends that before serving virtual disks for the first time to a host, that all DataCore front-end ports on all DataCore Servers are correctly discovered by the host first. Then, from within the SANsymphony Console, the virtual disk is marked Online, up to date and that the storage sources have a host access status of Read/Write.
To more than one host port
DataCore virtual disks always have their own unique Network Address Authority (NAA) identifier that a host can use to manage the same virtual disk being served to multiple ports on the same host server and the same virtual disk being served to multiple hosts.
While DataCore cannot guarantee that a disk device's NAA is used by a host's operating system to identify a disk device served to it over different paths generally we have found that it is. And while there is sometimes a convention that all paths by the same disk device should always using the same LUN 'number' to guarantees consistency for device identification, this may not be technically true. Always refer to the host Operating System vendor’s own documentation for advice on this.
DataCore's Software does, however always try to create mappings between the host's ports and the DataCore Server's front-end (FE) ports for a virtual disk using the same LUN number where it can. The software will first find the next available (lowest) LUN 'number' for the host-DataCore FE mapping combination being applied and will then try to apply that same LUN number for all other mappings that are being attempted when the virtual disk is being served. If any host-DataCore FE port combination being requested at that moment is already using that same LUN number (e.g., if a host has other virtual disks served to it from previous) then the software will find the next available LUN number and apply that to those specific host-DataCore FE mappings only.
The Linux Host's Settings
SCSI Disk Timeout
This should be set to 80 seconds for all SCSI devices created from SANsymphony virtual disks. The timeout for a given SCSI device can be checked using the ‘cat’ command.
Example:
cat /sys/block/sda/device/timeout
There are two methods that can be used to change the SCSI disk timeout for a given device.
- Use the ‘echo’ command – this is temporary and will not survive the next reboot of the Linux host server.
- Create a custom ‘udev rule’ – this is permanent but will require a reboot for the setting to take effect.
Using the ‘echo’ command (will not survive a reboot)
Set the SCSI Disk timeout value to 80 seconds:
echo 80 > /sys/block/[disk_device]/device/timeout
Creating a custom ‘udev’ rule (permanent but requires a reboot)
Create a file called ‘/etc/udev/rules.d/99-datacore.rules’ with the following settings:
SUBSYSTEM=="block", ACTION=="add", ATTRS{vendor}=="DataCore", ATTRS{model}=="Virtual Disk", RUN+="/bin/sh -c 'echo 80 > /sys/block/%k/device/timeout'"
For OracleVMx86, RHEL and Ubuntu distributions, refer to their respective documentation to configure custom udev rules. Refer to SUSE Support for SLES users.
- This KB article applies to all current versions of SANsymphony 10.x as well.
- Make sure that the udev rule is exactly as written above. Else this may result in the Linux operating system defaulting back to 30 seconds.
- There are 4 blank whitespace characters after the ATTRS{model} string which much be observed otherwise paths to SANsymphony virtual disks may not be re-discovered.
Multipath Configuration Settings
If configuring Linux hosts using SAP HANA then do not use the settings below but refer to the guide SANsymphony with SAP HANA - Sizing Guidelines and use the multipath configuration settings there. Refer to SANsymphony with SAP HANA - Sizing Guidelines.
The 'defaults' section
Add/Modify the polling_interval to a value of 60 (seconds).
defaults { polling_interval 60 }
This tells the host how often to check for access on a previously failed virtual disk path. A smaller setting will interfere with host performance. Do not add this parameter to the 'device' section of the multipath configuration file (see below) as it will prevent the polling from working as expected.
The ‘blacklist exceptions’ section
blacklist_exceptions {
vendor "DataCore"
product "Virtual Disk"
}
The 'multipaths' section
Adding this section allows the Linux users to identify the virtual disks with a human readable name rather than relying on wwid. This is useful for mount point identification and is also supported by SAP HANA to have a user friendly configuration. The wwid starts with "3" and is followed by the name of the virtual disk. Adding this section causes the /dev/mapper special files to be generated which are named according to the alias.
multipaths {multipath {wwid "360030d90e434a90619f366b49256afa8"
alias "vDisk1"
}
multipath {wwid "360030d9094baa806a7c296187cbff811"
alias "vDisk2"
}
}
The 'device' section
All the following entries listed are DataCore-required values. See the notes section for more specific technical details.
ALUA enabled
device {vendor "DataCore"
product "Virtual Disk"
failback 10
path_checker tur
prio alua
no_path_retry fail
# dev_loss_tmo infinity
dev_loss_tmo 60
fast_io_fail_tmo 5
rr_min_io_rq 100
# rr_min_io 100
path_grouping_policy group_by_prio
# path_grouping_policy failover
# user_friendly_names yes
}
ALUA not enabled
device {vendor "DataCore"
product "Virtual Disk"
failback 10
path_checker tur
no_path_retry fail
# dev_loss_tmo infinity
dev_loss_tmo 60
fast_io_fail_tmo 5
# user_friendly_names yes
}
- vendor / product
Virtual disks created in SANsymphony 8.x or later will use the strings listed above.
Virtual disks created in SANmelody or SANsymphony 7.x and earlier or will have different strings and an additional device section will need to be created to work with those virtual disks. Refer to the SCSI Standard Inquiry section in Changing Virtual Disk Settings. - failback
Adds an extra ‘wait’ period (10 seconds) to prevent unnecessary ‘failback’ attempts to a virtual disk whose host access value is ‘Not Allowed’. - path_checker
Use the value indicated. No other value should be used. - path_grouping_policy (applies to ALUA enabled hosts only)
Either one of two values is allowed:- group_by_prio
- failover
This setting is ‘Not Qualified’ on RHEL 6.5 and greater. Refer to Appendix A for more information regarding the preferred server settings.
- prio (applies to ALUA enabled hosts only)
This is a DataCore-required value. No other value should be used. - no_path_retry
This is a DataCore-required value. No other value should be used. - dev_loss_tmo
Either one of two values is allowed:- For SANsymphony 10.0 PSP 8 or later use a dev_loss_tmo value of 60
- For SANsymphony 10.0 PSP 7 Update 2 and earlier use a dev_loss_tmo value of ‘infinity’. Older kernels might not recognize ‘infinity’ a syslog error is usually posted, so in this case the default value - usually ‘600’ seconds - will be applied instead.
Use the ‘cat’ command to verify that any DataCore virtual disks detected by the Linux host are using the ‘infinity’ value correctly.
Example:sleshost3:~ # cat /sys/class/fc_remote_ports/rport-*\:*-*/dev_loss_tmo
Devices using the ‘Infinity’ setting will have a value of ‘2147483647’
- fast_io_fail_tmo
This is a DataCore-required value. No other value should be used. - rr_min_io_rq (applies to ALUA enabled hosts only)
Use on systems running kernels newer than 2.6.30.
This is a DataCore-required value. No other value should be used. - rr_min_io (applies to ALUA enabled hosts only)
Use on systems running kernels older than 2.6.31.
This is a DataCore-required value. No other value should be used. - user_friendly_names
Optional. This tells the operating system to use a persistent, unique alias to the multipath device, in the form of mpathn. Otherwise, a WWID will be used as the alias instead.
Known Issues in Linux Configuration Guide
The following is intended to make DataCore Software users aware of any issues that affect performance, access or may give unexpected results under certain conditions when SANsymphony is used in configurations with Linux hosts.
These Known Issues may have been found during DataCore’s own testing, but others may have been reported by our users when a solution was found that was not to do with DataCore’s own products.
DataCore cannot be held responsible for incorrect information regarding another vendor’s products and no assumptions should be made that DataCore has any communication with these other vendors regarding the issues listed here.
We always recommend that the vendors should be contacted directly for more information on anything listed in this section.
For ‘Known issues’ that apply to DataCore Software’s own products, please refer to the relevant DataCore Software Component’s release notes.
Formatting Virtual Disks
Affects all Linux Distributions
Formatting a virtual disk may take longer than expected
If the virtual disk is mounted on the Linux host using the -o discard mount option formatting the disk will automatically use ‘TRIM/UNMAP’ commands during the format process which can result in a significantly longer wait time for the format to complete.
Use either the mkfs command with the ‘nodiscard’ switch or mount the virtual disk without the –o discard option. Refer to the mkfs and mount man pages for your specific Linux distribution for more information.
Affects all Linux Distributions
Ext3 FS will use excessive disk pool Storage Allocations
The Ext3 filesystem will use significant amounts of Storage Allocation Units (SAU) during the ‘Writing superblocks and filesystem accounting information’ phase of the file system's creation. Care must therefore be taken so as not to completely use all the SAUs from the disk pool; and if Ext3 is required, then use a small (i.e., 4MB) SAU size. Other filesystem types do not seem to exhibit this behavior and use only a few SAUs during filesystem creation.
Redetecting Paths to Virtual Disks
Affects all Linux Distributions
A manual rescan on the host is needed to discover new paths after using SANsymphony’s evacuation feature.
Refer to the Evacuating a DataCore Server section in the Maintenance Mode documentation.
Symptoms include the host reporting "alua not supported" and/or "failed to read S.M.A.R.T. values" for evacuated virtual disks until the new paths are discovered.
Affects Ubuntu Only
Manual rescans are needed to update previously failed paths for Ubuntu hosts
During testing, DataCore have not been able to get Ubuntu to automatically re-detect paths to mirrored virtual disks that have failed or have been removed (e.g., after stopping a DataCore Server) and are then subsequently made available again. Manual intervention is required.
Use the 'multipath' command to establish which paths were previously failed (and are now available from the DataCore Server):
multipath -ll
Then use the 'echo' command to send an IOCTL to the disk device and ‘force’ the operating system to update the path’s status properly. For example:
echo 1 > /sys/block/sdc/device/rescan
Alternatively, download and install the 'scsitools' package and use the 'rescan-scsi-bus' command to re-establish the connection to the previously failed path.
Appendices
A: Preferred Server and Preferred Path Settings
Without ALUA Enabled
If hosts are registered without ALUA support, the Preferred Server and Preferred Path settings will serve no function. All DataCore Servers and their respective Front End (FE) paths are considered ‘equal’.
It is up to the host’s own Operating System or Failover Software to determine which DataCore Server is its preferred server.
With ALUA Enabled
Setting the Preferred Server to ‘Auto’ (or an explicit DataCore Server), determines the DataCore Server that is designated ‘Active Optimized’ for host IO. The other DataCore Server is designated ‘Active Non-Optimized’.
If for any reason the Storage Source on the preferred DataCore Server becomes unavailable, and the host Access for the virtual disk is set to Offline or Disabled, then the other DataCore Server will be designated the ‘Active Optimized’ side. The host will be notified by both DataCore Servers that there has been an ALUA state change, forcing the host to re-check the ALUA state of both DataCore Servers and act accordingly.
If the Storage Source on the preferred DataCore Server becomes unavailable but the host Access for the virtual disk remains Read/Write, for example if only the Storage behind the DataCore Server is unavailable but the FE and MR paths are all connected or if the host physically becomes disconnected from the preferred DataCore Server (e.g., Fibre Channel or iSCSI Cable failure) then the ALUA state will not change for the remaining, ‘Active Non- optimized’ side. However, in this case, the DataCore Server will not prevent access to the host, nor will it change the way READ or WRITE IO is handled compared to the ‘Active Optimized’ side, but the host will still register this DataCore Server’s Paths as ‘Active Non-Optimized’ which may (or may not) affect how the host behaves generally.
Refer to the Preferred Servers and Preferred Paths sections in Port Connections and Paths for more information.
In the case where the Preferred Server is set to ‘All’, then both of the DataCore Servers are designated ‘Active Optimized’ for host IO.
All IO requests from a host will use all Paths to all DataCore Servers equally, regardless of the distance that the IO must travel to the DataCore Server. For this reason, the ‘All’ setting is not normally recommended. If a host has to send a WRITE IO to a ‘remote’ DataCore Server (where the IO Path is significantly distant compared to the other ‘local’ DataCore Server), then the WAIT times accrued by having to send the IO not only across the SAN to the remote DataCore Server, but for the remote DataCore Server to mirror back to the local DataCore Server and then for the mirror write to be acknowledged from the local DataCore Server to the remote DataCore Server and finally for the acknowledgment to be sent to the host back across the SAN, can be significant.
The benefits of being able to use all Paths to all DataCore Servers for all virtual disks are not always clear cut. Testing is advised.
For Preferred Path settings it is stated in the SANsymphony Help:
A preferred front-end path setting can also be set manually for a particular virtual disk. In this case, the manual setting for a virtual disk overrides the preferred path created by the preferred server setting for the host.
For example, if the Preferred Server is designated as DataCore Server A and the Preferred Paths are designated as DataCore Server B, then DataCore Server B will be the ‘Active Optimized’ Side not DataCore Server A.
In a two-node Server group there is usually nothing to be gained by making the Preferred Path setting different to the Preferred Server setting and it may also cause confusion when trying to diagnose path problems, or when redesigning your DataCore SAN with regard to host IO Paths.
For Server Groups that have three or more DataCore Servers, and where one (or more) of these DataCore Servers shares mirror Paths between other DataCore Servers setting the Preferred Path makes more sense.
For example, DataCore Server A has two mirrored virtual disks, one with DataCore Server B, and one with DataCore Server C and DataCore Server B also has a mirrored virtual disk with DataCore Server C then using just the Preferred Server setting to designate the ‘Active Optimized’ side for the host’s virtual disks becomes more complicated. In this case the Preferred Path setting can be used to override the Preferred Server setting for a much more granular level of control.
B: Reclaiming Storage from Disk Pools
How Much Storage will be Reclaimed?
This is impossible to predict.
SANsymphony can only reclaim Storage Allocation Units that have no block-level data on them. If a host write its data ‘all over’ its own filesystem, rather than contiguously, the amount of storage that can be reclaimed may be significantly less than expected.
Defragmenting data on virtual disks
It may be possible to use a host’s own defragmentation tools to consolidate data spread out all over the host’s filesystem, but care should be taken as even more storage may be allocated while the existing data is defragmented.
Once any defragmentation is completed then additional steps will need to wipe the ‘free’ filesystem space on the host and then use SANsymphony’s ‘Manual Reclamation’ feature.
Notes on SANsymphony's Reclamation Feature
Automatic Reclamation
SANsymphony checks for any ‘zero’ write I/O as it is received by the disk pool and keeps track of which block’s addresses they were sent to. When all the blocks of an allocated SAU have received ‘zero’ write I/O, the storage used by the SAU is then reclaimed.
Mirrored and replicated virtual disks will mirror/replicate the ‘zero’ write I/O so that storage can be reclaimed on the mirror/replication destination DataCore Server in the same way.
Manual Reclamation
SANsymphony checks for ‘zero’ block data by sending read I/O to the storage. When all the blocks of an allocated SAU are detected as having ‘zero’ data on them, the storage used by the SAU is then reclaimed.
Mirrored virtual disks will receive the manual reclamation ‘request’ on all DataCore Servers involved in the mirror configuration at the same time and each DataCore Server will read from its own storage.
The Manual reclamation ‘request’ is not sent to replication destination DataCore Servers from the source. Replication destinations will need to be manually reclaimed separately.
Reclaiming Storage on the Host Manually
Using ‘fstrim’ or ‘mount –o discard’ command
SANsymphony's support for SCSI UNMAP when used in conjunction the Linux fstrim command or the ‘mount –o discard’ option on certain file system types and allows hosts to send 'all-zero' write I/O to a virtual disk and trigger SANsymphony's Automatic Reclamation feature. Refer to Compatibility Lists to see if your distribution of Linux will work with SANsymphony’s SCSI UNMAP support.
See also fstrim and mount for Linux Man-pages project, and RedHat’s Storage Administration Guide - 2.4. Discard unused blocks
Using the ‘dd’ command
A suggestion would be to create a sparse file of an appropriate size and then use the dd command to send zeros to the file.
Example:
From within the file system on the Disk Device create an ‘empty’ 2GB file called ‘my_file’:
fallocate --length 2147483648 my_file
Then use the dd command to write 'all-zero' I/O.
dd if=/dev/zero of=my_file bs=1024 count=2097152
This I/O will then be detected by SANsymphony's Automatic Reclamation function.
Previous Changes
| Section(s) | Content Changes | Date | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Compatibility Lists |
Updated SUSE Linux Enterprise Server
The Linux host settings – SCSI disk timeouts – custom udev rules The previous documented setting was: ACTION=="add", SUBSYSTEM=="block", ATTRS{vendor}=="DataCore", ATTRS{model}=="virtual disk ", RUN+="/bin/sh -c 'echo 80 > /sys/block/%k/device/timeout'"
This has been changed to SUBSYSTEM=="block", ACTION=="add", ATTRS{vendor}=="DataCore", ATTRS{model}=="Virtual Disk ", RUN+="/bin/sh -c 'echo 80 > /sys/block/%k/device/timeout'"
The order of the ACTION and SUBSYSTEM settings have been swapped around as it had been found that the previous settings could cause some Linux distributions to not use the expected 80 second timeout value and default instead back to a timeout value which would cause inconsistent failover/failback during SANsymphony virtual disk failed redundancy events. Also, the ATTRS{model} section did not have the correct upper-case letters for the model’s name. Please also note that there are 4 white-space characters included at the end of the ATTRS{model} string. |
July 2021 | ||||||||||||
| General |
Updated This document has been reviewed for SANsymphony 10.0 PSP 11. No additional settings or configurations are required. |
January 2021 | ||||||||||||
| Compatibility Lists |
Updated RedHat Enterprise Linux
Ubuntu LTS
|
August 2020 | ||||||||||||
| General |
Updated This document has been reviewed for SANsymphony 10.0 PSP 9. No additional settings or configurations are required. |
October 2019 | ||||||||||||
| Known Issues - Formatting virtual disks - Affects all Linux distributions |
Updated Formatting a virtual disk may take longer than expected If the virtual disk is mounted on the Linux host using the -o discard mount option formatting the disk will automatically use ‘TRIM/UNMAP’ commands during the format process which can result in a significantly longer wait time for the format to complete. Use either the mkfs command with the ‘nodiscard’ switch or mount the virtual disk without the –o discard option. Refer to the mkfs and mount man pages for your specific Linux distribution for more information. |
|||||||||||||
| The DataCore Server’s settings – Port Roles | Updated | July 2019 | ||||||||||||
| General |
Removed All information regarding SANsymphony-V 9.x as this version is end of life (EOL). Refer to End of life notifications for DataCore Software products for more information. |
|||||||||||||
| Compatibility Lists |
Added RedHat Enterprise Linux RedHat Enterprise Linux 8.x added to compatibility list. Currently this version is considered ‘Not Supported’ for SANsymphony 9.0 PSP 4 Update 4 and ‘Not Qualified’ for all versions of SANsymphony 10.x. |
June 2019 | ||||||||||||
| Compatibility Lists |
Updated RedHat Enterprise Linux Added footnotes for those versions of RedHat that may be at (or near to) the end of their RedHat Life Cycle subscription service that are considered ‘Not Qualified’. |
|||||||||||||
| SUSE Enterprise Linux |
Updated Added footnotes for those versions of SUSE that may be at (or near to) the end of their SUSE Long Term Service Support (LTSS) that are considered ‘Not Qualified’. |
|||||||||||||
| Compatibility Lists |
Added RedHat Enterprise Linux 7.5 – 7.6 SUSE Linux Enterprise Server 12.0 SP 4 and 15 These versions are currently considered 'Not Qualified' for SANsymphony 10.x versions and 'Not Supported' for SANsymphony-V 9.0 PSP 4 Update 4 (and earlier). |
March 2019 | ||||||||||||
| The Linux host’s settings |
Updated Multipath configuration settings Minor informational additions to the ‘devices’ sections to highlight that there are two possible device_loss_tmo settings that can be used, depending on the version of SANsymphony that is serving the virtual disks. See the notes section for more details. |
|||||||||||||
| The Linux host’s settings |
Updated Multipath configuration settings For SANsymphony 10.0 PSP 8 or later use a dev_loss_tmo setting of 60. Earlier versions of SANsymphony use a dev_loss_tmo setting of infinity. |
October 2018 | ||||||||||||
| Compatibility lists |
Added RedHat Enterprise Linux 7.4 This version is now qualified for SANsymphony 10.0 PSP 7 Update 2 or later. Earlier versions of SANsymphony 10.x are considered 'Not Qualified'. SUSE Linux Enterprise Server 12 SP 3 This version is now qualified for SANsymphony 10.0 PSP 7 Update 2 or later. Earlier versions of SANsymphony 10.x are considered 'Not Qualified'. Ubuntu 18.04 LTS This version is now qualified for SANsymphony 10.0 PSP 7 Update 2 or later. Earlier versions of SANsymphony 10.x are considered 'Not Qualified'. |
September 2018 | ||||||||||||
| Compatibility Lists |
Added Added SCSI UNMAP compatibility table. |
August 2018 | ||||||||||||
| Known Issues |
Added Affects all Linux distributions A manual rescan on the host is needed to discover new paths after using SANsymphony’s evacuation feature. Refer to the Evacuating a DataCore Server section in Maintenance Mode. Symptoms include the host reporting "alua not supported" and/or "failed to read S.M.A.R.T. values" for evacuated virtual disks until the new paths are discovered. |
|||||||||||||
| Compatibility lists - Red Hat Enterprise Linux |
Updated Ubuntu 16.04 LTS This version is now ‘supported’ for SANsymphony 10.x versions and 'Not Supported' for SANsymphony-V 9.0 PSP 4 Update 4 (and earlier). |
May 2018 | ||||||||||||
| Compatibility lists - Red Hat Enterprise Linux |
Added Ubuntu 18.x This version is currently considered 'Not Qualified' for SANsymphony 10.x versions and 'Not Supported' for SANsymphony-V 9.0 PSP 4 Update 4 (and earlier). |
|||||||||||||
| General |
Updated This document has been reviewed for SANsymphony 10.0 PSP 7. No additional settings or configurations are required. |
February 2018 | ||||||||||||
| Appendix B – Configuring disk pools |
Removed The information here has been removed as it is now superseded by the information in: The DataCore Server- Best Practice Guidelines What was previously 'Appendix C' has now been moved to 'Appendix B'. |
|||||||||||||
| Compatibility Lists |
Added RedHat Enterprise Linux 7.4 This version is currently considered 'Not Qualified' for SANsymphony 10.x versions and 'Not Supported' for SANsymphony-V 9.0 PSP 4 Update 4 (and earlier). SUSE Linux Enterprise Server 12.0 SP 3 This version is currently considered 'Not Qualified' for SANsymphony 10.x versions and 'Not Supported' for SANsymphony-V 9.0 PSP 4 Update 4 (and earlier). Ubuntu 17.x This version is currently considered 'Not Qualified' for SANsymphony 10.x versions and 'Not Supported' for SANsymphony-V 9.0 PSP 4 Update 4 (and earlier). |
October 2017 | ||||||||||||
| Compatibility Lists |
Updated RHEL 6.9 - This version is 'Not Supported' for SANsymphony – V 9.x and earlier and 'Not Qualified' for SANsymphony versions 10.x RHEL 7.3 - This version is now qualified for SANsymphony 10.0 PSP 6 and greater when using ALUA (earlier versions of SANsymphony are still considered 'not qualified'). |
August 2017 | ||||||||||||
| Compatibility Lists |
Updated RHEL 7.2 - This version is now qualified for SANsymphony 10.0 PSP 6 and greater when using ALUA |
May 2017 | ||||||||||||
| Compatibility Lists |
Updated A note about Multipathing Support has been added with regard to expected versions of 'Multipathing Tools' that should be installed. RHEL 7.3 SUSE Linux Enterprise Server 12.0 SP 2 These versions are 'not supported' for SANsymphony-V 9.x and 'not qualified' for SANsymphony 10.x.
Ubuntu 15.x This version is 'not supported' for SANsymphony-V 9.0 PSP 4 Update 4 'Without ALUA'. Previously it was, incorrectly, marked as 'not qualified'. |
April 2017 | ||||||||||||
| SAP HANA – certified configuration settings |
Removed The information has been moved to the 'SANsymphony with SAP HANA - Sizing Guidelines' document. |
|||||||||||||
| The Linux host's settings – Operating system settings – Disk Timeouts |
Updated Expanded the note under this section that refers to a URL from SUSE's own Knowledgebase that explains how to make the required SCSI Disk Device timeout setting permanent over a reboot. |
February 2017 | ||||||||||||
| Linux compatibility list |
Added Oracle VM Server Version 3.4 has now been qualified with SANsymphony-V 10.0 PSP 6 or greater. |
January 2017 | ||||||||||||
| The DataCore Server's settings |
Added Added link: Video: Configuring Linux hosts to use DataCore virtual disks |
December 2017 | ||||||||||||
| Appendix C - Reclaiming storage |
Updated Automatic and Manual reclamation These two sections have been re-written with more detailed explanations and technical notes. |
November 2017 | ||||||||||||
| Linux compatibility lists |
Updated SUSE Linux Enterprise Server 11.0 SP 4 SUSE Linux Enterprise Server 12.0 SP 1 Both of these versions are now 'Supported' using ALUA with Fibre Channel front-end connections. Note: iSCSI Front End connections are still considered 'Not Qualified' |
October 2017 | ||||||||||||
| General |
Updated This document has been reviewed for SANsymphony 10.0 PSP 5. No other updates were required. |
July 2017 | ||||||||||||
| Linux compatibility list |
Added Red Hat Enterprise Linux Versions 7.1 – 7.2 Red Hat Enterprise Linux Versions 6.7 – 6.8 SUSE Linux Enterprise Server 12 (no Service Pack) and 12 Service Pack 1 |
April 2017 | ||||||||||||
| Linux compatibility list |
Updated Red Hat Enterprise Linux Version 5.5 – 5.10 Previously this version was listed as 'not qualified' with ALUA enabled hosts and SANsymphony-V 9.x. This has now been changed to 'Not Supported with mirrored or dual virtual disks'. Red Hat Enterprise Linux Version 6.6 Previously this version was listed as 'Not Qualified' with ALUA enabled hosts and SANsymphony-V 10.x. This version is now 'Qualified' with ALUA enabled hosts and SANsymphony-V 10.x. |
January 2017 | ||||||||||||
| Linux Applications – SAP HANA |
Added This includes an example of a 3-node SAP HANA configuration. |
November 2015 | ||||||||||||
| General |
Updated SANsymphony-V 8.x and all versions of SANsymphony 9.x before PSP4 Update 4 are now ‘End of Life’. Refer to End of Life Notifications. |
|||||||||||||
| Linux Applications – SAP HANA |
Added A new section has been added with settings specific to SAP HANA. |
September 2015 | ||||||||||||
| Linux compatibility list |
Updated SUSE Linux Enterprise Server 11.0 Service Pack 3 using ALUA are certified with SAP HANA versions SPS09 and SPS10. |
|||||||||||||
| Multipath Configuration Settings |
Updated The multipath.conf settings for all qualified Linux distributions are now identical so there is only one section for all Linux distributions listed here. The setting dev_loss_tmo infinity requires the additional setting fast_io_fail_tmo to be present in the multipath.conf file – this was omitted previously from the SUSE Linux Enterprise Server requirements; and that the fast_io_fail_tmo value is set to 5 – this was previously set to 30 for Red Hat Enterprise Linux requirements. |
|||||||||||||
| Linux compatibility list |
Added Ubuntu 14.04 LTS has now been qualified with SANsymphony-V 10.x. |
June 2015 | ||||||||||||
| Known Issues |
Added Ubuntu requires manual intervention to redetect failed paths to a DataCore Server. |
|||||||||||||
| Known Issues |
Added All RHEL or SUSE Linux specific ‘known issues’ with SANsymphony-V will now be documented here. |
April 2015 | ||||||||||||
| Linux compatibility lists |
Updated SUSE Linux Enterprise Server 11.0 with Service Pack 3 is now qualified with SANsymphony-V 10.x using ALUA-only settings. |
March 2015 | ||||||||||||
| Linux compatibility lists |
Updated Red Hat Enterprise Linux 7.0 is now qualified with SANsymphony-V 10.x using ALUA-only settings. |
February 2015 | ||||||||||||
| Multipath Configuration Settings – Red Hat Enterprise Linux |
Added Added new entry in the multipath.conf file no_path_retry fail This is required for any Oracle RAC/GFS configured hosts. Hosts using ALUA with the ‘Preferred Server’ setting configured for ALL. |
|||||||||||||
| Linux compatibility lists |
Updated Updated the table for all Red Hat Enterprise Linux and SUSE Linux Enterprise Server Versions Single virtual disks are now always considered supported. |
November 2014 | ||||||||||||
| Linux compatibility lists |
Updated Updated the table for all Red Hat Enterprise Linux Versions 5.0 - 5.10. It was previously listing versions 5.0 – 5.2 only. |
July 2014 | ||||||||||||
| Host Settings |
Added Disk Timeouts – Added an example for use of the cat command to determine the current SCSI Disk Timeout and a note that some versions of Linux may revert to the default settings after a reboot and how to resolve this. |
|||||||||||||
| Linux compatibility lists |
Updated Updated the table for SANsymphony-V 10.x |
June 2014 | ||||||||||||
| Linux compatibility lists |
Added Red Hat Enterprise Linux – 6.5 with ALUA is now qualified for use with SANsymphony-V 9.x |
May 2014 | ||||||||||||
| Appendix A - Reclaiming Storage from Linux hosts |
Added Added information for 'ATA Trim' commands and Automatic Reclamation from disk pools. |
|||||||||||||
| Multipath Configuration Settings |
Updated Red Hat Enterprise Linux only. Added a new Multipath.conf entry requirement - fast_io_fail_tmo - which is required to support the dev_loss_tmo value of ‘infinity’ else the value may default back to 10 minutes instead. NB: Check with your Vendor to make sure your specific Linux Kernel version supports these options. Red Hat Enterprise Linux and SUSE Enterprise Linux DataCore recommends that the Multipath.conf entry path_grouping_policy be ‘group_by_prio’ instead of ‘failover’. NB: The ‘failover’ option is considered unqualified for RHEL version 6.5. Added an optional Multipath.conf entry user_friendly_names which will create simpler, easier to read, disk device names for users to work with. NB: Check with your Vendor to make sure your specific Linux Kernel version supports this option. |
|||||||||||||
| General |
Updated This document combines all of DataCore’s Linux-related information from older Technical Bulletins into a single document including: Technical Bulletin 2a: "‘Other’ Linux hosts" Technical Bulletin 2b: "Redhat Enterprise Linux 6.x hosts" Technical Bulletin 2c: "SUSE Linux Enterprise Server 11.x hosts" Technical Bulletin 8: "Formatting host’s File Systems on virtual disks created from disk pools" Technical Bulletin 11: "Disk Timeout Settings on hosts" Technical Bulletin 16: "Reclaiming Space in disk pools" |
April 2014 | ||||||||||||
| Linux compatibility lists |
Added Added new tables to show which versions are explicitly qualified, unqualified and not supported with either SANsymphony-V 8.x or 9.x, and if the configuration is with or without ALUA enabled hosts. Note that the minimum requirement for SANsymphony-V 8.x is now 8.1 PSP1 Update 4 to guarantee expected behavior for qualified versions of Linux. |
|||||||||||||
| Appendix |
Added Appendix A This section gives more detail on the Preferred Server and Preferred Path settings with regard to how it may affect a host. Appendix B This section incorporates information regarding "Reclaiming Space in disk pools" (from Technical Bulletin 16) that is specific to Linux hosts. |
|||||||||||||
| Host Settings |
Updated Host Settings - SUSE Linux Enterprise Server with/without ALUA enabled. dev_loss_tmo - For SLES 11 SP2 or greater, please make sure that multipath-tools-0.4.9-0.70.72.1 or greater is installed for the ‘infinity’ setting to work properly. Improved explanations to most of the required Host Settings and DataCore Server Settings generally. |