Partager via

Problèmes connus : Workbench de modélisation et de simulation Azure

  • Article

Le service Workbench de modélisation et de simulation Azure est une plateforme sécurisée basée sur le cloud pour l’ingénierie collaborative, la conception et les charges de travail de simulation qui nécessitent une sécurité et une confidentialité. Workbench fournit une isolation pour les entreprises distinctes, permettant à chacune d’elles d’importer du code, des données ou des applications et de les appliquer à un environnement partagé sans exposer de propriété intellectuelle confidentielle.

Ce guide des problèmes connus fournit des informations de dépannage et des conseils pour résoudre ou reconnaître les problèmes à résoudre. Le cas échéant, des étapes de contournement ou d’atténuation sont fournies.

Dépendances de cadence

Lorsqu'un administrateur de chambre tente d'installer certaines versions récentes des outils Cadence, certains utilisateurs signalent des dépendances manquantes sur Modeling and Simulation Workbench. Pour résoudre ce problème, installez les dépendances manquantes.

Étapes de dépannage

Lors de l'installation, le vérificateur de dépendances de Cadence checkSysConf signale que les paquets suivants sont manquants dans les VMs de Modeling and Simulation Workbench. Certains de ces paquets sont installés, mais la vérification des dépendances échoue en raison d'autres dépendances.

  • xterm
  • motif
  • libXp
  • apr
  • apr-util

Un administrateur de chambre peut installer ces paquets avec la commande suivante dans un terminal :

sudo yum install motif apr apr-util xterm

Échecs de chargement de licence EDA sur le nom du serveur

Lorsque vous chargez des fichiers de licence EDA (Electronic Design Automation) avec des noms de serveur qui contiennent un symbole de tiret (« - »), le serveur de fichiers de licence de la chambre ne parvient pas à traiter le fichier. Pour certains fichiers de licence, le nom du serveur de la ligne SERVER n’est pas correctement analysé. L’analyseur ne parvient pas à tokeniser cette ligne afin de la reformater pour l’environnement du serveur de licences de chambre.

Étapes de dépannage

Si le nom de votre serveur de licences comporte des tirets (« - ») et qu’un échec se produit lors du chargement d’un fichier de licence, il se peut que ce problème soit présent pour votre version. Remplacez le nom du serveur par n’importe quel espace réservé à mot unique en utilisant uniquement des caractères alphanumériques (A-Z, a-z, 0-9) et aucun caractère spécial ou « - ». Par exemple, si votre ligne SERVER ressemble à ceci :

SERVER license-server-01 6045BDEB339C 1717

Remplacez le nom du serveur de licences par un nom sans tirets. Le nom n’a pas d’importance, car le serveur de licences transforme tout ce qui se trouve dans la position du serveur avec le nom correctement mis en forme.

SERVER serverplaceholder 6045BDEB339C 1717

Échecs de chargement des fichiers de licence Synopsys en raison de numéros de ports manquants

Certains fichiers de licence EDA Synopsys échouent lors du chargement vers le service de licences de la chambre Workbench de modélisation et de simulation en l’absence de numéro de port.

Étapes de dépannage

Un fichier de licence Synopsys émis sans numéro de port sur la ligne VENDOR ne sera pas correctement chargé, sauf s’il est modifié manuellement de façon à inclure le numéro de port. Le numéro de port se trouve dans la page de vue d’ensemble du serveur de licences de la chambre.

Un fichier de licence émis sans numéro de port sur la ligne VENDOR est affiché.

VENDOR snpslmd /path/to/snpslmd

Ajoutez le port du serveur de licences à la fin de la ligne VENDOR. Vous n’avez pas besoin de mettre à jour le chemin d’accès au fichier outil (/path/to/snpslmd, dans notre exemple) ou tout autre contenu.

VENDOR snpslmd /path/to/snpslmd 27021

Les utilisateurs sur le connecteur IP public disposant d’une adresse IP sur liste verte ne peuvent pas accéder au bureau Workbench ou au pipeline de données

Lorsque le connecteur IP public de la chambre est configuré de façon à autoriser les utilisateurs dont l’adresse IP figure après la première entrée de la liste verte, ceux-ci ne peuvent pas être accédé via le bureau ou le pipeline de données avec AzCopy. Si la liste verte sur un connecteur IP public contient des réseaux qui se chevauchent, dans certains cas, le préprocesseur peut ne pas détecter les réseaux qui se chevauchent avant de tenter de les valider dans le groupe de sécurité réseau actif. Les échecs ne sont pas signalés à l’utilisateur. D’autres règles de groupe de sécurité réseau ailleurs ( avant ou après la règle d’interférence) peuvent ne pas être traitées, provoquant l’utilisation par défaut de la règle « refuser tout ». L’accès au connecteur peut être bloqué de façon inattendue pour les utilisateurs qui avaient auparavant accès et apparaissaient ailleurs dans la liste. L’accès est bloqué pour toutes les interactions de connecteur, notamment en ce qui concerne le bureau, le chargement de pipeline de données et le téléchargement de pipeline de données. Le connecteur répond toujours aux requêtes de port, mais n’autorise pas les interactions à partir d’une adresse IP ou d’une plage IP figurant dans la liste verte réseau du connecteur.

