

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
<a name="pacemaker-tutorial-setup3"></a>

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](pacemaker-tutorial-prerequisites.md) 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
<a name="pacemaker-tutorial-setup3-ocf-agent"></a>

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

```
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
<a name="pacemaker-tutorial-setup3-attach-resource"></a>

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
<a name="pacemaker-tutorial-setup3-verify-recovery"></a>

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
   ```

1. **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
   ```

1. **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.