Problema RunBooks - Studio di ricerca e ingegneria
Problemi di installazioneProblemi di gestione delle identitàStorageSnapshotInfrastrutturaAvvio di desktop virtualiComponente del desktop virtualeEliminazione di EnvAmbiente dimostrativo

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Problema RunBooks

La sezione seguente contiene i problemi che possono verificarsi, come rilevarli e suggerimenti su come risolverli.

Problemi di installazione

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

AWS CloudFormation lo stack non riesce a creare il messaggio «messaggio non riuscito WaitCondition ricevuto». Errore: Stati. TaskFailed»

Per identificare il problema, esamina il gruppo di CloudWatch log Amazon denominato<stack-name>-InstallerTasksCreateTaskDefCreateContainerLogGroup<nonce>-<nonce>. Se ci sono più gruppi di log con lo stesso nome, esamina il primo disponibile. Un messaggio di errore all'interno dei log fornirà ulteriori informazioni sul problema.

Nota

Verificate che i valori dei parametri non abbiano spazi.

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

Notifica e-mail non ricevuta dopo che gli AWS CloudFormation stack sono stati creati correttamente

Se non è stato ricevuto un invito via e-mail dopo che gli AWS CloudFormation stack sono stati creati correttamente, verifica quanto segue:

  1. Conferma che il parametro dell'indirizzo email è stato inserito correttamente.

    Se l'indirizzo e-mail non è corretto o non è possibile accedervi, elimina e ridistribuisci l'ambiente Research and Engineering Studio.

  2. Controlla la EC2 console di Amazon per le prove delle istanze cicliche.

    Se ci sono EC2 istanze Amazon con il <envname> prefisso che sembrano terminate e poi vengono sostituite con una nuova istanza, potrebbe esserci un problema con la configurazione di rete o di Active Directory.

  3. Se hai distribuito le ricette AWS High Performance Compute per creare le tue risorse esterne, verifica che il VPC, le sottoreti private e pubbliche e altri parametri selezionati siano stati creati dallo stack.

    Se uno qualsiasi dei parametri non è corretto, potrebbe essere necessario eliminare e ridistribuire l'ambiente RES. Per ulteriori informazioni, consulta Disinstalla il prodotto.

  4. Se hai distribuito il prodotto con risorse esterne, verifica che la rete e Active Directory corrispondano alla configurazione prevista.

    È fondamentale confermare che le istanze dell'infrastruttura siano entrate a far parte di Active Directory con successo. Prova i passaggi seguenti Istanze in ciclo o vdc-controller in stato di errore per risolvere il problema.

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

Istanze in ciclo o vdc-controller in stato di errore

La causa più probabile di questo problema è l'impossibilità delle risorse di connettersi o unirsi ad Active Directory.

Per verificare il problema:

  1. Dalla riga di comando, avvia una sessione con SSM sull'istanza in esecuzione del vdc-controller.

  2. Esegui sudo su -.

  3. Esegui systemctl status sssd.

Se lo stato è inattivo, non riuscito o vengono visualizzati errori nei log, l'istanza non è riuscita a entrare in Active Directory.

Registro degli errori SSM

Registro degli errori SSM

Per risolvere il problema:

  • Dalla stessa istanza della riga di comando, cat /root/bootstrap/logs/userdata.log esegui per esaminare i log.

Il problema potrebbe avere una delle tre possibili cause principali.

Esamina i log. Se vedi quanto segue ripetuto più volte, significa che l'istanza non è riuscita a entrare in 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. Verificate che i valori dei parametri per quanto segue siano stati inseriti correttamente durante la creazione dello stack RES.

    • directoryservice.ldap_connection_uri

    • directoryservice.ldap_base

    • directoryservice.users.ru

    • directoryservice.groups.ou

    • directoryservice.sudoers.ou

    • directoryservice.computers.ou

    • directoryservice.name

  2. Aggiorna eventuali valori errati nella tabella DynamoDB. La tabella si trova nella console DynamoDB in Tabelle. Il nome della tabella dovrebbe essere. <stack name>.cluster-settings

  3. Dopo aver aggiornato la tabella, eliminate il cluster-manager e il vdc-controller che attualmente eseguono le istanze di ambiente. La scalabilità automatica avvierà nuove istanze utilizzando i valori più recenti della tabella DynamoDB.

Se i log vengono restituitiInsufficient permissions to modify computer account, il ServiceAccount nome inserito durante la creazione dello stack potrebbe essere errato.

  1. Dalla AWS console, apri Secrets Manager.

  2. Cercare directoryserviceServiceAccountUsername. Il segreto dovrebbe essere<stack name>-directoryservice-ServiceAccountUsername.

  3. Apri il segreto per visualizzare la pagina dei dettagli. In Valore segreto, scegli Recupera valore segreto e scegli Testo normale.

  4. Se il valore è stato aggiornato, elimina le istanze cluster-manager e vdc-controller attualmente in esecuzione dell'ambiente. La scalabilità automatica avvierà nuove istanze utilizzando il valore più recente di Secrets Manager.

