Problema RunBooks - Estúdio de Pesquisa e Engenharia
Problemas de instalaçãoProblemas de gerenciamento de identidadeArmazenamentoSnapshotsInfraestruturaLançamento de desktops virtuaisComponente de desktop virtualExclusão do ambienteAmbiente de demonstração

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Problema RunBooks

A seção a seguir contém problemas que podem ocorrer, como detectá-los e sugestões sobre como resolvê-los.

Problemas de instalação

........................

Quero configurar domínios personalizados depois de instalar o RES

nota

Pré-requisitos: Você deve armazenar o certificado e o PrivateKey conteúdo em um segredo do Secrets Manager antes de executar essas etapas.

Adicionar certificados ao cliente web

  1. Atualize o certificado anexado ao ouvinte do balanceador de carga external-alb:

    1. Navegue até o balanceador de carga externo RES no AWS console em EC2> Balanceamento de carga > Balanceadores de carga.

    2. Procure o balanceador de carga que segue a convenção de nomenclatura. <env-name>-external-alb

    3. Verifique os ouvintes conectados ao balanceador de carga.

    4. Atualize o ouvinte que tem um certificado SSL/TLS padrão anexado com os detalhes do novo certificado.

    5. Salve as alterações.

  2. Na tabela de configurações do cluster:

    1. Encontre a tabela de configurações de cluster em DynamoDB -> Tabelas ->. <env-name>.cluster-settings

    2. Acesse Explorar itens e filtrar por atributo — nome “chave”, tipo “string”, condição “contém” e valor “external_alb”.

    3. cluster.load_balancers.external_alb.certificates.providedDefina como Verdadeiro.

    4. Atualize o valor decluster.load_balancers.external_alb.certificates.custom_dns_name. Esse é o nome de domínio personalizado para a interface de usuário da web.

    5. Atualize o valor decluster.load_balancers.external_alb.certificates.acm_certificate_arn. Esse é o Amazon Resource Name (ARN) do certificado correspondente armazenado no Amazon Certificate Manager (ACM).

  3. Atualize o registro correspondente do subdomínio Route53 que você criou para seu cliente web para apontar para o nome DNS do balanceador de carga externo do laboratório. <env-name>-external-alb

  4. Se o SSO já estiver configurado no ambiente, reconfigure o SSO com as mesmas entradas que você usou inicialmente no botão Gerenciamento de ambiente > Gerenciamento de identidade > Login único > Status > Editar no portal web RES.

Adicione certificados ao VDIs

  1. Conceda permissão ao aplicativo RES para realizar uma GetSecret operação no segredo adicionando as seguintes tags aos segredos:

    • res:EnvironmentName : <env-name>

    • res:ModuleName : virtual-desktop-controller

  2. Na tabela de configurações do cluster:

    1. Encontre a tabela de configurações de cluster em DynamoDB -> Tabelas ->. <env-name>.cluster-settings

    2. Acesse Explorar itens e filtrar por atributo — nome “chave”, tipo “string”, condição “contém” e valor “dcv_connection_gateway”.

    3. vdc.dcv_connection_gateway.certificate.providedDefina como Verdadeiro.

    4. Atualize o valor devdc.dcv_connection_gateway.certificate.custom_dns_name. Esse é o nome de domínio personalizado para acesso à VDI.

    5. Atualize o valor devdc.dcv_connection_gateway.certificate.certificate_secret_arn. Esse é o ARN do segredo que contém o conteúdo do certificado.

    6. Atualize o valor devdc.dcv_connection_gateway.certificate.private_key_secret_arn. Esse é o ARN do segredo que contém o conteúdo da chave privada.

  3. Atualize o modelo de execução usado para a instância do gateway:

    1. Abra o grupo Auto Scaling no AWS console em EC2> Auto Scaling > Auto Scaling Groups.

    2. Selecione o grupo de escalonamento automático do gateway que corresponde ao ambiente RES. O nome segue a convenção <env-name>-vdc-gateway-asg de nomenclatura.

    3. Encontre e abra o modelo de lançamento na seção de detalhes.

    4. Em Detalhes > Ações > escolha Modificar modelo (Criar nova versão).

    5. Role para baixo até Detalhes avançados.

    6. Role até a parte inferior, até Dados do usuário.

    7. Procure as palavras CERTIFICATE_SECRET_ARN PRIVATE_KEY_SECRET_ARN e. Atualize esses valores com o ARNs conteúdo fornecido aos segredos que contêm o certificado (consulte a etapa 2.c) e a chave privada (consulte a etapa 2.d).

    8. Certifique-se de que o grupo Auto Scaling esteja configurado para usar a versão recém-criada do modelo de lançamento (na página do grupo Auto Scaling).

  4. Atualize o registro correspondente do subdomínio Route53 que você criou para seus desktops virtuais para apontar para o nome DNS do balanceador de carga nlb externo:. <env-name>-external-nlb

  5. Encerre a instância existente do dcv-gateway: <env-name>-vdc-gateway e espere que uma nova seja ativada.

........................

AWS CloudFormation falha ao criar a pilha com a mensagem “mensagem de falha WaitCondition recebida”. Erro: Estados. TaskFailed”

Para identificar o problema, examine o grupo de CloudWatch registros da Amazon chamado<stack-name>-InstallerTasksCreateTaskDefCreateContainerLogGroup<nonce>-<nonce>. Se houver vários grupos de registros com o mesmo nome, examine o primeiro disponível. Uma mensagem de erro nos registros fornecerá mais informações sobre o problema.

nota

Confirme se os valores dos parâmetros não têm espaços.

........................

Notificação por e-mail não recebida após a criação bem-sucedida das AWS CloudFormation pilhas

Se um convite por e-mail não foi recebido após a criação bem-sucedida das AWS CloudFormation pilhas, verifique o seguinte:

  1. Confirme se o parâmetro do endereço de e-mail foi inserido corretamente.

    Se o endereço de e-mail estiver incorreto ou não puder ser acessado, exclua e reimplante o ambiente do Research and Engineering Studio.

  2. Verifique o EC2 console da Amazon para obter evidências de casos de ciclismo.

    Se houver EC2 instâncias da Amazon com o <envname> prefixo que aparecem como encerradas e depois são substituídas por uma nova instância, pode haver um problema com a configuração da rede ou do Active Directory.

  3. Se você implantou as receitas de computação de AWS alto desempenho para criar seus recursos externos, confirme se a VPC, as sub-redes públicas e privadas e outros parâmetros selecionados foram criados pela pilha.

    Se algum dos parâmetros estiver incorreto, talvez seja necessário excluir e reimplantar o ambiente RES. Para obter mais informações, consulte Desinstalar o produto.

  4. Se você implantou o produto com seus próprios recursos externos, confirme se a rede e o Active Directory correspondem à configuração esperada.

    Confirmar que as instâncias de infraestrutura ingressaram com sucesso no Active Directory é fundamental. Experimente as etapas Ciclismo de instâncias ou controlador vdc em estado de falha para resolver o problema.

........................

Ciclismo de instâncias ou controlador vdc em estado de falha

A causa mais provável desse problema é a incapacidade do (s) recurso (s) de se conectar ou ingressar no Active Directory.

Para verificar o problema:

  1. Na linha de comando, inicie uma sessão com SSM na instância em execução do controlador vdc.

  2. Executar sudo su -.

  3. Executar systemctl status sssd.

Se o status for inativo, falhar ou você ver erros nos registros, a instância não conseguiu ingressar no Active Directory.

Registro de erros do SSM

Registro de erros do SSM

Para resolver o problema:

  • Na mesma instância da linha de comando, execute cat /root/bootstrap/logs/userdata.log para investigar os registros.

O problema pode ter uma das três possíveis causas principais.

