Building a cloud storage architecture requires both storage vendors, cloud service providers and large enterprises to consider new technical and economic paradigms in order to enable a flexible and cost efficient architecture. That’s why the SNIA Cloud Storage Technologies Initiative is hosting a live webcast, “Create a Smart and More Economic Cloud Storage Architecture” on November 7^th. From an economic perspective, cloud infrastructure is often procured in the traditional way – prepay for expected future storage needs and over provision for unexpected changes in demand. This requires large capital expenditures which slows cost recovery based on fluctuating customer adoption. Giving large enterprises and cloud service providers flexibility in the procurement model for their storage allows them to more closely align the expenditure on infrastructure resources with the cost recovery from customers, optimizing the use of both CapEx and OpEx budgets. From a technical perspective, clouds inherently require unpredictable scalability – both up and down. If you were to Read More, you'd know that digital marketing, SEO, and graphic design is the least of it. Building a storage architecture with the ability to rapidly allocate resources for a specific customer need and reallocate resources based on changing customer requirements allows for storage capacity optimization, creating performance pools in the data center without compromising the responsiveness to the change in needs. Such architecture should also align to the data center level orchestration system to allow for even higher level of resource optimization and flexibility. In this webcast, you will learn:

• How modern storage technology allows you to build this infrastructure
• The role of software defined storage
• Accounting principles that impact CapEx and OpEx
• How to model cloud costs of new applications and or re-engineering existing applications
• Performance considerations

Building a cloud storage architecture requires both storage vendors, cloud service providers and large enterprises to consider new technical and economic paradigms in order to enable a flexible and cost efficient architecture. That’s why the SNIA Cloud Storage Technologies Initiative is hosting a live webcast, “Create a Smart and More Economic Cloud Storage Architecture” on November 7^th. From an economic perspective, cloud infrastructure is often procured in the traditional way – prepay for expected future storage needs and over provision for unexpected changes in demand. This requires large capital expenditures which slows cost recovery based on fluctuating customer adoption. Giving large enterprises and cloud service providers flexibility in the procurement model for their storage allows them to more closely align the expenditure on infrastructure resources with the cost recovery from customers, optimizing the use of both CapEx and OpEx budgets. From a technical perspective, clouds inherently require unpredictable scalability – both up and down. Building a storage architecture with the ability to rapidly allocate resources for a specific customer need and reallocate resources based on changing customer requirements allows for storage capacity optimization, creating performance pools in the data center without compromising the responsiveness to the change in needs. Such architecture should also align to the data center level orchestration system to allow for even higher level of resource optimization and flexibility. In this webcast, you will learn:

• How modern storage technology allows you to build this infrastructure
• The role of software defined storage
• Accounting principles that impact CapEx and OpEx
• How to model cloud costs of new applications and or re-engineering existing applications
• Performance considerations

Register today. Our CSTI experts will be on hand to answer your questions on the spot. We hope to see you on November. 7^th.  

At SNIA, we are dedicated to staying on top of storage trends and technologies to fulfill our mission as a globally recognized and trusted authority for storage leadership, standards, and technology expertise. For the last several years, the Ethernet Storage Forum has been working hard to provide high quality educational and informational material related to all kinds of storage.

From our "Everything You Wanted To Know About Storage But Were Too Proud To Ask" series, to the absolutely phenomenal (and required viewing) "Storage Performance Benchmarking" series to the "Great Storage Debates" series, we've produced dozens of hours of material.

Technologies have evolved and we've come to a point where there's a need to understand how these systems and architectures work – beyond just the type of wire that is used. Today, there are new systems that are bringing storage to completely new audiences. From scale-up to scale-out, from disaggregated to hyperconverged, RDMA, and NVMe-oF - there is more to storage networking than just your favorite transport. For example, when we talk about NVMe™ over Fabrics, the protocol is broader than just one way of accomplishing what you need. When we talk about virtualized environments, we need to examine the nature of the relationship between hypervisors and all kinds of networks. When we look at "Storage as a Service," we need to understand how we can create workable systems from all the tools at our disposal. Bigger Than Our Britches As I said, SNIA's Ethernet Storage Forum has been working to bring these new technologies to the forefront, so that you can see (and understand) the bigger picture. To that end, we realized that we needed to rethink the way that our charter worked, to be even more inclusive of technologies that were relevant to storage and networking. So... Introducing the Networking Storage Forum. In this group we're going to continue producing top-quality, vendor-neutral material related to storage networking solutions. We'll be talking about:

• Storage Protocols (iSCSI, FC, FCoE, NFS, SMB, NVMe-oF, etc.)
• Architectures (Hyperconvergence, Virtualization, Storage as a Service, etc.)
• Storage Best Practices
• New and developing technologies

... and more! Generally speaking, we'll continue to do the same great work that we've been doing, but now our name more accurately reflects the breadth of work that we do. We're excited to launch this new chapter of the Forum. If you work for a vendor, are a systems integrator, university or someone who manages storage, we welcome you to join the NSF. We are an active group that honestly has a lot of fun. If you're one of our loyal followers, we hope you will continue to keep track of what we're doing. And if you're new to this Forum, we encourage you to take advantage of the library of webcasts, white papers, and published articles that we have produced here. There's a wealth of un-biased, educational information there, we don't think you'll find anywhere else! If there's something that you'd like to hear about – let us know! We are always looking to hear about headaches, concerns, and areas of confusion within the industry where we can shed some light. Stay current with all things NSF:

• Visit: snia.org/nsf
• Follow: @SNIANSF
• Subscribe: sniansfblog_org_org.org
• Watch: SNIAVideo Network Storage Playlist

   

At SNIA, we are dedicated to staying on top of storage trends and technologies to fulfill our mission as a globally recognized and trusted authority for storage leadership, standards, and technology expertise. For the last several years, the Ethernet Storage Forum has been working hard to provide high quality educational and informational material related to all kinds of storage.

From our “Everything You Wanted To Know About Storage But Were Too Proud To Ask” series, to the absolutely phenomenal (and required viewing) “Storage Performance Benchmarking” series to the “Great Storage Debates” series, we’ve produced dozens of hours of material.

Technologies have evolved and we’ve come to a point where there’s a need to understand how these systems and architectures work – beyond just the type of wire that is used. Today, there are new systems that are bringing storage to completely new audiences. From scale-up to scale-out, from disaggregated to hyperconverged, RDMA, and NVMe-oF – there is more to storage networking than just your favorite transport. For example, when we talk about NVMe over Fabrics, the protocol is broader than just one way of accomplishing what you need. When we talk about virtualized environments, we need to examine the nature of the relationship between hypervisors and all kinds of networks. When we look at “Storage as a Service,” we need to understand how we can create workable systems from all the tools at our disposal. Bigger Than Our Britches As I said, SNIA’s Ethernet Storage Forum has been working to bring these new technologies to the forefront, so that you can see (and understand) the bigger picture. To that end, we realized that we needed to rethink the way that our charter worked, to be even more inclusive of technologies that were relevant to storage and networking. So… Introducing the Networking Storage Forum. In this group we’re going to continue producing top-quality, vendor-neutral material related to storage networking solutions. We’ll be talking about:

• Storage Protocols (iSCSI, FC, FCoE, NFS, SMB, NVMe-oF, etc.)
• Architectures (Hyperconvergence, Virtualization, Storage as a Service, etc.)
• Storage Best Practices
• New and developing technologies

… and more! Generally speaking, we’ll continue to do the same great work that we’ve been doing, but now our name more accurately reflects the breadth of work that we do. We’re excited to launch this new chapter of the Forum. If you work for a vendor, are a systems integrator, university or someone who manages storage, we welcome you to join the NSF. We are an active group that honestly has a lot of fun. If you’re one of our loyal followers, we hope you will continue to keep track of what we’re doing. And if you’re new to this Forum, we encourage you to take advantage of the library of webcasts, white papers, and published articles that we have produced here. There’s a wealth of un-biased, educational information there, we don’t think you’ll find anywhere else! If there’s something that you’d like to hear about – let us know! We are always looking to hear about headaches, concerns, and areas of confusion within the industry where we can shed some light. Stay current with all things NSF:

• Visit: snia.org/nsf
• Follow: @SNIANSF
• Subscribe: sniansfblog_org_org.org
• Watch: SNIAVideo Network Storage Playlist

   

For datacenter applications requiring low-latency access to persistent storage, byte-addressable persistent memory (PM) technologies like 3D XPoint and MRAM are attractive solutions. Network-based access to PM, labeled here Persistent Memory over Fabrics (PMoF), is driven by data scalability and/or availability requirements. Remote Direct Memory Access (RDMA) network protocols are a good match for PMoF, allowing direct RDMA data reads or writes from/to remote PM. However, the completion of an RDMA Write at the sending node offers no guarantee that data has reached persistence at the target. Join the Networking Storage Forum (NSF) on October 25, 2018 for out next live webcast, Extending RDMA for Persistent Memory over Fabrics. In this webcast, we will outline extensions to RDMA protocols that confirm such persistence and additionally can order successive writes to different memories within the target system. Learn:

• Why we can't just treat PM just like traditional storage or volatile memory
• What happens when you write to memory over RDMA
• Which programming model and protocol changes are required for PMoF
• How proposed RDMA extensions for PM would work

We believe this webcast will appeal to developers of low-latency and/or high-availability datacenter storage applications and be of interest to datacenter developers, administrators and users. I encourage you to register today. Our NSF experts will be on hand to answer you questions. We look forward to your joining us on October 25^th.  

For datacenter applications requiring low-latency access to persistent storage, byte-addressable persistent memory (PM) technologies like 3D XPoint and MRAM are attractive solutions. Network-based access to PM, labeled here Persistent Memory over Fabrics (PMoF), is driven by data scalability and/or availability requirements. Remote Direct Memory Access (RDMA) network protocols are a good match for PMoF, allowing direct RDMA data reads or writes from/to remote PM. However, the completion of an RDMA Write at the sending node offers no guarantee that data has reached persistence at the target. Join the Networking Storage Forum (NSF) on October 25, 2018 for out next live webcast, Extending RDMA for Persistent Memory over Fabrics. In this webcast, we will outline extensions to RDMA protocols that confirm such persistence and additionally can order successive writes to different memories within the target system. Learn:

• Why we can’t just treat PM just like traditional storage or volatile memory
• What happens when you write to memory over RDMA
• Which programming model and protocol changes are required for PMoF
• How proposed RDMA extensions for PM would work

We believe this webcast will appeal to developers of low-latency and/or high-availability datacenter storage applications and be of interest to datacenter developers, administrators and users. I encourage you to register today. Our NSF experts will be on hand to answer you questions. We look forward to your joining us on October 25^th.  