Se vengono visualizzati i logInvalid credentials, la ServiceAccount password inserita durante la creazione dello stack potrebbe essere errata.

  1. Dalla AWS console, apri Secrets Manager.

  2. Cercare directoryserviceServiceAccountPassword. Il segreto dovrebbe essere<stack name>-directoryservice-ServiceAccountPassword.

  3. Apri il segreto per visualizzare la pagina dei dettagli. In Valore segreto, scegli Recupera valore segreto e scegli Testo normale.

  4. Se hai dimenticato la password o non sei sicuro che la password inserita sia corretta, puoi reimpostarla in Active Directory and Secrets Manager.

    1. Per reimpostare la password in: AWS Managed Microsoft AD

      1. Apri la AWS console e vai a AWS Directory Service.

      2. Seleziona l'ID della directory RES e scegli Azioni.

      3. Scegliete Reimposta la password dell'utente.

      4. Inserisci il ServiceAccount nome utente.

      5. Inserisci una nuova password e scegli Reimposta password.

    2. Per reimpostare la password in Secrets Manager:

      1. Apri la AWS console e vai a Secrets Manager.

      2. Cercare directoryserviceServiceAccountPassword. Il segreto dovrebbe essere<stack name>-directoryservice-ServiceAccountPassword.

      3. Apri il segreto per visualizzare la pagina dei dettagli. In Valore segreto, seleziona Recupera valore segreto e scegli Testo normale.

      4. Seleziona Edit (Modifica).

      5. Imposta una nuova password per l' ServiceAccount utente e seleziona Salva.

  5. Se hai aggiornato il valore, elimina le istanze cluster-manager e vdc-controller attualmente in esecuzione dell'ambiente. La scalabilità automatica avvierà nuove istanze utilizzando il valore più recente.

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

Impossibile eliminare CloudFormation lo stack di ambiente a causa di un errore dell'oggetto dipendente

Se l'eliminazione dello <env-name>-vdc CloudFormation stack non riesce a causa di un errore dell'oggetto dipendente come ilvdcdcvhostsecuritygroup, ciò potrebbe essere dovuto a un' EC2 istanza Amazon che è stata lanciata in una sottorete o in un gruppo di sicurezza creato da RES utilizzando la Console. AWS

Per risolvere il problema, trova e chiudi tutte le EC2 istanze Amazon avviate in questo modo. È quindi possibile riprendere l'eliminazione dell'ambiente.

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

Errore rilevato per il parametro del blocco CIDR durante la creazione dell'ambiente

Durante la creazione di un ambiente, viene visualizzato un errore per il parametro di blocco CIDR con uno stato di risposta di [FAILED].

Esempio di errore: 

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.

Per risolvere il problema, il formato previsto è x.x.x.0/24 o x.x.x.0/32.

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

CloudFormation errore di creazione dello stack durante la creazione dell'ambiente

La creazione di un ambiente implica una serie di operazioni di creazione di risorse. In alcune regioni, può verificarsi un problema di capacità che impedisce la creazione di uno CloudFormation stack.

In tal caso, elimina l'ambiente e riprova a creare. In alternativa, puoi riprovare la creazione in un'altra regione.

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

La creazione dello stack di risorse esterne (demo) non riesce con CREATE_FAILED AdDomainAdminNode

Se la creazione dello stack dell'ambiente demo fallisce con il seguente errore, potrebbe essere dovuto all'applicazione di EC2 patch da parte di Amazon in modo imprevisto durante il provisioning dopo il lancio dell'istanza. 

AdDomainAdminNode CREATE_FAILED  Failed to receive 1 resource signal(s) within the specified duration
Per determinare la causa dell'errore:

  1. In SSM State Manager, controlla se l'applicazione delle patch è configurata e se è configurata per tutte le istanze.

  2. Nella cronologia di esecuzione di SSM, controlla se RunCommand/Automation l'esecuzione di un documento SSM relativo all'applicazione di patch coincide con l'avvio di un'istanza.

  3. Nei file di registro per le EC2 istanze Amazon dell'ambiente, esamina la registrazione dell'istanza locale per determinare se l'istanza è stata riavviata durante il provisioning.

Se il problema è stato causato dall'applicazione di patch, ritarda l'applicazione delle patch per le istanze RES di almeno 15 minuti dopo l'avvio.

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

Problemi di gestione delle identità

La maggior parte dei problemi con il Single Sign-On (SSO) e la gestione delle identità si verificano a causa di una configurazione errata. Per informazioni sulla configurazione SSO, consulta:

Per risolvere altri problemi relativi alla gestione delle identità, consulta i seguenti argomenti di risoluzione dei problemi:

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

Non sono autorizzato a eseguire iam: PassRole

Se ricevi un messaggio di errore indicante che non sei autorizzato a eseguire l'PassRole azione iam:, le tue politiche devono essere aggiornate per consentirti di trasferire un ruolo a RES.

Alcuni AWS servizi consentono di trasferire un ruolo esistente a quel servizio anziché creare un nuovo ruolo di servizio o un ruolo collegato al servizio. Per eseguire questa operazione, è necessario disporre delle autorizzazioni per trasmettere il ruolo al servizio.

L'errore di esempio seguente si verifica quando un utente IAM di nome marymajor tenta di utilizzare la console per eseguire un'azione in RES. Tuttavia, l'azione richiede che il servizio disponga delle autorizzazioni concesse da un ruolo di servizio. Mary non dispone delle autorizzazioni per passare il ruolo al servizio.

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

In questo caso, le politiche di Mary devono essere aggiornate per consentirle di eseguire l'azione iam:PassRole . Se hai bisogno di aiuto, contatta il tuo AWS amministratore. L'amministratore è la persona che ti ha fornito le credenziali di accesso.

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

Voglio consentire a persone esterne al mio AWS account di accedere al mio Research and Engineering Studio sulle AWS risorse

È possibile creare un ruolo con il quale utenti in altri account o persone esterne all'organizzazione possono accedere alle tue risorse. È possibile specificare chi è attendibile per l'assunzione del ruolo. Per i servizi che supportano politiche basate sulle risorse o liste di controllo degli accessi (ACLs), puoi utilizzare tali politiche per consentire alle persone di accedere alle tue risorse.

Per ulteriori informazioni, consulta gli argomenti seguenti:

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

Quando accedo all'ambiente, torno immediatamente alla pagina di accesso

Questo problema si verifica quando l'integrazione SSO non è configurata correttamente. Per determinare il problema, controlla i registri delle istanze del controller e verifica la presenza di errori nelle impostazioni di configurazione.

