host configurhost_configuration_guide_aixation guide aix

Global Leader in Storage Virtualization Software

Host Configuration Guide

IBM AIX

SANsymphony-V

June 2015

Table of contents

Overview 3

Recent changes made to this document 3

List of qualified AIX Versions 4

Notes on qualification 4

AIX 5

DataCore Server Settings 6

AIX 5.2 6

AIX 5.3 6

AIX 6.1 and 7.1 6

Host Settings 9

Applies to any AIX Host 9

Appendix A 11

Notes on the Preferred Server & Preferred Path settings 11

Appendix B 13

Configuring Disk Pools 13

Reclaiming Storage from Disk Pools 13

Previous Changes 15

Page | 3 Host Configuration Guide IBM AIX

Overview This document provides AIX-specific settings when serving Virtual Disks from a DataCore

Server.

Fundamental AIX administration skills are assumed; including how to connect AIX Hosts to

storage array target ports (i.e. DataCore Server Front End ports) using Fibre Channel, along

with the process of discovering, mounting and formatting disk devices in general.

Note: iSCSI connections from AIX are not currently supported

Recent changes made to this document New information added since last update (February 2015)

Added new information:

List of qualified AIX Versions - Notes on qualification

This section has been updated and new information added regarding the definitions of all

qualified, unqualified and not supported labels. A new section on AIX versions that are

no longer in development has also been added at the end of this section.

SANsymphony-V 8.x is now End of Life Please see End of Life Notifications http://datacore.custhelp.com/app/answers/detail/a_id/1329

Previous changes made to this document

Please see page 15


List of qualified AIX Versions

Notes on qualification DataCore Software will always support any SANsymphony-V installation that has a valid

support contract. Even installations that are using Hosts listed as not supported will still

be able to get technical support but we will never guarantee the behavior of a Host

operating system that is listed as not supported if using Mirrored Virtual Disks.

Qualified AIX versions that are listed as qualified are considered fully supported with redundant,

mirrored Virtual Disks as long as all the configuration settings listed in this document, and

that are specific to your AIX versions have been followed.

Unqualified AIX versions that are listed as unqualified have not been tested with SANsymphony-V and

so may not work (i.e. failover or failback) as expected with redundant, mirrored Virtual

Disks; even if all the configuration settings listed in this document, and that are specific to

your AIX version, have been followed.

Unqualified AIX versions can be self-qualified by following the process documented here:

DataCore Component Self-Qualification Process

http://datacore.custhelp.com/app/answers/detail/a_id/1506

Not Supported with Mirrored or Dual Virtual Disks These AIX versions are only supported when using non-mirrored Virtual Disks.

Any Mirrored or Dual Virtual Disk served to a Host operating system indicated as not

supported is done at the users own risk.

Versions that are explicitly marked as not supported can never be self-qualified.


What about other AIX versions? All other AIX versions (i.e. newer) that are not listed in this document are considered as

unqualified for mirrored or dual Virtual Disks when using SANsymphony-V and, just like all

the unqualified versions of AIX that are listed in this document, the behavior with

SANsymphony-V cannot be guaranteed.

These other distributions can also self-qualified by following the same process mentioned

in the previous page.

Non-mirrored Virtual Disks are always supported, even on other distributions.

AIX versions that are no longer in development Support for any AIX versions that is considered End of Life by the vendor or has no active

development/Long Term Support can still be self-qualified but only if there is an agreed

support contract with the supplier/HP.

In this case, DataCore Technical Support will help the customer to get the Host Operating

system accessing Virtual Disks, but will not then do any root-cause analysis.

AIX

The following table shows which specific versions of each version of AIX that are

considered Qualified (), Unqualified (?) or Not Supported with Mirrored or Dual Virtual

Disks (X) with SANsymphony-V 1

Note: iSCSI connections to AIX Hosts are not supported.

SANsymphony-V

Version 9.x Version 10.x

AIX ALUA Non-ALUA ALUA Non-ALUA

5.2 X ?

5.3 X ?

6.1 X ?

7.1 X ?

1 See the section Notes on qualification on page 4 for definitions of Qualified, Unqualified and Not Supported with Mirrored or Dual Virtual Disks


DataCore Server Settings These are the Host-specific settings that need to be configured directly on the DataCore

Server.

See the Registering Hosts section from the SANsymphony-V Help:

http://www.datacore.com/SSV-Webhelp/Hosts.htm

Operating System Type

AIX 5.2

When registering the Host running AIX versions 5.2 with ML9 or earlier, choose the IBM

AIX Native MPIO Legacy entry.

When registering the Host running AIX versions 5.2 with TL10 or greater, choose the IBM

AIX entry.

AIX 5.3

When registering the Host running AIX versions 5.3 with ML5 or earlier, choose the IBM

AIX Native MPIO Legacy entry.

When registering the Host running AIX versions 5.3 with TL6 or greater, choose the IBM

AIX entry.

AIX 6.1 and 7.1

When registering the Host running AIX version 6.1.x, choose the IBM AIX entry.


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 guarantees that any Hosts do not still try to

