Table of Contents Table of Contents Team Members Project Charter Abstract Operating System Requirements...

Transcription

1 ITS 470 Phase 3.1 November 2,

2 2

3 3 Table of Contents Table of Contents... 3 Team Members... 6 Project Charter... 7 Abstract... 9 Operating System Requirements Hardware Requirements DrQueue Hardware Requirements Cluster Computers Software Requirements Software Specifics Installation Documents Knoppix Installation User Documentation Live Queue Section 1 Master Node Section Master Node Set Up Section 2 DrQueue and the Master Node Section 3 Slave Node Section Slave Node Set Up Section 4 DrQueue Manager and the Slave Node Test Plan Introduction Overview of System Objectives of System Test Test Deliverables... 33

4 4 Inclusions Exclusions Test Items Features to be tested Features not to be tested Approach Pass/Fail Criteria Remaining Test Tasks Remaining Test Tasks Schedule Issues, Risks, and Assumptions: Issues Risks Assumptions Glossary Scripts Script Script Appendix A Designs Figure 1 Cluster Layout Figure 2 Lab Cluster Layout Figure 3 DrQueue Appendix B - Questions and Answers Planning Performance... 46

5 5 Testing Security Hardware Software Issues and Problems Conclusion Bibliography... 56

6 6 Team Members Aaron Covarrubias Ryan Gumbiner Marcin Karbowniczek Aleksandar Lukic Anthony Marszalek Aron Okichich Nick Prendergast Michael Rakers Robert Ruth Robert Sheehan Edwin Trinidad Jeffrey Wozniak

7 7 Project Charter Project Title: Live Render Project Starting Date: September 12, 2008 Project Finish Date: December 2008 Budget Information: Since most of the software that is being used is open source and is being used for Linux, it is mostly free. Project Manager: Aron Okichich: (219) Project Objectives: Create software that renders faster than the current software in use for the CGT department at Purdue University Calumet. Approach: Determine what needs to be used for the project to be accomplished Begin with the chosen software to be implemented Start writing the script and keep its usability simple Roles and Responsibilities Staff Role Position Contact Information Prof. Samuel Liles Project Champion Leader of the project Aron Okichich Section Leader Project Manager Aaron Covarrubias Team Member Project Member Ryan Gumbiner Section Leader Documentation Marcin Karbowniczek Team Member Project Member Aleksandar Lukic Team Member Project Member Anthony Marszalek Team Member Project Member Nick Prendergast Section Leader Scripting

8 8 Michael Rakers Section Leader Software Robert Ruth Team Member Project Member Robert Sheehan Section Leader Graphics Design Edwin Trinidad Team Member Project Member Jeffrey Wozniak Team Member Project Member

9 9 Abstract A rendering farm allows video editing software to render video, CGI or computer-generatedimagery, in a more efficient manner. This is possible by creating a computer cluster that enables the user to see the cluster as one computer and work with the computing power of that entire cluster. This will ideally allow them to perform the rendering of large video files in a much more efficient manner. This is what the ITS470 Fall 2008 class intends to develop throughout the semester. The proposal will consist of the design, implementation, and testing of a heterogeneous rendering cluster. The cluster will be designed so the individual nodes in the cluster will be transparent to the client s rendering software. In addition, the proposal s benchmark is set at 80%. Not only will the proposal create a functional rendering cluster but also provide a reasonable amount of performance, greatly enhancing the number of projects that can be rendered in a given time frame. This proposal will be the documentation showing the plans on how the team plans on implementing such a cluster.

10 10 Operating System Requirements The requirements for the cluster s operating system will require a Linux operating system that can be booted into a live environment. A live environment is a Linux operating system that boots from a removable storage media that does not affect the operating system on the machine s internal hard disk or hard disks. The chosen distribution for this live environment is Debian Lenny. Debian is the preferred operating system for several reasons. Debian provides extensive access to many Linux binaries and libraries needed to operate a High Performance Cluster (HPC). This particular distribution also has many resources available to create highly customizable live environments. In addition to the rendering software being easily obtainable via Debain s apt repository system, other cluster management software and parallel computation software is available and has been successfully tested in this distribution. Debain Live is a project from the Debain team that allows for customizable Linux Live CD s to be created using several types of architectures. Debain Live even allows for booting into multiple architectures including i386, AMD64, SPARC and PowerPC, which provides options for extensive expandability for the architecture of the cluster. Debian is also a common choice for running LAMP (Linux, Apache, MySQL and PHP). This allows for software such as DrQueueOnRails (mentioned in further detail in the Software Requirements section) to have all of the required prerequisite software. Hardware Requirements Hardware Amount Information PC s Up to 84 HP Desktop Computers Storage 156GB on NAS The NAS Server that the cluster is going to connect to is an HP NetServe with 156GB spanned on a RAID 5. Switches 4 Gigabit Switches 10/100/1000 switches that are already in place in the labs will be used for network transmissions. Firewall Already provided by the University The cluster will not directly affect the firewall, nor will the firewall be configured specifically for this cluster.

