Global Accelerator:Preguntas frecuentes sobre Global Accelerator

¿Cuáles son los principales casos de uso de GA?

GA permite acelerar el acceso a sistemas de automatización de oficina (OA), aplicaciones de internet y servidores de juegos. Para obtener más información, consulte Scenarios.

¿GA puede acelerar el acceso a servicios de backend desplegados en otra cuenta de Alibaba Cloud?

No de forma directa.

¿Los clientes pueden usar directamente el CNAME de una instancia de GA para acceder a los servicios de backend?

No.

El CNAME de GA solo sirve para identificar el servidor de origen del servicio de backend y no cuenta con un registro ICP. Los clientes no pueden usar el CNAME de GA para acelerar directamente el acceso al servicio de backend.

Si desea usar el CNAME de GA para acelerar el acceso a un servicio de backend, agregue un registro CNAME en su plataforma de DNS. De esta manera, asignará el nombre de dominio del servicio de backend al CNAME de GA. Para obtener más información, consulte Accelerate access to backend services that are associated with a specific domain name.

¿El CNAME de una instancia de GA es compatible con la resolución de DNS específica por región?

Sí.

Configure un registro CNAME en su plataforma de DNS para asignar el nombre de dominio al CNAME de GA. Cuando un cliente accede al servicio de backend mediante el nombre de dominio, GA resuelve automáticamente el nombre de dominio a la dirección IP acelerada correspondiente a la región del cliente.

¿Cómo se asignan las direcciones IP aceleradas de GA y cómo deben conectarse los clientes?

Si selecciona Elastic IP Address (EIP) como tipo de dirección IP acelerada, GA asigna las direcciones IP aceleradas por separado para cada región de aceleración. Cada región utiliza direcciones IP distintas. Se recomienda agregar un registro CNAME para el nombre de dominio de su negocio y apuntarlo al CNAME proporcionado por GA. Esto permite que GA enrute el tráfico mediante DNS y reduce el esfuerzo necesario para mantener las direcciones IP de cada región. También puede usar registros A para conectarse a GA, pero deberá mantener estos registros y gestionar el failover por su cuenta. El uso de un CNAME no garantiza que los cambios de configuración no afecten el acceso. Las cachés de DNS, los valores de tiempo de vida (TTL) y las conexiones existentes pueden influir en la forma en que surten efecto los cambios.

Si su aplicación requiere un conjunto común de direcciones IP a nivel mundial y acceso automático a través de puntos de acceso cercanos, seleccione Anycast Elastic IP Address (Anycast EIP) como tipo de dirección IP acelerada. GA proporciona dos Anycast EIP y no es necesario configurar regiones de aceleración. Actualmente, los puntos de acceso en China continental no son compatibles. Los clientes en China continental se conectan a través de China (Hong Kong). Si los clientes necesitan codificar de forma fija las direcciones IP o configurar listas de permitidos de IP, compruebe si las direcciones IP relevantes se conservarán y evalúe el impacto antes de modificar la configuración de la instancia o de la región de aceleración.

¿Cuánto tiempo tardan en surtir efecto los cambios de registros DNS en GA?

Cuando un endpoint utiliza un nombre de dominio personalizado, el tiempo que tardan en surtir efecto los cambios de registros DNS depende de los siguientes dos factores:

• Duración de la caché del servidor DNS: corresponde al TTL configurado para el registro DNS.

• Duración de la caché de GA: de forma predeterminada, GA recupera los registros DNS cada 15 segundos.

¿GA admite el procesamiento de paquetes TCP y UDP fragmentados?

No.

¿Puedo usar ICMP ping o TCPing para probar el rendimiento de aceleración de un listener UDP o TCP?

No.

¿Cuántas instancias de GA puedo crear con una sola cuenta de Alibaba Cloud?

De forma predeterminada, puede crear hasta 10 instancias estándar de GA. En la página Quota Management, request a quota increase.

Las instancias básicas de GA no tienen ninguna cuota establecida.

¿Puedo usar GA si mi cliente no tiene acceso a internet?

No.

Para conectarse a GA, los clientes deben tener acceso a internet.

¿Cuál es el ancho de banda mínimo que puedo asignar a una sola región de aceleración de GA?

• Si el tipo de dirección IP acelerada es Elastic IP Address: 2 Mbps.

• Si el tipo de dirección IP acelerada es Anycast Elastic IP Address: 200 Mbps.

¿GA cuenta con un mecanismo de caché?

No.

¿Por qué los clientes no pueden acceder a los servicios de backend después de configurar una instancia básica de GA?

• La ACL de red o el security group de la virtual private cloud (VPC) que aloja el recurso de backend del endpoint contiene reglas de bloqueo. Para obtener más información sobre cómo configurar las reglas de ACL de red y de security group, consulte Create and manage a network ACL o Modify security group rules.

• En la VPC que aloja el recurso de backend del endpoint, hay o hubo una puerta de enlace IPv4 activa. Debe agregar una ruta que apunte a la puerta de enlace IPv4 en la tabla de rutas de la VPC. Para obtener más información, consulte Create and manage an IPv4 gateway.

