Clustered Samba: Difference between revisions

From SambaWiki
(intro)
 
(the locking problem)
Line 7: Line 7:
Each node has its own [[smbd]] daemon - they should communicate with each other to avoid shared data corruption, treat [[oplock|oplocks]] and so on.
Each node has its own [[smbd]] daemon - they should communicate with each other to avoid shared data corruption, treat [[oplock|oplocks]] and so on.
So the most problem is the extending of the [[locking]] subsystem ([[share mode locks|share mode locks]], [[oplock|opportunistic locks]], [[byte-range lock|byte-range locks]]) to multi-node system and cluster point of view.
So the most problem is the extending of the [[locking]] subsystem ([[share mode locks|share mode locks]], [[oplock|opportunistic locks]], [[byte-range lock|byte-range locks]]) to multi-node system and cluster point of view.

== The Locking Problem ==

Here we'll gather information on how locking mechanisms are done in [[Samba3]].

Present locking mechanism uses single ''locking.tdb'' (database with shared information - share mode entries, [[deferred open]] entries, flags, etc) for all [[smbd]] processes:

[[Image:samba locking 1.png]]

On [[Cluster|clustered systems]] internal [[messaging]] can be used to interconnect [[smbd]] processes and locking databases:

[[Image:samba locking 2.png]]

This approach implies too many messaging opearations between [[smbd]] processes while locking/unlocking a file. They can be reduced noticeably if all locking information is stored on the one node - with the [[locking daemon]]:

[[Image:samba locking 3.png]]

Revision as of 09:06, 10 May 2006

Current Samba implementations can't be used directly on clustered systems cause it is oriented to single-server systems. The main reason is that smbd processes use TDB (local-oriented database) for messaging, storing shared data, etc - there is no way to coordinate smbd processes run on different cluster nodes.

Simple clustered samba system looks like this:

Clustered samba.png

Each node has its own smbd daemon - they should communicate with each other to avoid shared data corruption, treat oplocks and so on. So the most problem is the extending of the locking subsystem (share mode locks, opportunistic locks, byte-range locks) to multi-node system and cluster point of view.

The Locking Problem

Here we'll gather information on how locking mechanisms are done in Samba3.

Present locking mechanism uses single locking.tdb (database with shared information - share mode entries, deferred open entries, flags, etc) for all smbd processes:

Samba locking 1.png

On clustered systems internal messaging can be used to interconnect smbd processes and locking databases:

Samba locking 2.png

This approach implies too many messaging opearations between smbd processes while locking/unlocking a file. They can be reduced noticeably if all locking information is stored on the one node - with the locking daemon:

Samba locking 3.png