Revise os registros. Se você ver o seguinte repetido várias vezes, a instância não conseguiu ingressar no Active Directory.

+ local AD_AUTHORIZATION_ENTRY=
+ [[ -z '' ]]
+ [[ 0 -le 180 ]]
+ local SLEEP_TIME=34
+ log_info '(0 of 180) waiting for AD authorization, retrying in 34 seconds ...'
++ date '+%Y-%m-%d %H:%M:%S,%3N'
+ echo '[2024-01-16 22:02:19,802] [INFO] (0 of 180) waiting for AD authorization, retrying in 34 seconds ...'
[2024-01-16 22:02:19,802] [INFO] (0 of 180) waiting for AD authorization, retrying in 34 seconds ...
+ sleep 34
+ (( ATTEMPT_COUNT++ ))

  1. Verifique se os valores dos parâmetros a seguir foram inseridos corretamente durante a criação da pilha RES.

    • directoryservice.ldap_connection_uri

    • serviço de diretório.ldap_base

    • directoryservice.users.ou

    • directoryservice.groups.ou

    • directoryservice.sudoers.ou

    • directoryservice.computers.ou

    • nome do serviço de diretório.name

  2. Atualize todos os valores incorretos na tabela do DynamoDB. A tabela é encontrada no console do DynamoDB em Tabelas. O nome da tabela deve ser<stack name>.cluster-settings.

  3. Depois de atualizar a tabela, exclua o cluster-manager e o vdc-controller que estão executando as instâncias do ambiente no momento. O Auto Scaling iniciará novas instâncias usando os valores mais recentes da tabela do DynamoDB.

Se os registros retornaremInsufficient permissions to modify computer account, o ServiceAccount nome inserido durante a criação da pilha pode estar incorreto.

  1. No AWS console, abra o Secrets Manager.

  2. Pesquise por directoryserviceServiceAccountUsername. O segredo deveria ser<stack name>-directoryservice-ServiceAccountUsername.

  3. Abra o segredo para ver a página de detalhes. Em Valor secreto, escolha Recuperar valor secreto e escolha Texto sem formatação.

  4. Se o valor tiver sido atualizado, exclua as instâncias cluster-manager e vdc-controller do ambiente atualmente em execução. O escalonamento automático iniciará novas instâncias usando o valor mais recente do Secrets Manager.

Se os registros forem exibidosInvalid credentials, a ServiceAccount senha inserida durante a criação da pilha pode estar incorreta.

  1. No AWS console, abra o Secrets Manager.

  2. Pesquise por directoryserviceServiceAccountPassword. O segredo deveria ser<stack name>-directoryservice-ServiceAccountPassword.

  3. Abra o segredo para ver a página de detalhes. Em Valor secreto, escolha Recuperar valor secreto e escolha Texto sem formatação.

  4. Se você esqueceu a senha ou não tem certeza se a senha digitada está correta, você pode redefinir a senha no Active Directory e no Secrets Manager.

    1. Para redefinir a senha em AWS Managed Microsoft AD:

      1. Abra o AWS console e vá para AWS Directory Service.

      2. Selecione o ID do diretório para seu diretório RES e escolha Ações.

      3. Selecione Redefinir senha do usuário.

      4. Insira o ServiceAccount nome de usuário.

      5. Insira uma nova senha e escolha Redefinir senha.

    2. Para redefinir a senha no Secrets Manager:

      1. Abra o AWS console e vá para o Secrets Manager.

      2. Pesquise por directoryserviceServiceAccountPassword. O segredo deveria ser<stack name>-directoryservice-ServiceAccountPassword.

      3. Abra o segredo para ver a página de detalhes. Em Valor secreto, escolha Recuperar valor secreto e escolha Texto sem formatação.

      4. Selecione Editar.

      5. Defina uma nova senha para o ServiceAccount usuário e escolha Salvar.

  5. Se você atualizou o valor, exclua as instâncias cluster-manager e vdc-controller do ambiente atualmente em execução. O Auto Scaling iniciará novas instâncias usando o valor mais recente.

........................

Falha ao excluir a CloudFormation pilha de ambiente devido a um erro no objeto dependente

Se a exclusão da <env-name>-vdc CloudFormation pilha falhar devido a um erro de objeto dependente, como ovdcdcvhostsecuritygroup, isso pode ser devido a uma EC2 instância da Amazon que foi executada em uma sub-rede ou grupo de segurança criado pelo RES usando o console. AWS

Para resolver o problema, encontre e encerre todas as EC2 instâncias da Amazon iniciadas dessa maneira. Em seguida, você pode retomar a exclusão do ambiente.

........................

Erro encontrado no parâmetro de bloco CIDR durante a criação do ambiente

Ao criar um ambiente, aparece um erro para o parâmetro do bloco CIDR com um status de resposta de [FALHOU].

Exemplo de erro: 

Failed to update cluster prefix list: 
        An error occurred (InvalidParameterValue) when calling the ModifyManagedPrefixList operation: 
        The specified CIDR (52.94.133.132/24) is not valid. For example, specify a CIDR in the following form: 10.0.0.0/16.

Para resolver o problema, o formato esperado é x.x.x.0/24 ou x.x.x.0/32.

........................

CloudFormation falha na criação da pilha durante a criação do ambiente

A criação de um ambiente envolve uma série de operações de criação de recursos. Em algumas regiões, pode ocorrer um problema de capacidade que faz com que a criação da CloudFormation pilha falhe.

Se isso ocorrer, exclua o ambiente e repita a criação. Como alternativa, você pode tentar novamente a criação em uma região diferente.

........................

A criação da pilha de recursos externos (demo) falha com AdDomainAdminNode CREATE_FAILED

Se a criação da pilha do ambiente de demonstração falhar com o seguinte erro, pode ser devido à ocorrência inesperada de EC2 patches da Amazon durante o provisionamento após o lançamento da instância. 

AdDomainAdminNode CREATE_FAILED  Failed to receive 1 resource signal(s) within the specified duration
Para determinar a causa da falha:

  1. No SSM State Manager, verifique se o patch está configurado e se está configurado para todas as instâncias.

  2. No histórico de execução de RunCommand SSM/Automation, verifique se a execução de um documento SSM relacionado a patches coincide com o lançamento de uma instância.

  3. Nos arquivos de log das EC2 instâncias Amazon do ambiente, revise o registro da instância local para determinar se a instância foi reinicializada durante o provisionamento.

Se o problema foi causado por uma correção, adie a correção das instâncias RES pelo menos 15 minutos após o lançamento.

........................

Problemas de gerenciamento de identidade

A maioria dos problemas com o login único (SSO) e o gerenciamento de identidade ocorre devido à configuração incorreta. Para obter informações sobre como definir sua configuração de SSO, consulte:

Para solucionar outros problemas relacionados ao gerenciamento de identidades, consulte os seguintes tópicos de solução de problemas:

........................

Não estou autorizado a realizar iam: PassRole

Se você receber um erro informando que não está autorizado a realizar a PassRole ação iam:, suas políticas devem ser atualizadas para permitir que você passe uma função para o RES.

Alguns AWS serviços permitem que você passe uma função existente para esse serviço em vez de criar uma nova função de serviço ou uma função vinculada ao serviço. Para fazer isso, é preciso ter permissões para passar o perfil para o serviço.

O exemplo de erro a seguir ocorre quando um usuário do IAM chamado marymajor tenta usar o console para realizar uma ação no RES. No entanto, a ação exige que o serviço tenha permissões concedidas por um perfil de serviço. Mary não tem permissões para passar o perfil para o serviço.

User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole

Nesse caso, as políticas de Mary devem ser atualizadas para permitir que ela execute a PassRole ação iam:. Se precisar de ajuda, entre em contato com seu AWS administrador. Seu administrador é a pessoa que forneceu suas credenciais de login.

........................

Quero permitir que pessoas fora da minha AWS conta acessem meu estúdio de pesquisa e engenharia sobre AWS recursos

É possível criar um perfil que os usuários de outras contas ou pessoas fora da sua organização podem usar para acessar seus recursos. É possível especificar quem é confiável para assumir o perfil. Para serviços que oferecem suporte a políticas baseadas em recursos ou listas de controle de acesso (ACLs), você pode usar essas políticas para conceder às pessoas acesso aos seus recursos.

Para saber mais, consulte:

........................

Ao fazer login no ambiente, eu volto imediatamente para a página de login

Esse problema ocorre quando sua integração de SSO está configurada incorretamente. Para determinar o problema, verifique os registros da instância do controlador e verifique se há erros nas configurações.

Para verificar os registros:

  1. Abra o console de CloudWatch .

  2. Em Grupos de registros, encontre o grupo chamado/<environment-name>/cluster-manager.

  3. Abra o grupo de registros para pesquisar erros nos fluxos de registros.

Para verificar as configurações:

  1. Abra o console do DynamoDB

  2. Em Tabelas, encontre a tabela chamada<environment-name>.cluster-settings.

  3. Abra a tabela e escolha Explorar itens da tabela.

  4. Expanda a seção de filtros e insira as seguintes variáveis:

    • Nome do atributo — chave

    • Condição — contém

    • Valor — sso

  5. Escolha Executar.

  6. Na string retornada, verifique se os valores de configuração do SSO estão corretos. Se estiverem incorretos, altere o valor da chave sso_enabled para False.

    O console do DynamoDB com a tela Editar item para o valor da chave sso_enabled.

  7. Retorne à interface de usuário do RES para reconfigurar o SSO.

........................

Erro “Usuário não encontrado” ao tentar fazer login

Se um usuário receber o erro “Usuário não encontrado” ao tentar fazer login na interface RES e estiver presente no Active Directory:

  • Se o usuário não estiver presente no RES e você o tiver adicionado recentemente ao AD

    • É possível que o usuário ainda não esteja sincronizado com o RES. O RES sincroniza de hora em hora, então talvez seja necessário esperar e verificar se o usuário foi adicionado após a próxima sincronização. Para sincronizar imediatamente, siga as etapas emUsuário adicionado no Active Directory, mas ausente do RES.

  • Se o usuário estiver presente no RES:

    1. Certifique-se de que o mapeamento de atributos esteja configurado corretamente. Para obter mais informações, consulte Configurando seu provedor de identidade para login único () SSO.

    2. Certifique-se de que o assunto do SAML e o e-mail do SAML sejam mapeados para o endereço de e-mail do usuário.

........................

Usuário adicionado no Active Directory, mas ausente do RES

nota

Esta seção se aplica ao RES 2024.10 e versões anteriores. Para RES 2024.12 e versões posteriores, consulte. Como executar manualmente a sincronização (versão 2024.12 e posterior)

Se você adicionou um usuário ao Active Directory, mas ele está ausente no RES, a sincronização do AD precisa ser acionada. A sincronização do AD é realizada de hora em hora por uma função Lambda que importa entradas do AD para o ambiente RES. Ocasionalmente, há um atraso até que o próximo processo de sincronização seja executado após a adição de novos usuários ou grupos. Você pode iniciar a sincronização manualmente a partir do Amazon Simple Queue Service.

Inicie o processo de sincronização manualmente:

  1. Abra o console do Amazon SQS.

  2. Em Filas, selecione<environment-name>-cluster-manager-tasks.fifo.

  3. Escolha Enviar e receber mensagens.

  4. Em Corpo da mensagem, digite:

    { "name": "adsync.sync-from-ad", "payload": {} }

  5. Em ID do grupo de mensagens, digite: adsync.sync-from-ad

  6. Em ID de desduplicação de mensagens, insira uma sequência de caracteres alfanumérica aleatória. Essa entrada deve ser diferente de todas as chamadas feitas nos últimos cinco minutos ou a solicitação será ignorada.

........................

Usuário indisponível ao criar uma sessão

Se você for um administrador criando uma sessão, mas descobrir que um usuário que está no Active Directory não está disponível ao criar uma sessão, talvez o usuário precise fazer login pela primeira vez. As sessões só podem ser criadas para usuários ativos. Os usuários ativos devem fazer login no ambiente pelo menos uma vez.

........................

Erro de limite de tamanho excedido no log do gerenciador de CloudWatch clusters

2023-10-31T18:03:12.942-07:00 ldap.SIZELIMIT_EXCEEDED: {'msgtype': 100, 'msgid': 11, 'result': 4, 'desc': 'Size limit exceeded', 'ctrls': []}

Se você receber esse erro no log do CloudWatch gerenciador de cluster, a pesquisa ldap pode ter retornado muitos registros de usuário. Para corrigir esse problema, aumente o limite de resultados de pesquisa ldap do seu IDP.

........................

Armazenamento

........................

Eu criei o sistema de arquivos por meio do RES, mas ele não é montado nos hosts VDI

Os sistemas de arquivos precisam estar no estado “Disponível” antes de poderem ser montados por hosts VDI. Siga as etapas abaixo para validar se o sistema de arquivos está no estado necessário.

Amazon EFS

  1. Acesse o console do Amazon EFS.

  2. Verifique se o estado do sistema de arquivos está Disponível.

  3. Se o estado do sistema de arquivos não estiver Disponível, aguarde antes de iniciar os hosts VDI.

Amazon FSx ONTAP

  1. Acesse o FSx console da Amazon.

  2. Verifique se o status está disponível.

  3. Se o status não estiver disponível, aguarde antes de iniciar os hosts VDI.

........................

Eu integrei um sistema de arquivos por meio do RES, mas ele não é montado nos hosts VDI

Os sistemas de arquivos integrados ao RES devem ter as regras de grupo de segurança necessárias configuradas para permitir que os hosts VDI montem os sistemas de arquivos. Como esses sistemas de arquivos são criados externamente ao RES, o RES não gerencia as regras de grupo de segurança associadas.

O grupo de segurança associado aos sistemas de arquivos integrados deve permitir o seguinte tráfego de entrada:

  • Tráfego NFS (porta: 2049) dos hosts Linux VDC

  • Tráfego SMB (porta: 445) dos hosts VDC do Windows

........................

Não consigo ler/gravar em hosts VDI

O ONTAP suporta os estilos de segurança UNIX, NTFS e MIXED para os volumes. Os estilos de segurança determinam o tipo de permissões que o ONTAP usa para controlar o acesso aos dados e qual tipo de cliente pode modificar essas permissões.

Por exemplo, se um volume usa o estilo de segurança UNIX, os clientes SMB ainda podem acessar dados (desde que sejam autenticados e autorizados adequadamente) devido à natureza multiprotocolo do ONTAP. No entanto, o ONTAP usa permissões UNIX que somente clientes UNIX podem modificar usando ferramentas nativas.

Exemplos de casos de uso de tratamento de permissões

Usando volume no estilo UNIX com cargas de trabalho Linux

As permissões podem ser configuradas pelo sudoer para outros usuários. Por exemplo, o seguinte daria a todos os membros permissões <group-ID> completas de leitura/gravação no /<project-name> diretório:

sudo chown root:<group-ID> /<project-name>
sudo chmod 770 /<project-name>

Usando o volume no estilo NTFS com cargas de trabalho do Linux e do Windows

As permissões de compartilhamento podem ser configuradas usando as propriedades de compartilhamento de uma pasta específica. Por exemplo, considerando um usuário user_01 e uma pastamyfolder, você pode definir permissões de Full ControlChange, ou Read para Allow ouDeny:

As permissões de compartilhamento podem ser definidas como Permitir ou Negar para Controle Total, Alteração ou Leitura

Se o volume for usado por clientes Linux e Windows, precisamos configurar um mapeamento de nomes no SVM que associará qualquer nome de usuário Linux ao mesmo nome de usuário com o formato de nome de domínio NetBIOS de domínio\ nome de usuário. Isso é necessário para traduzir entre usuários do Linux e do Windows. Para referência, consulte Habilitando cargas de trabalho multiprotocolo com a Amazon FSx para NetApp ONTAP.

........................

Eu criei o Amazon FSx for NetApp ONTAP a partir do RES, mas ele não se juntou ao meu domínio

Atualmente, quando você cria o Amazon FSx for NetApp ONTAP a partir do console RES, o sistema de arquivos é provisionado, mas não se junta ao domínio. Para unir o SVM do sistema de arquivos ONTAP criado ao seu domínio, consulte SVMs Ingressar em um Microsoft Active Directory e siga as etapas no console da Amazon FSx . Certifique-se de que as permissões necessárias sejam delegadas à conta de FSx serviços da Amazon no AD. Depois que o SVM ingressar no domínio com sucesso, vá para Sumário do SVM > Endpoints > Nome DNS SMB e copie o nome DNS porque você precisará dele posteriormente.

Depois de ingressar no domínio, edite a chave de configuração do SMB DNS na tabela de configurações do cluster do DynamoDB:

  1. Acesse o console do Amazon DynamoDB.

  2. Escolha Tabelas e, em seguida, escolha<stack-name>-cluster-settings.

  3. Em Explorar itens da tabela, expanda Filtros e insira o seguinte filtro:

    • Nome do atributo - chave

    • Condição - Igual a

    • Valor - shared-storage.<file-system-name>.fsx_netapp_ontap.svm.smb_dns

  4. Selecione o item devolvido, depois Ações, Editar item.

  5. Atualize o valor com o nome DNS SMB que você copiou anteriormente.

  6. Escolha Save and close.

Além disso, garanta que o grupo de segurança associado ao sistema de arquivos permita o tráfego conforme recomendado no Controle de acesso ao sistema de arquivos com a Amazon VPC. Os novos hosts VDI que usam o sistema de arquivos agora poderão montar o SVM e o sistema de arquivos unidos ao domínio.

Como alternativa, você pode integrar um sistema de arquivos existente que já esteja associado ao seu domínio usando o recurso RES Onboard File System - em Gerenciamento de ambiente, escolha Sistemas de arquivos, Sistema de arquivos integrado.

........................

Snapshots

........................

Um Snapshot tem um status de Falha

Na página RES Snapshots, se um snapshot tiver o status Falha, a causa pode ser determinada acessando o grupo de CloudWatch log da Amazon do gerenciador de cluster no momento em que o erro ocorreu.

[2023-11-19 03:39:20,208] [INFO] [snapshots-service] creating snapshot in S3 Bucket:
  asdf at path s31
[2023-11-19 03:39:20,381] [ERROR] [snapshots-service] An error occurred while
  creating the snapshot: An error occurred (TableNotFoundException)
  when calling the UpdateContinuousBackups operation: 
  Table not found: res-demo.accounts.sequence-config

........................

Falha na aplicação de um Snapshot com registros indicando que as tabelas não puderam ser importadas.

Se um instantâneo tirado de um ambiente anterior não for aplicado em um novo ambiente, consulte os CloudWatch registros do cluster-manager para identificar o problema. Se o problema mencionar que a nuvem de tabelas necessária não foi importada, verifique se o instantâneo está em um estado válido.

  1. Faça o download do arquivo metadata.json e verifique se o status das ExportStatus várias tabelas está concluído. Certifique-se de que as várias tabelas tenham o ExportManifest campo definido. Se você não encontrar o conjunto de campos acima, o instantâneo está em um estado inválido e não pode ser usado com a funcionalidade de aplicar instantâneo.

  2. Depois de iniciar a criação de um instantâneo, certifique-se de que o status do instantâneo mude para CONCLUÍDO em RES. O processo de criação do Snapshot leva de 5 a 10 minutos. Recarregue ou visite novamente a página de gerenciamento de instantâneos para garantir que o instantâneo tenha sido criado com sucesso. Isso garantirá que o instantâneo criado esteja em um estado válido.

........................

Infraestrutura

........................

Grupos-alvo do balanceador de carga sem instâncias íntegras

Se problemas como mensagens de erro do servidor aparecerem na interface do usuário ou se as sessões de desktop não conseguirem se conectar, isso pode indicar um problema nas EC2 instâncias de infraestrutura da Amazon.

Os métodos para determinar a origem do problema são primeiro verificar se há EC2 instâncias da Amazon no EC2 console da Amazon que pareçam estar sendo encerradas repetidamente e substituídas por novas instâncias. Se for esse o caso, verificar os CloudWatch registros da Amazon pode determinar a causa.

Outro método é verificar os balanceadores de carga no sistema. Uma indicação de que pode haver problemas no sistema é se algum balanceador de carga encontrado no EC2 console da Amazon não mostrar nenhuma instância íntegra registrada.

Um exemplo de aparência normal é mostrado aqui:

Painel de balanceadores de carga ec2

Se a entrada Healthy for 0, isso indica que nenhuma EC2 instância da Amazon está disponível para processar solicitações.

Se a entrada Não íntegra for diferente de 0, isso indica que uma EC2 instância da Amazon pode estar circulando. Isso pode ser devido ao fato de o software do aplicativo instalado não passar pelas verificações de saúde.

Se as entradas íntegras e não íntegras forem 0, isso indica uma possível configuração incorreta da rede. Por exemplo, as sub-redes pública e privada podem não ter correspondências. AZs Se essa condição ocorrer, pode haver texto adicional no console indicando que o estado da rede existe.

........................

Lançamento de desktops virtuais

........................

O certificado expira ao usar um recurso externo CertificateRenewalNode

Se você implantou a receita de Recursos Externos e encontrar um erro que aparece "The connection has been closed. Transport error" ao se conectar ao Linux VDIs, a causa mais provável é um certificado expirado que não está sendo atualizado automaticamente devido a um caminho de instalação incorreto do pip no Linux. Os certificados expiram após 3 meses.

O grupo de CloudWatch registros da Amazon <envname>/vdc/dcv-connection-gateway pode registrar o erro de tentativa de conexão com mensagens semelhantes às seguintes:

| 2024-07-29T21:46:02.651Z | Jul 29 21:46:01.702  WARN HTTP:Splicer Connection{id=341 client_address="x.x.x.x:50682"}: Error in connection task: TLS handshake error: received fatal alert: CertificateUnknown | redacted:/res-demo/vdc/dcv-connection-gateway | dcv-connection-gateway_10.3.146.195 |
| 2024-07-29T21:46:02.651Z | Jul 29 21:46:01.702  WARN HTTP:Splicer Connection{id=341 client_address="x.x.x.x:50682"}: Certificate error: AlertReceived(CertificateUnknown) | redacted:/res-demo/vdc/dcv-connection-gateway | dcv-connection-gateway_10.3.146.195 |
Como resolver o problema:

  1. Na sua AWS conta, acesse EC2. Se houver uma instância chamada*-CertificateRenewalNode-*, encerre-a.

  2. Vá para Lambda. Você deve ver uma função Lambda chamada*-CertificateRenewalLambda-*, verifique o código Lambda para algo semelhante ao seguinte:

    export HOME=/tmp/home
mkdir -p $HOME

