Category: SNIA Swordfish

SNIA Volunteer Work Wins Recognition at Flash Memory Summit

kristin.hauser
SNIA thanks and celebrates the many hardworking SNIA member volunteers whose technical work was awarded Best of Show at the recent Flash Memory Summit.

Jennifer Dietz and Eden Kim accept FMS award from Jay Kramer

SNIA won the FMS Most Innovative Flash Memory Technology Award, recognizing innovations that will change the way flash memory works and is used in products, for the SNIA Technical Position Real World Storage Workloads Performance Test Specification (RWSW PTS), developed by the SNIA Solid State Storage Technical Work Group (SSS TWG). “Real World Workloads are important for Data Center, IT, and Storage professionals,” said Eden Kim, Chair of the SSS TWG, and CEO of SNIA member company Calypso Systems “because real world workloads are very different from synthetic lab workloads and are key determinants in datacenter server and storage performance, optimization and qualification.”   Eden and Jennifer Dietz of SNIA member company Intel and Co-Chair of the SNIA Solid State Storage Initiative Marketing Committee accepted the award from Jay Kramer of Flash Memory Summit.

Mark Carlson and Bill Martin accept award on behalf of SNIA from Jay Kramer

SNIA also won the FMS Best of show Technology Innovation Award, recognizing that cloud and other large data centers typically prioritize their selection criteria for storage solutions as those that can achieve the highest possible performance while avoiding proprietary vendor lock-in.  SNIA and EXTEN HyperDynamic™ NVMe over Fabrics high-performance storage software were recognized for creating an open storage management specification that works with EXTEN storage software for being the first in the industry to provide a solution based on SNIA Swordfish™ and DMTF Redfish® specifications. “We congratulate EXTEN Technologies for its innovation and well-deserved accolade,” said Don Deel, SNIA Storage Management Initiative Governing Board Chair. “By integrating SNIA Swordfish into its solution, EXTEN Technologies’ customers will benefit from a standards-based API that does not require learning the intricacies of storage infrastructure to handle day-to-day storage needs.” Accepting the award for SNIA at FMS were Mark Carlson of SNIA member company Toshiba Memory Systems and Bill Miller of SNIA member company Samsung Electronics, Co-Chairs of the SNIA Technical Council. Congratulations to all the SNIA volunteers who participated in the development of these award-winning specifications. SNIA Sessions at FMS Now Available for Viewing and Download Read More

SNIA Swordfish™ – Your Questions Answered

Diane Marsili

The Storage Networking Industry Association’s (SNIA’s) Storage Management Initiative (SMI) took on the topic of SNIA Swordfish™ in a live webcast titled “Introduction to SNIA Swordfish™ – Scalable Storage Management.” The replay is available here. SNIA experts Richelle Ahlvers and Don Deel, responded to questions during the webcast. Here are those questions and responses:

Q. You talked about two different ways to add storage to Redfish – hosted service configuration and integrated service configuration. When would you use one configuration instead of the other?

A. The integrated services configuration was added to clarify support with direct attach configurations using Swordfish constructs. If you have a server that has a RAID card in it, and you want to have it use a more complex storage configuration – storage pools and some notion of class of service, you would use the integrated service configuration. The hosted service configuration is used to model non-direct attach configurations, such as external storage arrays, or file services.

Q. Another service configuration question. For a pure JBOD, which would be the preferred approach?

A. A JBOD configuration configuration could start with either configuration depending on whether it is a standalone system (HSC) or server-attached. If the JBOD has an embedded controller in an enclosure, it could be modeled using the HSC configuration.

Q. Are there provisions for adding custom data in the payloads that Swordfish support. Is there a method to add vendor specific parameters in the payload?

A. Previous standards did not have a good model for adding OEM specific data.

As a result, Redfish, and its extensions such as Swordfish, have ensured that there is a very clean place to add OEM data. Every schema supports OEM extensions in two places. There are OEM extensions for properties and also for OEM actions – a way to support functions that don’t map to REST.

