Crie alta disponibilidade de keepalived + nginx hot standby (standby ativo + modo ativo duplo)

---

Prefácio

O Nginx mestre desliga, mas o nginx escravo pode funcionar imediatamente

Use a tecnologia vrrp para fornecer VIP

Quando o nginx principal desligar, use um script para desligar o keepalied principal. O keepalived usa a tecnologia vrrp para obter VIP na máquina escrava, instalar o mesmo nginx e configuração na máquina escrava, e a máquina escrava continua a fornecer serviços para o mundo exterior através do VIP.

Artigos relacionados:
[Nginx-Este artigo é suficiente para aprender nginx]
[Plano de implementação de alta disponibilidade LVS + KeepAlived + Nginx]

---

Uma introdução mantida viva

nginx:
É uma excelente ferramenta de proxy reverso que suporta distribuição de solicitações, balanceamento de carga, cache e outras funções muito práticas. Em termos de processamento de solicitações, o nginx usa o modelo epoll, que é um modelo baseado no monitoramento de eventos, por isso tem uma eficiência de processamento de solicitações muito eficiente e a capacidade de simultaneidade de uma única máquina pode chegar a milhões. As solicitações recebidas pelo nginx podem ser distribuídas aos seus servidores de aplicativos de nível inferior por meio de políticas de balanceamento de carga. Esses servidores geralmente são implantados em clusters. Portanto, no caso de desempenho insuficiente, o servidor de aplicativos pode expandir o tráfego adicionando máquinas. No momento, para alguns sites muito grandes, o gargalo de desempenho vem do nginx, porque a capacidade de simultaneidade de uma única máquina nginx tem um limite superior e o próprio nginx não suporta o modo cluster, então a expansão horizontal do nginx neste momento é parece particularmente importante.

Keepalived:
É um software de execução altamente confiável que implementa roteamento de backup VRRP no Linux. O modelo de serviço projetado com base no Keepalived pode realmente alcançar a transferência de IP instantânea e contínua quando o servidor principal e o servidor de backup falham.

Protocolo VRRP:
o nome completo é Virtual Router Redundancy Protocol
, que é o protocolo de redundância de roteamento virtual. Pode ser considerado um protocolo tolerante a falhas para alcançar alta disponibilidade de roteadores. N roteadores que fornecem as mesmas funções são formados em um grupo de roteadores (RouterGroup). Este grupo tem um mestre e vários backups, mas parece um só para o exterior. Constitui um roteador virtual e possui um IP virtual (vip, que é a rota padrão para outras máquinas na LAN onde o roteador está localizado). O mestre proprietário deste IP é o responsável pela resposta ARP e pelo encaminhamento de pacotes IP. Outros roteadores do grupo estão em espera como funções de backup. O mestre enviará mensagens multicast. Quando o backup não consegue receber pacotes vrrp dentro do período de tempo limite, considera-se que o mestre está inativo. Neste momento, um backup precisa ser eleito como mestre com base na prioridade VRRP para garantir o alta disponibilidade do roteador.

Resumo: As duas máquinas ativas e de backup são mantidas vivas para criar um IP virtual, que é VIP, o que não significa VIP, mas sim IP Virtual. O VIP passa a pertencer à máquina principal e a máquina de backup fica em estado inativo. Ao mesmo tempo, a comunicação entre os dois keepalived é equivalente a uma linha de pulsação. Eles se comunicam entre si através da linha de pulsação. Como contanto que a máquina principal monitore (por meio de um script) até que o serviço ngin pare, a máquina principal pare de manter a atividade por conta própria e entregue o VIP à máquina de backup para lidar com solicitações da web até que a máquina principal retorne ao normal novamente e devolva o VIP ao máquina principal.

A arquitetura é mostrada na figura abaixo:

Duas formas de alta disponibilidade:

1. Modo mestre-escravo

Esta solução usa um endereço VIP e usa 2 máquinas no front-end. Uma é a mestre e a outra é o backup. No entanto, apenas uma máquina está funcionando ao mesmo tempo. A outra máquina de backup sempre será desperdiçada quando a máquina principal funcionar não funciona mal., para sites com poucos servidores, esta solução não é econômica.

2. Modo mestre duplo

Esta solução usa dois endereços VIP e 2 máquinas no front-end para servir como primária e de backup uma para a outra. Duas máquinas funcionam ao mesmo tempo. Quando uma das máquinas falha, as solicitações das duas máquinas são transferidas para uma máquina, que é muito adequada ao ambiente arquitetônico atual.

Como mostrado abaixo:

2. Construção ambiental

1. Preparação do ambiente (o sistema centos7 é usado aqui)

