Conteúdo
- 1 Visão Geral do GSLB
- 2 Quando usar o GSLB
- 3 Como funciona o GSLB?
- 4 Configurando o GSLB for Disaster Recovery de datacenters
- 5 Configurando o GSLB para datacenters ativos-ativos
- 6 Delegando uma zona no serviço GSLB da Zevenet
- 7 Criando uma subzona dedicada para o GSLB
- 8 Apontando um host em nosso próprio DNS referenciado a um serviço GSLB
Visão Geral do GSLB
Hoje em dia, a alta disponibilidade de serviços de TI é uma obrigação e é por isso que empresas e organizações desenvolvem sistemas de computação distribuídos ao redor do mundo e hospedam serviços em mais de um Data Center, oferecendo os seguintes benefícios:
Tolerância ao erro: quando o serviço hospedado no data center falha, o serviço continua em qualquer um dos outros sites disponíveis.
Recuperação automática de data center: quando um data center falha, o serviço é redirecionado automaticamente para qualquer outro data center disponível.
Balanceamento de carga: o tráfego pode ser otimizado distribuindo a carga entre todos os sites disponíveis, melhorando a latência e agilizando a entrega do serviço.
Latência Aprimorada: o tráfego do aplicativo cliente é diretamente com o servidor real, não é necessário passar todos os dados do aplicativo por meio do balanceador de carga.
A adoção e implementação de serviços de TI na nuvem exige que um método baseado em WAN seja a melhor opção para fornecer soluções de alta disponibilidade localizadas geograficamente. Isso é o que chamamos Balanceamento de carga de serviço global or GSLB.
Quando usar o GSLB
O serviço GSLB é recomendado para ser usado nos seguintes casos de uso:
Empresas que hospedam seus serviços em mais de um data center através da WAN.
Empresas que precisam criar alta disponibilidade de serviços ou data centers.
Provedores de serviços de Internet para criar serviços de balanceamento de carga de entrada a serem usados por seus usuários.
Definitivamente, quando é necessário compartilhar usuários e tráfego entre servidores ao redor do mundo sem pontos de falha, o GSLB é a solução certa.
Como funciona o GSLB?
GSLB é um mecanismo de balanceamento de carga DNS protocolo, é rápido e confiável porque usa UDP protocolo e a resposta do cliente é quase em tempo real.
Em uma solicitação de DNS comum, por exemplo www.zvnlb.net, um cliente envia a resolução de solicitação de DNS para os servidores DNS configurados localmente (por exemplo 8.8.8.8 e 8.8.4.4 ) e, em seguida, o sistema do cliente seleciona aleatoriamente um dos servidores para fazer a solicitação e enviar a consulta.
O servidor DNS selecionado recebe a solicitação do cliente (por exemplo, qual é o endereço IP de www.zvnlb.net? ) e os servidores DNS configurados localmente tentam descobrir quem é o responsável por resolver a zona DNS zvnlb.net.
O DNS usado pelo cliente, 8.8.8.8 or 8.8.4.4 neste caso, detecta que ns1.zvnlb.net e ns2.zvnlb.net são responsáveis por resoluções de zona para zvnlb.net então eles enviam a consulta DNS recebida pelo cliente (por exemplo, qual é o endereço IP do www.zvnlb.net? ) para um deles.
Um dos servidores de nome também ns1.zvnlb.net or ns2.zvnlb.net recebe a consulta DNS de 8.8.8.8 or 8.8.4.4 e, em seguida, o servidor de nomes que recebe a solicitação, verifica os servidores disponíveis para o host www.zvnlb.net e responderá à consulta DNS com a lista de servidores de aplicativos disponíveis para servir o aplicativo real para o host www.zvnlb.netAssim, esta informação será finalmente recebida pelo cliente.
Agora, o cliente selecionará aleatoriamente um dos servidores de aplicativos da lista recebida na consulta DNS e enviará diretamente a solicitação para o aplicativo http://www.zvnlb.net.
Os servidores de nome ns1.zvnlb.net (no nosso exemplo, localizado em Frankfurt) e ns2.zvnlb.net (no nosso exemplo, localizado em Toronto) estão constantemente verificando o estado de saúde da aplicação real do host www.zvnlb.net (192.235.113.3 e 194.23.52.21 no nosso caso). E se ns1.zvnlb.net or ns2.zvnlb.net detectar qualquer problema na verificação do status de integridade de alguns dos servidores reais, o servidor indisponível será desativado por um determinado período de tempo e seu endereço IP não será listado nas consultas DNS até que seja disponibilizado novamente.
O diagrama a seguir mostra o tráfego DNS descrito com recursos do GSLB.
Configurando o GSLB for Disaster Recovery de datacenters
Essa configuração é recomendada para serviços que exigem alta disponibilidade de Data Centers for Disaster Recovery, portanto, se todos os serviços de uma determinada empresa estiverem em um data center e esse data center falhar, o sistema moverá todos os serviços afetados para outro data center disponível. .
Por favor, siga este exemplo real de configuração do GSLB para construir um centro de dados ativo-passivo para recuperação de desastres.
Nós implantamos dois balanceadores de carga Zevenet em dois data centers em diferentes locais, Frankfurt 159.89.7.124 e Toronto 159.203.12.35 e nós temos um serviço web que responde ao host DNS www.zvnlb.net, configurado em Data Center 1 e Data Center 2. O design desta arquitetura vai permitir enviar todo o tráfego de clientes para o Data Center 1 mas se falhar, redireciona os clientes para Data Center 2.
Para obter essa configuração, siga o procedimento abaixo.
Conecte-se ao painel da web Zevenet no Data Center 1 (Frankfurt para o nosso caso), clique no menu principal GSLB módulo e criar um novo Fazenda, no nosso exemplo será chamado DNS1-Frankfurt na porta virtual 53.
Depois que o farm for criado, edite-o e vá até a guia Zonas e crie a zona DNS que será gerenciada pelo módulo GSLB, neste caso zvnlb.net, do seguinte modo:
Depois de criar esta zona, faça a primeira configuração conforme mostrado abaixo:
Observe que ns1 e ns2 são os Servidores de Nomes responsáveis pelas resoluções de DNS da zona zvnlb.net (no nosso caso, um serviço GSLB em Frankfurt e outro em Toronto).
Em seguida, conecte-se ao painel da web do Zevenet no Data Center 2, no menu principal, selecione GSLB e criar um novo Fazenda, no nosso caso será chamado DNS2-Toronto na porta virtual 53.
Edite o novo farm do GSLB e vá para a guia Zonas, crie aqui a zona DNS que será gerenciada por este serviço GSLB para zvnlb.net como se segue:
Depois que esta nova zona for criada, faça a primeira configuração da seguinte maneira:
Como o caso do GSLB no Data Center 1, os servidores de nomes n1 e n2 apontará para os serviços GSLB em ambos Data Center 1 e Data Center 2, Respectivamente.
Então clique na aba Serviços e criar um novo serviço, por exemplo webprioridade:
Selecione os Algoritmo opção Prioridade: Conexões sempre ao mais disponível e configure o serviço da seguinte forma:
Reinicie o farm para aplicar as alterações. É necessário aplicar a mesma configuração de serviço GSLB em ambos os data centers.
Note que se Guardião da Fazenda não está configurado para aplicar qualquer verificação de integridade, o serviço GSLB usa um padrão check_tcp para a porta TCP definida no campo de verificação de integridade na configuração do serviço.
Para ativar o novo serviço, vá para a zona criada (zvnlb.net no nosso caso) e criar um novo Recurso. Em seguida, crie-o selecionando o novo e eficaz como é mostrado abaixo.
Finalmente, salve as alterações. É necessário aplicar esta configuração em ambos os Data Centers.
Neste ponto, o hospedeiro www.zvnlb.net é gerenciado pelo módulo GSLB em Prioridade modo, então todo o tráfego será enviado para o Data Center 1 e, em seguida, se falhar, o tráfego será redirecionado para o outro disponível Data Center 2.
O TTL foi configurado para 5, é o tipo de data de validade que é colocada em um registro DNS. O TTL serve para informar ao servidor recursivo ou resolvedor local quanto tempo deve manter o registro em cache. Portanto, um valor mais baixo é configurado mais rapidamente que as alterações são detectadas.
Aplicando este método, poderíamos adicionar quantos datacenters forem necessários, incluindo novos Servidores de Nomes com o serviço GSLB.
A solicitação DNS a seguir mostra a configuração dos Nameservers para zvnlb.net e a resolução de DNS para o host www.zvnlb.net.
user@client:# host -t ns zvnlb.net zvnlb.net name server ns2.zvnlb.net. zvnlb.net name server ns1.zvnlb.net.
Ambos os servidores de nomes usam os endereços IP virtuais configurados nos farms do GSLB.
Agora, use seus servidores DNS atuais para resolver um host (por exemplo www) nesta zona:
user@client:# nslookup www.zvnlb.net Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: www.zvnlb.net Address: 188.166.230.211
Como é mostrado, atualmente o host 188.166.230.211 é o nó de aplicativo real ativo no Data Center 1. Assim que o host não estiver acessível (por exemplo, o serviço http 188.166.230.211 estiver desativado) a resolução DNS será alterada conforme mostrado abaixo.
user@client:# nslookup www.zvnlb.net Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: www.zvnlb.net Address: 139.59.186.84
Assim que o servidor de aplicativos falhar, a resolução do DNS alterará o host para Data Center 2. Uma vez que o host no Data Center 1 é até o failback será aplicado automaticamente.
Configurando o GSLB para datacenters ativos-ativos
A alta disponibilidade com o modo de prioridade é uma boa opção para um sistema de Disaster Recovery, mas o Data Center de backup que é usado para a recuperação não tem muito uso, então geralmente é mais eficiente balancear a carga de todo o tráfego entre os dados disponíveis centros.
Para tais casos, use o método de compartilhamento do seu serviço GSLB chamado Balanceamento De Carga Robin Redondo como é mostrado no exemplo para o novo serviço chamado web:
Agora, adicione-o na zona zvnlb.net e mude a configuração do recurso www como se segue:
Salve as alterações e reinicie o farm, se solicitado.
Para testá-lo, tente resolver o host www.zvnlb.net e a saída terá a seguinte aparência:
user@client:# nslookup www.zvnlb.net Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: www.zvnlb.net Address: 188.166.230.211 Name: www.zvnlb.net Address: 139.59.186.84
Observe que o resolvedor de DNS retorna os dois servidores de aplicativos, em vez de um como o caso da Recuperação de Desastres.
Quando o host tiver uma falha, a resolução do DNS será alterada automaticamente. Veja abaixo o que acontece.
root@client:# nslookup www.zvnlb.net Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: www.zvnlb.net Address: 139.59.186.84
O servidor de aplicativos indisponível está desativado na lista de respostas do DNS.
Assim que o host 188.166.230.211 está disponível novamente, ele será incluído novamente na resolução de DNS.
Delegando uma zona no serviço GSLB da Zevenet
No caso de uma zona pública (por exemplo zvnlb.net) que fornece um serviço GSLB como um resolvedor de servidor de nomes que precisa ser reconhecido por servidores DNS públicos para tal domínio, então é necessário registrar o endereço IP público usado pelo serviço GSLB no registrador de seu domínio (como NameCheap, Goddady ou outros) . O link a seguir explica como registrar IPs GSLB como NameServers em um procedimento de registro de domínio.
Registre um host como um NameServer
Após o procedimento dado, você deve se registrar ns1.zvnlb.net e ns2.zvnlb.net com os IPs fornecidos.
Criando uma subzona dedicada para o GSLB
Caso não seja possível delegar a resolução DNS ao serviço GSLB do Zevenet, pode-se realizar a configuração explicada a seguir. O exemplo a seguir mostra como construir um subzona para zvnlb.net que aponta para os NameServers dessa nova subzona no serviço GSLB.
Nó 1 (por exemplo ns1.zvnlb.net com IP 162.243.5.109) e Nó 2 (por exemplo ns2.zvnlb.net com IP 178.62.233.104) são servidores de nomes configurados e oferecendo serviços de resolução de DNS para a zona zvnlb.net, esta zona está sob um serviço de DNS público Bind9 e queremos oferecer recursos GSLB para alguns hosts de nossa infraestrutura, então decidimos criar a subzona DNS cluster.zvnlb.net e configure farms 2 GSLB como Nameservers DNS para essa finalidade.
Criamos a subzona para nosso domínio cluster.zvnlb.net nos nossos Servidores DNS Bind9 da seguinte forma:
Agora siga a seção Delegando uma zona no serviço GSLB da Zevenet , a fim de manter 159.89.7.124 e 159.203.12.35 no nosso exemplo como servidores de nomes reconhecidos para a zona cluster.zvnlb.net por servidores DNS públicos.
Então, você pode aplicar a configuração como é explicado para o domínio zvnlb.net na seção acima Configurando o GSLB para Recuperação de Desastres de Datacenters.
Apontando um host em nosso próprio DNS referenciado a um serviço GSLB
Nas seções anteriores, criamos um host chamado www.zvnlb.net balanceamento de carga nos modos de prioridade e round robin, para que possamos reutilizar essa configuração para oferecer recursos GSLB a outro servidor de nomes DNS que não oferece suporte a esse recurso por padrão.
Para conseguir essa configuração, precisamos apenas criar um novo Recurso na zona DNS que não suporta opções GSLB (por exemplo zevenet.io é gerenciado por Bind9) como um Nome canônico or CNAME como é mostrado abaixo:
Depois que a alteração for aplicada, www.zevenet.io estará apontando para www.zvnlb.net, mas se a resolução do host www.zvnlb.net muda então automaticamente www.zevenet.io vai mudar também.
Observe que esse exemplo é feito em um servidor DNS Bind9, mas os nomes canônicos ou CNAMES são configurações de host DNS suportadas por qualquer implementação de serviço de servidor DNS.
Esta explicação simples mostra que um serviço GSLB pode ser usado mesmo se nosso serviço DNS atual não oferecer recursos GSLB, apenas encaminhando a resolução de determinado host em uma zona não GSLB para o serviço GSLB no Zevenet Load Balancer.