Tuesday, April 14, 2009

The migration from Rocks to xCAT

Thinking of using an alternative HPC solution to Rocks? Check out xCAT.

xCAT appears to be much more flexible, and less entangled with the underlying operating system (in Rocks case, either Red Hat EL5 or CentOS5). This is appealing in that you can apply core OS updates without the worry that you'll break compatibility with the cluster stack.

There's a long history of discussions on the Rocks mailing list about how to apply core OS updates, and which packages to avoid. Over the releases, Rocks has moved much of the functionality into its own space or commands (for example, old Rocks had a modified /usr/sbin/useradd). Some users now claim that they apply updates to the nodes on a weekly basis without any problems, while others say that it's still possible to break components by applying the updates.

xCAT lives in its own space, under $XCATROOT (I think I have that right). Since xCAT is perl based, your biggest exposure would be updating the core perl to a much newer release, but you'd have to do that outside the normal yum repos.

One of Rocks strengths is that a novice Linux user can install and manage a basic cluster fairly easy, and conversley xCAT appears to have a steep learning curve and certainly requires a good deal of familiarity with Linux in a CLI environment (sorry no GUI yet).

More to come as I get time to play with xCAT.

2 comments:

Vallard said...

how did this go? I find that xCAT has tons more flexibility and capabilities over ROCKS. On the other hand, its not as easy to configure for the novice. We're working on that...

Unknown said...

Sorry for the late reply, we never made the switch. I never found time to test it.

I'd really like to see Rocks begin supporting a repository like update method (yum for the Red Hat users). As it is now, upgrading requires a reinstall with an upgrade roll, which preserves some settings and accounts.