Symphonic Cooperative Flash Management targets a variety of system software stacks such as:
- Purpose-Built storage systems, including block level SAN arrays or file based appliances, including architectures that may have originally been designed around HDD technology
- All-Flash Arrays built from the ground up specifically for Flash
- Hybrid SSD/HDD systems with optimized tiering
- Advanced local file systems
- Software-Defined Storage architectures
- Hyperconverged systems
- Object/Key Value Stores
- Certain In-Memory & NoSQL data bases
- Server or Storage system Flash caching
System software is the result of a considerable R&D investment, and can include a range of advanced services from replication and mirroring to thin provisioning and deduplication.
These services may be integrated with the system’s core space management, and serve a larger objective in terms of design decisions made in the specific implementation. As an example, a system may perform space reclamation in a certain manner to facilitate more efficient snap shots.
Understanding these factors, Symphonic:
- Minimizes required modifications to existing system software
- Provides a platform to exploit the system’s intelligence and existing capabilities
- Minimizes the tuning efforts for these systems to optimize for Flash memory, even if they were not explicitly designed to target Flash memory
Most purpose-built storage systems, either block or file level, have implemented some variant of a log structured approach to overcome write latency. This provides a natural path towards directly performing Flash management, just as Flash-Translation-Layers (FTLs) are also log structured.
However, these advanced systems are unlikely to understand the opposing design trade-offs related to optimize around Flash memory. The Symphonic Address Configurator facilitates this optimization with minimal impact to the existing system.
Systems built from the ground up specifically for Flash, and utilizing SSDs, generally take approaches to overcome FTL driven latency spikes. In many cases, this can involve performing all writes in full stripes. Performing all writes in full stripes can reduce spikes induced by garbage collection, but not the majority of latency spikes. The approach also comes at a steep cost in terms of additional, system-level overprovisioning of the SSD capacity. This increases acquisition costs, and increases the degree of valid data relocation (write amplification), wearing the Flash out faster.
By operating in host address space and providing cooperative garbage collection, Symphonic enables far superior latency QoS without the overprovisioning or wear out associated with full stripe writes.
Hybrid SSD/HDD Systems
Some of Symphonic’s greatest advantages can be realized in hybrid systems that combine Flash SSDs and HDDs. These systems perform analysis on data access frequency, typically migrating cold data to slower HDD storage and more frequently accessed data to Flash SSDs. However, SSDs are internally performing a similar, redundant process in their own garbage collection process.
Because Symphonic is performing garbage collection under cooperative host control, it enables the host to integrate and optimize data migration for tiering with the valid data relocation process required by Flash garbage collection.
These synergies are further extended with the use of SMR HDD technology that requires many of the same management processes required by Flash storage, aligning with Symphonic from a process perspective and in terms of data layout and system tuning considerations.
inducing latency spikes that can only be overcome with more overprovisioning. As Software Defined Storage is largely focused on cost reduction, SSD FTL overprovisioning is already imposing an artificial cost increase, and when this storage has to be overprovisioned again at the system level it undermines the Flash value proposition.
Symphonic optimally addresses Software-Defined Storage requirements by providing deterministic latency at the highest traffic bandwidths, with <3% device overprovisioning.
Originally gaining popularity in hyperscale data centers, Software-Defined Storage moves certain advanced functionality that would have been found in a purpose-built array into the software-defined network to reduce costs and improve scalability. These services can involve replication, load balancing, and provisioning to be handled by distributed software frameworks. But operating services at this scale can negatively impact performance.
Flash has played a critical role for Software-Defined Storage in gaining larger adoption, especially beyond cold storage and archiving. The higher performance from a low latency Flash tier improves response times, helping offset the overhead from the SDS layer. But even with load balancing, the replication strategies required by Software-Defined Storage can concentrate high intermittent traffic to specific nodes,
Many servers have employed what is being called a hyperconverged architecture, where primary storage is resident in the same appliance that hosts the primary application, and potentially providing shared network access to the storage.
An obvious limitation of a hyperconverged approach is the constraint on local system resources, including CPU, system memory, and memory I/O. Because Symphonic turns the SSD into an offload engine, it not only scales SSDs in a system with linear performance metrics, but it offloads metadata generation from the host complex, freeing resources for the resident application.
Many systems employ caching specifically designed for Flash, to extract the maximum benefit from the Flash storage while minimizing costs. This can involve a pure read cache, to minimize wear out, or using the Flash as a write cache, or both. In any advanced Flash caching architecture, the caching software will attempt to write to the SSD in a particular segment size, and often attempt to match the segment size to the FTL’s internal segment or stripe size. But while many FTL SSDs expose an optimal stripe size, it is generally not configurable. So the caching strategy and algorithm will need to work around both the FTL’s predetermined segmentation, and how the FTL organizes the physical data layout and parallelization. These restrictions limit the range and consequently the effectiveness of the caching policies.
Symphonic enables the host system to control optimal segment sizes, preserves the system’s data layout, and offers a range of possibilities provided by its Address Configurator.