NOME DE ANFITRIÃO	PI	ilustrar
manter1	192.168.92.100	servidor mestre keepalived (mesmo balanceador de carga mestre nginx)
manter2	192.168.92.101	servidor mestre keepalived (mesmo balanceador de carga mestre nginx)
web1	192.168.92.102	Nó do servidor web back-end (balanceamento de carga configurado no nginx) Este artigo é para conveniência de teste (opcional)
manter4	192.168.92.103	Máquina de teste de cliente simulada (opcional)

Para conveniência do teste, este artigo usa apenas dois servidores (keep1, keep12) para demonstração.

2. instalação mantida

Recomenda-se usar o Xshell para operação simultânea de múltiplos terminais e operação simultânea de múltiplas janelas.

Este artigo não entrará em detalhes sobre a instalação do nginx . Se necessário, consulte o Baidu.

# 安装ipvs
yum install ipvsadm

# 安装keepalived
yum install keepalived

Comandos comuns

#启动
systemctl start keepalived
#停止
systemctl stop keepalived
重启# 
systemctl restart keepalived
#查看状态
systemctl status keepalived
#设置开机启动
systemctl enable keepalived
#关闭开机启动
systemctl disable keepalived

Configurações relevantes podem ser modificadas editando o arquivo keepalived.conf no diretório /etc/keepalived/.

vim /etc/keepalived/keepalived.conf 

• CentOS 7 tem o firewall firewalld instalado por padrão. Desligue o firewall.

#启动防火墙
systemctl start firewalld
#关闭防火墙
systemctl stop firewalld

3. configurações relacionadas ao keepalived

1. script e configuração nginx

Como será testado posteriormente, o primeiro script simples é suficiente.Enquanto for considerado que o processo nginx não tem valor, o serviço keepalived será interrompido. O script de teste é o seguinte:

#! /bin/bash
pidof nginx
if [ $? -ne 0 ];then
systemctl stop keepalived
fi

Se o teste for concluído, você pode adicionar uma tentativa de iniciar o nginx. Se a tentativa falhar duas vezes, interrompa o serviço keepalived.
Crie o script check_nginx.sh. O script é o seguinte:

#!/bin/bash
counter=$(ps -C nginx --no-heading|wc -l)
if [ "${counter}" = "0" ]; then
    /usr/local/nginx/sbin/nginx
    sleep 2
    counter=$(ps -C nginx --no-heading|wc -l)
    if [ "${counter}" = "0" ]; then
      systemctl stop keepalived
    fi
fi

Configuração do nginx no servidor nginx: você só precisa alterar o server_name para o IP do VIP. Nenhuma outra alteração é necessária. Durante o balanceamento de carga, você só precisa acessar esse endereço VIP para facilitar o teste. Este artigo retorna diretamente a string por
meio proxy. Na operação real, local Configure o proxy reverso de back-end em .

server {
    
    
	      listen       80;
	      #server_name  192.168.92.200;  #vip地址可加可不加
	      location / {
    
    
		  default_type text/html;
		  return 200 "Hello, Nginx! Server 192.168.92.100";
	      }
     }

2. Modo ativo e de backup

1.configuração mantida

Esta configuração está no modo de espera ativo. Depois de entender primeiro o modo de espera ativo, será mais fácil configurar o modo ativo duplo.
Localização do arquivo de configuração:

/etc/keepalived/keepalived.conf
vi /etc/keepalived/keepalived.conf

Existem três módulos básicos, módulo global global_defs, módulo vip de configuração vrrp_instance e módulo de script vrrp_script, usado para detectar serviços nginx.
Nota: Após vrrp_script definir o script, o parâmetro track_script deve ser adicionado ao módulo vrrp_instance. Caí nessa armadilha, fazendo com que o script não entrasse em vigor.

Parâmetros do módulo global_defs

• notification_email: keepalived precisa enviar um endereço de notificação por e-mail quando ocorre uma operação de troca, e o seguinte smtp_server também é conhecido como o endereço do servidor de e-mail. Você também pode chamar a polícia por outros métodos, afinal os e-mails não são notificados em tempo real.
• router_id: Identificação da máquina, geralmente definida como nome do host. Notificações por e-mail são usadas quando ocorrem falhas.

Parâmetros do módulo vrrp_instance

