Pillar Axiom: An Explanation of Non-Optimized Access (NOA) on Axiom Arrays

Asset ID:	1-79-1391479.1
Update Date:	2012-08-27
Keywords:

Solution Type Predictive Self-Healing Sure

Solution 1391479.1 : Pillar Axiom: An Explanation of Non-Optimized Access (NOA) on Axiom Arrays

Applies to:

Pillar Axiom 600 Storage System - Version Not Applicable to Not Applicable [Release N/A]
Pillar Axiom 500 Storage System - Version Not Applicable to Not Applicable [Release N/A]
Pillar Axiom 300 Storage System - Version Not Applicable to Not Applicable [Release N/A]
Information in this document applies to any platform.

Purpose

This article describes the concept of non-optimized access and several symptoms that may be encountered as a result.

Details

There may be times when an end user notes a lot of "Non-optimized Access" entries in the event log. Conversely, the user may notice poor performance on specific SAN LUNs or the entire Axiom and numerous non-optimized access events are noted by the event log.

Explanation

Every LUN on the Axiom has an owning Slammer Control Unit. Inside this Control Unit (CU) is that LUN's cache and access data. Optimized access is taken through the Fibre Channel or iSCSI ports on that CU. If access for a LUN is requested from a port that is not on the owning CU, that is called Non-optimized access (NOA). The request needs to be forwarded to the owning CU, which takes CPU overhead from both CUs and causes an overall lag of the total system. Since the cache is missed, the request is sent to the bricks, increasing traffic load on the back-end Private Interconnect (PI).

Ownership change

After so many non-optimized access requests, the Axiom temporarily moves the ownership of the LUN to the other CU. The code assumes that this is only a temporary access pattern and, after six minutes, moves the LUN back to the original owner.

SCSI Sense Key 06/29/06 (Unit attention, asymmetric access state changed)

Some hosts may print out SCSI errors on their console during a time the Axiom is changing ownership of a LUN. These errors usually have the sense key of 06/29/06, which translates to "Unit attention, asymmetric access state changed." These errors are for any outstanding requests sent to the Axiom while the ownership change is taking place. If the host follows SCSI protocol, the requests will be retried.

Non-APM hosts

SAN hosts running Axiom Path Management (APM) software will automatically detect the optimized path by communicating to the pilot system. However, non-APM hosts, such as VMWare ESX servers, will have to be manually configured.

Using the Axiom Storage Manager GUI, a user can look up the properties of all LUNs experiencing non-optimized access events, making sure you note which Slammer and Control Unit owns the LUN in question. The non-APM host can then be configured to access the correct ports.

For Fibre Channel communications, ports with WWNs beginning with 0x21 (PORT0) and 0x23 (PORT1) belong to CU0. Ports with WWNs beginning with 0x22 (PORT0) and 0x24 (PORT1) belong to CU1.

For iSCSI communications, traffic can be directed by referencing the IP or MAC address of the correct ports.

IMPORTANT: Access from non-APM hosts must be set to an active/passive paradigm. Meaning that only one communication path is used for normal communication and the others are used as failover paths only.

Attachments

This solution has no attachment