GB/T 36450.1-2026Information technology - Storage management - Part 1: Overview (English PDF)

1 Scope 1

2 Normative References 1

3 Terms, Definitions, and Abbreviations 1

4 Storage Management Overview 1

4.1 Introduction 1

4.2 Business Principles 2

4.4 Technological Trends 3

4.5 Management Environment 4

Introduction

0.1 Explanation of the text structure of GB/T 36450 GB/T 36450 "Information Technology Storage Management" is a recommended standard to guide the standardization of storage management in my country, aiming to unify...

The standard management interface solves the problems of interoperability of products from multiple vendors and the management of distributed storage systems that are cross-regional and multifunctional.

GB/T 36450 "Information Technology Storage Management" is based on ISO/IEC 24775 and is planned to consist of eight parts.

---Part 1: Overview. This section aims to provide a high-level introduction to key concepts, which is essential for understanding GB/T 36450 "Information Technology".

This forms an important foundation for the detailed content of the "Technology Storage Management" standard.

---Part 2: General Architecture. The aim is to establish a general transmission model to facilitate communication of management information between various components of the management system.

The document provides information and outlines the design rules for this general transmission model, as well as the roles and responsibilities of each component in using the model.

---Part 3: General Outline. The aim is to establish a unified solution for storage management across multiple autonomous management profiles.

Other system configuration files are also supported.

---Part 4: Block Devices. The purpose is to establish configuration interfaces for the security, scalability, and interoperability of storage management systems.

The interface supports the management of devices and subsystems in different environments through object-oriented, XML-based, and information-transfer protocol design.

System requirements.

---Part 5: File System. The purpose is to establish autonomous management configuration files for programs and devices, and to provide support for file data.

The core functional requirements for holding and accessing.

---Part 6: Switching Architecture. The aim is to establish the autonomous management configuration files for the programs and devices that support storage networking.

Requirements.

Document requirements.

---Part 8: Media Library. The purpose is to establish specific requirements for modeling media library objects for monitoring.

0.2 Format Conventions in addition to informative and normative content, this document also provides guidance on the maturity level of some emerging technologies. These emerging technologies...

Although the technical content has passed rigorous design review, its application in commercial products is still insufficient. This type of content is already covered in GB/T 36450.

Some of them are marked.

In terms of its structure, this document outlines the normative requirements for all parts of GB/T 36450, as well as its iterative implementation and deployment.

Lifecycle. The goal of this document is to ensure that all content presents a mature and stable design, validated through extensive engineering implementation.

Continued support for backward compatibility is provided, but only for technologies of equivalent maturity. Unless otherwise defined in this document.

A specific sub-maturity level; otherwise, all items are assumed to meet the above requirements and are collectively referred to as "completed." Given that the content under development is still...

For items not reaching this maturity level, Parts 2 to 8 of GB/T 36450 define three maturity levels to indicate the maturity of each item.

Key characteristics of a project's gradual maturation and stabilization process. Each maturity level is based on the degree of accumulated experience in project implementation.

The maturity level is defined by its own stability and its dependence on other emerging standards. Each maturity level also uses its own proprietary formatting.

The marking rules are used to clearly distinguish content at different maturity stages.

Experimental maturity level. This document only contains technical content where the initial architecture has been completed and passed design review.

Some of the technical content has been designed and reviewed, but implementation experience and the maturity gained through implementation are lacking. This type of content...

The content is included in this document to gain broader review and implementation experience. This material will be marked as "experimental." this document is intended to be helpful to implementers interested in the future development of storage management standards. The contents of this "experimental" outline document may change as needed.

The product will change based on accumulated experience. It's highly likely that any changes will be included in newer versions of this document. Once implemented, experimental...

The formatting conventions for experimental content are shown in Figure 1.

Figure 1.Legend of experimental maturity level labels

Implementation maturity level. Outline files that have completed initial implementation are categorized as "implemented". This indicates that there are at least two distinct supplies.

The provider has implemented the outline file, including at least one provider implementation. At this maturity level, there is a stable underlying architecture and modeling process.

Future version changes will be limited to correcting defects discovered through further implementation experience. If this material becomes obsolete in the future, it will be removed from subsequent implementations.

Before deleting it in the current version, this material should be discarded when making minor modifications to this document.

The format conventions for the implemented content are shown in Figure 2.

Figure 2.Legend of implemented maturity level labels

