Maximización del rendimiento de la puerta de enlace de archivo de S3 - AWS Storage Gateway

Amazon FSx File Gateway ya no está disponible para nuevos clientes. Los clientes actuales de FSx File Gateway pueden seguir utilizando el servicio con normalidad. Para obtener información sobre funciones similares a las de FSx File Gateway, visite esta entrada de blog.

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.

Maximización del rendimiento de la puerta de enlace de archivo de S3

En las siguientes secciones se describen las prácticas recomendadas para maximizar el rendimiento entre los clientes de NFS y SMB, la puerta de enlace de archivo de S3 y Amazon S3. Las directrices que se proporcionan en cada sección contribuyen gradualmente a mejorar el rendimiento general. Si bien ninguna de estas recomendaciones es obligatoria y estas no son interdependientes, se han seleccionado y ordenado de la forma lógica en que Soporte las emplea para probar y ajustar las implementaciones de la puerta de enlace de archivo de S3. Al implementar y probar estas sugerencias, tenga en cuenta que cada implementación de la puerta de enlace de archivo de S3 es única, por lo que los resultados pueden variar.

La puerta de enlace de archivo de S3 proporciona una interfaz de archivos para almacenar y recuperar objetos de Amazon S3 mediante protocolos de archivos NFS o SMB estándares del sector, con una asignación 1:1 nativa entre el archivo y el objeto. Puede implementar la puerta de enlace de archivo de S3 como una máquina virtual en las instalaciones en un entorno KVM de VMware, Microsoft Hyper-V o en la nube de AWS como una instancia de Amazon EC2. La puerta de enlace de archivo de S3 no está diseñada para sustituir completamente a la NAS empresarial. La puerta de enlace de archivo de S3 emula un sistema de archivos, pero no lo es. El uso de Amazon S3 como almacenamiento interno de backend genera una sobrecarga adicional en cada operación de E/S, por lo que evaluar el rendimiento de la puerta de enlace de archivo de S3 con respecto a una NAS o un servidor de archivos existente no es una comparación equivalente.

Implementar la puerta de enlace en la misma ubicación que los clientes

Se recomienda implementar el dispositivo virtual de puerta de enlace de archivo de S3 en una ubicación física con la menor latencia de red posible entre este y sus clientes de NFS o SMB. A la hora de elegir una ubicación para la puerta de enlace, tenga en cuenta lo siguiente:

  • Una menor latencia de la red en la puerta de enlace puede ayudar a mejorar el rendimiento de los clientes de NFS o SMB.

  • La puerta de enlace de archivo de S3 está diseñada para tolerar una latencia de red más alta entre la puerta de enlace y Amazon S3 que entre la puerta de enlace y los clientes.

  • Para las instancias de la puerta de enlace de archivo de S3 implementadas en Amazon EC2, se recomienda mantener la puerta de enlace y los clientes de NFS o SMB en el mismo grupo de ubicación. Para obtener más información, consulte Grupos de ubicación para instancias de Amazon EC2 en la Guía del usuario de Amazon Elastic Compute Cloud.

Reducir los cuellos de botella causados por la lentitud de los discos

Se recomienda supervisar la métrica IoWaitPercent de CloudWatch para detectar los cuellos de botella en el rendimiento generados por la lentitud de los discos de almacenamiento en la puerta de enlace de archivo de S3. Al intentar optimizar los problemas de rendimiento relacionados con los discos, tenga en cuenta lo siguiente:

  • IoWaitPercent indica el porcentaje de tiempo que la CPU está a la espera de recibir una respuesta de los discos raíz o de caché.

  • Cuando IoWaitPercent es superior al 5 o 10 %, esto suele indicar un cuello de botella en el rendimiento de la puerta de enlace provocado por discos con bajo rendimiento. Esta métrica debe estar lo más cerca posible del 0 %, lo que significa que la puerta de enlace nunca espera en el disco, lo que ayuda a optimizar los recursos de la CPU.

  • Puede consultar IoWaitPercent en la pestaña Supervisión de la consola de Storage Gateway o configurar las alarmas de CloudWatch recomendadas para que le notifiquen automáticamente si la métrica supera un umbral específico. Para obtener más información, consulte Creación de alarmas de CloudWatch recomendadas para la puerta de enlace.

  • Se recomienda utilizar discos NVMe o SSD para los discos raíz y de caché de la puerta de enlace a fin de minimizar IoWaitPercent.

