The SNIA Data, Storage & Networking Community's AI Stack Webinar Series recently featured "Deconstructing the Storage Software Stack: From Legacy Silos to AI-Scale Architecture." In this live webinar, SNIA experts explored how the storage software stack is evolving to support the shift from traditional enterprise workloads to the massive scale and performance demands of AI pipelines.

Our presenters, Jayanthi Ramakalanjiyam of Celestica and Rohan Mehta of Micron Technology, joined moderator Luis Freeman of IBM for a lively discussion. The webinar generated more audience questions than time allowed, as promised, here are their answers.

Q: Could you elaborate on ““Implementation-based virtualization and Access-based virtualization are mutually exclusive. What does this mean in practice when designing custom enterprise solutions? 

A: This means that the structural layer where abstraction occurs (Host, Network, or Controller level) is fundamentally separate from how data is presented to the user application (Block, File, or Object). 

  • Any one of the three implementation layers can expose more than one access type. 
  • While this allows for 9 distinct combinations traversing multiple protocol paths, they are not all engineered equally in terms of latency, CPU overhead, or scalability. 
  • Architects are advised to stick to industry-proven "ideal paths"—such as Host + Block (via local NVMe/RDMA) or Controller + File/Object (via NFS/SMB Direct over RDMA). 
  • Deviating into non-standard combinations usually requires translation gateways and extra metadata hops, resulting in higher CPU costs that fail to scale efficiently in enterprise deployments. 

Q: From an engineering standpoint, how should we choose between designing our storage software stack around Data Indirection versus Data Redirection when managing snapshots and high availability?

A: The choice depends on whether your software stack is trying to map addresses or dynamically reroute live data traffic. 

  • Data Indirection should be utilized when you need to maintain a separate table mapping logical addresses to physical addresses. This is perfect for background data efficiency operations—like thin provisioning, flash wear leveling, and deduplication because it executes with zero disturbance to the application. 
  • Data Redirection should be selected when you need to physically intercept and shift active I/O requests to an entirely different path. This is ideal for managing high availability/failover states, or for creating highly efficient snapshots where newly written data is redirected to a new drive rather than copying existing data blocks. 

Q: When must an enterprise transition from a standard horizontal Scale-Out architecture to a Scale-Across infrastructure?

A: Horizontal Scale-Out architectures increase capacity by adding similar servers or racks to handle parallel processing. 

  • While theoretically infinite, Scale-Out is ultimately bounded by the physical limits of synchronization and networking interconnections between those distinct systems. 
  • When these boundaries are breached, or when data sovereignty demands it, you must move to a Scale-Across architecture to spread workloads across disparate environments and geographical locations. 
  • However, scaling across data centers forces you to design around a separate set of harsh limitations: high network latency, power availability constraints, and complex global laws or regulations. 

Q: Host-level virtualization is noted as the foundation for Hyper-Converged Infrastructure (HCI) and cloud-native storage, but it directly consumes host CPU and memory cycles. How do we scale this model without starving workloads of compute power? 

A: To prevent host-level virtualization from draining compute resources away from primary applications, you must incorporate hardware-agnostic performance acceleration layers. 

  • This is achieved by utilizing Kernel/CPU Bypass architectures facilitated by intelligent NICs or specialized Host Bus Adapters (HBAs). 
  • Deploying Ethernet NICs equipped with RDMA over Converged Ethernet (RoCEv2) or iWARP capabilities allows the host to bypass traditional kernel networking stacks. 
  • Transitioning to these "Lane 1" pathways guarantees zero-copy (or near zero-copy) data transfers and exceptionally low CPU usage per I/O operation. 

Q: For enterprise SAN data centers that must integrate legacy Fibre Channel (FC) block hardware with modern NVMe over Fabrics (NVMe-oF), which virtualization layer is best suited to handle this complexity? 

