The Host Server. Linux Configuration Guide. August The authority on real-time data

Transcription

1 The Host Server Linux Configuration Guide August 2018 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 The authority on real-time data

2 Table of contents Changes made to this document 3 Compatibility lists 4 Oracle VM Server for x86 RedHat Enterprise Linux 4 5 SUSE Linux Enterprise Server Ubuntu 6 7 All other Linux distributions SCSI UNMAP support 8 8 SAP HANA Qualified vs. Not Qualified vs. Not Supported 9 10 The DataCore Server's settings 11 Operating System Type 11 Port roles 11 Multipathing 11 ALUA support 11 Serving Virtual Disks 11 The Linux Host's settings 13 Operating system settings 13 Multipath configuration settings 14 Known issues 17 Formatting Virtual Disks 17 Redetecting paths to Virtual Disks 18 Appendix A 19 Preferred Server & Preferred Path settings 19 Appendix B 21 Reclaiming storage from Disk Pools 21 Previous changes 23

3 Changes made to this document The most recent version of this document is available from here: All changes since May 2018 Added Compatibility lists Added SCSI UNMAP compatibility table Known Issues - 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. See the section Evacuating a DataCore Server from the online help: 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. For previous changes made to this document please see page 23 Page 3

4 Linux compatibility lists Compatibility lists Oracle VM Server for x86 SANsymphony 9.0 PSP 4 Update 4 (1) SANsymphony 10.0 (all versions) Version WITH ALUA WITHOUT ALUA WITH ALUA WITHOUT ALUA 3.3 and earlier Not Supported Not Qualified Not Supported Not Supported 3.4.x Not Supported Not Supported Not Qualified Qualified (2) Notes: Qualified vs. Not Qualified vs. Not Supported See page 10 for definitions. DataCore Server Front-End Port connections Only Fibre Channel Front-End connections are supported. 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. 1 Earlier versions are End of Life. See: 2 SANsymphony 10.0 PSP 6 or greater with Fibre Channel connections only. ISCSI is considered not qualified. Page 4

5 Linux compatibility lists RedHat Enterprise Linux SANsymphony 9.0 PSP 4 Update 4 (1) SANsymphony 10.0 (all versions) Version WITH ALUA WITHOUT ALUA WITH ALUA WITHOUT ALUA 5.10 and earlier Not Supported Not Supported Not Supported Not Supported Qualified Qualified Not Qualified Not Qualified Not Qualified Not Qualified Qualified Not Qualified Not Supported Not Supported Not Qualified Not Qualified 7.0 Not Supported Not Supported Qualified Not Qualified 7.1 Not Supported Not Supported Not Qualified Not Qualified Not Supported Not Supported Qualified (2) Not Qualified Notes: Qualified vs. Not Qualified vs. Not Supported See the page 10 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. 1 Earlier versions are End of Life. See: 2 Qualified with SANsymphony version 10.0 PSP 6 or greater; earlier versions are 'Not Qualified'. Page 5

6 Linux compatibility lists SUSE Linux Enterprise Server SANsymphony 9.0 PSP 4 Update 4 (1) SANsymphony 10.0 (all versions) Version WITH ALUA WITHOUT ALUA WITH ALUA WITHOUT ALUA 10.x and earlier Not Supported Not Supported Not Supported Not Supported 11.0 Not Supported Qualified Not Supported Not Supported 11.0 SP 1 Not Supported Not Supported Not Supported Not Supported 11.0 SP 2 Qualified Qualified Not Qualified Not Qualified 11.0 SP 3 Not Qualified Not Qualified Qualified Not Qualified 11.0 SP 4 Not Supported Not Supported Qualified (2) Not Qualified 12.0 Not Supported Not Supported Not Qualified Not Qualified 12.0 SP 1 Not Supported Not Supported Qualified (2) Not Qualified 12.0 SP 2-3 Not Supported Not Supported Not Qualified Not Qualified Notes: Qualified vs. Not Qualified vs. Not Supported See the page 10 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 iscsi connections are 'Not qualified'. Multipath Tools For SLES 12.x use version 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. 1 Earlier versions are End of Life. See: 2 Fibre Channel only iscsi FE connections are still considered 'Not Qualified'. Page 6