Ajustar la asignación de recursos de la máquina virtual para los discos de CPU, RAM y caché

Al intentar optimizar el rendimiento de la puerta de enlace de archivo de S3, es importante asignar suficientes recursos a la máquina virtual de puerta de enlace, incluidos los discos de CPU, RAM y caché. Los requisitos mínimos de recursos virtuales de 4 CPU, 16 GB de RAM y 150 GB de almacenamiento en caché suelen ser adecuados solo para cargas de trabajo más pequeñas. Al asignar recursos virtuales a cargas de trabajo más grandes, se recomienda lo siguiente:

  • Aumente la cantidad de CPU asignadas a entre 16 y 48, según el uso de CPU típico generado por su puerta de enlace de archivo de S3. Puede supervisar el uso de la CPU mediante la métrica UserCpuPercent. Para obtener más información, consulte Descripción de métricas de la puerta de enlace.

  • Aumente la RAM asignada a entre 32 y 64 GB.

    nota

    La puerta de enlace de archivo S3 no puede utilizar más de 64 GB de RAM.

  • Utilice discos NVMe o SSD para los discos raíz y el disco de caché, y ajuste el tamaño de los discos de caché para adaptarlos al conjunto de datos de trabajo máximo que planea escribir en la puerta de enlace. Para obtener más información, consulte Prácticas recomendadas sobre el dimensionamiento de la memoria caché de la puerta de enlace de archivo de S3 en el canal oficial de YouTube de Amazon Web Services.

  • Añada al menos 4 discos de caché virtuales a la puerta de enlace, en lugar de utilizar un único disco grande. Varios discos virtuales pueden mejorar el rendimiento incluso si comparten el mismo disco físico subyacente, pero las mejoras suelen ser mayores cuando los discos virtuales se encuentran en discos físicos subyacentes diferentes.

    Por ejemplo, si quiere implementar 12 TB de caché, puede utilizar una de las siguientes configuraciones:

    • 4 discos de caché de 3 TB

    • 8 discos de caché de 1,5 TB

    • 12 discos de caché de 1 TB

    Esto no solo permite una administración más eficiente del rendimiento, sino también de la máquina virtual a lo largo del tiempo. A medida que cambie su carga de trabajo, puede aumentar gradualmente la cantidad de discos de caché y la capacidad total de caché, al tiempo que mantiene el tamaño original de cada disco virtual individual para preservar la integridad de la puerta de enlace.

    Para obtener más información, consulte Cálculo de la cantidad de almacenamiento en disco local.

Cuando implemente la puerta de enlace de archivo de S3 como una instancia de Amazon EC2, tenga en cuenta lo siguiente:

  • El tipo de instancia que elija puede afectar significativamente al rendimiento de la puerta de enlace. Amazon EC2 ofrece una amplia flexibilidad para ajustar la asignación de recursos para la instancia de la puerta de enlace de archivo de S3.

  • Para ver los tipos de instancia de Amazon EC2 recomendados para la puerta de enlace de archivo de S3, consulte Requisitos para los tipos de instancia de Amazon EC2.

  • Puede cambiar el tipo de instancia de Amazon EC2 que aloja una puerta de enlace de archivo de S3 activa. Esto le permite ajustar fácilmente la generación de hardware y la asignación de recursos de Amazon EC2 para encontrar una relación precio-rendimiento ideal. Para cambiar el tipo de instancia, utilice el siguiente procedimiento en la consola de Amazon EC2:

    1. Detenga la instancia de Amazon EC2.

    2. Cambie el tipo de instancia de Amazon EC2.

    3. Encienda la instancia de Amazon EC2.

    nota

    Si detiene una instancia que aloja una puerta de enlace de archivo de S3, se interrumpirá temporalmente el acceso a los recursos compartidos de archivos. Asegúrese de programar un período de mantenimiento si es necesario.

  • La relación precio-rendimiento de una instancia de Amazon EC2 se refiere a la potencia informática que obtiene por el precio que paga. Por lo general, las instancias Amazon EC2 de nueva generación ofrecen la mejor relación precio-rendimiento, con un hardware más nuevo y un rendimiento mejorado a un coste relativamente menor en comparación con las generaciones anteriores. Factores como el tipo de instancia, la región y los patrones de uso influyen en esta relación, por lo que es importante seleccionar la instancia adecuada para su carga de trabajo específica a fin de optimizar la rentabilidad.

