SES-2 : Peer enclosure services processes with common managed elements

Fore, Chris Chris_Fore at adaptec.com
Tue Jan 31 10:56:25 PST 2006


* From the T10 Reflector (t10 at t10.org), posted by:
* "Fore, Chris" <Chris_Fore at adaptec.com>
*
In follow-up to our SES-2 peer ES questions from last week (see thread below): 

Suppose there is an application client that has visibility to a pair of peer Enclosure Services (ES) processes in single enclosure (as shown in Figure 2 of 03-347r1).  Does SES-2 provide a standard mechanism that such an application client could use to distinguish between cases (A), (B), and (C) below?  In other words, can peer ES processes explicitly identify shared and common elements? 

We have arrived at a handful of ad hoc methods that could be used (sometimes in combination with application-specific knowledge) for specific types of elements, but have not been able to identify any provisions in the standard to address this as a general case.

Application Example 1: Consider figure 2 and case (B), where each ES process reports and manages a disjoint element set composed of 1 cooling and 4 device elements in the same primary subenclosure (same NAA identifier).
Is it possible for an application client, which is connected redundantly to both SCSI target ports of the enclosure, to identify uniquely the total number of elements by analyzing the configuration pages of each ES?  
If yes, how would the configuration pages have to differ for both ES processes?

Application Example 2: How would the configuration pages differ in another case where both ES processes would report and manage 2 cooling elements and 8 device elements in common for same subenclosure (case A)?

- Chris 
:: R. Chris Fore
:: Principal Engineer - Storage Systems Architecture 
:: Adaptec, Research Triangle Park, NC 
:: (919) 287-2024 

-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Elliott, Robert (Server Storage)
Sent: Wednesday, January 25, 2006 2:28 PM
To: t10 at t10.org
Subject: RE: SES-2 : Peer enclosure services processes with common managed elements 

* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert (Server Storage)" <Elliott at hp.com>
*

> -----Original Message-----
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf 
> Of Fore, Chris
> Sent: Wednesday, January 25, 2006 9:05 AM
> To: t10 at t10.org
> Subject: SES-2 : Peer enclosure services processes with 
> common managed elements 
> 
> We have some questions regarding the application of SES-2 to 
> peer Enclosure Services (ES) processes. 
> 
> For this discussion, we refer to Figure 2 from T10 document 
> 03-347r1 ("SES-2 Reporting peer enclosure service 
> processes").  This figure is accompanied by the following 
> explanatory text (excepted here for reference convenience): 
> 
>    "Figure 2 shows multiple enclosure service processes. Both 
>    return the same enclosure serial number, etc. in the 
>    Configuration diagnostic page. They might each have the ability 
>    to manage the full enclosure or just part of it (this can be 
>    determined by examing which elements they manage)."
> 
> The peer ES processes shown in figure 2 might have the 
> following relationships with respect to managed elements: 
> A) Both ES processes manage the same elements. 
> B) Each ES process manages a disjoint set of elements (no 
> elements in common). 
> C) The ES processes manage overlapping sets of elements (some 
> common elements, some unique). 
> 
> QUESTION ONE: Are all three of these relationships permitted 
> by the standard? 

Yes, but A) and C) will each have difficulties with some of
the element types.

For example, if they share a Cooling element, and one requests
a fan speed of 111b and the other requests 001b, what speed
should the fan run at?

The Enclosure Services Controller Electronics element's SELECT
ELEMENT bit can be used to select an enclosure services process
as the "active" one.  This might be used to choose one of
the processes as the owner of any shared elements, letting the
other control them only if the active one fails - either
detected by the enclosure services processes themselves or
selected by software setting the SELECT ELEMENT bit to one
in the non-active one.

If one is not favored over the other, then perhaps the last
one to update an element gets what it requests.  Some
bits might make sense ORed or ANDed together.  This approach
seems unpredictable.


> QUESTION TWO: Assuming for the moment that case (C) above is 
> permitted, then which of the following implementation 
> alternatives are consistent with the standard? 
> 
> ALTERNATIVE ONE: Each ES process reports multiple 
> subenclosures, with the common elements in the primary 
> subenclosure and the unique elements in distinct subenclosures.
> 
> ALTERNATIVE TWO: Each ES process reports a single 
> subenclosure which contains all the elements that it manages.

I think of subenclosures more as complete enclosures that just
happen to be accessed via a primary subenclosure, rather than
as parts of the same enclosure.  This leads to alternative two.

Alternative 1 is subject to delivering a unique NAA identifier for 
each subenclosure in the Configuration diagnostic page ENCLOSURE
LOGICAL IDENTIFIER field, which seems unlikely.

> Thanks in advance, 
> 
> :: R. Chris Fore
> :: Adaptec, Research Triangle Park, NC 
> 
--
Rob Elliott, elliott at hp.com
Hewlett-Packard Industry Standard Server Storage Advanced Technology
https://ecardfile.com/id/RobElliott
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org

*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org





More information about the T10 mailing list