Come risolvere i problemi relativi alla condivisione file - AWSStorage Gateway
La condivisione di file è bloccata nello stato CREATINGImpossibile creare una condivisione fileLe condivisioni file SMB non consentono più metodi di accesso diversiLe condivisioni di file multiple non possono scrivere sul bucket S3 mappatoImpossibile caricare file nel bucket S3Impossibile modificare la crittografia predefinita in SSE-KMSLe modifiche apportate direttamente in un bucket S3 con il controllo delle versioni degli oggetti abilitato possono influire su ciò che vedi nella condivisione di fileQuando si scrive su un bucket S3 con il controllo delle versioni degli oggetti abilitato, il gateway di file può creare più versioni di un oggetto S3Le modifiche apportate a un bucket S3 non si riflettono in Storage GatewayLe autorizzazioni di ACL non funzionano come previstoLe prestazioni del gateway sono diminuite dopo un'operazione ricorsiva

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

Come risolvere i problemi relativi alla condivisione 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. Verificare che il bucket S3 su cui è mappata la condivisione 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, consultaCreazione di un bucketnellaGuida dell'utente di Amazon Simple Storage.

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

  4. Verificare che il ruolo IAM utilizzato per accedere al bucket S3 disponga delle autorizzazioni corrette e che il bucket S3 sia elencato tra le risorse nella policy IAM. Per ulteriori informazioni, consultare Concessione dell'accesso a un bucket Amazon S3.

Non è possibile creare una condivisione file

  1. Se non riesci a creare una condivisione file perché si blocca allo stato CREATING (CREAZIONE IN CORSO), verifica innanzitutto che il bucket S3 su cui l'hai mappata esista. Per informazioni su come fare, consulta il paragrafo precedente, La condivisione di file è bloccata nello stato CREATING.

  2. Se il bucket S3 esiste, verificare cheAWS Security Token Serviceè abilitato nella regione in cui vuoi creare la condivisione file. Qualora non fosse già attivo, occorrerà abilitare il token di sicurezza. Per informazioni su come abilitare un token utilizzandoAWS Security Token Service, consultaAttivazione e disattivazioneAWSSTS inAWSRegionnellaIAM User Guide.

Le condivisioni 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.

Le condivisioni di file multiple non possono scrivere sul bucket S3 mappato

Non è consigliabile configurare il bucket S3 in modo da permettervi la scrittura da parte di più condivisioni file. 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, consultare Best practice per la condivisione file.

Impossibile caricare file nel bucket S3

Se non si riesce a caricare file nel bucket S3, occorre procedere come segue:

  1. Verificare di aver concesso le autorizzazioni di accesso necessarie affinché Amazon S3 File Gateway carichi file nel bucket S3. Per ulteriori informazioni, consultare 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, consultare Best practice per la condivisione file.

  3. Se il gateway di file utilizza SSE-KMS per la crittografia, assicurarsi che il ruolo IAM associato alla condivisione di file includakms:Encrypt,kms:Decrypt,KMS: ricrittografa,kms:GenerateDataKey, ekms:DescribeKeyautorizzazioni. Per ulteriori informazioni, consultaUtilizzo di policy basate su identità (Policy IAM) per Storage Gateway.

Impossibile modificare la crittografia predefinita per utilizzare SSE-KMS per crittografare gli oggetti memorizzati nel bucket S3

Se si modifica la crittografia predefinita e si crea la crittografia SSE-KMS (lato server conAWS KMS—managed keys) il valore predefinito per il bucket S3, gli oggetti memorizzati da Amazon S3 File Gateway nel bucket non sono crittografati con SSE-KMS. Per impostazione predefinita, un Gateway file S3 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 in modo da utilizzare SSE-KMS con la chiave AWS KMS, è necessario abilitare la crittografia SSE-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, consultare Crittografia dati utilizzandoAWS KMS.

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

Quando il bucket S3 include oggetti scritti da client alternativi, la sua visualizzazione potrebbe non essere aggiornata a causa della funzione Versioni multiple degli oggetti di un 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. Ad esempio, ad esempio, ogni copia ha un valore ID separatofile1.jpg:ID="xxx"efile1.jpg: ID="yyy". Il numero degli oggetti con lo stesso nome e la loro durata sono regolati dalle policy per il ciclo di vita di Amazon S3. Per ulteriori informazioni su questi concetti di Amazon S3, consultaUso della funzione Versioni multipleeGestione del ciclo di vita degli oggettinellaGuida per gli sviluppatori Amazon S3.

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.

