Solución de problemas: problemas relacionados con recursos compartidos de archivos - AWS Storage Gateway
El recurso compartido de archivos está bloqueado en el estado CREATINGNo se puede crear un recurso compartido de archivosLos recursos compartidos de archivos SMB no permiten varios métodos de acceso diferentesVarios recursos compartidos de archivos no pueden escribir en el bucket de S3 asignadoNotificación de un grupo de registro eliminado cuando se utilizan registros de auditoríaNo puede cargar archivos en el bucket de S3No se puede cambiar el cifrado predeterminado a SSE-KMSLos cambios realizados directamente en un bucket de S3 con el control de versiones de objetos activado pueden afectar a lo que ve en sus archivos compartidosAl escribir en un bucket de S3 con el control de versiones activado, la puerta de enlace de archivo de Amazon S3 puede crear varias versiones de los objetos de Amazon S3Los cambios realizados en un bucket de S3 no se reflejan en Storage GatewayLos permisos de ACL no funcionan según lo previstoEl rendimiento de la puerta de enlace se ha reducido después de realizar una operación recursiva

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Solución de problemas: problemas relacionados con recursos compartidos de archivos

A continuación encontrará información sobre las acciones que debe realizar si experimenta problemas inesperados con recursos compartidos de archivos.

El recurso compartido de archivos está bloqueado en el estado CREATING

Cuando el recurso compartido de archivos se está creando, el estado es CREATING. El estado pasa a ser a AVAILABLE una vez que se crea el recurso compartido de archivos. Si el recurso compartido de archivos se bloquea en el estado CREATING, haga lo siguiente:

  1. Abra la consola de Amazon S3 en https://console.aws.amazon.com/s3/.

  2. Asegúrese de que el bucket de S3 al que ha asignado el recurso compartido de archivos existe. Si el bucket no existe, créelo. Después de crear el bucket, el estado del recurso compartido de archivos pasa a ser AVAILABLE. Para obtener más información sobre cómo crear un bucket de S3, consulte la sección de Crear un bucket en la Guía del usuario de Amazon Simple Storage Service.

  3. Asegúrese de que el nombre del bucket cumple las normas de denominación de bucket de Amazon S3. Para obtener más información, consulte Reglas para nombrar buckets en la Guía del usuario de Amazon Simple Storage Service.

    nota

    La puerta de enlace de archivo de S3 no admite buckets de Amazon S3 con puntos (.) en el nombre del bucket.

  4. Asegúrese de que el rol de IAM que utilizó para acceder al bucket de S3 tiene los permisos adecuados y verifique que el bucket de S3 se muestra como un recurso en la política de IAM. Para obtener más información, consulte Concesión de acceso a un bucket de Amazon S3.

No puede crear un recurso compartido de archivos

  1. Si no puede crear un recurso compartido de archivos porque el recurso compartido de archivos se bloquea en el estado CREATING, verifique que el bucket de S3 al que ha asignado el recurso compartido de archivos existe. Para obtener información acerca de cómo hacerlo, consulte El recurso compartido de archivos está bloqueado en el estado CREATING, más arriba.

  2. Si el bucket de S3 existe, compruebe que AWS Security Token Service esté activado en la región en la que va a crear el recurso compartido de archivos. Si un token de seguridad no está activo, debe activarlo. Para obtener información sobre cómo activar un token mediante AWS Security Token Service, consulte Activación y desactivación del AWS STS en una AWS región en la Guía del usuario de IAM.

Los recursos compartidos de archivos SMB no permiten varios métodos de acceso diferentes

Los recursos compartidos de archivos SMB tienen las siguientes restricciones:

  1. Cuando el mismo cliente intenta montar un recurso compartido de archivos SMB para el acceso de invitado y para Active Directory, se muestra el siguiente mensaje de error: 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 usuario de Windows no puede estar conectado a dos recursos compartidos de archivos SMB para el acceso de invitado y es posible que se le desconecte cuando se establezca una nueva conexión de acceso de invitado.

  3. Un cliente de Windows no puede montar un recurso compartido de archivos SMB para el acceso de invitado y para Active Directory que se haya exportado por la misma gateway.

