There isn't enough information here to answer your question in a specific way, so I'll give you some generalities that may help:
For database servers you want a big- (and fast-)disked, ram-heavy multi-core/multi-CPU monster -- the assumption being there will be a lot of disk activity, you'll want to be able to suck large portions of your database into RAM for fast queries, and you'll have a lot of parallel queries happening at once.
How you size this out depends on a lot of factors (data set size, number of simultaneous connections, how abusive the queries are going to be). Typical disk configurations include very fast SAS or SATA drives in RAID-1 configurations (possibly multiple spindles to separate out your disk load).
Exception: If your DB will be lightly loaded (now and in the foreseeable future) you can skimp and get a dinky database server. Beware of false economy though: Under-specing your DB server may require an extended outage in the future to migrate to better hardware, so it's almost always better to over-build a bit.
For web servers you want to size them proportionally to workload. Serving a bunch of static pages doesn't take much CPU power or RAM. Doing a lot of fancy Ruby work (data-set manipulation on the web server) could require substantially more resources. Reality is probably somewhere in between.
The only real constant for web servers is you need "enough disk to hold your static content and any temporary/cached content" and with today's huge disks that's usually easy to get.
My web servers use OS-level software RAID on relatively tiny / slow SATA drives, usually with 2-4 Gigs of RAM & a single dual- or quad-core CPU (whatever our vendor has on sale at the moment), but our web application is lightweight and doesn't run the risk of overburdening that kind of configuration.