New node joining in CrossTree 

Context in source publication

Context 1

... organizes many PCs together to form a Condor Pool. Nodes in Condor Pool can run tasks from other users or submit its tasks to spare nodes. Each Condor Pool has a single Central Management Node. It collects all the information about resources and tasks in the Condor Pool, and it carries out all the match and dispatch actions. Condor can make effective use of spare resources in the system. However, as long as the Condor nodes are controlled by the Central Management Node, its reliability and scalability is restricted. Node ID in CrossTree is formed based on the resources it provides. For example, if Node A provides the following resources, OpSys = WINNT Architecture = INTEL Memory = 256 MB DiskSpace = 4096 MB ...... Then A’s Node ID is, 0001 0001 0256 4096 The first 0001 represents for WINNT operating system, the following 0001 stands for INTEL architecture, ‘0256’ means this node provides 256M memory space for sharing, and 4G disk space as well. It’s only a conceptual example. In practice, memory and disk space will also be encoded, and the number of resources is more than four listed above. Using this method, the Node’s ID just corresponds to the resources it provides. The system architecture is organized as follows, (1) Nodes have same Node ID are collected together and built as trees, as shown in figure 1. (2) All the trees’ roots are connected with each other under full connection mode, called Cross part. In CrossTree, nodes in the same tree have same Node ID and provide same resources. Each tree represents a kind of resource and corresponding jobs can be run on any spare nodes in the tree. Nodes in CrossTree can be divided into two classes: the full-connection nodes (trees’ roots) and the tree nodes (excluding roots). For full-connection nodes, route table has two parts, (1) Full-connection route table. It records the other roots’ <ID , IP Address> pair. (2) Tree route table. There are some fields in the records. Such as, P1 (Parent’s IP), P2 (Grandparent’s IP), RP (Root’s IP), and < IP Address, Free, Level, FC >, which is collection of its child nodes. Here, ‘IP Address’ is the IP address of this child node. ‘Free’ indicates whether this child node is spare or not. ‘Level’ is a yardstick of this child’s height. It is used to maintain tree height balance when new nodes join the tree. ‘FC (Free Count)’ records the number of free nodes in all children of current node. When a request arrives at current node, if it is too busy, it will choose a node from its children whose FC field greater than zero, and forwards this request. For tree nodes, the route table includes only the tree route table. In order to improve system’s reliability, besides the tree route table, the direct children of full- connection nodes also maintain a copy of full- connection route table from their parents (the roots). Firstly, the joining node needs to know a full- connection node, called K, which exists in the system. It’s similar to the DHT system.When new node N joins, it acts as follows, (1) Based on the resources it provides, node N get its Node ID, noted as NID. (2) N sends JOIN request to node K with its own NID and IP Address. (3) K looks up NID in its full-connection route table, if found then go to (5), else go to (4). (4) K adds <NID, IP Address> pair to its own full- connection route table, and sends <NID, IP Address> to all the other full-connection nodes to update their route tables. Meanwhile, K sends its full-connection route table to N for N’s initialization. P1 and P2 fields of N’s Tree route table are set to NULL, RP field is set to its own IP. Go to (*). (5) K forwards the JOIN message to the found node F, and F will become N’s root node. (6) F checks its tree route table, if the child list is not full, then <IP,true,0,0> is added to F’s tree route table, and F sends a copy of its full-connection route table to N, go to (&). If the child list is full, go to (7). (7)Select a node M with the minimum Level value in the child list, and forward the JOIN message to it. (8) M checks its tree part route table, if the child list neither empty nor full, then adds <IP, true, 0, 0> to it, go to (&). If the child list is full, go to (7). If the child list is empty, go to (9). (9) Insert < IP, true, 0, 0 > into tree route table, set N’s P1 field to be the IP address of current node, set N’s P2 field to be P1 value of current node, set N’s RP field to be RP value of current node. Traveling up step by step through P1 field until reach the root node, all the nodes on the way should increase its corresponding FC field by 1, and Level field increased by 1 as well. Go to (*). (&) Set N’s P1 field to be IP address of current node, set N’s P2 field to be P1 value of current node, set N’s RP field to be RP value of current node. Traveling up step by step through P1 field until reach the root node, all the nodes on the way should increase its corresponding FC field by 1. (*) Node N joining procedure is over. The procedure is shown in figure 2. When Node E decides to leave, it acts as follows: (1)The tree is searched until one of E’s deepest leaf node, named P, is gotten. (2)Move P from leaf to E’s position, copy E’s tree route table to P. If E is the root node or root’s child node, full-connection route table is also copied to P. (3) Update the P1 of all E’s children, make P1 point to their new parent P. If E is the root node, P need broadcast its IP address to all the other full-connection nodes. The procedure is shown in figure 3. When a full-connection node is doing the routing job, it may find that the target full-connection node fails to respond. At this time, it only sends this request to another tree which can provide enough resources, marks the leaving node as ‘disabled’ and start a timer for it. If this node receives response from the disabled node before the timer expires, then the disabled node returns to normal state again, else it would be deleted from the route table as soon as the timer expires. In fact, as long as the tree where the disabled node lies is not empty, due to the tree’s self-repair mechanism described in the next sector, a leaf node will soon replace the leaving node and update the route table of all the other full-connection nodes. Only when the leaving node is the last node of the tree, its failure will cause the tree vanish from the system. Alive detection between tree nodes is the main part of CrossTree’s structure maintenance. In each tree, every node periodically sends keep-alive packets to its parent node to ensure its haleness. The reasons that alive detection is used include: (1) Maintain the integrity of the tree structure When node realized that its parent node has been disabled, it will launch a corresponding process, as described in the next section, to deal with this case. Finally, a leaf node will be lifted up to replace the leaving node. (2) Ensure all the status information up to date Another important task that alive detection responsible for is to ensure all the status information of the tree is up to date. Along with the keep-alive packets, the sending node’s FC and Level fields are also sent to its parent node, thus during a single detection period, the parent node collects all its children’s FC field and Level field and then update itself to keep them up to date. When node E turns to be unreachable because of some unexpectable reasons, E’s direct children (noted as collection S) will sense this failure depended on detection mechanism. These nodes act as follows: (1)S send their own <Level, Free, IP> to their grandparent node Q (P2 pointes), or send to the first node Q in its copy of the full-connection route table if the failure node E is the root node. (2)When node Q receives these requests, it will perform arbitration and select node T which has the largest Level value in S. Q requires T for its deepest leaf node. T forwards this request to its deepest leaf node Z. Z send its own IP address to node Q. (3)Move Z from leaf to E’s position, and set Z as new parent of all nodes in S. If E is root node, Z need to broadcast its IP address to all other full-connection nodes also. As shown in figure 4, The job matching procedure acts as follows: (1) Based on the resources that the job needs, its Job ID, which noted as TID, is calculated. (2) If TID equals to current node’s NID, it means this job can be satisfied in the submitting tree, go to step 3. Else, go to step 5. (3) Checking the child list of current node to find a free node. If found, select it and go to step *. Else, select a child whose FC field greater than zero and forward this job request to it. This step is repeated on that node. If the children’s FC fields are all zero, go to step 4. (4) Forwarding this job request to parent node Q (P1 points). If Q is the root node, then go to step 7, else go back to step 3. (5) The job request is sent to the root node of the tree (RP points). (6) Looking up TID in R’s full-connection route table, if found, forward this job request to the found node Q. Else, go to step 0. (7) Checking the child list of current node to find a free node. If found, select it and go to step *, else select a child whose FC field greater than zero and forward this job request to it. This step is repeated on that node. If the children’s FC fields are all zero, go to step 0. (*) Setting free field of selected node to be false, traveling up step by step according to P1 until reach the root node. All the nodes on the way should decrease its corresponding FC field by 1. (X) Spare node A has been found, match success. (0)There is no suitable node for this task. As shown in figure 5, Overlay network is a logical topology constructed over the physical network. Adjacent nodes in the overlay network may be far away in the physical network. It means the high efficiency in the overlay network does not mean it’s really in physical network. A solution is adding geographic information into the Node ID’s representation. For ...