Per controllare i log:

  1. Apri la CloudWatch console.

  2. Da Gruppi di log, trova il gruppo denominato/<environment-name>/cluster-manager.

  3. Apri il gruppo di log per cercare eventuali errori nei flussi di log.

Per verificare le impostazioni di configurazione:

  1. Apri la console DynamoDB

  2. In Tabelle, trova la tabella denominata. <environment-name>.cluster-settings

  3. Apri la tabella e seleziona Esplora gli elementi della tabella.

  4. Espandi la sezione dei filtri e inserisci le seguenti variabili:

    • Nome dell'attributo: chiave

    • Condizione: contiene

    • Valore: sso

  5. Seleziona Esegui.

  6. Nella stringa restituita, verifica che i valori di configurazione SSO siano corretti. Se non sono corretti, modifica il valore della chiave sso_enabled su False.

    La console DynamoDB con la schermata Modifica elemento per il valore della chiave sso_enabled.

  7. Tornate all'interfaccia utente RES per riconfigurare l'SSO.

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

Errore «Utente non trovato» durante il tentativo di accesso

Se un utente riceve l'errore «Utente non trovato» quando tenta di accedere all'interfaccia RES e l'utente è presente in Active Directory:

  • Se l'utente non è presente in RES e l'hai recentemente aggiunto ad AD

    • È possibile che l'utente non sia ancora sincronizzato con RES. RES si sincronizza ogni ora, quindi potrebbe essere necessario attendere e verificare che l'utente sia stato aggiunto dopo la sincronizzazione successiva. Per eseguire la sincronizzazione immediata, segui la procedura riportata di seguito. Utente aggiunto in Active Directory, ma mancante in RES

  • Se l'utente è presente in RES:

    1. Assicurati che la mappatura degli attributi sia configurata correttamente. Per ulteriori informazioni, consulta Configurazione del provider di identità per il Single Sign-On (SSO).

    2. Assicurati che l'oggetto SAML e l'e-mail SAML corrispondano entrambi all'indirizzo e-mail dell'utente.

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

Utente aggiunto in Active Directory, ma mancante in RES

Se hai aggiunto un utente ad Active Directory ma non è presente in RES, è necessario attivare la sincronizzazione AD. La sincronizzazione AD viene eseguita ogni ora da una funzione Lambda che importa le voci AD nell'ambiente RES. A volte, dopo l'aggiunta di nuovi utenti o gruppi, si verifica un ritardo fino all'esecuzione del processo di sincronizzazione successivo. Puoi avviare la sincronizzazione manualmente da Amazon Simple Queue Service.

Avvia il processo di sincronizzazione manualmente:

  1. Apri la console Amazon SQS.

  2. Da Queues, seleziona. <environment-name>-cluster-manager-tasks.fifo

  3. Seleziona Invia e ricevi messaggi.

  4. Per il corpo del messaggio, inserisci:

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

  5. Per l'ID del gruppo di messaggi, inserisci: adsync.sync-from-ad

  6. Per ID di deduplicazione dei messaggi, inserisci una stringa alfanumerica casuale. Questa immissione deve essere diversa da tutte le chiamate effettuate negli ultimi cinque minuti o la richiesta verrà ignorata.

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

Utente non disponibile durante la creazione di una sessione

Se sei un amministratore che crea una sessione, ma scopri che un utente che si trova in Active Directory non è disponibile durante la creazione di una sessione, potrebbe essere necessario accedere per la prima volta. Le sessioni possono essere create solo per utenti attivi. Gli utenti attivi devono accedere all'ambiente almeno una volta.

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

Il limite di dimensione è stato superato (errore nel registro del gestore del CloudWatch cluster)

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

Se si riceve questo errore nel registro del CloudWatch gestore del cluster, la ricerca ldap potrebbe aver restituito troppi record utente. Per risolvere questo problema, aumenta il limite dei risultati di ricerca ldap del tuo IDP.

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

Storage

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

Ho creato il file system tramite RES ma non si monta sugli host VDI

I file system devono essere nello stato «Disponibile» prima di poter essere montati dagli host VDI. Segui i passaggi seguenti per verificare che il file system sia nello stato richiesto.

Amazon EFS

  1. Vai alla console Amazon EFS.

  2. Verifica che lo stato del file system sia Disponibile.

  3. Se lo stato del file system non è Disponibile, attendi prima di avviare gli host VDI.

  1. Vai alla FSx console Amazon.

  2. Verifica che lo stato sia disponibile.

  3. Se Status non è disponibile, attendi prima di avviare gli host VDI.

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

Ho effettuato l'onboarding di un file system tramite RES ma non viene montato sugli host VDI

I file system integrati su RES devono avere le regole di gruppo di sicurezza richieste configurate per consentire agli host VDI di montare i file system. Poiché questi file system vengono creati esternamente a RES, RES non gestisce le regole dei gruppi di sicurezza associati.

Il gruppo di sicurezza associato ai file system integrati dovrebbe consentire il seguente traffico in entrata:

  • Traffico NFS (porta: 2049) dagli host Linux VDC

  • Traffico SMB (porta: 445) proveniente dagli host Windows VDC

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

Non riesco ad accedervi dagli read/write host VDI

ONTAP supporta lo stile di sicurezza UNIX, NTFS e MIXED per i volumi. Gli stili di sicurezza determinano il tipo di autorizzazioni utilizzate da ONTAP per controllare l'accesso ai dati e il tipo di client che può modificare tali autorizzazioni.

Ad esempio, se un volume utilizza lo stile di sicurezza UNIX, i client SMB possono comunque accedere ai dati (a condizione che si autentichino e autorizzino correttamente) grazie alla natura multiprotocollo di ONTAP. Tuttavia, ONTAP utilizza autorizzazioni UNIX che solo i client UNIX possono modificare utilizzando strumenti nativi.