Ajustar el nivel de seguridad de SMB

El protocolo SMBv3 permite tanto la firma como el cifrado SMB, lo que tiene algunas desventajas en términos de rendimiento y seguridad. Para optimizar el rendimiento, puede ajustar el nivel de seguridad de SMB de la puerta de enlace para especificar cuáles de estas características de seguridad se aplican a las conexiones de los clientes. Para obtener más información, consulte Establecer un nivel de seguridad para la puerta de enlace.

A la hora de ajustar el nivel de seguridad de SMB, tenga en cuenta lo siguiente:

  • El nivel de seguridad predeterminado para la puerta de enlace de archivo de S3 Aplicar cifrado. Esta configuración aplica tanto el cifrado como la firma de las conexiones de los clientes de SMB a los recursos compartidos de archivos de la puerta de enlace, lo que significa que todo el tráfico del cliente a la puerta de enlace está cifrado. Esta configuración no afecta al tráfico desde la puerta de enlace a AWS, que siempre está cifrado.

    La puerta de enlace limita cada conexión de cliente cifrada a una sola vCPU. Por ejemplo, si solo tiene un cliente cifrado, ese cliente estará limitado a solo 1 vCPU, aunque se asignen 4 o más vCPU a la puerta de enlace. Por este motivo, el rendimiento de las conexiones cifradas desde un único cliente a la puerta de enlace de archivo de S3 suele tener cuellos de botella entre 40 y 60 MB/s.

  • Si sus requisitos de seguridad le permiten adoptar una postura más flexible, puede cambiar el nivel de seguridad a negociado con el cliente, lo que deshabilitará el cifrado SMB y solo aplicará la firma SMB. Con esta configuración, las conexiones de los clientes a la puerta de enlace pueden utilizar varias vCPU, lo que normalmente se traduce en un aumento del rendimiento.

    nota

    Tras cambiar el nivel de seguridad de SMB de la puerta de enlace de archivo de S3, debe esperar a que el estado del recurso compartido de archivos cambie de Actualizado a Disponible en la consola de la Storage Gateway y, a continuación, desconectar y volver a conectar los clientes de SMB para que se aplique la nueva configuración.

Utilizar varios subprocesos y clientes para paralelizar las operaciones de escritura

Es difícil lograr el máximo rendimiento con una puerta de enlace de archivo de S3 que utilice solo un cliente de NFS o SMB para escribir un archivo a la vez, ya que la escritura secuencial desde un único cliente es una operación de subproceso único. En su lugar, se recomienda usar varios subprocesos de cada cliente de NFS o SMB para escribir varios archivos en paralelo y usar varios clientes de NFS o SMB simultáneamente en la puerta de enlace de archivo de S3 para maximizar el rendimiento de la puerta de enlace.

El uso de varios subprocesos puede mejorar considerablemente el rendimiento. Sin embargo, el uso de más subprocesos requiere más recursos del sistema, lo que puede afectar negativamente al rendimiento si la puerta de enlace no tiene el tamaño adecuado para soportar el aumento de carga. En una implementación típica, cabe esperar un mejor rendimiento de procesamiento a medida que agrega más subprocesos y clientes, hasta alcanzar las limitaciones máximas de hardware y ancho de banda para la puerta de enlace. Se recomienda experimentar con distintos números de subprocesos para encontrar el equilibrio óptimo entre la velocidad y el uso de recursos del sistema para la configuración específica de hardware y red.

