By now, we at the SNIA Storage Ethernet Storage Forum (ESF) hope you are familiar with (perhaps even a loyal fan of) the “Everything You Wanted To Know About Storage But Were Too Proud To Ask,” popular webcast series. On August 1^st, the “Too Proud to Ask” train will make another stop. In this seventh session, “Everything You Wanted to Know About Storage But Were Too Proud To Ask: Turquoise – Where Does My Data Go?, we will take a look into the mysticism and magic of what happens when you send your data off into the wilderness. Once you click “save,” for example, where does it actually go? When we start to dig deeper beyond the application layer, we often don’t understand what happens behind the scenes. It’s important to understand multiple aspects of the type of storage our data goes to along with their associated benefits and drawbacks as well as some of the protocols used to transport it. In this webcast we will explain:

• Volatile v Non-Volatile v Persistent Memory
• NVDIMM v RAM v DRAM v SLC v MLC v TLC v NAND v 3D NAND v Flash v SSDs v NVMe
• NVMe (the protocol)

Many people get nervous when they see that many acronyms, but all too often they come up in conversation, and you’re expected to know all of them? Worse, you’re expected to know the differences between them, and the consequences of using them? Even worse, you’re expected to know what happens when you use the wrong one? We’re here to help. It’s an ambitious project, but these terms and concepts are at the heart of where compute, networking and storage intersect. Having a good grasp of these concepts ties in with which type of storage networking to use, and how data is actually stored behind the scenes. Register today to join us for this edition of the “Too Proud To Ask” series, as we work towards making you feel more comfortable in the strange, mystical world of storage. And don’t let pride get in the way of asking any and all questions on this great topic. We will be there on August 1^st to answer them!      

This summer, join SNIA as they evangelize members’ industry activity to advance the convergence of storage and memory. SNIA is participating in the first annual European In-Memory Computing Summit, June 20-21, 2017 at the Movenpick Hotel in Amsterdam.  SNIA Europe Vice-Chair and SNIA Solid State Storage Initiative (SSSI) Co-Chair Alex McDonald of NetApp keynotes a session on SNIA and Persistent Memory, highlighting SNIA work on an NVM programming model and persistent memory solutions available today and SNIA is a sponsor in the exhibit hall. Alex’s presentation and SNIA’s booth presence is just one of SNIAs many outreach and education activities on persistent memory taking place this summer. Rob Peglar, SNIA Board of Directors member, was a highlight of Storage Field Day earlier this month, engaging with tech’s leading bloggers on persistent memory advances.  Watch the day’s video on-demand. SNIA’s NVDIMM Special Interest Group exhibited at the JEDEC Server Forum, presenting an application demonstration using multiple member companies’ JEDEC-compliant NVDIMM-Ns.   Eden Kim, chair of SNIA’s Solid State Storage Technical Work Group, speaks later this week at the China Flash Summit on SNIA’s work in persistent memory and solid state storage performance. In August, SNIA will have a major presence at Flash Memory Summit, with a dedicated persistent memory conference track, an NVDIMM Forum, and a persistent memory demonstration area.  Stay tuned for all the details coming in July. Finally, SNIA will continue an interest in containers and persistent memory with a SNIA BrightTalk webcast July 27 at 10:00 am PT/1:00 pm ET. Registration is now open to join SNIA experts Arthur Sainio, SNIA NVDIMM SIG Co-Chair, Chad Thibodeau, SNIA Cloud Storage member, and Alex McDonald, Co-Chair of SNIA Solid State Storage and SNIA Cloud Storage Initiatives to find out what customers, storage developers, and the industry want to see to fully unlock the potential of persistent memory in a container environment.

