Difference between revisions of "Load-balancing"
(→Processes) |
(→Processes) |
||
Line 158: | Line 158: | ||
[[File:Load balancing.jpg]]<br /> | [[File:Load balancing.jpg]]<br /> | ||
'''Requests served'''<br /> | '''Requests served'''<br /> | ||
− | + | [[File:Served_requests.jpg]] | |
− | [[File:Served_requests.jpg]]< | + | <p> |
+ | A simple dispose of served requests. | ||
+ | </p> | ||
=Results= | =Results= |
Revision as of 21:09, 17 January 2016
- Project name: Load-balancing
- Class: 4IT496 (WS 2015/2016)
- Author: Bc. Patrik Tomášek
- Model type: Discrete-event simulation
- Software used: SimProcess, trial version
Contents
Problem definition
A hosting company with its own infrastructure is using so called "load balancing" to distribute the overall load between multiple servers (hardware nodes) and “high-availability” to minimize service down-time.
Load-balancing
In the case of web hosting service it means dividing the incoming request between multiple devices (called nodes) based on a set of rules (priority, weight, etc). The simulation is based on nginx (a webserver software) load balancing.
Note: In the picture the load-balacer isn't redundant, therefore HA isn't enabled. The simulation has two load-balances present.
High-avaibility
Ensures that a system or component is operational for desirable time. The solution necessary to provide web hosting consists of many parts, where all of them need to be on-line for the whole to be operational.
To enable HA a provider can use failover and backups. Failover is basically a backup piece of hardware, which ensures that when a component goes off-line another takes it's place. After that it's necessary to load the backup on the component that took over. If there is a SAN (storage area network) implemented than there is no need to load a backup, because failover just uses the same data from one central storage, which is used for all the server nodes. In the simulation a SAN is implemented and failover is taken into consideration.
Anti-DoS/DDoS
Denial-of-service (DoS) attack is an incident is witch the targeted service goes down. Distributed denial-of-service means, that more than one system is used to attack a single target. There are more means of possible protection against such attack. Setting up a decent firewall rules might be a good place to start, but it isn't so effective as implementing a device, which can mitigate the attack. A Radware defencePro device is implemented in the simulation.
The goal of the simulation is to find the optimal number of server and other components necessary to enable the mentioned functions (LB, HA, Anti-DoS).
Method
SIMPROCESS
Model
The simulation is divided into 4 main processes:
- New requests - generation of new requests, further information in Entities section.
- DoS mitigation - implementation of anti-dos device.
- Load balancing - main process, witch distributes the generated (incoming) request between resources.
- Served request - simple dispose of the generated requests.
The simulation is set to run in two 9 minutes iterations, using multiple schedules to apply the content changes of a web page (cached/un-cached content).
Generated request are the highest recorded numbers of the given hosting environment (so called peak). Other possibilities doesn't need to be taken into consideration because the system must be able to handle the peak and with owned hardware, there is not much use for downscaling. Besides the peak might come at odd hour, and starting up an off-line server takes a lot of time. It would be better to use the unallocated server usage for some other calculation, which might be beneficial for the provider.
Time unit used: seconds
Number of all requests: 9000 per second is the maximum recorded in the given environment. The number was divided by 100 for the simulation purposes (so it's 90).
Number of replications: 2
Entities
This is a list of all defined and used entities within the simulation.
Requests
The request data are based on real data from an hosting environment, that hosts multiple Magento e-shops (a rather complex system, which uses a lot of hardware).
The incoming request are categorised because Magento uses caching and indexing. It takes less time to server a cached content than un-cached one. Further more there are multiple schedules used to generate the requests. If new data have been added to the e-shop, that they need to be cached first, witch means more large requests.
- Small request
Request of a cached content.
- Standard request
Request of a content on storage server, no need to accesses database.
- Large request
Request of a content on storage server and database.
D-DoS
A large number of requests aiming to cripple the system.
Resources
This is only a brief summary of resources used, further information follows in processes section of this page.
When it comes to resource price, I take only lease into consideration. Of course it is also possible to purchase the given component. Cloud computing is also not considered.
Load-balancer
An important component described earlier on this page.
These devices are quite expensive. In case of lease, the price can be 300 USD monthly for a sufficient component for this simulation requirements.
Web server
There are two types of this resource, each with different capabilities:
Type 1 - a faster server that goes for 150 USD monthly
Type 2 - a slower server that goes for 100 USD monthly
Storage server SAN
In the simulation only SAN is used as a name of this resource.
The price of one SAN depends on the configuration (number of HDDs, etc.). A sufficient SAN can be leased for 220 USD monthly.
Database server
Database server is quite fast, so in the simulation only one is necessary, however to achieve HA even with DB server a second one should be implemented.
The price of one DB server is about 200 USD monthly.
Radware DefensePro
This is an anti-dos component implemented in the simulation.
The cost of this hardware is extreme, therefore partial lease is used.
The price depends on the internet connection of the provider, is this case it goes around 50 USD monthly.
Processes
New requests
In this process new requests are generated according to the following schedule:
Interval: 1 second
Entity type | Most content cached | Standard content | New content added | Sum of normal requests | Addition DoS requests (red square) |
---|---|---|---|---|---|
New small request (green dot) | Poi(45) | Poi(25) | Poi(13.5) | Poi(90) | Poi(150) |
New standard request (orange dot) | Poi(31.5) | Poi(45) | Poi(31.5) | Poi(90) | Poi(150) |
New large request (black dot) | Poi(13.5) | Poi(20) | Poi(45) | Poi(90) | Poi(150) |
DoS mittigation
This is a simple process, which implements anti-dos device and ensures that the system is not effected by the attack.
The "Branch" activity simply lets forward only the correct request and the rest is disposed, thus the attack is mitigated.
Without this device implemented the system would get flooded as later illustrated in results section of this page.
Load balancing
A simple dispose of served requests.
Results
Conclusion
Code
Sources
http://searchnetworking.techtarget.com/definition/load-balancing
http://searchstorage.techtarget.com/definition/failover
http://searchsoftwarequality.techtarget.com/definition/denial-of-service
http://searchsecurity.techtarget.com/definition/distributed-denial-of-service-attack
http://cepa.io/devlog/secure-https-load-balancing-with-nginx