SNIA thanks and celebrates the many hardworking SNIA member volunteers whose technical work was awarded Best of Show at the recent Flash Memory Summit. [caption id="attachment_884" align="alignright" width="150"] Jennifer Dietz and Eden Kim accept FMS award from Jay Kramer[/caption] 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. [caption id="attachment_885" align="alignleft" width="150"] Mark Carlson and Bill Martin accept award on behalf of SNIA from Jay Kramer[/caption] 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 Also at Flash Memory Summit, SNIA work and volunteers were on display in sessions on persistent memory (PM), solid state storage, form factors, and testing. A two-day PM track featured talks on advances in PM, PM hardware, PM software and applications, and remote persistent memory (PMEM-101-1; PMEM -102-1; PMEM-201-1; and PMEM-202-1). SNIA is now partnering with the Enterprise and Datacenter SSD Form Factor Working Group (EDSFF) on form factors and a Wednesday session outlined their advances (SSD-201-1). SNIA also presented a preconference seminar (G) on bringing your SSD testing up to date, and a SNIA Education afternoon with sessions on flash storage, programming and networking, buffers, queues, and caches; and a BoF on PM futures.  Check out all these sessions and more on the Flash Memory Summit proceedings page. SNIA Executive Director Michael Oros shared SNIA strategic directions and areas of focus in a FMS main stage presentation, available here. SNIA also presented updates on their work in Persistent Memory, Solid State Storage, and alliances at a well-attended reception on Monday evening.  The SSSI honored Doug Voigt, co-chair of the NVM Programming Technical Work Group, for his contributions to SNIA and the NVM Programming Model. We continued our discussions on the exhibit floor featuring JEDEC-compliant NVDIMM-Ns from SNIA Persistent Memory and NVDIMM SIG members AgigA Tech, Micron, Netlist, SMART Modular Technologies, and Viking in a Supermicro box running an open source performance demonstration.  If you missed it, the SIG will showcase a similar demonstration at the upcoming SNIA Storage Developer Conference September 24-27, 2018, and the SNIA Persistent Memory Summit January 24, 2019 at the Hyatt Santa Clara.  Register now for both events!

SNIA thanks and celebrates the many hardworking SNIA member volunteers whose technical work was awarded Best of Show at the recent Flash Memory Summit. 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. 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 Also at Flash Memory Summit, SNIA work and volunteers were on display in sessions on persistent memory (PM), solid state storage, form factors, and testing. A two-day PM track featured talks on advances in PM, PM hardware, PM software and applications, and remote persistent memory (PMEM-101-1; PMEM -102-1; PMEM-201-1; and PMEM-202-1). SNIA is now partnering with the Enterprise and Datacenter SSD Form Factor Working Group (EDSFF) on form factors and a Wednesday session outlined their advances (SSD-201-1). SNIA also presented a preconference seminar (G) on bringing your SSD testing up to date, and a SNIA Education afternoon with sessions on flash storage, programming and networking, buffers, queues, and caches; and a BoF on PM futures.  Check out all these sessions and more on the Flash Memory Summit proceedings page. SNIA Executive Director Michael Oros shared SNIA strategic directions and areas of focus in a FMS main stage presentation, available here. SNIA also presented updates on their work in Persistent Memory, Solid State Storage, and alliances at a well-attended reception on Monday evening.  The SSSI honored Doug Voigt, co-chair of the NVM Programming Technical Work Group, for his contributions to SNIA and the NVM Programming Model. We continued our discussions on the exhibit floor featuring JEDEC-compliant NVDIMM-Ns from SNIA Persistent Memory and NVDIMM SIG members AgigA Tech, Micron, Netlist, SMART Modular Technologies, and Viking in a Supermicro box running an open source performance demonstration.  If you missed it, the SIG will showcase a similar demonstration at the upcoming SNIA Storage Developer Conference September 24-27, 2018, and the SNIA Persistent Memory Summit January 24, 2019 at the Hyatt Santa Clara.  Register now for both events!

