Simulation of Hierarchical Locking Protocol for iSCSI SAN File Sharing

1
Simulation of Hierarchical Locking Protocol for
iSCSI SAN File Sharing

• Plan B Project
• Fang Zhang

2
Project Goal

• Implement a Simulation Model of Hierarchical
  Locking Protocol for iSCSI SAN file sharing with
  NS-2
• Measure locking performance (in terms of
  throughput, deadlocks) under different lock
  granularity, threshold values using the
  simulation model

3
Storage Area Networks

• Storage area networks (SANs) are designed to
  provide shared, remotely attached data storage.
• Fibre channel (FC) based SANs
• Dedicated connections between storage and
  processors,
• Low-latency, High-bandwidth
• iSCSI based SANs a cheaper alternative
• Use iSCSI protocol to transport SCSI protocols
  across TCP/IP can use existing WAN/LAN
• High-latency, Low-bandwidth

4
Overview of iSCSI SAN

• Client/Server Model
• Client a host system that issues requests to
  read or write data.
• The server a storage device that responds to
  client requests.
• A Storage Router
• Has a number of SCSI ports and a network
  interface
• Performs the mapping among initiators and the
  targets.

5
Disk File Sharing in iSCSI SANs

• iSCSI SANs deal with data blocks
• iSCSI SANs provide both File I/Os and Disk I/Os
  as all File I/Os result at a lower layer in Block
  I/Os
• Needs Locking Mechanism for Concurrency Control
• Choice of Locking Granularity Block Level
  vs. File Level
• Block level has more concurrency
• File level locking has less message traffic

6
Hierarchical Locking Protocol ( I )

• Data Items are organized into a hierarchy, each
  node of the hierarchy can be locked, locks are
  requested in root to leaf order
• Implicit locking of all lower level data items
  under the node of a higher level can with low
  lock overhead
• Co-existing coarse-grain and fine-grain locking
• Control mechanism at file level to block new
  request using threshold value to alleviate lock
  contentions among transactions

7
Hierarchical Locking Protocol ( II )

• Needs more lock modes than Non-Hierarchical
  Locking Protocol
• 
  Conflict table
• Shared (read) ---- S
• Exclusive (write) ---- X
• Intension Shared ---- IS
• Intension Write ---- IX

8
Simulation Model

Disk Application
TCP Agent
9
Global Lock Manager

• Allows locking and releasing all shared items
• Maintains data structures to represent locks on
  items
• Makes a transaction to wait for a lock if a lock
  cannot be given
• Deadlock detection
• Pick victim transaction to abort

10
Data Structures of Lock Manager

• Lock table
  
• Transaction table

11
Lock State Transitions
12
Deadlock Detection

• Classification of Deadlocks
• Normal Deadlocks each holds locks needed by the
  other
• Convert Deadlocks both read the same item, then
  upgrade to write
• Detect deadlock situations by detecting cycles in
  the Wait-For graph
• Detect deadlock whenever a lock request is
  blocked by others
• Only one transaction is allowed to wait in the
  convert queue, the second upgrade requestor has
  to abort
• Use both Lock Table and Transaction Table

13
Transaction Applications

• Create access pattern and write it into an input
  file
• Behavior Model
• Read from input file and send following requests
  to lock manager
• Begin a transaction
• Open a file(file name, read only/write,
  percentage)
• The total percentage of blocks in the file to be
  accessed is given to the Lock Manager for the
  study of threshold values
• Read/Write blocks
• End/Abort the execution
• Obey Strict 2PL
• Write-Back Policy
• write to local buffer before commit point to be
  recoverable
• Restart if asked by the lock manager

14
Implementation with NS-2
Client Application
Lock Manger Application
ClientApp Header
ClientApp Header
LMApp Header
LMApp Header
Modified TCP Agent
Modified TCP Agent
Application
Connector
ClientApp
LMApp
Delay
Queue
Agent
Trace
TCP
UDP
newTCP
15
Factors that affect Locking Performance

• The volume of message traffic
• The cost of deadlock
• Time spent on waiting for the lock that can not
  be granted immediately.
• They are determined by the access pattern of
  applications, the choice of granularity and the
  workload of the system. The intricacy of these
  factors makes it impossible to predict a better
  solution. Simulation is the only way to evaluate
  the locking performance under different locking
  strategies and access patterns.

16
Measure Performance by Simulation (I)

• Data item hierarchy used for iSCSI File Sharing
  in the simulation model
• File
• Group of Blocks
• Size of group of blocks is adjustable to
  accommodate different choices of lock
  granularity.
• Performance under different threshold values on
  the file level are also examined for blocking the
  new lock request when the percentage of granted
  lock plus the new request exceeds the threshold
  percentage to alleviate lock contentions and
  reduce deadlocks.

17
Measure Performance by Simulation (II)

• File Size 1GB, Block Size 8KB, total blocks
  128000
• Two different application access patterns are
  studied
• Pattern I -- each transaction will access 5 of
  the shared file, i.e. 6400 blocks. These blocks
  are accessed by the transaction in 20 batches,
  each of which starts from a random beginning
  block number, each batch of accesses are to 320
  data blocks with sequential addresses on the
  disk.
• Pattern II each transaction will access 2 of
  the shared file, i.e. 2560 blocks. These blocks
  are accessed by the transaction in 20 batches,
  each of which starts from a random beginning
  block number, each batch of accesses are to 128
  data blocks with sequential addresses on the
  disk.

18
Throughput VS. Group Size for Pattern I, II
19
Deadlocks VS. Group Size for Pattern I, II
20
Throughput VS. Groupsize under different
threshold Values
21
Deadlocks VS. Group size under different
threshold Values
22
Conclusion Remarks

• The basic results obtained for iSCSI SAN file
  sharing from the experiments can be summarized as
  follows.
• First, the correct choice of locking strategy
  depends on the expected access pattern and the
  overall system overload.
• Second, Hierarchical Locking provides a hybrid
  coarse-grain/fine-grain locking strategy. This
  flexibility in choosing locking granularity will
  greatly benefit different application access
  patterns.
• Third, using threshold at file level to control
  lock contentions extends the effectiveness of
  Hierarchical Locking as it is a very effective
  way of reducing deadlocks for fine-grain locking.

23
Future Work

• The performance of locking model is closely
  related to the application access patterns. more
  detailed study of application access patterns is
  crucial in studying locking performance.
• Implement caching and consistency control
  policies is also very necessary to further reduce
  locking overhead.
• In this project, the victim transaction will
  restart from the very beginning, a more efficient
  way is to restart to some checkpoint until the
  deadlock is resolved. This can also be done in
  the future work.
• Investigating alternative deadlock management
  schemes are also necessary as accurate deadlock
  detection costs too much space and time. All of
  those will benefit from simulation approach.