Problème RunBooks - Studio de recherche et d'ingénierie
Problèmes d'installationProblèmes liés à la gestion des identitésStockageInstantanésInfrastructureLancement de bureaux virtuelsComposant de bureau virtuelSuppression d'environnementsEnvironnement de démonstration

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Problème RunBooks

La section suivante décrit les problèmes susceptibles de survenir, explique comment les détecter et propose des suggestions pour les résoudre.

Problèmes d'installation

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

Je souhaite configurer des domaines personnalisés après avoir installé RES

Note

Conditions préalables : Vous devez stocker le certificat et PrivateKey son contenu dans un secret Secrets Manager avant d'effectuer ces étapes.

Ajouter des certificats au client Web

  1. Mettez à jour le certificat attaché à l'écouteur de l'équilibreur de charge external-alb :

    1. Accédez à l'équilibreur de charge externe RES dans la AWS console sous EC2> Équilibrage de charge > Équilibreurs de charge.

    2. Recherchez l'équilibreur de charge qui respecte la convention <env-name>-external-alb de dénomination.

    3. Vérifiez les écouteurs connectés à l'équilibreur de charge.

    4. Mettez à jour l'écouteur auquel est attaché un certificat SSL/TLS par défaut avec les détails du nouveau certificat.

    5. Enregistrez vos modifications.

  2. Dans le tableau des paramètres du cluster :

    1. Trouvez la table des paramètres du cluster dans DynamoDB -> Tables ->. <env-name>.cluster-settings

    2. Accédez à Explorer les éléments et filtrez par attribut : nom « clé », type « chaîne », condition « contient » et valeur « external_alb ».

    3. Réglé cluster.load_balancers.external_alb.certificates.provided sur True.

    4. Mettez à jour la valeur decluster.load_balancers.external_alb.certificates.custom_dns_name. Il s'agit du nom de domaine personnalisé pour l'interface utilisateur Web.

    5. Mettez à jour la valeur decluster.load_balancers.external_alb.certificates.acm_certificate_arn. Il s'agit de l'Amazon Resource Name (ARN) du certificat correspondant stocké dans Amazon Certificate Manager (ACM).

  3. Mettez à jour l'enregistrement de sous-domaine Route53 correspondant que vous avez créé pour votre client Web afin qu'il pointe vers le nom DNS de l'équilibreur de charge alb externe. <env-name>-external-alb

  4. Si l'authentification unique est déjà configurée dans l'environnement, reconfigurez l'authentification unique avec les mêmes entrées que celles que vous avez utilisées initialement depuis le bouton Paramètres généraux > Fournisseur d'identité > Authentification unique > État > Modifier du portail Web RES.

Ajoutez des certificats au VDIs

  1. Accordez à l'application RES l'autorisation d'effectuer une GetSecret opération sur le secret en ajoutant les balises suivantes au secret :

    • res:EnvironmentName : <env-name>

    • res:ModuleName : virtual-desktop-controller

  2. Dans le tableau des paramètres du cluster :

    1. Trouvez la table des paramètres du cluster dans DynamoDB -> Tables ->. <env-name>.cluster-settings

    2. Accédez à Explorer les éléments et filtrez par attribut : nom « clé », type « chaîne », condition « contient » et valeur « dcv_connection_gateway ».

    3. Réglé vdc.dcv_connection_gateway.certificate.provided sur True.

    4. Mettez à jour la valeur devdc.dcv_connection_gateway.certificate.custom_dns_name. Il s'agit du nom de domaine personnalisé pour l'accès VDI.

    5. Mettez à jour la valeur devdc.dcv_connection_gateway.certificate.certificate_secret_arn. Il s'agit de l'ARN du secret qui contient le contenu du certificat.

    6. Mettez à jour la valeur devdc.dcv_connection_gateway.certificate.private_key_secret_arn. Il s'agit de l'ARN du secret qui contient le contenu de la clé privée.

  3. Mettez à jour le modèle de lancement utilisé pour l'instance de passerelle :

    1. Ouvrez le groupe Auto Scaling dans la AWS console sous EC2> Auto Scaling > Auto Scaling Groups.

    2. Sélectionnez le groupe de mise à l'échelle automatique de la passerelle qui correspond à l'environnement RES. Le nom suit la convention de dénomination<env-name>-vdc-gateway-asg.

    3. Recherchez et ouvrez le modèle de lancement dans la section des détails.

    4. Sous Détails > Actions > choisissez Modifier le modèle (Créer une nouvelle version).

    5. Faites défiler l'écran vers le bas jusqu'à Détails avancés.

    6. Faites défiler l'écran jusqu'en bas, jusqu'à Données utilisateur.

    7. Recherchez les mots CERTIFICATE_SECRET_ARN etPRIVATE_KEY_SECRET_ARN. Mettez à jour ces valeurs avec les ARNs informations fournies aux secrets qui contiennent le contenu du certificat (voir étape 2.c) et de la clé privée (voir étape 2.d).

    8. Assurez-vous que le groupe Auto Scaling est configuré pour utiliser la version récemment créée du modèle de lancement (depuis la page du groupe Auto Scaling).

  4. Mettez à jour l'enregistrement de sous-domaine Route53 correspondant que vous avez créé pour vos bureaux virtuels afin qu'il pointe vers le nom DNS de l'équilibreur de charge nlb externe :. <env-name>-external-nlb

  5. Mettez fin à l'instance dcv-gateway existante : <env-name>-vdc-gateway et attendez qu'une nouvelle instance démarre.

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

AWS CloudFormation la pile ne parvient pas à être créée avec le message « message d'échec WaitCondition reçu ». Erreur : États. TaskFailed»

Pour identifier le problème, examinez le groupe de CloudWatch journaux Amazon nommé<stack-name>-InstallerTasksCreateTaskDefCreateContainerLogGroup<nonce>-<nonce>. S'il existe plusieurs groupes de journaux portant le même nom, examinez le premier groupe disponible. Un message d'erreur dans les journaux fournira plus d'informations sur le problème.

Note

Vérifiez que les valeurs des paramètres ne comportent pas d'espaces.

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

Notification par e-mail non reçue après la création AWS CloudFormation réussie des piles

Si aucune invitation par e-mail n'a été reçue après la création réussie des AWS CloudFormation piles, vérifiez les points suivants :

  1. Vérifiez que le paramètre d'adresse e-mail a été correctement saisi.

    Si l'adresse e-mail est incorrecte ou n'est pas accessible, supprimez et redéployez l'environnement Research and Engineering Studio.

  2. Consultez la EC2 console Amazon pour trouver des preuves de l'existence d'instances cycliques.

    Si certaines EC2 instances Amazon avec le <envname> préfixe apparaissent comme terminées puis sont remplacées par une nouvelle instance, il se peut qu'il y ait un problème avec le réseau ou la configuration d'Active Directory.

  3. Si vous avez déployé les recettes AWS High Performance Compute pour créer vos ressources externes, vérifiez que le VPC, les sous-réseaux privés et publics et les autres paramètres sélectionnés ont été créés par la pile.

    Si l'un des paramètres est incorrect, vous devrez peut-être supprimer et redéployer l'environnement RES. Pour de plus amples informations, veuillez consulter Désinstallez le produit.

  4. Si vous avez déployé le produit avec vos propres ressources externes, vérifiez que le réseau et Active Directory correspondent à la configuration attendue.

    Il est essentiel de confirmer que les instances d'infrastructure ont rejoint avec succès Active Directory. Essayez les étapes ci-dessous Instances en cycle ou contrôleur VDC en état d'échec pour résoudre le problème.

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

