Problemas conhecidos: Bancada de Trabalho de Modelagem e Simulação do Azure
O Modeling and Simulation Workbench é uma plataforma segura baseada em nuvem para cargas de trabalho colaborativas de engenharia, projeto e simulação que exigem segurança e confidencialidade. O Workbench fornece isolamento para empresas separadas, permitindo que cada uma traga código, dados ou aplicativos e os aplique a um ambiente compartilhado sem expor a propriedade intelectual confidencial.
Este guia de Problemas Conhecidos fornece informações de solução de problemas e consultoria para resolver ou reconhecer problemas a serem resolvidos. Quando aplicável, são fornecidas etapas de solução alternativa ou mitigação.
Dependências de cadência
Quando um administrador de câmara está tentando instalar algumas versões recentes de ferramentas de cadência, alguns usuários relatam dependências ausentes no Workbench de modelagem e simulação. Para corrigir esse problema, instale as dependências ausentes.
Etapas para solucionar problemas
Durante a instalação, o verificador de dependências de cadência checkSysConf informa que os seguintes pacotes estão ausentes das VMs do Workbench de modelagem e simulação. Alguns desses pacotes estão instalados, mas falham na verificação de dependência devido a outras dependências.
xtermmotiflibXpaprapr-util
Um Administrador de câmara pode instalar esses pacotes com o seguinte comando em um terminal:
sudo yum install motif apr apr-util xterm
Falhas de upload de licença EDA no nome do servidor
Ao carregar arquivos de licença do Electronic Design Automation (EDA) com nomes de servidor que contêm um símbolo de traço ("-"), o servidor de arquivos de licença da câmara falha ao processar o arquivo. Para alguns arquivos de licença, o nome do servidor de linha SERVER não está sendo analisado corretamente. O analisador falha ao tokenizar essa linha para reformatar para o ambiente do servidor de licenças da câmara.
Etapas para solucionar problemas
Se o servidor de licenças tiver algum caractere de traço ("-") no nome e falhar ao fazer upload de um arquivo de licença, esse problema poderá estar presente para sua versão. Substitua o nome do servidor por qualquer espaço reservado de palavra única usando apenas caracteres alfanuméricos (A-Z, a-z, 0-9) e nenhum caractere especial ou "-". Por exemplo, se sua linha SERVER for assim:
SERVER license-server-01 6045BDEB339C 1717
Substitua o nome do servidor de licença por um nome sem traços. O nome é irrelevante, pois o servidor de licenças transforma o que quer que esteja na posição do servidor com o nome formatado corretamente.
SERVER serverplaceholder 6045BDEB339C 1717
Falhas de upload de arquivos de licença Synopsys devido a números de porta ausentes
Determinados arquivos de licença do Synopsys EDA falham quando carregados no serviço de licença de câmara do Modeling and Simulation Workbench sem um número de porta.
Etapas para solucionar problemas
Um arquivo de licença Synopsys emitido sem um número de porta na linha VENDOR não será carregado com êxito, a menos que seja editado manualmente para incluir o número da porta. O número da porta pode ser encontrado na página de visão geral do servidor de licenças da câmara.
Um arquivo de licença emitido sem um número de porta na linha VENDOR é mostrado.
VENDOR snpslmd /path/to/snpslmd
Adicione a porta do servidor de licenças ao final da linha VENDOR. Você não precisa atualizar o caminho do arquivo de ferramenta, indicado no exemplo como /path/to/snpslmd ou qualquer outro conteúdo.
VENDOR snpslmd /path/to/snpslmd 27021
Os usuários no conector IP público com IP na lista de permissões não podem acessar a área de trabalho do workbench ou o pipeline de dados
Uma câmara com um conector de IP público configurado para Permitir Usuários cujo IP está listado após a primeira Entrada da lista de permitidos não pode ser acessada nem pela Área de Trabalho nem pelo pipeline de dados usando o AzCopy. Se a lista de permissões em um conector IP público contiver redes sobrepostas, em alguns casos, o pré-processador poderá falhar ao detectar as redes sobrepostas antes de tentar confirmá-las no NSG ativo. As falhas não são relatadas de volta ao usuário. Outras regras de NSG em outro lugar - antes ou depois da regra de interferência - podem não ser processadas, padronizando a regra "negar tudo". O acesso ao conector pode ser bloqueado inesperadamente para usuários que anteriormente tinham acesso e aparecem em outro lugar na lista. O acesso é bloqueado para todas as interações do conector, incluindo área de trabalho, upload de pipeline de dados e download de pipeline de dados. O conector ainda responde a consultas de porta, mas não permite interações de um IP ou intervalo de IP mostrado na lista de permissões de rede do conector.
Pré-requisitos
Uma câmara é configurada com um conector IP público (o gateway aparece como "Nenhum").
A lista de permissões tem entradas com intervalos de IP mascarados por CIDR menores que um único host /32 (/31 e menor).
Os intervalos de IP de duas ou mais entradas com mascaramento de sub-rede estão sobrepostos. Intervalos sobrepostos às vezes podem ser identificados com octetos iniciais sendo idênticos, mas octetos à direita marcados com um "0".
Etapas para solucionar problemas
Se um usuário que podia acessar anteriormente o workbench perder a conectividade mesmo que seu IP ainda esteja na lista de permissões, um erro sobreposto, mas não tratado, com a lista de permissões poderá estar bloqueando. A perda de conectividade não impede que qualquer firewall, VPN ou gateway local ou local também possa estar bloqueando o acesso.
Os usuários devem identificar intervalos de IP sobrepostos verificando a lista de permissões de sub-redes mascaradas menores que um único host (menor que /32) e garantir que essas sub-redes não tenham sobreposição. Essas sub-redes sobrepostas devem ser substituídas por sub-redes não sobrepostas. Um indicador disso é que a primeira entrada da lista de permissões é reconhecida, mas outras regras não.
Corrupção ou truncamento de arquivo de upload de pipeline de dados
Os arquivos carregados em uma câmara por meio do pipeline de dados podem estar truncados ou corrompidos.
Etapas para solucionar problemas
Ao carregar arquivos em uma câmara, você pode ver um arquivo que não tem o comprimento esperado, está corrompido ou que não passa por uma verificação de hash.
Possíveis causas:
O arquivo não está corrompido ou truncado, mas ainda está sendo carregado. O pipeline de dados não é um único estágio e os arquivos colocados no pipeline de upload não aparecem instantaneamente no diretório /mount/datapipeline/datain e provavelmente ainda estão sendo concluídos. Verifique novamente mais tarde e verifique o comprimento ou hash.
As VMs do Azure localizadas na mesma região que um workbench não podem acessar um conector IP público
Os recursos implantados fora de uma bancada de trabalho, em particular máquinas virtuais (VM), não podem acessar uma câmara por meio de um conector IP público se estiverem localizados na mesma região. Uma VM implantada na mesma região ou mesmo no mesmo grupo de recursos que um workbench não consegue se conectar ao conector da câmara. O endereço IP voltado para o público da VM está na lista de permissões. Uma versão instalada localmente do AzCopy não consegue acessar o pipeline de dados da câmara. Os erros incluem tempos limite ou não autorizados.
Pré-requisitos
Uma câmara de bancada é implantada usando um conector IP público em uma região.
Uma máquina virtual ou outro recurso com um endereço IP voltado para o público é implantado na mesma região.
A lista de permissões do conector tem o endereço IP voltado para o público da VM.
Etapas para solucionar problemas
Os recursos do Azure na mesma região não usam IP público ou Internet para se comunicar. Em vez disso, se um recurso do Azure iniciar a comunicação com outro recurso do Azure na mesma região, a rede privada do Azure será usada. Como resultado, os endereços IP de origem e de destino são endereços de rede privada, que não são permitidos na lista de permissões do conector.
A VM ou outro recurso de comunicação direta deve estar localizado em outra região ao lado da região do ambiente de trabalho. A rede continua a acontecer na rede de backbone do Azure e não passa pela Internet geral, mas usa o endereço IP público. A nova região pode ser qualquer região permitida para o recurso e não precisa ser uma região ativa para o Workbench de modelagem e simulação.