Is it common to have several different servers for the same web application?

  

I will base my premise on the fact that there is no difference between the quality of service between the contracted accommodations. I mean the quality difference between hosting that exists.
  For this answer, I will idealize that they are all the same.

This case is not as different as you might think. It may be not visible, but it is common. Not between the three you cited, but usually between the database server and the application server.

Even if you hire a single host, you do not guarantee that everything you put in will be on a single server, and that's what usually happens.

When configuring the database, application and redis you will point the location, which a host gives you the access data, but not sure which will be on the same server. Different hosts are just different servers (this does not take into account the quality of each one).

There are some points in relation to separate services on different hosts, which are:

Safety

Your web server is available to anonymous users, taking into account that something is not as it should, you leave your database and other information unsafe for some security breach.

And we take into account that if any of the hosts are "accessed externally", you will have a time to prevent before reaching the rest.

Performance

If configured correctly, you will not lose performance, on the contrary. You are required to make the requests, regardless of whether you are on a host or not. Big companies like Google, Facebook and StackOverFlow use differentiated servers, due to performance issues, among others.

It is very common to see a large load-balancing host in large companies, which helps keep the service online (of course, this is usually implicit, but it happens).

Scalability

One of the biggest difficulties today is to scale the hardware needed for the system to work. By separating on hosts, you can better differentiate where the bottleneck is and whether or not you need to change the hardware settings.

UPTIME

As @CiganoMorrisonMendez said in your reply, you can keep your application working even if any of these hosts fall (except of the application logically). Today you have tools to cache your system and ensure almost independent functionality by using some features to save the data if the bank host stops working. Of course, you need to prepare your application for this, but it is possible.

Costs

Separating your system into different hosting places high costs on your services, which can cause problems for many.

Complexity

The difficulty of maintaining three lodgings is greater than one centralized. This will generate a greater complexity to keep the application running. Poor configuration of these features may lead to application malfunction and / or loss of performance, as many people say.

References:

• Why is it not advisable to have the database and web server on the same machine?
• Stackchange Performance
• How to host a single website on multiple servers
• Autoscale - Facebook
• Load Balancing

  

Is this a commonly used approach?

Common is not. It's a little bit extravagant, but it's not wrong.

  

Keeping every thing on a different server can bring me some kind of problem?

Problems are more related to the complexity of your contingency. The choice not to leave everything centralized may or may not be a performance bonus. There is also the question of the quality of each service, the complexity of managing them, and something involving costs. In short, division can be both an advantage and a disadvantage.

For example, if your Redis server crashes, your application will not necessarily stop working, especially if Redis is used as your application's second level cache. Now, if your SQL Server crashes, even with Redis running, you'll drop the application even with the other services running. Contingency is much easier to manage when centralized.

On the other hand, establishing this division creates an interesting form of parallelism. The workload is divided into three different places, which can be converted into performance gains.

I am answering based on what was asked. It's talking about having servers in different hosting. The other answers say things that make sense in a hosting with different servers. They are correct for the scenarios that resolved to respond, not to the scenario of the question.

For me the question makes it clear that the separation is only occurring because they did not find a place that would provide everything together.

Depends on what you consider normal. Most sites are very simple and need a very simple structure. For example, the site that actually needs Redis is rare.

It is very rare to find any hosting that offers SQL Server and not ASP.Net. Many offer both and Redis (which I doubt is necessary).

This structure even works, but will generate traffic between the hosting, generating costs, which is not ideal and will greatly increase the response latency of the site. The more access you have, the more you will have difficulty dealing with a totally decentralized structure.

There is no way to perform better by having services that are dependent on each other in different physical locations. This will only generate more latency, with no gain.

Undoubtedly having the distributed load can give better performance than having everything on one server. But only if the server is overloaded, otherwise it will only add latency with no gain. Just measuring to be sure when to separate servers.

If the option is to have separate servers on the same network, then the gain may be more interesting, but only in cases of high access volume. If the load is small, adding servers with dependent services to each other, even on the same network, will certainly add latency, but small and acceptable because the volume requires this.

There is still a possibility to use different datacenters to increase the availability time, after all a datacenter can leave the air. But if you do this, you should have full copy of all the components in the two datacenters . That is, you will have one or more servers in each of them containing the 3 services reported: SQL Server, Redis, ASP.Net (probably an IIS).

Even if you are thinking about load distribution, this has to be an engineering job, not a road accident.

Possible is, but I would not recommend doing this. It's more complex and more costly.

Look for a location that meets all your needs. Azure, for example, answers. Not that I'm recommending.

You can pick up an instance where you can put the 3 services together or you can hire the separate services (it usually gets a lot more expensive).

Does your need look like StackOverflow? If not, go for the simple. Go for what you're used to. Only create complexity in the system when the need arises.