On February 13, 2019, the SNIA Cloud Storage Technologies Initiative (CSTI) presented a live webcast, Why Composable Infrastructure? Our goal was to clearly explain the reasoning behind, and the benefits of, composable infrastructure in an educational, vendor-neutral way. We believe our speakers, Philip Kufeldt and Mike Jochimsen, did just that. Now, as promised, Philip and Mike have answered the many interesting questions we received during the live event.
Q. Are composable infrastructure solutions incompatible with virtualized or containerized environments? Will these solutions only serve bare metal environments?
A. Composable infrastructure solutions will eventually work across any environment that supports the orchestration toolsets. There are no compatibility issues between virtualization/containerization and composable infrastructure, even if they fundamentally look at allocation of resources within a defined resource differently. For example, in a virtualized environment if the need for network bandwidth or storage capacity exceeds the capability of a given resource, a “larger” resource could be composed using the orchestration tools. It would then be managed within the virtualization layer like any other resource.
Q. Typically new technology adoption is slowed due to support within commercial operating systems. Are there changes needed in the major OS environments (Linux, Windows, VMware, etc.), that will need to be released before composable infrastructure solutions will be supported?
A. So the PCIe and Ethernet based fabrics are already well established and have great OS support. The storage world and networking worlds already deploy composable infrastructure. However, the newer standards such as Gen-Z, OpenCAPI, and CCIX will need both hardware and software support. ARM SoCs are showing up with CCIX HW and OpenCAPI is in the Power architecture. But this is just the early stage; switches, enclosures and components that support these standards are still in the offing. Furthermore the OS support for these standards is also unavailable. And finally the management mechanisms and composability software is also undefined. So we still are a good distance from the larger composable infrastructure being available.
Q. Are the data center orchestration tools currently on the market capable of building a composable infrastructure solution like you described?
A. The tools on the market are still in the early stages of providing this capability. Some are purpose built for specific environments while others encompass a wider set of environments, but lack some of the dynamic/automation capabilities. Also, there is work going on, or starting up, in standards bodies to define the APIs needed for orchestration to work in truly heterogeneous application, operating system and hardware environments.
Q. In composable environments, how does security scale with it, specifically, encryption? Encrypt everything? Or some subset of jobs that truly are only jobs requiring encryption?
A. Fabrics can be configured to be local and private relieving the need for encrypted transfers. However there will be new issues to contend with. For example, consider memory that was previously used in one configuration that was disassembled and then reused in another. Ensuring that memory is cleaned before reuse will become required to prevent information leakage.
Q. For Gen-Z, Pooled Memory or Memory from different Racks, what about the Latency issues? Local memories don’t have issues with latency?
A. Although Gen-Z supports longer distance interconnects, it does not mean that only long distance configurations will be utilized. Think of it as a set of tools in a toolbox. Some memories will be close for lower latencies and others will be farther to provide for 4th or 5th level caching.
Q. Is it more about declarative mapping of the components? At this point software and hardware are decoupled, so the messaging and logic are really the requirement for orchestration.
A. The orchestration layer provides a translation between a declarative and imperative state in composable infrastructure. It is responsible for gathering the requirements from the application (declarative – “this is what I want”), then identifying the capabilities of the components on the network and logically mapping them to create a virtual infrastructure (imperative – “this is how to do it”).
Q. As apps start to be built from microservices, which may run across different physical nodes, I would think this further raises performance challenges on disaggregated infrastructure. How this will impact things would be an interesting next topic.
A. Agreed. Although I believe microservices will actually be enhanced by composable infrastructure. Composable infrastructure in general will create smaller systems that more closely fit the needs of the service or classes of services that will run on them. Just as in a bin packing problem having smaller units tends to provide better utilization of the container.
Got more questions? Feel free to comment on this blog and we’ll answer.