The SNIA Storage Developer Conference (SDC) is coming up September 24-27, 2018 at the Hyatt Regency Santa Clara CA.  The agenda is now live! SNIA on Storage is teaming up with the SNIA Technical Council to dive into major themes of the 2018 conference.  The SNIA Technical Council takes a leadership role to develop the content for each SDC, so SNIA on Storage spoke with Mark Carlson, SNIA Technical Council Co-Chair and Principal Engineer, Industry Standards, Toshiba Memory America, to understand why SDC is bringing Orchestration to conference attendees. SNIA On Storage (SOS):  When I think of “orchestration”, my first vision is of a conductor with a magnificent symphony.  Am I on the right track in thinking this way? Mark Carlson (MC):  If you think of the conductor as the “automator” of the symphony, you’re right on!  Orchestration for computing is the automated arrangement, coordination, and management of computer systems, middleware, and services.  For example, cloud orchestration technology helps to manage the interconnections and interactions among public and private cloud infrastructure workloads. SOS:  What are some examples of orchestration? MC:  One example is in using software containers, which are applications built on a small set of supported libraries instead of on the full operating system. This is an efficient way to use the underlying infrastructure instead of firing up multiple versions of the operating system as Virtual Machines.  Many organizations run microservices (small app components) in these containers, which can provide a simpler way to scale up a service in a much more fine-grained manner.  Here, orchestration is the conductor – the person up front – who makes sure the microservices and container-based infrastructure playing the music are in tune and on time.  There are many examples of container-based infrastructure, such as Kubernetes and Docker, evolving from the days when companies like Netflix moved to the cloud, created containers, and populated them with microservices. SOS:  Do companies and applications approach orchestration in the same way? MC:  Every container-based infrastructure has its own approach to orchestration and to the storage underlying the microservices.  SNIA member volunteers work with a variety of standards bodies and organizations to support how storage operations work in orchestration.  For example, Kubernetes is standardizing around an Application Programming Interface (API) for container storage interfaces (Container Storage Interface) that is an open source project.  SNIA is working on that with the Cloud Native Computing Foundation (CNCF) to ensure it works for storage vendors and applications. SOS: Why does the Storage Developer Conference agenda have a focus on orchestration?  MC: With all the applications and approaches out there, it’s important for developers to learn about orchestration and containers in a vendor neutral environment as a foundation for understanding and evaluation. That’s where SNIA’s Storage Developer Conference plays a big role.  Orchestration talks can be found in the agenda under the Cloud Storage, Storage Architecture, and Storage Management Tracks and feature speakers from Stanford University, HPE, DESY, Google, Portworx, Kasten, and NetApp. SOC:  How can I get up to speed on orchestration topics before attending SDC 2018? MC: SNIA has several great Brighttalk webcasts on containers that have thousands of views.  Check out these titles.

• Containers: Best Practices and Data Management Services 
• Containers and Persistent Memory

Also, check out this video on Containers and Persistent Memory from the 2018 SNIA Storage Developer Conference India. The 2017 SDC had a number of presentations on orchestration-related topics that are available via SNIA Video - and you can view the slides along with them.  Check under the Cloud Storage and Containers headings. Also check out the Storage Developer Conference Podcast Series, featuring 73 sessions from previous SDC events, with more arriving each month. SOS:  Does SNIA have a group focused on orchestration? MC:  SNIA’s Cloud Storage Technologies Initiative (CSTI) supports the evolving cloud business models and architectures, including OpenStack, software defined storage, Kubernetes, and object storage.  You can check out a new blog on CSTI here. SOC:  Great to chat with you, Mark, and look forward to our next dive – into NVMe!

