Problemas conocidos: Azure Modeling y Simulation Workbench
Modeling y Simulation Workbench es una plataforma segura basada en la nube para cargas de trabajo colaborativas de ingeniería, diseño y simulación que requieren seguridad y confidencialidad. Workbench proporciona aislamiento para empresas independientes, lo que permite que cada uno incorpore código, datos o aplicaciones y aplíquelos a un entorno compartido sin exponer la propiedad intelectual confidencial.
Esta guía de problemas conocidos proporciona información de solución de problemas y asesoramiento para resolver o reconocer problemas que se van a solucionar. Si es necesario, se proporcionan pasos de solución alternativa o mitigación.
Dependencias de cadencia
Cuando un administrador de cámara está intentando instalar algunas versiones recientes de las herramientas de cadencia, algunos usuarios notifican que faltan dependencias en Modeling y Simulation Workbench. Para corregir este problema, instale las dependencias que faltan.
Pasos para solucionar problemas
Durante la instalación, el comprobador de dependencias de cadencia checkSysConf informa de que faltan los siguientes paquetes en las máquinas virtuales de Modeling y Simulation Workbench. Algunos de esos paquetes están instalados, pero se produce un error en la comprobación de dependencias debido a otras dependencias.
xtermmotiflibXpaprapr-util
Un administrador de cámara puede instalar estos paquetes con el siguiente comando en un terminal:
sudo yum install motif apr apr-util xterm
Errores de carga de licencias de EDA en el nombre del servidor
Al cargar archivos de licencia de Automatización de diseño electrónico (EDA) con nombres de servidor que contienen un símbolo de guión ("-"), el servidor de archivos de licencias de cámara no puede procesar el archivo. En algunos archivos de licencia, el nombre del servidor de línea SERVER no se analiza correctamente. El analizador no puede tokenizar esta línea para volver a formatear el entorno del servidor de licencias de cámara.
Pasos para solucionar problemas
Si el servidor de licencias tiene caracteres de guiones ("-") en el nombre y se produce un error al cargar un archivo de licencia, este problema podría estar presente para la versión. Reemplace el nombre del servidor por cualquier marcador de posición de palabra único con solo caracteres alfanuméricos (A-Z, a-z, 0-9) y sin caracteres especiales o "-". Por ejemplo, si la línea de SERVER tiene este aspecto:
SERVER license-server-01 6045BDEB339C 1717
Reemplace el nombre del servidor de licencias por un nombre sin guiones. El nombre es irrelevante, ya que el servidor de licencias transforma lo que esté en la posición del servidor con el nombre con el formato correcto.
SERVER serverplaceholder 6045BDEB339C 1717
Errores en la carga de archivos de licencia de Synopsys por falta de números de puerto
Algunos archivos de licencia de Synopsys EDA fallan cuando se cargan en el servicio de licencia de cámara de Modeling y Simulation Workbench sin un número de puerto.
Pasos para solucionar problemas
Un archivo de licencia de Synopsys emitido sin un número de puerto en la línea VENDOR no se cargará correctamente a menos que se edite manualmente para incluir el número de puerto. El número de puerto se puede encontrar en la página de información general del servidor de licencias de cámara.
Se muestra un archivo de licencia emitido sin un número de puerto en la línea VENDOR.
VENDOR snpslmd /path/to/snpslmd
Agregue el puerto del servidor de licencias al final de la línea VENDOR. No es necesario actualizar la ruta de acceso del archivo de la herramienta, indicada en el ejemplo como /path/to/snpslmd ni ningún otro contenido.
VENDOR snpslmd /path/to/snpslmd 27021
Los usuarios del conector de IP pública con IP en la lista de permitidos no pueden acceder al escritorio del workbench o a la canalización de datos
No se puede acceder a una cámara con un conector de IP pública configurado para permitir usuarios cuya IP aparece después de la primera entrada de la lista de permitidos ni a través del escritorio ni a través de la canalización de datos mediante AzCopy. Si la lista de permitidos de un conector IP público contiene redes superpuestas, en algunos casos el preprocesador podría no detectar las redes superpuestas antes de intentar asignarlas al NSG activo. Los errores no se notifican al usuario. Es posible que no se procesen otras reglas de NSG, ya sea antes o después de la regla de interferencia, de forma predeterminada en la regla "denegar todo". Es posible que el acceso al conector se bloquee inesperadamente para los usuarios que anteriormente tenían acceso y aparecen en otra parte de la lista. El acceso se bloquea para todas las interacciones del conector, como escritorio, carga de canalización de datos y descarga de canalización de datos. El conector sigue respondiendo a las consultas de puerto, pero no permite interacciones de un intervalo IP o IP que se muestra en la lista de permitidos de redes del conector.
Requisitos previos
Una cámara está configurada con un conector IP público (la puerta de enlace aparece como "Ninguna").
La lista de permitidos tiene entradas con intervalos IP enmascarados por CIDR inferiores a un único host /32 (/31 y más pequeños).
Los intervalos IP de dos o más entradas con enmascaramiento de subred se superponen. A veces, los intervalos superpuestos se pueden identificar con octetos iniciales idénticos, pero los octetos finales marcados con un "0".
Pasos para solucionar problemas
Si un usuario que antes podía acceder a Workbench pierde la conectividad aunque su IP siga en la lista de permitidos, puede que se esté bloqueando un error solapado pero no controlado con la lista de permitidos. La pérdida de conectividad no excluye que cualquier firewall local o en las instalaciones, VPN o puerta de enlace también pueda estar bloqueando el acceso.
Los usuarios deben identificar intervalos IP superpuestos comprobando la lista de permitidos de subredes enmascaradas menores que un único host (menor que /32) y asegurarse de que esas subredes no tienen superposición. Esas subredes superpuestas deben reemplazarse por subredes no superpuestas. Un indicador de esto es que se reconoce la primera entrada de lista de permitidos, pero no hay otras reglas.
Archivo de carga de canalización de datos dañado o truncado
Los archivos cargados en una cámara a través de la canalización de datos se pueden truncar o dañar.
Pasos para solucionar problemas
Al cargar archivos en una cámara, es posible que vea un archivo que no es la longitud esperada, está dañada o, de lo contrario, no pasa una comprobación hash.
Causas posibles:
El archivo no está dañado ni truncado, pero se sigue cargando. La canalización de datos no es una sola fase y los archivos colocados en la canalización de carga no aparecen instantáneamente en el directorio /mount/datapipeline/datain y es probable que se completen. Vuelva a comprobar más adelante y compruebe la longitud o el hash.
Las máquinas virtuales de Azure ubicadas en la misma región que un área de trabajo no pueden acceder a un conector de IP pública
Los recursos implementados fuera de un workbench, en particular las máquinas virtuales (VM), no pueden acceder a una cámara a través de un conector IP público si se encuentran en la misma región. Una máquina virtual implementada en la misma región o incluso el mismo grupo de recursos que un área de trabajo no puede conectarse al conector de la cámara. La dirección IP pública de la máquina virtual está en la lista de permitidos. Una versión instalada localmente de AzCopy no puede acceder a la canalización de datos de la cámara. Los errores incluyen tiempos de espera o no autorizados.
Requisitos previos
Una cámara de workbench se implementa utilizando un conector IP público en una región.
Una máquina virtual u otro recurso con una dirección IP orientada al público se implementa en la misma región.
La lista de permitidos del conector tiene la dirección IP pública de la máquina virtual.
Pasos para solucionar problemas
Los recursos de Azure de la misma región no usan la dirección IP pública ni Internet para comunicarse. En su lugar, si un recurso de Azure inicia la comunicación con otro recurso de Azure en la misma región, se usan redes privadas de Azure. Como resultado, las direcciones IP de origen y destino son direcciones de red privadas, que no se permiten en la lista de permitidos del conector.
La VM u otro recurso que se comunique directamente debe estar situado en otra región junto a la del workbench. La conexión en red sigue produciéndose en la red troncal de Azure y no pasa por la Internet general, sino que utiliza la dirección IP pública. La nueva región puede ser cualquier región permitida para el recurso y no necesita ser una región activa para Modeling y Simulation Workbench.