Configura la verificación activa del estado para la conmutación por error regional con PSC

Esta página se aplica a Apigee, pero no a Apigee Hybrid.

Consulta la documentación de Apigee Edge.

En este documento, se explica cómo configurar Apigee a fin de configurar la verificación activa del estado para los casos en los que desees usar Private Service Connect (PSC) para el enrutamiento de red ascendente (el tráfico de clientes a Apigee). La verificación activa del estado es útil para evitar la pérdida de tráfico de red en caso de una falla regional.

Descripción general

Si planeas usar PSC para el enrutamiento de red ascendente del Apigee, sigue las instrucciones de este documento a fin de configurar la verificación activa del estado. En este momento, PSC no admite la supervisión activa de las verificaciones de estado. Para solucionar esta limitación de PSC, puedes modificar la configuración de instalación de Apigee a fin de usar un grupo de instancias administrado (MIG), que proporciona capacidad de verificación de estado activa.

Podrías usar la detección de valores atípicos para la supervisión del estado. Sin embargo, durante las fallas regionales, es posible que pierdas parte del tráfico de forma periódica, ya que la detección de valores atípicos usa el tráfico en tiempo real como indicadores. La detección de valores atípicos redirecciona parte del tráfico en vivo de forma periódica para verificar el estado de la región con errores.

En la Figura 1, se muestra la arquitectura propuesta. Un extremo de servicio se conecta al adjunto de servicio de la instancia de Apigee y un MIG envía el tráfico al extremo de servicio. Habilitas la supervisión de la verificación de estado en el MIG.

Figura 1. Arquitectura de Apigee para una verificación activa del estado sin intercambio de tráfico de VPC.

Enfoque de verificación de estado basado en MIG

Requisitos previos

Puedes aplicar la técnica descrita en este documento a las instalaciones de Apigee que usan el intercambio de tráfico entre VPC o que no lo usan. Pero en el caso de una instalación de intercambio de tráfico entre VPC, la técnica de verificación aciva activa del estado que se describe aquí solo se aplica si usas PSC para la configuración de enrutamiento.

Antes de realizar los pasos de esta sección, haz lo siguiente:

• Para instalaciones que no son de intercambio de tráfico entre VPC, haz lo siguiente:
  1. Completa los pasos del 1 al 6 del aprovisionamiento de Apigee para instalaciones basadas en suscripciones o de pago por uso. En este momento, la única opción es seguir estos pasos con la interfaz de línea de comandos.
  2. Omite el paso 7: Configura el enrutamiento y realiza los siguientes pasos.
• Para instalaciones de intercambio de tráfico entre VPC que usan PSC para el enrutamiento, haz lo siguiente:
  1. Completa los pasos del 1 al 7 del aprovisionamiento de Apigee para instalaciones basadas en suscripciones o de pago por uso. En este momento, la única opción es seguir estos pasos con la interfaz de línea de comandos.
  2. Omite el paso 8: Configura el enrutamiento y realiza los siguientes pasos.

1. Configura un extremo de servicio de PSC para el adjunto del servicio de Apigee

En este paso, debes crear un extremo del servicio PSC que apunte al adjunto de servicio en la instancia de Apigee:

1. Obtén el adjunto de servicio de la instancia de Apigee que creaste antes:

   curl -i -X GET -H "Authorization: Bearer $AUTH" \
     "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances"

   En el siguiente resultado de muestra, el valor serviceAttachment se muestra con letra negrita:

   {
     "instances": [
       {
         "name": "us-west1",
         "location": "us-west1",
         "host": "10.82.192.2",
         "port": "443",
         "createdAt": "1645731488019",
         "lastModifiedAt": "1646504754219",
         "diskEncryptionKeyName": "projects/my-project/locations/us-west1/keyRings/us-west1/cryptoKeys/dek",
         "state": "ACTIVE",
         "peeringCidrRange": "SLASH_22",
         "runtimeVersion": "1-7-0-20220228-190814",
         "ipRange": "10.82.192.0/22,10.82.196.0/28",
         "consumerAcceptList": [
           "875609189304"
         ],
         "serviceAttachment": "projects/bfac74a67a320c43a12p-tp/regions/us-west1/serviceAttachments/apigee-us-west1-crw1"
       }
     ]
   }

   Nota: El ID del proyecto que usaste para crear tu organización de Apigee siempre aparece en la lista consumerAcceptList En el resultado de ejemplo anterior, es el único proyecto en la lista.
