Como seu caso de uso é bastante personalizado e suas necessidades podem mudar no futuro, por que você não faz algo como o seguinte...

crie um novo timer systemd (por exemplo failover-manager, ) em ambas as máquinas que execute uma vez por minuto. O timer systemd iniciará um serviço systemd one-shot associado em intervalos regulares.

Esse serviço systemd one-shot pode apenas executar um script bash que contém sua lógica:

• execute seu amIthePrimarycheque
• se primário, inicie seu serviço systemd e verifique se ele foi iniciado sem erros.
• se não for primário, pare o serviço systemd se estiver em execução.
• se o seu script não puder iniciar/parar/verificar a execução, ele deverá falhar (monitorável), caso contrário, será bem-sucedido.
• este script de temporizador não precisa produzir nada (ruído), exceto quando faz uma alteração, ou seja:
  • "Sou primário, mas o serviço não está em execução. Iniciando... Aguardando alguns segundos... o serviço verificado está sendo executado sem erros." ou
  • "Eu não sou o principal, mas o serviço ESTÁ em execução. Parando."

Dessa forma, você sempre sabe que pode monitorar se sua verificação regular/temporizador está sendo executada sem erros. Se o seu serviço de timer tiver problemas (saída diferente de zero), você poderá detectar isso com o monitoramento. Você pode monitorar as falhas do seu serviço de aplicativo principal separadamente.

Se suas necessidades mudarem, você pode facilmente adaptar seu script de timer ou a frequência em que ele é executado.

Provavelmente existem maneiras mais limpas de fazer isso, mas elas provavelmente dependeriam de um evento sendo gerado a partir do que está por trás do seu amIthePrimarycheque... e você não forneceu nenhum detalhe sobre isso. ou seja, failover orientado a eventos em vez de polling.

Você também pode colocar sua amIthePrimaryverificação em ExecStartPre=... mas quando ele falhar em impedir que o serviço seja iniciado, seu serviço estará em um estado FAILED, o que pode confundir seu monitoramento porque não é uma falha ruim, mas sim uma falha intencional. Portanto, talvez você prefira usar a abordagem do temporizador, pois pode monitorar seu processo de temporizador e seu processo de serviço principal separadamente. timer deve estar sempre em execução, ativo e não falhando. Seu serviço (se estiver em execução) nunca deve estar em um estado de falha ou o monitoramento deve ser desativado. Há outra questão sobre como saber se o serviço deve ou não estar sendo executado sob uma perspectiva de monitoramento, mas isso está além do escopo da questão.

Atualização - incluindo exemplo de implementação de amostra

Não testado, mas apenas para deixar minha sugestão mais clara.

failover-manager.sh

Digamos que este script seja implantado para/opt/failover-manager/failover-manager.sh

#!/bin/bash

# expected ENV.  Provided by the service that starts this script.
#
# APP_SERVICE (your main application)
# SECONDS_TO_START (e.g. some java apps start very slowly)

if [ -z "$APP_SERVICE" -o -z "$SECONDS_TO_START" ]; then
    echo "Missing environment"
    exit 1
fi

function is_running {
    systemctl is-active --quiet $1
    return $?
}

if amIthePrimary; then
    if is_running $APP_SERVICE; then   # no change, no log
        exit 0
    else
        echo "I AM primary, but service NOT running.  STARTING..."
        systemctl start $APP_SERVICE
        sleep $SECONDS_TO_START
        if is_running $APP_SERVICE; then 
            echo "Verified service is STARTED without error: $APP_SERVICE."
            exit 0
        else
            echo "Service $APP_SERVICE has not yet STARTED after $SECONDS_TO_START seconds."
            exit 1
        fi
    fi
