Difference between revisions of "Topology"
From MosixWiki
(New page: TOPOLOGY(M7) MOSIX Description TOPOLOGY(M7) '''NAME''' TOPOLOGY - incorporating networking costs in MOSIX '''TUNING''' MOSIX can make ...) |
|||
(2 intermediate revisions by one user not shown) | |||
Line 2: | Line 2: | ||
'''NAME''' | '''NAME''' | ||
− | TOPOLOGY - incorporating networking | + | TOPOLOGY - incorporating networking overheads in MOSIX |
'''TUNING''' | '''TUNING''' | ||
− | MOSIX can make better migration decisions when it | + | MOSIX can make better migration decisions when it has a good estimate of |
− | involved in running processes away from home | + | 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. | |
− | + | Since using tune can be tedious, a library of tuning-results for commonly | |
− | Since using tune | + | used combinations of processors and networks is provided. This library |
− | + | is in /etc/mosix/tunes, where each file contains 2 lines: the first | |
− | + | describes the computers and the network used to produce the results and | |
− | + | the second contains the 7 (space-separated) constants produced by tune. | |
− | + | ||
− | + | 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. | |
− | latency, processor type, memory type, network card, | + | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | '''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. | |
− | ing to | + | |
− | + | ||
− | + | ||
− | + | 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''' | ||
− | + | 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 == LAST == 0 Always: unconditional | ||
Line 64: | Line 71: | ||
FIRST > LAST > 0 (IP < FIRST || IP > LAST) && ~(F & FEATURES) | FIRST > LAST > 0 (IP < FIRST || IP > LAST) && ~(F & FEATURES) | ||
− | The features of a node are listed in /etc/mosix/myfeatures by a | + | '''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- | |
− | they | + | 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''' | '''SEE ALSO''' | ||
mosix(7). | mosix(7). | ||
− | MOSIX | + | MOSIX June 2008 MOSIX |
Latest revision as of 13:41, 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. Since using tune can be tedious, a library of tuning-results for commonly used combinations of processors and networks is provided. This library is in /etc/mosix/tunes, where each file contains 2 lines: the first describes the computers and the network used to produce the results and the second contains the 7 (space-separated) constants produced by tune. 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 June 2008 MOSIX