Instances en cycle ou contrôleur VDC en état d'échec

La cause la plus probable de ce problème est l'incapacité des ressources à se connecter ou à rejoindre Active Directory.

Pour vérifier le problème, procédez comme suit :

  1. À partir de la ligne de commande, démarrez une session avec SSM sur l'instance en cours d'exécution du vdc-controller.

  2. Exécutez sudo su -.

  3. Exécutez systemctl status sssd.

Si le statut est inactif, en échec ou si des erreurs apparaissent dans les journaux, cela signifie que l'instance n'a pas pu rejoindre Active Directory.

Journal des erreurs SSM

Journal des erreurs SSM

Pour résoudre le problème, procédez comme suit :

  • À partir de la même instance de ligne de commande, exécutez cat /root/bootstrap/logs/userdata.log pour examiner les journaux.

Le problème peut avoir l'une des trois causes profondes possibles.

Passez en revue les journaux. Si le message suivant se répète plusieurs fois, cela signifie que l'instance n'a pas pu rejoindre 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. Vérifiez que les valeurs des paramètres suivants ont été saisies correctement lors de la création de la pile RES.

    • directoryservice.ldap_connection_uri

    • directoryservice.ldap_base

    • directoryservice.users.ou

    • directoryservice.groups.ou

    • directoryservice.sudoers.ou

    • directoryservice.computers.ou

    • directoryservice.name

  2. Mettez à jour les valeurs incorrectes dans la table DynamoDB. La table se trouve dans la console DynamoDB sous Tables. Le nom de la table doit être<stack name>.cluster-settings.

  3. Après avoir mis à jour la table, supprimez le gestionnaire de clusters et le contrôleur vdc qui exécutent actuellement les instances de l'environnement. Auto Scaling démarrera de nouvelles instances en utilisant les dernières valeurs de la table DynamoDB.

Si les journaux sont renvoyésInsufficient permissions to modify computer account, le ServiceAccount nom saisi lors de la création de la pile est peut-être incorrect.

  1. Depuis la AWS console, ouvrez Secrets Manager.

  2. Recherchez directoryserviceServiceAccountUsername. Le secret devrait être<stack name>-directoryservice-ServiceAccountUsername.

  3. Ouvrez le secret pour afficher la page de détails. Sous Valeur secrète, choisissez Récupérer la valeur secrète, puis Texte en clair.

  4. Si la valeur a été mise à jour, supprimez les instances de cluster-manager et vdc-controller en cours d'exécution de l'environnement. Auto Scaling démarrera de nouvelles instances en utilisant la dernière valeur de Secrets Manager.

Si les journaux s'affichentInvalid credentials, le ServiceAccount mot de passe saisi lors de la création de la pile est peut-être incorrect.

  1. Depuis la AWS console, ouvrez Secrets Manager.

  2. Recherchez directoryserviceServiceAccountPassword. Le secret devrait être<stack name>-directoryservice-ServiceAccountPassword.

  3. Ouvrez le secret pour afficher la page de détails. Sous Valeur secrète, choisissez Récupérer la valeur secrète, puis Texte en clair.

  4. Si vous avez oublié le mot de passe ou si vous n'êtes pas certain que le mot de passe saisi est correct, vous pouvez le réinitialiser dans Active Directory et Secrets Manager.

    1. Pour réinitialiser le mot de passe dans AWS Managed Microsoft AD :

      1. Ouvrez la AWS console et accédez à AWS Directory Service.

      2. Sélectionnez l'ID de répertoire pour votre répertoire RES, puis choisissez Actions.

      3. Sélectionnez Réinitialiser le mot de passe utilisateur.

      4. Entrez le ServiceAccount nom d'utilisateur.

      5. Entrez un nouveau mot de passe, puis choisissez Réinitialiser le mot de passe.

    2. Pour réinitialiser le mot de passe dans Secrets Manager, procédez comme suit :

      1. Ouvrez la AWS console et accédez à Secrets Manager.

      2. Recherchez directoryserviceServiceAccountPassword. Le secret devrait être<stack name>-directoryservice-ServiceAccountPassword.

      3. Ouvrez le secret pour afficher la page de détails. Sous Valeur secrète, choisissez Récupérer la valeur secrète, puis choisissez Texte en clair.

      4. Choisissez Modifier.

      5. Définissez un nouveau mot de passe pour l' ServiceAccount utilisateur et choisissez Enregistrer.

  5. Si vous avez mis à jour la valeur, supprimez les instances de cluster-manager et vdc-controller actuellement en cours d'exécution dans l'environnement. La mise à l'échelle automatique démarrera les nouvelles instances en utilisant la dernière valeur.

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

La CloudFormation pile d'environnements ne parvient pas à être supprimée en raison d'une erreur d'objet dépendant

Si la suppression de la <env-name>-vdc CloudFormation pile échoue en raison d'une erreur d'objet dépendant telle que lavdcdcvhostsecuritygroup, cela peut être dû à une EC2 instance Amazon lancée dans un sous-réseau ou un groupe de sécurité créé par RES à l'aide de la AWS console.

Pour résoudre le problème, recherchez et mettez fin à toutes les EC2 instances Amazon lancées de cette manière. Vous pouvez ensuite reprendre la suppression de l'environnement.

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

Erreur rencontrée pour le paramètre de bloc CIDR lors de la création de l'environnement

Lors de la création d'un environnement, une erreur apparaît pour le paramètre de bloc CIDR avec un statut de réponse de [FAILED].

Exemple d'erreur : 

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.

Pour résoudre le problème, le format attendu est x.x.x.0/24 ou x.x.x.0/32.

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

CloudFormation échec de création de pile lors de la création de l'environnement

La création d'un environnement implique une série d'opérations de création de ressources. Dans certaines régions, un problème de capacité peut survenir et entraîner l'échec de la création d'une CloudFormation pile.

Dans ce cas, supprimez l'environnement et réessayez de le créer. Vous pouvez également réessayer la création dans une autre région.

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

La création d'une pile de ressources externes (démo) échoue avec AdDomainAdminNode CREATE_FAILED

Si la création de la pile d'environnement de démonstration échoue avec l'erreur suivante, cela peut être dû au fait que l'application de EC2 correctifs Amazon s'est produite de manière inattendue lors du provisionnement après le lancement de l'instance. 