• state: Especifique o estado inicial da instância (Inicial), MASTER ou BACKUP, que não é único e está relacionado ao parâmetro de prioridade por trás dele.
• interface: A placa de rede vinculada à instância, pois ao configurar o IP virtual ela deve ser adicionada à placa de rede existente (preste atenção no seu próprio sistema, o meu é ens33 por padrão, e alguns são eth0)
• mcast_src_ip: O endereço IP de origem ao enviar pacotes multicast. Preste atenção aqui. Na verdade, isso está enviando notificações VRRP nesse endereço. Isso é muito importante. Você deve escolher uma porta de placa de rede estável para enviar. Isso é equivalente à porta de pulsação de pulsação. Se não estiver definido, será usado o IP padrão da placa de rede vinculada, que é o endereço IP especificado pela interface.
• virtual_router_id: Defina VRID aqui, é muito importante aqui, o mesmo VRID é um grupo, vai determinar o endereço MAC do multicast
• priority: Defina a prioridade deste nó, aquele com maior prioridade é o mestre (1-255)
• advert_int: Intervalo de verificação, o padrão é 1 segundo. Este é o temporizador VRRP. A cada intervalo de tempo, o MASTER enviará uma mensagem publicitária para notificar os outros roteadores do grupo que está funcionando normalmente.
• authentication: Defina o método de autenticação e a senha. O mestre e o escravo devem ser iguais.
• virtual_ipaddress: O que é definido aqui é o VIP, que é o endereço IP virtual. Ele é adicionado e excluído conforme o estado muda. É adicionado quando o estado é mestre e excluído quando o estado é backup. É determinado principalmente pela prioridade. É tem pouco a ver com o valor definido por estado. Vários endereços IP podem ser definidos aqui.
• track_script: referência ao script VRRP, o nome especificado na seção vrrp_script. Execute-os periodicamente para alterar as prioridades e, eventualmente, acionar uma alternância ativo/em espera.

O parâmetro do módulo vrrp_script
diz ao keepalived para mudar em que circunstâncias, por isso é particularmente importante. Pode haver vários vrrp_scripts

• script: Um script de detecção escrito por mim. Também pode ser um comando de uma linha, como killall -0 nginx
• interval 2: Detectado a cada 2s
• weight -5: Se a detecção falhar (o script retornar diferente de 0), a prioridade será -5
• fall 2: O teste deve falhar 2 vezes seguidas para ser considerado uma falha verdadeira. Usará peso para reduzir a prioridade (entre 1-255)
• rise 1: É considerado bem-sucedido se a detecção for bem-sucedida uma vez. mas não altera a prioridade

No servidor nginx principal 192.168.92.100, o VIP está definido como 192.168.92.200 e a configuração é a seguinte:

! Configuration File for keepalived

global_defs {
    
    
  router_id Nginx_01
}
vrrp_script check_nginx {
    
    
	script "/etc/keepalived/check_nginx.sh"
	interval 2
    weight -5
    fall 3
    rise 2
}
vrrp_instance VI_1 {
    
    
    state MASTER
    interface ens33
    virtual_router_id 51
    priority 150
    advert_int 1
    authentication {
    
    
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
    
    
        192.168.92.200

    }
	track_script {
    
    
    	check_nginx
    }
}

No servidor nginx de backup 192.168.92.101, a configuração é a mesma, mas há três diferenças, uma das quais deve ser a mesma: 1. O router_id é diferente, 2. o estado BACKUP é diferente e 3. a prioridade é diferente. 4.virtual_router_id deve ser o mesmo. A configuração é a seguinte:

! Configuration File for keepalived

global_defs {
    
    
		router_id Nginx_02
}
vrrp_script check_nginx {
    
    
	script "/etc/keepalived/check_nginx.sh"
	interval 2
    weight -5
    fall 3
    rise 2
}
vrrp_instance VI_1 {
    
    
    state BACKUP
    interface ens33
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
    
    
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
    
    
        192.168.92.200
    }
	
	track_script {
    
    
    	check_nginx
    }
}

2. Inicie o teste e verifique o IP

Reinicie dois keepalived

syetemctl restart keepalived
ip a

Verifique o ip, você pode ver que o vip agora está no servidor 100

1. Teste se o VIP está disponível

[root@bogon keepalived]# curl http://192.168.92.200
Hello, Nginx! Server 192.168.92.100

2. Interrompa um keepalived e verifique se o VIP mudou

Quando o keepalived for interrompido no serviço 100, solicite novamente o endereço do serviço e verifique os resultados. O servidor 101 é solicitado.

[root@bogon keepalived]# curl http://192.168.92.200
Hello, Nginx! Server 192.168.92.101

3. Modo mestre duplo

1.configuração mantida

Depois de compreender os modos ativo e de espera, o modo ativo duplo é muito mais fácil de configurar. Basta adicionar um vrrp_instance chamado vrrp_instance VI_2 a cada arquivo de configuração keepalived, alterar alguns parâmetros e definir outro VIP: a
configuração 192.168.200.201 keep1 é a seguinte:

! Configuration File for keepalived

global_defs {
    
    
  router_id Nginx_01
}
vrrp_script check_nginx {
    
    
	script "/etc/keepalived/check_nginx.sh"
	interval 2
    weight -5
    fall 3
    rise 2
}
vrrp_instance VI_1 {
    
    
    state MASTER
    interface ens33
    virtual_router_id 51
    priority 150
    advert_int 1
    authentication {
    
    
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
    
    
        192.168.92.200

    }
	track_script {
    
    
    	check_nginx
    }
}
#  100------100
vrrp_instance VI_2 {
    
    
    state BACKUP
    interface ens33
    virtual_router_id 52
    priority 100
    advert_int 1
    authentication {
    
    
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
    
    
        192.168.92.201

    }
	track_script {
    
    
    	check_nginx
    }
}

A configuração do keep2 é a seguinte:

! Configuration File for keepalived

global_defs {
		router_id Nginx_02
}
vrrp_script check_nginx {
	script "/etc/keepalived/check_nginx.sh"
	interval 2
    weight -5
    fall 3
    rise 2
}
vrrp_instance VI_1 {
    state BACKUP
    interface ens33
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.92.200
    }
	
	track_script {
    	check_nginx
    }
}
#  101------101
vrrp_instance VI_2 {
    state MASTER
    interface ens33
    virtual_router_id 52
    priority 150
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.92.201

    }
	track_script {
    	check_nginx
    }
}

Após a conclusão da modificação, inicie keep1 e keep2 respectivamente para verificar o status VIP da ligação.

2. Inicie o teste e verifique o IP

ip addr

Se você vir os resultados a seguir, a configuração foi bem-sucedida.

1. Teste se o VIP está disponível

Os resultados a seguir indicam que a configuração foi bem-sucedida, como segue:

[root@bogon ~]# curl http://192.168.92.201
Hello, Nginx! Server 192.168.92.101
[root@bogon ~]# curl http://192.168.92.200
Hello, Nginx! Server 192.168.92.100

2. Interrompa um keepalive e verifique se o vip foi desviado.

Em seguida, paramos o serviço keep de 192.168.90.100

systemctl stop keepalived

Verifique o endereço IP do servidor 101.

Quando o keepalived no serviço 100 for interrompido, solicite o endereço do serviço novamente e verifique os resultados. O servidor 101 é solicitado.

[root@bogon ~]# curl http://192.168.92.201
Hello, Nginx! Server 192.168.92.101
[root@bogon ~]# curl http://192.168.92.200
Hello, Nginx! Server 192.168.92.101

Inicie manualmente o servidor 100 e você descobrirá que o endereço 200 foi vinculado automaticamente.

4. Explicação detalhada do arquivo de configuração keepalived (referência)

#全局配置
global_defs {
   # 邮件通知信息
   notification_email {
     # 定义收件人
     [email protected]
   }
   # 定义发件人
   notification_email_from [email protected]
   # SMTP服务器地址
   smtp_server 192.168.200.1
   smtp_connect_timeout 30
   # 路由器标识，一般不用改，也可以写成每个主机自己的主机名
   router_id LVS_DEVEL
   # VRRP的ipv4和ipv6的广播地址，配置了VIP的网卡向这个地址广播来宣告自己的配置信息，下面是默认值
   vrrp_mcast_group4 224.0.0.18
   vrrp_mcast_group6 ff02::12
}

# 定义用于实例执行的脚本内容，比如可以在线降低优先级，用于强制切换
vrrp_script SCRIPT_NAME {

}

