Noeuds worker gérés par IBM fournis par le maître au client pour le plan de contrôle d'emplacement Satellite

Les hôtes que vous souhaitez associer au plan de contrôle de l'emplacement Satellite doivent disposer d'une connexion à faible latence, avec un temps aller-retour (RTT) inférieur ou égal à 200 millisecondes (<= 200ms), vers la région IBM Cloud à partir de laquelle votre emplacement Satellite est géré. Au fur et à mesure que le temps d'attente augmente, vous pouvez observer des impacts sur les performances, notamment le débit de Satellite Link, le temps de mise à disposition du service IBM Cloud prêt pour Satellite, le temps de reprise après échec de l'hôte et, dans les cas extrêmes, la disponibilité des ressources qui s'exécutent dans le plan de contrôle d'emplacement Satellite, tels que les clusters maîtres Red Hat OpenShift. Pour plus d'informations, voir Test du temps d'attente entre IBM Cloud et les hôtes du plan de contrôle d'emplacement Satellite.

Des noeuds worker fournis par le client dans le plan de contrôle d'emplacement Satellite vers des noeuds worker qui exécutent des services IBM Cloud prêts pour Satellite, tels que des clusters Red Hat OpenShift dans le même emplacement.

La configuration de votre infrastructure hôte doit disposer d’une connexion à faible latence, avec un temps aller-retour (RTT) inférieur ou égal à 100 millisecondes (<= 100ms), entre les hôtes utilisés pour les nœuds de travail du plan de contrôle de l’emplacement Satellite et les hôtes utilisés pour les autres ressources de l’emplacement, telles que les clusters ou le service IBM Cloud activé pour l’ Satellite. Par exemple, pour les fournisseurs de cloud tels que AWS, cette configuration signifie généralement que tous les hôtes de l'emplacement Satellite proviennent de la même région de cloud, comme us-east-1. Au fur et à mesure que le temps d'attente augmente, vous pouvez observer des impacts sur les performances, y compris les temps de mise à disposition et de reprise, la réduction des noeuds worker dans le cluster, la dégradation du service IBM Cloud prêt pour Satellite et, dans les cas extrêmes, des défaillances de vos applications de cluster.

Noeuds worker fournis par le client qui sont affectés à la même ressource, comme le plan de contrôle d'emplacement ou un cluster Satellite

La configuration de votre infrastructure d’hôtes doit disposer d’une connexion à faible latence, avec un temps aller-retour (<= 10ms RTT) inférieur ou égal à 10 millisecondes entre tous les hôtes affectés à une même ressource d’ Satellite, telle que le plan de contrôle de localisation Satellite, un service IBM Cloud compatible avec la fonctionnalité Satellite ou un cluster. Au fur et à mesure que le temps d'attente augmente, vous observerez des impacts sur les performances, y compris les services IBM Cloud prêts pour Satellite comme les bases de données ou les échecs d'application de cluster.

Test du temps d'attente entre IBM Cloud et les hôtes du plan de contrôle d'emplacement Satellite

Chaque emplacement Satellite est géré à partir d'une région multizone IBM Cloud. Vous pouvez tester la latence entre vos hôtes et la région afin de vous assurer que vous utilisez une connexion à faible latence, avec un temps aller-retour (RTT) inférieur ou égal à 200 millisecondes (<= 200ms).

1. Dans votre fournisseur d'infrastructure, connectez-vous à une machine hôte que vous souhaitez ajouter à un emplacement Satellite. Par exemple, connectez-vous à la machine via SSH à partir d'une ligne de commande.

2. Notez les adresses IP de la région IBM Cloud que vous souhaitez tester

   Dallas

   52.117.39.146, 169.48.134.66, 169.63.36.210

   Francfort

   149.81.188.122, 158.177.88.18, 161.156.38.122

   Londres

   158.175.120.210, 141.125.97.106, 158.176.139.66

   Osaka

   163.68.73.50, 163.69.65.242, 163.73.67.10

   São Paulo

   163.107.67.18, 163.109.71.82, 169.57.144.42

   Sydney

   130.198.65.82, 135.90.66.194, 168.1.58.90

   Tokyo

   161.202.104.226, 128.168.67.106, 165.192.108.10

   Toronto

   163.74.65.138, 163.75.70.50, 169.53.160.154

   Washington, DC

   169.63.123.154, 169.63.110.114, 169.62.13.2, 169.60.123.162, 169.59.152.58, 52.117.93.26

   Madrid

   13.120.67.114, 13.121.67.98, 13.122.67.106

3. A partir de votre hôte, envoyez une commande ping aux adresses IP de la région IBM Cloud.

   ping <ip_address>
   

4. Une fois la transmission de quelques paquets terminée, fermez la connexion. Par exemple, depuis la ligne de commande, saisissez ctrl+c.

5. Dans le résultat ping statistics, notez la distance aller-retour moyenne (avg) en millisecondes (ms) entre l’hôte et la région d’ IBM Cloud, puis vérifiez si la connexion respecte l’exigence de latence inférieure ou égale à 200 millisecondes (<= 200ms).

   Exemple de connexion répondant aux exigences en matière de temps d'attente

   --- 169.63.123.154 ping statistics ---
   25 packets transmitted, 25 packets received, 0.0% packet loss
   round trip min/avg/max/stddev = 48.131/77.716/181.397/27.893 ms
   

   Exemple de connexion ne répondant pas aux exigences en matière de temps d'attente

   --- 158.175.120.210 ping statistics ---
   9 packets transmitted, 9 packets received, 0.0% packet loss
   round trip min/avg/max/stddev = 138.453/217.370/419.901/108.211 ms