Esempi di casi d'uso per la gestione delle autorizzazioni

Utilizzo di volumi in stile UNIX con carichi di lavoro Linux

Le autorizzazioni possono essere configurate dal sudoer per altri utenti. Ad esempio, quanto segue fornirebbe a tutti i membri le read/write autorizzazioni <group-ID> complete sulla directory: /<project-name>

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

Utilizzo di volumi in stile NTFS con carichi di lavoro Linux e Windows

Le autorizzazioni di condivisione possono essere configurate utilizzando le proprietà di condivisione di una cartella particolare. Ad esempio, in base a un utente user_01 e a una cartellamyfolder, è possibile impostare le autorizzazioni di Full ControlChange, o Read su Allow o: Deny

Le autorizzazioni di condivisione possono essere impostate su Consenti o Nega per il controllo completo, la modifica o la lettura

Se il volume verrà utilizzato da client Linux e Windows, è necessario impostare una mappatura dei nomi su SVM che assocerà qualsiasi nome utente Linux allo stesso nome utente con il formato del nome di dominio NetBIOS domain\ username. Questo è necessario per tradurre tra utenti Linux e Windows. Per riferimento, consulta Abilitazione dei carichi di lavoro multiprotocollo con Amazon FSx for NetApp ONTAP.

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

Ho creato Amazon FSx for NetApp ONTAP da RES ma non è stato aggiunto al mio dominio

Attualmente, quando crei Amazon FSx for NetApp ONTAP dalla console RES, il file system viene fornito ma non entra a far parte del dominio. Per aggiungere la SVM del file system ONTAP creata al tuo dominio, consulta Registrazione SVMs a Microsoft Active Directory e segui i passaggi sulla console Amazon FSx . Assicurati che le autorizzazioni richieste siano delegate all'account Amazon FSx Service in AD. Una volta che l'SVM si è unito correttamente al dominio, vai su SVM Summary > Endpoints > SMB DNS name e copia il nome DNS perché ti servirà in seguito.

Dopo averlo aggiunto al dominio, modifica la chiave di configurazione DNS SMB nella tabella DynamoDB delle impostazioni del cluster:

  1. Vai alla console Amazon DynamoDB.

  2. Seleziona Tabelle, quindi scegli. <stack-name>-cluster-settings

  3. In Esplora gli elementi della tabella, espandi Filtri e inserisci il seguente filtro:

    • Nome dell'attributo: chiave

    • Condizione: uguale a

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

  4. Seleziona l'articolo restituito, quindi Azioni, Modifica articolo.

  5. Aggiorna il valore con il nome DNS SMB che hai copiato in precedenza.

  6. Seleziona Salva e chiudi.

Inoltre, assicurati che il gruppo di sicurezza associato al file system consenta il traffico come consigliato in File System Access Control with Amazon VPC. I nuovi host VDI che utilizzano il file system saranno ora in grado di montare SVM e file system uniti al dominio.

In alternativa, è possibile effettuare l'onboarding di un file system esistente che fa già parte del dominio utilizzando la funzionalità RES Onboard File System: da Environment Management seleziona File Systems, Onboard File System.

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

Snapshot

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

Lo stato di un'istantanea è Fallito

Nella pagina RES Snapshots, se uno snapshot ha lo stato Failed, la causa può essere determinata accedendo al gruppo di CloudWatch log di Amazon per il gestore del cluster per il momento in cui si è verificato l'errore.