7 Linux compatibility lists Ubuntu SANsymphony 9.0 PSP 4 Update 4 (1) SANsymphony 10.0 (all versions) Version WITH ALUA WITHOUT ALUA WITH ALUA WITHOUT ALUA 13.x and earlier Not Supported Not Qualified Not Supported Not Supported LTS Not Supported Not Qualified Not Supported Qualified Not Supported Not Qualified Not Supported Not Supported 15.x Not Supported Not Supported Not Supported Not Qualified LTS Not Supported Not Supported Not Qualified Qualified Not Supported Not Supported Not Qualified Not Qualified 17.x Not Supported Not Supported Not Qualified Not Qualified 18.x Not Supported Not Supported Not Qualified Not Qualified Notes: Applies to Linux distribution provided by Canonical Ltd. Debian (and distributions based on Ubuntu) are considered Other Linux distributions, see the next page. Qualified vs. Not Qualified vs. Not Supported See the page 10 for definitions. DataCore Server Front-End Port connections Fibre Channel and iscsi connections are both supported. Multipath Tools Use Multipath Tools version git1.656f8865 or later. Earlier versions are considered 'Not Qualified'. SCSI UNMAP SCSI UNMAP is supported. 1 Earlier versions are End of Life. See: Page 7

8 Linux compatibility lists All other Linux distributions SANsymphony 9.0 PSP 4 Update 4 (1) SANsymphony 10.0 (all versions) WITH ALUA WITHOUT ALUA WITH ALUA WITHOUT ALUA Not Supported Not Supported Not Qualified Not Qualified Notes: Qualified vs. Not Qualified vs. Not Supported See the page 10 for definitions. SCSI UNMAP support SANsymphony 9.0 PSP 4 Update 4 (1) SANsymphony 10.0 (all versions) Distribution Oracle VM x86 Tested/Works Tested/Works RHEL Tested/Works Tested/Works SLES Does not work Does not work Ubuntu Not Tested Not Tested Notes: SANsymphony 9.0 PSP 4 or greater only Earlier versions of SANsymphony will ignore UNMAP requests. 1 Earlier versions are End of Life. See: Page 8

9 Linux compatibility lists SAP HANA SANsymphony versions Distribution 9.0 PSP 4 update 4 (1) 10.0 PSP 2 or earlier 10.0 PSP 3 or later Oracle VM x86 Not Certified Not Certified Not Certified RHEL Not Certified Not Certified Not Certified SLES Not Certified Not Certified Certified Ubuntu Not Certified Not Certified Not Certified Notes: Please refer to SANsymphony with SAP HANA - Sizing Guidelines for more information: 1 Earlier versions are End of Life. See: Page 9

10 Linux compatibility lists 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 Disks 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 Disks 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 Disks 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 Disks types are configured at the users own risk. Self-qualification is not possible. Mirrored or Dual Virtual Disks 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. 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'. Page 10

11 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 used for serving Virtual Disks to Hosts should only have the Front End (FE) role enabled. Mixing other Port Role types may cause unexpected results as Ports that only have the FE role enabled will be turned off when the DataCore Server software is stopped (even if the physical server remains running). This helps to guarantee that any Hosts do not still try to access FE Ports, for any reason, once the DataCore Software is stopped but where the DataCore Server remains running. Any Port with the Mirror and/or Back End role enabled do not shut off when the DataCore Server software is stopped but still remain active. 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. Also see the Multipathing Support section from the SANsymphony Help: WebHelp/Hosts.htm 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 Please refer to your distribution s Compatibility Lists on pages 4-8. 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. Page 11

12 The DataCore Server's settings 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. Also See Registering Hosts Changing Virtual Disk Settings - SCSI Standard Inquiry Video: Configuring Linux Hosts to use DataCore Virtual Disks Page 12

13 The Linux Host's settings Operating system settings SCSI Disk Timeout Using the echo command Set the SCSI Disk timeout value to 80 seconds: echo 80 > /sys/block/[disk_device]/device/timeout The timeout can be verified using the cat command cat /sys/block/sda/device/timeout Notes This setting will be lost on the next reboot. DataCore recommend configuring a custom udev rule (see next). Using a custom udev rule Example: /etc/udev/rules.d/99-datacore.rules ACTION=="add", SUBSYSTEM=="block", ATTRS{vendor}=="DataCore", ATTRS{model}=="Virtual Disk ", RUN+="/bin/sh -c 'echo 80 > /sys/block/%k/device/timeout'" Notes For Oracle VM x86, RHEL and Ubuntu users, please refer to their own documentation on how to configure a custom udev rule. For SLES users please see: This KB article applies to all versions of SANsymphony (not just 'SANsymphony-V 9'). Page 13