To date, thousands have watched our "Great Storage Debate" webcast series. Our most recent installment of this friendly debate (where no technology actually emerges as a "winner") was Centralized vs. Distributed Storage. If you missed it, it's now available on-demand. The live event generated several excellent questions which our expert presenters have thoughtfully answered here: Q. Which performs faster, centralized or distributed storage? A. The answer depends on the type of storage, the type of connections to the storage, and whether the compute is distributed or centralized. The stereotype is that centralized storage performs faster if the compute is local, that is if it's in the same data center as the centralized storage. Distributed storage is often using different (less expensive) storage media and designed for slower WAN connections, but it doesn't have to be so. Distributed storage can be built with the fastest storage and connected with the fastest networking, but it rarely is used that way. Also it can outperform centralized storage if the compute is distributed in a similar way to the distributed storage, letting each compute node access the data from a local node of the distributed storage. Q. What about facilities costs in either environment? Ultimately the data has to physically "land" somewhere and use power/cooling/floor space. There is an economy of scale in centralized data centers, how does that compare with distributed? A. One big difference is in the cost of power between various data centers. Typically, data centers tend to be the places where businesses have had traditional office space and accommodation for staff. Unfortunately, these are also areas of power scarcity and are consequently expensive to run. Distributed data centers can be in much cheaper locations; there are a number for instance in Iceland where geothermally generated electricity is very cheap, and environmental cooling is effectively free. Plus, the thermal cost per byte can be substantially lower in distributed data centers by efficiently packing drives to near capacity with compressed data. Learn more about data centers in Iceland here. Another difference is that distributed storage might consume less space if its data protection method (such as erasure coding) is more efficient than the data protection method used by centralized storage (typically RAID or triple replication). While centralized storage can also use erasure coding, compression, and deduplication, it's sometimes easier to apply these storage efficiency technologies to distributed storage. Q. What is sharding? A. Sharding is the process of breaking up, typically a database, into a number of partitions, and then putting these pieces or shards on separate storage devices or systems. The partitioning is normally a horizontal partition; that is, the rows of the database remain complete in a shard and some criteria (often a key range) is used to make each shard. Sharding is often used to improve performance, as the data is spread across multiple devices which can be accessed in parallel. Sharding should not be confused with erasure coding used for data protection. Although this also breaks data into smaller pieces and spreads it across multiple devices, each part of the data is encoded and can only be understood once a minimum number of the fragments have been read and the data has been reconstituted on some system that has requested it. Q. What is the preferred or recommended choice of NVMe over Fabrics (NVME-oF) for centralized vs. distributed storage systems for prioritized use-case scenarios such as data integrity, latency, number of retries for read-write/resource utilization? A. This is a straightforward cost vs. performance question. This kind of solution only makes sense if the compute is very close to the data; so either a centralized SAN, or a (well-defined) distributed system in one location with co-located compute would make sense. Geographically dispersed data centers or compute on remote data adds too much latency, and often bandwidth issues can add to the cost. Q. Is there a document that has catalogued the impact of latency on the many data types? When designing storage I would start with how much latency an application can withstand. A. We are not aware of any single document that has done so, but many applications (along with their vendors, integrators, and users) have documented their storage bandwidth and latency needs. Other documents show the impact of differing storage latencies on application performance. Generally speaking one could say the following about latency requirements, though exceptions exist to each one:

• Block storage wants lower latency than file storage, which wants lower latency than object storage
• Large I/O and sequential workloads tolerate latency better than small I/O and random workloads
• One-way streaming media, backup, monitoring and asynchronous replication care more about bandwidth than latency. Two-way streaming (e.g. videoconferencing or IP telephony), database updates, interactive monitoring, and synchronous replication care more about latency than bandwidth.
• Real-time applications (remote control surgery, multi-person gaming, remote AR/VR, self-driving cars, etc.) require lower latency than non-real-time ones, especially if the real-time interaction goes both ways on the link.

One thing to note is that many factors affect performance of a storage system. You may want to take a look at our excellent Performance Benchmark webinar series to find out more. Q. Computation faces an analogous debate between distributed compute vs. centralized compute. Please comment on how the computation debate relates to the storage debate. Typically, distributed computation will work best with distributed storage. Ditto for centralized computation and storage. Are there important applications where a user would go for centralized compute and distributed storage? Or distributed compute and centralized storage? A. That's a very good question, to which there is a range of not so very good answers! Here are some application scenarios that require different thinking about centralized vs. distributed storage. Video surveillance is best with distributed storage (and perhaps a little local compute to do things like motion detection or object recognition) with centralized compute (for doing object identification or consolidation of multiple feeds). Robotics requires lots of distributed compute; think self-driving cars, where the analysis of a scene and the motion of the vehicle needs to be done locally, but where all the data on traffic volumes and road conditions needs multiple data sources to be processed centrally. There are lots of other (often less exciting but just as important) applications that have similar requirements; retail food sales with smart checkouts (that part is all local) and stock management systems & shipping (that part is heavily centralized). In essence, sometimes it's easier to process the data where it's born, rather than move it somewhere else. Data is "sticky", and that sometimes dictates that the compute should be where the data lies. Equally, it's also true that the only way of making sense of distributed data is to centralize it; weather stations can't do weather forecasting, so it needs to be unstuck, collected up & transmitted, and then computed centrally.We hope you enjoyed this un-biased, vendor-neutral debate. You can check out the others in this series below:

• File vs. Block vs. Object Storage
• Fibre Channel vs. iSCSI
• FCoE vs. iSCSI vs. iSER
• RoCE vs. iWARP

Follow us @SNIAESF for more upcoming webcasts.