Q. Is there any work related to NVMe over Fabric in development?

A. Both SNIA and the Distributed Management Task Force (DMTF – which developed Redfish) have been working on this. The DMTF’s Redfish Forum developed the base model for SAS/SATA and PCIe fabrics, which is being extended to include NVMe over Fabric. SNIA is also working on adding NVMe over Fabric device connections to their basic models to integrate the storage elements.

Q. I think of Redfish as talking to the Baseboard Management Controller (BMC). Where is Swordfish functionality located? Is it on the CPU running the OS or is it also out of band?

A. Where Swordfish is running will be determined by the implementation. An implementation can choose to run either in band or out of band. In most cases this will be consistent with implementations. If a vendor’s existing architecture supports out of band management, then their Swordfish implementation will also likely be out of band. Note that the Swordfish implementation may leverage existing Redfish instrumentation on integrated components in either case, but this is a completely vendor-specific choice.

Q. What is meant by endpoint?

A. Endpoints are an abstraction of a connection. They describe the connections without needing to define everything about the underlying hardware.

Q. Since JBODs fall within the domain of server hardware, can software RAID solutions take full advantage of Swordfish?

A. The software RAID solutions can absolutely take full advantage of Swordfish. Remember that Swordfish is a schema extension to Redfish for storage functionality; therefore, it doesn’t care what underlying hardware it is running on. Note that many different types of storage solutions today run on “server hardware” – SDS solutions, for example, have no custom hardware, and fall exclusively in this domain, yet are clearly storage solutions.

Q. Is Swordfish planning on staying an extension to Redfish? Does it have a goal of being integrated into Redfish specification at some point?

A. Yes, Swordfish plans to remain an extension to Redfish. There isn’t a reason to integrate it into Redfish, as it is already tightly coupled with Redfish; the schema are delivered publicly on the same site. The SNIA will continue to own Swordfish content separately from DMTF in order to take advantage of the focused attention of the large body of storage domain experts in SNIA. In order to allow the Redfish ecosystem to grow to its maximum potential as quickly as possible, DMTF is partnering with other organizations to add features such as storage and networking to the standard.

Q. Do you have to be a SNIA member to contribute to the open source work?

A. No. You do not have to be a SNIA member to contribute to the open source projects. You will, however, need to sign the SNIA Contributor License Agreement, available at snia.org/cla in order to release any contributions you make to the open source projects to SNIA to allow us to incorporate them back into the open source projects.

Q. Going through the specs for Redfish /Swordfish, I can see that only a few parameters of the schema are really mandatory to be supported by the vendor. Does that not break functionality where a client would be expecting data as per the entire schema?

A. The SSM TWG is working on the development of feature profiles, which will help clarify which functionality is required to be implemented for specific clients, applications, and use cases. In addition to the functionality requirements in the Swordfish specification, the profile definitions will help clarify to both clients and service implementations much more clearly what functionality is required to implement for their specific configurations.

Additional information on SNIA Swordfish is available at: www.snia.org/swordfish. This site contains resources including the latest specification, a Swordfish User Guide, a Swordfish Practical Guide, Swordfish mockups and more.

You can also join the Redfish Specification Forum to ask and answer questions about Swordfish!

SNIA Swordfish™ – Your Questions Answered

Diane Marsili

The Storage Networking Industry Association’s (SNIA’s) Storage Management Initiative (SMI) took on the topic of SNIA Swordfish™ in a live webcast titled “Introduction to SNIA Swordfish™ – Scalable Storage Management.” The replay is available here. SNIA experts Richelle Ahlvers and Don Deel, responded to questions during the webcast. Here are those questions and responses:

Q. You talked about two different ways to add storage to Redfish – hosted service configuration and integrated service configuration. When would you use one configuration instead of the other?

A. The integrated services configuration was added to clarify support with direct attach configurations using Swordfish constructs. If you have a server that has a RAID card in it, and you want to have it use a more complex storage configuration – storage pools and some notion of class of service, you would use the integrated service configuration. The hosted service configuration is used to model non-direct attach configurations, such as external storage arrays, or file services.

