General architecture
From Ceph wiki
Jfchevrette (Talk | contribs) |
m (→The client: typo) |
||
| Line 26: | Line 26: | ||
=== The client === | === The client === | ||
| - | Not | + | Not actually a daemon, but it must be mentioned here. The client accesses and uses the file system. It can be a kernel module, a fuse module or a simple command line program (ie [[csyn]]). For a client to be able to access the file system it requires a connection to a monitor daemon. [[client|See more]]. |
Latest revision as of 16:14, 14 November 2010
The ceph distributed file system is composed of multiple daemons running on one or more machines. Here's a general overview of a ceph system architecture:
The following lists all the daemons and their interactions.
Contents |
List of daemons
3. cmds
4. The client
Description of each daemon
The monitor daemon
The Ceph monitor cluster handles critical cluster state and configuration information. Monitor state is managed using a modified version of the Paxos part-time parliament algorithm in order to provide strict data integrity guarantees and scalable read access. Among other things, it tracks the list of osds and their current state and through it the clients are able to connect to the distributed file system. See more.
The object store daemon
The object store daemon has the job of actualy storing data in a partition/hardisk/file directory, so as stated above it's the building block of the system. You will probably have one of these running for each used partition/hard drive/directory See more.
The cmds daemon
To be written
The client
Not actually a daemon, but it must be mentioned here. The client accesses and uses the file system. It can be a kernel module, a fuse module or a simple command line program (ie csyn). For a client to be able to access the file system it requires a connection to a monitor daemon. See more.