2. Crea un extremo de servicio de PSC que apunte al adjunto de servicio que obtuviste del cuerpo de la respuesta de la instancia en el paso anterior, como se explica en Crea un extremo de Private Service Connect.

2. Configura un MIG que apunte al extremo del servicio

En este paso, debes crear un MIG que actúe como proxy para el tráfico al extremo del servicio. Luego, puedes habilitar la verificación activa del estado en el MIG.

Permisos necesarios para esta tarea

Puedes otorgar al aprovisionador de Apigee un rol predefinido que incluya los permisos necesarios para completar esta tarea, o bien otorgar permisos más detallados a fin de proporcionar el privilegio mínimo necesario. Consulta Roles predefinidos y Permisos de enrutamiento de acceso.

Nota: Los MIG no son globales, son regionales. Por lo tanto, en el caso de varias regiones, debes crear un MIG para cada región y agregarlos al servicio de backend del balanceador de cargas global.

2A. Habilita el Acceso privado a Google para una subred de tu red de VPC

Si quieres habilitar el Acceso privado a Google para una subred de tu red de VPC, sigue los pasos que se indican en Habilita el Acceso privado a Google.

Nota: Si realizas una configuración multirregional, debes realizar este paso una vez para cada región.

2B. Configure las variables de entorno

Multirregión: Una configuración multirregional requiere un MIG separado para cada región.

En las instrucciones de esta sección, se usan variables de entorno para hacer referencia a strings que se usan de forma repetida. Te recomendamos que configures lo siguiente antes de continuar:

MIG_NAME=YOUR_MIG_NAME  # A name you provide for the MIG
VPC_NAME=default       # If you are using a shared VPC, use the shared VPC name
VPC_SUBNET=default     # Private Google Access must be enabled for this subnet
REGION=RUNTIME_REGION        # The same region as your Apigee runtime instance
SERVICE_ENDPOINT_IP=YOUR_SERVICE_ENDPOINT_IP.  ## The endpoint IP of the service endpoint you just created

Deberá usar estas variables muchas veces durante los procesos restantes. Si deseas configurar varias regiones, crea variables con valores específicos para cada región.

2C. Crea un grupo de instancias administrado

Multirregión: Una configuración multirregional requiere un MIG separado para cada región. Si quieres configurar varias regiones, repite los pasos 2b y 2c para cada región y sustituye las variables adecuadas para cada región.

En este paso, crearás y configurarás un grupo de instancias administrado (MIG).

1. Crea una plantilla de instancias mediante la ejecución del siguiente comando.

   gcloud compute instance-templates create $MIG_NAME \
   --project $PROJECT_ID \
   --region $REGION \
   --network $VPC_NAME \
   --subnet $VPC_SUBNET \
   --tags=https-server,apigee-mig-proxy,gke-apigee-proxy \
   --machine-type e2-medium --image-family debian-12 \
   --image-project debian-cloud --boot-disk-size 20GB \
   --no-address \
   --metadata ENDPOINT=$SERVICE_ENDPOINT_IP,startup-script-url=gs://apigee-5g-saas/apigee-envoy-proxy-release/latest/conf/startup-script.sh

   Como se puede ver en este comando, las máquinas son del tipo e2-medium. Ejecutan Debian 12 y tienen 20 GB de disco. La secuencia de comandos startup-script.sh configura el MIG para enrutar el tráfico entrante desde el balanceador de cargas hasta la instancia de Apigee.