Q. Another service configuration question. For a pure JBOD, which would be the preferred approach?

A. A JBOD configuration configuration could start with either configuration depending on whether it is a standalone system (HSC) or server-attached. If the JBOD has an embedded controller in an enclosure, it could be modeled using the HSC configuration.

Q. Are there provisions for adding custom data in the payloads that Swordfish support. Is there a method to add vendor specific parameters in the payload?

A. Previous standards did not have a good model for adding OEM specific data.

As a result, Redfish, and its extensions such as Swordfish, have ensured that there is a very clean place to add OEM data. Every schema supports OEM extensions in two places. There are OEM extensions for properties and also for OEM actions – a way to support functions that don’t map to REST.

Q. Is there any work related to NVMe over Fabric in development?

A. Both SNIA and the Distributed Management Task Force (DMTF – which developed Redfish) have been working on this. The DMTF’s Redfish Forum developed the base model for SAS/SATA and PCIe fabrics, which is being extended to include NVMe over Fabric. SNIA is also working on adding NVMe over Fabric device connections to their basic models to integrate the storage elements.

Q. I think of Redfish as talking to the Baseboard Management Controller (BMC). Where is Swordfish functionality located? Is it on the CPU running the OS or is it also out of band?

A. Where Swordfish is running will be determined by the implementation. An implementation can choose to run either in band or out of band. In most cases this will be consistent with implementations. If a vendor’s existing architecture supports out of band management, then their Swordfish implementation will also likely be out of band. Note that the Swordfish implementation may leverage existing Redfish instrumentation on integrated components in either case, but this is a completely vendor-specific choice.

Q. What is meant by endpoint?

A. Endpoints are an abstraction of a connection. They describe the connections without needing to define everything about the underlying hardware.

Q. Since JBODs fall within the domain of server hardware, can software RAID solutions take full advantage of Swordfish?

A. The software RAID solutions can absolutely take full advantage of Swordfish. Remember that Swordfish is a schema extension to Redfish for storage functionality; therefore, it doesn’t care what underlying hardware it is running on. Note that many different types of storage solutions today run on “server hardware” – SDS solutions, for example, have no custom hardware, and fall exclusively in this domain, yet are clearly storage solutions.

Q. Is Swordfish planning on staying an extension to Redfish? Does it have a goal of being integrated into Redfish specification at some point?

A. Yes, Swordfish plans to remain an extension to Redfish. There isn’t a reason to integrate it into Redfish, as it is already tightly coupled with Redfish; the schema are delivered publicly on the same site. The SNIA will continue to own Swordfish content separately from DMTF in order to take advantage of the focused attention of the large body of storage domain experts in SNIA. In order to allow the Redfish ecosystem to grow to its maximum potential as quickly as possible, DMTF is partnering with other organizations to add features such as storage and networking to the standard.

Q. Do you have to be a SNIA member to contribute to the open source work?

A. No. You do not have to be a SNIA member to contribute to the open source projects. You will, however, need to sign the SNIA Contributor License Agreement, available at snia.org/cla in order to release any contributions you make to the open source projects to SNIA to allow us to incorporate them back into the open source projects.

Q. Going through the specs for Redfish /Swordfish, I can see that only a few parameters of the schema are really mandatory to be supported by the vendor. Does that not break functionality where a client would be expecting data as per the entire schema?

A. The SSM TWG is working on the development of feature profiles, which will help clarify which functionality is required to be implemented for specific clients, applications, and use cases. In addition to the functionality requirements in the Swordfish specification, the profile definitions will help clarify to both clients and service implementations much more clearly what functionality is required to implement for their specific configurations.

Additional information on SNIA Swordfish is available at: www.snia.org/swordfish. This site contains resources including the latest specification, a Swordfish User Guide, a Swordfish Practical Guide, Swordfish mockups and more.

You can also join the Redfish Specification Forum to ask and answer questions about Swordfish!

SNIA Swordfish™ – Your Questions Answered

