Maximizar el rendimiento de S3 File Gateway

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

S3 File Gateway 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 un mapeo 1:1 nativo entre el archivo y el objeto. Puede implementar S3 File Gateway como una máquina virtual local en su VMware entorno KVM de Microsoft Hyper-V o Linux, o en la nube AWS como una instancia de Amazon. EC2 S3 File Gateway no está diseñado para sustituir completamente al NAS empresarial. S3 File Gateway emula un sistema de archivos, pero no es un sistema de archivos. El uso de Amazon S3 como almacenamiento interno duradero genera una sobrecarga adicional en cada I/O operación, por lo que evaluar el rendimiento de S3 File Gateway con respecto a un NAS o servidor de archivos existente no es una comparación equivalente.

Implemente su puerta de enlace en la misma ubicación que sus clientes

Recomendamos implementar su dispositivo virtual S3 File Gateway en una ubicación física con la menor latencia de red posible entre él y sus clientes NFS o SMB. Al elegir una ubicación para su 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 NFS o SMB.

• S3 File Gateway está diseñado 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 S3 File Gateway implementadas en Amazon EC2, recomendamos mantener la puerta de enlace y los clientes NFS o SMB en el mismo grupo de ubicación. Para obtener más información, consulte Grupos de ubicación para sus EC2 instancias de Amazon en la Guía del usuario de Amazon Elastic Compute Cloud.

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

Recomendamos monitorear la IoWaitPercent CloudWatch métrica para identificar los cuellos de botella en el rendimiento que pueden resultar de la lentitud de los discos de almacenamiento en su S3 File Gateway. Al intentar optimizar los problemas de rendimiento relacionados con el disco, tenga en cuenta lo siguiente:

• IoWaitPercentindica el porcentaje de tiempo que la CPU espera una respuesta de los discos raíz o de la memoria caché.

• Cuando IoWaitPercent es superior al 5 o 10%, suele indicar un cuello de botella en el rendimiento de la puerta de enlace provocado por discos con un rendimiento inferior. 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 la pestaña Supervisión de la consola Storage Gateway o configurar CloudWatch las alarmas recomendadas para que le notifiquen automáticamente si la métrica supera un umbral específico. Para obtener más información, consulte Crear CloudWatch las alarmas recomendadas para la puerta de enlace.

• Le recomendamos que utilice una unidad SSD NVMe o una unidad SSD para los discos raíz y caché de la puerta de enlace, a fin de minimizar el riesgoIoWaitPercent.

Ajuste 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 archivos de S3, es importante asignar suficientes recursos a la máquina virtual de la puerta de enlace, incluidos los discos de CPU, RAM y caché. Los requisitos mínimos de recursos virtuales de 4 CPUs, 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 para cargas de trabajo más grandes, recomendamos lo siguiente:

• Aumente el número asignado CPUs a entre 16 y 48, en función del uso típico de la CPU que genere su S3 File Gateway. Puede supervisar el uso de la CPU mediante la UserCpuPercent métrica. Para obtener más información, consulta Cómo entender las métricas de las puertas de enlace.

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

  nota

  S3 File Gateway no puede utilizar más de 64 GB de RAM.

• Utilice NVMe un SSD para los discos raíz y el disco caché, y ajuste el tamaño de los discos de caché a fin de ajustarlos al conjunto de datos de trabajo máximo que planea escribir en la puerta de enlace. Para obtener más información, consulte las mejores prácticas de tamaño de caché de S3 File Gateway en el YouTube canal oficial de Amazon Web Services.

• Añada al menos 4 discos de caché virtual a la puerta de enlace, en lugar de utilizar un solo 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 desea implementar 12 TB de caché, puede usar 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

  Además del rendimiento, esto permite una administración más eficiente 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 Decidir la cantidad de almacenamiento en disco local.

Al implementar S3 File Gateway como una EC2 instancia de Amazon, 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 su instancia de S3 File Gateway.

• Para ver los tipos de EC2 instancias de Amazon recomendados para S3 File Gateway, consulta Requisitos para los tipos de EC2 instancias de Amazon.

• Puede cambiar el tipo de EC2 instancia de Amazon que aloja un S3 File Gateway activo. Esto le permite ajustar fácilmente la generación de EC2 hardware y la asignación de recursos de Amazon para encontrar una price-to-performance proporción ideal. Para cambiar el tipo de instancia, usa el siguiente procedimiento en la EC2 consola de Amazon:

  1. Detenga la EC2 instancia de Amazon.

  2. Cambia el tipo de EC2 instancia de Amazon.

  3. Encienda la EC2 instancia de Amazon.

  nota

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

• La price-to-performance proporción de una EC2 instancia de Amazon se refiere a la potencia de cálculo que obtienes por el precio que pagas. Por lo general, EC2 las instancias Amazon de nueva generación ofrecen la mejor price-to-performance relación, con un hardware más nuevo y un rendimiento mejorado a un costo 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.

Ajusta el nivel de seguridad de las pequeñas y medianas empresas

El SMBv3 protocolo permite tanto la firma como el cifrado SMB, lo que tiene algunas desventajas en cuanto a rendimiento y seguridad. Para optimizar el rendimiento, puede ajustar el nivel de seguridad SMB de la puerta de enlace para especificar cuáles de estas funciones 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.

Al ajustar el nivel de seguridad de las pequeñas y medianas empresas, tenga en cuenta lo siguiente:

• El nivel de seguridad predeterminado de S3 File Gateway es Exigir el cifrado. Esta configuración impone el cifrado y la firma de las conexiones de los clientes SMB a los archivos compartidos 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, incluso si se CPUs asignan 4 o más v a la puerta de enlace. Por este motivo, el rendimiento de las conexiones cifradas desde un único cliente a S3 File Gateway suele estar limitado a entre 40 y 60 MB/s.

• Si sus requisitos de seguridad le permiten adoptar una postura más relajada, puede cambiar el nivel de seguridad a negociado por 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 múltiples vCPUs, lo que normalmente se traduce en un aumento del rendimiento.

  nota

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

Utilice varios subprocesos y clientes para paralelizar las operaciones de escritura

Es difícil lograr el máximo rendimiento con una puerta de enlace de archivos de S3 que utilice solo un cliente NFS o SMB para escribir un archivo a la vez, ya que la escritura secuencial desde un único cliente es una operación de un solo subproceso. En su lugar, recomendamos usar varios subprocesos de cada cliente NFS o SMB para escribir varios archivos en paralelo y usar varios clientes NFS o SMB simultáneamente en su S3 File Gateway 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, puede esperar lograr 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 su puerta de enlace. Le recomendamos que experimente con distintos recuentos de subprocesos para encontrar el equilibrio óptimo entre la velocidad y el uso de recursos del sistema para su configuración específica de hardware y red.

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

• Puede probar el rendimiento de escritura en subprocesos múltiples mediante herramientas como la robocopia para copiar un conjunto de archivos a un recurso compartido de archivos de la puerta de enlace. De forma predeterminada, robocopy utiliza 8 subprocesos al copiar archivos, pero puedes especificar hasta 128 subprocesos.

  Para utilizar varios subprocesos con robocopy, añada el /MT:n modificador a su comando, donde n se 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 evaluación comparativa de almacenamiento, como DISKSPD o FIO. Estas herramientas tienen opciones para ajustar la cantidad de subprocesos, la profundidad de E/S y otros parámetros para adaptarlos a sus requisitos de carga de trabajo específicos.

  DiskSpd permite controlar el número de subprocesos mediante el -t parámetro. 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

  • Funciona durante 300 segundos () -d300

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

  • Utiliza 64 hilos (-t64)

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

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

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

  Para obtener más información, consulte Usar DISKSPD para probar el rendimiento del almacenamiento de cargas de trabajo en el sitio web de Microsoft Learn.

• FIO usa el numjobs parámetro para controlar el número de hilos 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 I/O prueba 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 I/O la profundidad en 64 () --iodepth=64

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

  • Funciona durante 5 minutos (--runtime=300)

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

  • Utiliza un motor asíncrono I/O () --ioengine=libaio

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

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

Desactive la actualización automática de la memoria caché

La función de actualización automática de la caché permite a su S3 File Gateway actualizar sus metadatos automáticamente, lo que puede ayudar a capturar cualquier cambio que los usuarios o las aplicaciones realicen en su 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 de bucket de Amazon S3.

Para optimizar el rendimiento de la puerta de enlace, recomendamos desactivar esta función en las implementaciones en las que todas las lecturas y escrituras del bucket de Amazon S3 se realicen a través de su S3 File Gateway.

Al 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 su implementación escriben ocasionalmente directamente en Amazon S3, le recomendamos configurar el intervalo de tiempo más largo posible entre las actualizaciones, lo que siga siendo práctico para 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 navegar por 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 de 30 días.

• Si decide establecer un intervalo de actualización de la caché muy corto, le recomendamos que pruebe la experiencia de navegación de directorios de sus clientes 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.

Aumente el número de subprocesos de carga de Amazon S3

De forma predeterminada, S3 File Gateway 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 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 su 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.

Recomendamos usar la CachePercentDirty CloudWatch métrica para monitorear 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 nosotros Soporte para determinar si aumentar el número de subprocesos de carga podría mejorar el rendimiento de su S3 File Gateway. Para obtener más información, consulte Descripción de las métricas de las pasarelas 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.

Aumente la configuración de tiempo de espera de SMB

Cuando S3 File Gateway copia archivos de gran tamaño a un recurso compartido de archivos SMB, se agota el tiempo de espera de la conexión del cliente SMB tras un período prolongado de tiempo.

Recomendamos ampliar el tiempo de espera de sesión SMB para sus clientes 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 de 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.

Active el bloqueo oportunista para las aplicaciones compatibles

El bloqueo oportunista, o «oplocks», está activado de forma predeterminada para cada nueva puerta de enlace de archivos 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. Recomendamos 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 desactivas el bloqueo oportunista, las aplicaciones que admiten los 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 rendimiento alto I/O y bajo.

Ajuste 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 funciona bien para la mayoría de las cargas de trabajo, incluso si hay 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 funcional de archivos de más de 5 millones, la puerta de enlace tendrá que realizar frecuentes desalojos 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 recientes de Amazon S3.

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

Recomendamos utilizar la acción de la UpdateGatewayInformation API para aumentar la capacidad de la puerta de enlace y adaptarla al número de archivos de un 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.

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

Recomendamos 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 la Guía de rendimiento para puertas de enlace con varios recursos compartidos de archivos.

• Los recursos de cada puerta de enlace de archivos 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 recomendamos crear varios recursos compartidos de archivos que estén mapeados 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 de escritura múltiple, lo que puede provocar problemas de integridad de los datos.