forked from sheepdog/sheepdog
-
Notifications
You must be signed in to change notification settings - Fork 0
shepherd design note
mitake edited this page Mar 11, 2013
·
4 revisions
This document describes the design and the status of shepherd.
If you are a long user of sheepdog, you would know that shepherd is an old name of collie. The name is recycled.
shepherd is a cluster manager specially designed for sheepdog. It cannot be used for other distributed systems. So the source code is tightly integreted with sheepdog. With this integration, shepherd can utilize internal knowledge of sheepdog. e.g. we can use struct sd_node in the source code of shepherd.
- Leaving of nodes are treated as an event processed in event_loop() like other events. shepherd use eventfd() for this purpose. remove_efd is the fd and remove_handler() is the handler.
- list of sheeps is managed as a liked list of struct list_head. The head is sheep_list_head, and struct sheep is a type of object for representing sheeps. struct sheep has struct sd_node as its member.
- messages are defined in include/shepherd_msg.def. The .def file is included by other files and expanded with custom MSG() macros. This coding style can reduce the overhead of keeping consistency between messages and its string representations by hands.
- Current shepherd can pass all tests.
- Sometimes shepherd dies with undeterministic bugs.
- Bug fixes.
- More human friendly log messages.
- Make shepherd redundant with corosync. Currently it is a SPOF of sheep cluster.
- Remoev master election mechanism. Under management by shepherd, no sheep must work as a master node. Because cluster information like latest epoch can be managed by shepherd. In other words, sheeps don't have to call sd_check_join_cb().