> 2. each node needs 500GB local disk space, 4 cores, 2.5GHz or better, > 8GB ram.
You could of course, just use 500G mirrored disks. But if you have the option of 250G mirrored, and make two mirrors and stripe them together, you will get significantly improved performance. > 3. need to have cluster be dual boot between windows HPC and linux > RHEL5. > > 4. a controlling node that can be switched between linux and windows to > control the cluster. Perhaps run a hypervisor on this and have both > controllers running at the same time? I can understand the compute nodes being dual boot, if you've got some apps that run under linux, and others that run under windows ... But I don't know why you would want the master node to be dual boot. Are you planning to run a queueing system that can only talk with others of its own kind? I know with SGE and LSF at least, the master can run on whatever (I prefer linux) and the compute nodes can run anything else. The master is perfectly happy to manage a mixed bunch of linux & windows & other nodes. > 5. Possibly some shared space. They do not know yet if shared space is > useful for a compute cluster. I always find the shared space to be instrumental. It may depend on your types of jobs, but people like to run things ... without knowing where it runs ... and certain source files etc always reside in a known path. For example, I normally create a linux cluster with /mycompany/ being shared space, and /mycompany/home/username is your home directory. So you get the same environment whichever machine you're on. And then there's a /scratch/username directory, which is always guaranteed to be on local disk, separate for each machine. So each machine can do its heavy IO and calculations under /scratch. No clogging the network or overloading the fileserver. One important side effect: Users are informed to do all heavy work under /scratch, but they're informed to only create re-creatable data under /scratch. Because only /mycompany is backed up. Scratch is not backed up. This is a necessity, by design, if you're creating large stuff there and need to avoid clogging the network or overloading the fileserver (or backup server). _______________________________________________ Tech mailing list [email protected] http://lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