else
    if is_running $APP_SERVICE; then 
        echo "I am NOT primary, but service IS running.  Stopping..."
        systemctl stop $APP_SERVICE
        sleep $SECONDS_TO_START
        if is_running $APP_SERVICE; then 
            echo "Service $APP_SERVICE has not yet STOPPED after $SECONDS_TO_START seconds."
            exit 1
        else
            echo "Verified service is STOPPED: $APP_SERVICE."
            exit 0
        fi
    else   # no change, no log
        exit 0
    fi
fi

failover-manager.timer

[Unit]
Description=Timer that starts failover-manager.service
Requires=failover-manager.service

[Timer]
Unit=failover-manager.service
# every 1 minute
OnCalendar=*:0/1
AccuracySec=1s
Persistent=true


[Install]
WantedBy=timers.target

failover-manager.service

Esse cara é executado pelo temporizador acima.

[Unit]
Description=Checks if we need to start or stop our application.

[Service]
Type=oneshot
Environment=APP_SERVICE="my-application.service" SECONDS_TO_START="5"    
WorkingDirectory=/opt/failover-manager/
ExecStart=/opt/failover-manager/failover-manager.sh

User=root
Group=root

opções puras do systemd?

Se você estiver procurando por um mecanismo systemd puro para fazer isso de maneira limpa, talvez não seja possível.

Seu caso de uso é personalizado e IMO além do escopo do systemd.

Portanto, você pode "hackear" usando ExecStartPreou usando requires/ wantsmecanismos de dependência de tipo ... mas todas essas abordagens dependem de um processo estar no estado parado devido a uma falha (monitoramento de interrupções ... ... ou esse processo sendo iniciado/parado por "algo" que está ciente de algo fora do mundo systemd. O último não interrompe o monitoramento, mas requer algo além do systemd e o que propus é uma maneira de fazer isso.

alternativas

Como @anx sugeriu... talvez re-engenharia como seu failover de DR funciona.

Essa também é a abordagem que adotamos. Se tivermos uma caixa de espera/nuvem/rack/etc, então gostamos de ter certeza de que tudo já está funcionando (por exemplo, serviços, etc).

Então a questão é apenas... como fazer a transição.

Há duas maneiras comuns de realizar o failover para um endpoint em espera...

1 - Failover DNS

Defina um ttl DNS baixo (tempo de cache) para seus terminais críticos e atualize seus registros DNS para apontar para o terminal em espera (por exemplo, atualização de DNS CNAME, A, AAAA) quando uma falha for detectada.

Muitos provedores de DNS gerenciados (por exemplo, dnsmadeeasy, dynect) oferecem isso como parte de seu serviço (detecção e failover). Mas é claro que você pode implementar isso com seu próprio DNS ou qualquer provedor de DNS que permita definir um TTL baixo e facilmente, manual ou automaticamente (monitoramento + API DNS) atualizar seus registros DNS.

Um problema potencial aqui é que você pode se preocupar com bots fazendo solicitações para o endpoint "não ativo". Isso definitivamente acontecerá, mas se seu aplicativo for bem projetado, não interromperá nada ter algumas solicitações chegando ao ponto de extremidade de DR em espera.

O bom é que isso força você a pensar em como tornar sua arquitetura de aplicativo mais robusta em termos de vários endpoints simultâneos recebendo tráfego (compartilhamento de bancos de dados, replicação, etc).

Se for um grande problema você pode adicionar regras do iptables para gerenciar isso...mas então você pode ter o mesmo problema de antes... para que o failover aconteça).

2 - failover do balanceador de carga

É bastante comum ter servidores em espera que não estão ativos em um balanceador de carga e podem ser rapidamente adicionados/trocados no pool de servidores ativos atrás do balanceador de carga.

Nesse caso, o balanceador de carga ou um terceiro componente pode gerenciar as verificações de integridade e atualizar a configuração do balanceador de carga para trocar servidores íntegros por não íntegros.

Isso não funciona tão bem para um caso de DR, pois os balanceadores de carga geralmente são locais de rack ou datacenter. Portanto, para DR, provavelmente é melhor criar um failover baseado em DNS para um data center/região diferente.