This summer, join SNIA as they evangelize members’ industry activity to advance the convergence of storage and memory. SNIA is participating in the first annual European In-Memory Computing Summit, June 20-21, 2017 at the Movenpick Hotel in Amsterdam.  SNIA Europe Vice-Chair and SNIA Solid State Storage Initiative (SSSI) Co-Chair Alex McDonald of NetApp keynotes a session on SNIA and Persistent Memory, highlighting SNIA work on an NVM programming model and persistent memory solutions available today and SNIA is a sponsor in the exhibit hall. Alex’s presentation and SNIA’s booth presence is just one of SNIAs many outreach and education activities on persistent memory taking place this summer. Rob Peglar, SNIA Board of Directors member, was a highlight of Storage Field Day earlier this month, engaging with tech’s leading bloggers on persistent memory advances.  Watch the day’s video on-demand. SNIA’s NVDIMM Special Interest Group exhibited at the JEDEC Server Forum, presenting an application demonstration using multiple member companies’ JEDEC-compliant NVDIMM-Ns.   Eden Kim, chair of SNIA’s Solid State Storage Technical Work Group, speaks later this week at the China Flash Summit on SNIA’s work in persistent memory and solid state storage performance. In August, SNIA will have a major presence at Flash Memory Summit, with a dedicated persistent memory conference track, an NVDIMM Forum, and a persistent memory demonstration area.  Stay tuned for all the details coming in July. Finally, SNIA will continue an interest in containers and persistent memory with a SNIA BrightTalk webcast July 27 at 10:00 am PT/1:00 pm ET. Registration is now open to join SNIA experts Arthur Sainio, SNIA NVDIMM SIG Co-Chair, Chad Thibodeau, SNIA Cloud Storage member, and Alex McDonald, Co-Chair of SNIA Solid State Storage and SNIA Cloud Storage Initiatives to find out what customers, storage developers, and the industry want to see to fully unlock the potential of persistent memory in a container environment.

Following enthusiastic response to their first Storage Field Day in March, SNIA is returning to the lineup on June 15, 2017. Storage Field Day events bring together innovative IT organizations and independent thought leaders to share information and opinions in a presentation format that is lively – and live streamed. SNIA will present Storage Field Day #13 at their Technology Center in Colorado Springs, CO where organizer Stephen Foskett and a dozen delegates will tour the facility and interact with SNIA members on persistent memory and scalable storage management - two hot storage topics that consumers and the industry want to learn more about. Specifically, SNIA experts will discuss:

• How the convergence of storage and memory will revolutionize computer architecture
• How SNIA is accelerating a system for unified, scalable server and storage management.

In SNIA’s 90 minute session, beginning at 12 pm Pacific/1:00 pm Mountain/ 3:00 pm Eastern, Rob Peglar, senior vice president and CTO at Symbolic IO and a SNIA Board member, will first discuss how SNIA, its technical work, and its outreach initiatives are key contributors to an ecosystem driving system memory and storage into a single, unified “persistent memory” entity. Rob will describe activities of the SNIA Non Volatile Memory Technical Work Group, which is delivering specifications describing the behavior of a common set of software interfaces that provide access to non volatile memory, and the NVDIMM Special Interest Group, which accelerates awareness and adoption of Non Volatile Dual In-line (NVDIMM) memory modules in the marketplace. Richelle Ahlvers, principal storage management architect at Broadcom Limited and co-chair of the SNIA Scalable Storage Management Technical Work Group, will discuss how the customer-centric SNIA Swordfish^TM interface extends the DMTF’s Redfish specification (API) to handle the management of storage equipment and storage services found in modern data centers. By extending the DMTF Redfish API protocol and schema, SNIA Swordfish helps provide a unified approach for the management of storage equipment, data services, and servers in converged, hyper-converged, hyperscale and cloud infrastructure environments. The same easy-to-use RESTful interface is used, along with JavaScript Object Notation (JSON) and the Open Data Protocol (OData), making it easier for IT administrators to integrate scalable solutions into their data centers. SNIA invites you and your colleagues to watch the live stream of Storage Field Day 13 on June 15th at 1:00 pm MT.  Click here to access the live viewing portal.  If your plans don’t permit you to watch live, check out the SNIAVideo channel for on-demand viewing of all SNIA’s presentations at Storage Field Day, and other technology discussions or follow the conversation on Twitter using #SFD13.

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.

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.

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.

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.