11 11 The required hardware for the design of the rendering cluster will require a group of computers, initially 20 machines connected together within one room, and eventually 80 machines connected together between four rooms. The computers being used are those of the CIT labs, which have the necessary requirements to complete a project such as this. For operating systems use, the computers will contain Debian Linux. Debian itself needs very little when it comes to hardware requirements. Depending on which architecture you are using it may vary on what hardware it needs. The GUI it uses also makes a difference as well. Some desktop environments such as XFCE or Fluxbox use less resources compared to GNOME or KDE. We will be using XFCE. Generally for hardware it only needs the following: 64 MB of RAM (512 MB of RAM is recommended) 5 GB of disk space. 1 GHz Pentium 3 or Athlon XP CPU The hardware on the machines that we will be using are listed below in the Cluster Computers section. They will be able to provide more than enough resources to run Debian Linux. Each computer will contain a wired connection to one another through gigabit switches. The idea of the cluster is to use computers that contain hardware exactly the same as or to the upmost similarity as the other computers contained on that cluster. The hardware, when clustered, should be able to output at least 80% of its total combined computing power for use for rendering. DrQueue Hardware Requirements Drqueue is a small but powerful program. There isn't much out there on the Drqueue hardware requirements. Yet, the documentation shows that it should run fine on any up to date machines, and with any current Linux operating system. Cluster Computers For the computers being used to form the cluster, the group has chose to use the computers in the CIT labs/classrooms. The cluster has the potential of containing 84 machines if all 4 rooms are used for the final design. The HP computers are each equipped with the same basic hardware setup, including: Intel Core 2 Duo 2.13 GHz Processor with 4MB of L2 cache 2GB of RAM 160GB SATA Hard Disk Gigabit Ethernet Intel GMA x3100 Integrated Video with 384MB of shared memory

12 12 Software Requirements Michael Rakers, Aleksandar Lukic, Anthony Marszalek, Edwin Trinidad For the rendering portion of the design the team decided to choose a well renowned open source distribution render queue called DrQueue. DrQueue has been used by many institutions and productions including NASA, Martian Labs, Bren Entertainment, Indiana University, and University of Wisconsin Parkside. DrQueue works on virtually all 3D applications that the user may use including Maya and 3ds max. Software Specifics DrQueue became the obvious software solution not only because of its previous use but for its ability to be transparent. DrQueue provides a web interface called DrQueueOnRails. The user will be able to log into the web interface and upload their 3d scene to the web server. The interface then gives estimates for when the job will be completed then allows the user to retrieve their completed project back. The only requirements for this would be a Linux device with a MySQL database for the web site. Some of the basic requirements for DrQueue are to have fully established Network File System Server for all of the clients using Linux machines. Additionally SAMBA open source software could be used for windows clients. Some of the other requirements to run DrQueue are a 3d animation tool, BASH (bourne again shell), c shell as well as some type of rendering engine. The web server will act as the client as it sends a job to the master node. The master node then priorities the jobs in first come first server formation. The master node also contains the list of available slave devices that can be used to calculate the rendered image. When the file is ready to process the master node grabs the file from network storage and distributes the workload to the slave nodes. Each slave node within the system will have capability to decide if it s capable of rendering a specific process. In essence the slave node will communicate with the master node if rendering is available. Additionally the slave nodes will also report to master node if certain tasks need to be reassigned to another node, or if a specific node is no longer capable of handling a specific process. DrQueue also offers some additional GUI tools to check specific nodes and their rendering capabilities as well as to stop and change rendering frames. In addition while using DrQueue, one is capable of configuring the limitations of each node and therefore determine, if a node is capable of executing a particular rendering task. DrQueue also allows the users to monitor the logs in real time job as well as determine the minimum amount of memory one node would need to execute a specific job (refer to Figure 3 DrQueue).

13 13 Installation Documents Knoppix Installation To begin the installation, Knoppix is booted for CD/DVD to start the installation process with sudo knoppix-installer. Figure 1 shows the introductory screen to install. (Figure 1 Welcome Screen) In Figure 1, the OK button is clicked to begin the installation of Knoppix. After the introductory screen, Figure 2 shows two options to pick as shown below. (Figure 2 Choosing Installation) Since Knoppix is being installed, the Install Starts the Installer option is selected. After selecting this option, the OK button is clicked. Once this is selected, there is another screen that appears that has options to choose from as shown in Figure 3 below.

14 14 (Figure 3 Choosing an Action) In Figure 3, Configure Installation Create a new configuration is selected. Once this option is selected, the OK button is clicked. The step of the installation process is to choose the system type. This part is shown in Figure 4. (Figure 4 Choosing the system Type) The system type that is selected in Figure 4 is debian. The first radio button in Figure 4 is debian: Debain-like system (recommended). This is what default is and the Next button was then clicked to bring up Figure 5, Choose the partition to install Knoppix screen.