# 一个vrrp_instance就是定义一个虚拟路由器的，实例名称
vrrp_instance VI_1 {
    # 定义初始状态，可以是MASTER或者BACKUP
    state MASTER
    # 工作接口，通告选举使用哪个接口进行
    interface ens33
    # 虚拟路由ID，如果是一组虚拟路由就定义一个ID，如果是多组就要定义多个，而且这个虚拟
    # ID还是虚拟MAC最后一段地址的信息，取值范围0-255
    virtual_router_id 51
    # 使用哪个虚拟MAC地址
    use_vmac XX:XX:XX:XX:XX
    # 监控本机上的哪个网卡，网卡一旦故障则需要把VIP转移出去
    track_interface {
        eth0
        ens33
    }
    # 如果你上面定义了MASTER,这里的优先级就需要定义的比其他的高
    priority 100
    # 通告频率，单位为秒
    advert_int 1
    # 通信认证机制，这里是明文认证还有一种是加密认证
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    # 设置虚拟VIP地址，一般就设置一个，在LVS中这个就是为LVS主机设置VIP的，这样你就不用自己手动设置了
    virtual_ipaddress {
        # IP/掩码 dev 配置在哪个网卡
        192.168.200.16/24 dev eth1
        # IP/掩码 dev 配置在哪个网卡的哪个别名上
        192.168.200.17/24 dev label eth1:1
    }
    # 虚拟路由，在需要的情况下可以设置lvs主机 数据包在哪个网卡进来从哪个网卡出去
    virtual_routes {
        192.168.110.0/24 dev eth2
    }
    # 工作模式，nopreempt表示工作在非抢占模式，默认是抢占模式 preempt
    nopreempt|preempt
    # 如果是抢占默认则可以设置等多久再抢占，默认5分钟
    preempt delay 300
    # 追踪脚本，通常用于去执行上面的vrrp_script定义的脚本内容
    track_script {

    }
    # 三个指令，如果主机状态变成Master|Backup|Fault之后会去执行的通知脚本，脚本要自己写
    notify_master ""
    notify_backup ""
    notify_fault ""
}

# 定义LVS集群服务，可以是IP+PORT；也可以是fwmark 数字，也就是防火墙规则
# 所以通过这里就可以看出来keepalive天生就是为ipvs而设计的
virtual_server 10.10.10.2 1358 {
    delay_loop 6
    # 算法
    lb_algo rr|wrr|lc|wlc|lblc|sh|dh 
    # LVS的模式
    lb_kind NAT|DR|TUN
    # 子网掩码，这个掩码是VIP的掩码
    nat_mask 255.255.255.0
    # 持久连接超时时间
    persistence_timeout 50
    # 定义协议
    protocol TCP
    # 如果后端应用服务器都不可用，就会定向到那个服务器上
    sorry_server 192.168.200.200 1358

    # 后端应用服务器 IP PORT
    real_server 192.168.200.2 1358 {
        # 权重
        weight 1
        # MSIC_CHECK|SMTP_CHEKC|TCP_CHECK|SSL_GET|HTTP_GET这些都是
        # 针对应用服务器做健康检查的方法
        MISC_CHECK {}
        # 用于检查SMTP服务器的
        SMTP_CHEKC {}

        # 如果应用服务器不是WEB服务器，就用TCP_CHECK检查
        TCP_CHECK {
          # 向哪一个端口检查，如果不指定默认使用上面定义的端口
          connect_port <PORT>
          # 向哪一个IP检测，如果不指定默认使用上面定义的IP地址
          bindto <IP>
          # 连接超时时间
          connect_timeout 3
        }

        # 如果对方是HTTPS服务器就用SSL_GET方法去检查，里面配置的内容和HTTP_GET一样
        SSL_GET {}

        # 应用服务器UP或者DOWN，就执行那个脚本
        notify_up "这里写的是路径，如果脚本后有参数，整体路径+参数引起来"
        notify_down "/PATH/SCRIPTS.sh 参数"

        # 使用HTTP_GET方法去检查
        HTTP_GET {
            # 检测URL
            url { 
              # 具体检测哪一个URL
              path /testurl/test.jsp
              # 检测内容的哈希值
              digest 640205b7b0fc66c1ea91c463fac6334d
              # 除了检测哈希值还可以检测状态码，比如HTTP的200 表示正常，两种方法二选一即可
              status_code 200
            }
            url { 
              path /testurl2/test.jsp
              digest 640205b7b0fc66c1ea91c463fac6334d
            }
            url { 
              path /testurl3/test.jsp
              digest 640205b7b0fc66c1ea91c463fac6334d
            }
            # 向哪一个端口检查，如果不指定默认使用上面定义的端口
            connect_port <PORT>
            # 向哪一个IP检测，如果不指定默认使用上面定义的IP地址
            bindto <IP>
            # 连接超时时间
            connect_timeout 3
            # 尝试次数
            nb_get_retry 3
            # 每次尝试之间间隔几秒
            delay_before_retry 3
        }
    }

    real_server 192.168.200.3 1358 {
        weight 1
        HTTP_GET {
            url { 
              path /testurl/test.jsp
              digest 640205b7b0fc66c1ea91c463fac6334c
            }
            url { 
              path /testurl2/test.jsp
              digest 640205b7b0fc66c1ea91c463fac6334c
            }
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
}

Resumir

O acesso aos dois VIPs configurados em keepalived pode ser agendado normalmente. Quando paramos qualquer nó keepalived, o acesso ainda é normal. Neste ponto, a construção de alta disponibilidade de keepalived + nginx hot standby (standby ativo + modo ativo duplo) está concluída.