2. Para crear un grupo de instancias administrado, ejecuta el siguiente comando:

   gcloud compute instance-groups managed create $MIG_NAME \
   --project $PROJECT_ID --base-instance-name apigee-mig \
   --size 2 --template $MIG_NAME --region $REGION

3. Configura el ajuste de escala automático para el grupo mediante la ejecución del siguiente comando:
   Nota: Un MIG regional con instancias e2-medium puede admitir un máximo de 6 Gbps. Si eso no es suficiente para tus necesidades de capacidad de procesamiento, considera aumentar el tamaño de la VM o la cantidad de réplicas.

   gcloud compute instance-groups managed set-autoscaling $MIG_NAME \
   --project $PROJECT_ID --region $REGION --max-num-replicas 3 \
   --target-cpu-utilization 0.75 --cool-down-period 90

4. Define un puerto con nombre mediante la ejecución del siguiente comando:

   gcloud compute instance-groups managed set-named-ports $MIG_NAME \
   --project $PROJECT_ID --region $REGION --named-ports https:443

3. Configura el balanceador de cargas con la supervisión de verificación de estado

En los siguientes pasos, configurarás un balanceador de cargas con la supervisión de verificación de estado.

3A. Crea un certificado y una clave SSL para el balanceador de cargas

Solo debes crear las credenciales una vez, ya sea que instales en una o varias regiones. En un paso posterior, asociarás estas credenciales con el proxy HTTPS de destino del balanceador de cargas.

Puedes crear las credenciales de la siguiente manera:

• Tu propio certificado de una autoridad certificada
• Un certificado SSL administrado por Google
• Un certificado autofirmado (no se recomienda para la producción)

Si deseas obtener más información sobre la creación y el uso de certificados SSL para el balanceador de cargas de Google Cloud, consulta Certificados SSL y Descripción general del certificado SSL.

En el siguiente ejemplo, se crea un certificado SSL administrado por Google:

1. Crea estas variables de entorno:

   CERTIFICATE_NAME=YOUR_CERT_NAME
   DOMAIN_HOSTNAME=YOUR_DOMAIN_HOSTNAME 

   Establece DOMAIN_HOSTNAME en un nombre de host de dominio válido que hayas registrado. En un paso posterior, obtendrás la dirección IP del balanceador de cargas y actualizarás el registro A del dominio para que apunte a esa dirección. Por ejemplo, el nombre de host del dominio podría tener el siguiente aspecto: foo.example.com.

2. Ejecuta el comando gcloud compute ssl-certificates create:

   gcloud compute ssl-certificates create $CERTIFICATE_NAME \
   --domains=$DOMAIN_HOSTNAME \
   --project $PROJECT_ID \
   --global

   El certificado puede tardar hasta una hora en aprovisionarse. Para verificar el estado del aprovisionamiento, ejecuta este comando:

   gcloud compute ssl-certificates describe $CERTIFICATE_NAME \
   --global \
   --format="get(name,managed.status, managed.Status)"

   Nota: Puedes crear varios registros A de DNS para tus nombres de host del grupo de entornos que apuntan a la misma dirección IP del balanceador de cargas.

3B. Crear una verificación de estado

1. Cree una verificación de estado.

   gcloud compute health-checks create https HEALTH_CHECK_NAME \
   --project $PROJECT_ID --port 443 --global \
   --request-path /healthz/ingress

   Usarás esta verificación de estado para garantizar que el servicio de backend se esté ejecutando. Para configurar verificaciones de estado más avanzadas en un proxy específico, consulta Realiza verificaciones de estado.

   Nota: Si recibes el siguiente error mientras intentas crear una verificación de estado, haz lo siguiente:

   ERROR: unrecognized arguments: --global,

   Intenta actualizar gcloud mediante el comando gcloud components update.