AdDomainAdminNode CREATE_FAILED  Failed to receive 1 resource signal(s) within the specified duration
Pour déterminer la cause de l'échec, procédez comme suit :

  1. Dans le gestionnaire d'état SSM, vérifiez si les correctifs sont configurés et s'ils sont configurés pour toutes les instances.

  2. Dans l'historique d'exécution de RunCommand SSM/Automation, vérifiez si l'exécution d'un document SSM lié aux correctifs coïncide avec le lancement d'une instance.

  3. Dans les fichiers journaux des EC2 instances Amazon de l'environnement, consultez la journalisation des instances locales pour déterminer si l'instance a redémarré pendant le provisionnement.

Si le problème est dû à l'application de correctifs, retardez l'application des correctifs pour les instances RES au moins 15 minutes après le lancement.

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

Problèmes liés à la gestion des identités

La plupart des problèmes liés à l'authentification unique (SSO) et à la gestion des identités sont dus à une mauvaise configuration. Pour plus d'informations sur la configuration de votre configuration SSO, voir :

Pour résoudre d'autres problèmes liés à la gestion des identités, consultez les rubriques de résolution des problèmes suivantes :

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

Je ne suis pas autorisé à effectuer iam : PassRole

Si vous recevez un message d'erreur indiquant que vous n'êtes pas autorisé à exécuter l'PassRole action iam :, vos politiques doivent être mises à jour pour vous permettre de transmettre un rôle à RES.

Certains AWS services vous permettent de transmettre un rôle existant à ce service au lieu de créer un nouveau rôle de service ou un rôle lié à un service. Pour ce faire, un utilisateur doit disposer des autorisations nécessaires pour transmettre le rôle au service.

L'exemple d'erreur suivant se produit lorsqu'un utilisateur IAM nommé marymajor essaie d'utiliser la console pour effectuer une action dans RES. Toutefois, l’action nécessite que le service ait des autorisations accordées par un rôle de service. Mary ne dispose pas des autorisations nécessaires pour transférer le rôle au service.

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

Dans ce cas, les politiques de Mary doivent être mises à jour pour lui permettre d'effectuer l'PassRole action iam :. Si vous avez besoin d'aide, contactez votre AWS administrateur. Votre administrateur vous a fourni vos informations d’identification de connexion.

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

Je souhaite autoriser des personnes extérieures à mon AWS compte à accéder à mon studio de recherche et d'ingénierie sur les AWS ressources

Vous pouvez créer un rôle que les utilisateurs provenant d’autres comptes ou les personnes extérieures à votre organisation pourront utiliser pour accéder à vos ressources. Vous pouvez spécifier qui est autorisé à assumer le rôle. Pour les services qui prennent en charge les politiques basées sur les ressources ou les listes de contrôle d'accès (ACLs), vous pouvez utiliser ces politiques pour autoriser les utilisateurs à accéder à vos ressources.

Pour plus d’informations, consultez les éléments suivants :

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

Lorsque je me connecte à l'environnement, je reviens immédiatement à la page de connexion

Ce problème se produit lorsque votre intégration SSO est mal configurée. Pour déterminer le problème, consultez les journaux de l'instance du contrôleur et vérifiez que les paramètres de configuration ne contiennent pas d'erreurs.

Pour consulter les journaux :

  1. Ouvrez la CloudWatch console.

  2. Dans Groupes de journaux, recherchez le groupe nommé/<environment-name>/cluster-manager.

  3. Ouvrez le groupe de journaux pour rechercher d'éventuelles erreurs dans les flux de journaux.

Pour vérifier les paramètres de configuration, procédez comme suit :

  1. Ouvrez la console DynamoDB

  2. Dans Tables, recherchez la table nommée<environment-name>.cluster-settings.

  3. Ouvrez le tableau et choisissez Explorer les éléments du tableau.

  4. Développez la section des filtres et entrez les variables suivantes :

    • Nom de l'attribut — clé

    • État — contient

    • Valeur — SSO

  5. Cliquez sur Exécuter.

  6. Dans la chaîne renvoyée, vérifiez que les valeurs de configuration SSO sont correctes. S'ils sont incorrects, remplacez la valeur de la clé sso_enabled par False.

    La console DynamoDB avec l'écran Modifier un élément pour la valeur de la clé sso_enabled.

  7. Retournez à l'interface utilisateur RES pour reconfigurer le SSO.

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

Erreur « Utilisateur introuvable » lors de la tentative de connexion

Si un utilisateur reçoit le message d'erreur « Utilisateur introuvable » lorsqu'il essaie de se connecter à l'interface RES, alors que l'utilisateur est présent dans Active Directory :

  • Si l'utilisateur n'est pas présent dans RES et que vous l'avez récemment ajouté à AD

    • Il est possible que l'utilisateur ne soit pas encore synchronisé avec RES. RES se synchronise toutes les heures, vous devrez donc peut-être attendre et vérifier que l'utilisateur a été ajouté après la prochaine synchronisation. Pour synchroniser immédiatement, suivez les étapes décrites dansUtilisateur ajouté dans Active Directory, mais absent de RES.

  • Si l'utilisateur est présent dans RES :

    1. Assurez-vous que le mappage des attributs est correctement configuré. Pour de plus amples informations, veuillez consulter Configuration de votre fournisseur d'identité pour l'authentification unique () SSO.

    2. Assurez-vous que l'objet et l'e-mail SAML correspondent tous deux à l'adresse e-mail de l'utilisateur.

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

Utilisateur ajouté dans Active Directory, mais absent de RES

Note

Cette section s'applique à RES 2024.10 et versions antérieures. Pour RES 2024.12 et versions ultérieures, voir. Comment exécuter manuellement la synchronisation (version 2024.12 et versions ultérieures)

Si vous avez ajouté un utilisateur à Active Directory mais qu'il est absent de RES, la synchronisation AD doit être déclenchée. La synchronisation AD est effectuée toutes les heures par une fonction Lambda qui importe des entrées AD dans l'environnement RES. Parfois, il y a un délai avant l'exécution du prochain processus de synchronisation après l'ajout de nouveaux utilisateurs ou groupes. Vous pouvez lancer la synchronisation manuellement depuis le service Amazon Simple Queue.

Lancez le processus de synchronisation manuellement :

  1. Ouvrez la console Amazon SQS.

  2. Dans Files d'attente, sélectionnez<environment-name>-cluster-manager-tasks.fifo.

  3. Choisissez Envoyer et recevoir des messages.

  4. Dans le champ Corps du message, entrez :

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

  5. Pour l'ID du groupe de messages, entrez : adsync.sync-from-ad

  6. Pour l'ID de déduplication des messages, entrez une chaîne alphanumérique aléatoire. Cette entrée doit être différente de tous les appels effectués au cours des cinq minutes précédentes, sinon la demande sera ignorée.

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

Utilisateur non disponible lors de la création d'une session

Si vous êtes un administrateur qui crée une session, mais que vous constatez qu'un utilisateur figurant dans Active Directory n'est pas disponible lors de la création d'une session, il se peut que l'utilisateur doive se connecter pour la première fois. Les sessions ne peuvent être créées que pour les utilisateurs actifs. Les utilisateurs actifs doivent se connecter à l'environnement au moins une fois.

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

