Cluster Monitor: Difference between revisions
		
		
		
		
		
		Jump to navigation
		Jump to search
		
				
		
		
	
No edit summary  | 
				No edit summary  | 
				||
| Line 16: | Line 16: | ||
* [[S3 Buckets]]  | * [[S3 Buckets]]  | ||
* [[Ceph/Rados]]  | * [[Ceph/Rados]]  | ||
== How to set up ==  | |||
TODO: describe how to edit (settings) to connect to other nodes and authenticate (add at least a common secret and optionally a list of nodes in the cluster)  | |||
== How it works ==  | |||
Each node in the network knows all other nodes.  | |||
Also, there is a distributed key map that tracks which resource is claimed by whom:   | |||
* COLD items are not tracked in the list at all to save space  | |||
* SHARED and WRITE items are tracked together with their owners  | |||
* when a user claims WRITE, all other owners must confirm that they give up their SHARED status  | |||
* when a user claims SHARED, the WRITE owner must confirm that he gives up his SHARED status  | |||
* after you claimed your access, you can use the storage backend to read/write the data  | |||
Revision as of 19:55, 31 August 2025
The cluster monitor lets you scale out MemCP over multiple nodes. Here is what you can achieve:
- Multiple users: each user has his own database
 - One big user: Big tables are spread over multiple nodes
 - A mixture of both variants
 
Each database and each shard (the piece where a part of a table's data is stored) can be placed either:
- COLD: only in storage backend
 - SHARED: read-only on multiple nodes (e.g. the access table)
 - WRITE: exclusively on one node
 
Cluster monitors can coordinate all kinds of storage:
How to set up
TODO: describe how to edit (settings) to connect to other nodes and authenticate (add at least a common secret and optionally a list of nodes in the cluster)
How it works
Each node in the network knows all other nodes.
Also, there is a distributed key map that tracks which resource is claimed by whom:
- COLD items are not tracked in the list at all to save space
 - SHARED and WRITE items are tracked together with their owners
 - when a user claims WRITE, all other owners must confirm that they give up their SHARED status
 - when a user claims SHARED, the WRITE owner must confirm that he gives up his SHARED status
 - after you claimed your access, you can use the storage backend to read/write the data