cd /tmp
wget https://bootstrap.pypa.io/pip/3.7/get-pip.py 
python3 ./get-pip.py
pip3 install boto3
eval $(python3 -c "from botocore.credentials import InstanceMetadataProvider, InstanceMetadataFetcher; provider = InstanceMetadataProvider(iam_role_fetcher=InstanceMetadataFetcher(timeout=1000, num_attempts=2)); c = provider.load().get_frozen_credentials(); print(f'export AWS_ACCESS_KEY_ID={c.access_key}'); print(f'export AWS_SECRET_ACCESS_KEY={c.secret_key}'); print(f'export AWS_SESSION_TOKEN={c.token}')")

mkdir certificates
cd certificates
git clone https://github.com/Neilpang/acme.sh.git
cd acme.sh

  3. Encontre o modelo de pilha de certificados de recursos externos mais recente aqui. Encontre o código Lambda no modelo: Recursos → → Propriedades CertificateRenewalLambda→ Código. Você pode encontrar algo semelhante ao seguinte:

    sudo yum install -y wget
export HOME=/tmp/home
mkdir -p $HOME
cd /tmp
wget https://bootstrap.pypa.io/pip/3.7/get-pip.py
mkdir -p pip
python3 ./get-pip.py --target $PWD/pip
$PWD/pip/bin/pip3 install boto3
eval $(python3 -c "from botocore.credentials import InstanceMetadataProvider, InstanceMetadataFetcher; provider = InstanceMetadataProvider(iam_role_fetcher=InstanceMetadataFetcher(timeout=1000, num_attempts=2)); c = provider.load().get_frozen_credentials(); print(f'export AWS_ACCESS_KEY_ID={c.access_key}'); print(f'export AWS_SECRET_ACCESS_KEY={c.secret_key}'); print(f'export AWS_SESSION_TOKEN={c.token}')")

mkdir certificates
cd certificates
VERSION=3.1.0
wget https://github.com/acmesh-official/acme.sh/archive/refs/tags/$VERSION.tar.gz -O acme-$VERSION.tar.gz
tar -xvf acme-$VERSION.tar.gz
cd acme.sh-$VERSION

  4. Substitua a seção da Etapa 2 na função *-CertificateRenewalLambda-* Lambda pelo código da Etapa 3. Selecione Implantar e aguarde até que a alteração do código entre em vigor.

  5. Para acionar manualmente a função Lambda, acesse a guia Teste e selecione Teste. Nenhuma entrada adicional é necessária. Isso deve criar uma EC2 instância de certificado que atualize o certificado e PrivateKey os segredos no Secret Manager.

  6. Encerre a instância existente do dcv-gateway: <env-name>-vdc-gateway e espere que o grupo de auto scaling implante automaticamente uma nova.

........................

Um desktop virtual que estava funcionando anteriormente não consegue mais se conectar com êxito

Se uma conexão de desktop for fechada ou você não puder mais se conectar a ela, o problema pode ser devido à falha da EC2 instância Amazon subjacente ou a instância da Amazon EC2 pode ter sido encerrada ou interrompida fora do ambiente RES. O status da interface do usuário do administrador pode continuar mostrando um estado pronto, mas as tentativas de se conectar a ele falham.

O Amazon EC2 Console deve ser usado para determinar se a instância foi encerrada ou interrompida. Se parar, tente iniciá-lo novamente. Se o estado for encerrado, outra área de trabalho precisará ser criada. Todos os dados armazenados no diretório inicial do usuário ainda devem estar disponíveis quando a nova instância for iniciada.

Se a instância que falhou anteriormente ainda aparecer na interface do administrador, talvez ela precise ser encerrada usando a interface do administrador.

........................

Só consigo iniciar 5 desktops virtuais

O limite padrão para o número de desktops virtuais que um usuário pode iniciar é 5. Isso pode ser alterado por um administrador usando a interface de usuário do administrador da seguinte forma:

  • Vá para Configurações da área de trabalho.

  • Selecione a guia Servidor.

  • No painel DCV Session, clique no ícone de edição à direita.

  • Altere o valor em Sessões permitidas por usuário para o novo valor desejado.

  • Selecione Enviar.

  • Atualize a página para confirmar se a nova configuração está em vigor.

........................

As tentativas de conexão do Windows para desktop falham com “A conexão foi fechada”. Erro de transporte”

Se uma conexão de desktop do Windows falhar com o erro de interface do usuário “A conexão foi fechada. Erro de transporte”, a causa pode ser devido a um problema no software do servidor DCV relacionado à criação de certificados na instância do Windows.

O grupo de CloudWatch registros da Amazon <envname>/vdc/dcv-connection-gateway pode registrar o erro de tentativa de conexão com mensagens semelhantes às seguintes:

Nov 24 20:24:27.631 DEBUG HTTP:Splicer Connection{id=9}:
Websocket{session_id="1291e75f-7816-48d9-bbb2-7371b3b911cd"}:
Resolver lookup{client_ip=Some(52.94.36.19) 
session_id="1291e75f-7816-48d9-bbb2-7371b3b911cd"
 protocol_type=WebSocket extension_data=None}:NoStrictCertVerification: 
 Additional stack certificate (0): [s/n: 0E9E9C4DE7194B37687DC4D2C0F5E94AF0DD57E]

Nov 24 20:25:15.384  INFO HTTP:Splicer Connection{id=21}:Websocket{
session_id="d1d35954-f29d-4b3f-8c23-6a53303ebc3f"}: 
Connection initiated error: unreachable, server io error Custom { 
kind: InvalidData, error:
General("Invalid certificate: certificate has expired (code: 10)") }

Nov 24 20:25:15.384  WARN HTTP:Splicer Connection{id=21}:
Websocket{session_id="d1d35954-f29d-4b3f-8c23-6a53303ebc3f"}: 
Error in websocket connection: Server unreachable: Server error: IO error: 
unexpected error: Invalid certificate: certificate has expired (code: 10)

Se isso ocorrer, uma solução pode ser usar o SSM Session Manager para abrir uma conexão com a instância do Windows e remover os dois arquivos relacionados ao certificado a seguir:

PS C:\Windows\system32\config\systemprofile\AppData\Local\NICE\dcv> dir

    Directory: C:\Windows\system32\config\systemprofile\AppData\Local\NICE\dcv


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----         8/4/2022  12:59 PM           1704 dcv.key
-a----         8/4/2022  12:59 PM           1265 dcv.pem

Os arquivos devem ser recriados automaticamente e uma tentativa de conexão subsequente pode ser bem-sucedida.

Se esse método resolver o problema e se novas inicializações de desktops Windows produzirem o mesmo erro, use a função Criar pilha de software para criar uma nova pilha de software Windows da instância fixa com os arquivos de certificado regenerados. Isso pode produzir uma pilha de software do Windows que pode ser usada para lançamentos e conexões bem-sucedidos.

........................

VDIs preso no estado de aprovisionamento

Se a inicialização de um desktop permanecer no estado de provisionamento na interface do usuário do administrador, isso pode ser devido a vários motivos.

Para determinar a causa, examine os arquivos de log na instância de desktop e procure erros que possam estar causando o problema. Este documento contém uma lista de arquivos de log e grupos de CloudWatch log da Amazon que contêm informações relevantes na seção Fontes úteis de informações de registros e eventos.