To date, thousands have watched our “Great Storage Debate” webcast series. Our most recent installment of this friendly debate (where no technology actually emerges as a “winner”) was Centralized vs. Distributed Storage. If you missed it, it’s now available on-demand. The live event generated several excellent questions which our expert presenters have thoughtfully answered here: Q. Which performs faster, centralized or distributed storage? A. The answer depends on the type of storage, the type of connections to the storage, and whether the compute is distributed or centralized. The stereotype is that centralized storage performs faster if the compute is local, that is if it’s in the same data center as the centralized storage. Distributed storage is often using different (less expensive) storage media and designed for slower WAN connections, but it doesn’t have to be so. Distributed storage can be built with the fastest storage and connected with the fastest networking, but it rarely is used that way. Also it can outperform centralized storage if the compute is distributed in a similar way to the distributed storage, letting each compute node access the data from a local node of the distributed storage. Q. What about facilities costs in either environment? Ultimately the data has to physically “land” somewhere and use power/cooling/floor space. There is an economy of scale in centralized data centers, how does that compare with distributed? A. One big difference is in the cost of power between various data centers. Typically, data centers tend to be the places where businesses have had traditional office space and accommodation for staff. Unfortunately, these are also areas of power scarcity and are consequently expensive to run. Distributed data centers can be in much cheaper locations; there are a number for instance in Iceland where geothermally generated electricity is very cheap, and environmental cooling is effectively free. Plus, the thermal cost per byte can be substantially lower in distributed data centers by efficiently packing drives to near capacity with compressed data. Learn more about data centers in Iceland here. Another difference is that distributed storage might consume less space if its data protection method (such as erasure coding) is more efficient than the data protection method used by centralized storage (typically RAID or triple replication). While centralized storage can also use erasure coding, compression, and deduplication, it’s sometimes easier to apply these storage efficiency technologies to distributed storage. Q. What is sharding? A. Sharding is the process of breaking up, typically a database, into a number of partitions, and then putting these pieces or shards on separate storage devices or systems. The partitioning is normally a horizontal partition; that is, the rows of the database remain complete in a shard and some criteria (often a key range) is used to make each shard. Sharding is often used to improve performance, as the data is spread across multiple devices which can be accessed in parallel. Sharding should not be confused with erasure coding used for data protection. Although this also breaks data into smaller pieces and spreads it across multiple devices, each part of the data is encoded and can only be understood once a minimum number of the fragments have been read and the data has been reconstituted on some system that has requested it. Q. What is the preferred or recommended choice of NVMe over Fabrics (NVME-oF) for centralized vs. distributed storage systems for prioritized use-case scenarios such as data integrity, latency, number of retries for read-write/resource utilization? A. This is a straightforward cost vs. performance question. This kind of solution only makes sense if the compute is very close to the data; so either a centralized SAN, or a (well-defined) distributed system in one location with co-located compute would make sense. Geographically dispersed data centers or compute on remote data adds too much latency, and often bandwidth issues can add to the cost. Q. Is there a document that has catalogued the impact of latency on the many data types? When designing storage I would start with how much latency an application can withstand. A. We are not aware of any single document that has done so, but many applications (along with their vendors, integrators, and users) have documented their storage bandwidth and latency needs. Other documents show the impact of differing storage latencies on application performance. Generally speaking one could say the following about latency requirements, though exceptions exist to each one:

• Block storage wants lower latency than file storage, which wants lower latency than object storage
• Large I/O and sequential workloads tolerate latency better than small I/O and random workloads
• One-way streaming media, backup, monitoring and asynchronous replication care more about bandwidth than latency. Two-way streaming (e.g. videoconferencing or IP telephony), database updates, interactive monitoring, and synchronous replication care more about latency than bandwidth.
• Real-time applications (remote control surgery, multi-person gaming, remote AR/VR, self-driving cars, etc.) require lower latency than non-real-time ones, especially if the real-time interaction goes both ways on the link.

