Storage Network Management Cummings I–X 001–105 3/2/04 12:55 PM Page I

Storage Network Management Cummings I–X 001–105 3/2/04 12:55 PM Page I

SNIA TECHNICAL T UTORIAL Storage Network Management Cummings_i–x_001–105 3/2/04 12:55 PM Page i SNIA TECHNICAL T UTORIAL Storage Network Management Cummings_i–x_001–105 3/2/04 12:55 PM Page ii The SNIA Technical Tutorial booklet series provides introductions to storage technology topics for users of storage networks. The content is prepared by teams of SNIA technical experts and is open to review by the entire SNIA membership. Each booklet corresponds with tutorials delivered by instructors at Storage Networking World and other conferences. To learn more about SNIA Technical Tutorials, email [email protected]. Cummings_i–x_001–105 3/2/04 12:55 PM Page iii SNIA TECHNICAL T UTORIAL Storage Network Management Roger Cummings SAN Technologist, VERITAS Software Cummings_i–x_001–105 3/2/04 12:55 PM Page iv Copyright © 2004 Storage Networking Industry Association (SNIA). All rights reserved. The SNIA logo is a trademark of SNIA. This publication—photography, illustration, and text—is protected by copyright and permission should be obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying, recordings, or likewise. To obtain permission(s) to use material from this work, please submit a written request to SNIA, Permissions Department, 301 Rockrimmon Blvd, South, Colorado Springs, CO 80919. For information regarding permissions, call (719) 884-8903. Photography, illustration, and text incorporated into SNIA printed publications are copy- right protected by SNIA or other owners and/or representatives. Downloading, screen cap- turing or copying these items in any manner for any use other than personally viewing the original document in its entirety is prohibited. Notice to Government End Users: SNIA software and documentation are provided with restricted rights. Use, duplication or disclosure by the Government is subject to the restric- tions set forth in FAR 52.227-19 and subparagraph (c)(1)(ii) of Rights in Technical Data and Computer Software clause at DFARS 252.227-7013. Cummings_i–x_001–105 3/2/04 12:55 PM Page v Contents Preface vii About the Author x Chapter 1 Introduction 1 Chapter 2 Definition of Terminology 5 Chapter 3 A Brief History of Management Protocols 13 Chapter 4 An Overview of Current Management Techniques 17 Chapter 5 An Introduction to Web-Based Enterprise Management and SMI-S 21 Chapter 6 Profiles of Storage Network Equipment Types 51 Chapter 7 Available Tools and Development Facilities 83 Chapter 8 Future Developments and Goals 89 Chapter 9 Summary 93 Appendix A Applicable Standards 95 Appendix B Recommended Bibliography 101 Publications 101 Web Sites 102 Cummings_i–x_001–105 3/2/04 12:55 PM Page vi Cummings_i–x_001–105 3/2/04 12:55 PM Page vii Preface Development of the Fibre Channel interface in the early 1990s presaged a major change in computer architecture: the separation of storage peripherals from processing complexes. This change allowed storage capacities to increase almost without limit, regardless of the physical limitations of server cabinets and cable lengths. The impact of this new architecture was not immediately apparent because the new interface still used the Small Computer System Interface (SCSI) command sets that had been used by a predecessor interface for many years, and thus did not require any major operating system changes. The small number of disks in the initial Fibre Channel configurations could be discovered, managed, and configured using exactly the same schemes as for that predecessor interface. As these configurations grew to incorporate hundreds of devices connected by switches, the load placed on the administrators using these schemes became intolerable. With the advent of storage networks, for the first time servers running dis- parate operating systems (for example, Windows and UNIX) could feasibly be connected to the same set of storage resources. Again, this advance required little change in the operating systems themselves, because they continued to be unaware of each other. The systems were not only incapable of sharing stored information, but could destroy information in unrecognized formats. To provide the requisite isolation between noncooperating systems, additional services were introduced into the storage network, together with new features, such as zoning, that restricted the connectivity available to each server. In addition, virtualization began to be widely employed as a mechanism of separating each server’s view of storage from its actual physical configuration in the network. These new features inevitably added considerable complexity to the management of storage networks. Throughout the industry, therefore, new specialist administration groups were formed to manage storage and its infrastructure, which in turn led to the creation of applications specifically tailored to support this task. Such applications, however, proved difficult to develop for two major reasons. First, storage infrastructure is much more fragmented, and of much less end-to- end nature, than a comparable network infrastructure. Although network infra- structure management is complicated by network address translators, storage networks have virtualization devices that provide both address translation and complex processing of the information itself. Additionally, storage networks have bridges that always terminate the SCSI command protocols and may also trans- late between different transport technologies. Both of these classes of device are largely opaque to any management technology. vii Cummings_i–x_001–105 3/2/04 12:55 PM Page viii viii Preface Second, access to and definition of the information required by the applica- tion is very splintered. Information must be obtained from many different sources, using several different technologies and architectures, to build up the pic- ture of how the storage network operates. Many designers of storage network equipment expose management information and controls via a Web server hosted on the equipment itself and accessed via a dedicated “Management LAN” con- nection. Additional information is often accessed from an agent that also runs on the equipment itself using a standard network management scheme such as the Simple Network Management Protocol (SNMP). However, the information returned from such an agent is often unique and does not conform to the mod- els developed for other types of networking equipment. Those models are ori- ented to the report static data structures and simple monotonic data value changes, such as performance counters, rather than the complex state manipula- tions and dynamic changes encountered in many storage applications. Addition- ally, many of the existing schemes have difficulty coping with information sources that constantly change, appear, and disappear, as often happens in a virtualized storage situation. Further, such network management protocols were designed before network security and reliability became paramount, and they do not incor- porate any viable schemes for restricting access to vital control functions. Some storage network equipment also has functions that are only accessible via a command line interface, which is accessed via either telnet or a special- purpose serial interface. Each new type of equipment challenges application designers because of the inconsistent provision of management and control facilities. Many of those facil- ities are designed for direct use by human operators rather than applications, which involves the application in repugnant practices like “screen scraping.” Because information obtained from different devices is not consistently presented or defined, much effort must be dedicated to cross-correlating the information in order to present a true picture of the state of the storage network. This daunting task is subject to largely unpredictable change in the face of equipment firmware changes. Much effort in management application development is consumed in the acquisition and correlation of information from a multivendor storage network. Thus, little time remains to create intelligent high-level functions that will relieve the burden placed on administrators. Any attempt at significant administration simplification, therefore, founders on the diversity of access and inconsistency of information. The need therefore exists for a set of new definitions that will streamline the way the industry manages storage networks. Consistent information provided by every vendor and a single flexible interface are the key requirements. Manage- ment application developers would then no longer have to integrate incompati- ble feature-poor interfaces into their products. Equipment developers would no longer have to push their unique interface functionality at application develop- ers. Instead, both would be better able to concentrate on developing features and functions of value to administrators. With these requirements met, the manage- Cummings_i–x_001–105 3/2/04 12:55 PM Page ix Preface ix ment of network storage will become simpler and cheaper than managing an equivalent amount of storage attached directly to servers. Ultimately, when the reduced costs for management are delivered, end users will be able to build larger more powerful networks and to adopt storage networks more rapidly. The Storage Networking Industry Association (SNIA) is working on defini- tions to meet the above requirements as part of its Storage Management Initia- tive (SMI). SMI is based on the

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    116 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us