Cette rubrique répond aux questions fréquentes sur Global Accelerator (GA).
Le CNAME d'une instance GA prend-il en charge la résolution DNS spécifique à une région ?
Combien de temps faut-il pour qu'un enregistrement DNS prenne effet dans GA ?
Combien d'instances GA un compte Alibaba Cloud peut-il créer ?
Puis-je utiliser GA si mon client n'a pas accès à Internet ?
Quelle est la bande passante minimale allouable à une seule zone d'accélération ?
Comment tester le bon fonctionnement du service de traduction IPv6 ?
Pourquoi le service de traduction IPv6 ne prend-il pas effet ?
Comment résoudre les problèmes de perte de paquets sur les réseaux transfrontaliers ?
Principaux cas d'utilisation
GA permet d'accélérer l'accès aux systèmes d'automatisation des bureaux (OA), aux applications Internet et aux serveurs de jeux. Pour plus d'informations, consultez la rubrique Scénarios.
Accélération inter-comptes
Non, pas directement.
Si votre service backend est déployé sur Alibaba Cloud via un compte différent de celui utilisé pour activer GA, vous pouvez toujours utiliser GA. Lors de la configuration de GA, tenez compte des points suivants :
Le compte utilisé pour GA doit disposer d'un plan de bande passante d'accélération amélioré ou premium actif.
Lorsque vous configurez le groupe de points de terminaison, spécifiez que le service backend n'est pas déployé sur Alibaba Cloud.
Utilisation d'un CNAME pour l'accélération
Non.
Le CNAME de GA sert uniquement à identifier le serveur d'origine du service backend et ne dispose pas de dépôt ICP. Les clients ne peuvent pas utiliser le CNAME de GA pour accélérer directement l'accès au service backend.
Si vous souhaitez utiliser le CNAME de GA pour accélérer l'accès à un service backend, ajoutez un enregistrement CNAME sur votre plateforme DNS afin de mapper le nom de domaine du service backend au CNAME de GA. Pour plus d'informations, consultez la rubrique Accélérer l'accès aux services backend associés à un nom de domaine spécifique.
Résolution CNAME spécifique à une région
Oui.
Vous pouvez configurer un enregistrement CNAME sur votre plateforme DNS pour mapper le nom de domaine au CNAME de GA. Lorsqu'un client accède au service backend via le nom de domaine, GA résout automatiquement le nom de domaine vers l'adresse IP accélérée correspondant à la région du client.
Stabilité de l'adresse IP accélérée
Nous vous recommandons d'utiliser un CNAME plutôt que d'intégrer en dur les adresses IP accélérées. Lorsque vous utilisez le type Elastic IP Address (EIP), GA attribue une adresse IP accélérée distincte à chaque région d'accélération ; l'adresse IP varie donc selon les régions. Lorsque des clients situés dans différentes régions accèdent au domaine d'accélération, le CNAME est automatiquement résolu par le DNS intelligent vers l'adresse IP accélérée de la région d'accélération correspondante. Ainsi, vous n'avez pas besoin de maintenir manuellement une liste d'adresses IP et vous n'êtes pas affecté par les changements d'adresse IP liés à l'ajout ou à la suppression ultérieure de régions d'accélération.
Si votre activité nécessite de fournir une adresse IP fixe pour l'accès externe, sélectionnez le type Anycast EIP lors de la création de l'instance. GA fournit alors deux adresses IP publiques fixes à l'échelle mondiale. Notez que l'Anycast EIP ne prend actuellement pas en charge les points d'accès en Chine continentale (les clients en Chine continentale accèdent à GA via Hong Kong (Chine)) et ne prend pas en charge les régions d'accélération personnalisées.
Délai de propagation DNS
Si le service backend d'un point de terminaison est un nom de domaine personnalisé, le délai de propagation DNS dépend des facteurs suivants :
La durée de mise en cache de l'enregistrement DNS sur un serveur DNS. Il s'agit de la valeur TTL (Time-To-Live) que vous pouvez spécifier lors de la configuration de l'enregistrement DNS.
La durée de mise en cache de l'enregistrement DNS dans Global Accelerator. Par défaut, Global Accelerator actualise son cache DNS toutes les 15 secondes.
Traitement des fragments TCP et UDP
Non.
Tests de performance avec Ping ou TCPing
Non.
GA prend en charge le mécanisme de réponse proxy. Les requêtes ICMP Ping et TCPing reçoivent une réponse et sont fermées dans la région d'accélération ; elles ne sont pas transmises aux serveurs backend. ICMP Ping et TCPing permettent de tester la connectivité réseau entre le client et la région d'accélération, mais ne peuvent pas servir à mesurer la latence.
Pour savoir comment tester les performances d'accélération, consultez la rubrique Tester les performances d'accélération d'une instance GA.
Quota d'instances GA
Par défaut, vous pouvez créer jusqu'à 10 instances GA standard. Vous pouvez demander une augmentation de quota sur la page Quota Management.
Aucun quota n'est imposé pour les instances GA basiques.
Accès Internet du client
Non.
Pour se connecter à GA, les clients doivent avoir accès à Internet.
Bande passante minimale par zone d'accélération
Si le type d'adresse IP accélérée est Elastic IP Address : 2 Mbit/s.
Si le type d'adresse IP accélérée est Anycast Elastic IP Address : 200 Mbit/s.
Mécanisme de mise en cache
Non.
Dépannage des instances basiques
La liste de contrôle d'accès réseau (ACL) ou le groupe de sécurité du VPC hébergeant la ressource backend du point de terminaison contient des règles de blocage. Pour plus d'informations sur la configuration des règles d'ACL réseau et de groupe de sécurité, consultez les rubriques Créer et gérer une ACL réseau ou Modifier les règles de groupe de sécurité.
Dans le VPC hébergeant la ressource backend du point de terminaison, une passerelle IPv4 est ou a été active. Vous devez ajouter une route pointant vers la passerelle IPv4 à la table de routage du VPC. Pour plus d'informations, consultez la rubrique Créer et gérer une passerelle IPv4.
-
Le service backend du point de terminaison utilise une adresse IP privée secondaire d'une instance ECS ou d'une interface réseau élastique (ENI), mais le système d'exploitation n'a pas été configuré pour utiliser cette adresse.
Pour savoir comment afficher les configurations ENI, consultez la rubrique Configurer un système d'exploitation pour reconnaître les adresses IP d'une ENI secondaire.
Pour savoir comment configurer une adresse IP privée secondaire pour une ENI, consultez la rubrique Attribuer des adresses IP privées secondaires.
Test du service de traduction IPv6
Si un service web utilise le service de traduction IPv6 de GA, exécutez la commande curl sur un client IPv6 pour accéder au service web IPv4 backend et vérifier que le service de traduction IPv6 fonctionne. Les étapes suivantes décrivent comment effectuer le test :
Cette rubrique utilise Alibaba Cloud Linux 2 à titre d'exemple. Les commandes de test peuvent varier selon le système d'exploitation. Pour plus d'informations, consultez la documentation de votre système d'exploitation.
Dans la zone d'accélération de GA, ouvrez l'interface de ligne de commande (CLI) du client IPv6.
-
Exécutez la commande suivante pour tester si le client IPv6 peut accéder au service web IPv4 backend.
curl -6 -g http://[<Accelerated IP address assigned by GA>]Le résultat du test indique que le client IPv6 peut accéder au service web IPv4 backend via l'adresse IP accélérée.
[root@iZ2xxx ~]# curl -6 -g http://[2408:4xxx2] This is ipv6 access ipv4 web test. [root@iZ2xxx ~]#
Dépannage du service de traduction IPv6
Le service de traduction IPv6 de GA peut échouer pour plusieurs raisons. Vérifiez les points suivants :
-
Vérifiez si la configuration de Global Accelerator est complète.
Une configuration complète doit inclure une zone d'accélération, un écouteur (pour les instances GA standard), un groupe de points de terminaison et un point de terminaison.
-
Vérifiez si le client prend en charge l'accès IPv6 via Internet.
Vous pouvez exécuter la commande ping pour tester l'adresse IP accélérée via IPv6. Si la commande échoue, activez IPv6 sur le client et assurez-vous qu'il dispose d'un accès Internet.
-
Si vous fournissez des services via un nom de domaine, vérifiez si la résolution DNS est configurée pour ce nom de domaine.
Vous pouvez exécuter une commande telle que dig pour vérifier les informations de résolution DNS. Vérifiez si un enregistrement AAAA ou CNAME a été ajouté. Un enregistrement AAAA spécifie une adresse IP accélérée IPv6. Un enregistrement CNAME spécifie un CNAME pour l'accélération. Pour plus d'informations, consultez la rubrique Configurer les paramètres DNS.
-
Si vous ajoutez un enregistrement CNAME pour la résolution DNS, vérifiez si la région du client est incluse dans la zone d'accélération.
Le CNAME d'une instance GA est spécifique à une région et dépend de la configuration de la zone d'accélération. L'accès interrégional peut échouer. Par exemple, si la zone d'accélération n'inclut que des régions en Chine continentale, le CNAME ne peut pas être résolu depuis l'extérieur de la Chine continentale. Nous vous recommandons d'ajouter une zone d'accélération hors de Chine continentale ou de basculer vers un enregistrement AAAA.
-
Vérifiez si des politiques de sécurité ou des pare-feu sont configurés pour votre site web.
Si des politiques de sécurité sont configurées sur votre serveur d'origine, elles doivent autoriser le trafic provenant de l'adresse IP publique utilisée par le point de terminaison pour le trafic origine-destination.
En raison des délais de synchronisation DNS et des mécanismes de détection variables, certains sites web de détection IPv6 tiers peuvent échouer. Dans ce cas, accédez au site web depuis un client IPv6 pour vérifier si IPv6 fonctionne comme prévu.
Dépannage des instances standard
Si votre application ne peut pas se connecter à un service backend via GA après la configuration, vérifiez les points suivants :
-
Vérifiez si le service backend fonctionne correctement.
Accédez directement à votre service backend. Si vous ne pouvez pas y accéder, dépannez le serveur d'origine.
-
Si vous utilisez un enregistrement CNAME pour la résolution DNS, vérifiez si la région du client est ajoutée en tant que zone d'accélération GA.
Le CNAME d'une instance GA est spécifique à une région et dépend de la configuration de la zone d'accélération. L'accès interrégional peut échouer.
Par exemple, si la zone d'accélération n'inclut que des régions hors de Chine continentale (à l'exclusion de Hong Kong (Chine)), l'enregistrement CNAME ne peut pas prendre effet en Chine continentale, ce qui entraîne des échecs d'accès pour les clients situés en Chine continentale. Vous pouvez utiliser l'une des solutions suivantes :
-
Solution 1 : Configurez la résolution DNS intelligente basée sur l'emplacement du client. Résolvez le trafic provenant de l'extérieur de la Chine continentale vers le CNAME GA, et résolvez le trafic provenant de la Chine continentale directement vers le serveur d'origine.
Dans ce cas, le trafic provenant de l'extérieur de la Chine continentale entre dans GA via l'adresse IP accélérée de la zone d'accélération située hors de Chine continentale. Le trafic provenant de la Chine continentale se connecte directement au serveur d'origine, ce qui peut entraîner une latence et une perte de paquets dues aux limitations des FAI et des liaisons internationales.
-
Solution 2 : Ajoutez une zone d'accélération en Chine continentale à l'instance GA et utilisez la ligne DNS par défaut pour résoudre les requêtes vers le CNAME GA.
GA attribue automatiquement une adresse IP accélérée en fonction de la région d'où provient la requête. Le trafic provenant de l'extérieur de la Chine continentale est acheminé vers GA via les adresses IP accélérées des zones d'accélération situées hors de Chine continentale, et le trafic provenant de la Chine continentale est acheminé vers GA via les adresses IP accélérées en Chine continentale.
Remarque : Si la zone d'accélération inclut la Chine continentale et que votre trafic de service est HTTP ou HTTPS, vous devez obtenir un dépôt ICP pour votre nom de domaine. Sinon, l'accélération échouera.
-
-
Vérifiez si le serveur backend dispose de politiques de sécurité.
Vérifiez si le trafic est autorisé depuis l'adresse IP publique origine-destination du point de terminaison. Vous pouvez consulter cette adresse IP dans l'onglet Listener Details. Si votre serveur d'origine est protégé par un dispositif de sécurité tiers, tel qu'un VPN SSL Sangfor ou un pare-feu, vous devez ajouter l'adresse IP publique origine-destination du point de terminaison GA à la liste d'autorisation du dispositif. Sinon, un délai de connexion peut survenir.
-
Vérifiez si le port de service requis a été ajouté à l'écouteur GA.
Par exemple, une application web utilise à la fois le port 80 et le port 443. Vous devez ajouter les deux ports à l'écouteur GA. Sinon, si vous utilisez un port qui ne figure pas dans l'écouteur pour accéder à l'instance GA, l'accès échouera.
-
Si votre serveur d'origine n'est pas déployé sur Alibaba Cloud, vérifiez si la fonctionnalité Preserve Client IP est activée.
La fonctionnalité Preserve Client IP exige que le serveur d'origine prenne en charge le Proxy Protocol. Sinon, l'accès échouera. Nous vous recommandons de désactiver la fonctionnalité Preserve Client IP et de tenter à nouveau d'accéder au service.
-
Vérifiez si le trafic dépasse le pic de bande passante de la zone d'accélération.
Vous pouvez accéder à l'onglet Monitoring Chart pour afficher le nombre de connexions et l'utilisation de la bande passante. Des pics de trafic peuvent indiquer des attaques DDoS. Pour afficher les métriques de l'instance, consultez la rubrique Afficher les métriques de l'instance.
Vous pouvez modifier le pic de bande passante d'une zone d'accélération. Pour plus d'informations, consultez la rubrique Modifier une zone d'accélération.
Vérifiez si une liste de contrôle d'accès (ACL) est activée pour l'instance GA et si l'adresse IP du client figure dans la liste d'autorisation de l'ACL.
-
Vérifiez si la résolution DNS du nom de domaine est correctement configurée pour résoudre vers le CNAME de GA ou vers l'adresse IP accélérée.
Vous pouvez utiliser une commande telle que dig pour vérifier. Pour plus d'informations sur la configuration d'un enregistrement CNAME, consultez la rubrique Configurer un enregistrement CNAME.
-
Vérifiez si le port de contrôle d'état correspond au port d'écoute du service backend.
Si GA achemine les requêtes vers le service backend via un équilibreur de charge tel que CLB, le port de contrôle d'état doit être identique au port d'écoute réel du service backend. Dans les scénarios de mappage de ports, le port d'écoute backend réel peut différer du port d'écoute GA. Dans ce cas, vous devez configurer les contrôles d'état en fonction du port d'écoute backend réel. Sinon, les contrôles d'état échoueront, le serveur backend sera considéré comme indisponible, ce qui entraînera des échecs d'accès.
Mise à l'échelle automatique pour les pics de trafic
L'ajustement automatique de l'accès client et de la bande passante de transmission dépend de la méthode de facturation de l'instance GA :
Paiement à l'utilisation : La bande passante est automatiquement ajustée en fonction du trafic, jusqu'au pic de bande passante de la zone d'accélération.
Abonnement : La mise à l'échelle automatique n'est pas prise en charge. La bande passante est limitée par la bande passante du plan de bande passante basique et par la capacité maximale de bande passante de la spécification de l'instance GA.
Comment résoudre les problèmes de perte de paquets sur les réseaux transfrontaliers ?
Si vous constatez une perte de paquets importante lors de l'accès à une instance ECS Alibaba Cloud depuis l'étranger, vous pouvez localiser le segment de liaison internationale congestionné en suivant ces étapes :
-
Effectuez une trace de route de longue durée.
Sur le client, exécutez l'une des commandes suivantes :
Linux :
mtr -rwc 100 <public IP of the destination ECS>Windows :
pathping -n -q 100 <public IP of the destination ECS>
Description des paramètres :
-ractive le mode rapport (les résultats sont imprimés ensemble une fois la sonde terminée),-wimprime les noms d'hôte complets et-c 100envoie 100 paquets de sonde. Pour pathping,-nignore la résolution des noms d'hôte et-q 100envoie 100 requêtes par saut. Un échantillonnage de longue durée reflète plus précisément la perte de paquets réelle sur la liaison et évite les jugements erronés causés par des gigue transitoires.Par défaut, mtr utilise des sondes ICMP. Certains réseaux dorsaux appliquent des politiques de transfert ou de limitation de débit différentes pour ICMP et TCP ; ainsi, la perte de paquets ICMP n'équivaut pas nécessairement à la perte de paquets métier (TCP). Pour rester plus proche du trafic métier réel, vous pouvez utiliser le mode TCP pour sonder le port métier, par exemple
mtr -rwc 100 -T -P 443 <public IP of the destination ECS>. -
Interprétez la sortie mtr pour localiser le saut où la perte de paquets se produit.
Loss% : le taux de perte de paquets du saut (en pourcentage)
Snt : le nombre de paquets de sonde envoyés
Last : la latence du dernier aller-retour (ms)
Avg : la latence moyenne des allers-retours (ms)
Best : la latence d'aller-retour la plus faible (ms)
Wrst : la latence d'aller-retour la plus élevée (ms)
Pour localiser le segment présentant des pertes, concentrez-vous sur le saut où Loss% augmente significativement pour la première fois et reste élevé pour tous les sauts suivants. Ce saut constitue le point de départ du segment réellement défaillant. Si un saut affiche 100 % de Loss% mais que les sauts suivants reviennent à la normale, cela signifie généralement que ce routeur limite le débit de ses réponses aux sondes ICMP, plutôt que d'être un point réel de perte de paquets.
-
Effectuez une trace inverse depuis l'ECS de destination.
Depuis l'instance ECS de destination, tracez le chemin retour vers l'IP publique du client :
mtr -r -c 100 <public IP of the client>.Comparez les résultats mtr du chemin aller (client → ECS) et du chemin retour (ECS → client) : si les sauts présentant des pertes diffèrent entre les deux directions, les chemins aller et retour empruntent des liaisons internationales différentes, et vous devez analyser séparément le segment congestionné de chaque direction.
Si le client se trouve derrière un NAT ou un pare-feu, son IP publique peut ne pas répondre aux ICMP, et la perte de paquets au dernier saut de la trace inverse peut indiquer une limitation de la sonde plutôt qu'une perte de paquets réelle. Dans ce cas, vous pouvez effectuer à nouveau une trace aller depuis le client vers l'ECS pour une vérification croisée, ou utiliser le mode TCP pour sonder aux deux extrémités.
-
Localisez le segment de liaison internationale congestionné en fonction de l'itinéraire de l'opérateur.
Utilisez une recherche de propriété IP (telle que la commande whois ou un outil de recherche IP en ligne) pour identifier l'opérateur et l'emplacement du nœud du saut présentant une perte de paquets élevée. Comparez les différences de perte de paquets sur les itinéraires de différents opérateurs pour déterminer si la congestion se situe au niveau de la sortie internationale.
-
Après avoir confirmé la congestion de la liaison internationale, utilisez Global Accelerator pour résoudre la perte de paquets transfrontalière.
Une fois que vous avez confirmé que la perte de paquets est causée par la congestion de la liaison internationale, nous vous recommandons d'utiliser Global Accelerator (GA) pour accélérer l'accès transfrontalier. GA optimise la transmission transfrontalière grâce à l'accès au plus proche et à la bande passante BGP de haute qualité, et vous pouvez mettre à niveau la bande passante premium vers une ligne dédiée transfrontalière China Unicom selon vos besoins, réduisant ainsi le taux de perte de paquets et la latence causés par la congestion de la liaison internationale.