Redfish 1.9.1官方规范：2020年现代管理接口

需积分: 0 177 浏览量更新于2024-07-15 收藏 861KB PDF 举报

Redfish Specification DSP0266 第1.9.1版，发布于2020年3月27日，是分布式管理任务组(DMTF)发布的最新开放标准，目标是为现代和安全的平台硬件管理提供一个统一的框架。这个规范以RESTful超媒体接口为基础，采用了数据模型来描述和管理数据中心的各种资源，包括但不限于服务器、BMC(Baseboard Management Controller，基础板管理控制器)以及远程监控功能。该规范的主要特点在于其一致性，使得不同的硬件和软件厂商可以按照相同的接口设计他们的管理系统，从而实现跨平台的互操作性和标准化。1.9.1版本是对1.9.0版本的继承和发展，作为规范性文档，它详细规定了实施步骤和期望的行为，适用于已发布的正式文档。遵循的是DMTF的版权政策，允许非营利组织和个人在注明版本和发布时间的前提下复制和使用这些规格，但需确保正确引用DMTF。值得注意的是，部分Redfish标准元素可能受到第三方专利保护，包括暂定专利权。尽管DMTF不保证用户免受这些权利的影响，也不负责识别或公开任何潜在的专利权所有者，因此在实施时需自行评估潜在的法律风险。在实际应用中，Redfish 1.9.1标准支持的功能包括但不限于： 1. **数据中心资源管理**：提供了一个全面的接口，用于查询、配置和控制服务器、存储、网络等基础设施设备。 2. **事件处理**：通过标准化的方式处理和报告系统事件，帮助运维人员及时发现并解决问题。 3. **长期任务执行**：支持异步任务处理，如定期维护、备份和恢复等，提高管理效率。 4. **发现机制**：允许通过URL访问Redfish服务，自动化发现和连接到网络中的设备，简化了管理过程。 5. **BMC集成**：与IPMI (Intelligent Platform Management Interface) 相结合，提供了更强大的远程管理和监控能力。 Redfish 1.9.1版本是IT领域的重要里程碑，它不仅提升了服务器和数据中心的管理效率，还促进了行业间的合作和标准化，有助于降低技术门槛和维护成本。对于从事IT管理和硬件厂商来说，理解和遵循这一标准是提升产品竞争力和实现兼容性的关键。

Term

Definition

BMC Baseboard management controller

CORS Cross-origin resource sharing

CRUD Create, read, update, and delete

CSRF Cross-Site Request Forgery

HTTP Hypertext Transfer Protocol

HTTPS Hypertext Transfer Protocol over TLS

IP Internet Protocol

IPMI Intelligent Platform Management Interface

JSON JavaScript Object Notation

KVM-IP Keyboard, Video, Mouse redirection over IP

NIC Network interface controller

PCI Peripheral Component Interconnect

PCIe Peripheral Component Interconnect Express

TCP Transmission Control Protocol

XSS Cross-site scripting

5. Overview

Redfish is a management standard that uses a data model representation with a RESTful interface.

Being RESTful, Redfish is easier to use and implement.

Being model-oriented, it can express the relationships between components and the semantics of the

Redfish Services and components within them. The model is also easy to extend.

By requiring JSON representation, Redfish enables easy integration with programming environments. It is

also easy to interpret by humans.

An interoperable Redfish schema defines this model, which is freely available and published in OpenAPI

YAML, OData CSDL, and JSON Schema formats.

Redfish Specification DSP0266

16 Published Version 1.9.1

5.1. Scope

This specification defines the required protocols, data model, behaviors, and other architectural

components for an interoperable, multivendor, remote, and out-of-band capable interface. This interface

meets the cloud-based and web-based IT professionals' expectations for scalable platform management.

While large and hyperscale environments are the primary focus, clients can use the specification for

individual system management.

The specification defines the required elements for all Redfish implementations, and the optional

elements that system vendors and manufacturers can choose. This specification also defines at which

points an implementation can provide OEM-specific extensions.

The specification sets normative requirements for Redfish Services and associated materials, such as

Redfish schema files. In general, the specification does not set requirements for Redfish clients but

indicates what a client should do to successfully and effectively access and use a Redfish Service.

The specification does not require that implementations of the Redfish interfaces and functions require

particular hardware or firmware.

5.2. Goals

As an architecture, data representation, and definition of protocols that enable a client to access Redfish

Services, Redfish has these goals:

Goal Purpose

Scalable Can scale on stand-alone machines or racks of equipment.

Flexible Can implement through existing hardware or entirely as a software service.

Extensible Can easily add new and vendor-specific capabilities to the data model.

Backward-

compatible

Can add capabilities while preserving investments in earlier implementations.

Interoperable Provides consistent functionality across multiple vendor implementations.

Standards-

based

Built on ubiquitous and secure protocols. Leverages other standards where

applicable.

Simple

Easy-to-use without the need for highly specialized programming skills or

systems knowledge.

Lightweight

Designed to reduce complexity and implementation costs. Minimizes the required

footprint for implementations.

DSP0266 Redfish Specification

Version 1.9.1 Published 17

5.3. Design tenets

To deliver these goals, Redfish:

• Provides a RESTful interface by using a JSON payload and a data model.

• Separates the protocol from the data model, which enables the independent revision and use of

each.

• Specifies versioning rules for protocols and schema.

• Leverages strength of ubiquitous standards where it meets architectural requirements, such as

JSON, HTTP, OData, OpenAPI, and the RFCs that this document references.

• Organizes the data model so that it provides clearly demarcated and value-add features in the