• El servicio de backend del endpoint utiliza una dirección IP privada secundaria de una instancia de ECS o de una interfaz de red elástica (ENI), pero el sistema operativo no se ha configurado para usar dicha dirección.

  • Para conocer cómo consultar las configuraciones de ENI, consulte Configure an operating system to recognize the IP addresses of a secondary ENI.

  • Para conocer cómo configurar una dirección IP privada secundaria para una ENI, consulte Assign secondary private IP addresses.

¿Cómo compruebo que la función de traducción IPv6 de GA funciona correctamente?

¿Por qué la función de traducción IPv6 de GA no surte efecto?

¿Por qué los clientes no pueden acceder a los servicios del backend después de configurar una instancia estándar de GA?

¿Cómo soluciono los errores 502 después de configurar GA?

Si las solicitudes devuelven un error HTTP 502 después de configurar GA, identifique primero la ruta de la solicitud y el origen del error. Luego, revise la configuración de conexión del backend y los servicios:

1. Identifique la ruta de la solicitud y el origen del error: consulte los resultados de la resolución DNS de su dominio comercial para comprobar que las solicitudes pasan por la instancia de GA prevista. Se recomienda el acceso basado en CNAME, aunque también se admiten registros A que apunten a direcciones IP aceleradas de GA. Compare los registros de GA, del servidor de origen y de la aplicación para identificar qué componente generó la respuesta 502. Un listener TCP solo reenvía tráfico y no genera respuestas HTTP 502.

2. Revise el estado de salud y los registros del backend: si las comprobaciones de estado están habilitadas, consulte el estado de los endpoints y verifique su configuración. Una comprobación de estado exitosa no garantiza que todas las solicitudes de la aplicación tengan éxito. Compruebe que el backend se esté ejecutando y busque cierres inesperados de conexión o respuestas no válidas.

3. Distinga los fallos de TLS del frontend de los fallos de conexión del backend: los errores de validación de certificados o de enlace TLS entre el cliente y GA suelen manifestarse como errores de conexión. Si el cliente recibió un error HTTP 502 a través de HTTPS, revise primero la conexión de GA al servicio del backend. Si GA utiliza HTTPS para conectarse al backend, compruebe la compatibilidad del protocolo TLS, la configuración del certificado y los resultados del enlace TLS en el backend.

4. Revise el protocolo del backend, los puertos y las directivas de seguridad: compruebe la dirección del endpoint, el protocolo del backend, el puerto de servicio y la asignación de puertos. En un listener HTTPS, el protocolo utilizado entre el cliente y GA puede diferir del que se usa entre GA y el backend. Configure el protocolo del backend según los protocolos que el servicio realmente admita. Revise los grupos de seguridad, los firewalls y los controles de acceso correspondientes al tipo de conexión pública o privada aplicable.

5. Utilice herramientas de diagnóstico: consulte los resultados de diagnóstico de la instancia. Si la instancia cumple los requisitos para sondear el origen, incluidas las especificaciones compatibles y los protocolos del listener, cree una tarea de sondeo de origen para ayudar a localizar el problema.

¿GA ajusta automáticamente el ancho de banda de acceso del cliente y el ancho de banda de la red interna de Alibaba Cloud durante los picos de tráfico?

El ajuste automático del ancho de banda de acceso del cliente y de transmisión depende del método de facturación de la instancia de GA:

• pay-as-you-go: el ancho de banda se escala automáticamente según el tráfico, hasta alcanzar el pico de ancho de banda del área de aceleración.

• subscription: no admite escalado automático. El ancho de banda está limitado por el plan de ancho de banda básico y por la capacidad máxima de ancho de banda de la especificación de la instancia de GA.

¿Cómo soluciono la pérdida de paquetes en redes transfronterizas?

Si los clientes experimentan pérdida de paquetes o errores de acceso al conectarse a una instancia de Alibaba Cloud ECS a través de fronteras, utilice MTR o PathPing para recopilar evidencia de red. Después, correlaciónela con las solicitudes de la aplicación y las capturas de paquetes:

1. Recopile los resultados del sondeo desde el cliente

   Ejecute a continuación los comandos en el cliente. Sustituya el marcador de posición por la dirección IP pública real de la instancia ECS, sin incluir los corchetes angulares:

   • Linux: mtr -rwc 100 <ECS-public-IP>

   • Windows: pathping -n -q 100 <ECS-public-IP>

   En MTR, -r habilita el modo de informe, -w activa los informes amplios para evitar que se trunquen los nombres de host y -c 100 ejecuta 100 ciclos de sondeo. En PathPing, -n deshabilita la resolución de nombres de host y -q 100 envía 100 consultas a cada router de la ruta. Repita las pruebas durante el incidente y conserve los resultados de los periodos estables para compararlos.

   MTR usa ICMP de forma predeterminada, por lo que la pérdida de sondeos ICMP no necesariamente indica pérdida de paquetes en la aplicación. Para sondear el puerto real de la aplicación mediante TCP, use un comando como mtr -rwc 100 -T -P 443 <ECS-public-IP>. Los saltos intermedios en modo TCP suelen depender de respuestas ICMP Time Exceeded. El MTR por TCP no valida los intercambios TLS ni las solicitudes HTTP, así que pruebe también las solicitudes reales de la aplicación.

