Changes between Version 3 and Version 4 of Internal/VirtualPL/ParallelImaging

Timestamp:

Sep 18, 2006, 10:31:39 PM (18 years ago)

Author:

Surya Satyavolu

Comment:

—

Internal/VirtualPL/ParallelImaging

@@ -1 +1 @@
 The task of parallelization of imaging basically involves running multiple instances of nodeHandler which would launch different images on different nodes. The basic sequence of imaging of nodes as of now is as follows:
 
-1. The user runs the script imageNodes with the nodes and the image to be loaded as inputs.
+ 1. The user runs the script imageNodes with the nodes and the image to be loaded as inputs.
 
-2. The parameters are passed on to the nodeHandler which then resets the specific nodes using cmc.
+ 2. The parameters are passed on to the nodeHandler which then resets the specific nodes using cmc.
 
-3. It also launches the frisbee server from the tftpboot which sends out the particular image on a multicast address and creates tftp links to the node to provide nodes with the memory based image.
+ 3. It also launches the frisbee server from the tftpboot which sends out the particular image on a multicast address and creates tftp links to the node to provide nodes with the memory based image.
 
-4. On the node side, the nodes when started boot into the memory image and then launch the frisbee client.
+ 4. On the node side, the nodes when started boot into the memory image and then launch the frisbee client.
 
-5. The frisbee client fetches disk chunks from the frisbee client and writes it to the hard disk.
+ 5. The frisbee client fetches disk chunks from the frisbee client and writes it to the hard disk.
 
-6. The tftp links for the nodes are then removed.
+ 6. The tftp links for the nodes are then removed. 
 
-7. From now on the nodes boot up from the image stored in the hard disk.
+ 7. From now on the nodes boot up from the image stored in the hard disk.
 
 The imaging of nodes in parallel involves launching multiple instances of nodehandler which in turn implies launching more than one frisbee servers with different multicast addresses throwing away different images. At present the frisbee server settings are such that one multicast address per domain is allowed. For e.g. if a user is using a sb only one multicast address for a particular sb is allowed. So in case a user runs a second imageNodes in parallel, the frisbee server fetches the same nulticast address that results in an error. Thus the basic steps involved in parallelization would be :
 
-1. Tweaking the way frisbee server is launched, so that even if two frisbee servers are launched in the same domain, they throw images on different multicast addresses.
-2. Making appropriate changes in nodeHandler.rb since right now the script only allows one instance of nodeHandler to run at a time. 
+ 1. Tweaking the way frisbee server is launched, so that even if two frisbee servers are launched in the same domain, they throw images on different multicast addresses.
+ 2. Making appropriate changes in nodeHandler.rb since right now the script only allows one instance of nodeHandler to run at a time. 
 
 An alternative approach could be launching the frisbee server and client manually for different images. On a high level the basic steps involved would be:
 
-1. Create the tftp links to the nodes manually so that the nodes can boot into the memory based images.
-2. Launch the frisbee servers from tftpboot in reposotory2 using different multicast addresses.
-3. Launch the frisbee client on the nodes manually, with multicast addresses corresponding to the images to be loaded. 
+ 1. Create the tftp links to the nodes manually so that the nodes can boot into the memory based images.
+ 2. Launch the frisbee servers from tftpboot in reposotory2 using different multicast addresses.
+ 3. Launch the frisbee client on the nodes manually, with multicast addresses corresponding to the images to be loaded. 
 
 As a first step, some changes have been made to the imageNodes shell script which result in the identification of any concurrent running instance of nodeHandler. If the nodeHandler is already being run, it gives out a warning message to the user and exits. The nodeHandler in the meanwhile continues the imaging of the nodes. In case nodeHandler is not running, it will go ahead and image the nodes as specified. The modified imageNodes (imageNodes_new) is attached at the end of the page.