SQL Server clustering is designed to solve the problem of high availability, not the problem of load balancing.

You can install SQL Server on a multi-node cluster, but only one node of the SQL Server instance name can be active at one time. If you have a multi-node cluster this has the effect of increasing the number of locations where SQL Server can be started if a given server fails, but it does not allow you to run multiple active nodes at one time.

Gridscale adds a little bit extra. This gives you a single logical name your applications can use to connect to SQL Server, and routes the connection request to the appropriate SQL Server instance. Each SQL Server instance in Gridscale has exclusive use of the databases attached to it. This means that if you have a given database that is used very heavily it MUST be located on a server that has enough power to run all your queries. Gridscale does not give you a shared data cluster where multiple nodes can both update the same database.

There is a way to get a shared data cluster with SQL Server, where multiple nodes are able to update the same database, but I have no idea what performance this would have. If you have what Microsoft call a geographically dispersed cluster you use SAN replication to keep the various LUNs synchronised. SQL Server uses the VSS writer component to let all active nodes know what pages have been changed, so that the other nodes can refresh their copy of these pages from disk. It is marketed as a way to distribute a cluster across multiple data centres, but there is no reason why everything could not be located in a single SAN. My main reservation with this setup is lack of community knowledge on the performance of the VSS writer component, because if this cannot keep up with the rate of change everything would comer to a halt or get corrupted.