The SNIA Cloud Storage Initiative (CSI) has had a rebrand; we’ve added a T for Technologies into our name, and we’re now officially the Cloud Storage Technologies Initiative (CSTI). That doesn’t seem like a significant change, but there’s a good reason. Our old name reflected the push to getting acceptance of cloud storage, and that specific cloud storage debate has been won, and big time. One relatively small cloud service provider is currently storing 400PB of clients’ data. Twitter alone consumes 300PB of data on Google’s cloud offering. Facebook, Amazon, AliBaba, Tencent – all have huge data storage numbers. Enterprises of every size are storing data in the cloud. That’s why we added the word “technologies.” The expanded charter and new name reflect the need to support the evolving cloud business models and architectures such as OpenStack, software defined storage, Kubernetes and object storage. It includes data services, orchestration and management, understanding hyperscale requirements and the role standards play. So what do we do? The CSTI is an active group that publishes articles and white papers, speaks at industry conferences and presents at highly-rated webcasts that have been viewed by thousands. You can learn more about the CSTI and check out the Infographic for highlights on cloud storage trends and CSTI activities. If you’re interested in cloud storage technologies, I encourage you to consider joining our group. We have multiple membership options for established vendors, startups, educational institutions, even individuals. Learn more about CSTI membership here.

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!

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!

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!

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!

By Paul Grun, Chair, OpenFabrics Alliance and Senior Technologist, Cray, Inc. Remote Persistent Memory, (RPM), is rapidly emerging as an important new technology. But understanding a new technology, and grasping its significance, requires engagement across a wide range of industry organizations, companies, and individuals. It takes a village, as they say. Technologies that are capable of bending the arc of server architecture come along only rarely. It’s sometimes hard to see one coming because it can be tough to discern between a shiny new thing, an insignificant evolution in a minor technology, and a serious contender for the Technical Disrupter of the Year award. Remote Persistent Memory is one such technology, the ultimate impact of which is only now coming into view. Two relatively recent technologies serve to illustrate the point: The emergence of dedicated, high performance networks beginning in the early 2000s and more recently the arrival of non-volatile memory technologies, both of which are leaving a significant mark on the evolution of computer systems. But what happens when those two technologies are combined to deliver access to persistent memory over a fabric? It seems likely that such a development will positively impact the well-understood memory hierarchies that are the basis of all computer systems today. And that, in turn, could cause system architects and application programmers to re-think the way that information is accessed, shared, and stored. To help us bring the subject of RPM into sharp focus, there is currently a concerted effort underway to put some clear definition around what is shaping up to be a significant disrupter. For those who aren’t familiar, Remote Persistent Memory refers to a persistent memory service that is accessed over a fabric or network. It may be a service shared among multiple users, or dedicated to one user or application. It’s distinguished from local Persistent Memory, which refers to a memory device attached locally to the processor via a memory or I/O bus, in that RPM is accessed via a high performance switched fabric. For our purposes, we’ll further refine our discussion to local fabrics, neglecting any discussion of accessing memory over the wide area. Most important of all, Persistent Memory, including RPM, is definitely distinct from storage, whether that is file, object or block storage. That’s why we label this as a ‘memory’ service - to distinguish it from storage.  The key distinction is that the consumer of the service recognizes and uses it as it would any other level in the memory hierarchy. Even though the service could be implemented using block or file-oriented non-volatile memory devices, the key is in the way that an application accesses and uses the service. This isn’t faster or better storage, it’s a whole different kettle of fish. So how do we go about discovering the ultimate value of a new technology like RPM? So far, a lively discussion has been taking place across multiple venues and industry events. These aren’t ad hoc discussions nor are they tightly scripted events; they are taking place in a loosely organized fashion designed to encourage lots of participation and keep the ball moving forward. Key discussions on the topic have hopscotched from the SNIA’s Storage Developers Conference, to SNIA/SSSI’s Persistent Memory Summit, to the OpenFabrics Alliance (OFA) Workshop and others. Each of these industry events has given us an opportunity for the community at large to discuss and develop the essential ideas surrounding RPM. The next installment will occur at the upcoming Flash Memory Summit in August where there will be four sessions all devoted to discussing Remote Persistent Memory. Having frequent industry gatherings is a good thing, naturally, but that by itself doesn’t answer the question of how we go about progressing a discussion of Remote Persistent Memory in an orderly way.  A pretty clear consensus has emerged that RPM represents a new layer in the memory hierarchy and therefore the best way to approach it is to take a top-down perspective. That means starting with an examination of the various ways that an application could leverage this new player in the memory hierarchy. The idea is to identify and explore several key use cases. Of course, the technology is in its early infancy, so we’re relying on the best instincts of the industry at large to guide the discussion. Once there is a clear idea of the ways that RPM could be applied to improve application performance, efficiency or resiliency, it’ll be time to describe how the features of an RPM service are exposed to an application. That means taking a hard look at network APIs to be sure they export the functions and features that applications will need to access the service. The API is key, because it defines the ways that an application actually accesses a new network service. Keep in mind that such a service may or may not be a natural fit to existing applications; in some cases, it will fit naturally meaning that an existing application can easily begin to utilize the service to improve performance or efficiency. For other applications, more work will be needed to fully exploit the new service. Notice that the development of the API is being driven from the top down by application requirements. This is a clear break from traditional network design, where the underlying network and its associated API are defined roughly in tandem. Contrast that to the approach being taken with RPM, where the set of desired network characteristics is described in terms of how an application will actually use the network. Interesting! Armed with a clear sense of how an application might use Remote Persistent Memory and the APIs needed to access it, now’s the time for network architects and protocol designers to deliver enhanced network protocols and semantics that are best able to deliver the features defined by the new network APIs. And it’s time for hardware and software designers to get to work implementing the service and integrating it into server systems. With all that in mind, here’s the current state of affairs for those who may be interested in participating. SNIA, through its NVM Programming Technical Working Group, has published a public document describing one very important use case for RPM – High Availability. The document describes the requirements that the SNIA NVM Programming Model – first released in December 2013 -- might place on a high-speed network.  That document is available online. In keeping with the ‘top-down’ theme, SNIA’s work begins with an examination of the programming models that might leverage a Remote Persistent Memory service, and then explores the resulting impacts on network design. It is being used today to describe enhancements to existing APIs including both the Verbs API and the libfabric API. In addition, SNIA and the OFA have established a collaboration to explore other use cases, with the idea that those use cases will drive additional API enhancements. That collaboration is just now getting underway and is taking place during open, bi-weekly meetings of the OFA’s OpenFabrics Interfaces Working Group (OFIWG). There is also a mailing list dedicated to the topic to which you can subscribe by going to www.lists.openfabrics.org and subscribing to the Ofa_remotepm mailing list. And finally, we’ll be discussing the topic at the upcoming Flash Memory Summit, August 7-9, 2018.  Just go to the program section and click on the Persistent Memory major topic, and you’ll find a link to PMEM-202-1: Remote Persistent Memory. See you in Santa Clara!