Prérequis

  • Une chambre est configurée avec un connecteur IP public (la mention « Aucune » apparaît pour la passerelle).

  • La liste verte contient des entrées avec des plages d’adresses IP masquées CIDR inférieures à un hôte unique /32 (/31 et plus petits).

  • Les plages d’adresses IP de deux entrées ou plus avec masquage de sous-réseau se chevauchent. Les plages qui se chevauchent peuvent parfois être identifiées avec des octets de début identiques, mais des octets de fin marqués par un « 0 ».

Étapes de dépannage

Si un utilisateur qui pouvait auparavant accéder à Workbench perd la connectivité alors que son adresse IP figure toujours sur la liste verte, une erreur de chevauchement non gérée au niveau de la liste verte peut être la cause du blocage. La perte de connectivité n’empêche pas qu’un pare-feu, un VPN ou une passerelle local(e) bloque également l’accès.

Les utilisateurs doivent identifier les plages d’adresses IP qui se chevauchent en vérifiant la liste verte des sous-réseaux masqués inférieurs à un hôte unique (inférieurs à /32) et veiller à ce que ces sous-réseaux ne se chevauchent pas. Les sous-réseaux qui se chevauchent doivent être remplacés par des sous-réseaux qui ne se chevauchent pas. Ce problème se traduit par le fait que la première entrée de la liste verte est reconnue, mais pas les autres règles.

Troncation ou altération d’un fichier de chargement de pipeline de données

Les fichiers chargés dans une chambre via le pipeline de données peuvent être tronqués ou endommagés.

Étapes de dépannage

Lors du chargement de fichiers dans une chambre, vous pouvez observer un fichier qui n’a pas la longueur attendue, qui est endommagé, ou dont la vérification de hachage échoue.

Causes possibles

Le fichier n’est pas endommagé ou tronqué, mais toujours en cours de chargement. Le pipeline de données ne compte pas une phase unique, et les fichiers placés dans le pipeline de chargement n’apparaissent pas instantanément dans le répertoire /mount/datapipeline/datain et sont probablement encore en cours de traitement. Vérifiez ultérieurement la longueur ou le hachage.

Les machines virtuelles Azure situées dans la même région qu’un Workbench ne peuvent pas accéder à un connecteur IP public

Les ressources déployées en dehors d’un Workbench, en particulier les machines virtuelles, ne peuvent pas accéder à une chambre via un connecteur IP public si elles se trouvent dans la même région. Une machine virtuelle déployée dans la même région ou le même groupe de ressources qu’un Workbench ne peut pas se connecter au connecteur de la chambre. L’adresse IP publique de la machine virtuelle figure sur la liste verte. Une version installée localement d’AzCopy ne peut pas accéder au pipeline de données de la chambre. Les erreurs incluent des expirations de délais d’attente ou des refus d’autorisation d’accès.

Prérequis

  • Une chambre Workbench est déployée à l’aide d’un connecteur IP public dans une région.

  • Une machine virtuelle ou une autre ressource avec une adresse IP publique est déployée dans la même région.

  • L’adresse IP publique de la machine virtuelle figure sur la liste verte du connecteur.

Étapes de dépannage

Les ressources Azure de la même région n’utilisent pas d’adresse IP publique ou Internet pour communiquer. Au lieu de cela, si une ressource Azure lance la communication avec une autre ressource Azure dans la même région, le réseau Azure privé est utilisé. En conséquence, les adresses IP source et de destination sont toutes deux des adresses réseau privées, qui ne sont pas autorisées à figurer sur la liste verte du connecteur.

La machine virtuelle ou toute autre ressource qui communique directement doit se trouver dans une région autre que celle de Workbench. La mise en réseau continue de se produire sur le réseau principal d’Azure et ne bascule pas sur l’Internet général, mais utilise plutôt l’adresse IP publique. La nouvelle région peut être n’importe quelle région autorisée pour la ressource. Il n’est pas obligatoire que ce soit une région active pour le service Workbench de modélisation et de simulation Azure.