One thing to note is that many factors affect performance of a storage system. You may want to take a look at our excellent Performance Benchmark webinar series to find out more. Q. Computation faces an analogous debate between distributed compute vs. centralized compute. Please comment on how the computation debate relates to the storage debate. Typically, distributed computation will work best with distributed storage. Ditto for centralized computation and storage. Are there important applications where a user would go for centralized compute and distributed storage? Or distributed compute and centralized storage? A. That’s a very good question, to which there is a range of not so very good answers! Here are some application scenarios that require different thinking about centralized vs. distributed storage. Video surveillance is best with distributed storage (and perhaps a little local compute to do things like motion detection or object recognition) with centralized compute (for doing object identification or consolidation of multiple feeds). Robotics requires lots of distributed compute; think self-driving cars, where the analysis of a scene and the motion of the vehicle needs to be done locally, but where all the data on traffic volumes and road conditions needs multiple data sources to be processed centrally. There are lots of other (often less exciting but just as important) applications that have similar requirements; retail food sales with smart checkouts (that part is all local) and stock management systems & shipping (that part is heavily centralized). In essence, sometimes it’s easier to process the data where it’s born, rather than move it somewhere else. Data is “sticky”, and that sometimes dictates that the compute should be where the data lies. Equally, it’s also true that the only way of making sense of distributed data is to centralize it; weather stations can’t do weather forecasting, so it needs to be unstuck, collected up & transmitted, and then computed centrally.We hope you enjoyed this un-biased, vendor-neutral debate. You can check out the others in this series below:

• File vs. Block vs. Object Storage
• Fibre Channel vs. iSCSI
• FCoE vs. iSCSI vs. iSER
• RoCE vs. iWARP

Follow us @SNIAESF for more upcoming webcasts.

To understand Swordfish, let’s start with the basics to examine how modern data centers are managed.

A user of a PC/notebook is assumed to be in control of that PC. What happens when there are two? Or 10? Or 1,000? Today’s modern data centers can have 100,000 computers (servers) or more! That requires the ability to be in control or “manage” them from a central location. How does one do that? It is done via a protocol that enables remote management; today that standard is IPMI, an acronym for Intelligent Platform Management Interface, and which has existed for 20 years. Among issues with IPMI is that the scale of today’s data centers was not fully envisioned 20 years ago, so some of the components of IPMI cannot cover the tens of thousands of servers it is expected to manage. The developers also did not foresee the stringent security and increased privacy requirements expected in modern data centers.

The DMTF created, and continues to improve upon, a modern alternative standard for remote or centralized management of data centers called Redfish®. For those familiar with server management, Redfish is referred to as “schema-based,” meaning that engineers have carefully organized many different categories of information as well as the relationships between them. Schema are structured to manage the millions of bits of information and operating characteristics that data centers create and report on a continuous basis and that managers monitor to understand the status of the datacenter. In this way, information on the operational parameters of the machines in the data center is provided, when and where needed, in a consistent, organized and reliable way.

Unlike IPMI, the new Redfish standard uses modern tools, allowing it to scale to the size of today’s modern data centers. Redfish has output language readable by datacenter operators, works across the wide variety of servers and datacenter equipment that exists today, and is extensible for the new hardware of tomorrow.

The Storage Networking Industry Association (SNIA) is a global non-profit organization dedicated to developing standards and education programs to advance storage and information technology. SNIA created the Storage Management Initiative Specification (SMI-S) currently in use in datacenters to manage interoperable storage. SNIA immediately recognized the value of the new Redfish standard and created SNIA Swordfish™, which is an extension to Redfish that seamlessly manages storage equipment and storage services in addition to the server management of Redfish. Just as most PC’s have one or more storage devices, so do most servers in datacenters, and Swordfish can manage storage devices and allocation across all of the servers in a datacenter in the same structured and organized fashion.

A summary and additional information for the more technical readers is below. If you want to learn more, all the items underlined and in bold below yield more information. You can click them, or type them into your internet browser for more information on the terms used in this tutorial:

• For security, Swordfish employs HTTPS, a well-known and well-tested protocol that is used for secure communications over the World Wide Web.
• JavaScript and ODATA increase the readability, compatibility and integration of RESTful API’s that manage data collected from datacenter devices and covers a range of information useful for beginners through experienced engineers.
• Interoperability exists due to the use of a common schema definition language (CSDL) and common APIs from eco-system partners including the Open Compute Project (OCP).
• Redfish and Swordfish were created and are maintained by industry leaders that meet weekly to tune and extend management capabilities. (See DMTF.ORG, SNIA.ORG)
• These schema work together to allow full network discovery, provisioning, volume mapping and monitoring of block, file and object storage for all the systems in a modern datacenter.

