Risoluzione dei problemi: problemi di condivisione dei file - AWS Storage Gateway

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à.

Risoluzione dei problemi: problemi di condivisione dei file

Di seguito è spiegato cosa fare se si verificano problemi imprevisti nella condivisione file.

La condivisione di file è bloccata nello stato CREATING

Non appena la configuri, alla condivisione file viene assegnato lo stato CREATING (CREAZIONE IN CORSO) che diventa AVAILABLE (DISPONIBILE) solo al termine della creazione. Se la condivisione file si blocca allo stato CREATING (CREAZIONE IN CORSO), occorre procedere come segue:

  1. Apri la console Amazon S3 all'indirizzo. https://console.aws.amazon.com/s3/

  2. Assicurati che il bucket S3 su cui hai mappato la condivisione di file esista. In caso contrario, crearlo. Una volta creato il bucket, lo stato della condivisione file passa a AVAILABLE (DISPONIBILE). Per informazioni su come creare un bucket S3, consulta Create a bucket nella Amazon Simple Storage Service User Guide.

  3. Assicurati che il nome del bucket sia conforme alle regole per la denominazione dei bucket in Amazon S3. Per ulteriori informazioni, consulta le Regole per la denominazione dei bucket nella Guida per l'utente di Amazon Simple Storage Service.

    Nota

    S3 File Gateway non supporta i bucket Amazon S3 con periodi . () nel nome del bucket.

  4. Assicurati che il ruolo IAM che hai usato per accedere al bucket S3 disponga delle autorizzazioni corrette e verifica che il bucket S3 sia elencato come risorsa nella policy IAM. Per ulteriori informazioni, consulta Concessione dell'accesso a un bucket Amazon S3.

Non puoi creare una condivisione di file

  1. Se non riesci a creare una condivisione di file perché la condivisione di file è bloccata nello stato CREATING, verifica che il bucket S3 su cui hai mappato la condivisione di file esista. Per informazioni su come fare, consulta il paragrafo precedente, La condivisione di file è bloccata nello stato CREATING.

  2. Se il bucket S3 esiste, verifica che AWS Security Token Service sia attivato nella regione in cui stai creando la condivisione di file. Se un token di sicurezza non è attivo, è necessario attivarlo. Per informazioni su come attivare un token utilizzando AWS Security Token Service, consulta Attivazione e disattivazione di AWS STS in una AWS regione nella Guida per l'utente IAM.

Le condivisioni di file SMB non consentono più metodi di accesso diversi

Le condivisioni di file SMB hanno le seguenti restrizioni:

  1. Quando lo stesso client tenta di montare sia una condivisione file Active Directory che una condivisione SMB con accesso guest viene visualizzato il seguente messaggio di errore: Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again.

  2. Un utente di Windows non può essere connesso a due condivisioni di file SMB con accesso guest e potrebbe essere disconnesso quando viene stabilita una nuova connessione con accesso guest.

  3. Un client di Windows non è in grado di montare insieme una condivisione file Active Directory e una condivisione SMB con accesso guest esportate dallo stesso gateway.

Più condivisioni di file non possono scrivere sul bucket S3 mappato

Non è consigliabile configurare il bucket S3 per consentire la scrittura di più condivisioni di file su un unico bucket S3. Tale approccio, infatti, è in grado di determinare risultati imprevisti.

Al contrario, è bene consentire a un'unica condivisione file di scrivere su ciascun bucket S3. Per permettere al solo ruolo associato alla tua condivisione file di scrivere sul bucket, puoi creare una policy del bucket. Per ulteriori informazioni, consulta Best Practices for File Gateway.

Notifica per il gruppo di log eliminato quando si utilizzano i log di controllo

Se il gruppo di log non esiste, l'utente può selezionare il collegamento al gruppo di log sotto il messaggio per creare un nuovo gruppo di log o utilizzare un gruppo di log esistente da utilizzare come destinazione per i log di controllo

Impossibile caricare file nel bucket S3

Se non riesci a caricare file nel tuo bucket S3, procedi come segue:

  1. Assicurati di aver concesso l'accesso richiesto ad Amazon S3 File Gateway per caricare file nel tuo bucket S3. Per ulteriori informazioni, consulta Concessione dell'accesso a un bucket Amazon S3.

  2. Verificare che il ruolo che ha creato il bucket sia autorizzato a scrivere nel bucket S3. Per ulteriori informazioni, consulta Best Practices for File Gateway.

  3. Se il tuo File Gateway utilizza SSE-KMS o DSSE-KMS per la crittografia, assicurati che il ruolo IAM associato alla condivisione di file includa le autorizzazioni KMS:Encrypt, KMS:Decrypt, kms: *, kms: e kms:. ReEncrypt GenerateDataKey DescribeKey Per ulteriori informazioni, consulta Using Identity-Based Policies (IAM Policies) for Storage Gateway.

Non riesco a modificare la crittografia predefinita per utilizzare SSE-KMS per crittografare gli oggetti archiviati nel mio bucket S3