Varios recursos compartidos de archivos no pueden escribir en el bucket de S3 asignado

No le recomendamos configurar el bucket de S3 para permitir que varios recursos compartidos de archivos escriban en un bucket de S3. Este enfoque puede producir resultados impredecibles.

En su lugar, le recomendamos que solo un recurso compartido de archivos pueda escribir en cada bucket de S3. Puede crear una política de bucket para permitir que únicamente el rol asociado al recurso compartido de archivos escriba en el bucket. Para obtener información, consulte Prácticas recomendadas para la puerta de enlace de archivo.

Notificación de un grupo de registro eliminado cuando se utilizan registros de auditoría

Si el grupo de registro no existe, el usuario puede seleccionar el enlace del grupo de registro que aparece debajo de ese mensaje para crear un nuevo grupo de registro o utilizar un grupo de registro existente para usarlo como destino de los registros de auditoría

No pueden cargar archivos en el bucket de S3

Si no se pueden cargar archivos en el bucket de S3, haga lo siguiente:

  1. Asegúrese de haber concedido el acceso necesario para que la puerta de enlace de archivo de Amazon S3 cargue archivos en el bucket de S3. Para obtener más información, consulte Concesión de acceso a un bucket de Amazon S3.

  2. Asegúrese de que el rol que creó el bucket tenga permiso para escribir en el bucket de S3. Para obtener información, consulte Prácticas recomendadas para la puerta de enlace de archivo.

  3. Si su puerta de enlace de archivos utiliza SSE-KMS o DSSE-KMS para el cifrado, asegúrese de que la función de IAM asociada al recurso compartido de archivos incluya los permisos KMS:Encrypt, KMS:Decrypt, kms: *, kms: y kms:. ReEncrypt GenerateDataKey DescribeKey Para obtener más información, consulte Uso de políticas basadas en identidad (políticas de IAM) para Storage Gateway.

No puede cambiar el cifrado predeterminado para utilizar SSE-KMS con el fin de cifrar los objetos almacenados en el bucket de S3

Si cambia el cifrado predeterminado y establece SSE-KMS (cifrado del servidor con claves administradas por AWS KMS) como predeterminado para el bucket de S3, los objetos que la puerta de enlace de archivo de Amazon S3 almacena en el bucket no se cifran con SSE-KMS. De forma predeterminada, una puerta de enlace de archivo de S3 utiliza el cifrado del servidor administrado con Amazon S3 (SSE-S3) cuando escribe datos en un bucket de S3. Cambiar la configuración predeterminada no cambiará el cifrado automáticamente.

Para cambiar el cifrado para usar SSE-KMS con su propia AWS KMS clave, debe activar el cifrado SSE-KMS. Para ello, debe proporcionar el nombre de recurso de Amazon (ARN) de la clave de KMS al crear el recurso compartido de archivos. También puede actualizar la configuración de KMS para el recurso compartido de archivos utilizando operación UpdateNFSFileShare o UpdateSMBFileShare de la API. Esta actualización se aplica a los objetos almacenados en los buckets de S3 después de la actualización. Para obtener más información, consulte Cifrado de datos mediante AWS KMS.

Los cambios realizados directamente en un bucket de S3 con el control de versiones de objetos activado pueden afectar a lo que ve en sus archivos compartidos

Si su bucket de S3 tiene objetos escritos en él por otro cliente, es up-to-date posible que su visión del bucket de S3 no se deba al control de versiones de los objetos del bucket de S3. Actualice siempre la caché antes de examinar los archivos que le interesen.

El control de versiones de objetos es una característica opcional del bucket de S3 que ayuda a proteger los datos al almacenar varias copias del objeto con el mismo nombre. Cada copia tiene un valor de ID independiente, por ejemplo file1.jpg: ID="xxx" y file1.jpg: ID="yyy". El número de objetos con nombres idénticos y su duración se controla mediante las políticas de ciclo de vida de Amazon S3. Para obtener más información sobre estos conceptos de Amazon S3, consulte Uso del control de versiones y Administración del ciclo de vida de los objetos en la Guía para desarrolladores de Amazon S3.