Tenga en cuenta la siguiente información sobre las herramientas habituales que pueden ayudar a probar la configuración de subprocesos y clientes:

  • Puede probar el rendimiento de escritura de varios subprocesos mediante herramientas como la robocopia para copiar un conjunto de archivos en un recurso compartido de archivos de la puerta de enlace. De forma predeterminada, la robocopia utiliza 8 subprocesos al copiar archivos, pero se pueden especificar hasta 128 subprocesos.

    Para utilizar varios subprocesos con robocopia, añada el conmutador /MT:n al comando, donde n indica el número de subprocesos que desea utilizar. Por ejemplo:

    robocopy C:\source D:\destination /MT:64

    Este comando utilizará 64 subprocesos para la operación de copia.

    nota

    No se recomienda utilizar el Explorador de Windows para arrastrar y soltar archivos cuando se intenta obtener el máximo rendimiento, ya que este método se limita a un único subproceso y copia los archivos secuencialmente.

    Para obtener más información, consulte robocopy en el sitio web de Microsoft Learn.

  • También puede realizar pruebas con herramientas comunes de análisis comparativo de almacenamiento, como DISKSPD o FIO. Estas herramientas disponen de opciones para ajustar la cantidad de subprocesos, la profundidad de E/S y otros parámetros para adaptarlos a los requisitos de carga de trabajo específicos.

    DiskSpd permite controlar el número de subprocesos mediante el parámetro -t. Por ejemplo:

    diskspd -c10G -d300 -r -w50 -t64 -o32 -b1M -h -L C:\testfile.dat

    Este comando de ejemplo hace lo siguiente:

    • Crea un archivo de prueba de 10 GB (-c1G)

    • Se ejecuta durante 300 segundos (-d300)

    • Realiza una prueba de E/S aleatoria con un 50 % de lecturas y un 50 % de escrituras (-r -w50)

    • Utiliza 64 subprocesos (-t64)

    • Establece la profundidad de cola en 32 por subproceso (-o32)

    • Utiliza un tamaño de bloque de 1 MB (-b1M)

    • Deshabilita el almacenamiento en caché de hardware y software (-h -L)

    Para obtener más información, consulte Use DISKSPD to test workload storage performance en el sitio web de Microsoft Learn.

  • FIO usa el parámetro numjobs para controlar el número de subprocesos paralelos. Por ejemplo:

    fio --name=mixed_test --rw=randrw --rwmixread=70 --bs=1M -- iodepth=64 --size=10G --runtime=300 --numjobs=64 --ioengine=libaio --direct=1 --group_reporting

    Este comando de ejemplo hace lo siguiente:

    • Realiza una prueba de E/S aleatoria (--rw=randrw)

    • Realiza un 70 % de lecturas y un 30 % de escrituras (--rwmixread=70)

    • Utiliza un tamaño de bloque de 1 MB (--bs=1M)

    • Establece la profundidad de E/S en 64 (--iodepth=64)

    • Realiza pruebas en un archivo de 10 GB (--size=10G)

    • Se ejecuta durante 5 minutos (--runtime=300)

    • Crea 64 trabajos paralelos (subprocesos) (--numjobs=64)

    • Utiliza un motor de E/S asíncrono (--ioengine=libaio)

    • Agrupa los resultados para facilitar el análisis (--group_reporting)

    Para obtener más información, consulte la página del manual de Linux fio.

Desactivar la actualización automática de la caché

La característica de actualización automática de la caché permite a la puerta de enlace de archivo de S3 actualizar los metadatos automáticamente, para ayudar a capturar cualquier cambio que los usuarios o las aplicaciones realicen en el conjunto de archivos escribiéndolos directamente en el bucket de Amazon S3, en lugar de hacerlo a través de la puerta de enlace. Para obtener más información, consulte Actualización de la caché de objetos del bucket de Amazon S3.

Para optimizar el rendimiento de la puerta de enlace, se recomienda desactivar esta característica en las implementaciones en las que todas las lecturas y escrituras del bucket de Amazon S3 se realicen a través de la puerta de enlace de archivo de S3.

