View a markdown version of this page

Active/active AWS IoT Greengrass V2 componente - AWS IoT Greengrass

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Active/active AWS IoT Greengrass V2 componente

Nessa configuração, você gerencia um AWS IoT Greengrass V2 componente com o Pacemaker usando um agente de recursos OCF (Open Cluster Framework) personalizado. Isso permite que o Pacemaker monitore a integridade de um AWS IoT Greengrass V2 componente e acione ações de recuperação quando o componente entra em um estado quebrado.

Importante

Conclua todas as etapas Pré-requisitos e configuração do cluster antes de continuar, exceto as etapas de configuração do DRBD. Essa configuração não usa DRBD. Em vez disso, instale AWS IoT Greengrass V2 em um caminho local em cada instância. AWS IoT Greengrass V2 devem ser provisionados e executados em todas as instâncias. Este tutorial pressupõe que AWS IoT Greengrass V2 esteja instalado em/greengrass/v2. Se você escolheu um caminho diferente, atualize a GG_CLI variável no script OCF adequadamente.

Crie um agente de recursos OCF personalizado

Crie o diretório e o script personalizados do agente de recursos em todas as instâncias. Este exemplo gerencia um componente chamadoPythonWebServer.

sudo mkdir -p /usr/lib/ocf/resource.d/custom

Crie o script do agente de recursos em /usr/lib/ocf/resource.d/custom/gg-webserver com o conteúdo a seguir.

#!/bin/bash # OCF Resource Agent for Greengrass Web Server component . /usr/lib/ocf/lib/heartbeat/ocf-shellfuncs GG_CLI="/greengrass/v2/bin/greengrass-cli" COMPONENT="PythonWebServer" STATE_FILE="/run/gg-webserver.ocf-state" case "$1" in meta-data) cat <<EOF <?xml version="1.0"?> <resource-agent name="gg-webserver"> <version>1.0</version> <longdesc lang="en">Greengrass webserver component agent</longdesc> <shortdesc lang="en">GG Webserver</shortdesc> <parameters> </parameters> <actions> <action name="start" timeout="60"/> <action name="stop" timeout="10"/> <action name="monitor" timeout="5" interval="10"/> <action name="meta-data" timeout="5"/> </actions> </resource-agent> EOF ;; start) touch "$STATE_FILE" systemctl restart greengrass if [ $? -eq 0 ]; then exit $OCF_SUCCESS else rm -f "$STATE_FILE" exit $OCF_ERR_GENERIC fi ;; stop) rm -f "$STATE_FILE" exit $OCF_SUCCESS ;; monitor) # Check state file first — if absent, resource is stopped [ ! -f "$STATE_FILE" ] && exit $OCF_NOT_RUNNING # Check if the Greengrass service is running if ! systemctl is-active --quiet greengrass; then exit $OCF_NOT_RUNNING fi STATE=$($GG_CLI component details -n=$COMPONENT 2>/dev/null | grep '^[[:space:]]*State:' | awk '{print $2}') if [[ -z "$STATE" ]]; then ocf_log warn "Component $COMPONENT state is empty — component may not be deployed" exit $OCF_SUCCESS elif [[ "$STATE" == "BROKEN" ]]; then exit $OCF_ERR_GENERIC else exit $OCF_SUCCESS fi ;; *) echo "Usage: $0 {start|stop|monitor|meta-data}" exit $OCF_ERR_UNIMPLEMENTED ;; esac

Torne o script executável.

sudo chmod +x /usr/lib/ocf/resource.d/custom/gg-webserver
nota

A start ação reinicia todo o AWS IoT Greengrass V2 serviço, que reinicia todos os componentes na instância, não apenas. PythonWebServer Esse é o único caminho prático de recuperação porque AWS IoT Greengrass V2 não suporta a reinicialização de componentes individuais. A stop ação é intencionalmente autônoma porque esse agente é um invólucro de monitoramento — o ciclo de vida do AWS IoT Greengrass V2 serviço é gerenciado pelo systemd, não por esse agente. Se um componente permanecer persistentemente BROKEN (por exemplo, devido a uma implantação incorreta), o Pacemaker tentará novamente migration-threshold várias vezes e, em seguida, banirá o recurso nesse nó até que expire. failure-timeout Você deve corrigir a causa raiz (por exemplo, reimplantar uma versão válida do componente) para interromper o ciclo de repetição.

Anexar o recurso

Crie o recurso Pacemaker usando o agente OCF personalizado.

sudo pcs property set stonith-enabled=false
Atenção

O STONITH está desativado aqui para simplificar este tutorial. Em um ambiente de produção, você deve habilitar o STONITH e configurar um agente de esgrima (por exemplo, para instâncias do Amazon fence_aws EC2) para evitar a divisão cerebral e a corrupção de dados.

sudo pcs resource create gg-webserver ocf:custom:gg-webserver \ op monitor interval=30s \ op start timeout=60s \ meta migration-threshold=3 failure-timeout=60s \ clone

Verifique a recuperação

  1. Verifique o estado inicial. Verifique se o AWS IoT Greengrass V2 componente está funcionando e funcionando em todas as instâncias.

    sudo pcs status
  2. Simule a falha do componente. Elimine o processo do componente para simular uma falha transitória. AWS IoT Greengrass V2 pode tentar a recuperação interna primeiro. Se o componente entrar em um BROKEN estado, o Pacemaker o detectará e acionará a reinicialização do serviço. Se AWS IoT Greengrass V2 recuperar o componente internamente, o Pacemaker não tomará nenhuma ação.

    sudo pkill -f "PythonWebServer" # Wait 30-60 seconds, then check the component state sudo /greengrass/v2/bin/greengrass-cli component details -n=PythonWebServer
  3. Verifique a recuperação. O Pacemaker detecta que o componente não está íntegro e executa as etapas de recuperação conforme definido no script OCF personalizado. Nenhum failover é necessário — o Pacemaker reinicia o serviço na mesma instância.

    Outros serviços, como o HAProxy, AWS IoT Greengrass V2 continuam operando normalmente em todas as instâncias. O aplicativo nas instâncias em espera continua recebendo solicitações sem interrupção.

    sudo pcs status

    Quando a instância recuperada volta a funcionar, o balanceador de carga a identifica e distribui as solicitações do cliente conforme necessário.