Cuando se elimina un objeto con control de versiones, ese objeto se marca con un marcador de eliminación pero se conserva. Solo el propietario de un bucket de S3 puede eliminar definitivamente un objeto con el control de versiones activado.

Los archivos que se muestran en la puerta de enlace de archivo de S3 son las versiones más recientes de los objetos de un bucket de S3 en el momento en que el que se recuperó el objeto o se actualizó la caché. Las puertas de enlace de archivo de S3 omiten las versiones anteriores o los objetos marcados para su eliminación. Cuando se lee un archivo, los datos que se leen son de la versión más reciente. Al escribir un archivo en el recurso compartido de archivos, la puerta de enlace de archivo de S3 crea una nueva versión de un objeto con nombre con los cambios y esa versión pasa a ser la versión más reciente.

La puerta de enlace de archivo de S3 sigue leyendo la versión anterior y las actualizaciones que se realicen estarán basadas en la versión anterior si se añade una versión nueva al bucket de S3 fuera de la aplicación. Para leer la versión más reciente de un objeto, usa la acción de la RefreshCacheAPI o actualiza desde la consola, tal y como se describe enActualización de la caché de objetos del bucket de Amazon S3.

importante

No recomendamos que se escriban objetos o archivos en el bucket de S3 de la puerta de enlace de archivo de S3 desde fuera del recurso compartido de archivos.

Al escribir en un bucket de S3 con el control de versiones activado, la puerta de enlace de archivo de Amazon S3 puede crear varias versiones de los objetos de Amazon S3

Con el control de versiones de objetos activado, es posible que cree varias versiones de un objeto en Amazon S3 en cada actualización de un archivo desde su cliente de NFS o SMB. Estos son algunos escenarios que pueden provocar la creación de varias versiones de un objeto en el bucket de S3:

  • Cuando un cliente de NFS o SMB modifica un archivo en la puerta de enlace de archivo de Amazon S3 después de cargarlo en Amazon S3, la puerta de enlace de archivo de S3 carga los datos nuevos o modificados en lugar de cargar todo el archivo. La modificación del archivo da como resultado la creación de una nueva versión del objeto de Amazon S3.

  • Cuando un cliente de NFS o SMB escribe un archivo en la puerta de enlace de archivo de S3, la puerta de enlace de archivo de S3 carga los datos del archivo en Amazon S3 seguidos de sus metadatos (propietarios, marcas de tiempo, etc.). Al cargar los datos del archivo, se crea un objeto de Amazon S3 y, al cargar los metadatos del archivo, se actualizan los metadatos del objeto de Amazon S3. Este proceso crea otra versión del objeto, lo que da como resultado dos versiones de un objeto.

  • Cuando la puerta de enlace de archivo de S3 carga archivos más grandes, es posible que tenga que cargar partes más pequeñas del archivo antes de que el cliente termine de escribir en la puerta de enlace de archivo. Esto se debe, entre otros motivos, a la necesidad de liberar espacio en la caché o a una alta tasa de escrituras en un archivo. Esto puede dar lugar a varias versiones de un objeto en el bucket de S3.

Debe supervisar el bucket de S3 para determinar cuántas versiones de un objeto existen antes de configurar políticas de ciclo de vida para mover los objetos a diferentes clases de almacenamiento. Debe configurar el vencimiento del ciclo de vida de las versiones anteriores a fin de minimizar la cantidad de versiones que tiene para un objeto en su bucket de S3. El uso de replicación en la misma región (SRR) o replicación entre regiones (CRR) entre buckets de S3 aumentará el almacenamiento utilizado. Para obtener más información acerca de la replicación, consulte Replicación.

importante

No configure la replicación entre buckets de S3 hasta que sepa cuánto almacenamiento se utiliza cuando está activado el control de versiones de objetos.

