SCSI Acceleration Service in SAN via Redirect Table
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current SCSI acceleration techniques in storage area networks (SAN) require awkward network topologies and manual configuration to function effectively, especially across MAN and WAN links, due to bidirectional SCSI I/Os and the need for traffic to traverse the same endpoints, leading to increased latency and performance issues.
Innovation Solution
The implementation of a SCSI acceleration service in a SAN using a routing device with a processor and memory, which receives and redirects write operations based on a shared redirect table, allowing the acceleration service to be performed between initiating and target devices across a network link, abstracting Fibre Channel and Fibre Channel over IP write acceleration techniques away from transport endpoints, and enabling transparent operation without manual configuration or network rewiring.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If SCSI acceleration techniques are implemented at the end points of two sites over MAN or WAN, then write acceleration is achieved, but awkward network topologies are required and traffic flows must traverse the same end points in both directions
Solution Approach 1:
A redirect table is introduced as an intermediary mechanism that sits between the initiating device and target device. The redirect table contains source/destination address pairs that are translated to redirected source/destination address pairs, allowing write operations to be redirected to acceleration services without requiring complex endpoint configurations. This intermediary redirect table absorbs the topology complexity, enabling simple endpoint connections while achieving acceleration.
2Productivity
If traffic flows are forced to traverse the same endpoint nodes for acceleration techniques to function, then SCSI acceleration is achieved, but manual configuration and network rewiring are required
Solution Approach 1:
The acceleration service implements self-service through automatic address translation. When a write operation is initiated, the redirect table automatically translates the source/destination address pairs to the appropriate redirected address pairs without requiring manual configuration at the endpoints. The system self-adapts to routing changes and automatically manages the acceleration traffic flows, eliminating the need for manual network rewiring or configuration.
Solution Approach 2:
The redirect table dynamically changes address parameters (source/destination address pairs) based on the specific write operation. Instead of requiring fixed network topology or manual configuration, the system changes the address parameters on-the-fly to route traffic through the acceleration service. This parameter-based routing allows the same physical infrastructure to support multiple acceleration scenarios without reconfiguration.
3Speed
If Fibre Channel or Fibre Channel over IP connections are used to interconnect SANs, then high-speed data transfer is achieved, but latency is introduced over MAN and WAN links
Solution Approach 1:
The redirect table performs preliminary action by pre-establishing the address translation mappings before actual write operations occur. When write operations are initiated, the translation is already in place, allowing immediate redirection to the acceleration service without waiting for runtime routing decisions. This preliminary setup of address mappings reduces the time required for each write operation to be routed through the acceleration service.
Data Source
AI summary
Techniques are disclosed for abstracting write acceleration techniques and tape acceleration techniques away from transport providers (e.g., away from an FC or FCIP interlink between two storage area networks) and allowing acceleration to be provided as a service by nodes within the storage area network (SAN). Doing so allows the acceleration service to be provided anywhere in the SAN. Further, doing so allows users to scale the acceleration service as needed, without having to create awkward topologies of multiple VSANS. Further still, as the acceleration service is offered independently from the transport, compression, encryption, and other services may be offered as part of the transport between the FC/FCIP connection along with the acceleration service.