14 The Linux Host's settings Multipath configuration settings The 'defaults' section Add/Modify the polling_interval to a value of 60 (seconds). defaults { polling_interval 60 } This is a DataCore-required value that manages how often the Host checks for access on a previously failed Virtual Disk. A smaller setting will interfere with Host performance. Notes Do not add this parameter to the 'device' section of the multipath configuration file as the setting will not work as expected. The blacklist exceptions section blacklist_exceptions { vendor product } "DataCore" "Virtual Disk" Notes By default all new Virtual Disks created in SANsymphony versions 8, 9 and 10 will use the vendor and product strings DataCore and Virtual Disk listed above. Virtual Disks that were originally created using the older DataCore SANsymphony 7 or SANmelody products will have different vendor and product values so a new, additional device section will need to be added to the multipath configuration file to work with those Virtual Disks, all other settings will remain the same, only the vendor and product strings will change. See the section SCSI Standard Inquiry from the online help: Page 14

15 The Linux Host's settings The 'device' section ALUA enabled device { } vendor "DataCore" product "Virtual Disk" failback 10 path_checker tur prio alua no_path_retry fail dev_loss_tmo infinity 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 fast_io_fail_tmo 5 # user_friendly_names yes Notes All of the entries listed in the configuration settings are DataCore-required values. vendor / product By default all new Virtual Disks created in SANsymphony versions 8, 9 and 10 will use the vendor and product strings DataCore and Virtual Disk listed above. Virtual Disks that were originally created using the older DataCore SANsymphony 7 or SANmelody products will have different vendor and product values so a new, additional device section will need to be added to the multipath configuration file to work with those Virtual Disks, all other settings will remain the same, only the vendor and product strings will change. See the section SCSI Standard Inquiry from the online help: Page 15

16 The Linux Host's 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 above. 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 (N.B. this setting is Not Qualified on RHEL 6.5 and greater) See page 19 for more information regarding the preferred server settings. prio (applies to ALUA enabled Hosts only) Use the value indicated above. No other value should be used. no_path_retry Use the value indicated above. No other value should be used. dev_loss_tmo / fast_io_fail_tmo Older kernels might not recognize infinity as a value and a syslog error may be posted. Then a default value - usually 600 seconds - will be applied instead. fast_io_fail_tmo is required when using the infinity setting for dev_loss_tmo. Use the cat command to verify that any DataCore Virtual Disks detected by the Linux Host are using the infinity value correctly. Example (note: indicates an infinity setting) sleshost3:~ # cat /sys/class/fc_remote_ports/rport-*\:*-*/dev_loss_tmo rr_min_io_rq / rr_min_io (applies to ALUA enabled Hosts only) Use the rr_min_io_rq setting for Linux Kernels and later. Use the rr_min_io setting for Linux Kernels and earlier. 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 an alias instead. Page 16

17 Known issues The following is intended to make DataCore Software customers aware of any issues that may affect performance, access or generally give unexpected results under certain conditions when Linux Hosts are used with SANsymphony. Some of the issues here have been found during DataCore s own testing but many others are issues reported by DataCore Software customers, where a specific problem had been identified and then subsequently resolved. DataCore cannot be held responsible for incorrect information regarding Linux products. No assumption should be made that DataCore has direct communication with any of the Linux vendors regarding the issues listed here and we always recommend that users contact their own Linux vendor directly to see if there are any updates or fixes since they were reported to us. For Known issues for DataCore s own Software 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 mkfs command sends additional UNMAP commands during the format process, resulting in longer format times. Ubuntu has not been tested with SCSI UNMAP so is at this time considered unqualified for SCSI UNMAP operations. Disable the discard command during formatting. Refer to your own man page to be sure your installation supports this option. 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. Page 17

18 Known issues 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. See the section Evacuating a DataCore Server from the online help: 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. Page 18

19 Appendix A Preferred Server & 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 Nonoptimized 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. Also see Preferred Servers and Preferred Paths from: Page 19

20 Appendix A - Preferred Server & Preferred Path settings In the case where the Preferred Server is set to All, then both 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 has to 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 acknowledgement 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. So 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. So 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. Page 20

