ANSI INCITS 388.0-2011 Information Technology C Storage Management C Overview.pdf

《ANSI INCITS 388.0-2011 Information Technology C Storage Management C Overview.pdf》由会员分享，可在线阅读，更多相关《ANSI INCITS 388.0-2011 Information Technology C Storage Management C Overview.pdf（42页珍藏版）》请在麦多课文档分享上搜索。

1、American National StandardDeveloped byfor Information Technology Storage Management OverviewINCITS 388.0-2011INCITS 388.0-2011INCITS 388.0-2011Revision and Partition ofINCITS 388-2008American National Standardfor Information Technology Storage Management OverviewSecretariatInformation Technology Ind

2、ustry CouncilApproved February 11. 2011 American National Standards Institute, Inc.AbstractThis specification defines an interface between WBEM-capable clients and servers for the secure, exten-sible, and interoperable management of networked storage.Approval of an American National Standard require

3、s review by ANSI that therequirements for due process, consensus, and other criteria for approval havebeen met by the standards developer.Consensus is established when, in the judgement of the ANSI Board ofStandards Review, substantial agreement has been reached by directly andmaterially affected in

4、terests. Substantial agreement means much more thana simple majority, but not necessarily unanimity. Consensus requires that allviews and objections be considered, and that a concerted effort be madetowards their resolution.The use of American National Standards is completely voluntary; theirexisten

5、ce does not in any respect preclude anyone, whether he has approvedthe standards or not, from manufacturing, marketing, purchasing, or usingproducts, processes, or procedures not conforming to the standards.The American National Standards Institute does not develop standards andwill in no circumstan

6、ces give an interpretation of any American NationalStandard. Moreover, no person shall have the right or authority to issue aninterpretation of an American National Standard in the name of the AmericanNational Standards Institute. Requests for interpretations should beaddressed to the secretariat or

7、 sponsor whose name appears on the titlepage of this standard.CAUTION NOTICE: This American National Standard may be revised orwithdrawn at any time. The procedures of the American National StandardsInstitute require that action be taken periodically to reaffirm, revise, orwithdraw this standard. Pu

8、rchasers of American National Standards mayreceive current information on all standards by calling or writing the AmericanNational Standards Institute.American National StandardPublished byAmerican National Standards Institute, Inc.25 West 43rd Street, New York, NY 10036Copyright 2011 by Information

9、 Technology Industry Council (ITI)All rights reserved.No part of this publication may be reproduced in anyform, in an electronic retrieval system or otherwise,without prior written permission of ITI, 1101 K Street NW, Suite 610 Washington, DC 20005. Printed in the United States of AmericaCAUTION: Th

10、e developers of this standard have requested that holders of patents that may be re-quired for the implementation of the standard disclose such patents to the publisher. However, nei-ther the developers nor the publisher have undertaken a patent search in order to identify which, ifany, patents may

11、apply to this standard. As of the date of publication of this standard, followingcalls for the identification of patents that may be required for the implementation of the standard,notice of one or more such claims has been received. By publication of this standard, no positionis taken with respect

12、to the validity of this claim or of any rights in connection therewith. The knownpatent holder(s) has (have), however, filed a statement of willingness to grant a license underthese rights on reasonable and nondiscriminatory terms and conditions to applicants desiring to ob-tain such a license. Deta

13、ils may be obtained from the publisher. No further patent search is con-ducted by the developer or publisher in respect to any standard it processes. No representation ismade or implied that this is the only license that may be required to avoid infringement in the use ofthis standard.iContentsForew

14、ord. ivIntroduction to Overview Part v1. Scope .12. Normative References32.1 Approved references 32.2 References under development. 32.3 Other references 33. Terms and definitions 54. Typographical Conventions 74.1 Experimental Maturity Level. 74.2 Implemented Maturity Level. 74.3 Stable Maturity Le

15、vel 84.4 Finalized Maturity Level . 84.5 Deprecated Material. 85. Introduction.115.1 Preamble 115.2 Business Rationale 115.3 Interface Definition . 115.4 Technology Trends 145.5 Management Environment. 155.6 Architectural Objectives . 165.7 Disclaimer 176. Overview196.1 Base Capabilities . 197. Func

16、tionality Matrix237.1 Capabilities of This Version 258. Operational Environment.298.1 General 298.2 Using this Specification 308.3 Language Bindings 31iiList of TablesTable 1. Functionality Matrix.23iiiList of FiguresFigure 1. Experimental Maturity Level Tag 7Figure 2. Implemented Maturity Level Tag

