View a markdown version of this page

Active/active AWS IoT Greengrass V2 component - AWS IoT Greengrass
Cree un agente de recursos de OCF personalizadoAdjunte el recursoVerifique la recuperación

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Active/active AWS IoT Greengrass V2 component

En esta configuración, se administra un AWS IoT Greengrass V2 componente con Pacemaker mediante un agente de recursos OCF (Open Cluster Framework) personalizado. Esto permite a Pacemaker supervisar el estado de un AWS IoT Greengrass V2 componente y activar acciones de recuperación cuando el componente entra en un estado dañado.

importante

Complete todos los pasos Requisitos previos y configuración del clúster antes de continuar, excepto los pasos de configuración del DRBD. Esta configuración no utiliza DRBD. En AWS IoT Greengrass V2 su lugar, instálelo en una ruta local en cada instancia. AWS IoT Greengrass V2 debe aprovisionarse y ejecutarse en todas las instancias. En este tutorial AWS IoT Greengrass V2 se presupone que está instalado en/greengrass/v2. Si eligió una ruta diferente, actualice la GG_CLI variable en el script OCF en consecuencia.

Cree un agente de recursos de OCF personalizado

Cree el directorio y el script de agentes de recursos personalizados en todas las instancias. En este ejemplo se administra un componente denominadoPythonWebServer.

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

Cree el script del agente de recursos /usr/lib/ocf/resource.d/custom/gg-webserver con el siguiente contenido.

#!/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

Haga que el script sea ejecutable.

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

La start acción reinicia todo el AWS IoT Greengrass V2 servicio, lo que reinicia todos los componentes de la instancia, no solo. PythonWebServer Esta es la única ruta de recuperación práctica porque no AWS IoT Greengrass V2 admite el reinicio de componentes individuales. La stop acción es intencionalmente innecesaria porque este agente es un contenedor de monitoreo: systemd administra el ciclo de vida del AWS IoT Greengrass V2 servicio, no este agente. Si un componente permanece de forma persistente BROKEN (por ejemplo, debido a una mala implementación), Pacemaker lo volverá a intentar migration-threshold varias veces y, a continuación, bloqueará el recurso en ese nodo hasta que caduque. failure-timeout Debe corregir la causa raíz (por ejemplo, volver a implementar una versión de componente válida) para detener el ciclo de reintentos.

Adjunte el recurso

Cree el recurso Pacemaker con el agente OCF personalizado.

sudo pcs property set stonith-enabled=false
aviso

STONITH está deshabilitado aquí para simplificar este tutorial. En un entorno de producción, debe habilitar STONITH y configurar un agente de control (por ejemplo, para las instancias de Amazon EC2) fence_aws para evitar la división de cerebros y la corrupción de los datos.

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 la recuperación

  1. Compruebe el estado inicial. Compruebe que el AWS IoT Greengrass V2 componente esté funcionando y en buen estado en todas las instancias.

    sudo pcs status

  2. Simule el fallo de un componente. Cierre el proceso del componente para simular un fallo transitorio. AWS IoT Greengrass V2 podría intentar primero la recuperación interna. Si el componente entra en un BROKEN estado, Pacemaker lo detecta y desencadena un reinicio del servicio. Si AWS IoT Greengrass V2 recupera el componente internamente, Pacemaker no realiza ninguna acción.

    sudo pkill -f "PythonWebServer"

# Wait 30-60 seconds, then check the component state
sudo /greengrass/v2/bin/greengrass-cli component details -n=PythonWebServer

  3. Compruebe la recuperación. Pacemaker detecta que el componente está en mal estado y lleva a cabo los pasos de recuperación tal y como se definen en el script OCF personalizado. No es necesaria una conmutación por error: Pacemaker reinicia el servicio en la misma instancia.

    Otros servicios, como HAProxy, AWS IoT Greengrass V2 siguen funcionando con normalidad en todas las instancias. La aplicación de las instancias en espera sigue recibiendo solicitudes sin interrupción.

    sudo pcs status

    Cuando la instancia recuperada vuelve a funcionar, el balanceador de cargas la identifica y distribuye las solicitudes de los clientes según sea necesario.