same payload as standardized items.

• Makes data in payloads as obvious in context as possible.

• Maintains implementation flexibility. Does not tie the interface to any particular underlying

implementation or architecture.

• Focuses on widely used capabilities. To avoid complexity, does not add functions that only a

small percentage of users value.

5.4. Limitations

Redfish minimizes the need for clients to complete upgrades by using strict versioning and forward-

compatibility rules, and separation of the protocols from the data model. However, Redfish does not

guarantee that clients never need to update their software. For example, clients might need to upgrade to

manage new system or component types, or update the data model.

Interoperable does not mean identical. Many elements of Redfish are optional. Clients should be

prepared to discover the optional elements by using the built-in discovery methods.

The resource tree reflects the topology of the system and its devices. Consequently, different hardware or

device types result in different resource trees, even for identical systems from the same manufacturer.

References between resources may result in a graph instead of a tree. Clients that traverse the resource

tree should provide logic to avoid infinite loops.

Additionally, not all Redfish resources use simple REST read-and-write semantics. Different use cases

may follow other types of client logic. For example, clients cannot simply read user credentials or

certificates from one service and write them to another service.

Finally, the hyperlink values between resources and other elements can vary across implementations.

Clients should not assume that they can reuse hyperlinks across different Redfish Service instances.

Redfish Specification DSP0266

18 Published Version 1.9.1

5.5. Additional design background and rationale

5.5.1. REST-based interface

Redfish exposes many service applications as RESTful interfaces. This document defines a RESTful

interface.

Redfish defines a RESTful interface because it:

• Enables a lightweight implementation, using fewer layers than previous standards.

• Is a prevalent access method in the industry.

• Is easy to learn, document, and implement in modern programming languages.

• Has a number of development environments and a healthy tooling ecosystem.

• Fits with the design goal of simplicity.

• Equally applies to software application space as it does to embedded environments, which

enables convergence and sharing of code within the management ecosystem.

• Adapts well to any data modeling language.

• Has industry-provided security and discovery mechanisms.

5.5.2. Data-oriented

The Redfish data model is developed by focusing on the contents of the payload. By concentrating on the

contents of the payload first, Redfish payloads are easily mapped to schema definition languages and

encoding types. The data model is defined in various schema languages, including OpenAPI YAML,

OData CSDL, and JSON Schema.

5.5.3. Separation of protocol from data model

Redfish separates the protocol operations from the data model and versions the protocol independently

from the data model. This enables clients to extend and change the data model as needed without

requiring the protocol version to change.

5.5.4. Hypermedia API Service Root

Redfish has a single Service Root URI and clients can discover all resources through referenced URIs.

The hypermedia API enables the discovery of resources through hyperlinks.

5.5.5. OpenAPI v3.0 support

The OpenAPI v3.0 provides a rich ecosystem of tools for using RESTful interfaces that meet the design

requirements of that specification. Starting with Redfish Specification v1.6.0, the Redfish schemas

support the OpenAPI YAML file format and URI patterns that conform to the OpenAPI Specification were

defined. Conforming Redfish Services that support the Redfish protocol version v1.6.0 or later implement

DSP0266 Redfish Specification

Version 1.9.1 Published 19

those URI patterns to enable use of the OpenAPI ecosystem.

For details, see OpenAPI Specification v3.0.

5.5.6. OData conventions

With the popularity of RESTful APIs, there are nearly as many RESTful interfaces as there are

applications. While following REST patterns helps promote good practices, due to design differences

between the many RESTful APIs there few common conventions between them.

To provide for interoperability between APIs, OData defines a set of common RESTful conventions and

annotations. Redfish adopts OData conventions for describing schema, URL conventions, and definitions

for typical properties in a JSON payload.

5.6. Service elements

5.6.1. Synchronous and asynchronous operation support

Some operations can take more time than a client typically wants to wait. For this reason, some

operations can be asynchronous at the discretion of the service. The request portion of an asynchronous

operation is no different from the request portion of a synchronous operation.

To determine whether an operation was completed synchronously or asynchronously, clients can review

the HTTP status codes. For more information, see the Asynchronous operations clause.

5.6.2. Eventing mechanism

Redfish enables clients to receive messages outside the normal request and response paradigm. The

service uses these messages, or events, to asynchronously notify the client of a state change or error

condition, usually of a time critical nature.

This specification defines two styles of eventing:

• Push-style eventing.

When the service detects the need to send an event, it calls HTTP POST to push the event

message to the client. Clients can enable reception of events by creating a subscription entry in

the Event Service, or an administrator can create subscriptions as part of the Redfish Service

configuration.

• Server-Sent Events (SSE)-style eventing.

The client opens an SSE connection to the service through a GET on the

ServerSentEventUri-specified URI in the Event Service.

Redfish Specification DSP0266

20 Published Version 1.9.1

剩余181页未读，继续阅读

疯狂java杰尼龟

粉丝: 4w+
资源: 13

Redfish 1.9.1官方规范：2020年现代管理接口

Redfish Specification

redfish协议

H3C HDM Redfish参考手册_V2.17

TMS_RemoteDB_1.9.1_Downloadly.ir.rar

com.msd.professionalchinese_1.9.1_liqucn.com.apk

DeepL Translate_1.9.1_Apkpure.xapk.xapk.1

consul Mac 版本 _consul_1.9.1_darwin_amd64.zip

最新版windows consul_1.9.1_windows_amd64.zip

最新版linux consul_1.9.1_linux_amd64.zip

Python库 | core_composer_app-1.9.1.tar.gz

最新资源