There is so much to learn beyond this brief tutorial. Start at DMTF.ORG to learn about Redfish. Then surf over to SNIA.ORG/SWORDFISH to see how Swordfish brings the benefits of schema-based management to all your storage devices. You will learn how Swordfish works in hyperscale and cloud infrastructure environments and enables a scalable solution that grows as your datacenter requirements grow.

By Barry Kittner, Technology Initiatives Manager, Intel and SNIA Storage Management Initiative Governing Board Member

To understand Swordfish, let’s start with the basics to examine how modern data centers are managed.

A user of a PC/notebook is assumed to be in control of that PC.  What happens when there are two? Or 10? Or 1,000? Today’s modern data centers can have 100,000 computers (servers) or more! That requires the ability to be in control or “manage” them from a central location.  How does one do that?  It is done via a protocol that enables remote management; today that standard is IPMI, an acronym for Intelligent Platform Management Interface, and which has existed for 20 years.  Among issues with IPMI is that the scale of today’s data centers was not fully envisioned 20 years ago, so some of the components of IPMI cannot cover the tens of thousands of servers it is expected to manage.  The developers also did not foresee the stringent security and increased privacy requirements expected in modern data centers.

The DMTF created, and continues to improve upon, a modern alternative standard for remote or centralized management of data centers called Redfish®.  For those familiar with server management, Redfish is referred to as “schema-based,” meaning that engineers have carefully organized many different categories of information as well as the relationships between them.  Schema are structured to manage the millions of bits of information and operating characteristics that data centers create and report on a continuous basis and that managers monitor to understand the status of the datacenter.  In this way, information on the operational parameters of the machines in the data center is provided, when and where needed, in a consistent, organized and reliable way.

Unlike IPMI, the new Redfish standard uses modern tools, allowing it to scale to the size of today’s modern data centers. Redfish has output language readable by datacenter operators, works across the wide variety of servers and datacenter equipment that exists today, and is extensible for the new hardware of tomorrow.

The Storage Networking Industry Association (SNIA) is a global non-profit organization dedicated to developing standards and education programs to advance storage and information technology. SNIA created the Storage Management Initiative Specification (SMI-S) currently in use in datacenters to manage interoperable storage. SNIA immediately recognized the value of the new Redfish standard and created SNIA Swordfish, which is an extension to Redfish that seamlessly manages storage equipment and storage services in addition to the server management of Redfish.  Just as most PC’s have one or more storage devices, so do most servers in datacenters, and Swordfish can manage storage devices and allocation across all of the servers in a datacenter in the same structured and organized fashion.

A summary and additional information for the more technical readers is below. If you want to learn more, all the items underlined and in bold below yield more information. You can click them, or type them into your internet browser for more information on the terms used in this tutorial:

• For security, Swordfish employs HTTPS, a well-known and well-tested protocol that is used for secure communications over the World Wide Web.
• JavaScript and ODATA increase the readability, compatibility and integration of RESTful API’s that manage data collected from datacenter devices and covers a range of information useful for beginners through experienced engineers.
• Interoperability exists due to the use of a common schema definition language (CSDL) and common APIs from eco-system partners including the Open Compute Project (OCP).
• Redfish and Swordfish were created and are maintained by industry leaders that meet weekly to tune and extend management capabilities. (See DMTF.ORG, SNIA.ORG)
• These schema work together to allow full network discovery, provisioning, volume mapping and monitoring of block, file and object storage for all the systems in a modern datacenter.

There is so much to learn beyond this brief tutorial.  Start at DMTF.ORG to learn about Redfish.  Then surf over to SNIA.ORG/SWORDFISH to see how Swordfish brings the benefits of schema-based management to all your storage devices.  You will learn how Swordfish works in hyperscale and cloud infrastructure environments and enables a scalable solution that grows as your datacenter requirements grow.

By Barry Kittner, Technology Initiatives Manager, Intel and SNIA Storage Management Initiative Governing Board Member