2. Crea un servicio de backend:

   gcloud compute backend-services create PROXY_BACKEND_NAME \
   --project $PROJECT_ID \
   --protocol HTTPS \
   --health-checks HEALTH_CHECK_NAME \
   --port-name https \
   --timeout 302s \
   --connection-draining-timeout 300s \
   --global

   Note: Como se documenta en la referencia de las propiedades de extremos de Apigee, la entrada de Apigee (balanceador de cargas interno) tiene un tiempo de espera predeterminado de 300 segundos. Establecer el tiempo de espera de servicios de backend del balanceador de cargas en 302 segundos permitirá que el comando de servicios de backend se complete por completo dentro de Apigee en caso de que haya transacciones de larga duración. Establecer este valor en un valor menor, como 60 segundos, puede hacer que el balanceador de cargas agote el tiempo de espera antes de que se complete la solicitud, lo que genera 502 respuestas.
3. Agrega el MIG a tu servicio de backend con el siguiente comando:
   Multirregión: A fin de obtener una configuración multirregional, debes crear un MIG independiente para cada uno, luego repite este paso para agregar cada MIG al servicio de backend. Asegúrate de sustituir las variables REGION y MIG_NAME apropiadas para cada región.

   gcloud compute backend-services add-backend PROXY_BACKEND_NAME \
   --project $PROJECT_ID --instance-group $MIG_NAME \
   --instance-group-region $REGION \
   --balancing-mode UTILIZATION --max-utilization 0.8 --global

4. Crea un mapa de URL de balanceo de cargas con el siguiente comando:

   gcloud compute url-maps create MIG_PROXY_MAP_NAME \
   --project $PROJECT_ID --default-service PROXY_BACKEND_NAME

5. Crea un proxy HTTPS de destino de balanceo de cargas con el siguiente comando:

   gcloud compute target-https-proxies create MIG_HTTPS_PROXY_NAME \
   --project $PROJECT_ID --url-map MIG_PROXY_MAP_NAME \
   --ssl-certificates $CERTIFICATE_NAME

3C. Obtén una dirección IP reservada y crea reglas de firewall

Debes asignar una dirección IP al balanceador de cargas y, luego, crear reglas que permitan al balanceador de cargas acceder al MIG. Solo debes realizar este paso una vez, ya sea que instales en una o varias regiones.

1. Reserva una dirección IP para el balanceador de cargas:

   gcloud compute addresses create ADDRESSES_NAME \
   --project $PROJECT_ID \
   --ip-version=IPV4 \
   --global

2. Crea una regla de reenvío global con el siguiente comando:

   gcloud compute forwarding-rules create FORWARDING_RULE_NAME \
   --project $PROJECT_ID --address ADDRESSES_NAME --global \
   --target-https-proxy MIG_HTTPS_PROXY_NAME --ports 443

3. Obtén una dirección IP reservada mediante la ejecución del siguiente comando:

   gcloud compute addresses describe ADDRESSES_NAME \
   --project $PROJECT_ID --format="get(address)" --global

4. Paso importante: Ve al sitio, host de DNS o ISP donde se administran tus registros DNS y asegúrate de que el registro DNS de tu dominio se resuelva en la dirección IP del balanceador de cargas de Google Cloud. Esta dirección es el valor de IP que se muestra en el último paso. Si deseas obtener más detalles, consulta Actualiza los registros A y AAAA de DNS para que apunten a la dirección IP del balanceador de cargas.
5. Crea una regla de firewall que permita al balanceador de cargas acceder al MIG con el siguiente comando:

   gcloud compute firewall-rules create FIREWALL_RULE_NAME \
   --description "Allow incoming from GLB on TCP port 443 to Apigee Proxy" \
   --project $PROJECT_ID --network $VPC_NAME --allow=tcp:443 \
   --source-ranges=130.211.0.0/22,35.191.0.0/16 --target-tags=gke-apigee-proxy

   Ten en cuenta que los rangos de direcciones IP 130.211.0.0/22 y 35.191.0.0/16 son los rangos de direcciones IP de origen para el balanceo de cargas de Google. Esta regla de firewall permite a Google Cloud Load Balancing realizar solicitudes de verificación de estado al MIG.

El aprovisionamiento de Apigee se completó. Ve a Implementa un proxy de muestra.