Se modifichi la crittografia predefinita e rendi SSE-KMS (crittografia lato server con chiavi AWS KMS gestite) l'impostazione predefinita per il tuo bucket S3, gli oggetti che un Amazon S3 File Gateway memorizza nel bucket non vengono crittografati con SSE-KMS. Per impostazione predefinita, un S3 File Gateway utilizza la crittografia lato server gestita con Amazon S3 (SSE-S3) quando scrive dati in un bucket S3. Modificare l'impostazione predefinita non modificherà automaticamente la crittografia.

Per modificare la crittografia per utilizzare SSE-KMS con la tua chiave, devi attivare la crittografia SSE-KMS. AWS KMS A tale scopo, ti basta fornire l'Amazon Resource Name (ARN) della chiave KMS quando crei la condivisione file. Puoi anche aggiornare le impostazioni KMS per la condivisione file utilizzando l'operazione API UpdateNFSFileShare o UpdateSMBFileShare. Questo aggiornamento si applica agli oggetti archiviati nei bucket S3 dopo l'aggiornamento. Per ulteriori informazioni, consulta Crittografia dei dati utilizzando AWS KMS.

Le modifiche apportate direttamente in un bucket S3 con il controllo delle versioni degli oggetti attivato possono influire su ciò che vedi nella condivisione di file

Se il bucket S3 contiene oggetti scritti da un altro client, la visualizzazione del bucket S3 potrebbe non essere up-to-date il risultato del controllo delle versioni degli oggetti del bucket S3. Prima di esaminare i file d'interesse, occorre aggiornare la cache.

La funzione Versioni multiple degli oggetti è una funzione facoltativa dei bucket S3 che consente di preservare i dati memorizzando più copie di un oggetto con lo stesso nome. A ciascuna copia è assegnato un valore ID univoco, ad esempio file1.jpg: ID="xxx" e file1.jpg: ID="yyy". Il numero di oggetti con lo stesso nome e la loro durata sono controllati dalle politiche del ciclo di vita di Amazon S3. Per ulteriori dettagli su questi concetti di Amazon S3, consulta Using versioning and Object Lifecycle Management nella Amazon S3 Developer Guide.

Un oggetto con versione eliminato acquisisce il contrassegno di eliminazione, ma viene conservato. Solo il proprietario del bucket S3 può eliminare definitivamente un oggetto con la funzione Versioni multiple attiva.

In S3 File Gateway, i file mostrati sono le versioni più recenti degli oggetti in un bucket S3 al momento in cui l'oggetto è stato recuperato o la cache è stata aggiornata. Gli S3 File Gateway ignorano le versioni precedenti o gli oggetti contrassegnati per l'eliminazione. Quando si legge un file, vengono visualizzati i dati della versione più recente. Quando scrivi un file nella condivisione di file, S3 File Gateway crea una nuova versione di un oggetto denominato con le modifiche apportate, e quella versione diventa la versione più recente.

S3 File Gateway continua a leggere dalla versione precedente e gli aggiornamenti che apporti si basano sulla versione precedente nel caso in cui venga aggiunta una nuova versione al bucket S3 al di fuori dell'applicazione. Per leggere la versione più recente di un oggetto, utilizza l'azione RefreshCacheAPI o aggiorna dalla console come descritto in. Aggiornamento della cache degli oggetti del bucket Amazon S3

Importante

Non è consigliabile scrivere oggetti o file nel bucket S3 File Gateway S3 dall'esterno della condivisione di file.

Quando si scrive su un bucket S3 con il controllo delle versioni attivato, Amazon S3 File Gateway può creare più versioni di oggetti Amazon S3

Con il controllo delle versioni degli oggetti attivato, potresti avere più versioni di un oggetto creato in Amazon S3 per ogni aggiornamento di un file dal tuo client NFS o SMB. Ecco alcuni scenari che possono comportare la creazione di più versioni di un oggetto nel bucket S3:

  • Quando un file viene modificato in Amazon S3 File Gateway da un client NFS o SMB dopo che è stato caricato su Amazon S3, S3 File Gateway carica i dati nuovi o modificati anziché caricare l'intero file. La modifica del file comporta la creazione di una nuova versione dell'oggetto Amazon S3.

  • Quando un file viene scritto su S3 File Gateway da un client NFS o SMB, S3 File Gateway carica i dati del file su Amazon S3 seguiti dai relativi metadati (proprietà, timestamp, ecc.). Il caricamento dei dati del file crea un oggetto Amazon S3 e il caricamento dei metadati per il file aggiorna i metadati per l'oggetto Amazon S3. Questo processo crea un'altra versione dell'oggetto, ottenendo due versioni di un oggetto.

  • Quando S3 File Gateway carica file di grandi dimensioni, potrebbe essere necessario caricare porzioni più piccole del file prima che il client abbia finito di scrivere sul File Gateway. Alcuni motivi includono la necessità di liberare spazio nella cache o un'elevata velocità di scrittura su un file. Ciò può comportare più versioni di un oggetto nel bucket S3.

