Lock Manager Rotation in Multi-Core SANs

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

In storage area networks (SANs), centralized lock managers can become bottlenecks in multi-core or multi-processor environments, leading to potential data corruption and system failures due to the inability to efficiently manage interlock requests and state information across multiple hosts accessing shared storage volumes.

Innovation Solution

Implementing a lock manager that dynamically moves between processors based on IO counts or operational time to prevent bottlenecks, utilizing a storage services module (SSM) and software layers to manage interlock requests and state information, and employing multi-core processors for high-speed communications.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If a centralized lock manager is used in a multi-core SAN environment, then data consistency can be maintained, but processor bottlenecks and system performance degradation occur

Engineering Contradiction:
Improvedata consistencyVSAvoidsystem performance
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The patent implements a dynamic lock manager rotation mechanism where the lock manager role is transferred between different cores based on operational time thresholds or IO count thresholds. This prevents any single core from becoming a persistent bottleneck while maintaining data consistency through proper lock management. The system dynamically adapts the lock manager's location rather than assigning it statically to one core.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The lock manager role is periodically transferred between cores based on predetermined criteria (time thresholds or IO count thresholds). This periodic rotation ensures that no single core handles all lock management operations continuously, distributing the computational burden and preventing processor bottlenecks while maintaining reliable lock management across the multi-core system.

Inventive Principle:
Principle #19Periodic action

2Productivity

If lock manager rotation is implemented to prevent bottlenecks, then system performance improves, but system complexity increases

Engineering Contradiction:
Improvesystem performanceVSAvoidlock management complexity
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The system employs feedback mechanisms through counters that track operational time and IO processing counts for each core. When a core reaches a predetermined threshold, the lock manager role is automatically transferred to another core. This feedback-driven approach simplifies the rotation logic by using straightforward threshold comparisons rather than complex scheduling algorithms, making the system easier to implement and manage.

Inventive Principle:
Principle #23Feedback

Solution Approach 2:

The lock manager rotation is implemented as an automatic self-managing process where cores monitor their own operational metrics (time spent as lock manager, number of IOs processed) and trigger their own role transfer when thresholds are reached. This eliminates the need for external management or complex centralized control logic, reducing overall system complexity while maintaining performance benefits.

Inventive Principle:
Principle #25Self-service

Data Source

PatentUS7844784B2Lock manager rotation in a multiprocessor storage area network
Publication Date: 2010.11.30 CISCO TECHNOLOGY INC
  • US7844784B2 patent drawing
  • US7844784B2 patent drawing
  • US7844784B2 patent drawing

AI summary

In one embodiment, a solution is provided wherein a lock manager is kept moving among multiple cores or processors in a multi-core or multi-processor environment. By “hopping” the lock manager from processor to processor, a bottleneck at any of the processors is prevented. The frequency of movement may be based on, for example, a counter that counts the number of input/outputs handled by the lock manager and moves the lock manager to a different processor once a determined threshold is met. In another embodiment of the present invention, the frequency of the movement between processors may be based on a time that counts the amount of time the lock manager has been operating on the processor and moves the lock manager to a different processor once a predetermined time is reached.