Two or more instances of SQL server can not share the same MDF/LDF files. Each SQL server needs exclusive access to it's own database files. So you can not load balance SQL server in this way.
There are basically three options to handle this. Possibly there are even more, but these are the three most commonly used.
Option 1: Master-Slave
One option is to set up multiple SQL server instances in a master slave scenario. One database server is the master and that is the database to which you write all data and changes. The slaves sync with the master and you let the web servers use the slaves for read operations. As most websites usually read more data than they write this helps to increase your database throughput. You will have to change the code of your websites to make it work with separate databases for read and write operations. The slaves can be behind a load balancer so your code would only need to support one write database server and one read database server. When reading, the load balancer will distribute the load evenly across all slaves.
Option 2: Sharding
In this scenario you distribute the data across multiple database servers. A simple example is a user database distributed across two database servers. All users with a odd UserID (e.g. 1, 3, 5, etc.) are stored on database server 1 and all users with an even UserID (e.g. 2, 4, 6, etc.) are stored on database server 2. This has the advantages that on average, each database server takes approximately half the load. This also scales very well as you can add more and more database servers and distribute the data more and more with your own custom schema. Your code will have to be changed to support multiple database servers but if you have a good multi-tier design you will have to change one tier to support this model.
Option 3: Don't use a SQL database
Use a non-SQL database solution. These are becoming more and more popular under the commong name: NoSQL. This means 'Not Only SQL'. It doesn't mean you shouldn't use SQL at all, but it means: don't use it for everything. There are a lot of other database systems which have advantages (and disadvantages) over SQL which might be a solution for your problem. A good read is the blog post: 35+ Use Cases for Choosing Your Next NoSQL Database.
Which option you choose depends on your application and database model. You could use both scenario's at the same time as well. E.g. sharding for the user database and master-slave for the orders table (in a web shop). If you require transaction support or have a lot of join operations, you will have to take this into consideration when deciding on which scenario to take. Scaling databases is a pretty complex topic and there isn't one solution for all problems.