Advantages of dedicated servers over cloud solutions on the example of Tuffle.com server architecture
We launched the first version of Tuffle on a cloud server from Selectel and for some time we hosted there. It seemed to us that the "cloud server" stands for "pay the actual consumption of resources and forget about the problems of scaling and lack of performance." But the problems and made themselves felt ... Since the article is not about Selectel, we will simply list the reasons for which we had to find a different solution.
1. Often, with high attendance, the server just turned off. We had to constantly check the status of the site to be able to quickly respond to problems.
2. Management restrictions. Our dedicated server at the same time was a virtual server. As a result, all non-standard operations were performed using the ticket system, and this is terribly inconvenient.
')
3. With an increase in attendance in proportion to the growth and the price tag on the server. What seemed to be quite obvious, only the cost at a certain point became completely undemocratic and called into question the economics of cloud solutions.
And once they wrote to us that a DDoS attack was coming from our servers. We all rechecked, the alarm was false, but the unpleasant aftertaste remained.
By virtue of all of the above, we decided to organize our own server storage. This is where the fun begins.
And the decision was:
1. Adopt a pair of “clean” individual servers
2. Develop a horizontal scaling system
3. Distribute personal tasks between servers. Sometimes a few tasks.
First of all, we rushed to look for where to get such servers so that the channel was good and the price did not bite. As a result, we stopped at Hetzner and immediately bought 8 servers. And you know, it came out cheaper than the one at Selectel.
To begin with, we drew a table in which we painted, for which we need servers, what characteristics they should have, etc.
Vertical arrows, we denoted those characteristics that were most important for a particular server.
But it turned out that with Hetzner you cannot configure the iron filling yourself. Therefore, all of our 8 servers were exactly the same, namely EX40 . By the way, it is worth noting that for non-European countries, you can safely subtract 19% from the amount, this is VAT.
Above, we talked about scalability. So: 3 main areas in which the ability to quickly scale is important:
1. Application server. With a high load, they can not cope.
2. Database Servers
3. Content Servers
The rest is more or less stable.
For these directions, master-slave replication is great. In order for scaling to work, it needs to be understood. Therefore, we take a marker and draw on the board.
The user logs on to the site and accesses the front server, which can itself execute this request (in our case, it is called master), or send this request to a friend (slave server), which is no different from master. Therefore, if we encounter a situation where there are not enough resources of 2 servers, we just need to add one more slave server.
With content a little bit different. The application should know which server to upload images and videos, and from which server to read. Therefore, we have several master servers. And the application knows where the specific file is located. Expanding is also easy, add the server and upload pictures to it. And we already read each file from our server.
The project uses Mongo, it even has its own separate server on which it feels great.
Our technological stack is not tricky, we have been working according to the classical scheme that has been proven over the years. At the entrance Nginx - handles statics, sends dynamic requests for Apache. The code is written in PHP using the Zend Framework. Database - MySQL. Temporary storage, and in some cases permanent storage, MongoDB.
How does the server determine where to send the user? This is done by Nginx itself, it balances between application servers based on clients' IP addresses. A request from the same IP will always go to the same server. Query balancing is done using haproxy , which needed to be installed on each server. In addition, haproxy balances requests in round-robin mode to MySQL.
Of course, we have listed only the base, there are a lot of software that is involved in video conversion (FFMPEG), background tasks, etc.
Still, we work with ponderous content, so data backup is a very hot topic. We made backups incremental, but that's not all. For our own safety, we store melon on “third” servers. About how Tuffle backups are configured, plutov has already written in his blog .
There are many servers, so Munin helps us to keep track of them. It easily tracks all parameters both separately for servers and as a whole. Informs about critical points.
For us, this is a positive rejection of cloud solutions. For about six months, our server has never shut down, but Apache did not die. What and you want.
1. Often, with high attendance, the server just turned off. We had to constantly check the status of the site to be able to quickly respond to problems.
2. Management restrictions. Our dedicated server at the same time was a virtual server. As a result, all non-standard operations were performed using the ticket system, and this is terribly inconvenient.
')
3. With an increase in attendance in proportion to the growth and the price tag on the server. What seemed to be quite obvious, only the cost at a certain point became completely undemocratic and called into question the economics of cloud solutions.
And once they wrote to us that a DDoS attack was coming from our servers. We all rechecked, the alarm was false, but the unpleasant aftertaste remained.
By virtue of all of the above, we decided to organize our own server storage. This is where the fun begins.
Truly Dedicated Servers
And the decision was:
1. Adopt a pair of “clean” individual servers
2. Develop a horizontal scaling system
3. Distribute personal tasks between servers. Sometimes a few tasks.
First of all, we rushed to look for where to get such servers so that the channel was good and the price did not bite. As a result, we stopped at Hetzner and immediately bought 8 servers. And you know, it came out cheaper than the one at Selectel.
Server requirements
To begin with, we drew a table in which we painted, for which we need servers, what characteristics they should have, etc.
Vertical arrows, we denoted those characteristics that were most important for a particular server.
But it turned out that with Hetzner you cannot configure the iron filling yourself. Therefore, all of our 8 servers were exactly the same, namely EX40 . By the way, it is worth noting that for non-European countries, you can safely subtract 19% from the amount, this is VAT.
Above, we talked about scalability. So: 3 main areas in which the ability to quickly scale is important:
1. Application server. With a high load, they can not cope.
2. Database Servers
3. Content Servers
The rest is more or less stable.
For these directions, master-slave replication is great. In order for scaling to work, it needs to be understood. Therefore, we take a marker and draw on the board.
The user logs on to the site and accesses the front server, which can itself execute this request (in our case, it is called master), or send this request to a friend (slave server), which is no different from master. Therefore, if we encounter a situation where there are not enough resources of 2 servers, we just need to add one more slave server.
A similar scheme with databases.
With content a little bit different. The application should know which server to upload images and videos, and from which server to read. Therefore, we have several master servers. And the application knows where the specific file is located. Expanding is also easy, add the server and upload pictures to it. And we already read each file from our server.
The project uses Mongo, it even has its own separate server on which it feels great.
Server software
Our technological stack is not tricky, we have been working according to the classical scheme that has been proven over the years. At the entrance Nginx - handles statics, sends dynamic requests for Apache. The code is written in PHP using the Zend Framework. Database - MySQL. Temporary storage, and in some cases permanent storage, MongoDB.
How does the server determine where to send the user? This is done by Nginx itself, it balances between application servers based on clients' IP addresses. A request from the same IP will always go to the same server. Query balancing is done using haproxy , which needed to be installed on each server. In addition, haproxy balances requests in round-robin mode to MySQL.
Of course, we have listed only the base, there are a lot of software that is involved in video conversion (FFMPEG), background tasks, etc.
Data
Still, we work with ponderous content, so data backup is a very hot topic. We made backups incremental, but that's not all. For our own safety, we store melon on “third” servers. About how Tuffle backups are configured, plutov has already written in his blog .
Monitoring
There are many servers, so Munin helps us to keep track of them. It easily tracks all parameters both separately for servers and as a whole. Informs about critical points.
Conclusion
For us, this is a positive rejection of cloud solutions. For about six months, our server has never shut down, but Apache did not die. What and you want.
Source: https://habr.com/ru/post/218521/
All Articles