Erreur de dépassement de la limite de taille dans le journal du gestionnaire 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': []}

Si vous recevez cette erreur dans le journal du CloudWatch gestionnaire de clusters, la recherche LDAP a peut-être renvoyé trop d'enregistrements utilisateur. Pour résoudre ce problème, augmentez la limite de résultats de recherche LDAP de votre fournisseur de services Internet.

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

Stockage

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

J'ai créé le système de fichiers via RES mais il ne se monte pas sur les hôtes VDI

Les systèmes de fichiers doivent être dans l'état « Disponible » avant de pouvoir être montés par des hôtes VDI. Suivez les étapes ci-dessous pour vérifier que le système de fichiers est dans l'état requis.

Amazon EFS

  1. Accédez à la console Amazon EFS.

  2. Vérifiez que l'état du système de fichiers est disponible.

  3. Si l'état du système de fichiers n'est pas disponible, attendez avant de lancer les hôtes VDI.

Amazon FSx ONTAP

  1. Accédez à la FSx console Amazon.

  2. Vérifiez que le statut est disponible.

  3. Si le statut n'est pas disponible, attendez avant de lancer les hôtes VDI.

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

J'ai intégré un système de fichiers via RES mais il ne se monte pas sur les hôtes VDI

Les systèmes de fichiers intégrés à RES doivent avoir les règles de groupe de sécurité requises configurées pour permettre aux hôtes VDI de monter les systèmes de fichiers. Ces systèmes de fichiers étant créés en externe à RES, RES ne gère pas les règles de groupe de sécurité associées.

Le groupe de sécurité associé aux systèmes de fichiers intégrés doit autoriser le trafic entrant suivant :

  • Trafic NFS (port : 2049) depuis les hôtes Linux VDC

  • Trafic SMB (port : 445) depuis les hôtes Windows VDC

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

Je ne parviens pas à lire/écrire depuis les hôtes VDI

ONTAP prend en charge les styles de sécurité UNIX, NTFS et MIXED pour les volumes. Les styles de sécurité déterminent le type d'autorisations qu'ONTAP utilise pour contrôler l'accès aux données et le type de client qui peut modifier ces autorisations.

Par exemple, si un volume utilise le style de sécurité UNIX, les clients SMB peuvent toujours accéder aux données (à condition qu'ils s'authentifient et autorisent correctement) en raison de la nature multiprotocole d'ONTAP. ONTAP utilise toutefois des autorisations UNIX que seuls les clients UNIX peuvent modifier à l'aide d'outils natifs.

Exemples de cas d'utilisation relatifs à la gestion des autorisations

Utilisation d'un volume de style UNIX avec des charges de travail Linux

Les autorisations peuvent être configurées par le sudoer pour les autres utilisateurs. Par exemple, ce qui suit accorderait à tous les membres des autorisations <group-ID> complètes de lecture/écriture sur le /<project-name> répertoire :

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

Utilisation d'un volume de style NTFS avec des charges de travail Linux et Windows

Les autorisations de partage peuvent être configurées à l'aide des propriétés de partage d'un dossier spécifique. Par exemple, pour un utilisateur user_01 et un dossiermyfolder, vous pouvez définir des autorisations de Full ControlChange, ou Read pour Allow ou Deny :

Les autorisations de partage peuvent être définies sur Autoriser ou Refuser pour un contrôle total, une modification ou une lecture

Si le volume doit être utilisé à la fois par des clients Linux et Windows, nous devons configurer un mappage de noms sur la SVM qui associera tout nom d'utilisateur Linux au même nom d'utilisateur au format de nom de domaine NetBIOS de domaine \ nom d'utilisateur. Cela est nécessaire pour traduire entre les utilisateurs de Linux et de Windows. Pour référence, voir Activation des charges de travail multiprotocoles avec Amazon FSx pour NetApp ONTAP.

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

J'ai créé Amazon FSx pour NetApp ONTAP à partir de RES, mais il n'a pas rejoint mon domaine

Actuellement, lorsque vous créez Amazon FSx pour NetApp ONTAP à partir de la console RES, le système de fichiers est provisionné mais il ne rejoint pas le domaine. Pour associer la SVM du système de fichiers ONTAP créée à votre domaine, consultez Joindre SVMs à un Microsoft Active Directory et suivez les étapes indiquées sur la console Amazon FSx . Assurez-vous que les autorisations requises sont déléguées au compte Amazon FSx Service dans AD. Une fois que la SVM a rejoint le domaine avec succès, allez dans Résumé de la SVM > Points de terminaison > Nom DNS SMB, et copiez le nom DNS car vous en aurez besoin ultérieurement.

Une fois qu'elle est jointe au domaine, modifiez la clé de configuration DNS SMB dans le tableau DynamoDB des paramètres du cluster :

  1. Accédez à la console Amazon DynamoDB.

  2. Choisissez Tables, puis choisissez<stack-name>-cluster-settings.

  3. Sous Explorer les éléments du tableau, développez les filtres et entrez le filtre suivant :

    • Nom de l'attribut - clé

    • État - Égal à

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

  4. Sélectionnez l'article renvoyé, puis Actions, Modifier l'article.

  5. Mettez à jour la valeur avec le nom DNS SMB que vous avez copié précédemment.

  6. Choisissez Enregistrer et fermer.

En outre, assurez-vous que le groupe de sécurité associé au système de fichiers autorise le trafic conformément aux recommandations de la section Contrôle d'accès au système de fichiers avec Amazon VPC. Les nouveaux hôtes VDI qui utilisent le système de fichiers pourront désormais monter la SVM et le système de fichiers joints au domaine.

Vous pouvez également intégrer un système de fichiers existant déjà joint à votre domaine à l'aide de la fonctionnalité RES Onboard File System. Dans Gestion de l'environnement, choisissez Systèmes de fichiers, Système de fichiers intégré.

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

Instantanés

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

Un instantané a le statut Echoué

Sur la page RES Snapshots, si un instantané a le statut Echec, vous pouvez en déterminer la cause en accédant au groupe de CloudWatch journaux Amazon du gestionnaire de clusters au moment où l'erreur s'est produite.