15 15 (Figure 5 Partition for Knoppix to be installed on) As shown in Figure 5, there is not much choice to pick from so the Next button is clicked. This brings up Figure 6, the Choose filesystem-type screen. (Figure 6 Filesystem-type) In Figure 6, default is ext3: Extended 2 filesystem with journal support. This is what is kept and the Next button is clicked. The next few screens have to do with User names and passwords for security reasons. The Next button is clicked. Figure 7 is for the Users full name. (Figure 7 Full name)

16 16 As shown in Figure 7, the User has opt to use Web User as their full user name. This is just an example of what an entire user name may look like. For example, John Smith may be used as a full user name. After entering a full user name, the Next button is the clicked. In Figure 8, the name of the user will be entered. (Figure 8 User Name) In Figure 7, web is an example of what a user is going to use for their user name. As mentioned earlier, John Smith may be used for a full user name. In this case for a user name, John might be used for just the user name. After entering a user name, the Next button is clicked. To show Figure 9, the password screen. (Figure 9 Password entry) In Figure 9, the user must enter a password. This password is for the user login. Note, in the lower left hand corner of Figure 9, there is a check box that allows the user to hide that

17 17 characters in the password that are being typed in the password box. This is a nice security feature provided by Knoppix. Once a password is entered, the Next button is then clicked. (Figure 10 Root Password) In Figure 10, there is a Root Password that is entered for administration rights. Once again there is a check box for whether or not the password characters should be shown or not. The Next button is then clicked after entering a Root Password. In Figure 11, there is a Host Name entered. (Figure 11 Host Name) In Figure 11, for example, LohgoAMD was entered for a host name. This is where any host name can be made up and entered in for security reasons. There is no reason that users have to use this same one. The Next button is then clicked to choose where the boot loader will go.

18 18 (Figure 12 Boot Loader Location) In Figure 12, the first radio button was selected for the Master Boot Record (mbr) and the Next button was clicked. Figure 13 shows what action to take next. (Figure 13 Choosing Next Action) The next action to take as shown in Figure 13 was to start the installation of Knoppix. The OK button was then clicked to start. A window that appears asking if the user wants to save the configurations. The OK button is then clicked. A screen as shown in Figure 14 appears giving the user a chance to review everything that has been done before starting the installation.

19 19 (Figure 14 Reviewing Information) After reviewing the information, the Next button is clicked to begin the full install. Figure 15 shows the install process.

20 20 (Figure 15 Install Process) After installation is complete, Knoppix is ready to go.

21 21 User Documentation Live Queue When setting up the master node, follow the Master Node Set Up located in Section 1.1 of this document. If you are setting up the slave node, skip to Section 3.1. Section 1 Master Node Section Master Node Set Up Note: Please have a USB storage device, such as an external hard drive with the file that needs to be rendered, attached to the machine before turning the machine on. This will also serve as the location of where the render files will be saved. Put the Linux Live CD into the CD-ROM drives of the computers that is going to be used as the master node. Only one machine will be used as the master node. The computer will then boot up to the Knoppix boot screen as shown in figure 1.1. Figure After inserting the Live CD into the CD-ROM drive, the user will be greeted with this screen.

22 22 On this welcome screen, the user can press enter to start the distribution or wait a few seconds and it will eventually load itself. Once the distribution has fully loaded, a screen similar to that in figure 1.2 will greet the user. Figure 1.2 This is the greeting screen for Live Queue, the user has the option to choose if the machine will be the master node or the slave node. Once this screen has appeared, the user will have a short period of time to choose whether or not this machine will be the master node. If the machine is going to be the master node, than press y, and then press enter. The user will then be supplied with the IP address of the machine. This IP address will need to be written down as it will be needed to tell the slave nodes where to find the master node. This is shown in figure 1.3 below. Note: Only one machine needs to serve as the master node. Please be aware that once the time allotted to choose whether the machine is the master node or a salve node has expired, it will automatically default to being a slave node.

23 23 Figure 1.3 Once pressing y, and then pressing enter, the IP address of the master node will be displayed. This number needs to be written down. In this example the IP address is Once the IP address has been written down, enter can be pressed to move onto the user interface of Dr. Queue. Section 2 DrQueue and the Master Node After the instance has been fully launched, the DrQueue manager should have launched as shown in figure 2.1.

24 24 Figure 2.1 Once the master node has fully loaded, the DrQueue Manager will open automatically, where the user can then start a job to render their file. Note: Before starting a render job, all of the slave nodes need to be ready. For this to happen the master node needs to be fully loaded and DrQueue Manager needs to be running before the slave nodes are started. Once DrQueue Manager has been loaded, the IP address of the master node can be entered into all of the slave nodes and the slaves can be started. To see the slave nodes in DrQueue Manager, click the Computers tab at the top of the screen. For more information on this please see section 3. To start a job, right-click within in the DrQueue Manager interface and select new job as shown in figure 2.2.

25 25 Figure 2.2 When the DrQueue Manager appears, right click within the dialog window and choose new job. After selecting new job from the menu, the New Job window will open. In the first section of the New Job window is the Kind of Job section. In this section the user will select Blender as the file type. This is shown in figure 2.3.