At our recent SNIA Cloud Storage webcast “IP-Based Object Drives Now Have a Management Standard,” our panel of experts discussed how the SNIA release of the IP-Based Drive Management Standard eases the management of these drives. If you missed the webcast, you can watch it on-demand. A lot of interesting questions came up during the live event. As promised, here are answers to them: Q. Am I correct in thinking that each IP based drive will have a unique IP address? A. Each Ethernet interface on the drive will have its own unique IP Address. Object Drives may be deployed in private address spaces (such as in a fully configured rack). In such configurations, two Object Drives might have the same IP address, but would be on completely separate networks. Q. Assuming vendors will be using RedFish, will the API calls be made through existing middleware or directly to the BMCs (baseboard management controllers, specialized service processors that monitors the physical state of a computer) on the platforms? A. Redfish can be supported by host based middleware, the enclosure's BMC, or may be supported directly from the drive. Q. Would a drive with native iSCSI protocol and an Ethernet interface be considered an "IP Drive"?   A. Yes. This is why we use the generic IP Drive term as it allows for multiple protocols to be supported. Q. What are the data protection schemes supported in the existing products in this space? A. Examples of data protection typically used with IP drives include erasure encoding and traditional RAID. Q. Is this approach similar to the WD Ethernet Drive? A. The WD Ethernet Drive is an IP based drive. Q. Do you expect to see interposers with higher Ethernet bandwidth that could be used with SSD vs. HDDs? A. Yes, there are multiple examples starting to appear in the market of interposers for SSDs. Q. Is this regular Ethernet or NVMe over Fabrics? A. Regular Ethernet. This does not require Converged Ethernet, nor anything layered on that. NVMe over Fabrics could utilize IP based Drive Management in the future. In this era of rapid development, where progress is evident in various facets of life such as the internet, sports, and gaming, you can even explore the exciting avenue of betting on platforms like 아리아카지노, with the enticing prospect of winning valuable prizes adding an extra layer of thrill to the ever-evolving landscape of opportunities.                  

At our recent SNIA Cloud Storage webcast “IP-Based Object Drives Now Have a Management Standard,” our panel of experts discussed how the SNIA release of the IP-Based Drive Management Standard eases the management of these drives. If you missed the webcast, you can watch it on-demand. A lot of interesting questions came up during the live event. As promised, here are answers to them: Q. Am I correct in thinking that each IP based drive will have a unique IP address? A. Each Ethernet interface on the drive will have its own unique IP Address. Object Drives may be deployed in private address spaces (such as in a fully configured rack). In such configurations, two Object Drives might have the same IP address, but would be on completely separate networks. Q. Assuming vendors will be using RedFish, will the API calls be made through existing middleware or directly to the BMCs (baseboard management controllers, specialized service processors that monitors the physical state of a computer) on the platforms? A. Redfish can be supported by host based middleware, the enclosure’s BMC, or may be supported directly from the drive. Q. Would a drive with native iSCSI protocol and an Ethernet interface be considered an “IP Drive”?   A. Yes. This is why we use the generic IP Drive term as it allows for multiple protocols to be supported. Q. What are the data protection schemes supported in the existing products in this space? A. Examples of data protection typically used with IP drives include erasure encoding and traditional RAID. Q. Is this approach similar to the WD Ethernet Drive? A. The WD Ethernet Drive is an IP based drive. Q. Do you expect to see interposers with higher Ethernet bandwidth that could be used with SSD vs. HDDs? A. Yes, there are multiple examples starting to appear in the market of interposers for SSDs. Q. Is this regular Ethernet or NVMe over Fabrics? A. Regular Ethernet. This does not require Converged Ethernet, nor anything layered on that. NVMe over Fabrics could utilize IP based Drive Management in the future.