17、. 7Figure 3. Stable Maturity Level Tag . 8Figure 4. Deprecated Tag 9Figure 5. Interface Functions . 12Figure 6. Large SAN Topology. 15Figure 7. Example Client Server Distribution in a SAN 16Figure 8. Object Model/Server Relationship 20Figure 9. Canonical Inheritance . 21Figure 10. Sample CIM-XML Mes

18、sage 22Figure 11. Operational Environment 30iv(This foreword is not part of American National Standard INCITS 388-2011.)ForewordThis Technical Specification defines a method for the interoperable management of aheterogeneous Storage Area Network (SAN), describes the information available to aWBEM Cl

19、ient from an SMI-S compliant CIM Server and an object-oriented, XML-based,messaging-based interface designed to support the specific requirements of managingdevices in and through Storage Area Networks (SANs).This document is intended for use by individuals and companies engaged in developing,deploy

20、ing, and promoting interoperable multi-vendor SANs through the SNIA organiza-tion.The information contained in this publication is subject to change without notice. TheSNIA makes no warranty of any kind with regard to this specification, including, but notlimited to, the implied warranties of mercha

21、ntability and fitness for a particular purpose.The SNIA shall not be liable for errors contained herein or for incidental or consequentialdamages in connection with the furnishing, performance, or use of this specification.This standard contains annexes. Those labeled Informative are not considered

22、part ofthis standard. Those labeled Normative are part of this standard.Requests for interpretation, suggestions for improvement and addenda, or defect reportsare welcome. They should be sent to the INCITS Secretariat, InterNational Committeefor Information Technology Standards, c/o ITI, 1101 K Stre

23、et, NW, Suite 610, Washing-ton, DC 20005. This standard was processed and approved for submittal to ANSI by the InterNationalCommittee for Information Technology Standards (INCITS). Committee approval of thestandard does not necessarily imply that all committee members voted for its approval.At the

24、time it approved this standard, INCITS had the following members:Don Wright, ChairJennifer Garner, SecretaryOrganization Represented Name of RepresentativeAdobe Systems, Inc. Scott FosheeSteve Zilles (Alt.)AIM Global, Inc. Dan MullenCharles Biss (Alt.)Apple Computer, Inc. Kwok LauHelene Workman (Alt

25、.)David Singer (Alt.)Distributed Managment Task Force . John CrandallJeff Hilland (Alt.)Electronic Industries Alliance . Edward Mikoski, Jr.Henry Cuschieri (Alt.)EMC Corporation Gary RobinsonFarance, Inc. Frank FaranceTimothy Schoechle (Alt.)GS1 US Ray DelnickiFrank Sharkey (Alt.)James Chronowski (A

26、lt.)Mary Wilson (Alt.)Hewlett-Packard Company. Karen HigginbottomPaul Jeran (Alt.)vOrganization Represented Name of RepresentativeIBM Corporation Gerald LaneRobert Weir (Alt.)Arnaud Le Hors (Alt.)Debra Borland (Alt.)Steve Holbrook (Alt.)IEEE Bill AshJodie Haasz (Alt.)Bob Labelle (Alt.)Intel .Philip

27、WennblomGrace Wei (Alt.)Stephen Balogh (Alt.)Lexmark InternationalDon WrightDwight Lewis (Alt.)Paul Menard (Alt.)Jerry Thrasher (Alt.)Microsoft CorporationJim HughesDick Brackney (Alt.)John Calhoun (Alt.)National Institute of Standards Accelerate customer acquisition of new storage management techno

28、logy; Expand the total market.Additionally, a single common management interface allows SAN vendors and integrators to decrease the timerequired to bring new more functional technology, products, and solutions to market.5.3 Interface DefinitionThis management interface allows storage management syst

29、ems to reliably identify, classify, monitor, and controlphysical and logical resources in a storage system. The fundamental relationship of this interface to storageINCITS 388.0-2011 Introduction12management software, presentation frameworks, user applications, SAN physical entities (i.e., devices),

30、 SANdiscovery systems, and SAN logical entities is illustrated in Figure 5.Figure 5 illustrates that functions of the interface can be distributed across multiple devices (i.e., Switches or ArrayControllers) and/or software systems (i.e., Discovery Systems). While the functionality of the interface

31、is distributedwithin or across a storage environment, to insure that monitoring and control operations by clients are consistentand reliable, the state of a given resource is not certain to be valid if it is simultaneously available to clients frommultiple unsynchronized sources. EXAMPLE: A request

32、by an SRM application and a backup engine for the bandwidth available on agiven Fibre Channel path should be coordinated by a single monitoring entity to insureinformation consistency. If the SRM application and Backup engine obtain different availablebandwidth information for a given Fibre Channel