26 26 Figure 2.3 Within the New Job window, the user needs to select Blender as the kind of job that is going to be rendered. In the next section, Blender Job Information, the user needs to set the location of the file that is going to be rendered. This should be on the USB storage device that was attached prior to booting up the master node. Once the location has been entered, the user then clicks the Create Script button. This is shown in figure 2.4.

27 27 Figure 2.4 In the Blender Job Information section, the user needs to specify the location of the Scene File. In this example it is /mnt/drqueue/output/test.blend. Once this has been specified, the Create Script button needs to be pressed. Under the General Job Information section, the name of the render needs to be entered into the Name section. The Command section should have automatically been filled in when the Create Script button was entered earlier. The start frame and the end frame should then be entered into the corresponding sections. The default frame that DrQueue Manager starts at is 1 and finishes at frame 100, if there are more frames than this in the file that is going to be rendered, than make sure to specify the correct amount of frames that are going to be rendered. In the Operating Systems section, be sure that only Linux is selected and all the other options have no check in the box next to it. This is shown in figure 2.5.

28 28 Figure 2.5 In the General Job Information section make sure that the appropriate data has been entered. Make sure to specify a name and that the correct frames are set. Also be sure that only Linux is set as the operating system under the Operating Systems sections. Once this information has been entered, it is safe to click the Submit button on the bottom of the screen. This is shown in figure 2.6.

29 29 Figure 2.7 Once all the information has been entered, it is safe to click the Submit button. Once this has been completed a screen similar to figure 2.8 will appear. This screen shows that the job is waiting to be started.

30 30 Figure 2.8 Once the job has been submitted it will appear in under the Jobs tab of the DrQueue Manager. After a few moments, the status will change from waiting, to active, indicating that the file rendering process has started. Once the render has completed, it will state that it is finished. Note: If at any time the master node screen goes to a blank screen, simply move the mouse as the machine went into a screen saving mode. Section 3 Slave Node Section Slave Node Set Up Put the Linux Live CD into the CD-ROM drives of the computers that are going to be used for the slave nodes. This can be a multiple number of machines. The computers will then boot up to the Knoppix boot screen as shown in figure 3.1.

31 31 Figure After inserting the Live CD into the CD-ROM drive, the user will be greeted with this screen. On this welcome screen, the user can press enter to start the distribution or wait a few seconds and it will eventually load itself. Once the distribution has fully loaded, the user will be greeted by a screen similar to that in figure 3.2.

32 32 Figure 3.2 This is the greeting screen for Live Queue, the user has the option to choose if the machine will be the master node or the slave node. In this case the user would press n. The user is then prompted to enter the IP address of the master node. The IP address of the master node was given upon starting up the master node. The IP address should be entered, but before pressing enter to continue and start the slave node, DrQueue Manager needs to be fully running on the master node. Once it has been confirmed that the master node is ready, all of the slave can be started by entering the IP address and pressing enter. Section 4 DrQueue Manager and the Slave Node Regarding DrQueue and the slave node: this part of the process is fully automated from the master node, so no user interaction is required except that of what is listed in section 3.1. Note: A graphical user interface (GUI) will not be present on the slave nodes. Once the master node has booted fully, and the IP address has been entered into the slave node, the slave node will report that it is working silently. This is correct. Also, if the screen goes blank while the slave nodes are running do not panic, this means that the slave went into a screen saving mode and it is still working silently. If you wish to bring the machine out of sleep mode, press the shift key on the keyboard.

33 33 Test Plan Introduction Overview of System The aim of this phase of the project is to implement a cluster to enable: Faster rendering for CGI students Give the appearance that the user is using one workstation to aid in simplicity in regards to user/cluster interaction Render large video files in a much more efficient manner Enhance the number if projects that can be rendered at one time The utilization of this software will render larger video files in a shorter period of time, increase the number of projects that could be rendered at one time, and give the user the perception that he/she is using a familiar rendering software program. Objectives of System Test This system test intends to prove that: Test the systems performance in an realistic environment To ensure the documentation is user friendly To discover any unforeseen issues Test Deliverables Inclusions Project Deliverables Linux operating system that boots from a removable storage media Debian Lenny distribution to operate a High Performance Cluster Debain Live allows for customizable Linux Live CD s to be created DrQueue rendering software DrQueueOnRails web interface SAMBA open source software that could be used for windows clients Exclusions Specific Exclusions To be determined Test Items Features to be tested Performance testing Stability testing