A seguir estão as possíveis causas desse problema.

  • O ID da AMI usado foi registrado como uma pilha de software, mas não é suportado pelo RES.

    O script de provisionamento de bootstrap não foi concluído porque a Amazon Machine Image (AMI) não tem a configuração esperada nem as ferramentas necessárias. Os arquivos de log na instância, como /root/bootstrap/logs/ em uma instância Linux, podem conter informações úteis sobre isso. AMIs IDs retirados do AWS Marketplace podem não funcionar para instâncias de desktop RES. Eles precisam de testes para confirmar se são compatíveis.

  • Os scripts de dados do usuário não são executados quando a instância de desktop virtual do Windows é iniciada a partir de uma AMI personalizada.

    Por padrão, os scripts de dados do usuário são executados uma vez quando uma EC2 instância da Amazon é iniciada. Se você criar uma AMI a partir de uma instância de desktop virtual existente, depois registrar uma pilha de software na AMI e tentar iniciar outro desktop virtual com essa pilha de software, os scripts de dados do usuário não serão executados na nova instância de desktop virtual.

    Para corrigir o problema, abra uma janela de PowerShell comando como administrador na instância de desktop virtual original que você usou para criar a AMI e execute o seguinte comando: 

    C:\ProgramData\Amazon\EC2-Windows\Launch\Scripts\InitializeInstance.ps1 –Schedule

    Em seguida, crie uma nova AMI a partir da instância. Você pode usar a nova AMI para registrar pilhas de software e depois iniciar novos desktops virtuais. Observe que você também pode executar o mesmo comando na instância que permanece no estado de provisionamento e reinicializar a instância para corrigir a sessão da área de trabalho virtual, mas terá o mesmo problema novamente ao iniciar outra área de trabalho virtual a partir da AMI configurada incorretamente.

........................

VDIs entrar em estado de erro após o lançamento

Possível problema 1: O sistema de arquivos inicial tem um diretório para o usuário com diferentes permissões POSIX.

Esse pode ser o problema que você enfrentará se os seguintes cenários forem verdadeiros:

  1. A versão RES implantada é 2024.01 ou superior.

  2. Durante a implantação da pilha RES, o atributo for EnableLdapIDMapping foi definido como. True

  3. O sistema de arquivos inicial especificado durante a implantação da pilha RES foi usado na versão anterior ao RES 2024.01 ou foi usado em um ambiente anterior com definido como. EnableLdapIDMapping False

Etapas de resolução: exclua os diretórios do usuário no sistema de arquivos.

  1. SSM para o host do gerenciador de clusters.

  2. cd /home.

  3. ls- deve listar diretórios com nomes de diretórios que correspondam aos nomes de usuário, comoadmin1,admin2.. e assim por diante.

  4. Exclua os diretórios,sudo rm -r 'dir_name'. Não exclua os diretórios ssm-user e ec2-user.

  5. Se os usuários já estiverem sincronizados com o novo ambiente, exclua os usuários da tabela DDB do usuário (exceto clusteradmin).

  6. Inicie a sincronização do AD - execute sudo /opt/idea/python/3.9.16/bin/resctl ldap sync-from-ad no gerenciador de clusters Amazon. EC2

  7. Reinicialize a instância VDI no Error estado a partir da página da web do RES. Valide se o VDI faz a transição para o Ready estado em cerca de 20 minutos.

........................

Componente de desktop virtual

........................

A EC2 instância da Amazon está sendo exibida repetidamente encerrada no console

Se uma instância de infraestrutura for exibida repetidamente como encerrada no EC2 console da Amazon, a causa pode estar relacionada à sua configuração e depender do tipo de instância de infraestrutura. A seguir estão os métodos para determinar a causa.

Se a instância vdc-controller mostrar estados encerrados repetidos no EC2 console da Amazon, isso pode ser devido a uma tag secreta incorreta. Os segredos mantidos pelo RES têm tags que são usadas como parte das políticas de controle de acesso do IAM anexadas às EC2 instâncias de infraestrutura da Amazon. Se o controlador vdc estiver circulando e o erro a seguir aparecer no grupo de CloudWatch registros, a causa pode ser que um segredo não tenha sido marcado corretamente. Observe que o segredo precisa ser marcado com o seguinte:

{
    "res:EnvironmentName": "<envname>" # e.g. "res-demo"
    "res:ModuleName": "virtual-desktop-controller"
}

A mensagem de CloudWatch log da Amazon para esse erro será semelhante à seguinte:

An error occurred (AccessDeniedException) when calling the GetSecretValue
operation: User: arn:aws:sts::160215750999:assumed-role/<envname>-vdc-gateway-role-us-east-1/i-043f76a2677f373d0 
is not authorized to perform: secretsmanager:GetSecretValue on resource:
arn:aws:secretsmanager:us-east-1:160215750999:secret:Certificate-res-bi-Certs-5W9SPUXF08IB-F1sNRv 
because no identity-based policy allows the secretsmanager:GetSecretValue action

Verifique as tags na EC2 instância da Amazon e confirme se elas correspondem à lista acima.

........................

A instância vdc-controller está circulando devido à falha na junção do módulo AD/eVDI e mostra Failed API Health Check

Se o módulo eVDI estiver falhando na verificação de integridade, ele mostrará o seguinte na seção Status do ambiente.

um exemplo dos módulos do ambiente e do painel de status

Nesse caso, o caminho geral para a depuração é examinar os registros do gerenciador de clusters. CloudWatch (Procure o grupo de registros chamado<env-name>/cluster-manager.)