33、path from multiple unsynchronized sourcesthey could function in conflict and degrade the efficiency of the environment. Addressing this concern is the responsibility of parties configuring Storage and Network management clients thatrely on the primitives defined in the specification.Note: Within thi

34、s architecture (as depicted by Figure 5) entities like an appliance-based volume manager maypotentially act as both a client and a server to the interface.EXAMPLE: A Host-based volume manager wants to construct a large storage pool from multiple SANappliance based volumes, as well as volumes/LUNs or

35、iginating from array controllers. In thisFigure 5 - Interface FunctionsSMI-S InterfaceObjectsApplication FrameworkLULU CloneLU SnapshotOtherPortHostZoneEnclosureGraphical InterfaceCardMedia RobotDisk DriveHBAMgmt ApplianceExtenderTape Virtual VolumeImplementationRAIDsetRemovable Media SetFabricRoute

36、rArraySwitchPerformance Capacity PlanningResource AllocationCommand InterfaceMedia ManagementVolume ManagementFile System Backup SystemDatabase SystemData Migration (HSM)OtherIntroduction INCITS 388.0-201113case, the host based volume manager needs to inspect the characteristics of the volumes onbot

37、h the SAN appliance and array controller prior to allocation. Additionally, the SANappliance (which runs a volume manager) needs to inspect the properties of storage deviceswhen building its volumes. As such, the SAN appliance in this case is both a client and serverin the management environment, de

38、pending on the action being performed. Figure 5 includes a number of strategic functional requirements for the interface. These capabilities will beintroduced to the interface implementation over time, and may not be present in this version of the interface. Thefunctionalities required to fully sati

39、sfy the needs of clients using a storage management interface include:a) Clients need to be able to obtain sufficient information to discern the topology of the SAN or complex storage system;b) Clients need to be able to reliably identify resources that have experienced an error/fault condition that

40、 has resulted in degraded/disabled operation;c) Clients need to be able to construct a zone of allocation around a select group of host and storage resources;d) Clients need to be able to identify nonvolatile storage resources available to a storage management sys-tem, to allow them to construct a s

41、torage pool of a consistent level of performance and availability;e) Clients need to be able to identify third-party copy engines (and associated media libraries/robots) avail-able to a cooperating backup engine, allowing it to allocate an engine/library/robot to a given backup task;f) Clients need

42、to be able to dynamically allocate non-volatile storage resources;g) Each volume to be utilized is subject to strict availability and performance requirements. As a result, the file system needs to inspect the properties of each volume prior to allocation.h) Clients need to be able to access suffici

43、ent topology and component information to allow a Storage Resource Management (SRM) application like a performance monitor to examine topology and line utili-zation, such that performance bottlenecks can be exposed and capacity planning performed;i) Clients need to be able to employ appropriate data

44、 reporting and tracking to allow capacity planning sys-tem to identify each storage pool in the SAN and then interact with the manager of each pool to assess utilization statistics;j) Clients need to be provided with adequate controls for a privileged, user-written application to restrict the use of

45、 a volume to a specific host, set of hosts, or set of controller communications ports;k) Clients need to be assured of timely propagation of data concerning the health and performance of the devices and subsystems in the SAN to fault isolation and analysis systems.Example non-goals for this interfac

46、e include:a) The ability to select a logical communications port over which to send/receive data;b) The ability to read or write data to a volume;c) The ability to identify and recover from data communications errors and failures;d) The ability to log a new communications device into a network.INCIT

47、S 388.0-2011 Introduction145.4 Technology TrendsTo be broadly embraced and long lived this management interface should respect and leverage key technologytrends evolving within the industry. These include:a) Improved Connectivity: Whether available In-band (i.e., over Fibre Channel/iSCSI) or availab

48、le out-of-band (i.e., over a LAN/MAN/WAN), or available over a mix of both, virtually all devices in a storage man-agement environment have (or soon will have), access to a common communications transport suitable for carrying management information content (e.g., TCP/IP), that is used to transmit a

49、 standardized encoding (e.g., a WBEM Protocol) of recognized semantics (e.g., CIM);b) Increased Device Manageability: Through a common, general-purpose network transport, provide the option to provide proxy services to provide access to (e.g., general purpose computer system) devices via this standardized management interface;EXAMPLE: A legacy array controller is incapable of running the software necessary toimplement a management server for this interface and uses a proxy server on aSAN appliance to communicate within the management environment. EXAMPLE: An HBA is incapable of runnin