I file mostrati nel gateway S3 sono le versioni più recenti degli oggetti in un bucket S3 al momento del recupero o dell'aggiornamento della cache. Il gateway file S3 ignora le versioni obsolete o eventuali oggetti contrassegnati per l'eliminazione. Quando si legge un file, vengono visualizzati i dati della versione più recente. Quando si scrive un file nella condivisione, il gateway file S3 crea una nuova versione dell'oggetto specificato con le modifiche, che diviene la versione più recente.

Nel caso in cui al bucket S3 venisse aggiunta una nuova versione al di fuori della propria applicazione, il gateway file S3 continuerebbe a leggere dalla versione precedente, sulla quale, inoltre, proseguirebbero a basarsi gli aggiornamenti apportati. Per leggere la versione più recente di un oggetto, utilizzare l'operazione API Aggiorna cache o eseguire l'aggiornamento dalla console come descritto in Aggiornamento di oggetti nel bucket Amazon S3.

Importante

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

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

Con il controllo delle versioni degli oggetti abilitato, potresti avere più versioni di un oggetto create in Amazon S3 per ogni aggiornamento di un file dal tuo client NFS o SMB. Di seguito sono riportati gli 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 invece di 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, il Gateway file S3 carica i dati del file su Amazon S3 seguito 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, risultando in due versioni di un oggetto.

  • Quando S3 File Gateway sta caricando file più grandi, potrebbe essere necessario caricare pezzi più piccoli del file prima che il client abbia finito di scrivere sul gateway di file. Alcuni motivi per questo includono la liberazione di spazio nella cache o un elevato tasso di scritture su un file. Ciò può risultare in più versioni di un oggetto nel bucket S3.

È necessario monitorare il bucket S3 per determinare quante versioni di un oggetto esistono prima di impostare i criteri 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 disponibili per un oggetto nel bucket S3. L'uso della replica della stessa regione (SRR) o della replica Cross-Region (CRR) tra i bucket S3 aumenterà lo storage utilizzato. Per ulteriori informazioni sulla replica, consultaReplica.

Importante

Non configurare la replica tra bucket S3 finché non si capisce quanto spazio di archiviazione viene utilizzato quando è abilitato il controllo delle versioni degli oggetti.

Avvalendosi dei bucket S3 con le versioni, si aumenta molto più spazio di storage in Amazon S3, poiché per ogni modifica a un file viene creata una nuova versione dell'oggetto S3. Per impostazione predefinita, Amazon S3 continua ad archiviare tutte le versioni, a meno che non si crei una policy specifica per ignorare questo comportamento e limitare il numero di versioni conservate. Se noti un utilizzo insolitamente ampio dello spazio di storage con la funzione Versioni multiple degli oggetti attiva, verifica che le policy di storage siano impostate appropriatamente. 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 si abilita il controllo delle versioni degli oggetti dopo l'installazione di un gateway file S3, tutti gli oggetti univoci vengono conservati (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.

Una volta abilitata la funzione Versioni multiple degli oggetti, non è possibile riportare il bucket S3 nello stato senza versione. 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 apportate a un bucket S3 non si riflettono in Storage Gateway

Storage Gateway aggiorna automaticamente la cache di condivisione file quando si scrivono file nella cache localmente utilizzando la condivisione file. Tuttavia, Storage Gateway non aggiorna automaticamente la cache quando carichi un file direttamente su Amazon S3. Quando lo fai, devi eseguire unaRefreshCacheoperazione per vedere le modifiche apportate alla condivisione di file. Se si dispone di più di una condivisione file, è necessario eseguire laRefreshCacheoperazione su ogni condivisione di file.

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

  • Per aggiornare la cache utilizzando la console Storage Gateway, consulta Aggiornamento degli oggetti nel bucket Amazon S3.

  • Per aggiornare la cache utilizzando ilAWS CLI:

    1. Eseguire il comandoaws storagegateway list-file-shares

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

    3. Eseguirerefresh-cachecomando con il tuo ARN come valore--file-share-arn:

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

Per automatizzareRefreshCacheoperazione, vediCome posso automatizzare l'operazione RefreshCache su Storage Gateway?

Le autorizzazioni di 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 aver eseguito un'operazione ricorsiva

In alcuni casi, è possibile eseguire un'operazione ricorsiva, ad esempio la rinomina di una directory o l'abilitazione dell'ereditarietà per una lista ACL e spingerla in fondo alla struttura. In questo caso, il Gateway file S3 applica ricorsivamente l'operazione a tutti gli oggetti nella condivisione file.

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