[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

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

Uno snapshot non viene applicato con i log che indicano che le tabelle non possono essere importate.

Se un'istantanea scattata da un ambiente precedente non viene applicata in un nuovo ambiente, esamina i CloudWatch log di Cluster-Manager per identificare il problema. Se il problema indica che le tabelle richieste dal cloud non possono essere importate, verifica che lo snapshot sia in uno stato valido.

  1. Scaricate il file metadata.json e verificate che lo stato delle varie tabelle sia ExportStatus COMPLETATO. Assicurati che il campo sia impostato nelle varie tabelle. ExportManifest Se non trovi i campi precedenti impostati, l'istantanea è in uno stato non valido e non può essere utilizzata con la funzionalità di applicazione dell'istantanea.

  2. Dopo aver avviato la creazione di un'istantanea, assicurati che lo stato dell'istantanea diventi su COMPLETATO in RES. Il processo di creazione dell'istantanea richiede da 5 a 10 minuti. Ricarica o rivisita la pagina di gestione delle istantanee per assicurarti che l'istantanea sia stata creata correttamente. Ciò garantirà che l'istantanea creata sia in uno stato valido.

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

Infrastruttura

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

Load Balancer si rivolge a gruppi target senza istanze integre

Se nell'interfaccia utente compaiono problemi come messaggi di errore del server o le sessioni desktop non riescono a connettersi, ciò potrebbe indicare un problema nell'infrastruttura delle EC2 istanze Amazon.

I metodi per determinare l'origine del problema consistono innanzitutto nel controllare la EC2 console Amazon per eventuali EC2 istanze Amazon che sembrano terminare ripetutamente e essere sostituite da nuove istanze. In tal caso, il controllo dei CloudWatch log di Amazon può determinarne la causa.

Un altro metodo è controllare i sistemi di bilanciamento del carico nel sistema. Un'indicazione che potrebbero esserci problemi di sistema è se alcuni sistemi di bilanciamento del carico presenti sulla EC2 console Amazon non mostrano alcuna istanza integra registrata.

Di seguito è riportato un esempio di aspetto normale:

dashboard dei sistemi di bilanciamento del carico ec2

Se la voce Healthy è 0, ciò indica che nessuna EC2 istanza Amazon è disponibile per elaborare le richieste.

Se la voce Unhealthy è diversa da 0, ciò indica che EC2 un'istanza Amazon potrebbe essere in ciclo. Ciò può essere dovuto al fatto che il software delle applicazioni installate non supera i controlli sanitari.

Se entrambe le voci Healthy e Unhealthy sono 0, ciò indica una potenziale configurazione errata della rete. Ad esempio, le sottoreti pubbliche e private potrebbero non avere corrispondenze. AZs Se si verifica questa condizione, è possibile che sulla console sia presente un testo aggiuntivo che indica l'esistenza dello stato della rete.

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

Avvio di desktop virtuali

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

Un desktop virtuale che in precedenza funzionava non è più in grado di connettersi correttamente

Se una connessione desktop si chiude o non riesci più a connetterti ad essa, il problema potrebbe essere dovuto al guasto dell' EC2 istanza Amazon sottostante o l'istanza Amazon EC2 potrebbe essere stata terminata o interrotta al di fuori dell'ambiente RES. Lo stato dell'interfaccia utente di amministrazione può continuare a mostrare uno stato pronto, ma i tentativi di connessione non riescono.

La EC2 console Amazon deve essere utilizzata per determinare se l'istanza è stata interrotta o interrotta. Se interrotta, prova a riavviarla. Se lo stato viene terminato, sarà necessario creare un altro desktop. Tutti i dati archiviati nella home directory dell'utente dovrebbero essere ancora disponibili all'avvio della nuova istanza.

Se l'istanza che aveva avuto esito negativo in precedenza è ancora presente nell'interfaccia utente di amministrazione, potrebbe essere necessario chiuderla utilizzando l'interfaccia utente di amministrazione.

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

Sono in grado di avviare solo 5 desktop virtuali

Il limite predefinito per il numero di desktop virtuali che un utente può avviare è 5. Questo può essere modificato da un amministratore utilizzando l'interfaccia utente di amministrazione come segue:

  • Vai a Impostazioni del desktop.

  • Seleziona la scheda Server.

  • Nel pannello DCV Session, fai clic sull'icona di modifica a destra.

  • Modificate il valore in Sessioni consentite per utente con il nuovo valore desiderato.

  • Selezionare Invia.

  • Aggiorna la pagina per confermare che la nuova impostazione è attiva.

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

I tentativi di connessione su Desktop Windows falliscono e viene visualizzato il messaggio «La connessione è stata chiusa. Errore di trasporto»

Se una connessione desktop Windows fallisce e viene visualizzato l'errore dell'interfaccia utente «La connessione è stata chiusa. «Errore di trasporto», la causa può essere dovuta a un problema nel software del server DCV relativo alla creazione di certificati sull'istanza di Windows.

Il gruppo di CloudWatch log di Amazon <envname>/vdc/dcv-connection-gateway può registrare l'errore del tentativo di connessione con messaggi simili ai seguenti:

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)

In tal caso, una soluzione potrebbe essere quella di utilizzare SSM Session Manager per aprire una connessione all'istanza di Windows e rimuovere i seguenti 2 file relativi al certificato:

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

I file devono essere ricreati automaticamente e un successivo tentativo di connessione potrebbe avere successo.

Se questo metodo risolve il problema e se i nuovi avvii dei desktop Windows generano lo stesso errore, utilizzate la funzione Create Software Stack per creare un nuovo stack software Windows dell'istanza fissa con i file di certificato rigenerati. Ciò può produrre uno stack di software Windows che può essere utilizzato per avvii e connessioni di successo.

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

VDIs bloccato nello stato di Provisioning

Se il lancio di un desktop rimane nello stato di provisioning nell'interfaccia utente di amministrazione, ciò può essere dovuto a diversi motivi.

Per determinare la causa, esamina i file di registro sull'istanza desktop e cerca gli errori che potrebbero causare il problema. Questo documento contiene un elenco di file di log e gruppi di CloudWatch log Amazon che contengono informazioni pertinenti nella sezione denominata Fonti utili di informazioni su log ed eventi.

Di seguito sono elencate le possibili cause di questo problema.

  • L'ID AMI utilizzato è stato registrato come stack software ma non è supportato da RES.

    Lo script di provisioning bootstrap non è stato completato perché l'AMI non dispone della configurazione o degli strumenti previsti richiesti. I file di registro sull'istanza, ad esempio /root/bootstrap/logs/ su un'istanza Linux, possono contenere informazioni utili in merito. AMIs gli id presi dal AWS Marketplace potrebbero non funzionare per le istanze desktop RES. Richiedono dei test per confermare se sono supportati.

  • Gli script dei dati utente non vengono eseguiti quando l'istanza del desktop virtuale di Windows viene avviata da un'AMI personalizzata.

    Per impostazione predefinita, gli script dei dati utente vengono eseguiti una sola volta all'avvio di un' EC2 istanza Amazon. Se crei un'AMI da un'istanza di desktop virtuale esistente, quindi registri uno stack software con l'AMI e provi ad avviare un altro desktop virtuale con questo stack software, gli script dei dati utente non verranno eseguiti sulla nuova istanza di desktop virtuale.

    Per risolvere il problema, apri una finestra di PowerShell comando come amministratore sull'istanza del desktop virtuale originale che hai usato per creare l'AMI ed esegui il seguente comando: 

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

    Quindi crea una nuova AMI dall'istanza. È possibile utilizzare la nuova AMI per registrare stack software e avviare successivamente nuovi desktop virtuali. Tieni presente che puoi anche eseguire lo stesso comando sull'istanza che rimane nello stato di provisioning e riavviare l'istanza per correggere la sessione del desktop virtuale, ma riscontrerai nuovamente lo stesso problema all'avvio di un altro desktop virtuale dall'AMI non configurata correttamente.

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

VDIs entra nello stato di errore dopo l'avvio

Possibile problema 1: il filesystem home ha una directory per l'utente con permessi POSIX diversi.