A la hora de configurar la actualización automática de la caché, tenga en cuenta lo siguiente:

  • Si necesita utilizar la actualización automática de la caché porque los usuarios o las aplicaciones de la implementación a veces escriben directamente en Amazon S3, se recomienda configurar el intervalo de tiempo más largo posible entre las actualizaciones, aquel que mejor se adapte a las necesidades de su empresa. Un intervalo de actualización de la caché más prolongado ayuda a reducir la cantidad de operaciones de metadatos que la puerta de enlace debe realizar al explorar directorios o modificar archivos.

    Por ejemplo: configure la actualización automática de la caché en 24 horas, en lugar de 5 minutos, si es tolerable para su carga de trabajo.

  • El intervalo de tiempo mínimo es de 5 minutos. El intervalo máximo es 30 días.

  • Si decide configurar un intervalo de actualización de la caché muy corto, se recomienda probar la experiencia de navegación de directorios de los clientes de NFS y SMB. El tiempo que se tarda en actualizar la caché de la puerta de enlace puede aumentar considerablemente en función del número de archivos y subdirectorios del bucket de Amazon S3.

Aumentar el número de subprocesos del cargador de Amazon S3

De forma predeterminada, la puerta de enlace de archivo de S3 abre 8 subprocesos para la carga de datos de Amazon S3, lo que proporciona suficiente capacidad de carga para la mayoría de las implementaciones habituales. Sin embargo, es posible que una puerta de enlace reciba datos de clientes de NFS y SMB a una velocidad superior a la que puede cargar en Amazon S3 con la capacidad estándar de 8 subprocesos, lo que puede provocar que la caché local alcance su límite de almacenamiento.

En circunstancias específicas, Soporte puede aumentar el número de subprocesos de carga de Amazon S3 para la puerta de enlace de 8 a 40, lo que permite cargar más datos en paralelo. En función del ancho de banda y de otros factores específicos de la implementación, esto puede aumentar considerablemente el rendimiento de carga y ayudar a reducir la cantidad de almacenamiento en caché necesaria para soportar la carga de trabajo.

Se recomienda utilizar la métrica CachePercentDirty de CloudWatch para supervisar la cantidad de datos almacenados en los discos de caché de la puerta de enlace local que aún no se han cargado en Amazon S3 y ponerse en contacto con Soporte para determinar si aumentar el número de subprocesos de carga podría mejorar el rendimiento de la puerta de enlace de archivo de S3. Para obtener más información, consulte Descripción de métricas de la puerta de enlace.

nota

Esta configuración consume recursos adicionales de la CPU de la puerta de enlace. Se recomienda supervisar el uso de la CPU de la puerta de enlace y aumentar los recursos de CPU asignados si es necesario.

Aumentar la configuración de tiempo de espera de SMB

Cuando la puerta de enlace de archivo de S3 copia archivos de gran tamaño en un recurso compartido de archivos SMB, el tiempo de espera de la conexión del cliente de SMB puede agotarse después de un período prolongado.

Se recomienda ampliar el tiempo de espera de las sesiones de SMB para sus clientes de SMB a 20 minutos o más, según el tamaño de los archivos y la velocidad de escritura de la puerta de enlace. El valor predeterminado es 300 segundos o 5 minutos. Para obtener más información, consulte El trabajo de copia de seguridad de la puerta de enlace falla o se producen errores al escribir en la puerta de enlace.

Activar el bloqueo oportunista para las aplicaciones compatibles

El bloqueo oportunista, u “oplocks”, está activado de forma predeterminada para cada nueva puerta de enlace de archivo de S3. Al usar oplocks con aplicaciones compatibles, el cliente agrupa varias operaciones más pequeñas en operaciones más grandes, lo que resulta más eficiente para el cliente, la puerta de enlace y la red. Se recomienda mantener activado el bloqueo oportunista si utiliza aplicaciones que aprovechan el almacenamiento en caché local del lado del cliente, como Microsoft Office, Adobe Suite y muchas otras, ya que puede mejorar considerablemente el rendimiento.

