Edgium / Edge Load Balancer
Load balancing at the edge: traffic goes to the origin that is up
Load balancing between different clouds and your datacenter, with automatic failover. If a server or service fails, Edgium notices and sends the visitor to another one before they notice anything.
An origin goes down, the visitor does not notice
The balancer sits on the anycast edge, close to whoever is visiting, and checks your origins all the time. When one fails, it leaves the route. When it answers again, it comes back in.
- visitor request
- pass-through to a healthy origin
- origin that failed the check
Swipe sideways to see the whole animation.
Several clouds, one address
Origins in different clouds, in your datacenter or in both. The visitor uses a single address.
Health check and failover
Each origin is tested all the time (health check). The one that fails leaves the route and comes back on its own when it answers.
Weight and affinity
You define how much each origin receives, and the same visitor tends to return to the same server, which preserves sessions.
Exclusive anycast IPs
Each balancer gets its own anycast IPs, the same at every point of the network, in Brazil and abroad.
DDoS protection and SYN flood
The attack is split across the points and stops at the edge, including floods of fake TCP connections (SYN flood).
Block by source
Networks or addresses that should not reach the service are kept out, with rules applied across the whole edge.
Not everything is a website: protocol streams
The balancer also passes TCP and UDP connections through the edge. The client connects to Edgium, and Edgium hands the connection to the available origin.
- SMTP: incoming email spread across servers, without exposing the IP of your real MX.
- SIP: telephony with a protected exchange and more than one server behind it.
- Databases: MySQL and SQL Server behind a single address, with the origin hidden.
- APIs: several origins behind a single address, with the failing one taken off the route.
- HTTP and HTTPS: with the connection opened close to the visitor, which reduces the time to first byte.
What changes for the company and for users
For the company
- No dependence on a single cloud: spread traffic across providers and negotiate with whoever you want.
- Maintenance without downtime windows: take an origin off the route, update it and put it back.
- Your own datacenter put to use: the cloud joins for the peak, and what you already have keeps working.
- Servers out of sight: whoever connects sees Edgium, never the IP of the application.
For users
- The system stays up even when a server goes down in the middle of the day.
- Faster answers, because the connection starts at the closest point and continues along a path that is already open.
- Sessions preserved, with no being thrown out of the system on every click.
Use examples
Common situations and how Edgium handles each one.
Systems, SaaS and APIs
A cloud goes down and the customer does not notice: automatic failover between origins and an API at the edge.
See the full exampleVoIP telephony and SIP exchanges
A SIP exchange out of the line of fire: hidden IP, attacks stopped at the edge and more than one server behind it.
See the full exampleCompanies with their own ERP, database and email
ERP and email reachable from outside, with the company's server hidden behind the edge.
See the full exampleQuestions about the Load Balancer
Do the origins have to be in the same cloud?
No. They can be in different clouds, in your datacenter or in a mix of both. For the visitor, it is a single address.
Does it work for more than websites?
Yes. Besides HTTP and HTTPS, the balancer handles TCP and UDP protocols, such as SMTP, SIP and database connections (MySQL and SQL Server).
Does the same visitor always land on the same server?
By default, the same IP tends to go to the same origin (affinity), which helps applications with sessions. You also set the weight of each origin.
How long does it take to remove a failing origin?
The origin is checked all the time. When it fails the check, it leaves the route, and it comes back on its own when it answers again.
Can I test the balancing before switching traffic?
Yes. Talk to us: Edgium sets up the origins and tests failover with you, through a test address, before real traffic goes through the balancer.
How many origins does your application have today?
Talk to Edgium: tell us where your servers are and which protocols go through them. We design the entry point with you and test it before switching traffic.