Questo potrebbe essere il problema che stai affrontando se si verificano i seguenti scenari:

  1. La versione RES implementata è 2024.01 o successiva.

  2. Durante la distribuzione dello stack RES l'attributo for EnableLdapIDMapping è stato impostato su. True

  3. Il filesystem home specificato durante l'implementazione dello stack RES è stato utilizzato nella versione precedente a RES 2024.01 o è stato utilizzato in un ambiente precedente con impostato su. EnableLdapIDMapping False

Fasi di risoluzione: eliminare le directory utente nel filesystem.

  1. SSM all'host del gestore del cluster.

  2. cd /home.

  3. ls- dovrebbe elencare le directory con nomi di directory che corrispondono ai nomi utenteadmin1, admin2 come.. e così via.

  4. Eliminare le directory,. sudo rm -r 'dir_name' Non eliminate le directory ssm-user ed ec2-user.

  5. Se gli utenti sono già sincronizzati con il nuovo env, elimina l'utente dalla tabella DDB dell'utente (eccetto clusteradmin).

  6. Avvia la sincronizzazione AD: eseguila sudo /opt/idea/python/3.9.16/bin/resctl ldap sync-from-ad nel gestore di cluster Amazon. EC2

  7. Riavvia l'istanza VDI Error nello stato della pagina Web RES. Verifica che il VDI passi allo stato in circa 20 minuti. Ready

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

Componente del desktop virtuale

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

L' EC2 istanza Amazon viene ripetutamente visualizzata come terminata nella console

Se un'istanza dell'infrastruttura viene ripetutamente visualizzata come terminata nella EC2 console Amazon, la causa potrebbe essere correlata alla sua configurazione e dipendere dal tipo di istanza dell'infrastruttura. Di seguito sono riportati i metodi per determinare la causa.

Se l'istanza vdc-controller mostra stati terminati ripetuti nella EC2 console Amazon, ciò può essere dovuto a un tag segreto errato. I segreti gestiti da RES hanno tag che vengono utilizzati come parte delle politiche di controllo degli accessi IAM collegate alle EC2 istanze Amazon dell'infrastruttura. Se il controller vdc è in esecuzione ciclica e nel gruppo di CloudWatch log viene visualizzato il seguente errore, è possibile che un segreto non sia stato etichettato correttamente. Nota che il segreto deve essere etichettato con quanto segue:

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

Il messaggio di CloudWatch log di Amazon relativo a questo errore apparirà simile al seguente:

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

Controlla i tag sull' EC2 istanza Amazon e verifica che corrispondano all'elenco precedente.

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

L'istanza vdc-controller è ciclica a causa del mancato accesso al modulo AD/eVDI mostra Failed API Health Check

Se il modulo eVDI non funziona, durante il controllo dello stato dell'ambiente verrà visualizzato quanto segue nella sezione Environment Status.

un esempio dei moduli di ambiente e del pannello di controllo dello stato

In questo caso, il percorso generale per il debug consiste nell'esaminare i log del gestore del cluster. CloudWatch (Cerca il gruppo di log denominato.) <env-name>/cluster-manager

Problemi possibili:

  • Se i log contengono il testoInsufficient permissions, assicurati che il ServiceAccount nome utente fornito al momento della creazione dello stack res sia digitato correttamente.

    Esempio di riga di 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

    • È possibile accedere al ServiceAccount nome utente fornito durante l'implementazione di RES dalla SecretsManager console. Trova il segreto corrispondente in Secrets Manager e seleziona Recupera testo normale. Se il nome utente non è corretto, seleziona Modifica per aggiornare il valore segreto. Termina le istanze correnti di cluster-manager e vdc-controller. Le nuove istanze verranno visualizzate in uno stato stabile.

    • Il nome utente deve essere "ServiceAccount" se si utilizzano le risorse create dallo stack di risorse esterne fornito. Se il DisableADJoin parametro è stato impostato su False durante la distribuzione di RES, assicuratevi che l'utente "ServiceAccount" disponga delle autorizzazioni per creare oggetti Computer in AD.

  • Se il nome utente utilizzato era corretto, ma i log contengono il testoInvalid credentials, la password inserita potrebbe essere errata o scaduta.

    Esempio di riga di registro:

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

    • Puoi leggere la password che hai inserito durante la creazione dell'ambiente accedendo al segreto che memorizza la password nella console Secrets Manager. Seleziona il segreto (ad esempio<env_name>directoryserviceServiceAccountPassword) e seleziona Recupera testo normale.

    • Se la password nel segreto non è corretta, seleziona Modifica per aggiornarne il valore nel segreto. Termina le istanze correnti di cluster-manager e vdc-controller. Le nuove istanze utilizzeranno la password aggiornata e si presenteranno in uno stato stabile.

    • Se la password è corretta, è possibile che sia scaduta nell'Active Directory connessa. Dovrai prima reimpostare la password in Active Directory e quindi aggiornare il segreto. È possibile reimpostare la password dell'utente in Active Directory dalla console Directory Service:

      1. Scegli l'ID di directory appropriato

      2. Seleziona Azioni, Reimposta la password dell'utente, quindi compila il modulo con il nome utente (ad esempio, "ServiceAccount«) e la nuova password.

      3. Se la password appena impostata è diversa dalla password precedente, aggiorna la password nel segreto del Secret Manager corrispondente (ad esempio,<env_name>directoryserviceServiceAccountPassword.

      4. Termina le istanze correnti di cluster-manager e vdc-controller. Le nuove istanze verranno visualizzate in uno stato stabile.

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

Il progetto non viene visualizzato nel menu a discesa quando si modifica lo stack software per aggiungerlo

Questo problema può essere correlato al seguente problema associato alla sincronizzazione dell'account utente con AD. Se si verifica questo problema, verifica l'errore "<user-home-init> account not available yet. waiting for user to be synced" nel gruppo di CloudWatch log Amazon cluster-manager per determinare se la causa è la stessa o correlata.

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

Il CloudWatch log di Amazon cluster-manager mostra «< user-home-init > account non ancora disponibile in attesa della sincronizzazione dell'utente» (dove l'account è un nome utente)

