However, in this case, I just so happened to have built two Exchange 5.5 (and three Exchange 2000) clusters on this platform, and actually do know it fairly intimately. So, I thought I would at least share my experiences, even though, as I said, YMWV.
I don't know how many users you are planning on deploying on to the cluster, but regardless, you will want to make sure you have enough memory in each node. If you can, try to get as many external disks as possible. I would also configure the external storage as follows:
2 disks in RAID 1 - Quorum
2 disks in RAID 1 - Exchange Transaction Logs
X disks in RAID 5 - Exchange databases
In the above configuration, the number of disks needed for the databases is left at X. I don't know how much space you will need, so you'll have to calculate and plug in the appropriate number. You'll have 10 disks left after creating the RAID 1 arrays. If you got 18GB disks and you used all 10, you would end up with 162GB of space for your database.
Having said all of this, you'll want to first make sure that you are considering a clustering solution for the right reasons. Clusters give you some decent benefits, including easier system management (because multiple systems are managed as a single system), support for rolling upgrades (I can move Exchange 5.5 to one node while I install Service Pack 3 for Windows 2000 on the other-passive-node). But their real strength (and ultimately their primary benefit) is providing high-availability and automatic failover in case of hardware failure. Clustering won't help you with application problems, corrupt databases, buggy drivers, spam, etc. You should only cluster if the primary cause of downtime in your environment is hardware failure. If other things are causing downtime, then clustering won't help you. <self-promo> For more information on clustering, check out my Microsoft Cluster Server Center Web site. </self-promo>