21 Appendix 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 see next. 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 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. Page 21

22 Appendix B - Reclaiming storage from Disk Pools 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 page 4 to see if your distribution of Linux will work with SANsymphony s SCSI UNMAP support. Also see The Linux man-pages project fstrim - mount - RedHat s Storage Administration Guide 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 my_file Then use the dd command to write 'all-zero' I/O. dd if=/dev/zero of=my_file bs=1024 count= This I/O will then be detected by SANsymphony's Automatic Reclamation function (see previous page for more details). Also see Auto-reclamation of unused SAUs Reclaiming Unused Virtual Disk Space in Disk Pools: Page 22

23 Previous changes May 2018 Compatibility lists - Red Hat Enterprise Linux Ubuntu 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). Added Compatibility lists - Red Hat Enterprise Linux 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 This document has been reviewed for SANsymphony 10.0 PSP 7. No additional settings or configurations are required. February 2018 Removed Appendix B Configuring Disk Pools 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'. October 2017 Added Compatibility lists 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). Compatibility lists RHEL This version is 'Not Supported' for SANsymphony V 9.x and earlier and 'Not Qualified' for SANsymphony versions 10.x August 2017 RHEL 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'). Page 23

24 Previous changes Compatibility lists RHEL This version is now qualified for SANsymphony 10.0 PSP 6 and greater when using ALUA May 2017 April 2017 Compatibility lists 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'. Removed SAP HANA certified configuration settings. The information has been moved to the 'SANsymphony with SAP HANA - Sizing Guidelines' document: February 2017 The Linux Host's settings Operating system settings Disk Timeouts 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. Added Linux compatibility list Oracle VM Server Version 3.4 has now been qualified with SANsymphony-V 10.0 PSP 6 or greater. January 2017 Added The DataCore Server's settings Added link: Video: Configuring Linux Hosts to use DataCore Virtual Disks December 2017 Appendix C - Reclaiming storage Automatic and Manual reclamation These two sections have been re-written with more detailed explanations and technical notes. November 2017 October 2017 Linux compatibility lists 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' Page 24

25 Previous changes This document has been reviewed for SANsymphony 10.0 PSP 5. No other updates were required. July 2017 Added Linux compatibility list Red Hat Enterprise Linux Versions Red Hat Enterprise Linux Versions SUSE Linux Enterprise Server 12 (no Service Pack) and 12 Service Pack 1 April 2017 January 2017 Linux compatibility list Red Hat Enterprise Linux Version 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. November Added Linux Applications SAP HANA This includes an example of a 3-node SAP HANA configuration and earlier SANsymphony-V 8.x and all versions of SANsymphony 9.x before PSP4 Update 4 are now End of Life. Please see: End of Life Notifications September Added Linux Applications SAP HANA A new section has been added with settings specific to SAP HANA. Linux compatibility list SUSE Linux Enterprise Server 11.0 Service Pack 3 using ALUA are certified with SAP HANA versions SPS09 and SPS10. Multipath Configuration Settings 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. June Added Linux compatibility list Ubuntu LTS has now been qualified with SANsymphony-V 10.x. Known Issues Ubuntu requires manual intervention to redetect failed paths to a DataCore Server. April Added Page 25

26 Previous changes Known Issues All RHEL or SUSE Linux specific known issues with SANsymphony-V will now be documented here. March Linux compatibility lists SUSE Linux Enterprise Server 11.0 with Service Pack 3 is now qualified with SANsymphony-V 10.x using ALUA-only settings. February Linux compatibility lists Red Hat Enterprise Linux 7.0 is now qualified with SANsymphony-V 10.x using ALUA-only settings. Multipath Configuration Settings Red Hat Enterprise Linux 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 November Linux compatibility lists the table for all Red Hat Enterprise Linux and SUSE Linux Enterprise Server Versions Single Virtual Disks are now always considered supported. July Linux compatibility lists the table for all Red Hat Enterprise Linux Versions It was previously listing versions only. Host Settings 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. June Linux compatibility lists the table for SANsymphony-V 10.x May Added Linux compatibility lists Red Hat Enterprise Linux 6.5 with ALUA is now qualified for use with SANsymphony-V 9.x Appendix A - Reclaiming Storage from Linux Hosts Added information for 'ATA Trim' commands and Automatic Reclamation from Disk Pools. Multipath Configuration Settings 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. Page 26