L'abbonato SQS è occupato e bloccato in un ciclo infinito perché non può accedere all'account utente. Questo codice viene attivato quando si tenta di creare un filesystem home per un utente durante la sincronizzazione dell'utente.

Il motivo per cui non è possibile accedere all'account utente potrebbe essere che RES non è stato configurato correttamente per l'AD in uso. Un esempio potrebbe essere che il ServiceAccountUsername parametro utilizzato per la creazione BI/RES dell'ambiente non era il valore corretto, ad esempio utilizzando "ServiceAccount" anziché «Admin».

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

Il desktop di Windows al tentativo di accesso dice «Il tuo account è stato disabilitato. Rivolgiti al tuo amministratore»

schermata di errore relativa all'account disabilitato

Se l'utente non è in grado di accedere nuovamente a una schermata bloccata, ciò potrebbe indicare che l'utente è stato disabilitato nell'AD configurato per RES dopo aver effettuato correttamente l'accesso tramite SSO.

L'accesso SSO dovrebbe fallire se l'account utente è stato disabilitato in AD.

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

Problemi relativi alle opzioni DHCP con external/customer la configurazione AD

Se riscontri un errore durante l'utilizzo "The connection has been closed. Transport error" di desktop virtuali Windows quando usi RES con il tuo Active Directory, controlla nel CloudWatch log di dcv-connection-gateway Amazon qualcosa di simile al seguente:

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 utilizzi un controller di dominio AD per le opzioni DHCP per il tuo VPC, devi:

  1. Aggiungere AmazonProvided DNS ai due controller di dominio. IPs

  2. Imposta il nome di dominio su ec2.internal.

Un esempio è mostrato qui. Senza questa configurazione, il desktop di Windows restituirà l'errore Transport, perché RES/DCV cerca ip-10-0-x-xx.ec2.internal hostname.

esempio di nomi di dominio e server di nomi di dominio

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

Errore Firefox MOZILLA_PKIX_ERROR_REQUIRED_TLS_FEATURE_MISSING

Quando si utilizza il browser Web Firefox, è possibile che venga visualizzato il messaggio di errore del tipo MOZILLA_PKIX_ERROR_REQUIRED_TLS_FEATURE_MISSING quando si tenta di connettersi a un desktop virtuale.