El uso de buckets de S3 con control de versiones puede aumentar en gran medida la cantidad de almacenamiento en S3, ya que cada modificación que se realiza en un archivo crea una versión nueva del objeto de S3. De forma predeterminada, Amazon S3 continúa almacenando todas estas versiones a menos que se cree específicamente una política para anular este comportamiento y limitar el número de versiones que se conservan. Si observa un uso del almacenamiento excepcionalmente elevado cuando está activado el control de versiones de objetos, compruebe si ha establecido de forma apropiada las políticas de almacenamiento. Un aumento en el número de respuestas HTTP 503-slow down a las solicitudes del navegador también puede indicar la existencia de problemas con el control de versiones de objetos.

Si activa el control de versiones de objetos después de instalar una puerta de enlace de archivo de S3, todos los objetos únicos se conservan (ID=”NULL”) y podrá verlos en el sistema de archivos. A las versiones nuevas de los objetos se les asigna un ID exclusivo (las versiones anteriores se conservan). Basándose en la marca temporal del objeto, solo se puede ver el objeto con control de versiones más reciente en el sistema de archivos de NFS.

Una vez activado el control de versiones de objetos, el bucket de S3 no puede volver a un estado sin control de versiones. Sin embargo, sí que se puede suspender el control de versiones. Al suspender el control de versiones, a los objetos nuevos se les asigna un ID. Si el objeto con el mismo nombre existe con un valor ID=”NULL”, la versión anterior se sobrescribe. Sin embargo, las versiones que contengan ID que no sean NULL se conservan. Las marcas temporales identifican el objeto nuevo como el objeto actual y ese el que aparece en el sistema de archivos de NFS.

Los cambios realizados en un bucket de S3 no se reflejan en Storage Gateway

Storage Gateway actualiza la caché del recurso compartido de archivos automáticamente cuando se escriben archivos en la caché de forma local mediante el recurso compartido de archivos. Sin embargo, Storage Gateway no actualiza automáticamente la caché cuando se carga un archivo directamente en Amazon S3. Al hacerlo, debe realizar una operación RefreshCache para ver los cambios realizados en el recurso compartido de archivos. Si tiene más de un recurso compartido de archivos, debe ejecutar la operación RefreshCache en cada recurso compartido de archivos.

Puede actualizar la caché mediante la consola de Storage Gateway y la AWS Command Line Interface (AWS CLI):

  • Para actualizar la caché mediante la consola de Storage Gateway, consulte Actualización de objetos en el bucket de Amazon S3.

  • Para actualizar la caché mediante la AWS CLI:

    1. Ejecute el comando aws storagegateway list-file-shares

    2. Copie el número de recurso de Amazon (ARN) del recurso compartido de archivos con la caché que quiera actualizar.

    3. Ejecute el comando refresh-cache con su ARN como valor para --file-share-arn:

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

Para automatizar la RefreshCache operación, consulte ¿Cómo puedo automatizar la RefreshCache operación en Storage Gateway?

Los permisos de ACL no funcionan según lo previsto

Si los permisos de lista de control de acceso (ACL) no funcionan según lo previsto en un recurso compartido de archivos SMB, puede hacer una prueba.

Para ello, en primer lugar, pruebe los permisos en un servidor de archivos de Microsoft Windows o un recurso compartido de archivos de Windows local. A continuación, compare el comportamiento con el del recurso compartido de archivos de la gateway.

El rendimiento de la puerta de enlace se ha reducido después de realizar una operación recursiva

En algunos casos, es posible que realice una operación recursiva, como por ejemplo, cambiar el nombre de un directorio o activar la herencia de una ACL y forzar su propagación por el árbol. Si lo hace, la puerta de enlace de archivo de S3 aplica de forma recursiva la operación a todos los objetos del recurso compartido de archivos.

Por ejemplo, supongamos que aplica una herencia a los objetos existentes en un bucket de S3. La puerta de enlace de archivo de S3 aplica de forma recursiva la herencia a todos los objetos del bucket. Este tipo de operaciones pueden provocar la degradación del rendimiento de la gateway.