34 34 User interface testing User documentation testing Features not to be tested To be determined Approach Calculate percentage increase on the 2GB machines Calculate percentage increase on the 1GB machines How many machines can be connected until optimal performance is reached Test 2GB machines with 1GB machines and calculate performance Test the system with a CGT student with only user documentation to determine user friendliness Run two rendering projects simultaneously and calculate performance Render a large file that to test stability Pass/Fail Criteria The Criteria that will determine if the software is considered a success or failure is a calculation that requires a 80% increase per machine added to the cluster Having a CGT student use the system efficiently and effective without the help of a ITS student Any major stability issues i.e. any node dropping out of the cluster Remaining Test Tasks Remaining Test Tasks Calculate percentage increase on the 2GB machines Calculate percentage increase on the 1GB machines How many machines can be connected until optimal performance is reached Test 2GB machines with 1GB machines and calculate performance Test the system with a CGT student with only user documentation to determine user friendliness Run two rendering projects simultaneously and calculate performance Ensure ISO burns to a disc and boots properly when inserted into node Schedule Issues, Risks, and Assumptions: Issues Risks Assumptions It will be on a secure network

35 35 The project will run on a live CD that will not hurt the current computers or network The master node will have a monitor Will run on hardware supported by live knoppix Glossary Dr. Queue- Maya- Blender- Rendering Farm- Frames-

36 36 Scripts Script 1 # /etc/inittab: init(8) configuration. # $Id: inittab,v /01/25 13:35:21 miquels Exp $ # The default runlevel. id:3:initdefault: # Boot-time system configuration/initialization script. # This is run first except when booting in emergency (-b) mode. si::sysinit:/etc/init.d/rcs # What to do in single-user mode. ~~:S:wait:/sbin/sulogin # /etc/init.d executes the S and K scripts upon change # of runlevel. # # Runlevel 0 is halt. # Runlevel 1 is single-user. # Runlevels 2-5 are multi-user. # Runlevel 6 is reboot. l0:0:wait:/etc/init.d/rc 0 l1:1:wait:/etc/init.d/rc 1 l2:2:wait:/etc/init.d/rc 2 l3:3:wait:/etc/init.d/rc 3 l4:4:wait:/etc/init.d/rc 4 l5:5:wait:/etc/init.d/rc 5 l6:6:wait:/etc/init.d/rc 6 # Normally not reached, but fallthrough in case of emergency. z6:6:respawn:/sbin/sulogin # What to do when CTRL-ALT-DEL is pressed. ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now # Action on special keypress (ALT-UpArrow). #kb::kbrequest:/bin/echo "Keyboard Request--edit /etc/inittab to let this work." # What to do when the power fails/returns. pf::powerwait:/etc/init.d/powerfail start pn::powerfailnow:/etc/init.d/powerfail now po::powerokwait:/etc/init.d/powerfail stop # /sbin/getty invocations for the runlevels. # # The "id" field MUST be the same as the last # characters of the device (after "tty"). # # Format:

37 37 # <id>:<runlevels>:<action>:<process> # # Note that on most Debian systems tty7 is used by the X Window System, # so if you want to add more getty's go ahead but skip tty7 if you run X. # 1:2345:respawn:/sbin/mingetty --autologin root tty1 2:23:respawn:/sbin/getty tty2 3:23:respawn:/sbin/getty tty3 4:23:respawn:/sbin/getty tty4 5:23:respawn:/sbin/getty tty5 6:23:respawn:/sbin/getty tty6 # Example how to put a getty on a serial line (for a terminal) # #T0:23:respawn:/sbin/getty -L ttys vt100 #T1:23:respawn:/sbin/getty -L ttys vt100 # Example how to put a getty on a modem line. # #T3:23:respawn:/sbin/mgetty -x0 -s ttys3

38 38 Script 2 # /etc/profile: system-wide.profile file for the Bourne shell (sh(1)) # and Bourne compatible shells (bash(1), ksh(1), ash(1),...). if [ "`id -u`" -eq 0 ]; then PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" else PATH="/usr/local/bin:/usr/bin:/bin:/usr/games" fi if [ "$PS1" ]; then if [ "$BASH" ]; then PS1='\u@\h:\w\$ ' else if [ "`id -u`" -eq 0 ]; then PS1='# ' else PS1='$ ' fi fi fi sleep 10 while [ "$CONTINUE"!= y ] do echo "Do you wish this to be the master node? (y/n)" read -t 5 RESPONSE case $RESPONSE in 'y') echo "This is the master node's IP address. Write it down. You will need to enter it at each slave node." DRQUEUE_MASTER=`ifconfig eth0 grep "inet addr" awk {'print $2'} sed s/addr://` echo "This is the master node's IP address:" $DRQUEUE_MASTER echo "Press enter to continue..." read export DRQUEUE_ROOT=/mnt/drqueue export DRQUEUE_MASTER=localhost export DISPLAY=:0 export PATH=$PATH:/mnt/drqueue/bin umount /dev/sda1 mount -t vfat /dev/sda1 /mnt/drqueue/output X :0 & DISPLAY=:0 drqman & CONTINUE="y" ;; 'n')

