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.                  

In our most recent “Everything You Wanted To Know About Storage But Were Too Proud To Ask” webcast series – Part Sepia – Getting from Here to There, we discussed terms and concepts that have a profound impact on storage design and performance. If you missed the live event, I encourage you to check it our on-demand. We had many great questions on encapsulation, tunneling, IOPS, latency, jitter and quality of service (QoS). As promised, our experts have gotten together to answer them all. Q. Is there a way to measure jitter? A. Jitter can be measured directly as a statistical function of the latency, typically as the Variance or Standard Deviation of the latency. For example a storage device might show an average latency of 5ms with a standard deviation of 1.5ms. This means roughly 95% of the transactions have a latency between 2ms and 8ms (average latency plus/minus two standard deviations), however many storage customers measure jitter indirectly by showing the 99.9%, 99.99%, or 99.999% latency. For example if my storage system has 99.99% latency of 8ms, it means 99.99% of transactions have latency <=8ms and 1/10,000 of transactions have latency >8ms. Percentile latency is an indirect measure of jitter but often easier to calculate or understand than the actual jitter. Q. Can jitter be easily characterized for storage, media, and networks.  How and what tools are available for doing this? A. Jitter is usually easy to measure on a network using standard network monitoring and reporting tools. It may or may not be easy to measure on storage systems or storage media, depending on the tools available (either built-in to the storage OS or using an external management or monitoring tool).  If you can record the latency of each transaction or packet, then it’s easy to calculate and show the jitter using standard statistical measures such as Variance or Standard Deviation of the latency. What most customers do is just measure the 99.9%, 99.99%, or 99.999% latency. This is an indirect measure of jitter but is often much easier to report and understand than the actual jitter. Q.  Generally IOPS numbers are published for a particular block size like 8k write/read size, but in reality, IO request per second could be of mixed sizes, what is your perspective on this? A. Most IOPS benchmarks test only one I/O size at a time. Most individual real workloads (for example databases) also use only one I/O size.  It is true that a storage controller or HDD/SSD might need to support multiple workloads simultaneously, each with a different I/O size.  While it is possible to run benchmarks with a mix of different I/O sizes, it’s rarely done because then there are too many workload combinations to test and publish. Some storage devices do not perform well if they must handle both small random and large sequential workloads simultaneously, so a smart storage controller might assign different workload types to different disk groups. Q. One often misconfigured parameter is queue depth. Can you talk about how this relates to IOPS, latency and jitter? A. Queue depth indicates how many tasks or I/Os can be lined up for a particular controller, interface, or CPU. Having a higher queue depth ensures the CPU (or controller or interface) always has a new task to do as soon as it finishes its current task(s). This can result in higher IOPS because the CPU is less likely to have idle time between transactions. But it could also increase latency because the CPU is more likely to be multi-tasking and context switching between different tasks or workloads. Q. Can you please repeat all your examples of tunneling? GRE, MPLS, what others? How can it be IPv4 via IPv6? A. VXLAN, LISP, GRE, MPLS, IPSEC.  Any time you encapsulate and send one protocol over another and decapsulate at the other end to send the original frame that process is tunneling. In the case we showed of IPv6 over IPv4, you are taking an original IPv6 frame with its IPv6 header of source address to destination address all IPv6 and sending it over and IPv4 enabled network we are encapsulating the IPv6 frame with an IPv4 header and “tunneling” IPv6 over the IPv4 network. Q. I think it’d be possible to configure QoS to a point that exceeds the system capacity. Are there any safeguards on avoiding this scenario? A. Some types of QoS allow over-provisioning and others do not. For example a QoS that imposes only maximum limits (and no minimum guarantees) on workloads might not prevent many workloads from exceeding system capacity. If the QoS allows over-provisioning, then you should use system monitoring and alerts to warn you when system capacity has been exceeded, or when any workloads are not getting their minimum guaranteed performance. Q. Is there any research being done on using storage analytics along with artificial intelligence (AI) to assist with QoS?   A. There are a number of storage analytics products, both third party and storage vendor specific that help with QoS. Whether any of these tools may be described as using AI is debatable, since we’re in the early days of using AI to do much in the storage arena. There are many QoS research projects, and no doubt they will eventually make their way into commercially available products if they prove useful. Q. Are there any methods (measurements) to calculate IOPS/MBps in tier capable storage? Would it be wrong metric if we estimate based on medium level, example tier 2 (between 1 and 3)? A. This question needs refinement, since tiering is sometimes a cache model rather than a data movement model. And knowing the answer may not actually help! Vendors do have tools (normally internal, since they are quite complex) that can help with the planning of tiered storage. By now, we hope you’re not “too proud” to ask some of these storage networking questions. We’ve produced four other webcasts in this “Everything You Wanted To Know About Storage,” series to date. They are all available on-demand. And you can register here for our next one on July 6^th where we’ll bring in experts to discuss:

• Storage APIs and POSIX
• Block, File, and Object storage
• Byte Addressable and Logical Block Addressing
• Log Structures and Journaling Systems

The Ethernet Storage Forum team and I hope to see you there!    

When it comes to the cloud, security is always a topic for discussion. Standards organizations like SNIA are in the vanguard of describing cloud concepts and usage, and (as you might expect) are leading on how and where security fits in this new world of dispersed and publicly stored and managed data. On July 20^th, the SNIA Cloud Storage Initiative is hosting a live webcast “The State of Cloud Security.” In this webcast, I will be joined by SNIA experts Eric Hibbard and Mark Carlson who will take us through a discussion of existing cloud and emerging technologies, such as the Internet of Things (IoT), Analytics & Big Data, and more, and explain how we’re describing and solving the significant security concerns these technologies are creating. They will discuss emerging ISO/IEC standards, SLA frameworks and security and privacy certifications. This webcast will be of interest to managers and acquirers of cloud storage (whether internal or external), and developers of private and public cloud solutions who want to know more about security and privacy in the cloud. Topics covered will include:

• Summary of the standards developing organization (SDO) activities:
  • Work on cloud concepts, Cloud Data Management Interface (CDMI), an SLA framework, and cloud security and privacy
• Securing the Cloud Supply Chain:
  • Outsourcing and cloud security, Cloud Certifications (FedRAMP, CSA STAR)
• Emerging & Related Technologies:
  • Virtualization/Containers, Federation, Big Data/Analytics in the Cloud, IoT and the Cloud

Register today. We hope to see you on July 20^th where Eric, Mark and I will be ready to answer your cloud security questions.

When it comes to the cloud, security is always a topic for discussion. Standards organizations like SNIA are in the vanguard of describing cloud concepts and usage, and (as you might expect) are leading on how and where security fits in this new world of dispersed and publicly stored and managed data. On July 20^th, the SNIA Cloud Storage Initiative is hosting a live webcast “The State of Cloud Security.” In this webcast, I will be joined by SNIA experts Eric Hibbard and Mark Carlson who will take us through a discussion of existing cloud and emerging technologies, such as the Internet of Things (IoT), Analytics & Big Data, and more, and explain how we’re describing and solving the significant security concerns these technologies are creating. They will discuss emerging ISO/IEC standards, SLA frameworks and security and privacy certifications. This webcast will be of interest to managers and acquirers of cloud storage (whether internal or external), and developers of private and public cloud solutions who want to know more about security and privacy in the cloud. Topics covered will include:

• Summary of the standards developing organization (SDO) activities:
  • Work on cloud concepts, Cloud Data Management Interface (CDMI), an SLA framework, and cloud security and privacy
• Securing the Cloud Supply Chain:
  • Outsourcing and cloud security, Cloud Certifications (FedRAMP, CSA STAR)
• Emerging & Related Technologies:
  • Virtualization/Containers, Federation, Big Data/Analytics in the Cloud, IoT and the Cloud

Register today. We hope to see you on July 20^th where Eric, Mark and I will be ready to answer your cloud security questions.

The colorful “Everything You Wanted To Know About Storage But Were Too Proud To Ask,” popular webcast series marches on! In this 6^th installment, Part – Vermillion – What if Programming and Networking Had a Storage Baby, we look into some of the nitties and the gritties of storage details that are often assumed. When looking at data from the lens of an application, host, or operating system, it’s easy to forget that there are several layers of abstraction underneath each before the actual placement of data occurs. In this webcast we are going to scratch beyond the first layer to understand some of the basic taxonomies of these layers. In this webcast we will show you more about the following:

• Storage APIs and POSIX
• Block, File, and Object storage
• Byte Addressable and Logical Block Addressing
• Log Structures and Journaling Systems

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 on July 6th for this session. You can ask all the questions that, until now, you’ve been too proud to ask and we promise not to to show you any baby pictures!