A: There are two primary choices depending on where we want to anchor the storage intelligence. 

  • Controller-Level Virtualization is highly effective because a primary array controller can natively pool its own capacity with connected, multi-vendor arrays. It abstracts structural complexity entirely, masking vendor differences so the host servers only see simple, uniform volumes. 
  • Network-Level Virtualization places the intelligence directly within switches sitting between initiators and targets across the fabric. This layer intercepts and redirects I/O requests across massive SAN environments, making it highly adept at managing thin provisioning and automated tiering (SSD to HDD) natively across disparate, multi-vendor physical backends. 

Q: Is Fibre Channel surviving in the AI Data Center. Looks like it's all Ethernet these days?

A: Yes, Fibre Channel (FC) is surviving in AI data centers, but not as the primary fabric for AI training or inference.

FC remains a strong enterprise block-storage transport: deterministic, lossless, low-latency, and deeply embedded in SAN environments. That still matters for databases, virtualization platforms, enterprise applications, regulated datasets, and existing arrays.

But the GPU tier in modern AI clusters usually consumes data through file, object, or data-service interfaces over Ethernet or InfiniBand/RDMA fabrics. Training datasets, checkpoints, model artifacts, and pipelines generally expect file/object semantics, not raw FC LUNs.

In brownfield environments, FC often remains important because valuable source data already lives on FC attached arrays. In that case, you typically add a data-service layer (e.g., NAS head, parallel filesystem, cache, staging tier, or array-native file/object interface) that exposes the data to the AI environment in the form the GPU cluster can consume. FC is not used there because the AI workload needs FC specifically; it’s used there because the enterprise data already lives behind FC.

In a greenfield AI-only environment, I would not introduce FC by default. Start with the access model AI actually needs: high-throughput file, object, or parallel filesystem storage over Ethernet or InfiniBand. Adding FC means operating a separate SAN fabric plus some block-to-file/object presentation layer, which is unnecessary unless you have a specific enterprise block-storage requirement.

Q: What company has implemented virtualization at the network level? 


A: The following are some of companies we are aware of. There could be other players as well. The list is not to endorse any company’s product but to highlight the different implementations of network virtualization.

Dell-EMC VPLEX, IBM SVC and DataCore have implemented network virtualization sitting directly in the data path to meet the requirements of enterprise data center. Companies like Hammerspace, DDN, Weka, VAST, Lightbits, etc. have implemented network virtualization to meet the high-performance requirements of the AI pipeline. The use cases and architecture of these implementations might vary from one another.

We recommend you go through the details of the offerings provided by the different companies and find the right one that matches your requirements.

Q: Data tiering and auto tiering both are the same, right?

A: Yes, as we discussed during the webinar, conceptually both terms refer to moving data between different categories of storage based on cost, capacity, and performance requirements. The major difference lies in the execution. Traditional data tiering typically relies on static, scheduled policies (such as a script moving files at midnight). In contrast, modern auto-tiering is built directly into the software fabric of the data center. It works autonomously and dynamically in real-time, instantly promoting or demoting data based on live usage patterns to ensure application performance never drops.

Q: With AI workloads demanding massive sequential throughput, are traditional storage controllers becoming a bottleneck, or have they kept pace?

A: Yes, traditional controllers would have been a bottleneck for AI workloads. But modern SSD controllers (and emerging architectures) have evolved significantly to keep pace. Briefly speaking, modern controllers support optimizations for both Read and Write - sequential reads with pre-fetch and sequential writes with hardware developments like TLC and QLC combined with SLC cache. 

Other developments include:

  • NAND channels: somewhat analogous to TCP streams
  • Sequential Read pre-fetch/read ahead (mentioned above)
  • Write-buffering at SLC (folding) for TLC and QLC (mentioned above)
  • Host-device co-design (NVMe features, zoned storage, KV interfaces)
  • Data path specializations for sequential + streaming workloads

Stay Connected!

This webinar is part of the SNIA Data, Storage & Networking Community’s “AI Stack” webinar series. We encourage you to register for our upcoming sessions and view our on-demand webinars in this series.

Up Next:

On-Demand:

We hope you will continue to participate in our educational webinars. Follow us for upcoming dates and topics on LinkedIn and @SNIA.