27 Previous changes April 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" Added Linux compatibility lists 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 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 - SUSE Linux Enterprise Server with/without ALUA enabled dev_loss_tmo - For SLES 11 SP2 or greater, please make sure that multipath-tools 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 and earlier Technical Bulletin 2a: " Other Linux Hosts" July 2013 Removed all references to SANmelody as this is now End of Life as of December Completely updated what is considered qualified, not qualified and not supported in this document. January 2013 the section for the multipath.conf sections specifically for the polling_interval line. July 2012 Added SANsymphony-V 9.x. the Notes section for the multipath.conf sections specifically for the getuid_callout line. May 2012 DataCore Server and Host minimum requirements. Removed all references to End of Life SANsymphony and SANmelody versions that are no longer supported as of December the configuration settings and entries for /etc/multipath.conf (with additional values and explanations) for all DataCore products. Users should re-check their existing configurations and make any appropriate changes. Removed all (out of date) step-by-step instructions on how to manage and configure/format disk devices on the Host. March 2011 Added SANsymphony-V December 2009 Initial Publication Technical Bulletin 2b: "Redhat Enterprise Linux 6.x Hosts" July 2013 Removed all references to RHEL version 5.3 as this were never tested with ALUA-enabled hosts and so may cause confusion. Please use Technical Bulletin 2a for this earlier version. This Bulletin is now only for RHEL versions 6.x. Host Requirements. Added additional information in the Notes section of the multipath.conf section. Page 27

28 Previous changes June 2013 Improved blacklist_exceptions example for multipath.conf. April 2013 Removed all references to SANmelody as this is now End of Life as of December settings for multipath.conf including additional settings and explanations. March 2013 RHEL versions 6.0, 6.1, 6.2 and 6.3 explicitly stated. January 2013 the section for the multipath.conf sections specifically for the polling_interval line. This was previously stated to go in the devices. This was incorrect, and should be added to defaults section instead. Technical Bulletin 2c: "SUSE Linux Enterprise Server 11.x Hosts" July 2013 This Bulletin is now only for SLES versions 11.x. Host Requirements. Completely updated what is considered qualified, not qualified and not supported in this document. Added additional information in the Notes section of the multipath.conf section. June 2013 Improved blacklist_exceptions example for multipath.conf. April 2013 Removed all references to SANmelody as this is now End of Life as of December settings for multipath.conf including additional settings and explanations. February 2013 Added notes for SLES 11 SP2; including an additional multipath.conf setting. that SLES 11 SP1 is no longer supported as this was found not work correctly in all failure conditions. Users on SLES 11 SP1 should update to SP2. January 2013 the section for the multipath.conf sections specifically for the polling_interval line. This was previously stated to go in the devices. This was incorrect, and should be added to defaults section instead. Page 28

29 The authority on real-time data Copyright 2018 by DataCore Software Corporation. All rights reserved. DataCore, the DataCore logo and SANsymphony are trademarks of DataCore Software Corporation. Other DataCore product or service names or logos referenced herein are trademarks of DataCore Software Corporation. All other products, services and company names mentioned herein may be trademarks of their respective owners. ALTHOUGH THE MATERIAL PRESENTED IN THIS DOCUMENT IS BELIEVED TO BE ACCURATE, IT IS PROVIDED AS IS AND USERS MUST TAKE ALL RESPONSIBILITY FOR THE USE OR APPLICATION OF THE PRODUCTS DESCRIBED AND THE INFORMATION CONTAINED IN THIS DOCUMENT. NEITHER DATACORE NOR ITS SUPPLIERS MAKE ANY EXPRESS OR IMPLIED REPRESENTATION, WARRANTY OR ENDORSEMENT REGARDING, AND SHALL HAVE NO LIABILITY FOR, THE USE OR APPLICATION OF ANY DATACORE OR THIRD PARTY PRODUCTS OR THE OTHER INFORMATION REFERRED TO IN THIS DOCUMENT. ALL SUCH WARRANTIES (INCLUDING ANY IMPLIED WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT, FITNESS FOR A PARTICULAR PURPOSE AND AGAINST HIDDEN DEFECTS) AND LIABILITY ARE HEREBY DISCLAIMED TO THE FULLEST EXTENT PERMITTED BY LAW. No part of this document may be copied, reproduced, translated or reduced to any electronic medium or machinereadable form without the prior written consent of DataCore Software Corporation