39 39 echo "Please enter the IP address of the master node: " read DRQUEUE_MASTER export DRQUEUE_ROOT=/mnt/drqueue export DRQUEUE_MASTER export PATH=$PATH:/mnt/drqueue/bin while [ 1 ] do check=$(fping $DRQUEUE_MASTER awk {'print $3'})] if [ "check" = "alive" ] then MOUNTCHK=$( mount grep drqueue) if [ "$MOUNTCHK" ] then echo "Mounted." else mount -t smbfs -o username=root,password=test //$DRQUEUE_MASTER/drqueue /mnt/drqueue fi fi sleep 300 done CONTINUE="y" ;; '') echo "Please enter the IP address of the master node: " read DRQUEUE_MASTER export DRQUEUE_ROOT=/mnt/drqueue export DRQUEUE_MASTER export PATH=$PATH:/mnt/drqueue/bin while [ 1 ] do check=$(fping $DRQUEUE_MASTER awk {'print $3'})] if [ "check" = "alive" ] then MOUNTCHK=$( mount grep drqueue) if [ "$MOUNTCHK" ] then echo "Mounted." else mount -t smbfs -o username=root,password=test //$DRQUEUE_MASTER/drqueue /mnt/drqueue fi fi sleep 300 done /mnt/drqueue/bin/./slave CONTINUE="y" ;; *)

40 40 echo "Please enter Y or N" ;; esac done umask 022

41 41 Appendix A Designs Figure 1 Cluster Layout (Rob Sheehan)

42 42 Figure 2 Lab Cluster Layout (Rob Sheehan)

43 Figure 3 DrQueue 43

44 44 Appendix B - Questions and Answers Planning 1. Are we going to have a good network documentation that could help reduce troubleshooting time? a) Yes, the network documentation will be written well enough to allow for easy understanding and troubleshooting. 2. For our detailed network map, are we going to show items included in the campus network, such as buildings and floors, location of major services, location of routers and switches, location of mainframes, location of major network management stations and the location of virtual LAN s as well as indication where workstations reside? a) Only the necessary locations will be shown such as the CIT labs and possibly where the main servers reside. 3. Is the network map going to include names of routers, network segments and servers? a) Yes, as this would be beneficiary when trying to troubleshoot problems as well as being part 4. What is the cable distance between each node within the cluster? a) The cable distance is the appropriate length that is required by cabling standards. 5. What is the cable distance between the nodes and the NAS? a) The cable distance is the appropriate length that is required by cabling standards. 6. What type of access should be given to the different users? a) The access will be dictated by the NT login through the Web interface. 7. When we hand the system over to the customer are we going to need to train the customer on how to use and manage the system as well as train the users? a) Documentation will be required for the students. Some training in the system should also be completed by facility because they should be with the organization longer than most of the build/install team. 8. What is the scalability of the project after it is completed? a) Once functional, the only reasonable limitation on the total number of nodes in the cluster is network capacity, i.e. available bandwidth and physical ports. As long as the underlying communication infrastructure is capable of supporting the number of nodes, there is no limit to the number of nodes that the clustering software can support. Beyond network limitations, the only other limiting factor may be the number of nodes that can be effectively managed and operated by the group. 9. What is the main goal of the customer?

45 45 a) The customer wishes to be able to utilize the rendering cluster to improve the current speed at which video projects can be rendered. The group intends to help the customer meet this goal by offering the ability to increase the rendering cluster's total processing capability by an amount equal to 80% of each additional node's maximum processing power. 10. How many switch ports will be required to interconnect all nodes? a) At least 86 ports must be included to connect all nodes. 84 ports are required for all of the nodes, 1 for an uplink to an outside gateway, and one for a NAS box allowing for shared data between all nodes. 11. How many are available? a) The rooms use several gigabit switches. There are approximately twice as many total ports as there are lab computers. This makes the theoretical total of available ports approximately If more are required, where will they come from? a) For every computer, another network interface exists next to that port, so an additional 84 ports are available. If the1 165 ports are exceeded, additional network equipment exists in the networking closet along with some additional space for those nodes. 13. Where will they be introduced in the network? a) The location of the nodes will not change. All of the nodes are already in production as lab computers. They will be booted into the cluster at predetermined times and are not a static addition to the existing network. The NAS server will be located in the CIT server room. If the Omnitechs are utilized in this project, sufficient power and network resources are located in the labs that they can be easily added alongside the current lab computers. 14. How much bandwidth will communication between the cluster require? a) Given all of the machines support high-performance processors, a high-performance network is required. For the specific hardware, at least a 100Mb/s connection is required for all of the machines to communicate effectively. 15. How much is available? a) All of the machineâ s NICâ s support Gigabit transmissions. All of the cable used is Cat5e and is connected to a Gigabit switch, allowing for Gigabit transmissions of up to 1000Mb/s between all nodes. 16. What are some of the rules and guidelines one should follow before removing a specific node from the cluster? a) Removing a node from a cluster can only be done if the node is not running any jobs. 17. What are some of the rules and guidelines one should follow before shutting the cluster down? a) Announce downtime, set down time, and then disable queues.