Diane Marsili Leave a comment

The Storage Networking Industry Association’s (SNIA’s) Storage Management Initiative (SMI) took on the topic of SNIA Swordfish™ in a live webcast titled “Introduction to SNIA Swordfish™ – Scalable Storage Management.” The replay is available here. SNIA experts Richelle Ahlvers and Don Deel, responded to questions during the webcast. Here are those questions and responses:

Q. You talked about two different ways to add storage to Redfish – hosted service configuration and integrated service configuration. When would you use one configuration instead of the other?

A. The integrated services configuration was added to clarify support with direct attach configurations using Swordfish constructs. If you have a server that has a RAID card in it, and you want to have it use a more complex storage configuration – storage pools and some notion of class of service, you would use the integrated service configuration. The hosted service configuration is used to model non-direct attach configurations, such as external storage arrays, or file services. Read More

A Q&A on Storage Management – These Folks Weren’t Too Proud to Ask!

J Metz
The most recent installment of our SNIA ESF webcast series “Everything You Wanted To Know About Storage But Were Too Proud To Ask” took on a broad topic – storage management. Our experts, Richelle Ahlvers, Mark Rogov and Alex McDonald did a great job explaining the basics and have now answered the questions that attendees asked here in this blog. If you missed the live webcast, check it out on-demand and download a copy of the slides if you’d like to take notes. Read More

Too Proud to Ask Webcast Series Opens Pandora’s Box – Storage Management

J Metz
Storage can be something of a “black box,” a monolithic entity that is at once mysterious and scary. That’s why we created “The Everything You Wanted To Know About Storage But Were Too Proud to Ask” webcast series. So far, we’ve explored various and sundry aspects of storage, focusing on “the naming of the parts.” Our goal has been to break down some of the components of storage and explain how they fit into the greater whole. On September 28th, we’ll be hosting “Everything You Wanted To Know About Storage But Were Too Proud To Ask – Part Cyan – Storage Management.” This time, we’re going to open up Pandora’s Box and peer inside the world of storage management, uncovering some of the key technologies that are used to manage devices, storage traffic, and storage architectures. In particular, we’ll be discussing: Read More

Managing Your Computing Ecosystem Part Two

khauser Leave a comment

by George Ericson, Distinguished Engineer, Dell EMC; Member,
SNIA Scalable Storage Management Technical Working Group,
@GEricson

 

Introduction

This blog is part two of a three-part series by George Ericson, a distinguished engineer at Dell EMC. If you missed part one, you can read it here. George is an active participant on the SNIA Scalable Storage Management Technical Working Group which has been developing the SNIA Swordfish™ storage management specification. Read More

Managing Your Computing Ecosystem Part Two

Kristen Hauser

by George Ericson, Distinguished Engineer, Dell EMC; Member,
SNIA Scalable Storage Management Technical Working Group,
@GEricson

 

Introduction

This blog is part two of a three-part series by George Ericson, a distinguished engineer at Dell EMC. If you missed part one, you can read it here. George is an active participant on the SNIA Scalable Storage Management Technical Working Group which has been developing the SNIA Swordfish™ storage management specification.

SNIA Swordfish is designed to integrate with the technologies used in cloud data center environments and can be used to accomplish a broad range of storage management tasks from the simple to the advanced. SNIA is holding the very first Swordfish plugfest June 13-15 in the SNIA Technology Center in Colorado Springs.

Overview

We are making strides toward universal and interoperable management interfaces. These are not only interfaces that will interoperate across one vendor or one part of the stack, but management interfaces that can truly integrate your infrastructure management. Last time, we discussed OData, the Rest standardization. This time we will talk about Redfish for managing hardware platforms.

DMTF’s Redfish®

Redfish defines a simple and secure, OData conformant data service for managing scalable hardware platforms. Redfish is defined by a set of open industry standard specifications that are developed by the Distributed Management Task Force, Inc. (DMTF).