By Paul Grun, Chair, OpenFabrics Alliance and Senior Technologist, Cray, Inc. Remote Persistent Memory, (RPM), is rapidly emerging as an important new technology. But understanding a new technology, and grasping its significance, requires engagement across a wide range of industry organizations, companies, and individuals. It takes a village, as they say. Technologies that are capable of bending the arc of server architecture come along only rarely. It’s sometimes hard to see one coming because it can be tough to discern between a shiny new thing, an insignificant evolution in a minor technology, and a serious contender for the Technical Disrupter of the Year award. Remote Persistent Memory is one such technology, the ultimate impact of which is only now coming into view. Two relatively recent technologies serve to illustrate the point: The emergence of dedicated, high performance networks beginning in the early 2000s and more recently the arrival of non-volatile memory technologies, both of which are leaving a significant mark on the evolution of computer systems. But what happens when those two technologies are combined to deliver access to persistent memory over a fabric? It seems likely that such a development will positively impact the well-understood memory hierarchies that are the basis of all computer systems today. And that, in turn, could cause system architects and application programmers to re-think the way that information is accessed, shared, and stored. To help us bring the subject of RPM into sharp focus, there is currently a concerted effort underway to put some clear definition around what is shaping up to be a significant disrupter. For those who aren’t familiar, Remote Persistent Memory refers to a persistent memory service that is accessed over a fabric or network. It may be a service shared among multiple users, or dedicated to one user or application. It’s distinguished from local Persistent Memory, which refers to a memory device attached locally to the processor via a memory or I/O bus, in that RPM is accessed via a high performance switched fabric. For our purposes, we’ll further refine our discussion to local fabrics, neglecting any discussion of accessing memory over the wide area. Most important of all, Persistent Memory, including RPM, is definitely distinct from storage, whether that is file, object or block storage. That’s why we label this as a ‘memory’ service – to distinguish it from storage.  The key distinction is that the consumer of the service recognizes and uses it as it would any other level in the memory hierarchy. Even though the service could be implemented using block or file-oriented non-volatile memory devices, the key is in the way that an application accesses and uses the service. This isn’t faster or better storage, it’s a whole different kettle of fish. So how do we go about discovering the ultimate value of a new technology like RPM? So far, a lively discussion has been taking place across multiple venues and industry events. These aren’t ad hoc discussions nor are they tightly scripted events; they are taking place in a loosely organized fashion designed to encourage lots of participation and keep the ball moving forward. Key discussions on the topic have hopscotched from the SNIA’s Storage Developers Conference, to SNIA/SSSI’s Persistent Memory Summit, to the OpenFabrics Alliance (OFA) Workshop and others. Each of these industry events has given us an opportunity for the community at large to discuss and develop the essential ideas surrounding RPM. The next installment will occur at the upcoming Flash Memory Summit in August where there will be four sessions all devoted to discussing Remote Persistent Memory. Having frequent industry gatherings is a good thing, naturally, but that by itself doesn’t answer the question of how we go about progressing a discussion of Remote Persistent Memory in an orderly way.  A pretty clear consensus has emerged that RPM represents a new layer in the memory hierarchy and therefore the best way to approach it is to take a top-down perspective. That means starting with an examination of the various ways that an application could leverage this new player in the memory hierarchy. The idea is to identify and explore several key use cases. Of course, the technology is in its early infancy, so we’re relying on the best instincts of the industry at large to guide the discussion. Once there is a clear idea of the ways that RPM could be applied to improve application performance, efficiency or resiliency, it’ll be time to describe how the features of an RPM service are exposed to an application. That means taking a hard look at network APIs to be sure they export the functions and features that applications will need to access the service. The API is key, because it defines the ways that an application actually accesses a new network service. Keep in mind that such a service may or may not be a natural fit to existing applications; in some cases, it will fit naturally meaning that an existing application can easily begin to utilize the service to improve performance or efficiency. For other applications, more work will be needed to fully exploit the new service. Notice that the development of the API is being driven from the top down by application requirements. This is a clear break from traditional network design, where the underlying network and its associated API are defined roughly in tandem. Contrast that to the approach being taken with RPM, where the set of desired network characteristics is described in terms of how an application will actually use the network. Interesting! Armed with a clear sense of how an application might use Remote Persistent Memory and the APIs needed to access it, now’s the time for network architects and protocol designers to deliver enhanced network protocols and semantics that are best able to deliver the features defined by the new network APIs. And it’s time for hardware and software designers to get to work implementing the service and integrating it into server systems. With all that in mind, here’s the current state of affairs for those who may be interested in participating. SNIA, through its NVM Programming Technical Working Group, has published a public document describing one very important use case for RPM – High Availability. The document describes the requirements that the SNIA NVM Programming Model – first released in December 2013 — might place on a high-speed network.  That document is available online. In keeping with the ‘top-down’ theme, SNIA’s work begins with an examination of the programming models that might leverage a Remote Persistent Memory service, and then explores the resulting impacts on network design. It is being used today to describe enhancements to existing APIs including both the Verbs API and the libfabric API. In addition, SNIA and the OFA have established a collaboration to explore other use cases, with the idea that those use cases will drive additional API enhancements. That collaboration is just now getting underway and is taking place during open, bi-weekly meetings of the OFA’s OpenFabrics Interfaces Working Group (OFIWG). There is also a mailing list dedicated to the topic to which you can subscribe by going to www.lists.openfabrics.org and subscribing to the Ofa_remotepm mailing list. And finally, we’ll be discussing the topic at the upcoming Flash Memory Summit, August 7-9, 2018.  Just go to the program section and click on the Persistent Memory major topic, and you’ll find a link to PMEM-202-1: Remote Persistent Memory. See you in Santa Clara!