access FE Ports, for any reason, once the software is stopped.

Any Port with the Mirror and/or Back End role enabled do not shut off when the DataCore

Server software is stopped, but remain active.

Mirrored or Dual Virtual Disks When registering the Host, Multipathing Support should be enabled so that Mirrored

Virtual Disks or Dual Virtual Disks can be served to Hosts from all available DataCore FE

ports.

See the Multipathing Support section from the SANsymphony-V Help:

http://www.datacore.com/SSV-Webhelp/Hosts.htm

Asymmetrical Logical Unit Access (ALUA) support ALUA is not supported for AIX Hosts.

Single Virtual Disks Single Virtual Disks (i.e. that are not mirrored or are not configured as Dual) 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.

Note: Hosts that only have Single Virtual Disks served to them do not need Multipathing

Support enabled unless they have other Mirrored or Dual Virtual Disks served as well.

Serving Virtual Disks to the Hosts for the first time DataCore recommends that before serving Virtual Disks to a Host for the first time to make

sure that access to all FE paths for all DataCore Servers are correctly discovered on the

Host and that from within the SANsymphony-V Management Console the Virtual Disks are

marked Online and up to date and that the storage sources have a host access of Read/Write.


Mappings DataCore recommend that the same Virtual Disk served to more than one Host or Host Port

should use same LUN number for its mapping. While Virtual Disks have their own unique

Network Address Authority (NAA) identifier, DataCore cannot guarantee that this is

enough for a Host Operating System to identify the same Virtual Disk served to different

Paths on the same Host. Using the same LUN often guarantees some sort of consistency for

device identification in these cases.

Also see the SCSI Standard Inquiry Data section from the SANsymphony-V Help:

http://www.datacore.com/SSV-Webhelp/Changing_Virtual_Disk_Settings.htm

Note: The LUN number for Mirror Paths does not need to be the same as the Front End port

mappings (or indeed as other Mirror Path mappings for the same Virtual Disk) as the Host

does not see these.


Host Settings These are the Host-specific settings that need to be configured directly on the Host Server.

Applies to any AIX Host

Install the DataCore Support for AIX MPIO software In order for SANsymphony-V Virtual Disks to be recognized as MPIO-capable disk devices

on AIX, additional software needs to be installed on the Host. Please download and install

the DataCore Support for AIX MPIO software from the DataCore Technical Support website

(a login is required). All installation instructions can be found in the release notes that

come with the software:

DataCore Software Downloads

http://datacore.custhelp.com/app/answers/detail/a_id/1419

Setting Disk Timeouts Once DataCore Virtual Disk(s) have been discovered on the Host, change the Disk

rw_timeout to 60 seconds.

To determine the current rw_timeout value, run the command:

lsattr l hdiskX E

Where X is the number of the DataCore Disk Device (as seen on the AIX Host).

Use the chdev command to change the rw_timeout to 60 (if not already set)

chdev l hdiskX a rw_timeout=60

Where X is the number of the DataCore Disk Device (as seen on the AIX Host).


Configure a dummy LUN AIXs MPIO always requires a healthy LUN 0 to be able to detect and use additional LUNs

served to the same port on the Host. DataCore recommend that a very small, non-mirrored

Virtual Disk be served up to the Host port as a dummy LUN 0 from each DataCore Front

End port to all AIX Host Ports that are intended to be used.

Do not set this dummy LUN as a mirrored Virtual Disk to avoid unnecessary cases where

the DataCore Servers mirror partner will set the local storage source for the Virtual Disk as

down on the AIX Host, thereby preventing potential access or discovery of other LUNs

served to the same Host port. There is no need to write any data to this LUN on the AIX

Host.


Appendix A

Notes on the Preferred Server & Preferred Path settings

See the Preferred Servers and Preferred Paths sections from the SANsymphony-V Help:

http://www.datacore.com/SSV-Webhelp/Port_Connections_and_Paths.htm

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 Hosts own Operating System or Failover Software to determine which

DataCore Server is its preferred server.

With ALUA enabled Note: ALUA is not supported for AIX Hosts so the following is for information only.

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 Servers Paths as Active Non-

Optimized which may (or may not) affect how the Host behaves generally.


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-V 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.

Where there are three or more Servers in a Server Group, and where one or more of these

DataCore Servers shares Mirror Paths between different DataCore Servers then 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 Hosts

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.


Appendix B

Configuring Disk Pools

See Creating Disk Pools and Adding Physical Disks from the SANsymphony-V Help:

http://www.datacore.com/SSV-Webhelp/About_Disk_Pools.htm

The smaller the SAU size, the larger the number of indexes are required, by the Disk Pool

driver, to keep track of the equivalent amount of allocated storage compared to a Disk Pool

with a larger SAU size; e.g. there are potentially four times as many indexes required in a

Disk Pool using a 32MB SAU size compared to one using 128MB the default SAU size.

As SAUs are allocated for the very first time, the Disk Pool needs to update these indexes