Stable maturity level. Once content at an implementation maturity level has gained more implementation experience, it can be marked as stable.

A defined maturity level. Materials at this maturity level have been produced by three different suppliers, including one provider and one customer.

If materials that have reached this maturity level are outdated, they can be discarded when making minor modifications to this document. At this maturity level...

Levels and obsolete materials can only be deleted when major changes are made to this document. Minor modifications to this document will result in...

In the next version, backward compatibility of profile files reaching this maturity level must be ensured. Therefore, those at or above a stable maturity level...

The profile file should not rely on any content at an experimental maturity level.

The formatting conventions for stable content are shown in Figure 3.

Figure 3.Legend of stable maturity level labels

Completed maturity level. Content that has reached the highest maturity level is called "completed." This includes content that meets the requirements of the stable maturity level.

Furthermore, content at the completion level should only rely on materials that have reached the completion level or their refinements. If the specification content depends on materials not subject to this level of maturity...

Materials controlled by documents are therefore not bound by their maturity level definitions. If materials that have reached this maturity level become obsolete, they can be reclassified under this document.

Compatibility. In short, it is hoped that all content in this document will reach this maturity level. Therefore, for this maturity level, there is no [specific requirement] as for other sub-levels.

Specific formatting conventions for maturity levels. For the content of this document, if a formatting convention specific to a sub-maturity level is not used...

If a mark is made according to the convention, it should be assumed that it has reached the completion level of maturity.

Discarded Materials. Experimental materials that can be discarded will not be included in subsequent revisions of this document. Sections marked "Discarded" contain...

The material is outdated and its use in new development work is not recommended. Existing and new implementations may still use the material, but should be discontinued as soon as possible.

A new approach is adopted. How long recently deprecated materials remain in the standard depends on their maturity level. "Implemented" content must at least maintain...

"Stable" and "complete" material should be retained until the next major revision of this document. Deprecated.

Any material that is still present in this document should be implemented by the provider to ensure backward compatibility. Clients may depend on deprecated materials.

While providing information, it encourages the use of non-abandoned alternatives where possible.

The deprecated clauses are arranged by citing the content of the previous version, and these deprecated clauses are incorporated as normative material into the current standard as replacements.

In the terms and conditions.

The formatting conventions for deprecated content are shown in Figure 4.

Figure 4.Legend of abandoned maturity level labels

Information Technology Storage Management Part 1: Overview

1 Scope

This document defines a secure, scalable, and interoperable management interface for distributed heterogeneous storage systems. This interface adopts an object-oriented approach.

An XML-based messaging protocol to support the specific needs of device and subsystem management in such storage environments.

This document applies to the design, implementation, and verification of management interfaces in distributed heterogeneous storage systems, as well as related storage devices and subsystems.

Management and integration.

The contents of the following documents, through normative references within the text, constitute essential provisions of this document. Dated citations are not included.

For references to documents, only the version corresponding to that date applies to this document; for undated references, the latest version (including all amendments) applies.

This document.

GB/T 36450.2-2021 Information technology storage management—Part 2: General architecture (ISO/IEC 24775-2:2021) MOD) Note. The content referenced in GB/T 36450.2-2021 has no technical differences from the content referenced in ISO/IEC 24775-2:2014.

3.Terms, Definitions and Abbreviations the terms, definitions and abbreviations defined in GB/T 36450.2-2021 apply to this document.

4.Storage Management Overview

4.1 Introduction

Large-scale storage systems and storage area networks have become important and independent information technology infrastructures in enterprise and medium-sized computing environments.

Applications and functional examples that drive the emergence of new storage technologies include.

---Sharing massive storage resources across multiple systems via a network;

---No LAN backup;

---Remote disaster recovery and online mirroring of critical mission data;

---Fault-tolerant applications and related system clusters centered around a single data replica;

---Archiving requirements for sensitive business information;

---Distributed databases and file systems.

To accelerate the rollout of more feature-rich and complex storage systems, the industry needs a standardized management interface that enables multi-vendor systems to operate seamlessly.

The purpose of this initiative is to develop a unified specification for SMI-S, thereby providing definitions for interfaces. This document can be complex and potentially widely distributed.

This article provides heterogeneous, feature-rich, reliable, and secure monitoring capabilities for critical global resources in multi-vendor storage topologies (such as SANs).

The defined interface overcomes the shortcomings of traditional management systems, which have hindered users from adopting more advanced storage management systems.