46 What are the guidelines when updating or revising the cluster? a) There is no need to revise the system unless rendering systems have changed. Performance 1. How long will it take the cluster to render a single image? a) It should take as long as 80% of the processing allows. 2. How long will it take the single node within the cluster to deliver the instruction to its destination? a) It should only take it milliseconds, which depends on how fast 80% of the cluster capacity is capable of delivering. 3. How long will it take to add an additional node to the cluster? a) It should be a relatively short time. It depends on how fast the node boots from the boot disk. 4. What are some of the consequences of adding a node to the cluster if the node is not configured properly? a) The consequence is that the node will not work with the rest of the cluster. 5. What are some of the rules and guidelines for adding a new node to the cluster? a) The node should aid in helping the cluster run at 80% capacity or better. If it doesn't then we either fix it or don't put it on at all. 6. How hot will the nodes within the cluster get? a) The node will be running within its own capacity and limits. If it starts going beyond its limits it will be shutdown. 7. How long can the cluster stay online? a) As long as nothing breaks or no one shuts it off it can stay on for long periods of time. 8. Are any extra standby nodes going to be implemented within the cluster? a) The node is going to have a certain amount of nodes it will be allowed. 9. How are we going to deal with resource contention? a) The idea of using resource contention should not be a problem. The cluster farm is going to be used specifically for rendering, giving usability to one user at a time. 10. Are we going to verify the quality of network services? a) No, other than basic connectivity test between nodes there is no need to check quality of network services. 11. What is the length of an average application session?

47 47 a) Length of session is dependent on average size of render images on all machines on the network at 80% capacity. 12. Will a guaranteed service be used? a) No, changing the quality of service of the transferred data is a violation of the network it is located. There is no other need for guaranteed services that isn t already set for the protocols to send files back and forth between machines. 13. What is the required uptime of the cluster? a) The required uptime of the cluster will be dependent on the length of the file being rendered and the amount of allowable time the lab has for use. 14. What kind of ventilation do the rooms have, will the cluster overheat? a) The machines being used in the cluster are arranged in such a way where overheating should not become an issue. 15. Will the cluster be connected wired, wireless, or mixed? a) The cluster will utilize the existing 10/100/1000 Ethernet network provided in the labs, so therefore, wired. 16. Will the labs be able to handle the power requirements of the clustered computers? a) The current lab environment provides sufficient power for all lab computers. 17. Will the cluster have a single point of failure? a) A variety of single points of failure are possible. Citrix as the entry point into the cluster can be a single point of failure. Power failure in the labs is another possible point of failure. Finally, unless additional hardware is utilized, network connections to the master node and NAS server may also provide single points of failure. 18. How will programs be used on the cluster? a) The cluster will utilize Live CDs and also have a web browser based interface to employ the applications available on the cluster. 19. What is the ideal time to render 1 hour of video? 2 hours? a) The ideal time to render files will be what the current power output from one computer time is to render files times eighty. 20. Will the available materials allow for homogeneous setup? a) The hardware available varies slightly, preventing a homogeneous setup. However, this cluster will be able to support a wide variety of hardware, eliminating the need to rely on homogeneity. 21. What is the speed going to the Network area storage going to be? a) The speed should be 100MB/s. 22. What is the speed coming from Network area storage going to be?

48 48 a) The speed should be one Gigabyte. 23. How much computing power is 80% of the available computer power? a) Around 16 machines working at full capacity for one room, given we use 20 computers and not the additional console computer. This is equivalent to GHz of processing power. If more than one lab is being used, up to a total of 84 machines could be used. This leaves about 67 computers running at full capacity as 80% of the available computing power. This is equivalent to GHz of processing power. 24. Once the data has been rendered, approximately how long would it take to deliver the rendered image? a) This is dependent on file size through a gigabit connection, and network traffic. 25. How long will it take the cluster to render a single image? a) It will take 80% of the processing speed for the image to be rendered. 26. How does the rendered image delivery affect each node within the cluster? a) It should not affect the nodes in the cluster. Their primary focus should be to render the image. 27. How does the amount of memory affect the rendered image? a) As long as there is enough RAM in the cluster to hold the image that is being created, the final product will not be affected. 28. What are some of the rules and guidelines one should follow before diagnosing a specific node within the cluster? a) The processing power, memory, and disk space of each node as well as the communication bandwidth between the nodes are all factors that should be considered. 29. What types of tools will be used to monitor the performance of the system as a whole, if any? a) We will calculate the acceptable performance by having the total amount of flops being 100% and only allowing 80% or more of those to occur while rendering. 30. In case network failure occurs how long would it take to fix it? a) Depending on the circumstance, if the portion of the network fails the clustering system should still be able to operate efficiently without any problems. Also considering that the cluster will not run 24/7 the chances of the cluster being affected by a network outage are minimal. However in case the entire network fails the mean time to repair the network would be one hour, in order to achieve high availability. 31. What is the maximum throughput the network will transfer? a) In order to measure maximum throughput the network will transfer, we will apply the following formula to help us calculate the max throughput. Max. Throughput = TCP Window Size / Round-trip time. 32. How can throughput be increased without adding extra overhead or retransmission?

