Oui le type de calcul va vraiment jouer sur le cluster a monter.
Le plus important c'est que les machines du cluster soit identique ( ou presque, le plus important est en fait leur capaciter a booter via LAN)
Il faut pas hesiter a rentre le serveur principal plus puissant que les noeud de calculs, c'est lui qui va les servir, donc autant eviter qu'il s'ecroule en calculant ou il doit envoyer les donnes. Il est mieux aussi que la grappe de machine soit sur un reseau disctinct.
La base du truc c'est dans cet ordre :
1 - installer le serveur principal avec les outils de serveur
2 - a partir d'un pc de calcul, installer un system de base avec les outils qui vont bien, en faire une image et la stocker sur le serveur principal
3 - Preparer le serveur central pour servir des images de boot avec les outils
4 - Brancher les PC de la grappes un a un, et vierge tant qu'a faire, si les choses sont bien faite, ils devraient booter depuis le reseau et installer ce qu'il faut au besoin
4 - Profit

Sur le stoquage deux ecoles existent, du NFS ou equivalent pour le "disque" system, ou utiliser le disque local. Un solution "hybride" peux etre faite avec un systeme minimal en local, et les apps de calculs monte en NFS, toujours booter le kernel depuis le reseau est une approche dans la majorite des cas (ca permet facilement de mettre a jour les machines de la grappe)
Apres si c'est par exemple de la compilation distribue, il y a des outils "decentralise" comme distcc par exemple qui permettent ca qui ne necessitent pas de faire une grappe classique. Idem pour du calcul distribue de rendu 3D, il y avais des plugin pour blender pour faire du rendu sur les PC de tout le monde dans un bureau (il y a meme un projet BOINC la dessus)
./3127: BOINC c'est bien, mais que pour les projets publique, et la capacite de calcul depends fortement du nombre de volontaires..