Compartilhamento de tecnologia

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

A arquitetura de alta disponibilidade no cluster lvs serve apenas para a alta disponibilidade do agendador.

Implementar os agendadores principais e de backup baseados em vrrp

Arquitetura HA altamente disponível

Agendador principal e agendador de backup (pode haver vários agendadores de backup)

Quando o escalonador está funcionando normalmente, o equipamento fica totalmente redundante (standby). Ele não participa da operação do cluster. Somente quando o agendador principal falhar, o backup assumirá o trabalho do agendador principal. Depois que o agendador principal recuperar sua função, o mestre continuará servindo como entrada para o cluster. , e o backup continuará em estado redundante (dependendo da prioridade).

Keepalive é baseado no protocolo vrrp para implementar solução de alta disponibilidade LVS.

1. Endereço multicast:

224.0.0.18 comunica-se com base no endereço multicast. Os dispositivos primário e secundário enviam mensagens para determinar se a outra parte está ativa.

2. Determinar as posições primária e secundária com base na prioridade.

3. Failover, se a máquina primária desligar, a máquina de backup continuará funcionando. Quando a máquina mestre se recuperar, a máquina de backup continuará aguardando.

4. A alternância entre primário e secundário é a alternância do endereço VIP.

Keepalive aparece especificamente para LVS, mas não é exclusivo para LVS.

módulo principal: o módulo principal do keepalive, responsável pela inicialização e manutenção do processo principal e pelo carregamento dos arquivos de configuração globais

Módulo vrrp: o módulo que implementa o protocolo vrrp, que é o módulo de função principal

módulo de verificação: Responsável pela verificação de integridade, podendo também verificar o status do servidor real em segundo plano.

Com base na experiência do modo DR no capítulo anterior, adicionamos algumas configurações. Desta vez, dois agendadores são usados, um primário e um de backup.

Primeiro instale o keepalive no agendador

yum -y install keepalived

Após a conclusão da instalação

Vamos alterar o arquivo keepalived.conf

[root@test1 ~]# vim /etc/keepalived/keepalived.conf
   notification_email_from [email protected]
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id LVS_01
   vrrp_skip_check_adv_addr
   vrrp_strict
   vrrp_garp_interval 0
   vrrp_gna_interval 0
   vrrp_iptables
}
 
vrrp_instance VI_1 {
    state MASTER
    interface ens33
    virtual_router_id 51
    priority 120
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.124.100
    }
}
 
virtual_server 192.168.124.100 80 {
    delay_loop 6
    lb_algo rr
    lb_kind DR
    persistence_timeout 50
    protocol TCP
 
    real_server 192.168.124.40 80 {
        weight 1
            TCP_CHECK {
            connect_port 80
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
 
    real_server 192.168.124.50 80 {
                                                                     9,1           36%

Copie o arquivo de configuração do primeiro agendador para o segundo agendador

scp root@192.168.233.10:/etc/keepallved/keepallved.conf
/etc/keepallved

Então altere a configuração

Prioridade do primário e secundário

Adicione uma opção iptables

Desta forma, o acesso às regras de keepalive não será interrompido na tabela de regras ipetables.

[root@localhost ~]# ipvsadm -ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  192.168.124.100:80 rr persistent 50
  -> 192.168.124.40:80            Route   1      0          0
  -> 192.168.124.50:80            Route   1      0          0

Confira

Então reinicie tudo

Dê uma olhada nos resultados do cliente

Vamos desligar o agendador principal primeiro

stsemctl stop keepalived.servers

O agendador de backup assume o trabalho do mestre e continua funcionando.

Este é o endereço VIP que foi carregado no agendador preparado. O cliente está acessando-o.

Ainda pode acessar

---

Resumir

Keepalived possui principalmente três módulos: core (módulo central, responsável pela inicialização do processo principal, manutenção e carregamento e análise de arquivos de configuração global), check (módulo de verificação de saúde) e vrrp (implementação do protocolo vrrp).

O princípio de funcionamento do Keepalived é baseado no protocolo VRRP. Vários servidores que fornecem as mesmas funções são formados em um grupo de servidores, que possui um mestre e vários backups. Existe um VIP no mestre que fornece serviços para o mundo externo (a rota padrão das outras máquinas na LAN onde o servidor está localizado é este VIP. O mestre enviará multicast quando o backup não puder receber o pacote VRRP). pensará que o mestre está inativo e, de acordo com a prioridade do nível VRRP, elegerá um backup para se tornar o novo mestre.

Ao configurar LVS + Keepalived, geralmente você precisa instalar software relacionado (como ipvsadm, keepalived) nos nós mestre e de backup e configurar o arquivo keepalived.conf. Por exemplo, no arquivo de configuração do nó mestre, você precisa especificar o estado (estado) como mestre, interface de rede (interface), ID de rota virtual (virtual_router_id), prioridade (prioridade), intervalo de anúncio (advert_int), informações de autenticação (autenticação) E endereço IP virtual (virtual_ipaddress), etc.; a configuração do nó de backup é semelhante, mas o status é backup e a prioridade geralmente é menor que a do mestre.

Após a conclusão da configuração, reinicie o serviço keepalived para obter balanceamento de carga de alta disponibilidade. Quando o nó mestre falhar, o VIP mudará automaticamente para o nó de backup para garantir o acesso normal ao serviço após a recuperação do mestre, ele servirá como nó de carga principal novamente; Além disso, o servidor real (rs) também pode ser configurado adequadamente. Por exemplo, ao usar o modelo DR para comunicação, lo deve ser configurado como VIP na placa de rede do rs.

Desta forma, a combinação LVS + Keepalived pode atingir os seguintes objetivos: o cliente acessa o serviço através do VIP, e a solicitação será distribuída de acordo com as regras de configuração quando o nó de balanceamento de carga do mestre falhar, podendo mudar automaticamente para o backup; nó para garantir que o serviço esteja normal; quando um determinado rs Quando um nó falha, o nó pode ser removido automaticamente e pode ser adicionado ao cluster novamente após a recuperação.

Em aplicações reais, questões relevantes precisam ser atentas, como o endereço IP configurado por virtual_ipaddress no arquivo de configuração Keepalived deve estar no mesmo segmento de rede, quanto maior o valor de prioridade, maior a probabilidade de o nó se tornar o mestre; nó; quanto menor o valor de advert_int, maior será a probabilidade do nó enviar mensagens VRRP. Ao mesmo tempo, factores como o ambiente de rede e o desempenho do servidor também devem ser considerados para garantir a estabilidade e o funcionamento eficiente de todo o sistema.