The initial development was from the point of view of a Baseboard Management Controller (BMC) or equivalent. Redfish management currently covers bare-metal discovery, configuration, monitoring, and management of all common hardware components. It is capable of managing and updating installed software, including for the operating system and for device drivers.

Redfish is not limited to low-level hardware/firmware management. It is also expected to be deployed to manage higher level functionality, including configuration and management of containers and virtual systems.   In collaboration with the IETF, Redfish is also being extended to include management of networks.

The Redfish Scalable Platforms Management API Specification specifies functionality that can be divided into three areas: OData extensions, utility interfaces, and platform management interfaces. These are described briefly in the following sections.

Redfish OData extensions

Redfish requires at least OData v4 and specifies some additional constraints:

  • Use of HTTP v1.1 is required, with support for POST, GET, PATCH, and DELETE operations, including requirements on many HTTP headers
  • JSON representations are required within payloads
  • Several well-known URIs are specified
    • /redfish/v1/ returns the ServiceRoot resource for locating resources
    • /redfish/v1/OData/ returns the OData service document for locating resources
    • /redfish/v1/$metadata returns the OData metadata document for locating the entity data model declarations.

Redfish also extends the OData metamodel with an additional vocabulary for annotating model declarations. The annotations specify information about, or behaviors of the modeled resources.

Redfish utility interfaces

The utility interfaces provide functionality that is useful for any management domain (for example, these interfaces are used by Swordfish for storage management). These interfaces include account, event, log, session, and task management.

The account service manages access to a Redfish service via a manager accounts and roles.

The event service provides the means to specify events and to subscribe to indications when a defined event occurs on a specified set of resources. Each subscription specifies where indications are sent, this can be to a listening service or to an internal resource, (e.g. a log service).

Each log service manages a collection of event records, including size and replacement policies. Resources may have multiple log services for different purposes.

The session service manages sessions and enables creation of an X-Auth-Token representing a session used to access the Redfish service.

The task service manages tasks that represent independent threads of execution known to the redfish service. Typically tasks are spawned as a result of a long running operation.

The update service provides management of firmware and software resources, including the ability to update those resources.

Redfish platform management interfaces

The principal resources managed by a Redfish service are chassis, computer systems and fabrics. Each resource has its current status. Additionally, each type of resource may have references to other resources, properties defining the current state of the resource, and additional actions as necessary.

Each chassis represents a physical or logical container. It may represent a sheet-metal confined space like a rack, sled, shelf, or module. Or, it may represent a logical space like a row, pod, or computer room zone.

Each computer system represents a computing system and its software-visible resources such as memory, processors and other devices that can be accessed from that system. The computer system can be general purpose system or can be a specialized system like a storage server or a switch.

Each fabric represents a collection of zones, switches and related endpoints. A zone is a collection of involved switches and contained endpoints. A switch provides connectivity between a set of endpoints.

All other subsystems are represented as resources that are linked via one or more of these principal resources. These subsystems include: bios, drives, endpoints, fans, memories, PCIe devices, ports, power, sensors, processors and various types of networking interfaces.

Conclusion

Redfish delivers a standardized management interface for hardware resources. While it is beginning with basic functionality like discovery, configuration and monitoring, it will deliver much more. It will extend into both richer services and cover more than physical resources – e.g. virtual systems, containers, and networks. Redfish is built as an OData conformant service, which makes it the second connected part of an integrated management API stack. Next up – Swordfish.

Managing Your Computing Ecosystem Part Two

Kristen Hauser

by George Ericson, Distinguished Engineer, Dell EMC; Member,
SNIA Scalable Storage Management Technical Working Group,
@GEricson

 

Introduction

This blog is part two of a three-part series by George Ericson, a distinguished engineer at Dell EMC. If you missed part one, you can read it here. George is an active participant on the SNIA Scalable Storage Management Technical Working Group which has been developing the SNIA Swordfish™ storage management specification.

SNIA Swordfish is designed to integrate with the technologies used in cloud data center environments and can be used to accomplish a broad range of storage management tasks from the simple to the advanced. SNIA is holding the very first Swordfish plugfest June 13-15 in the SNIA Technology Center in Colorado Springs.