49 49 a) By testing the devises we will be able to acquire enough information which will help us determine the number of packets per second a device must process. One of the alternatives would be to send bigger frames, since bigger are more efficient and carry less overhead. However bigger frames are more likely to be hit by an error, if there were no errors big frame would be the most efficient. 33. What are some of the solutions to prevent large portions of delay? a) Considering that delay is relevant for all data transmission technologies, one of the ways we are planning to measure delay is by measuring the round trip delay over the network, and by measuring the speed and load of the network as well as the cluster nodes. One of the ways we are planning to reduce the delay is by reducing the buffer size. 34. What is the average queue depth if utilization is at 80%? a) The average queue depth is: Queue Depth = Utilization / (1- Utilization). Moreover, in our case, using the utilization of 80%, Queue Depth would look something like this: (.80)/ (1-.80) = 4 packets. Testing 1. Are we going to create a smaller prototype of the clustering system? a) Yes, we will be using a few machines and run the cluster on a VM. 2. Are we going to document traffic flow for new and existing network applications? a) No, other than verifying that all nodes connect together, there is no need to document traffic flow. 3. Are we going to measure response times between significant network devices before and after we design the cluster? a) Yes, a simple ping test can prove that devices outside of the cluster can work effectively before, during, or after any cluster design to determine if there is a change of response times. 4. What is the average time that a station is idle between sending frames? a) Average time of the idle period between frames should be correspondent to the average latency of a network, which is ms. 5. Are we going to character the traffic flow as well as direction and symmetry of data traveling between sources and destinations? a) No, characterization of the flow is already outlined in the software design. 6. Where is the location of the cluster? a) The cluster will consist of the existing CIT lab machines. They are located in the Powers building CIT classrooms. 7. What type of usability is needed?

50 50 a) Users must be able to render files using the created cluster. The cluster should produce at least eighty percent of its total combined computing power for rendering files. 8. What type of manageability is needed? a) Users will have access to the applications needed to render files. They will be given the lowest level of usage rights. The cluster designers and professors will troubleshoot the cluster during its creation. 9. How many users will typically be on the network at one time? a) The cluster will be created with transparency in mind, so there should be only one user using the network at a time. 10. Are we going to analyze traffic and application behavior to optimize the network? a) Yes, as this would help in the goal of achieving an 80% success rate for the cluster. 11. What is our plan for detecting, isolation and correcting problems, occurring within our cluster or on the network? a) The plan for detecting and isolating problems will be testing the cluster and looking for problems to arise, and then isolating the problem, and then troubleshooting and correcting the problem. 12. How do we control, operate, identify, and collect data from managed devices? a) Data will be collected by monitoring the cluster; problems that are recorded will be troubleshot and corrected accordingly. 13. Should the network traffic from this lab be monitored like traffic on other parts of the network? a) Traffic should be monitored by the group to identify possible bottlenecks or other performance issues that may decrease efficiency. 14. How are we going to solve the problem with poor response times? a) We can accomplish this by simply resetting the node. Security 1. Which nodes will they be monitoring? a) All nodes will be monitored. 2. Are there any security risks? a) Security is limited by the physical environment of the labs. Since the cluster is being run from Live CDs, network security will be based on the type of usability allowed from those CDs. Physical security will be provided from the university. 3. What are some of the usability issues our network may encounter (strict security policies)? a) The only policies that would be in effect are those set forth by the University and the CIT department.

51 51 4. Will there be a need to write up a security document detailing what measures should be taken to secure the system? a) Documentation will be required for how to use the system; however, as far as security, the system will use the student login account for access. 5. What security measures are going to be taken to protect the clusters from viruses, worms, Trojan horses, etc? a) The selected OS is Linux, and because of this has inherent security against these attacks. 6. Are we going to implement any type of security policy for the cluster? b) The security of the cluster is within the security parameters of the overall network and should be physically protected. Hardware 1. Are all stations assumed to have similar load generating capabilities? a) No, stations may vary load if resources of the stations are different. If one machine has more RAM then another it is assumed that the station will have a heavier load of code to render than the smaller. 2. When identifying traffic flow, which of the five will be used: terminal/host, client server, p2p, server/server, distributed computing? a) The critical traffic to identify is between master and slave nodes, therefore a distributed form should be used as all others will not show true traffic as the device is transparent to other points. There is no main reason however to document the traffic flow between devices as the master node may be selective in the traffic. 3. What hardware is required by the OS(s)? a) Bare hardware requirements are: a computer with an AMD/Intel/PowerPC processor, at least 128MB or RAM, and an Ethernet network connection. A hard disk is not necessary, but for input/output files some storage is necessary. Network Attached Storage is the most common use of storage for sharing amongst several clustered computers. 4. Because there is video that may have sound involved, should there be better audio cards installed into the computers? a) Sound cards play no role in audio processing in the video creation process. 5. Will the available materials allow for homogeneous setup? a) The hardware available varies slightly, preventing a homogeneous setup. However, this cluster will be able to support a wide variety of hardware, eliminating the need to rely on homogeneity. 6. Will the users be able to save anything to their H drives from the system? If so, will the H drive need to be bigger for the video files?