Difference between revisions of "Topology"
From MosixWiki
Line 7: | Line 7: | ||
MOSIX can make better migration decisions when it has a good estimate of | MOSIX can make better migration decisions when it has a good estimate of | ||
the overheads involved in running processes away from home: the program | the overheads involved in running processes away from home: the program | ||
− | tune, with its front-end tune_mosix, can be used to measure | + | tune, with its front-end tune_mosix, can be used to measure 7 different |
constants that reflect those overheads between any given two nodes. | constants that reflect those overheads between any given two nodes. | ||
− | Those | + | Those constants depend on various factors such as network speed and |
latency, processor type, memory type, network card, whether a VPN layer | latency, processor type, memory type, network card, whether a VPN layer | ||
is used on top of the IP protocol, etc. | is used on top of the IP protocol, etc. | ||
Line 26: | Line 26: | ||
sured constants that applies uniformly to all nodes. To override this | sured constants that applies uniformly to all nodes. To override this | ||
default, the system-administrator needs to create the file: | default, the system-administrator needs to create the file: | ||
− | /etc/mosix/ | + | /etc/mosix/newtune (once that file is created or modified, MOSIX will |
automatically update its topology within one minute). | automatically update its topology within one minute). | ||
− | Each line in /etc/mosix/ | + | Each line in /etc/mosix/newtune should contain 10 space-separated inte- |
− | gers: | + | gers: 7 are the overhead constants (generated by tune_mosix) and 3 are |
topological conditions (see below) that describe to which node(s) those | topological conditions (see below) that describe to which node(s) those | ||
− | overhead constants apply (the last line can have only | + | overhead constants apply (the last line can have only 7 constants, mak- |
ing it unconditional). | ing it unconditional). | ||
− | + | ||
To decide which overhead constants apply for a given node, MOSIX scans | To decide which overhead constants apply for a given node, MOSIX scans | ||
the above conditions, starting with the first line and proceeding down | the above conditions, starting with the first line and proceeding down | ||
Line 84: | Line 84: | ||
mosix(7). | mosix(7). | ||
− | MOSIX | + | MOSIX February 2009 MOSIX |
Revision as of 11:26, 22 February 2009
TOPOLOGY(M7) MOSIX Description TOPOLOGY(M7) NAME TOPOLOGY - incorporating networking overheads in MOSIX TUNING MOSIX can make better migration decisions when it has a good estimate of the overheads involved in running processes away from home: the program tune, with its front-end tune_mosix, can be used to measure 7 different constants that reflect those overheads between any given two nodes. Those constants depend on various factors such as network speed and latency, processor type, memory type, network card, whether a VPN layer is used on top of the IP protocol, etc. INTRODUCING TOPOLOGY The overheads of running a process away from its home may not be uniform across the cluster or multi-cluster grid: the topology is therefore defined as a set of overhead constants measured between the local node and a subset of other nodes. MOSIX supports up to 10 topologies, allow- ing each node to define up to 10 sets of overhead constants, measured between itself and different sets of nodes in the cluster and/or multi- cluster grid. MOSIX comes with a built-in single default topology - a set of pre-mea- sured constants that applies uniformly to all nodes. To override this default, the system-administrator needs to create the file: /etc/mosix/newtune (once that file is created or modified, MOSIX will automatically update its topology within one minute). Each line in /etc/mosix/newtune should contain 10 space-separated inte- gers: 7 are the overhead constants (generated by tune_mosix) and 3 are topological conditions (see below) that describe to which node(s) those overhead constants apply (the last line can have only 7 constants, mak- ing it unconditional). To decide which overhead constants apply for a given node, MOSIX scans the above conditions, starting with the first line and proceeding down the list until a condition is found that is satisfied by the given node (if no condition is satisfied, the first line is selected). TOPOLOGICAL CONDITIONS Topological conditions consist of three numbers (unsigned 32-bit inte- gers), named: FIRST, LAST, and FEATURES. FIRST and LAST are IP addresses, while FEATURES is a bitmap (1st symbol in /etc/mosix/features is 1, 2nd symbol is 2, 3rd symbol is 4, etc.). The IP addresses are rep- resented as an unsigned integer in host order, so for example, IP address 123.45.67.89 is represented as: ((123*256+45)*256+67)*256+89 = 2066563929 To test whether a given node satisfies a condition, we consider both its IP address ("IP") and its features ("F"): the features are configured in /etc/mosix/myfeatures (see below) and are 0 if that file does not exist. The table below covers all the 5 possible combinations of FIRST and LAST, describing when a condition is satisfied by a given node: FIRST == LAST == 0 Always: unconditional FIRST == 0; LAST != 0 (F & FEATURES) != 0 LAST == 0; FIRST != 0 IP != FIRST && ~(F & FEATURES) 0 < FIRST <= LAST FIRST <= IP <= LAST || (F & FEATURES) FIRST > LAST > 0 (IP < FIRST || IP > LAST) && ~(F & FEATURES) CONFIGURING FEATURES The features of a node are listed in the file /etc/mosix/myfeatures by a comma-separated list of symbols, selected out of the 32 symbols in the file /etc/mosix/features. These symbols have no particular meaning other than to aid in construct- ing useful combinations of topological conditions. It is up to the multi- cluster system-administrators to agree between them on conventional mean- ings to those symbols. System-administrators are also allowed to modify those symbols if they wish, provided that they keep /etc/mosix/features the same throughout the multi-cluster Grid (if they do so, they must remember to restore that file after upgrading to a new version of MOSIX). SEE ALSO mosix(7). MOSIX February 2009 MOSIX