Si se desactiva el bloqueo oportunista, las aplicaciones que admiten oplocks suelen abrir archivos grandes (de 50 MB o más) con mucha más lentitud. Este retraso se debe a que la puerta de enlace envía los datos en partes de 4 KB, lo que se traduce en un alto nivel de E/S y un bajo rendimiento.

Ajustar la capacidad de la puerta de enlace en función del tamaño del conjunto de archivos de trabajo

El parámetro de capacidad de la puerta de enlace especifica el número máximo de archivos para los que la puerta de enlace almacenará los metadatos en su caché local. De forma predeterminada, la capacidad de la puerta de enlace está establecida en Pequeña, lo que significa que la puerta de enlace almacena metadatos de hasta 5 millones de archivos. La configuración predeterminada es idónea para la mayoría de las cargas de trabajo, aunque haya cientos de millones o incluso miles de millones de objetos en Amazon S3, ya que solo se accede activamente a un pequeño subconjunto de archivos en un momento dado en una implementación típica. Este grupo de archivos se denomina “conjunto de trabajo”.

Si su carga de trabajo accede con regularidad a un conjunto de trabajo de archivos de más de 5 millones, la puerta de enlace tendrá que realizar frecuentes expulsiones de caché, que son pequeñas operaciones de E/S que se almacenan en la RAM y persisten en el disco raíz. Esto puede afectar negativamente al rendimiento de la puerta de enlace, ya que la puerta de enlace obtiene datos nuevos de Amazon S3.

Puede supervisar la métrica IndexEvictions para determinar el número de archivos cuyos metadatos se expulsaron de la memoria caché y dejar espacio para nuevas entradas. Para obtener más información, consulte Descripción de métricas de la puerta de enlace.

Se recomienda utilizar la acción de la API UpdateGatewayInformation para aumentar la capacidad de la puerta de enlace y adaptarla al número de archivos del conjunto de trabajo habitual. Para obtener más información, consulte UpdateGatewayInformation.

nota

El aumento de la capacidad de la puerta de enlace requiere RAM y capacidad de disco raíz adicionales.

  • Los discos pequeños (5 millones de archivos) requieren al menos 16 GB de RAM y 80 GB de disco raíz.

  • El tamaño mediano (10 millones de archivos) requiere al menos 32 GB de RAM y 160 GB de disco raíz.

  • El disco grande (20 millones de archivos) requiere 64 GB de RAM y 240 GB de disco raíz.

importante

La capacidad de la puerta de enlace no se puede reducir.

Implementar varias puertas de enlace para cargas de trabajo más grandes

Se recomienda dividir la carga de trabajo en varias puertas de enlace siempre que sea posible, en lugar de consolidar muchos recursos compartidos de archivos en una sola puerta de enlace grande. Por ejemplo, puede aislar un recurso compartido de archivos muy utilizado en una puerta de enlace y agrupar los recursos compartidos de archivos que se utilizan con menos frecuencia en otra puerta de enlace.

Al planificar una implementación con varias puertas de enlace y recursos compartidos de archivos, tenga en cuenta lo siguiente:

  • El número máximo de recursos compartidos de archivos en una sola puerta de enlace es de 50, pero el número de recursos compartidos de archivos gestionados por una puerta de enlace puede afectar al rendimiento de la puerta de enlace. Para obtener más información, consulte Directrices de rendimiento para puertas de enlace con varios recursos compartidos de archivos.

  • Los recursos de cada puerta de enlace de archivo de S3 se comparten entre todos los recursos compartidos de archivos, sin necesidad de particionarlos.

  • Un único recurso compartido de archivos con un uso intensivo puede afectar al rendimiento de otros recursos compartidos de archivos de la puerta de enlace.

nota

No se recomienda crear varios recursos compartidos de archivos que estén asignados a la misma ubicación de Amazon S3 desde varias puertas de enlace, a menos que al menos una de ellas sea de solo lectura.

Las escrituras simultáneas en el mismo archivo desde varias puertas de enlace se consideran un escenario multiescritura, lo que puede provocar problemas de integridad de los datos.