[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

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

Un instantané ne s'applique pas avec des journaux indiquant que les tables n'ont pas pu être importées.

Si un instantané pris à partir d'un environnement précédent ne s'applique pas dans un nouvel environnement, consultez les CloudWatch journaux du gestionnaire de clusters pour identifier le problème. Si le problème indique que les tables requises ne peuvent pas être importées, vérifiez que l'instantané est dans un état valide.

  1. Téléchargez le fichier metadata.json et vérifiez que le ExportStatus statut des différentes tables est COMPLETED. Assurez-vous que le ExportManifest champ est défini dans les différentes tables. Si les champs ci-dessus ne sont pas définis, l'état de l'instantané n'est pas valide et ne peut pas être utilisé avec la fonctionnalité d'application d'un instantané.

  2. Après avoir lancé la création d'un instantané, assurez-vous que le statut de l'instantané passe à COMPLETED dans RES. Le processus de création d'un instantané prend de 5 à 10 minutes. Rechargez ou revisitez la page de gestion des instantanés pour vous assurer que le cliché a été créé avec succès. Cela garantira que l'instantané créé est dans un état valide.

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

Infrastructure

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

Groupes cibles d'équilibreur de charge dépourvus d'instances saines

Si des problèmes tels que des messages d'erreur du serveur apparaissent dans l'interface utilisateur ou si les sessions de bureau ne peuvent pas se connecter, cela peut indiquer un problème dans l'infrastructure EC2 des instances Amazon.

Les méthodes permettant de déterminer la source du problème consistent à vérifier d'abord dans la EC2 console Amazon la présence d' EC2 instances Amazon qui semblent se terminer à plusieurs reprises et être remplacées par de nouvelles instances. Si tel est le cas, la vérification des CloudWatch journaux Amazon peut en déterminer la cause.

Une autre méthode consiste à vérifier les équilibreurs de charge du système. Cela indique qu'il peut y avoir des problèmes avec le système si les équilibreurs de charge, trouvés sur la EC2 console Amazon, n'affichent aucune instance saine enregistrée.

Voici un exemple d'apparence normale :

Tableau de bord des équilibreurs de charge ec2

Si l'entrée Healthy est égale à 0, cela indique qu'aucune EC2 instance Amazon n'est disponible pour traiter les demandes.

Si l'entrée Unhealthy n'est pas égale à 0, cela indique qu'une EC2 instance Amazon est peut-être en cours de cycle. Cela peut être dû au fait que le logiciel d'application installé ne passe pas les tests de santé.

Si les entrées saines et malsaines sont toutes deux égales à 0, cela indique une erreur de configuration potentielle du réseau. Par exemple, les sous-réseaux public et privé peuvent ne pas avoir de correspondance AZs. Dans ce cas, un texte supplémentaire peut apparaître sur la console indiquant que l'état du réseau existe.

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

Lancement de bureaux virtuels

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

Un bureau virtuel qui fonctionnait auparavant n'est plus en mesure de se connecter correctement

Si une connexion de bureau se ferme ou si vous ne pouvez plus vous y connecter, le problème peut être dû à la défaillance de l' EC2 instance Amazon sous-jacente ou à la résiliation ou à l'arrêt de l' EC2 instance Amazon en dehors de l'environnement RES. L'état de l'interface utilisateur d'administration peut continuer à indiquer qu'il est prêt, mais les tentatives de connexion échouent.

La EC2 console Amazon doit être utilisée pour déterminer si l'instance a été résiliée ou arrêtée. En cas d'arrêt, essayez de le redémarrer. Si l'état est résilié, un autre bureau devra être créé. Toutes les données stockées dans le répertoire personnel de l'utilisateur doivent toujours être disponibles au démarrage de la nouvelle instance.

Si l'instance qui a échoué précédemment apparaît toujours dans l'interface utilisateur d'administration, il peut être nécessaire de la fermer à l'aide de l'interface utilisateur d'administration.

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

Je ne peux lancer que 5 bureaux virtuels

La limite par défaut du nombre de bureaux virtuels qu'un utilisateur peut lancer est de 5. Cela peut être modifié par un administrateur à l'aide de l'interface utilisateur d'administration comme suit :

  • Accédez aux paramètres du bureau.

  • Sélectionnez l'onglet Serveur.

  • Dans le panneau DCV Session, cliquez sur l'icône d'édition à droite.

  • Modifiez la valeur du champ Sessions autorisées par utilisateur à la nouvelle valeur souhaitée.

  • Sélectionnez Envoyer.

  • Actualisez la page pour confirmer que le nouveau paramètre est en place.

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

Les tentatives de connexion Windows pour ordinateur de bureau échouent avec le message « La connexion a été fermée ». Erreur de transport »

Si une connexion de bureau Windows échoue avec le message d'erreur « La connexion a été fermée » s'affiche dans l'interface utilisateur. « Erreur de transport », la cause peut être due à un problème dans le logiciel du serveur DCV lié à la création de certificats sur l'instance Windows.

Le groupe de CloudWatch log Amazon <envname>/vdc/dcv-connection-gateway peut enregistrer l'erreur de tentative de connexion avec des messages similaires aux suivants :

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)

Dans ce cas, une solution peut être d'utiliser le gestionnaire de session SSM pour ouvrir une connexion à l'instance Windows et supprimer les 2 fichiers relatifs aux certificats suivants :

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

Les fichiers doivent être automatiquement recréés et une tentative de connexion ultérieure peut être couronnée de succès.

Si cette méthode résout le problème et si les nouveaux lancements de postes de travail Windows produisent la même erreur, utilisez la fonction Create Software Stack pour créer une nouvelle pile logicielle Windows de l'instance fixe avec les fichiers de certificat régénérés. Cela peut produire une pile logicielle Windows qui peut être utilisée pour des lancements et des connexions réussis.

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

VDIs bloqué dans l'état de provisionnement

Si le lancement d'un poste de travail reste en état de provisionnement dans l'interface utilisateur d'administration, cela peut être dû à plusieurs raisons.

Pour en déterminer la cause, examinez les fichiers journaux de l'instance de bureau et recherchez les erreurs susceptibles d'être à l'origine du problème. Ce document contient une liste de fichiers journaux et de groupes de CloudWatch journaux Amazon contenant des informations pertinentes dans la section intitulée Sources d'informations utiles sur les journaux et les événements.

Les causes potentielles de ce problème sont les suivantes.

  • L'identifiant AMI utilisé a été enregistré en tant que pile logicielle mais n'est pas pris en charge par RES.

    Le script de provisionnement bootstrap n'a pas pu se terminer car l'Amazon Machine Image (AMI) ne dispose pas de la configuration attendue ou de l'outillage requis. Les fichiers journaux de l'instance, par exemple /root/bootstrap/logs/ sur une instance Linux, peuvent contenir des informations utiles à ce sujet. AMIs les identifiants extraits du AWS Marketplace peuvent ne pas fonctionner pour les instances de bureau RES. Ils doivent être testés pour confirmer s'ils sont pris en charge.

  • Les scripts de données utilisateur ne sont pas exécutés lorsque l'instance de bureau virtuel Windows est lancée à partir d'une AMI personnalisée.

    Par défaut, les scripts de données utilisateur s'exécutent une seule fois lors du lancement d'une EC2 instance Amazon. Si vous créez une AMI à partir d'une instance de bureau virtuel existante, puis que vous enregistrez une pile logicielle auprès de l'AMI et que vous essayez de lancer un autre bureau virtuel avec cette pile logicielle, les scripts de données utilisateur ne s'exécuteront pas sur la nouvelle instance de bureau virtuel.

    Pour résoudre le problème, ouvrez une fenêtre de PowerShell commande en tant qu'administrateur sur l'instance de bureau virtuel d'origine que vous avez utilisée pour créer l'AMI, puis exécutez la commande suivante : 

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

    Créez ensuite une nouvelle AMI à partir de l'instance. Vous pouvez utiliser la nouvelle AMI pour enregistrer des piles de logiciels et lancer de nouveaux bureaux virtuels par la suite. Notez que vous pouvez également exécuter la même commande sur l'instance qui reste dans l'état de provisionnement et redémarrer l'instance pour corriger la session de bureau virtuel, mais vous rencontrerez à nouveau le même problème lors du lancement d'un autre bureau virtuel à partir de l'AMI mal configurée.

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