Overview

We are making strides toward universal and interoperable management interfaces. These are not only interfaces that will interoperate across one vendor or one part of the stack, but management interfaces that can truly integrate your infrastructure management. Last time, we discussed OData, the Rest standardization. This time we will talk about Redfish for managing hardware platforms.

DMTF’s Redfish®

Redfish defines a simple and secure, OData conformant data service for managing scalable hardware platforms. Redfish is defined by a set of open industry standard specifications that are developed by the Distributed Management Task Force, Inc. (DMTF).

The initial development was from the point of view of a Baseboard Management Controller (BMC) or equivalent. Redfish management currently covers bare-metal discovery, configuration, monitoring, and management of all common hardware components. It is capable of managing and updating installed software, including for the operating system and for device drivers.

Redfish is not limited to low-level hardware/firmware management. It is also expected to be deployed to manage higher level functionality, including configuration and management of containers and virtual systems.   In collaboration with the IETF, Redfish is also being extended to include management of networks.

The Redfish Scalable Platforms Management API Specification specifies functionality that can be divided into three areas: OData extensions, utility interfaces, and platform management interfaces. These are described briefly in the following sections.

Redfish OData extensions

Redfish requires at least OData v4 and specifies some additional constraints:

  • Use of HTTP v1.1 is required, with support for POST, GET, PATCH, and DELETE operations, including requirements on many HTTP headers
  • JSON representations are required within payloads
  • Several well-known URIs are specified
    • /redfish/v1/ returns the ServiceRoot resource for locating resources
    • /redfish/v1/OData/ returns the OData service document for locating resources
    • /redfish/v1/$metadata returns the OData metadata document for locating the entity data model declarations.

Redfish also extends the OData metamodel with an additional vocabulary for annotating model declarations. The annotations specify information about, or behaviors of the modeled resources.

Redfish utility interfaces

The utility interfaces provide functionality that is useful for any management domain (for example, these interfaces are used by Swordfish for storage management). These interfaces include account, event, log, session, and task management.

The account service manages access to a Redfish service via a manager accounts and roles.

The event service provides the means to specify events and to subscribe to indications when a defined event occurs on a specified set of resources. Each subscription specifies where indications are sent, this can be to a listening service or to an internal resource, (e.g. a log service).

Each log service manages a collection of event records, including size and replacement policies. Resources may have multiple log services for different purposes.

The session service manages sessions and enables creation of an X-Auth-Token representing a session used to access the Redfish service.

The task service manages tasks that represent independent threads of execution known to the redfish service. Typically tasks are spawned as a result of a long running operation.

The update service provides management of firmware and software resources, including the ability to update those resources.

Redfish platform management interfaces

The principal resources managed by a Redfish service are chassis, computer systems and fabrics. Each resource has its current status. Additionally, each type of resource may have references to other resources, properties defining the current state of the resource, and additional actions as necessary.

Each chassis represents a physical or logical container. It may represent a sheet-metal confined space like a rack, sled, shelf, or module. Or, it may represent a logical space like a row, pod, or computer room zone.

Each computer system represents a computing system and its software-visible resources such as memory, processors and other devices that can be accessed from that system. The computer system can be general purpose system or can be a specialized system like a storage server or a switch.

Each fabric represents a collection of zones, switches and related endpoints. A zone is a collection of involved switches and contained endpoints. A switch provides connectivity between a set of endpoints.

All other subsystems are represented as resources that are linked via one or more of these principal resources. These subsystems include: bios, drives, endpoints, fans, memories, PCIe devices, ports, power, sensors, processors and various types of networking interfaces.

Conclusion

Redfish delivers a standardized management interface for hardware resources. While it is beginning with basic functionality like discovery, configuration and monitoring, it will deliver much more. It will extend into both richer services and cover more than physical resources – e.g. virtual systems, containers, and networks. Redfish is built as an OData conformant service, which makes it the second connected part of an integrated management API stack. Next up – Swordfish.