Possíveis problemas:

  • Se os registros contiverem o textoInsufficient permissions, verifique se o ServiceAccount nome de usuário fornecido quando a pilha de resolução foi criada está escrito corretamente.

    Exemplo de linha de registro:

    Insufficient permissions to modify computer account: CN=IDEA-586BD25043,OU=Computers,OU=RES,OU=CORP,DC=corp,DC=res,DC=com: 000020E7: AtrErr: DSID-03153943, #1: 0: 000020E7: DSID-03153943, problem 1005 (CONSTRAINT_ATT_TYPE), data 0, Att 90008 (userAccountControl):len 4 >> 432 ms - request will be retried in 30 seconds

    • Você pode acessar o ServiceAccount nome de usuário fornecido durante a implantação do RES a partir do SecretsManager console. Encontre o segredo correspondente no gerenciador de segredos e escolha Recuperar texto sem formatação. Se o nome de usuário estiver incorreto, escolha Editar para atualizar o valor secreto. Encerre as instâncias atuais do gerenciador de cluster e do controlador vdc. As novas instâncias surgirão em um estado estável.

    • O nome de usuário deve ser ServiceAccount "" se você estiver utilizando os recursos criados pela pilha de recursos externos fornecida. Se o DisableADJoin parâmetro foi definido como False durante a implantação do RES, certifique-se de que o usuário ServiceAccount "" tenha permissões para criar objetos de computador no AD.

  • Se o nome de usuário usado estiver correto, mas os registros contiverem o textoInvalid credentials, a senha digitada pode estar errada ou ter expirado.

    Exemplo de linha de registro:

    {'msgtype': 97, 'msgid': 1, 'result': 49, 'desc': 'Invalid credentials', 'ctrls': [], 'info': '80090308: LdapErr: DSID-0C090569, comment: AcceptSecurityContext error, data 532, v4563'}

    • Você pode ler a senha digitada durante a criação do ambiente acessando o segredo que armazena a senha no console do Secrets Manager. Selecione o segredo (por exemplo,<env_name>directoryserviceServiceAccountPassword) e escolha Recuperar texto sem formatação.

    • Se a senha no segredo estiver incorreta, escolha Editar para atualizar seu valor no segredo. Encerre as instâncias atuais do gerenciador de cluster e do controlador vdc. As novas instâncias usarão a senha atualizada e aparecerão em um estado estável.

    • Se a senha estiver correta, pode ser que a senha tenha expirado no Active Directory conectado. Você precisará primeiro redefinir a senha no Active Directory e depois atualizar o segredo. Você pode redefinir a senha do usuário no Active Directory a partir do console do Directory Service:

      1. Escolha a ID de diretório apropriada

      2. Escolha Ações, Redefinir senha do usuário e preencha o formulário com o nome de usuário (por exemplo, "ServiceAccount“) e a nova senha.

      3. Se a senha recém-definida for diferente da senha anterior, atualize a senha no segredo correspondente do Secret Manager (por exemplo,<env_name>directoryserviceServiceAccountPassword.

      4. Encerre as instâncias atuais do gerenciador de cluster e do controlador vdc. As novas instâncias surgirão em um estado estável.

........................

O projeto não aparece no menu suspenso ao editar a pilha de software para adicioná-lo

Esse problema pode estar relacionado ao seguinte problema associado à sincronização da conta do usuário com o AD. Se esse problema aparecer, verifique se o erro <user-home-init> account not available yet. waiting for user to be synced "" está no grupo de logs do gerenciador de clusters da CloudWatch Amazon para determinar se a causa é a mesma ou está relacionada.

........................

cluster-manager O registro CloudWatch da Amazon mostra “user-home-init< > conta ainda não disponível. Aguardando a sincronização do usuário” (onde a conta é um nome de usuário)

O assinante do SQS está ocupado e preso em um loop infinito porque não consegue acessar a conta do usuário. Esse código é acionado ao tentar criar um sistema de arquivos doméstico para um usuário durante a sincronização do usuário.

O motivo pelo qual ele não consegue acessar a conta do usuário pode ser que o RES não tenha sido configurado corretamente para o AD em uso. Um exemplo pode ser que o ServiceAccountCredentialsSecretArn parâmetro usado na criação do ambiente BI/RES não era o valor correto.

........................

A área de trabalho do Windows na tentativa de login diz “Sua conta foi desativada. Consulte seu administrador”

tela de erro da conta desativada

Se o usuário não conseguir fazer login novamente em uma tela bloqueada, isso pode indicar que o usuário foi desativado no AD configurado para RES após ter feito login com sucesso via SSO.

O login do SSO deve falhar se a conta do usuário tiver sido desativada no AD.

........................

Problemas de opções de DHCP com a configuração do AD externo/do cliente

Se você encontrar um erro informando "The connection has been closed. Transport error" sobre os desktops virtuais do Windows ao usar o RES com seu próprio Active Directory, verifique o CloudWatch log da dcv-connection-gateway Amazon em busca de algo semelhante ao seguinte:

Oct 28 00:12:30.626  INFO HTTP:Splicer Connection{id=263}:
Websocket{session_id="96cffa6e-cf2e-410f-9eea-6ae8478dc08a"}: Connection initiated error: unreachable, server io error Custom { kind: Uncategorized, error: "failed to lookup address information: Name or service not known" } 

Oct 28 00:12:30.626  WARN HTTP:Splicer Connection{id=263}: Websocket{session_id="96cffa6e-cf2e-410f-9eea-6ae8478dc08a"}: Error in websocket connection: Server unreachable: Server error: IO error: failed to lookup address information: Name or service not known
 
Oct 28 00:12:30.627 DEBUG HTTP:Splicer Connection{id=263}: ConnectionGuard dropped

Se você estiver usando um controlador de domínio AD para suas opções de DHCP para sua própria VPC, você precisará:

  1. Adicione o AmazonProvided DNS aos dois controladores IPs de domínio.

  2. Defina o nome do domínio como ec2.internal.

Um exemplo é mostrado aqui. Sem essa configuração, a área de trabalho do Windows exibirá um erro de transporte, porque o RES/DCV procura o nome de host ip-10-0-x-xx.ec2.internal.

exemplo de nome de domínio e servidores de nome de domínio

........................

Erro do Firefox MOZILLA_PKIX_ERROR_REQUIRED_TLS_FEATURE_MISSING

Ao usar o navegador Firefox, você pode encontrar a mensagem de erro do tipo MOZILLA_PKIX_ERROR_REQUIRED_TLS_FEATURE_MISSING ao tentar se conectar a uma área de trabalho virtual.

A causa é que o servidor web RES está configurado com TLS + Stapling On, mas não está respondendo com Stapling Validation (consulte https://support.mozilla). org/en-US/questions/1372483.

Você pode corrigir isso seguindo as instruções em: https://really-simple-ssl.com/mozilla_pkix_error_required_tls_feature_missing.

........................

Exclusão do ambiente

........................

res-xxx-cluster pilha no estado “DELETE_FAILED” e não pode ser excluída manualmente devido ao erro “A função é inválida ou não pode ser assumida”

Se você perceber que a pilha "res-xxx-cluster" está no estado “DELETE_FAILED” e não pode ser excluída manualmente, execute as etapas a seguir para excluí-la.

Se você ver a pilha no estado “DELETE_FAILED”, primeiro tente excluí-la manualmente. Pode aparecer uma caixa de diálogo confirmando Excluir pilha. Escolha Excluir.

tela pop-up de confirmação de exclusão da pilha

Às vezes, mesmo se você excluir todos os recursos necessários da pilha, ainda poderá ver a mensagem para selecionar os recursos a serem retidos. Nesse caso, selecione todos os recursos como “recursos a serem retidos” e escolha Excluir.

Você pode ver um erro que parece Role: arn:aws:iam::... is Invalid or cannot be assumed

CloudFormation janela de pilhas mostrando um erro de uma função inválida

Isso significa que a função necessária para excluir a pilha foi excluída primeiro, antes da pilha. Para contornar isso, copie o nome da função. Acesse o console do IAM e crie uma função com esse nome usando os parâmetros mostrados aqui, que são:

  • Para o tipo de entidade confiável, escolha AWS serviço.

  • Para Caso de uso, em Use cases for other AWS services EscolherCloudFormation.

A janela de criação de função do IAM Roles (etapa 1) permite que você selecione a entidade confiável.

Escolha Próximo. Certifique-se de conceder as permissões '' e AWSCloudFormationFullAccess 'AdministratorAccess' à função. Sua página de avaliação deve ter a seguinte aparência:

essa tela do IAM permite que você nomeie, revise e crie uma função

Em seguida, volte para o CloudFormation console e exclua a pilha. Agora você deve conseguir excluí-la desde que criou a função. Por fim, acesse o console do IAM e exclua a função que você criou.

........................

Coletando registros

Fazer login em uma EC2 instância a partir do EC2 console

  • Siga estas instruções para fazer login na sua EC2 instância Linux.

  • Siga estas instruções para fazer login na sua EC2 instância do Windows. Em seguida, abra PowerShell o Windows para executar qualquer comando.

Coletando registros do host da infraestrutura

  1. Gerenciador de cluster: obtenha registros do gerenciador de cluster nos seguintes locais e anexe-os ao ticket.

    1. Todos os registros do grupo de CloudWatch registros<env-name>/cluster-manager.

    2. Todos os registros no /root/bootstrap/logs diretório na <env-name>-cluster-manager EC2 instância. Siga as instruções vinculadas a “Fazer login em uma EC2 instância a partir do EC2 console” no início desta seção para fazer login na sua instância.

  2. Controlador VDC: obtenha os registros do controlador vdc nos seguintes locais e anexe-os ao ticket.

    1. Todos os registros do grupo de CloudWatch registros<env-name>/vdc-controller.

    2. Todos os registros no /root/bootstrap/logs diretório na <env-name>-vdc-controller EC2 instância. Siga as instruções vinculadas a “Fazer login em uma EC2 instância a partir do EC2 console” no início desta seção para fazer login na sua instância.

Uma das maneiras de obter os registros com facilidade é seguir as instruções na Baixando registros de EC2 instâncias Linux seção. O nome do módulo seria o nome da instância.

Coletando registros de VDI

Identifique a EC2 instância correspondente da Amazon

Se um usuário iniciasse uma VDI com o nome da sessãoVDI1, o nome correspondente da instância no EC2 console da Amazon seria<env-name>-VDI1-<user name>.

Colete registros de VDI do Linux

Faça login na EC2 instância correspondente da Amazon a partir do EC2 console da Amazon seguindo as instruções vinculadas em “Fazer login em uma EC2 instância a partir do EC2 console” no início desta seção. Obtenha todos os registros nos /var/log/dcv/ diretórios /root/bootstrap/logs e na instância VDI da Amazon EC2 .

Uma das maneiras de obter os registros seria enviá-los para o s3 e depois baixá-los de lá. Para isso, você pode seguir estas etapas para obter todos os registros de um diretório e, em seguida, carregá-los:

  1. Siga estas etapas para copiar os registros dcv no /root/bootstrap/logs diretório:

    sudo su - 
cd /root/bootstrap
mkdir -p logs/dcv_logs
cp -r /var/log/dcv/* logs/dcv_logs/

  2. Agora, siga as etapas listadas na próxima seção Baixando registros de VDI para baixar os registros.

Coletar registros de VDI do Windows

Faça login na EC2 instância correspondente da Amazon a partir do EC2 console da Amazon seguindo as instruções vinculadas em “Fazer login em uma EC2 instância a partir do EC2 console” no início desta seção. Obtenha todos os registros no $env:SystemDrive\Users\Administrator\RES\Bootstrap\Log\ diretório na EC2 instância da VDI.

Uma das maneiras de obter os registros seria enviá-los para o S3 e baixá-los de lá. Para fazer isso, siga as etapas listadas na próxima seção-Baixando registros de VDI.

........................

Baixando registros de VDI

  1. Atualize a função do IAM da EC2 instância de VDI para permitir o acesso ao S3.

  2. Acesse o EC2 console e selecione sua instância de VDI.

  3. Selecione a função do IAM que ele está usando.

  4. Na seção Políticas de permissão do menu suspenso Adicionar permissões, escolha Anexar políticas e selecione a política do FullAccessAmazonS3.

  5. Escolha Adicionar permissões para anexar essa política.

  6. Depois disso, siga as etapas listadas abaixo com base no seu tipo de VDI para baixar os registros. O nome do módulo seria o nome da instância.

    1. Baixando registros de EC2 instâncias Linuxpara Linux.

    2. Baixando registros de EC2 instâncias do Windowspara Windows.

  7. Por fim, edite a função para remover a AmazonS3FullAccess política.

nota

Todos VDIs usam a mesma função do IAM, que é <env-name>-vdc-host-role-<region>

........................

Baixando registros de EC2 instâncias Linux

Faça login na EC2 instância da qual você deseja baixar os registros e execute os seguintes comandos para carregar todos os registros em um bucket s3:

sudo su -
ENV_NAME=<environment_name>
REGION=<region>
ACCOUNT=<aws_account_number>
MODULE=<module_name>

cd /root/bootstrap
tar -czvf ${MODULE}_logs.tar.gz logs/ --overwrite
aws s3 cp ${MODULE}_logs.tar.gz s3://${ENV_NAME}-cluster-${REGION}-${ACCOUNT}/${MODULE}_logs.tar.gz

Depois disso, acesse o console do S3, selecione o bucket com o nome <environment_name>-cluster-<region>-<aws_account_number> e faça o download do <module_name>_logs.tar.gz arquivo carregado anteriormente.

........................

Baixando registros de EC2 instâncias do Windows

Faça login na EC2 instância da qual você deseja baixar os registros e execute os seguintes comandos para carregar todos os registros em um bucket do S3:

$ENV_NAME="<environment_name>"
$REGION="<region>"
$ACCOUNT="<aws_account_number>"
$MODULE="<module_name>"

$logDirPath = Join-Path -Path $env:SystemDrive -ChildPath "Users\Administrator\RES\Bootstrap\Log"
$zipFilePath = Join-Path -Path $env:TEMP -ChildPath "logs.zip"
Remove-Item $zipFilePath
Compress-Archive -Path $logDirPath -DestinationPath $zipFilePath
$bucketName = "${ENV_NAME}-cluster-${REGION}-${ACCOUNT}"
$keyName = "${MODULE}_logs.zip"
Write-S3Object -BucketName $bucketName -Key $keyName -File $zipFilePath

Depois disso, acesse o console do S3, selecione o bucket com o nome <environment_name>-cluster-<region>-<aws_account_number> e faça o download do <module_name>_logs.zip arquivo carregado anteriormente.

........................

Coletando registros do ECS para o erro WaitCondition

  1. Vá até a pilha implantada e selecione a guia Recursos.

  2. Expanda Implantar ResearchAndEngineeringStudio→ → Instalador CreateTaskDef→ Tarefas CreateContainer→ → LogGroupe selecione o grupo de registros para abrir CloudWatch os registros.

  3. Obtenha o registro mais recente desse grupo de registros.

........................

Ambiente de demonstração

........................

Erro de login no ambiente de demonstração ao lidar com a solicitação de autenticação ao provedor de identidade

Problema

Se você tentar fazer login e receber um “Erro inesperado ao processar a solicitação de autenticação para o provedor de identidade”, suas senhas podem ter expirado. Essa pode ser a senha do usuário com o qual você está tentando fazer login ou da sua Conta do Active Directory Service.

Mitigação

  1. Redefina as senhas do usuário e da conta de serviço no console do serviço de diretório.

  2. Atualize as senhas da Conta de Serviço no Secrets Manager para que correspondam à nova senha inserida acima:

    • para a pilha Keycloak: -... PasswordSecret - RESExternal-... - DirectoryService-... com descrição: Senha para o Microsoft Active Directory

    • para RES: res- ServiceAccountPassword -... com descrição: senha da conta do Active Directory Service

  3. Acesse o EC2 console e encerre a instância do gerenciador de cluster. As regras do Auto Scaling acionarão automaticamente a implantação de uma nova instância.

........................

O keycloak da pilha de demonstração não está funcionando

Problema

Se o servidor do keycloak travou e, quando você reiniciou o servidor, o IP da instância mudou, isso pode ter resultado na quebra do keycloak — a página de login do seu portal RES falha ao carregar ou fica presa em um estado de carregamento que nunca é resolvido.

Mitigação

Você precisará excluir a infraestrutura existente e reimplantar a pilha do Keycloak para restaurar o Keycloak a um estado saudável. Siga estas etapas:

  1. Acesse o Cloudformation. Você deve ver duas pilhas relacionadas ao keycloak lá:

    • <env-name>-RESSsoKeycloak-<random characters>(Pilha 1)

      <env-name>-RESSsoKeycloak-<random characters>-RESSsoKeycloak-*(Pilha 2)

  2. Exclua Stack1. Se solicitado a excluir a pilha aninhada, selecione Sim para excluir a pilha aninhada.

    Certifique-se de que a pilha tenha sido completamente excluída.

  3. Baixe o modelo de pilha RES SSO Keycloak aqui.

  4. Implante essa pilha manualmente com exatamente os mesmos valores de parâmetros da pilha excluída. Implante-o a partir do CloudFormation console acessando Criar pilha → Com novos recursos (padrão) → Escolha um modelo existente → Carregar um arquivo de modelo. Preencha os parâmetros necessários usando as mesmas entradas da pilha excluída. Você pode encontrar essas entradas na sua pilha excluída alterando o filtro no CloudFormation console e acessando a guia Parâmetros. Certifique-se de que o nome do ambiente, o key pair e outros parâmetros correspondam aos parâmetros originais da pilha.

  5. Depois que a pilha for implantada, seu ambiente estará pronto para ser usado novamente. Você pode encontrá-los ApplicationUrl na guia Saídas da pilha implantada.

........................