and this may cause a slight delay for IO completion and might be noticeable on the Host.

However this will depend on a number of factors such as the speed of the physical disks,

the number of Hosts accessing the Disk Pool and their IO READ/WRITE patterns, the

number of Virtual Disks in the Disk Pool and their corresponding Storage Profiles.

Therefore, DataCore usually recommend using the default SAU size (128MB) as it is a good

compromise between physical storage allocation and IO overhead during the initial SAU

allocation index update. Should a smaller SAU size be preferred, the configuration should

be tested to make sure that a potential increased number of initial SAU allocations does not

impact the overall Host performance.

Reclaiming Storage from Disk Pools

Using SCSI UNMAP / ATA Trim commands As of SANsymphony-V 9.0 PSP4 there is support for ATA Trim commands; however please

refer to your vendors documentation to determine which version of AIX including which

file system type(s) support Trim commands. The SCSI UNMAP feature is not supported

with AIX Hosts on DataCore Servers.

Automatic Reclamation Since SANsymphony-V 9.0 PSP4 the DataCore Server will, in the background, continuously

scan each Physical Disk in a Pool for any SAUs that contain all-zero data which are then

reclaimed back into the Disk Pool. The Automatic Reclamation process runs at a low

priority, so as to not potentially interfere with overall Disk Pool performance, and so will

generally take longer to scan a Physical Disk in a Pool compared to a Manual Reclamation

request (see below). However no user intervention is required.


Manual Reclamation For AIX Hosts that either do not support the fstrim command, or are using Virtual Disks

served from DataCore Servers running SANsymphony-V 9.0 PSP3 update2 or earlier

(including all versions of SANsymphony-V 8.x); a suggestion would be to create a sparse file

of an appropriate size (If there is enough free space available in the file system) and then

zero-fill it using the dd command.

This example will write zeroes within an empty file of 2GB in size (called my_file) using

the dd command:

dd if=/dev/zero of=my_file bs=1024 count=2097152

Then either wait for an Automatic Reclamation to take place or run a Manual Reclamation.

See the Performing Reclamation section from the SANsymphony-V Help:

http://www.datacore.com/SSV-Webhelp/Reclaiming_Virtual_Disk_Space.htm

Note that it is also possible to script manual reclamation using the

Start-DcsVirtualDiskReclamation PowerShell Command.

How much storage will be reclaimed? It is impossible to predict exactly how many Storage Allocation Units (SAUs) will be

reclaimed. For reclamation of an SAU to take place, it must contain only all-zero block data

over the entire SAU else it will remain allocated and this is entirely dependent on how and

where the Host has written its data on the DataCore LUN. For example, if the Host has

written the data in such a way that every allocated SAU contains a small amount of non-

zero block data, even if the total amount of data is significantly less than the total amount of

SAU allocation, then no SAUs can be reclaimed.

It may be possible, in some cases, to use the Host Operating Systems own defragmentation

tools to force the non-zero block data to be moved to a more contiguous pattern, so leaving

the end of the DataCore LUN full of SAUs that no longer have non-zero data on them that

can then be reclaimed. However care should be taken that the act of defragmenting the data

does not itself cause more SAU allocation as the block data is moved around during the re-

organization. DataCore Software can offer no guarantees.


Previous Changes 2015

February 2015

Updated section:

List of qualified AIX Versions

AIX 7.1 is now qualified with SANsymphony-V 10.x using non-ALUA settings.

Note: iSCSI is still not considered qualified at this time; all qualified versions are with Fibre Channel

only.

2014 December 2014

No new technical information has been added but this document now combines all of DataCores AIX-related

information from older Technical Bulletins into a single document including:

Technical Bulletin 6: AIX Hosts

Technical Bulletin 8: Formatting Hosts 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 new information:

Which Distributions are qualified?

Added new tables to show which versions are explicitly qualified, unqualified and not supported with

either SANsymphony-V 8.1 PSP1 Update 4, 9.x and 10.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

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 AIX Hosts.

Updated existing entries:

Host Settings - Improved explanations to most of the required Host Settings and DataCore Server

Settings generally.


2013

Technical Bulletin 6: AIX Hosts

April 2013 Removed all references to SANmelody as this is now End of Life of December 31 2012. Removed all references to iSCSI as this is not supported with AIX. July 2012 Updated for SANsymphony-V 9.x. No new technical information. January 2012 Updated 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 31 2011. June 2011 Added AIX 7.1. November 2011 Removed all references to End of Life SANsymphony and SANmelody versions that are no longer supported as of July 31 2011. October 2011 Added SANsymphony-V 8.x July 2009 Added AIX 6.1.x. March 2009 Initial publication of Technical Bulletin. Added AIX 5.2 TL10

COPYRIGHT

Copyright 2015 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 machine-readable form without the prior written consent of DataCore Software Corporation

host configurhost_configuration_guide_aixation guide aix

Documents

aix hosts

unqualified aix versions

aixspecific settings

host settings

configuration settings

datacore server settings

dual virtual disks

nonmirrored virtual