È necessario monitorare il bucket S3 per determinare quante versioni di un oggetto esistono prima di configurare le politiche del ciclo di vita per spostare gli oggetti in classi di storage diverse. È necessario configurare la scadenza del ciclo di vita per le versioni precedenti per ridurre al minimo il numero di versioni di un oggetto nel bucket S3. L'uso della replica Same-Region (SRR) o della replica Cross-Region (CRR) tra i bucket S3 aumenterà lo storage utilizzato. Per ulteriori informazioni sulla replica, vedere Replica.

Importante

Non configurate la replica tra i bucket S3 prima di aver compreso la quantità di storage utilizzata quando viene attivato il controllo delle versioni degli oggetti.

L'uso di bucket S3 con versioni diverse può aumentare notevolmente la quantità di storage in Amazon S3 perché ogni modifica a un file crea una nuova versione dell'oggetto S3. Per impostazione predefinita, Amazon S3 continua a memorizzare tutte queste versioni a meno che non si crei specificamente una policy per ignorare questo comportamento e limitare il numero di versioni che vengono conservate. Se noti un utilizzo insolitamente elevato dello storage con il controllo delle versioni degli oggetti attivato, verifica che le politiche di storage siano impostate in modo appropriato. L'utilizzo della funzione Versioni multiple degli oggetti può provocare, inoltre, l'incremento del numero di risposte HTTP 503-slow down alle richieste del browser.

Se attivi il controllo delle versioni degli oggetti dopo aver installato un S3 File Gateway, tutti gli oggetti unici vengono mantenuti (ID=”NULL”) e puoi vederli tutti nel file system. Alle nuove versioni degli oggetti viene assegnato un ID univoco (le versioni precedenti vengono comunque conservate). Nel file system NFS viene visualizzata solo l'ultima versione dell'oggetto in base al suo time stamp.

Dopo aver attivato il controllo delle versioni degli oggetti, non è possibile ripristinare lo stato senza versioni del bucket S3. Tuttavia, si può sospendere la funzione. In seguito alla sospensione, a un nuovo oggetto viene assegnato un ID. In presenza di un oggetto con lo stesso nome e un valore ID=”NULL”, la versione meno recente viene sovrascritta. Eventuali versioni contenenti un ID diverso da NULL, tuttavia, restano disponibili. I time stamp identificano il nuovo oggetto come quello attuale, nonché l'unico da visualizzare nel file system NFS.

Le modifiche a un bucket S3 non si riflettono in Storage Gateway

Storage Gateway aggiorna automaticamente la cache di condivisione dei file quando si scrivono file nella cache localmente utilizzando la condivisione di file. Tuttavia, Storage Gateway non aggiorna automaticamente la cache quando carichi un file direttamente su Amazon S3. Quando si esegue questa operazione, è necessario eseguire un'RefreshCacheoperazione per visualizzare le modifiche sulla condivisione di file. Se si dispone di più di una condivisione di file, è necessario eseguire l'RefreshCacheoperazione su ciascuna condivisione di file.

È possibile aggiornare la cache utilizzando la console Storage Gateway e AWS Command Line Interface (AWS CLI):

  • Per aggiornare la cache utilizzando la console Storage Gateway, consulta Refreshing objects in your Amazon S3 bucket.

  • Per aggiornare la cache utilizzando: AWS CLI

    1. Esegui il comando aws storagegateway list-file-shares

    2. Copia l'Amazon Resource Number (ARN) della condivisione di file con la cache che desideri aggiornare.

    3. Esegui il refresh-cache comando con il tuo ARN come valore per: --file-share-arn

      aws storagegateway refresh-cache --file-share-arn arn:aws:storagegateway:eu-west-1:12345678910:share/share-FFDEE12

Per automatizzare l'RefreshCacheoperazione, vedi Come posso automatizzare l' RefreshCache operazione su Storage Gateway?

Le autorizzazioni ACL non funzionano come previsto

Se le autorizzazioni della lista di controllo accessi (ACL) non funzionano come previsto con la tua condivisione di file SMB, è possibile eseguire un test.

Per eseguire questa operazione, testa prima le autorizzazioni su un server di file di Microsoft Windows o in una condivisione locale di file Windows. Quindi confronta il comportamento con la condivisione di file del gateway.

Le prestazioni del gateway sono diminuite dopo l'esecuzione di un'operazione ricorsiva

In alcuni casi, è possibile eseguire un'operazione ricorsiva, ad esempio rinominare una directory o attivare l'ereditarietà per un ACL, e forzarla verso il basso nell'albero. Se si esegue questa operazione, S3 File Gateway applica l'operazione in modo ricorsivo a tutti gli oggetti nella condivisione di file.

Ad esempio, supponiamo di applicare l'ereditarietà agli oggetti esistenti in un bucket S3. Il tuo S3 File Gateway applica in modo ricorsivo l'ereditarietà a tutti gli oggetti nel bucket. Tali operazioni possono provocare il peggioramento delle prestazioni del gateway.