Pillar Axiom 300 Storage System
 
Pillar Axiom 600 Storage System
 
Pillar Axiom 500 Storage System
 

PLA-Support>Sun Systems>DISK>Pillar Axiom>SN-DK: Ax600
 
.Old GCS Categories>Sun Microsystems>Storage - Disk>Pillar Axiom
 

In this Document

Purpose

Details

Applies to:

Purpose

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

Details

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 (or CU for short) 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. 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 (or PI for short).

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 fail-over
paths only.

This solution has no attachment