| | | | | | Consistent, system-wide naming conventions can help the user to recognize how files will be accessed. For example, in Chapter 6, it was suggested that all user home directories be shared under the file system /home. If this convention is followed, then one can be certain that any files in user home directories will require network I/O to be accessed by the internal nodes of the Beowulf. Similarly, the system files, /, /usr and /tmp are always on local hard disks. Thus, the examples using povray would not incur network traffic to copy the executable itself (assuming it is installed in the standard place in /usr/bin), but would incur network traffic to copy the files located in ~/rendering. Unfortunately, NFS is a fundamentally sequential system. The NFS server on the worldly node will respond one-at-a-time to requests from internal nodes, even if those requests are all for the same file. It will not use any underlying broadcast mechanisms. On the other hand, NFS clients (i.e., internal nodes) can cache data that is unchanging, e.g., input data files and executables. Therefore, if there's enough swap space on the remote nodes, repeated requests for the same file objects, e.g., executables or common input files, from the same client will not cause significant network traffic. | | | | | | | | | In Chapter 6, we suggested devoting any extra disk space on internal nodes to a user-accessible file system called /scratch. If I/O performance over NFS is an issue, then output files can be written to /scratch, rather than back into the NFSmounted user's home directory. While this can be an order of magnitude faster, it may require some additional bookkeeping for the user to keep track of his files. | | | | | | | | | Process level parallelism is often the easiest and most cost-effective way to utilize a Beowulf system. When it is applicable, it almost eliminates the time to "program" a parallel application. Essentially, all that is required is a few shell scripts to launch multiple copies of the application with suitable arguments. Optimizations are often unnecessary, but usually involve use of local file systems to reduce NFS traffic and improve I/O performance. The script shown in in Programs 7.2 and 7.3 allows for automatic load-balancing of process level parallelism across a Beowulf system. In many cases it is all that is needed. Nevertheless, it could be improved in several ways. A more sophisticated version might dynamically adapt to system load and could also allow commands to be dynamically added and deleted from the run queue. Multiple users could be accommodated with variable priorities and accounting and scheduling policies. Graphical user interfaces could display the state of the system, tailored to the needs of administrators and/or users. These features are typically found in large and complicated batch scheduling systems, which should be available for Beowulf systems in the near future. | | | | |
