Clustered systems are expensive. $30k does NOT sound like a lot. I would take a good look at the solution and make sure it's not too cheap. Also, 36GB seems awfully small.
The concept of a cluster is simple: 2 servers sharing a single, external RAID enclosure. They also have a dedicated link between the two servers so they can detect if their partner fails. In a Microsoft SQL Cluster, you generally split the RAID between the two servers. Lets say it a 200GB RAID. You create 2 logical drives: G: 100GB and H: 100GB. You assign G: to ServerA and H: to ServerB. Under normal conditions, ServerA will see only the G: drive and ServerB will see only the H: drive. You install 2 instances of SQL on EACH server and name them, for example SQLA and SQLB. SQLA expects to find its data on G: and SQLB expects to find its data on H:. On ServerA, the instance of SQLA will be running and the instance of SQLB will be stopped (these will appear as seperate services). On ServerB, the instance of SQLB will be running and the instance of SQLA will be stopped. Let's assume ServerB fails. ServerA notices immediately that ServerB is not responding. He sends a signal to the RAID enclosure and takes over the H: drive. Now, ServerA has both G: and H:. The cluster software will kick off a process (like a batch file) that will start the SQLB instance running on ServerA which finds its data on H:. The client application is using the SQL instance name to find the data so after a short time-out, the client will reconnect to SQLB not realizing that it is now running on a different server.
As for how reliable they are, that depends on the hardware (don't go cheap) and how well it's configured. Remember, the hardware of EACH server needsto be able to handle the combined load of BOTH servers. Otherwise the server will chock on the load when his partner fails. Under the right circumstances, the results are awesome.