2. Interprete la salida de MTR para identificar las áreas que debe investigar

   • Loss%: porcentaje de pérdida de sondeos en el salto.

   • Snt: número de sondeos enviados al salto.

   • Last: último tiempo de ida y vuelta (ms).

   • Avg: tiempo promedio de ida y vuelta (ms).

   • Best: tiempo mínimo de ida y vuelta (ms).

   • Wrst: tiempo máximo de ida y vuelta (ms).

   Compruebe si la pérdida persiste en los saltos posteriores hasta el destino. Una pérdida alta o del 100 % en un salto intermedio, seguida de saltos posteriores y un destino estables, suele indicar que faltan respuestas de sondeo, que están filtradas o que tienen límites de velocidad. Esto no confirma la pérdida de paquetes de la aplicación en ese salto. Si la pérdida comienza en un salto y continúa hasta el destino, se identifica un área para investigar; sin embargo, MTR por sí solo no determina el dispositivo exacto ni la dirección de la pérdida de paquetes.

3. Recopile los resultados en dirección inversa desde la instancia ECS

   Rastree la ruta desde la instancia ECS hasta la dirección IP pública del cliente: mtr -r -c 100 <client-public-IP>.

   Las pruebas desde ambos extremos ayudan a investigar las diferencias de ruta, pero los distintos números de saltos con pérdida no demuestran que el tráfico atraviese enlaces internacionales diferentes. Las estadísticas de sondeo dependen tanto de los sondeos salientes como de sus rutas de respuesta. Correlacione las rutas en ambas direcciones con las capturas de paquetes y el comportamiento de la aplicación.

   NAT o los firewalls pueden restringir los sondeos inversos, por lo que un salto final sin respuesta no necesariamente indica pérdida de paquetes en la aplicación. Los sondeos TCP requieren un servicio accesible del lado del cliente y cualquier asignación NAT necesaria. Repetir una prueba directa aporta evidencia adicional, pero no sustituye a una prueba inversa.

4. Correlacione otra evidencia para localizar el problema

   Analice en conjunto las tasas de error de las solicitudes de la aplicación, las retransmisiones TCP, las capturas de paquetes de ambos extremos, los datos del número de sistema autónomo (ASN) y la información del ISP para identificar la parte afectada de la red. whois y la geolocalización de IP proporcionan pistas complementarias, aunque no determinan por sí solos la ubicación de los routers ni la congestión en una puerta de enlace internacional.

5. Evalúe la aceleración transfronteriza

   Si la evidencia apunta a la calidad de la red pública transfronteriza, evalúe Global Accelerator (GA) y compare las tasas de éxito de la aplicación, la latencia y la pérdida de paquetes antes y después de su adopción. Antes de usar una línea dedicada transfronteriza de China Unicom, compruebe la elegibilidad de la instancia y la región, y complete los procedimientos de calificación y cumplimiento obligatorios.

¿Cómo soluciono los tiempos de espera o los restablecimientos de conexión que afectan a ISP específicos en China continental?

Si los clientes que usan ISP específicos o que se ubican en regiones particulares de China continental experimentan tiempos de espera o restablecimientos de conexión al acceder a servicios acelerados por GA, registre la hora, la región y el ISP del cliente, el dominio empresarial, la dirección IP acelerada de destino, el puerto y el mensaje de error. Distinga entre errores de DNS, tiempos de espera de conexión, errores de intercambio TLS y restablecimientos TCP. Los errores que afectan a un ISP, una región o una dirección IP acelerada en particular no demuestran por sí solos que una directiva del ISP sea la responsable.

Utilice herramientas de sondeo de red para comparar los resultados de acceso entre regiones, ISP y direcciones IP aceleradas. Mantenga constantes el dominio empresarial, el protocolo, el puerto y la ruta de solicitud. Para HTTPS, use el nombre de dominio empresarial en el encabezado Host y en Server Name Indication (SNI); utilizar una dirección IP como nombre de host de la URL puede generar diferencias de certificado o de enrutamiento. Compruebe el DNS, los listeners, los controles de acceso, el estado del backend, las directivas de seguridad tanto en el cliente como en el servidor de origen, y las capturas de paquetes o registros para identificar la etapa del error. Si los errores persisten para un ISP o una dirección IP acelerada específica, proporcione al equipo de soporte técnico de Alibaba Cloud los resultados de las pruebas exitosas y con errores, las marcas de tiempo y las capturas de paquetes. Coordínese con el ISP si es necesario. Para consultar las instrucciones de sondeo, consulte Test the acceleration performance of GA.