Edgium / Edge Load Balancer

Load Balancer na borda: o tráfego vai para a origem que está de pé

Balanceamento de carga entre nuvens diferentes e o seu datacenter, com failover automático. Se um servidor ou serviço falha, a Edgium percebe e manda o visitante para outro, antes que ele perceba alguma coisa.

Dois triângulos em verde-limão apontados um para o outro, ilustração do balanceador

Uma origem cai, o visitante nem percebe

O balanceador fica na borda anycast, perto de quem acessa, e verifica as suas origens o tempo todo. Quando uma falha, ela sai da rota. Quando volta a responder, entra de novo.

Animação: o Edge Load Balancer distribui os acessos entre duas nuvens e um datacenter; quando a Nuvem B falha na verificação, ela sai da rota e o tráfego segue para as outrasVisitantesLoad BalancerEdgium (anycast)Nuvem AorigemNuvem Borigemfalhou na verificação, saiu da rotaSeu datacenterorigem
  • acesso do visitante
  • repasse para uma origem saudável
  • origem que falhou na verificação

Arraste para o lado para ver a animação inteira.

Várias nuvens, um endereço

Origens em nuvens diferentes, no seu datacenter ou nos dois. O visitante usa um endereço só.

Verificação de saúde e failover

Cada origem é testada o tempo todo (health check). A que falha sai da rota e volta sozinha quando responde.

Peso e afinidade

Você define quanto cada origem recebe, e o mesmo visitante tende a voltar para o mesmo servidor, o que preserva sessões.

IPs anycast exclusivos

Cada balanceador recebe os seus próprios IPs anycast, os mesmos em todos os pontos da rede, no Brasil e no exterior.

Proteção DDoS e SYN flood

O ataque se divide entre os pontos e para na borda, inclusive a inundação de conexões TCP falsas (SYN flood).

Bloqueio por origem

Redes ou endereços que não devem acessar o serviço ficam de fora, com regras aplicadas em toda a borda.

Nem tudo é site: stream de protocolos

O balanceador também passa conexões TCP e UDP pela borda. O cliente conecta na Edgium, e a Edgium entrega na origem disponível.

  • SMTP: entrada de e-mail distribuída entre servidores, sem expor o IP do MX real.
  • SIP: telefonia com a central protegida e com mais de um servidor atrás.
  • Bancos de dados: MySQL e SQL Server atrás de um endereço só, com a origem escondida.
  • APIs: várias origens atrás de um endereço só, com a que falha fora da rota.
  • HTTP e HTTPS: com a conexão aberta perto do visitante, o que reduz o tempo até o primeiro byte.
Globo com pontos ligados por órbitas em verde-limão, ilustração da rede por onde passam os protocolos

O que muda para a empresa e para quem usa

Para a empresa

  • Sem depender de uma nuvem só: distribua entre provedores e negocie com quem quiser.
  • Manutenção sem janela de parada: tire uma origem da rota, atualize e devolva.
  • Datacenter próprio aproveitado: a nuvem entra para o pico, o que você já tem continua trabalhando.
  • Servidores fora da vista: quem conecta vê a Edgium, nunca o IP da aplicação.

Para quem usa

  • Sistema no ar mesmo quando um servidor cai no meio do dia.
  • Resposta mais rápida, porque a conexão começa no ponto mais perto e segue por um caminho já aberto.
  • Sessão preservada, sem ser jogado para fora do sistema a cada clique.

Exemplos de uso

Situações comuns e como a Edgium resolve cada uma.

Sistemas, SaaS e APIs

Uma nuvem cai e o cliente nem percebe: failover automático entre origens e API na borda.

Ver o exemplo completo

Telefonia VoIP e centrais SIP

Central SIP fora da mira: IP escondido, ataque na borda e mais de um servidor atrás.

Ver o exemplo completo

Empresas com ERP, banco de dados e e-mail próprio

ERP e e-mail acessíveis de fora, com o servidor da empresa escondido atrás da borda.

Ver o exemplo completo

Perguntas sobre o Load Balancer

As origens precisam estar na mesma nuvem?

Não. Elas podem estar em nuvens diferentes, no seu datacenter ou numa mistura dos dois. Para o visitante, é um endereço só.

Funciona para algo além de site?

Sim. Além de HTTP e HTTPS, o balanceador atende protocolos TCP e UDP, como SMTP, SIP e conexões de banco de dados (MySQL e SQL Server).

O mesmo visitante cai sempre no mesmo servidor?

Por padrão, o mesmo IP tende a ir para a mesma origem (afinidade), o que ajuda aplicações com sessão. Você também define o peso de cada origem.

Quanto tempo leva para tirar uma origem com problema?

A origem é verificada o tempo todo. Quando falha na verificação, sai da rota, e volta sozinha quando responde de novo.

Dá para testar o balanceamento antes de virar o tráfego?

Sim. Converse com a gente: a Edgium configura as origens e testa o failover com você, por um endereço de teste, antes de o tráfego de verdade passar pelo balanceador.

Quantas origens a sua aplicação tem hoje?

Converse com a Edgium: conte onde estão os servidores e quais protocolos passam por eles. A gente desenha a entrada com você e testa antes de virar o tráfego.