VDIs passer à l'état d'erreur après le lancement

Problème possible 1 : le système de fichiers personnel possède un répertoire pour l'utilisateur avec différentes autorisations POSIX.

C'est peut-être le problème que vous rencontrez si les scénarios suivants sont vrais :

  1. La version RES déployée est 2024.01 ou supérieure.

  2. Lors du déploiement de la pile RES, l'attribut for EnableLdapIDMapping a été défini surTrue.

  3. Le système de fichiers home spécifié lors du déploiement de la pile RES était utilisé dans une version antérieure à RES 2024.01 ou dans un environnement précédent avec EnableLdapIDMapping une valeur définie sur. False

Étapes de résolution : supprimez les répertoires utilisateur du système de fichiers.

  1. SSM vers l'hôte du gestionnaire de clusters.

  2. cd /home.

  3. ls- doit répertorier les répertoires dont les noms de répertoire correspondent aux noms d'utilisateur, tels queadmin1,admin2.. et ainsi de suite.

  4. Supprimez les répertoires,sudo rm -r 'dir_name'. Ne supprimez pas les répertoires ssm-user et ec2-user.

  5. Si les utilisateurs sont déjà synchronisés avec le nouvel environnement, supprimez ceux de l'utilisateur de la table DDB de l'utilisateur (sauf clusteradmin).

  6. Lancez la synchronisation AD : sudo /opt/idea/python/3.9.16/bin/resctl ldap sync-from-ad exécutez-la dans le gestionnaire de clusters Amazon. EC2

  7. Redémarrez l'instance VDI dans l'Errorétat indiqué sur la page Web RES. Vérifiez que le VDI passe à l'Readyétat en 20 minutes environ.

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

Composant de bureau virtuel

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

L' EC2 instance Amazon s'affiche à plusieurs reprises comme terminée dans la console

Si une instance d'infrastructure apparaît à plusieurs reprises comme étant terminée dans la EC2 console Amazon, la cause peut être liée à sa configuration et dépendre du type d'instance d'infrastructure. Les méthodes suivantes permettent d'en déterminer la cause.

Si l'instance vdc-controller affiche des états de terminaison répétés dans la EC2 console Amazon, cela peut être dû à une balise secrète incorrecte. Les secrets conservés par RES comportent des balises qui sont utilisées dans le cadre des politiques de contrôle d'accès IAM associées aux EC2 instances Amazon de l'infrastructure. Si le contrôleur vdc fonctionne en cycle et que l'erreur suivante apparaît dans le groupe de CloudWatch journaux, cela peut être dû au fait qu'un secret n'a pas été correctement étiqueté. Notez que le secret doit être marqué comme suit :

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

Le message du CloudWatch journal Amazon correspondant à cette erreur s'affichera comme suit :

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

Vérifiez les balises de l' EC2 instance Amazon et confirmez qu'elles correspondent à la liste ci-dessus.

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

L'instance vdc-controller est en cours de cycle car le module AD/eVDI ne parvient pas à rejoindre le module AD/eVDI et affiche un échec du contrôle de santé de l'API

Si le module eVDI échoue lors de son contrôle de santé, il affichera ce qui suit dans la section État de l'environnement.

un exemple des modules d'environnement et du tableau de bord d'état

Dans ce cas, le chemin général pour le débogage consiste à consulter les journaux du gestionnaire de clusters CloudWatch. (Recherchez le groupe de journaux nommé<env-name>/cluster-manager.)