La causa è che il server web RES è configurato con TLS + Stapling On ma non risponde con Stapling Validation (vedi https://support.mozilla. org/en-US/questions/1372483.

Puoi risolvere questo problema seguendo le istruzioni su: /mozilla_pkix_error_required_tls_feature_missing. https://really-simple-ssl.com

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

Eliminazione di Env

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

res-xxx-cluster impila nello stato «DELETE_FAILED» e non può essere eliminato manualmente a causa dell'errore «Il ruolo non è valido o non può essere assunto»

Se noti che lo stack "res-xxx-cluster" è nello stato «DELETE_FAILED» e non può essere eliminato manualmente, puoi eseguire le seguenti operazioni per eliminarlo.

Se vedi lo stack nello stato «DELETE_FAILED», prova prima a eliminarlo manualmente. Potrebbe apparire una finestra di dialogo che conferma Delete Stack. Seleziona Elimina.

schermata popup di conferma dell'eliminazione dello stack

A volte, anche se elimini tutte le risorse dello stack richieste, potresti comunque visualizzare il messaggio che richiede di selezionare le risorse da conservare. In tal caso, seleziona tutte le risorse come «risorse da conservare» e seleziona Elimina.

È possibile che venga visualizzato un errore simile a Role: arn:aws:iam::... is Invalid or cannot be assumed

CloudFormation finestra stacks che mostra l'errore di un ruolo non valido

Ciò significa che il ruolo richiesto per eliminare lo stack è stato eliminato prima dello stack. Per ovviare a questo problema, copia il nome del ruolo. Vai alla console IAM e crea un ruolo con quel nome utilizzando i parametri mostrati qui, che sono:

  • Per il tipo di entità affidabile, seleziona il AWS servizio.

  • Per Caso d'uso, in Use cases for other AWS services ScegliCloudFormation.

La finestra di creazione del ruolo di IAM Roles (fase 1) consente di selezionare l'entità affidabile.

Seleziona Avanti. Assicurati di concedere le autorizzazioni al ruolo AWSCloudFormationFullAccess «» e AdministratorAccess «». La tua pagina di recensione dovrebbe avere il seguente aspetto:

questa schermata IAM ti consente di assegnare un nome, rivedere e creare un ruolo

Quindi torna alla CloudFormation console ed elimina lo stack. Ora dovresti essere in grado di eliminarlo dopo aver creato il ruolo. Infine, vai alla console IAM ed elimina il ruolo che hai creato.

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

Raccolta dei registri

Accesso a un' EC2 istanza dalla console EC2

  • Segui queste istruzioni per accedere alla tua EC2 istanza Linux.

  • Segui queste istruzioni per accedere alla tua EC2 istanza Windows. Quindi apri Windows PowerShell per eseguire qualsiasi comando.

Raccolta dei registri degli host dell'infrastruttura

  1. Cluster-manager: recupera i log per il gestore del cluster dai seguenti punti e li allega al ticket.

    1. Tutti i log del gruppo di log. CloudWatch <env-name>/cluster-manager

    2. Tutti i log presenti /root/bootstrap/logs nella directory dell'istanza. <env-name>-cluster-manager EC2 Segui le istruzioni riportate in «Accesso a un' EC2 istanza dalla EC2 console» all'inizio di questa sezione per accedere alla tua istanza.

  2. Controller VDC: recupera i log del controller vdc dai seguenti punti e allegali al ticket.

    1. Tutti i log del gruppo di log. CloudWatch <env-name>/vdc-controller

    2. Tutti i log presenti /root/bootstrap/logs nella directory dell'istanza. <env-name>-vdc-controller EC2 Segui le istruzioni riportate in «Accesso a un' EC2 istanza dalla EC2 console» all'inizio di questa sezione per accedere alla tua istanza.

Uno dei modi per ottenere facilmente i log è seguire le istruzioni contenute nella Scaricamento dei log da istanze Linux EC2 sezione. Il nome del modulo sarebbe il nome dell'istanza.

Raccolta dei registri VDI

Identifica l' EC2 istanza Amazon corrispondente

Se un utente avviasse una VDI con nome di sessioneVDI1, il nome corrispondente dell'istanza sulla EC2 console Amazon sarebbe<env-name>-VDI1-<user name>.

Raccogli i log VDI di Linux

Accedi all' EC2 istanza Amazon corrispondente dalla EC2 console Amazon seguendo le istruzioni collegate a «Accesso a un' EC2 istanza dalla EC2 console» all'inizio di questa sezione. Ottieni tutti i log /var/log/dcv/ nelle directory /root/bootstrap/logs and sull'istanza Amazon EC2 VDI.

Uno dei modi per ottenere i log sarebbe caricarli su s3 e poi scaricarli da lì. Per questo, puoi seguire questi passaggi per ottenere tutti i log da una directory e poi caricarli:

  1. Segui questi passaggi per copiare i log dcv nella directory: /root/bootstrap/logs

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

  2. Ora, segui i passaggi elencati nella prossima sezione Scaricamento dei registri VDI per scaricare i log.

Raccogli i registri VDI di Windows

Accedi all' EC2 istanza Amazon corrispondente dalla EC2 console Amazon seguendo le istruzioni collegate a «Accesso a un' EC2 istanza dalla EC2 console» all'inizio di questa sezione. Ottieni tutti i log $env:SystemDrive\Users\Administrator\RES\Bootstrap\Log\ nella directory dell'istanza EC2 VDI.

Uno dei modi per ottenere i log sarebbe caricarli su S3 e poi scaricarli da lì. Per farlo, segui i passaggi elencati nella sezione successiva-. Scaricamento dei registri VDI

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

Scaricamento dei registri VDI

  1. Aggiorna il ruolo IAM dell' EC2 istanza VDI per consentire l'accesso a S3.

  2. Vai alla EC2 console e seleziona la tua istanza VDI.

  3. Seleziona il ruolo IAM che sta utilizzando.

  4. Nella sezione Politiche di autorizzazione dal menu a discesa Aggiungi autorizzazioni, seleziona Allega politiche, quindi scegli la politica FullAccessAmazonS3.

  5. Seleziona Aggiungi autorizzazioni per allegare quella politica.

  6. Dopodiché, segui i passaggi elencati di seguito in base al tipo di VDI in uso per scaricare i log. Il nome del modulo sarebbe il nome dell'istanza.

    1. Scaricamento dei log da istanze Linux EC2 per Linux.

    2. Scaricamento dei registri dalle istanze di Windows EC2 per Windows.

  7. Infine, modifica il ruolo per rimuovere la AmazonS3FullAccess politica.

Nota

Tutti VDIs utilizzano lo stesso ruolo IAM che è <env-name>-vdc-host-role-<region>

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

Scaricamento dei log da istanze Linux EC2

Accedi all' EC2 istanza da cui desideri scaricare i log ed esegui i seguenti comandi per caricare tutti i log in un 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

Dopodiché, vai alla console S3, seleziona il bucket con il nome <environment_name>-cluster-<region>-<aws_account_number> e scarica il file precedentemente caricato. <module_name>_logs.tar.gz

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

Scaricamento dei registri dalle istanze di Windows EC2

Accedi all' EC2 istanza da cui desideri scaricare i log ed esegui i seguenti comandi per caricare tutti i log in un bucket 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

Dopodiché, vai alla console S3, seleziona il bucket con il nome <environment_name>-cluster-<region>-<aws_account_number> e scarica il file precedentemente caricato. <module_name>_logs.zip

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

Raccolta dei log ECS relativi all'errore WaitCondition

  1. Vai allo stack distribuito e scegli la scheda Risorse.

  2. Espandi Deploy → ResearchAndEngineeringStudio→ Installer → Tasks → → CreateTaskDefCreateContainer→ LogGroupe seleziona il gruppo di log per aprire i log. CloudWatch

  3. Recupera il registro più recente da questo gruppo di log.

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

Ambiente dimostrativo

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

Errore di accesso all'ambiente demo durante la gestione della richiesta di autenticazione al provider di identità

Problema

Se tenti di accedere e ricevi un «Errore imprevisto durante la gestione della richiesta di autenticazione al provider di identità», le tue password potrebbero essere scadute. Potrebbe essere la password dell'utente con cui stai tentando di accedere o il tuo account di Active Directory Service.

Attenuazione

  1. Reimposta le password degli utenti e degli account di servizio nella console del servizio Directory.

  2. Aggiorna le password degli account di servizio in Secrets Manager in modo che corrispondano alla nuova password che hai inserito sopra:

    • per lo stack Keycloak: -... PasswordSecret - -... RESExternal - DirectoryService-... con descrizione: Password per Microsoft Active Directory

    • per RES: res- ServiceAccountPassword -... con descrizione: password dell'account del servizio Active Directory Service

  3. Vai alla EC2 console e termina l'istanza del gestore del cluster. Le regole di Auto Scaling attiveranno automaticamente la distribuzione di una nuova istanza.

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