Problèmes possibles :

  • Si les journaux contiennent le texteInsufficient permissions, assurez-vous que le ServiceAccount nom d'utilisateur indiqué lors de la création de la pile res est correctement orthographié.

    Exemple de ligne de journal :

    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

    • Vous pouvez accéder au ServiceAccount nom d'utilisateur fourni lors du déploiement de RES depuis la SecretsManager console. Trouvez le secret correspondant dans le gestionnaire de secrets et choisissez Retrieve Plain text. Si le nom d'utilisateur est incorrect, choisissez Modifier pour mettre à jour la valeur secrète. Arrêtez les instances actuelles de cluster-manager et de vdc-controller. Les nouvelles instances apparaîtront dans un état stable.

    • Le nom d'utilisateur doit être ServiceAccount « » si vous utilisez les ressources créées par la pile de ressources externes fournie. Si le DisableADJoin paramètre a été défini sur False lors de votre déploiement de RES, assurez-vous que l'utilisateur ServiceAccount « » est autorisé à créer des objets informatiques dans l'AD.

  • Si le nom d'utilisateur utilisé est correct, mais que les journaux contiennent le texteInvalid credentials, le mot de passe que vous avez saisi est peut-être erroné ou a expiré.

    Exemple de ligne de journal :

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

    • Vous pouvez lire le mot de passe que vous avez saisi lors de la création de l'environnement en accédant au secret qui stocke le mot de passe dans la console Secrets Manager. Sélectionnez le secret (par exemple<env_name>directoryserviceServiceAccountPassword) et choisissez Récupérer du texte brut.

    • Si le mot de passe indiqué dans le secret est incorrect, choisissez Modifier pour mettre à jour sa valeur dans le secret. Arrêtez les instances actuelles de cluster-manager et de vdc-controller. Les nouvelles instances utiliseront le mot de passe mis à jour et apparaîtront dans un état stable.

    • Si le mot de passe est correct, il se peut qu'il ait expiré dans l'Active Directory connecté. Vous devez d'abord réinitialiser le mot de passe dans Active Directory, puis mettre à jour le secret. Vous pouvez réinitialiser le mot de passe de l'utilisateur dans Active Directory à partir de la console Directory Service :

      1. Choisissez l'ID de répertoire approprié

      2. Choisissez Actions, Réinitialiser le mot de passe utilisateur, puis remplissez le formulaire avec le nom d'utilisateur (par exemple, ServiceAccount « ») et le nouveau mot de passe.

      3. Si le nouveau mot de passe est différent du mot de passe précédent, mettez-le à jour dans le secret Secret Manager correspondant (par exemple,<env_name>directoryserviceServiceAccountPassword.

      4. Arrêtez les instances actuelles de cluster-manager et de vdc-controller. Les nouvelles instances apparaîtront dans un état stable.

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

Le projet n'apparaît pas dans le menu déroulant lorsque vous modifiez la Suite logicielle pour l'ajouter

Ce problème peut être lié au problème suivant associé à la synchronisation du compte utilisateur avec AD. Si ce problème apparaît, vérifiez la présence de l'erreur <user-home-init> account not available yet. waiting for user to be synced « » dans le groupe de journaux CloudWatch Amazon du gestionnaire de clusters afin de déterminer si la cause est identique ou liée.

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

Le journal CloudWatch Amazon du gestionnaire de clusters indique que « user-home-init < > le compte n'est pas encore disponible. En attente de synchronisation de l'utilisateur » (où le compte est un nom d'utilisateur)

L'abonné SQS est occupé et bloqué dans une boucle infinie car il ne peut pas accéder au compte utilisateur. Ce code est déclenché lorsque vous essayez de créer un système de fichiers personnel pour un utilisateur lors de la synchronisation utilisateur.

La raison pour laquelle il ne parvient pas à accéder au compte utilisateur peut être que RES n'a pas été configuré correctement pour l'AD utilisé. Par exemple, le ServiceAccountCredentialsSecretArn paramètre utilisé lors de la création de l'environnement BI/RES n'était pas la bonne valeur.

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

Lors de la tentative de connexion, Windows Desktop indique « Votre compte a été désactivé. Veuillez consulter votre administrateur. »

écran d'erreur du compte désactivé

Si l'utilisateur ne parvient pas à se reconnecter à un écran verrouillé, cela peut indiquer qu'il a été désactivé dans l'AD configuré pour RES après s'être connecté avec succès via SSO.

La connexion SSO devrait échouer si le compte utilisateur a été désactivé dans AD.

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

Problèmes liés aux options DHCP avec la configuration AD externe/client

Si vous rencontrez un message d'erreur indiquant que "The connection has been closed. Transport error" vous utilisez les bureaux virtuels Windows lorsque vous utilisez RES avec votre propre Active Directory, consultez le CloudWatch journal dcv-connection-gateway Amazon pour trouver un résultat similaire à ce qui suit :

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

Si vous utilisez un contrôleur de domaine AD pour vos options DHCP pour votre propre VPC, vous devez :

  1. Ajoutez le AmazonProvided DNS aux deux contrôleurs de domaine IPs.

  2. Définissez le nom de domaine sur ec2.internal.

Un exemple est présenté ici. Sans cette configuration, le bureau Windows affichera une erreur de transport, car RES/DCV recherche le nom d'hôte ip-10-0-x-xx.ec2.internal.

exemple de nom de domaine et de serveurs de noms de domaine

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

Erreur Firefox MOZILLA_PKIX_ERROR_REQUIRED_TLS_FEATURE_MISSING

Lorsque vous utilisez le navigateur Web Firefox, le message d'erreur de type MOZILLA_PKIX_ERROR_REQUIRED_TLS_FEATURE_MISSING peut s'afficher lorsque vous essayez de vous connecter à un bureau virtuel.

Cela est dû au fait que le serveur Web RES est configuré avec TLS + Stapling On mais ne répond pas à la validation par agrafage (voir https://support.mozilla). org/en-US/questions/1372483.

Vous pouvez résoudre ce problème en suivant les instructions disponibles sur : https://really-simple-ssl.com/mozilla_pkix_error_required_tls_feature_missing.

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

Suppression d'environnements

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

res-xxx-cluster pile dans l'état « DELETE_FAILED » et ne peut pas être supprimée manuellement en raison de l'erreur « Le rôle n'est pas valide ou ne peut pas être assumé »

Si vous remarquez que la pile « res-xxx-cluster » est dans l'état « DELETE_FAILED » et ne peut pas être supprimée manuellement, vous pouvez effectuer les étapes suivantes pour la supprimer.

Si vous voyez la pile dans un état « DELETE_FAILED », essayez d'abord de la supprimer manuellement. Une boîte de dialogue confirmant Delete Stack peut s'afficher. Sélectionnez Delete (Supprimer).

écran contextuel de confirmation de suppression de la pile

Parfois, même si vous supprimez toutes les ressources de pile requises, vous pouvez toujours voir le message vous demandant de sélectionner les ressources à conserver. Dans ce cas, sélectionnez toutes les ressources comme « ressources à conserver » et choisissez Supprimer.

Vous pouvez voir un message d'erreur qui ressemble à Role: arn:aws:iam::... is Invalid or cannot be assumed

CloudFormation fenêtre de piles affichant une erreur liée à un rôle non valide

Cela signifie que le rôle requis pour supprimer la pile a d'abord été supprimé avant la pile. Pour contourner ce problème, copiez le nom du rôle. Accédez à la console IAM et créez un rôle portant ce nom à l'aide des paramètres indiqués ici, à savoir :

  • Pour Type d'entité de confiance, sélectionnez AWS service.

  • Pour Cas d'utilisation, sous Use cases for other AWS services ChoisirCloudFormation.

La fenêtre de création de rôles IAM (étape 1) vous permet de sélectionner l'entité de confiance

Choisissez Suivant. Assurez-vous d'accorder les autorisations aux rôles AWSCloudFormationFullAccess « » et AdministratorAccess « ». Votre page d'évaluation doit ressembler à ceci :

cet écran IAM vous permet de nommer, de réviser et de créer un rôle

Retournez ensuite sur la CloudFormation console et supprimez la pile. Vous devriez maintenant être en mesure de le supprimer depuis que vous avez créé le rôle. Enfin, accédez à la console IAM et supprimez le rôle que vous avez créé.

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

Collecte de journaux

Connexion à une EC2 instance depuis la EC2 console

  • Suivez ces instructions pour vous connecter à votre EC2 instance Linux.

  • Suivez ces instructions pour vous connecter à votre EC2 instance Windows. Ouvrez ensuite Windows PowerShell pour exécuter n'importe quelle commande.

Collecte des journaux des hôtes de l'infrastructure

  1. Cluster-manager : récupérez les journaux du gestionnaire de cluster aux emplacements suivants et joignez-les au ticket.

    1. Tous les journaux du groupe de CloudWatch journaux<env-name>/cluster-manager.

    2. Tous les journaux situés dans le /root/bootstrap/logs répertoire de l'<env-name>-cluster-manager EC2 instance. Suivez les instructions liées à la section « Connexion à une EC2 instance depuis la EC2 console » au début de cette section pour vous connecter à votre instance.

  2. Contrôleur VDC : récupérez les journaux du contrôleur VDC aux emplacements suivants et joignez-les au ticket.

    1. Tous les journaux du groupe de CloudWatch journaux<env-name>/vdc-controller.

    2. Tous les journaux situés dans le /root/bootstrap/logs répertoire de l'<env-name>-vdc-controller EC2 instance. Suivez les instructions liées à la section « Connexion à une EC2 instance depuis la EC2 console » au début de cette section pour vous connecter à votre instance.

L'un des moyens d'obtenir facilement les journaux est de suivre les instructions de la Téléchargement de journaux depuis des EC2 instances Linux section. Le nom du module serait le nom de l'instance.

Collecte des journaux VDI

Identifiez l' EC2 instance Amazon correspondante

Si un utilisateur lançait un VDI avec un nom de sessionVDI1, le nom correspondant de l'instance sur la EC2 console Amazon serait<env-name>-VDI1-<user name>.

Collectez les journaux VDI Linux

Connectez-vous à l' EC2 instance Amazon correspondante depuis la EC2 console Amazon en suivant les instructions indiquées dans la section « Connexion à une EC2 instance depuis la EC2 console » au début de cette section. Accédez à tous les journaux dans les /var/log/dcv/ répertoires /root/bootstrap/logs et de l' EC2 instance Amazon VDI.

L'un des moyens d'obtenir les journaux serait de les télécharger sur s3, puis de les télécharger à partir de là. Pour cela, vous pouvez suivre ces étapes pour obtenir tous les journaux d'un seul répertoire, puis les télécharger :

  1. Procédez comme suit pour copier les journaux DCV dans le /root/bootstrap/logs répertoire :

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

  2. Maintenant, suivez les étapes répertoriées dans la section suivante Téléchargement des journaux VDI pour télécharger les journaux.

Collectez les journaux Windows VDI

Connectez-vous à l' EC2 instance Amazon correspondante depuis la EC2 console Amazon en suivant les instructions indiquées dans la section « Connexion à une EC2 instance depuis la EC2 console » au début de cette section. Obtenez tous les journaux dans le $env:SystemDrive\Users\Administrator\RES\Bootstrap\Log\ répertoire de l' EC2 instance VDI.

L'un des moyens d'obtenir les journaux serait de les télécharger sur S3, puis de les télécharger à partir de là. Pour ce faire, suivez les étapes répertoriées dans la section suivante-Téléchargement des journaux VDI.

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

Téléchargement des journaux VDI

  1. Mettez à jour le rôle IAM de l' EC2 instance VDI pour autoriser l'accès à S3.

  2. Accédez à la EC2 console et sélectionnez votre instance VDI.

  3. Sélectionnez le rôle IAM qu'il utilise.

  4. Dans la section Politiques d'autorisation du menu déroulant Ajouter des autorisations, choisissez Joindre des politiques, puis sélectionnez la politique AmazonS3 FullAccess.

  5. Choisissez Ajouter des autorisations pour joindre cette politique.

  6. Ensuite, suivez les étapes répertoriées ci-dessous en fonction de votre type de VDI pour télécharger les journaux. Le nom du module serait le nom de l'instance.

    1. Téléchargement de journaux depuis des EC2 instances Linuxpour Linux.

    2. Téléchargement de journaux à partir d' EC2 instances Windowspour Windows.

  7. Enfin, modifiez le rôle pour supprimer la AmazonS3FullAccess politique.

Note

Tous VDIs utilisent le même rôle IAM qui est <env-name>-vdc-host-role-<region>

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

Téléchargement de journaux depuis des EC2 instances Linux

Connectez-vous à l' EC2 instance à partir de laquelle vous souhaitez télécharger les journaux et exécutez les commandes suivantes pour télécharger tous les journaux dans un compartiment 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

Ensuite, accédez à la console S3, sélectionnez le bucket avec son nom <environment_name>-cluster-<region>-<aws_account_number> et téléchargez le <module_name>_logs.tar.gz fichier précédemment téléchargé.

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

Téléchargement de journaux à partir d' EC2 instances Windows

Connectez-vous à l' EC2 instance à partir de laquelle vous souhaitez télécharger les journaux et exécutez les commandes suivantes pour télécharger tous les journaux dans un compartiment 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

Ensuite, accédez à la console S3, sélectionnez le bucket avec son nom <environment_name>-cluster-<region>-<aws_account_number> et téléchargez le <module_name>_logs.zip fichier précédemment téléchargé.

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

Collecte des journaux ECS pour l' WaitCondition erreur

  1. Accédez à la pile déployée et sélectionnez l'onglet Ressources.

  2. Développez Deploy ResearchAndEngineeringStudio→ → Installer → Tâches CreateTaskDef→ CreateContainer→ → LogGroup, puis sélectionnez le groupe de journaux pour ouvrir CloudWatch les journaux.

  3. Récupérez le dernier journal de ce groupe de journaux.

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

Environnement de démonstration

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

Erreur de connexion à l'environnement de démonstration lors du traitement de la demande d'authentification auprès du fournisseur d'identité

Problème

Si vous essayez de vous connecter et que vous recevez une « erreur inattendue lors du traitement de la demande d'authentification auprès du fournisseur d'identité », vos mots de passe ont peut-être expiré. Il peut s'agir du mot de passe de l'utilisateur sous lequel vous essayez de vous connecter ou de votre compte Active Directory Service.

Mitigation

  1. Réinitialisez les mots de passe de l'utilisateur et du compte de service dans la console du service d'annuaire.

  2. Mettez à jour les mots de passe des comptes de service dans Secrets Manager pour qu'ils correspondent au nouveau mot de passe que vous avez saisi ci-dessus :

    • pour la pile Keycloak : -... PasswordSecret - RESExternal-... - DirectoryService-... avec description : mot de passe pour Microsoft Active Directory

    • pour RES : res- ServiceAccountPassword -... avec description : mot de passe du compte Active Directory Service

  3. Accédez à la EC2 console et mettez fin à l'instance du gestionnaire de clusters. Les règles Auto Scaling déclencheront automatiquement le déploiement d'une nouvelle instance.

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

Demo Stack Keycloak ne fonctionne pas

Problème

Si votre serveur Keycloak est tombé en panne et que, lorsque vous l'avez redémarré, l'adresse IP de l'instance a changé, cela a peut-être entraîné une rupture de keycloak : la page de connexion de votre portail RES ne se charge pas ou reste bloquée dans un état de chargement qui ne se résout jamais.

Mitigation

Vous devrez supprimer l'infrastructure existante et redéployer la pile Keycloak pour rétablir le bon état de Keycloak. Procédez comme suit :

  1. Accédez à Cloudformation. Vous devriez y voir deux piles liées à Keycloak :

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

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

  2. Supprimez Stack1. Si vous êtes invité à supprimer la pile imbriquée, sélectionnez Oui pour supprimer la pile imbriquée.

    Assurez-vous que la pile a été complètement supprimée.

  3. Téléchargez le modèle de stack RES SSO Keycloak ici.

  4. Déployez cette pile manuellement avec exactement les mêmes valeurs de paramètres que la pile supprimée. Déployez-le depuis la CloudFormation console en accédant à Create Stack → Avec de nouvelles ressources (standard) → Choisir un modèle existant → Télécharger un fichier modèle. Renseignez les paramètres requis en utilisant les mêmes entrées que la pile supprimée. Vous pouvez trouver ces entrées dans votre pile supprimée en modifiant le filtre sur la CloudFormation console et en accédant à l'onglet Paramètres. Assurez-vous que le nom de l'environnement, la paire de clés et les autres paramètres correspondent aux paramètres de la pile d'origine.

  5. Une fois la pile déployée, votre environnement est prêt à être réutilisé. Vous pouvez les trouver ApplicationUrl dans l'onglet Sorties de la pile déployée.

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